バッファってなんだ？
第2回は「システム開発の計画にバッファが必要な理由」を説明させていただきます。
※本記事の第一回はこちらになります。本記事の前にご一読いただければ幸いです。
「バッファとはなんだ？」
「バッファとはバッファです」
という質問のやり取りが繰り返され続けている（笑）
システム開発現場の受注者・発注者の双方に参考になればと思います。 ※第一回をお読みください
システム開発はタスク予定表どおりには進行しません。
これは、見積もりの手法や、要件定義の精度、開発プロセスの習熟度、あるいは受注側の誠意の問題・・・ではないのです。開発チームに「頑張れ！」といっても解決しませんし。
ビジネスチームに「要件もっと細かく性格に纏めなさい」といっても解決しません。
そんなことは、どの会社も開発組織もプロジェクトも、とっくにしてきた事だからです。
事実としてシステム開発プロジェクトは作業計画通りには進行しません。
既にソフトウェアという産業が一般化して半世紀ほどにもなりますが。
その間に膨大なプロジェクトが実行され、結果として既に「一定程度の遅延や品質課題は発生する」ことが事実として明らかになっています。
たとえば、2020年の日本システムユーザー会JUSASの統計（ソフトウェアメトリックス）によれば約30%のプロジェクトは品質課題もしくは納期遅延の問題を多かれ少なかれ起こします。
https://juas.or.jp/cms/media/2020/05/20swm_pr.pdf
例えば、工期が20%以上、遅延する割合は13.3%となっています。
出典：上述 2020年度 JUSAS：ソフトウェアメトリックス調査 より
また、背景はともかく統計の対象となった700のプロジェクトの約18%で品質に問題がある（品質換算率1以下）のプロジェクトとなりました。
出典：上述 2020年度 JUSAS：ソフトウェアメトリックス調査 より
プロジェクトの13%は大幅な計画予算の超過をしています。
出典：上述 2020年度 JUSAS：ソフトウェアメトリックス調査 より
そして忘れてはならないのは「多くの会社で既にバッファを積んでプロジェクト計画をしている」という事実です。
なので、バッファを積んでなお、これだけリスクが顕在化していることになります。
遅延の原因は実に様々です。だからバッファが必要な理由も様々となるのです。
技術的な問題かもしれません。
開発会社の作業者のスキルレベルが足りないかもしれません。
要件が決まらないかもしれません。
インフラ基盤に思わぬ落とし穴がリリース日に見つかるかもしれません。
突然、社長交代してリリース直前でプロジェクトが見直しになるかもしれません。
そうした上記表のような品質や工期やコストなどの形でリスクが顕在化する
最大要因は「仕様変更」 です。
仕様変更は実に80%近いプロジェクトで発生します。
つまり「ほぼ確実に発生するプロジェクトリスク」なのです。
ですからバッファが必要な理由は「必ず仕様変更は起こるから」 と言って良いことになります。
・・・次回は、仕様変更とバッファの関係、そしてバッファの参考値について投稿してみたいと思います。
沢山「いいね」をいただければ早筆になるかもしれません（笑）