こんにちは、プロダクトマネージャーの田嶋です。
はじめにお断りしておきますが、本記事は、2021年7月にリリースした開発プロジェクト（以降「Rプロジェクト」）において、遅延なく開発を進められたことのプチ自慢です🎉 笑
週次で滞りなくバーンダウンが落ちていく様子を、チームで安心して見ることができました。スケジュールのストレスなく開発を進めることができたのは、チームの頑張りのほか、見積もりとスケジュール管理が良かったからだとも思っています！
開発プロジェクトにスケジュールが求められる理由は様々ですが、キャンペーン施策や営業資料の準備計画を立てるため、あるいは利用顧客へも告知責任があるから、などです。そのいずれの場合も、計画やそのための作業見積もりは欠かせません。
しかし多くの開発プロジェクトにおいて、実績は見積もりよりも上振れし、遅延してしまうことが多いのではないでしょうか。
本記事では、Rプロジェクトにおいて、遅延なく開発を進められた要因である「バッファ」の考え方と、「不確実性コーン」の勧めをしようと思います！
【目次】
1.バッファ？なにそれおいしいの？
まずはバッファの定義から確認してみましょう。
バッファとは「緩衝材」という意味ですが、時間管理においては「遅れたスケジュールを取り戻すために使われる予備時間」を指します。
みなさんには、バッファは順調に進めば消化せず、不測の事態が起こった時に利用するもの、というイメージがありませんか？ これだと、ステークホルダは最短のスケジュールを期待するし、バッファを使おうものなら遅延があったかのような印象です。 「なぜ遅延が起こっているの？」 「見積もりが甘かったからです、バッファを使います。」 なんてやり取りが今日も聞こえてきますね・・。
そもそも作業は、始めるまで分からないことがあるため、完璧な見積もりなど存在しません。つまり見積もりは実績とズレることを前提に考えるべきでしょう。そしてこの「ズレ」は、どれだけの情報を基に見積もりを行ったか？に見合った「誤差」として考慮する必要があります。
すると「バッファ」という表現が良くないかもしれません。予備ではなく「誤差」と捉える。この誤差を含めた計画をすべし！というのが本記事の主張です。
2.誤差をどう見積もるか？
以前までの私は、工数の0.2倍程度をバッファとして積む計画をしていました。（「こんなにバッファ必要？」と上司からコメントを受けて、0.2倍→0.15倍に削るなど・・）
しかし上述のとおり、どれだけの情報を基に見積もりを行ったか？ ≒ いつ見積もりを行ったか？に応じて、誤差の大きさは異なります。エイヤーでX倍とするのは、この誤差を見誤る可能性もあるでしょう。 ・・・実は、この誤差について、先人たちの知恵で既に表現している図がありました！「不確実性コーン」です。（参考文献はこちら）
プロジェクトの初期ほど見積もり誤差が大きく、終盤へ向かうにつれて小さくなることを、縦軸のブレ幅で示しています。その形がまるでコーンのようだと。
【ブレ幅の数値まとめ】 p1 初期コンセプト：4.00〜0.25倍 p2 承認されたプロダクト定義：2.00〜0.50倍 p3 要求の完了：1.50〜0.67倍 p4 UI設計完了：1.25〜0.80倍 p5 詳細設計完了：1.13〜0.87倍 p6 実装完了：1.00〜1.00倍
Rプロジェクトは10以上の複数の案件から成るものでしたが、それぞれの見積もりに、この進行フェーズに合わせた誤差を上乗せ※した計画を行いました。 （※不確実性コーン自体は下振れの可能性も示唆していますが、当時のスクラムマスターの経験則的に上振れすることが多い、とのこと。）
また開発工程には、要件定義/デザイン/設計/実装/QAなどがありますが、Rプロジェクトではエンジニア作業分として、設計/実装のみの計画にこの不確実性コーンを適用していました。
ちなみにこの計画で忘れがちなのが、不具合改修の期間。これは、バッファではなくQA期間に含めて設けるのが良いと思います。
3.スケジュールは進行管理とセットで。
不確実性コーンの使い方として、ある時点の見積もりはできても、プロジェクトの進行とともにどう管理していくか？という疑問があると思います。
もし当初の見積もりから前提や条件に変更がある場合は、再見積もりを行い、その進行フェーズに合わせた係数を掛けて再計画します。
一方で変更がない場合、再見積もりは行いませんが、こちらも進行フェーズに合わせた係数を掛け直して、バーンダウンの山を小さく調整します。これとセットで、稼働するチームのベロシティを計測し、バーンダウン上で着地予想をするのが、Rプロジェクトではうまく機能しました！
フェーズ毎の調整を行う上で、元の見積もり値と、係数を掛けた後の値は、それぞれ別で管理しておくのが良いと思います。
また弊チームは、1週間スプリントでスクラム運営しており、毎週のSprintPlanningでベロシティを計測し、バーンダウンをチーム全員で確認しています。幸い大きな前提の変更なく、概ね計画通りに進行していることが分かったので、計画変更に追われることもありませんでした。 ただ、毎週の進捗管理により、もし計画から差分があった場合にも、きっとすぐに検知、適用できたとも思っています。
おわりに
この記事では、 ・バッファは、見積もり誤差として予め認識しておくこと。 ・誤差の見積もりには、「不確実性コーン」が有用であること。 をご紹介しました。（今回ムスカに字幕を付けてみましたが、不確実性コーンはとってもいい奴です。）
ただ、見積もりと計画管理は、今回紹介した「バッファ」以外にも様々な考慮が必要で、かなり高度な作業と感じています。また今後、言語化して整理しようと思います！
以上、ありがとうございました！
ーーーーーーーーーーーーーーーーーーーーーーーーーー ユニファでは、新たな仲間を積極採用中です。 プロダクトマネージャーも大絶賛募集中！よろしくお願いします！ herp.careers
