こんにちは、EventHubの井上です。2024年12月から2025年3月の約3ヶ月に渡り、エピック（リリースまで数ヶ月を要する中規模以上の機能開発）のプロジェクトマネジメントを担いました。これまでマネジメント経験がない中での挑戦だったため、いくつもの壁にぶち当たりました。本記事では、プロジェクトを通して学んだ3つのことをご紹介します。
開発体制について
本題に入る前に、開発体制についてご紹介します。今回のエピックは以下のメンバー構成でスクラムによる開発を行いました。
- プロダクトオーナー（PO）2名：メインPOとサブPO
- デザイナー1名
- エンジニア4名
- チームリーダー1名
- メンバー3名（私を含む）
上記エンジニア4名は普段から固定のチームで動いています。プロジェクトマネジメントは「エピック担当」という名称で、チームリーダーを含む人員の中から一人がエピックごとに交代制で役割を担います。今回は私がエピック担当として選出されました。
1. プロジェクトの完了に責任を持つ
マネジメントという言葉から、なんとなく「管理する」のが仕事だと思っていましたが、プロジェクトの完了に責任を持つのが仕事だと教わりました。メンバーの協力を得たり、自分自身でも手を動かしたりして、あらゆる手段を使って完了させる意識で取り組みました。
特に意識していたことは以下2点です。
- 自身のコミットしたタスクは必ず期限内に終わらせること
- 全てのPRに目を通し、In Reviewになった当日にレビューすること
EventHubでは1週間スプリントのスクラム開発を行っていて、JIRA上のスプリントに乗せた全てのチケットをDONEにするために、とにかく実装とレビューを頑張りました。メンバーからの協力を得るために、自分は本気でこのプロジェクトを完了させたいんだという姿勢を示すようにしました。
また、レビューサイクルを早めることでチーム全体の実装スピードが上がると感じたため、認知負荷はかかりますが、GitHubやSlackの通知がきたらすぐにレビューするようにしました。
少し根性論のようなやり方かもしれませんが、マネジメントの引き出しのない自分が小手先であれこれやるよりも、自分が誰よりもプロジェクトにコミットするのが、シンプルで効果的だと考えました。
2. 見積もりに時間をかけすぎない
今回のエピックは機能スコープが広く、設計やチケットの洗い出しに苦労しました。普段のエピックでは技術スパイクという形でプロトタイプ的なものを作り、それを元に精度の高い見積もりを行うようにしていますが、全てをカバーしたプロトタイプを作るのは現実的ではありませんでした。
そこで、機能全体に関わる部分だけスパイクを行い、その他は解像度の粗い状態でチケットを切りました。その後のチームでの見積もりも当然ざっくりしたものになりますが、各チケットの担当者が実装する中で精度を高めていった方が、結果的に早くリリースできると考えました。
副作用として、8ptと見積もっていたものが実際は21ptぐらいのサイズだったことが判明したりと、当初よりポイントが膨らんでしまうものもありましたが、不確実性の高いものから取り組むようにしたことで、大幅なスケジュール遅延は避けられました。この点については後述します。
粗い見積もりでプロジェクトをスタートすることにはリスクが伴いますが、実装してみないと分からないことも多いため、早めに実装フェーズに移ることで、結果的にリリースタイミングを早めることができたと思います。例えば、1ヶ月かけて精緻に見積もりし、2ヶ月半のスケジュールを引いてぴったり完了したらトータル3ヶ月半です。一方で、2週間で粗い見積もりをし、2ヶ月のスケジュールを引いて2週間の遅れで完了したら3ヶ月でリリースできたことになります。
ただ、計画より遅延すると今後の開発計画やユーザーコミュニケーションに問題が生じる可能性があります。そのリスクを抑えるために、序盤は仮スケジュールと周知しておき、エピックの中盤でスケジュールを確定するような形にするといいのかなと思います。実際、今回のエピックも「見積もりが粗いので仮スケジュールです」と関係者にお伝えしてから開始しました。
3. 不確実性の高いものから取り組む
見積もりの話と関連しますが、工数やスケジュールの確度を上げるためには、不確実性の高いタスクから取り組むと良いことを学びました。個々のチケットの不確実性の総和が、リリーススケジュールの不確実性だとすると、当然、不確実性の高いものから順に取り組めば、後に残るのは工数が読めているものばかりになるため、スケジュールが予測しやすくなります。何より心理的な面で安心です。
ただし、不確実性の高さよりも優先すべきは、チケット単体でユーザーに価値提供できるものです。結果的に同じ工数なら、ユーザーへの提供は早いに越したことはないからです。また、DBマイグレーションなど先に終わらせておくことで後続のタスクがスムーズに進むものは、並列でタスク消化できるように優先すべきです。
以上を踏まえ、今回のエピックでは以下の優先順位でチケットを配置しました。
- ユーザーに価値提供できるストーリー
- 複数のブロッキングになるタスク
- 不確実性の高いタスク
- その他のタスク
不確実性の高いタスクは実装方針が不明瞭なことも多く、難易度が高いです。そのため、着手することに不安を覚えます。「どのチケットやりたいですか？」という希望性で取っていくと、たいてい不確実性の高いタスクは敬遠されて後ろ倒しになってしまいます。なので、不確実性の高いことから取り組む重要性をチームで共有し、勇気を持って先に着手していくことが大事だと思います。私個人としては、少なくとも選り好みはしないように気をつけました。
余談ですが、今回のエピックでは、序盤に不確実ではないと判断していたものの、後半になって考慮漏れがあったことに気づき、大幅な作業量増になってしまったチケットがありました。この問題の原因や防止策はチームで改めて振り返る予定ですが、目の前の実装に集中するあまり、チケットの再整理に時間を割けていなかったのが個人的な反省です。このあたり、自身の技術力やマネジメントスキルの不足であると実感します。
さいごに
今回のエピックは3月末で一旦終了となる予定ですが、来月すぐに後続のエピックが控えていて、そのマネジメントも引き続き担当します。きっと最適なプロジェクトマネジメントの仕方があるのだと思いますが、たった数ヶ月で熟練することはできなさそうです。今回と同じく個人としてはフルコミットでやりつつ、周囲の方の助けをお借りして、完了責任を果たそうと思います。
初めて指揮役をやってみて気づいたのは、チームの中にプロジェクトにフルコミットしてくれる方がいるととても心強いということです。自分自身もメンバーとして入る際は、今まで以上に前のめりな姿勢でやろうと思っています。プロジェクトマネジメントはなかなかタフな仕事ではありますが、個人の成長という意味でもすごく価値のある経験でした。3ヶ月間、未熟なマネジメントで課題だらけの中、一緒に走りきってくれた皆さんに心から感謝しています。
現在、EventHubではエンジニアを募集しています。本記事を読んで少しでも興味を持ってくださった方は、ぜひカジュアル面談からご連絡ください！
