2点見積もりが意外とうまくいった話

はじめまして。DeNAでゲームタイトルのPMを担当しているta1です。

PMになるまでは同チームのエンジニアとしてゲーム開発に携わっていました。PM歴1年の新人ですがよろしくお願いします。

※画像はMSQRDで撮った加工写真なので、実物はこんなにイケメンではありません。

私の担当しているゲームタイトルで2点見積もりと呼ばれる「最小工数と最大工数の2点で見積もる方法」を導入しました。
実際に導入してみて、良かった点や気をつけているポイントなどをいくつかご紹介させて頂きたいと思います。

※以降の説明では少し抽象度の高い書き方をしていますが、実際の経験をベースにしているものです。

■1点見積もりのプレッシャー

2点見積もりに出会うまでは、1つのタスクに対して1つの見積もりを出していました。
次のようなイメージです。

タスク名   担当者    見積もり  
タスク1 Aさん 5日
タスク2 Aさん 3日
タスク3 Bさん 3日

各担当者に見積もりを出してもらうのですが、このような見積もりは担当者に大きなプレッシャーがかかっていました。なぜかというと「見積もった工数はコミットになる」「考慮漏れがあったら遅れてしまう」といった不安がつきまとうからです。

この時のAさんのタスク1の見積もりは5日となっていますが「たぶん3日くらいで終わるけど、2日くらい余裕をもたせよう」と考えて出したものでした。
これはリスク回避という意味では当然の選択だと思いますが、プロジェクトマネジメント的には困った現象が起こります。

  • 時間に余裕があるから、優先順位の低いタスクもちょっとやっておこう」のように本来のタスクを後回しにしてしまい、予期せぬ問題が起こった際に遅れてしまう
  • 時間に余裕があるからダラダラしてしまう」など夏休みの宿題的なアレ
  • 早く終わったから、もっと丁寧に仕上げよう」など本来必要なかった作業をしてしまう

ここで誤解してはいけないのは「メンバーは怠けたりしようとしているわけではない」ということです。
プロとして仕事するために見積もりを行った結果、起こってしまう現象」であることを理解しておく必要があります。

また、逆のケースもありました。
はやく作ってチームに貢献したい/ユーザーに届けたい」という気持ちが強く、工数を少なく見積もり過ぎてしまうケースでした。

この時のBさんの見積もりは3日となっていますが「余裕をもったら5日くらいだが、最短なら3日で終わるだろう」と考えて出したものでした。このケースではスケジュールに余裕がなく、予期せぬ問題が起こった際に遅れてしまいます。

1点見積もりでは、二人とも「最短なら3日、余裕をもったら5日」という、同様の考え方で見積もったにもかかわらず、 ”心理的状況により異なる見積もり結果” となってしまいました。

そこで2点見積もりの登場です。

■2点見積もりの考え方

AさんBさんの例で既にでていますが、「最短なら3日、余裕をもったら5日」これがまさに2点見積もりの考え方です。

まずは1点見積もりをガントチャートにしてみます。

先述したような心理的特性により、タスク1が5日間よりも短く完了することはあまり期待できません。またタスク1が遅れると、連鎖的にタスク2が遅れるリスクがあります。

ここで ”バッファ” という概念が登場します。
 

   バッファ = 余裕のある期日 - 最短の期日


として分解し、バッファはまとめて最後につけます。

まずは最短の期日を目指して開発を進めてもらいます。最短期日で終わらないことも多いですが、その場合は、「バッファを消化する」という形で進捗管理をしていきます。

そうすることで、夏休みの宿題的な現象余計なタスクをやってしまうような心理も起こりづらくなります。

さらに「最短の期日の見積もり」で開発完了する確率を50%と仮定すると、バッファを消費する割合も半分となることが期待できます。

   バッファ =(余裕のある期日 - 最短の期日)÷ 2

このように、各タスクに潜んでいたバッファを明らかにすることで、不足していた工数が可視化され、余剰にとられていたバッファを取り除くことができました。

どちらかというと私はBさんタイプだったのですが、バッファを入れたことで見積もりのプレッシャーが和らぎました。1点見積もりの時は妥協点を探すのに苦労していましたが、そのような悩みも減りました。

■依存タスクによる影響

タスク2に依存タスクがあるケースを考えてみたいと思います。

図のように1点見積もりにタスク4(タスク2を開始するための依存タスク)を追加するとどうでしょうか。タスク1は早ければ3日程度で終わるにもかかわらず、6日目以降にしか着手できないという状況が発生します。

2点見積もりを適用した場合、タスク2の最短着手可能日は4日目となりますが、対応としては2つのケースが考えられます。

  • 依存タスクであるタスク4を4日目に間に合うように前倒しする

  • タスク2の開始日をタスク4にあわせて6日目からとする

どちらが適用できるかはタスク4とCさん次第ですが、タスク2に最短で着手するには、4日目までにタスク4を完了しないといけないことが明らかになりました。

2点見積もりでは依存タスクが必要になる最短の期日が明らかになるのもメリットの一つです。

■実践編

このような考え方に基づき、実際には最短の期日を50%見積もり、余裕のある期日を90%見積もりとして2点見積もりを行っています。

  • 50%見積もり:「この期間で終わる自信は半々くらいという “攻めの見積もり” 」

  • 90%見積もり:「これくらいあれば終わるという “自信のある見積もり” 」

ここで100%ではなく90%としているのは、100%とすると完全さが求められるような心理になって保守的になりすぎるのを避けるためです。

例えば、タスク間の依存関係が少ないプロジェクトではシンプルなタスクリストで管理しています。

タスク名 担当者  50%見積もり 90%見積もり 開始日 終了日
タスク1 Aさん 3日 5日 6/1 6/3
タスク2 Aさん 2日 3日 6/4 6/5
Aさんバッファ Aさん 1.5日 6/6 6/7
タスク3 Bさん 3日 5日 6/1 6/3
Bさんバッファ Bさん 1日 6/4 6/4
休暇 Bさん 1日 6/5 6/5
全体バッファ みんな 1日 6/8 6/8
※簡易化のために土日祝は省略

上の表で工夫している点は次の通りです。

  • 見積もりはスプレッドシートで作成

    • 2点見積もりに対応したツールは少ないので、スプレッドシートで作成しています。バッファは計算式で算出しています

    • バッファをタスクとして扱うことでスケジュールに組み込むようにしています

    • 終了日はWORKDAY関数を使うことでN営業日後の日時を算出しています(WORKDAY関数とNETWORKDAYS関数は営業日計算ができるのでとても便利です)

  • 全体バッファを設ける

    • 開発後半で予期せぬ問題が起きると、個別バッファだけで吸収しきれないことがあるので、全体バッファを入れるようにしています

  • 有給休暇も組み込む

    • スケジュールを一度組んでしまうと、休暇の調整が難しくなりがちです。見積もりに有給を入れることで、キチンと休めるようになりました

    • 基本的にバッファはすべて消化するものなので「バッファが余ったら休暇」という前提にしないように注意する必要があります

■進捗は残日数で報告

私のチームでは毎朝、進捗確認会を実施しています。
ガントチャートを全員で見ながら、各メンバーに進捗状況を報告してもらいます。

「タスク1でハマっていたのは解消されたので、あと2日で完了できそうです」

というように、残日数を報告してもらうようにしています。

例えば「3日間で予定したものが終わらずに、4日目の報告が進捗率70%」だった場合、いつタスクが完了するかわかるでしょうか?
直感的にわかりづらいですし、まだ懸念事項が残っているかもしれません。
そこで、
残日数で報告してもらうことで本当に必要な日数を確認することができるようになりました。

■バッファの消化は警告

1点見積もりでは開発が遅延してから気づくということも少なくありませんでした。
開発メンバーがギリギリまで頑張ってしまうことも多いので、開発完了日当日になって「今日中にはちょっと難しいです」となってしまうこともしばしばありました。

2点見積もりでは遅延する前に必ずバッファを消化するので、バッファを消化し始めた時に「何か予期しない問題が起こっているのかな」と気付くことができ、遅延する前に手を打つことができるようになりました。

■50%見積もりを完了日にしてはいけない

チーム内レビュー会などのマイルストーンが50%見積もり上に置かれてしまったことがありました。
これは
納期に対するプレッシャーバッファに対する誤解から起こってしまったことですが、2点見積もりではバッファを使い切ることを前提としているものですので、50%見積もりをつないだだけの線表では、絶対に間に合いません。

その結果、無理に間に合わせようとして開発メンバーの負荷があがってしまったり、次回以降の見積もりがそれを見越して保守的になってしまう可能性もあります。
そのため、50%見積もりといっているものが、実は90%見積もりになってしまうような事態になると、
1点見積もりの時よりもスケジュールが延びてしまうので注意が必要です。

また、バッファという言葉が、余分にとっている工数であると勘違いして捉えられがちなので、バッファを消化しきったところが開発完了日という認識をチームに持ってもらうことも重要です。

■最後に

今回は開発メンバー単位でバッファを付ける方法についてご紹介させて頂きました。

数名のプロジェクトから十数名のプロジェクトまで適用した実績がありますが、規模が大きくなるとメンバー間のタスクの依存関係による影響が大きくなってきます。
そういったケースではCCPM(クリティカルチェーン・プロジェクトマネジメント)
がとても参考になりました。

試しに導入してみたところ、進捗管理が難しいという課題はあったものの、見積もり・計画にとても強力な助けとなりましたので、興味を持たれた方は、CCPMで調べてみることをオススメします。

最後まで読んで頂きありがとうございました。

※タスクの依存関係とリソース制約を考慮に入れて、最も長いタスクの流れ(クリティカルチェーン)に着目した、プロジェクト管理手法のこと。