スケジュールにバッファを設けるのは悪か？

こんにちは、Tajiyyyです。
保育業界のスタートアップにて、PdM（プロダクトマネージャー）をしています。

はじめにお断りしておきますが、本記事は、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でベロシティを計測し、バーンダウンをチーム全員で確認しています。幸い大きな前提の変更なく、概ね計画通りに進行していることが分かったので、計画変更に追われることもありませんでした。
ただ、毎週の進捗管理により、もし計画から差分があった場合にも、きっとすぐに検知、適用できたとも思っています。

おわりに

この記事では、
・バッファは、見積もり誤差として予め認識しておくこと。
・誤差の見積もりには、「不確実性コーン」が有用であること。
をご紹介しました。（今回ムスカに字幕を付けてみましたが、不確実性コーンはとってもいい奴です。）

ただ、見積もりと計画管理は、今回紹介した「バッファ」以外にも様々な考慮が必要で、かなり高度な作業と感じています。また今後、言語化して整理しようと思います！

以上、ありがとうございました！