エンジニアに見積もりを依頼した時。”バッファ”を適切に見込んでいる開発組織では、しばしば「予定より早く終わりそうです」という報告を開発チームから受けます。
★第2回を投稿いたしました！
「”バッファ”とはなにか？」この質問は、ほとんどの開発組織でマネージャーや発注者から発せられています。
開発者は「”バッファ”とは”バッファ”です」と答えています（笑）
次に。「”バッファ”が必要な理由を説明しろ」とマネージャーや発注者は詰めます。
こうして”バッファ”は減らされていきます。
そして、見積を見直して大きく減らすことが出来たマネージャーや発注者は満足して引き上げます。
そして、3ヶ月後。マネージャーや発注者は「何故、プロジェクトが遅れているのか？」という議題に悩むことになります。
それは、貴方自身が削った”バッファ”が原因です。
「バッファがない見積」とは「全コースをミスもトラブルもなく。ベストラップで走り抜けられたら、このタイムでゴールします。」という、言わば理論上の世界レコードのようなものです。
バッファをゼロにしたプロジェクト計画とは貴方のプロジェクトメンバーが全員「ミハエル・シューマッハ」であることが前提なのです（苦笑）
勿論これは、わかりやすく極論化したものです。
ですが「ノーブレーキでアクセル踏みっぱなしなら1時間で着きます」という計画が無謀だということは誰にでもわかります。
”バッファ”をなくしたプロジェクト計画とは「理論上の最善値」で計画が組まれていることになります。
もし、貴社のITプロジェクトがいつも遅れ。いつも品質が課題になっているなら。
エンジニアや開発チームが盛り込んだ”バッファ”を信用してみるのはいかがですか？
きっと「予定より早く終わりそうです」という。いままでマネージャーや発注者が聞いたこともない。素晴らしいコメントを手に入れることができます。
計画より早く終わることは間違いですか？
いつも残業や休出で”巻き返し”を図るプロジェクトマネジメントは正しいと思っていますか？
ITプロジェクトが遅れるのは常識ですか？その結果、品質が課題になるのは開発チームの生産性問題ですか？
もし、貴方がマネージャーや発注者、組織管理者で「マネジメント」をする立場だとしたら。
思い出してみてください最期に「予定より早く終わりそうです」を聞いたのはいつだったか。
「システム開発のための見積りのすべてがわかる本」でも記述していますが。
”積み上げ方”で見積もる時、タスクごとにバッファを積むと、工数が1.5倍など”膨らむ”傾向があるのは事実です。
ですが、”バッファ”自体はテスト期間のように必要なコストです。
では”バッファ”とは結局なんでしょう？
・・・次回にさせていただきます＾＾
第2回を投稿いたしました！