■ 1. 見積りと計画の混同による問題
- 対立の発生:
- 見積りを作成した開発チームとそれを確認したビジネス担当者や経営者がその内容を巡って対立することがある
- 見積りが大き過ぎるやいやこれぐらいはかかりますよといったやり取りが発生する
- 混同の原因:
- 両者がともに見積りと計画を区別せず混同しているから発生している
- 見積り依頼を受けた時開発チームが提出するものはおそらく見積り
- しかしビジネス担当者や経営者が期待するアウトプットは計画
- 組織への影響:
- 見積り依頼という名のもとにソフトウェア組織に対立が日々生じている
■ 2. 見積りと計画の違い
- 見積り工数の例:
- 見積り結果の30人月という数字は計画ではなく見積り工数
- 30人月の開発を5人でこなすから6か月かかるというのもまだ見積り
- 計画への移行:
- 開始日と終了日も加え5月1日に開始して6か月後の10月31日に終了すると言えば計画っぽくなってくる
- ガントチャートを描くことでクリティカルパスを明らかにし5月1日に開始して7か月後の11月30日に終了すると伝えたなら益々計画っぽさが醸し出される
- 見積りの本質:
- これらいずれも見積もり依頼者の期待するアウトプットにはなり得ない
- 要求を実現するために必要な労力や規模や期間を見積っただけに過ぎない
- 見積り依頼者の期待とのズレ:
- 9月にリリースしたいのに10月や11月にリリースできると言われても困る
- 1000万円の予算におさめたいのに2000万円のコストを要すると言われても同様に困る
- 見積もり依頼者は9月にリリースするための計画や1000万円の予算に収まる計画を期待している
- 対立の発生:
- こういったズレが生じるとエンジニアはビジネスを理解しないとかビジネス担当者は現実を分かっていないといった対立が起こり始める
- 両者ともに見積りと計画を混同しているとこのような悲劇に見舞われる
- 副作用:
- 人と月を交換する文化を生む
- ガントチャートを描いてもプロジェクトは大抵その通りに進まない
■ 3. 計画と見積りの性質
- 計画の性質:
- 計画はターゲットを見据えてつくるもの
- ターゲットとは12月のクリスマス商戦に向けてこの新機能をリリースするとか法改正対応バージョンを施行までにリリースするや予算の範囲内で業務システムを構築するといったもの
- ソフトウェアプロジェクトを立ち上げるうえでのビジネス上の目標や制約
- ターゲットが明らかでなければ計画を作ることができない
- 計画づくりの前に開発チームと関係者の間で十分に認識を合わせておく必要がある
- 見積りの性質:
- 見積りにターゲットはない
- 見積りは要求の実現に必要な労力や規模を算定するもの
- 見積りを歪ませるバイアスは可能な限り排除しなければならない
- 見積り結果はプレーンであるべき
- 混同による弊害:
- 見積りを計画と混同すると算出された工数や理想時間やストーリーポイントはターゲットの影響を受けてしまう
- 予算や期日にあわせるように過小に見積ってしまうかもしれない
- リスクに過敏になって過剰なバッファを追加してしまうかもしれない
- 適切なプロセス:
- プレーンな見積りとターゲットを比較することではじめてその差分に基づいて適切な計画づくりが進められる
■ 4. ギャップに基づく計画づくり
- 計画づくりの本質:
- 計画づくりは見積りとターゲットのギャップを解決する活動
- 見積り結果として算出されたコストや開発期間などがターゲットの範囲内に収まらない可能性があるから
- トレードオフの発動:
- ターゲットに対してネガティブなギャップがあるならトレードオフの発動
- QCDSといったパラメータのうちターゲットの重視するものを考慮して調整し計画に落とし込む
- ターゲットの見直し:
- ギャップが大きすぎるならターゲットを見直すことも視野に関係者と話し合うことになる
- トレードオフだけでは調整しきれないから
- 開発に1年を要するものを2週間で作りあげることはできない
- バッファの組み込み:
- 計画にはバッファを組み込む
- 100パーセント正確な見積りなど作れないのだからそれに基づく計画も完全にはならない
- 計画には幅を持たせる必要がある
- バッファの種類:
- バッファには時間に対するものもあればスコープに対するものもある
- 前者をスケジュールバッファ後者をフィーチャバッファと呼ぶ
- コストに対してバッファを設けることもできるかもしれない
- どのタイプのバッファを用いるかはターゲットに応じて決定することになる
■ 5. アジャイルプロジェクトにおける計画づくり
- 計画の見直し:
- アジャイルプロジェクトではイテレーションが終了するたびに計画を見直す
- それまでの実績に基づいてプロジェクトの着地点の予測を立て直す
- 不確実性の高さ:
- プロジェクトの初期は不確実性が高くそれ故に見積りの正確性や精度も低くなるから
- プロジェクト開始前は8回のイテレーションで終了する計画であったとしても最終的には10回分を消費するかもしれない
- 実際にプロジェクトを開始してみると予想より手こずることだってある
- 不確実性コーン:
- 初期の見積りのばらつきは大きくて4倍小さくて0.25倍全体で16倍の差があると言われている
- これがプロジェクトの不確実性
- この不確実性はプロジェクトが進むにつれて収束していく
- 変化への対応:
- アジャイルなプロジェクトは変化を前提としている
- 変化を受け入れたなら見積りやターゲットが変わる
- そうすると計画が変わるのは必然
- プロジェクト初期には分からなかったことが少しずつ明らかになることで計画が変わることだってある
- 不確実性が削減され予測可能性が高まる
- アジャイルの本質:
- アジャイルはプロジェクトの計画性やコントロールを放棄しているわけではなく現状に常に適応している
- 予測の立て方:
- イテレーションごとにそれまでの実績を踏まえて予測を立てれば早い段階で正確な着地点を知ることができる
- 残ポイントを実績に基づいて算出し直したチームのベロシティで割ればあと何回のイテレーションが必要であるかが分かる
- これをバーンダウンチャートなどで可視化しておく
■ 6. アウトカムやインパクトをターゲットにする
- アウトプットターゲットの限界:
- ここまでで述べたターゲットはあくまでもプロジェクトによるアウトプットに対するもの
- アウトカムやインパクトをターゲットにすることもできる
- 特に自社プロダクトの内製プロジェクトではこの観点が求められる
- アウトプットの性質:
- 新しいプロダクトや機能をリリースすることはあくまでもアウトプット
- それが期待した通りのユーザー価値やビジネス価値を生み出すとは限らない
- むしろ期待を下回ることの方が多い
- 時には今ある価値を毀損してしまうことだってあり得る
- アウトカムとインパクトの定義:
- アウトカムやインパクトとはアウトプットによって得られるユーザー価値やビジネス価値のこと
- こちらのほうがターゲットすなわちビジネス目標として相応しい
- 第3四半期中にユーザー数を20%増やすといったもの
- 施策としてのアウトプット:
- こうしたターゲットを採用するとアウトプットはアウトカムやインパクトを得る施策としてとらえることができる
- 施策は想定通りの結果を生むこともあればそうでないこともある
- したがってその計画は目標とするアウトカムやインパクトを得るまで様々な施策を繰り返す枠組みとなる
- 両方のターゲットの使い分け:
- アウトカムやインパクトをターゲットとする計画とアウトプットをターゲットとする計画は排他的なものではない
- 前者はプロダクトやサービスのロードマップレベルの計画として描く
- 後者はその施策となる開発計画として用いるのが良い