はじめに

ある日の1on1にて…

ワイ：マネジメントの経験を積んでみたいです
リーダー：そういえば、ちょうどPMが空くプロジェクトがあるからやってみるか

こんな感じで2022年の12月からPMをやることになりました。

実務経験はまだ1年半ほどですが、今までのプロジェクトにはメンバーでしか参画したことがなく、マネジメントをするのは初めてでした。

1ヶ月ほどやってみて得た学びと反省点をまとめて今後に活かしていければと思います。

どんなプロジェクトか

既存サービスのリプレイス開発
自分を入れて5人のバックエンドチーム
スクラム開発(2週間スプリント)
自分も手を動かして開発に携わる(マネジメント全振りではない)

反省点

後続タスクを把握していなかったこと

毎朝行っているデイリースクラムでメンバーから、

今のタスクがもう終わりそうなのですが、次はどのタスクに着手すれば良いですか？

と質問されたのですが、その返事が

次は…えーっと、、(どれをやればいいんだ、、？)

後続タスクがすぐに答えられず、グダッてしまったことがありました。
後から振り返って、着手するタスクも把握してないのに何がプロジェクトマネジメントだと思いました。
この件以降、前日までにメンバーのタスクの進捗を確認して、タスクが枯渇しそうなら後続タスクを確認する作業を入れて対応しています。

バッファを設けずにスケジューリングしてしまった

スプリント初日にスプリントゴールを決めるのですが、過去のベロシティ(1スプリントで消費したストーリーポイントの合計)と各タスクのストーリーポイントで判断していました。

最近いい感じでベロシティ上がってるし、タスクちょっと増やしてみるか

と軽い感じでスプリントゴールを決めました。

前任の方はバッファを1営業日分設けてスケジューリングしていたにも関わらず、自分は全営業日フルで使って終わるくらいのスプリントゴールを設定してしまいました。
結局、メンバーの体調不良での欠席・進捗の遅れが発生し、2タスクくらい未達で終わりました。

全てがうまくいったら達成できるようなゴールを決めるのではなく、不測の事態が起きても対応できるようにするために、バッファを設けることの大切さを感じました。。

メンバーに頼りすぎた無責任な行動

この点が1番反省すべき部分だなと感じています。。

スクラム開発では、PBRというミーティングがあるのですが、羅列してあるPBIのサブタスクをPBRまでに準備するのがPMの主なタスクとなっていました。(あくまで自分のチームの話です。他のチームがどう運用しているのかはわかりません、、)

そんな中、複雑な機能の実装タスクが後続に控えていました。サブタスクを考えないといけないのですが、複雑ということもあって全く検討がつかず、PBRでこの機能ってどんなサブタスクを切ればいいですかねとメンバーに丸投げしてしまいました。

メンバーから返ってきた答えは、PBRの時間だけでは必要なサブタスクを網羅できないでした。
そもそもPBRってサブタスクの見積もりをメンバーと認識合わせする場なので、サブタスクを切ってない状態で臨むのは論外なんですよね。。

後日、サブタスクを自分なりに考えた状態でPBRに臨みました。そこでメンバーから、このサブタスクってどう実装するイメージですかという言葉が返ってきました。自分はハッキリとした答えを返せませんでした。
今回どうやってサブタスクを切ったのかというと、自分のチーム以外にも似たようなリプレイス開発をしているチームがあって、そのチームが切っていたサブタスクを自分のチームに当てはめただけでした。

メンバーからは、サブタスクの実装イメージを持って、メンバーが見積もりの議論に参加できる環境を構築してくださいという指摘をもらいました。

なぜメンバーに丸投げする姿勢になっていたのか

自分を入れて5人のメンバーがいるのですが、全員自分より年上でエンジニア経験もあり、弊社に関わっている期間が長い人たちでした。
そのようなメンバー編成だったので、PMっぽいことをしておけば助けてくれるだろうという考えを、心のどこかで持ってしまいました。プロジェクトをマネジメントするどころか、自分がマネジメントされようとしていました。

今まで参画したプロジェクトのPMの方を思い返してみると、質問したら何でも答えてくれたし、自分の意見をしっかり持った上でミーティングには参加してたし、他人を頼る部分は頼っていたしで、自分の軸をしっかり持っていたなと感じました。

今回メンバーから指摘をもらえたことは本当にありがたかったです。

学び

どう実装するかという設計の工程を経験できている

今までのプロジェクトでは、詳細設計まではほぼ終わっていて、あとはコードに落とし込むだけという段階から参画したことがほとんどでした。

PMになったおかげで、既存のコードを読んでリプレイスではどう実装するかという工程からやらせてもらえているので、正直めちゃくちゃ難しいですが今後もめげずに取り組みたいと思います。

技術力以外のスキルを伸ばせている

PMになってから参加するミーティングが一気に増えました。メンバーとして参画していた時には関わらなかったような方ともコミュニケーションをとる機会が増えたので、他部署との調整力というのは身についているなと感じます。

また、ミーティングのファシリをやることも増えたので、コミュニケーション力・ファシリテーション力というのも身についているなと感じます。(まだまだファシリをやるのは苦手ですが、、)

責任を追及される立場になった

学びというよりは良い経験だと思っているのですが、、

スプリントゴールが達成できなかった時の原因追及
障害が発生した際の一次請け
メンバーのタスク管理
タスクの見積もり

などなど、メンバーの時には経験できなかったことだらけなので、精神的な負荷が増えたのはとても良い経験だなと感じています。

これから

PMはチームの中でプロジェクトに一番詳しい人じゃないといけないというマインドを持って、今後取り組めたらなと思っています。
他人を頼ることと、他人に丸投げするのは全然違うと思っているので、自分の軸を持ちつつチーム全員で助け合いながら開発を進めていきたいです。

2023年の秋頃にリプレイス完了の見込みとなっているので、まずは期日通り完遂できるよう頑張ります！