はじめに

こんにちは、リンクアンドモチベーションでプロダクトマネージャーをしている社会人2年目の丸井です。

今回、

に向けて、プロジェクトの意思決定に論理性を持たせるために適切な見積もりをしよう
ということを、僕のプロジェクトマネジメントの経験を交えてお伝えしていこうと思います。

起こった問題について

あるプロダクトのアップデートを行うプロジェクトマネージャーとして、プロジェクトを推進したのですが、
プロジェクトは前に進んでいるが、終盤まで不確実性がほぼ減らなかった
ということが起こりました。

なぜ起こったのかを自分が行った内容を元にお伝えします。

プロジェクト開始時にエンジニア経験がないにも関わらず、
完全に感覚で1.5ヶ月くらいで開発が完了すると予測しました。

その後、信頼性がない予測を元にマイルストーンを敷いて進めていきます。
最初は材料のない中でマイルストーンを立てますが、
その後だんだんプロジェクトの実績を通した修正を行うべきです。
しかし、プロジェクトの着地点を把握していないので、その修正を行っていませんでいた。

そして、要件が固まり切ってからようやく見積もりの依頼を行いました。
この要件が固まり切ったタイミングはプロジェクトの最終月の頭です。
↑ここでようやく不確実性が減りました(下図を参照)

つまり、プロジェクトの大半を感覚でしかマネジメントしいなかったのです。
これだけが原因とは言えませんが、プロジェクトは期間内に終わりませんでした。
期間内に終わらないかどうかの報告も遅くなってしまいました。

行うべきだったのは、
精度が高くなくても良いから、定期的なタイミングで開発にどのくらいかかるのか？
という見積もりを行い、スケジュールをマネジメントすることでした。

ただ、ずっと見積もりをし続けていても、かえって効率を悪くしてしまいます。
そこで、先輩エンジニアからどのタイミングでどの粒度の見積もりをするべきかを
教えていただいたので、その方法を共有します。

超概算見積もり
- タイミング
  - プロジェクト初期
- 粒度
  - ポイント計算などなく、◯ヶ月くらいの粒度で出す
    - 経験のあるリードエンジニアが1時間くらいかけて見積もる
全量見積もり
- タイミング
  - 要求〜要件を決め始めたくらい
- 粒度
  - 要件が詰まっていないところ関係なく、一旦全部ポイントを振る
詳細見積もり
- タイミング
  - 要件が固まって、数回スプリント回したくらい
- 粒度
  - 具体的な着地点がだせるレベル

↓不確実性が減少していくイメージ図

これを行うことで、予測に論理が伴います。
早いタイミングでプロジェクトの着地の予測が立ち、
間に合わなそうであれば、早期に対応することができます。

×：情報が集まったら見積もる（積み上げ）
⚪︎：あるタイミングまでの情報を集めて見積もる（逆算）

そのタイミングまでにどれだけの情報を持って来るかが
プロジェクトマネージャーの腕の見せ所です。
エンジニアがどのような情報が欲しいのかを聞く / 想像して収集していきましょう。

見積もりはあくまで予測です。なので外れます。
ある程度は外れることをプロジェクトマネージャーが理解しておくことが大事です。
何もせずに感覚で予測するより、
何かしらの論理の通った予測を持つ方が何百倍も信頼度が高くなります。

この記事が、見積もりを適切に行えず、感覚的な意思決定をしてしまっている方の
参考になれば幸いです。

今回紹介した見積もりの方法は、さまざまな見積もり方法の内の一例なので、
参考程度に捉えていただければと思います！