こんにちは。
今回は前回のバーンアップチャートの利用に引き続き、進捗管理の精度を上げるためにTPM(Technical Product Manager)の私が行ったことを書こうと思います。
具体的に行ったことはたった一つで、 「自分自身でタスクの雑見積もりをしてみる」 です。
どんな人に読んでほしいか
- ProductのManagementをしている中で、一つ一つのタスクがどれぐらい大変なのかがわからない人
- エンジニアにはなるべく開発に時間を使ってほしいと思っている人
- 見積もりってどうやってやればいいか全くイメージの湧いていない人
TL;DR
- タスクを見積もりができる粒度に切り分けましょう
- 自分がエンジニアになったつもりでどうやって実装するのかを考えてみましょう
- 最低でも1日で終わるのか、2日以上かかるのかというレベルでもいいので見積もりをすることで完了予定日のズレが軽減されます
- 副次的に詰まっていない要件を事前に把握することができます
どうやって雑見積もりをするの？
実際に雑見積もりをやっている様子です。
図中にも書いてありますが、自分がエンジニアになったつもりで下記のようなことを考えて見積もります。
- 成果物が何になるのか、実装する箇所がどこなのかを考えます
- 画面の改修があるのか、サーバーサイドのロジックの改修はあるか、データベースに項目追加が必要そうか、Jobを作る必要があるか、など
- やりたいことの対象となる属性条件・タイミングを考えます
- 課金済みかどうか、学年は何年生か、特定の機能に依存しているか、リリースのタイミングはいつか、など
- 既存の実装を流用できないかを考えます
- 似たような機能が存在しないか、過去に似たような施策を実施したことはないか、など
- 余裕があれば実際に似た機能を画面で動かしてみて、キックされているAPIを特定したりコードを読んだりします
- やるべきことが明確か、条件が複雑ではないか、フロント~インフラのどこまで触らなければいけないか、などからどれぐらい実装が大変なのかを見積もります
- 難しければ、1日以内で収まりそうか、2日以上掛かりそうか、という粒度でも構いません
- やるべきことがあまりにも明確でない場合は、再度要件定義から仕切り直します
どれぐらい時間をかけるの？
あくまで見積もりは見積もりですし、どんなになりきったとしてもエンジニアではないので正確な見積もりはできません。
そのため「極力時間をかけずに」行うと良いと思います。
実際に私が15件ほどやった雑見積もりの例では1タスクあたり下記のような感じでした。
| ~1分 | 1分~3分 | 3分~5分 | 5分~ |
|---|---|---|---|
| 7 | 6 | 1 | 2 |
大半は1分とか3分以内で収まってる感じですね。
どうしてやってるの？
前回のブログにて、システム開発を行うにあたっての不確実な要素として、「タスクの増加」と「見積もりができていないタスク」というものを上げました。
ZenHubのバーンアップチャートの利用によって「タスクの増加状態の見える化」と「見積もりができていないタスクに対しての平均値見積もり」が実現できています。
しかし、「平均値見積もり」はあくまで機械的に算出したものであり、現実的にはタスクの粒度はまちまちになってしまうため、必ずしも不確実性がなくなったとは言えません。
特に差し込みが多いチームの場合には、小さいタスクを数多くこなすことなどもあるため、平均値が実感よりも小さく出てしまうことがあります。
この場合は実際に開発を始めると予想よりもタスクが大きくなってしまうことが発生し、結果として 進捗が遅れてしまいます。
雑見積もりをすると何が良いの？
平均値と比べて、少しでも高い精度で見積もることができます。
私のチームではScrumを導入しており、1週間Sprintで開発サイクルを回しています。
これまでは毎週のSprintPlanningの際に、今Sprintで対応予定のタスクに関して、エンジニアが見積もりを実施していました。
そのため、PBI(Product Backlog Item)の中に見積もれていないタスクがかなりの数存在していました。
仮に10個の見積もりしていないタスクがあり、見積もりの平均値が「1日」だとすると、「10日」という見積もりになります。
しかし、自分自身で「1日以内で収まりそうか、2日以上掛かりそうか」というレベルで雑に見積もったとして、4つのタスクが2日以上掛かりそうとなった場合、「14日」という見積もりになります。
もし見積もれていないタスクが50個あった場合は、その差は「20日」となり、約1ヶ月の差が発生します。
早い段階でエンジニアの工数を使わずに 「1ヶ月の完了予定日の差」 を知ることができるので、今後の対応スケジュールや差し込み案件へのコミュニケーションを変えることができるようになりますね。
他に良いことはないの？
前回のブログにも書きましたが、システム開発においては開発着手前の要件定義の時点で、すべてのケースにおいて仕様を詰め切るということはかなり難易度が高いです。
自分がエンジニアになったつもりで考えることにより、企画者として要件を詰めるときよりも詳細な条件やイレギュラーケースまで想いを馳せることができ、結果的に当初よりも要件を詰めることができます。
企画のときはどうしてもハッピーケースをメインで考えがちですが、実装にあたっては例外処理や異なるユーザー属性の場合のパターン、データが消えたとき、更新されたときなど考えることは多岐にわたります。
また、これらを考えた結果として、要件が詰まっていない場合には、 「要件が詰まっていないということを見える化」 できるため、再度企画としての仕切り直しをすることができます。
本当にちゃんと見積もれるの？
エンジニアではないのに見積もりをやったとしても、その見積もりは正確ではないのでは？と思う人もいると思います。
その気になりは至極まっとうだと思います。
そのため私は最初に10件ほど試しに見積もりをしてみて、エンジニアとの目線合わせの打ち合わせをすることで期待合わせをしました。
幸い前職がエンジニアだったということもあり、それほど大きなズレはなさそうという期待値を得ました。
また、Quipperに2年近く在籍していることもあり、プロダクトドメインに知見があるということも上手く働いたかもしれません。
ただ、実は「正確に見積もる必要はそれほどない」と私は思っていて、前述の通り 少しでも高い精度で 見積もることができれば十分だと思っています。
プロダクトマネジメントにおける不確実性は非常に厄介なもので、ともすれば簡単にスケジュールが崩れてしまうものです。
その中で一歩でも二歩でも正確さが上がり、かつコストがそれほどかからないのであれば、十分価値のある見積もりだと思っています。
やってみてどうなったの？
図中に記載の通り、初めて雑見積もりを実施した際に11story pointの積み上げがありました。
現在の私のチームのvelocityが1週間辺り10~15pt程度であるため、およそ1週間ほど精度が上がった状態です。
また、上述の通り企画の仕切り直しをしたケースも見つかり、実施前よりも安心した気持ちでプロダクトマネジメントを進めることができています。
エンジニアと会話する際にも、「こういう実装が必要そうで、こういう条件になり、、、」と言えることでより早く綿密なコミュニケーションが取れている気がします。
仮に見積もりがズレていたとしても、そういった場合には再度エンジニアの方で調査及び再見積もりを実施しているため、やったことが無駄になってしまうということは今の所起きていません。
本記事はTPM(Technical Product Manager)の @shunsuke-nishimura が執筆しました。
本日は連載2回目でした。もう少し続けようと思っておりますので、ご興味ありましたら次回作もお読みください。
