こんにちは、ログラスの松岡(@little_hand_s)です
3行まとめ
- バッファを適切に積まないと、計画が遅延する可能性が高まる。
- バッファを積みにくくする心理的バイアス(計画錯誤、過度に守備的と思われる不安)が存在する。
- バイアスを打ち破るために、内訳を分解して過去の実績データに基づいて算出する「分解・ファクトベースバッファ」を使うとよい
※この記事ではアジャイル開発を例に説明しますが、考え方はウォーターフォールなど他の開発手法でも使えます。
リリース計画、遅れてない？
リリース計画を立てても、計画通りに進まないことが多いですよね。こんな経験、ありませんか？
- リリース計画を立てたのに、予定より大幅に遅れる
- 「あと少しで終わります」が何度も繰り返される
- 見積もりを伝えた相手からの信頼が失われていく
原因は、見積もりに問題があることが結構あります。では、問題のある見積もりとはどんなものでしょうか？
原因1: 見積もりが感覚によっている
内訳を考えずに「大体の規模感」や「これくらいでできたら嬉しい」だけで見積もるケースがあります。
これらに共通するのは、感覚的な見積もりになっていることです。
何をどれくらいやるのか具体的に検討できていないため、「あ、これも必要だった」が後から出てきて、遅延しやすくなります。
原因2: バッファを積んでいない
見積もり自体はちゃんとやった。タスクも洗い出した。
しかし、洗い出したタスクの合計だけで計画を立てているケースがあります。
現実には、ほとんどの場合で 計画時に見えていないタスクが発生します。
- 要件追加・仕様変更
- 割り込みタスク（作業依頼、問い合わせ、トラブル対応…）
- 見積もり誤差
なぜなら、プロダクト開発には不確実性が存在するからです。
バッファとは、「計画時に見えていない不確実性を吸収するための時間」 です。
よって、バッファを積んでいないと、想定外のことが起きた時、スケジュールがずれます。
でも、バッファってなんだか積みにくい
バッファを積めば良いと頭では分かっていても、実際に積むのは難しい と感じることはないでしょうか。
なぜ積みにくいのか？それは 心理的な要因があるからです。以下、2つ紹介します。
1. 計画錯誤（Planning Fallacy）
バッファを積みにくい理由の1つは、計画錯誤です。
これは、「過去の経験を知っていても、未来の計画では楽観的に時間を過小評価してしまう」 という心理現象です（ノーベル賞学者カーネマンが提唱）。
たとえば、大小さまざまなプロジェクトで発生します：
- 東京五輪の予算：7000億円 → 3兆円超（4倍以上）
- シドニーのオペラハウス：当初4年 → 実際14年（3.5倍）
- 個人の引っ越し：「3時間で終わる」→ 実際8時間（2.7倍）
なぜ起こるのか？私たちは「今回はうまくいくはず」という心理的な期待を優先して、過去の失敗データを軽視してしまうからです。
「バッファを2週間積む」と言われると、心理的に「長すぎる」と感じて受け入れにくくなることがありますが、これも計画錯誤によるものです。
2. 過度に守備的と思われる不安
もう1つの抵抗があります。それは 「見積もりを伝えた相手から過度に守備的と思われないか」 という不安です。
バッファを積むこと自体は正しい判断なはずなのに、「多めに見積もっている」「保守的すぎる」と受け取られるのではないかという後ろめたさを感じてしまうことがあります。実際、過去の実績や信頼関係によっては、懐疑的に受け止められてしまうこともあります。
どうすればいい？
この2つの要因は、バッファの「積み方」 で大きく改善できます。
解決策：バッファを分解して、ファクトベースで考えよう
ポイントは2つあります。
- 内訳を分解する
- ファクト（事実・データ）に基づく
この2つを考慮したバッファを、この記事では「分解・ファクトベースバッファ」と呼びます。
なぜ「分解・ファクトベース」なのか？
ポイントは「不安だから積んでおく」ではなく、「内訳を分解し、過去の実績データから判断して必要だから積む」 と捉え方を変えることです。内訳を明示し、データをもとに算出すると、合理的な判断として受け入れられやすくなります。
分解・ファクトベースバッファの積み方
ステップ1: ベースとなる見積もりを出す
日数で見積もっても、ストーリーポイント（以下SP）で見積もっても、どちらでも大丈夫です。
参考：ストーリーポイントとベロシティを使った期間見積もりについての解説
ストーリーポイント（SP）とは
作業の相対的な規模を表す単位です。かかる時間ではなく、規模・複雑さ・不確実性 を考慮したサイズ感で見積もります。
基準となるタスクと比較して相対的に評価します。
例：
- ログイン機能の実装：3SP（基準）
- ユーザー一覧表示：5SP（ログインより少し大きく複雑）
- 複雑な検索機能：13SP（ログインの4倍以上の規模と複雑さ）
ベロシティとは
チームが1スプリントで完了できるSPの合計です。過去のスプリントの実績から計算します。
例：
- スプリント1：完了したタスク = 20SP
- スプリント2：完了したタスク = 25SP
- スプリント3：完了したタスク = 21SP
- ベロシティ（平均）= 22SP / スプリント
期間見積もりの計算
必要なスプリント数 = 総SP ÷ ベロシティ
例：
- 実装したい機能の合計：100SP
- チームのベロシティ：22SP / スプリント
- 必要なスプリント数 = 100 ÷ 22 ≒ 5スプリント
このように、SPとベロシティを使うことで、日数ではなく相対的な規模から期間を見積もることができると言われています。
ただし、それだけではだめ！ というのがこの記事の趣旨です。
ステップ2: 内訳ごとにバッファ比率を決める
見積もりを出したら、次はバッファを要素分解して内訳を考え、それごとにバッファ比率を決めます。たとえば以下のような内訳です。
- 見積もり誤差
- 想定より複雑だった、仕様が曖昧だったなどで増加する分です。
- 要件追加
- 途中で計画になかった機能追加や修正の工数増加分です。
- その他
- 割り込みタスク、バグ対応など
- なお、開発機能の規模に比例しないと考える場合は、期間に日数を直接加算する形で計算するのもありです。
- (結合テスト)
- 最初の見積もりに入っていれば不要です。
- 開発機能の大きさと結合テスト工数には相関があるので、この段階で一定比率で概算見積もりするのもありです。
内訳はプロジェクトによって変えても大丈夫です。上記を参考に、ご自身のプロジェクトに合わせて調整してください。
具体的な比率の例
- 見積もり誤差：20%
- 要件追加：20%
- 割り込みタスク、バグ対応など：20%
これを合算すると60%になります。
「バッファ60%」と聞くと直感的に「多すぎ！」と感じませんか？
でも、内訳を考えるとどうでしょうか？
SP(ストーリーポイント)見積もりで説明します。
-
見積もり誤差20%：
- 開発には不確実性があり、見積もり誤差は必ず発生します。
- 週に5SP消化できると思っていたのが4SPだっただけでも20%のぶれです。
-
要件追加20%：
- 20SPに機能追加が4SP分あれば20%増です。
- スプリントレビューのフィードバックを考えると、これくらいは十分増える可能性があります。
-
割り込みタスク、バグ対応など20%：
- 問い合わせ対応、緊急バグ修正、仕様確認など、開発中には様々な割り込みが発生します。
- 20SPに対して4SP相当の開発規模の割り込みを想定します。
このように内訳を示してみると、「60%はいらないだろう」と違和感を持っても、「積み重ねると意外と否定できないかも…」と感じるかもしれません。
数値に納得できなくても、「全てをゼロと仮定するのは危険かも」 という感覚が生まれると思います。計画上無視できない要素があることに気づけた段階で、大きな前進です。
ステップ3: 過去データから比率を調整する
内訳を考慮しても、楽観的なバイアス（計画錯誤）は残っています。
そこで、過去のプロジェクトで実際にどれくらい増えたかを参考に、数値を微調整します。
例1: 過去データが今回より大きい場合
- 今回は見積もり誤差を20%と置いたが、類似プロジェクトでは実際に30%だった
- →減らして良い理由がなければ同じ比率にしましょう！
- 理由が説明できないのに「でも今回はいけるはず」と考えるのは、まさに計画錯誤が働いている証拠です。
例2: 今回のプロジェクト特性を考慮する場合
- 過去プロジェクトでは要件追加は20%だったが、今回は仕様の不確実性がより大きい（または小さい）
- →不確実性の多寡に応じてバッファ比率を上げ下げできます
例3: 開発以外の割り込みを想定する場合
- 新規開発の見積もりだが、直近リリース内容に対する改善要望なども入ってくる可能性がある
- →開発するもの以外の割り込みも想定できると、現実的な見積もりになります
ステップ4: 計算する
内訳ごとのバッファ比率が決まったら、最終的な期間を計算します。
見積もり × (100% + バッファ率) = 実際にかかる期間/ポイント
ステップ5: プロジェクト運営中に記録し、次回に活かす
プロジェクト運営中、各内訳がどれくらい増減したかを記録しましょう。この記録が次回の計画精度を上げる鍵になります。
FAQ
Q1: 初めてのプロジェクトで過去データがない時はどうすればいい？
A: まずは内訳ごとの検討(ステップ2)を実施しましょう
過去データがなくても、「どれくらい誤差と要件追加があるか？」と考えるだけでも、ざっくり全体を見積もるより遥かに良くなります。
また、少し開発を進めた段階（最初は2週間程度が目安）で、バッファ比率を再検討しましょう。
例：
- 2ヶ月のプロジェクトで、要件追加を20%と仮定
- 2週間（全体の1/4）経過時点で、すでに要件が10%増えていた
- →このペースだと最終的に40%になる可能性がある
- →見積もり、スケジュール、スコープなどの変更要否を再検討する
このように、途中経過で得られた情報も「実績データ」として扱えます。
仮説を立てて、ファクトベースで検討することで、徐々に精度を上げていくことができます。
Q2: 見積精度を上げればバッファ率を下げられるのでは？
A: Yesですが、精度向上にもコストがかかるため、費用対効果を検討しましょう
1-2時間の検討で精度が上がるならやるべきですが、1-2週間かかるならコストに見合わない可能性があります。
また、プロダクト開発の不確実性に対して、作業開始時点の情報では精度が上がらないケースもあります。そういう場合は、作業を始めて新しい情報を得てから見積もりを再検討した方が効率的です。
大切なのは、今どれくらいの精度で見積もれているかを自覚し、それに応じたアクションを取ることです。
精度が低いと考えられる場合の対応例としては、
- 不確実な部分を先に解消するように計画する
- 開発途中で再見積もりする
- スケジュールが厳しくなる可能性があるなら、早めに検知して目標時期の再検討や交渉を行う
といったことが考えられます。
まとめ
リリース計画には、分解・ファクトベースバッファ(内訳を分解し、過去の実績データに基づいた判断)を積みましょう
なぜ分解・ファクトベースバッファが必要か？
- ✅ 心理バイアスを排除できる（計画錯誤・楽観バイアス）
- ✅ 調整しやすい（根拠があるから柔軟に対応できる）
- ✅ 精度が上がる（記録して次回に活かせる）
- ✅ 信頼を得られる（内訳が明確だから納得してもらえる）
ぜひ、試してみてください！
書籍紹介
本記事ではアジャイル開発におけるリリース計画について扱いました。
アジャイル開発でよく課題になるもう1つのテーマが、複雑なビジネスロジックをどう設計するかです。この課題に対しては、ドメイン駆動設計（DDD） が役立ちます。DDDはビジネスロジックを整理し、保守しやすいコードを書くための設計手法です。
筆者はドメイン駆動設計について以下の書籍を執筆しています：
①基礎編: 初めてDDDを学ぶ方向け。基礎概念から実装パターンまで幅広く解説しています
②実践編: 実践時の頻出の疑問にサンプルコード付きで回答しています
著者について
AI駆動開発・DDD・アジャイルに関する情報を発信しています。よろしければフォローしてください。
Discussion