この記事は セゾンテクノロジー Advent Calendar 2024 5日目の記事です。
シリーズ2は HULFT10 のエンジニアによる投稿をお届けします。
はじめに
私はHULFT開発責任者として、HULFT10プロジェクトでプロジェクトマネージャー(PM)と2つのプロジェクトリーダー(PL)、そしてリリースレディネスのリーダーを兼務しました。
開発部長とPM、PLを兼務するのは明らかにプロジェクトマネジメントとしてはアンチパターンなので全く推奨できませんが、なぜこのようになったのかは今回割愛します。
兼務とはいえ、私の稼働時間が5倍になるわけではないので、限られた時間の中で多角的にプロジェクトマネジメントをするために私が意識したことを4つご紹介します。
前提
- 開発手法はウォーターフォールを採用しています
- スクラム手法のような体系立ったコツはなく、実践ベースで記載しています
- PMとしてマネジメントする開発チームは、全8チームです
- 内、2チームのPLをプロジェクト途中から兼務
本質にこだわる
進捗管理の方法は？JIRA？Excel？
タスクの単位は？ストーリーポイント？人日？チケット数？
コミュニケーションプランは？Daily？Weekly？
マネジメントする人は大体忙しそうにするので、マネジメントしやすい方法を選択しそうですが、プロジェクトマネジメントの本質は
見積もる→フォーキャストを出す→実績ギャップを見る→振り返る→改善する
だと思っています。また、実際に開発をするのはデベロッパーなのでマネジメント面の負担を極力なくし、単位や方法にはとらわれずにやりやすい方法でやってみることを意識しました。
ただし、使えるツールは徹底的に使うことは意識します。
※開発ツールはすべてデベロッパーが使いやすいものを選定
- JIRAフィルタは自分が見やすいように自分でカスタマイズ、毎朝全チームの進捗を確認
- Tableauで工数進捗を可視化、毎週眺めるだけ
- Slackは全チャンネル参加、アクティビティや言動を横から見る（たまに口出しする）
- Gather（仮想オフィス）で誰と誰が会話しているのか見る
- 進捗報告資料はパワポを撤廃して、Boxnoteへ
PMとして、進捗報告は以下の点を毎週確認しました。
進捗は、「前倒しだけど問題あり」「遅れだけど問題なし」みたいな関係性であることも明示し、課題とリスクを混在させないよう、明示的に分けています。
- 前倒し or オンスケ or 遅れ
- 問題あり or 問題なし
- リスク and 課題 and 対策
見積もりと実績の振り返り
ストーリーポイントを使っているチームもあれば、工数を使っているチーム、高中低の三段階でやっているチーム、いろいろありました。プロダクト開発を中長期的に考えるのであれば、ある程度決まった方法で実施していく方が良いと思いますが、今回はそこに時間をかけずにとりあえず日本語（簡単、難しい）でも良いからデベロッパーに言ってもらってそれを無理やり定量的にしていく（簡単→1点、難しい→3点みたいな）ことでフォーキャストと見積実績比を出せるようにしていきました。
振り返りにおいては以下を意識し、デベロッパーたちへも意識させるようにしました。
- なぜ、うまくいったのか？ も言語化する！
- 実績乖離が出た際の最頻出ワードは 「見積もりが甘かった」 ですが、これ許容せず徹底的に深堀りする！
- 乖離は遅れだけではなく、前倒しも同じ！
- そして責めない！（プロジェクトメンバーで責められていると感じている人がいたらごめんなさい）
総じて、
前倒しでも、オンスケでも、後ろ倒しでも、全て なぜそうなった？ を行う。
前倒しならOKみたいな考えは保守的な見積もりにさせてしまうと思っています。
見積もり時に根拠を徹底的に出してレビューすることでリスクヘッジすることも重要ですが、精度100%の見積もりは完了するまで出ないので、実績が出た（もしくはもう大幅に乖離することが分かった）時点での振り返りを重視していました。見積もりと実績の差を見ながらデベロッパーの振り返りコメントを聞いていると、改善ポイントやフォーキャストを図る上でもとても効果的です。
ちなみに、今回のプロジェクトでは1週間での見積もり差異が最大3倍（前倒し）みたいなところもありましたが、そこは徹底的に褒めて、そのベロシティで安定させようとしました。
リスク管理は特化型で
リスク管理でよくありそうなのが、定常的にあるものをプロジェクトリスクとして出してしまうことかなと思います。例えば、エンジニアの離脱（体調不良や退職）、災害・業務停止、別タスクの増加（プロジェクト稼働率の低下）など。
こういうものは、大体に人が常日頃考えているのですぐに頭に出てくるんですが、たくさん出せば出すほどプロジェクトの本質的なリスクは影が薄くなります。常日頃のリスクは部門としてリスクヘッジするものであり、プロジェクトではプロジェクトに特化したリスクを出すことで、常に最悪のパターンを想定して予兆があれば早めに動くということができたと思います。
森と木の両方を見る
木を見ながら森を見るのはなかなか難しいですよね。意識的に細かいところを見ながら全体を見ようとすると難しいので、全体を見ながら細かいところはある程度気にしない（任せる）ことを意識しました。なんか少し矛盾している気もしますが、マイクロマネジメントは疲れるし、時間が無制限なら良いですが、どうしても限界があります。
すべてを細かくトラッキングするのではなく、今やっているチケットの重要度やプロジェクトへの影響度、マイルストーンとチェックポイントはどこか、細かく見るところと見ないところを自分の中で最初にある程度決めて、しっかり線引きしていくこともうまくいったポイントかなと思います。
そして、マネジメントする人はある程度の余裕を見せることも大事かなと思います。なんとなくメンバーからは○○さんは忙しいから…って思われてしまいますが、Slackは即時応答（遅くても即日応答）、疲れはプライベートで出す、でもたまに愚痴をこぼして人間らしさも出す、みたいなところも重要かなと思います。
※私自身、即応答を心がけることで、判断力強化のトレーニングにもなりました！
まとめ
体系立った知識や技術も非常に重要だと思いますし、学び続けることはとても大事です。ただ、どうしても実際の現場やプロジェクトになるとうまくいかなくなることの方が多いと思います。人間ですからね。
そんな時に総じて意識したことは、手法ではなく本質や目的を意識して応用すること、そして徹底的に楽をすることでした。書いた内容で、どれか一つでも実践してみようという方や同じ悩みを持っている方の何かになれたら嬉しいです。