不確実性コーンの話
引用: 日経クロステック
ソフトウェア開発の各段階での不確実性を示した図。
1981年にバリー・ベームが発表し、後にスティーブ・マコネルが命名した、ソフトウェア開発の各段階での不確実性を示した図です
引用: PROMAPEDIA
プロジェクト初期のGD(企画)、RD(要件定義)フェーズなどの不確実性が高いため、見積には最大4倍(下振れ/上振れ)の可能性がある。
フェーズが進んでいくと工数見積もりのブレが少なくなってくる。これはプロジェクトを何度もこなしているとよく分かると思うが、肌感にも合っている。
なぜこのようなコーンになるのか(上流工程での不確実性の高さ)
シンプルに、上流工程での不確実性の高さに依る。
下流工程(詳細設計以降)では仕様が確定しており、流石にこのフェーズまでにアーキテクチャ/フレームワークも決まっており(流石に決まってないPJには出会ったことがない…)、見積は既存の諸方法を使用すれば、そうそう大きな誤差が生まれることは無い。機能数/画面数/難易度(ざっくりでも)が決まっていて、開発メンバ側にもざっくりとしたスキルレベル設定をしておけば、工数が当初見積もりよりも大きく変わることは無いはずである。実体験として、私がリーダーとして牽引したPJ(5本程度だが)では、詳細設計以降で大きく工数上振れしたことは無い。
言い換えれば、下流工程は決まるべきことが決めっていて不確実性が低い。(もちろん、下流工程でも仕様変更を受け付けていては、工数が上振れすることは言うまでもない)
一方で、どんなPJでも上流工程はボラティリティは下流工程よりも大きくなる。不確実性が高いからである。
企画、要件定義フェーズでは、「どんなスコープを」「どんなベンダと」「どんな制限があって(社内のポリシやNWなどのインフラ/ハードetc…)」「顧客サイドの隠れルール」「業務仕様」「まだ議論に上がっていない隠れた仕様」「顧客が真に達成したい意図」などなど、見積のための正確な情報のINPUTが不足している点が大きい。
PJ初期の段階で情報が網羅的に全て揃っていることなどありえないし、フェーズを進めていく上で見える気づきなどもあるため、どうしても不確実性は高くなる。
どのように不確実性を潰していけるのか
2021/03/23 メモベースで書いているので後日清書
情報収集の定型化(ある程度の)
GD(企画)フェーズやRDフェーズを進めるにあたって、最低限この情報は拾っておくべきだろう、というのはPJを何度も推進している人間なら勘所を持っているはずである。それらをチーム、会社レベルで収集、汎化して、できるだけ上流工程での情報取得/深掘り漏れが起きにくいようある程度定型化しておくことが望ましい。
若干単元からは外れるが、これら情報の収集には時間がかかる(主に顧客側の足が遅い(誰に聞くべきか、それは正しい情報か、現場と実態差異が無いのかetc))ため、先行して洗い出しを行い、顧客にヒアリング、場合によっては自チームが主として推進することも必要になる。
同じ顧客に対してのPJを獲得する
1度とある顧客に対してのPJを経験したことがあるのであれば、同顧客の次案件では不確実性が下がるはずである。
顧客の仕事の進め方、スピード、押さえるべき観点、ステークホルダ、社内ルールetcなどの暗黙知を既に習得しているからである。
顧客を巻き込んだPJ推進方法がかなりクリアになっているため、工数ブレは少なくなる。
同じチームでPJを推進する
顧客が変わったとしても、自社内のチームメンバが同じであれば、案件の不確実性は下がるはずである。
チーム内の各メンバの性格、仕事の進め方、仕事の処理能力などなど、数字としては見えない部分を既に把握しているからである。
次のPJではメンバが全員変わっている…という場合は、どうしても不確実性が上がってしまう。
同じ業界の顧客に対してPJを推進する
過去PJと業界が同じであれば、ある程度不確実性を下げることができる。
その業界の気質であったり業務ルール等を既に認識している点、その業界に対する業務のあるべき(一定の)を既に把握しているからである。
個人の感想だが、業務知識/業界知識の習得は、それ以外のスキル(仕事の進め方などのメタスキル、テックスキル(設計やプログラミング))の習得よりも大変である。業務知識/業界知識は体系化されたINPUT情報が極めて少ないからである。
書店などに行ったら分かると思うが、テック系のスキルやビジネススキル本などは、体系化されており出版本の数も多く、良書も存在する。
一方で、業務知識を体系的にまとめた書籍は極めて少ない。よって、新しい業界の知識INPUTは本当に難しい。
適切なスコープ分割
上流工程の工数見積もりがx倍になってしまう、の根本解決にはなっていないが、コストが掛かり過ぎてしまうことの対策として有効。
また、スコープが分割されることで、PLが見る範囲を小さくすることができ、顧客折衝密度の向上、より詳細な仕様検討等、後続フェーズを見据えても良い効果が大きい。
不確実性の高さ解消というよりも、スコープを小さく切っておくことで、リリース時のコストが低くなる側面が大きいが、PJ推進するのであれば観点としては必須ということで一応記載。
まとめ
- プロジェクトの上流工程は不確実性が高く工数見積もりに大きなばらつきが生じる可能性がある。
- 不確実性を下げるための対策としては例えば下記が有効
- 情報収集の定型化
- 同じ顧客に対する案件の獲得
- 同じチームでの案件推進
- 同じ業界での案件の獲得
- 適切なスコープ分割
