「良いプロへジェクトは早く終わりましたを聞く」の適切なバッファについて。第三回。最終回です。
第一回ではバッファののないプロジェクトが、どんなに無謀で無計画かを説明しました。
第2回ではバッファの必要な原因はなにか？を探るため統計的を用いてバッファが何のためにあるのかを考えて。仕様変更は76.9%とほぼ8割のプロジェクトで起こることを検討しました。
第3回はこれらを踏まえて「適切なバッファ」の考慮をします。
なお以下の資料は引き続き「一般社団法人日本情報システム・ユーザー協会 ソフトウェアメトリックス調査2020」を使用しています。
仕様変更はスケジュールだけでなく全体の質を下げる
下記の図を見てみましょう。仕様変更の重要度で工期遅延する割合がよくわかります。
「仕様変更がない」プロジェクトが75%成功するのに対して、「重大な変更」が合った場合には、工期は3割も守られません「ほぼ失敗する」と確定していいくらいになります。
納期という観点の失敗だけではなく、品質や機能性、顧客や開発に携わった人々の満足度全てが低下しています。
適切なバッファとは？
幸い我々には実際にそうしたプロジェクトの結果を分析し、予め80%の確率で起こる仕様変更に備えることが出来ます。
JUASの資料で検証対象となるような”ある程度の規模”のプロジェクトの半数（52.6%）が総予算の10%を設定していることと
実際に仕様変更が発生した76%のプロジェクトの超過コストが9.3%であることから
総予算の10%がバッファの目安といっていいことになります
これは費用だけの話ではなく。スケジュール等他のリソース全てに当てはまります。
人員や、サーバーリソースなど、あらゆるリソースに10%プロジェクトが膨らんでもいい余裕
を持たせておく必要があります。
「早く終わりました」を聞くためには
「仕様変更は必ずと言っていいほど起こり。そして必ずと言っていいほど計画に影響する」事実を踏まえ。
見積もりやプロジェクト計画、リソース計画にバッファが必要であることを、開発チームだけではなく、ステークホルダー全体。発注者や会社組織全体で理解しましょう。
其の上で、これまでの多くのプロジェクト実績から少なくとも「総リソースの10%」をバッファとして用意しましょう。
勿論、この想定はプロジェクトの難易度や。チームの練度。発注側の要件定義体制の密度など、様々な要素に左右されます。
ですが「少なくとも10%」を確保しておくことで、飛躍的に成功確率は上がるといえます。
ぜひ、「早く終わりました」という報告をプロジェクトミーィングで聞き。
余裕を持ってビジネス運用を構築したり。
早くテストリリースして非機能要件のテストに当てたり。
より良いプロジェクトを運営できるように取り組みましょう。
最後にCMです。見積もりはプロジェクトの「初期計画」です。ぜひ本書を読んで取り組んでください＾＾
システム開発のための見積りのすべてがわかる本