見積もりを無視する「わがまま」は禁じ手と知るべし
今回は、第8章：予告宣言する をご紹介します。
連載記事一覧は、コチラの最下段から
見積もり作業は、筆舌に尽くしがたいくらい難しい
18章でもご紹介した通り、本章「予告宣言する」の扉絵は、ベーブ・ルースの「予告ホームラン」の写真ではあるものの、その中身は「ホームランを打つと予告しよう」ではなく「失点しないという予告」です。
「必要な作業量（＝労力）をどのように見積もるべきか」を失敗例から考えていくというお話です。この「大変さ加減」については、原書にあたっていただくべきだと面ますので、ここでは簡単にサマリー形式でご紹介するに留めます。
- 他者とのコミュニケーションが発生しないとしても、プログラムの規模に応じて、必要工数は累乗で増加する
- 従って、プログラム開発とプログラミングシステム製品開発は、”別物”と考えないといけない（詳細は第1章を参照）
- 投下工数の半分くらいは、プログラミングやデバッグ”以外”の作業に費やされる（書類作成や打ち合わせなど）
- 相互作用（≒コミュニケーションの必要性）があると、プログラマの生産性は簡単に1/7くらいまで落ちてしまう
ブルックス氏のアドバイスは「粗い拡大推計はやめとけ」
第2章でご紹介した「コーディングは全体の1/6」というお話を覚えているでしょうか。計画が1/3、コーディングが1/6、単体テストおよび初期システムテストが1/4、すべてのコンポーネントを統合して行うシステムテストが1/4というアレです。
これを思い出すと、「え、それ、見積もりに使えるんじゃないの？」と思いますよね？僕も思います。が、しかし・・・
計画段階、コーディング、単体テスト、およびシステムテストに適用できそうな比率については既に述べた。コーディングの部分だけから見積もり、それからそれぞれ比率を適用し、全体の作業を見積もるということは決してしないと誓う必要がある。コーディングはせいぜい6分の1に過ぎないから、そういう見積もりh\屋比率での誤りは、ばかげた結果につながりかねない。
え、だめなの？と思うかもしれませんが、まぁ、ダメって言うから駄目なんです。（なんとなく、納得いかないんですけどね。）
ま、この比率は、最初の「粗々の見積もりください。今日中に。」とかって営業が無茶を言ってきたときには、とりあえず6倍しとく（といいつつ、怖いからバッファ積んで8倍にしとく）みたいな感じで使うんですかね。
システム開発は「ステップ・バイ・ステップ」だ
この章から直接的に学ぶべきことは「見積もりって難しいね」ということなのですが、もう一歩踏み込んで（あるいは引いて）考えてみると、違った示唆が見えてきます。
それは「システム開発は、積み上げる作業だ」ということです。
そんなこと当たり前じゃねぇかと言われると、まぁ、そりゃぁそうなんですが、これをちゃんと理解しているのは「システム開発の現場経験がある人」だけです。多くの人、特にビジネスサイドの人は「システムが積み上げられて作られていく」という本質的な部分を理解していません。
この「世の中に理解されていないということを、理解する」ということは非常に重要です。それを踏まえて、開発サイドは”理解されていない”という前提で説明せねばなりませんし、できることならば、ビジネスサイドは”理解できていない”という意識を常に持って打ち合わせに臨むべきです。
企画業務とシステム開発は全然違う
例えば、戦略コンサルティングは、少数精鋭チームが考え抜いて”資料”を作り上げるために「作業の密度の濃さ」により、短時間でアウトプットにたどり着くことができます。（もちろん、それはそれで死ぬほど大変なんですけどね。）これは、必ずしも、戦略コンサルティングが机上の空論だから、ということではなく、純粋に仕事しての性質の違いに由来しています。これは、経営企画などでも同じことです。「どういう企画にしたいかを考えて、その企画がなぜ他の企画よりも優れているのかを資料にまとめる」ということであれば、作業密度で時間を短縮することが可能です。時間をかけたからと言って、より素晴らしいアイデアが出てくるわけでもなければ、成功確率が上がるわけでもありません。(インプットとなるデータの精度はあがると思いますが、それが”意思決定”に及ぼす影響は通常は非常に軽微で、誤差の範囲だと言えます。）
一方、大規模システム開発では、そうはいきません。コミュニケーションの内容もルートも複雑になり、さらに、文書化の必要性が高まるとともに、その文書のメンテナンス業務にも膨大な工数がかかります。そして、ボタンを一つ掛け違うと、数週間、数ヶ月、ひどいときには数年間の”積み上げ”が一瞬で無に帰す恐れがあります。
このあたりを、経営者も、戦略コンサルティングの従事者も、しっかりと認識しないといけません。「安い」という理由でベンダー（特に上流工程のベンダー）を選ぶのは自殺行為です。もちろん「高けりゃいい」ということにもなりませんが、「何を決めるフェーズなのか」「どうやって何を管理していくのか」が明確になっているベンダーを選ばないと、”システム開発”に関しては致命的な結果を招きかねない、ということは、もっともっと啓蒙されてしかるべきだと僕は思っています。（※ちなみに、情報系システムと基幹系システムでは、大きく事情が異なります。このあたりは関連記事をご参照いただければと思います。）
システム開発の現場が、今回ご紹介したような大変な苦労をしながら、必死で見積もりをしていることを理解しましょう。そして、いきなり「この機能を追加してよ」だとか、「えー、もっと納期短くならないの？」だとかいうことを”その日の気分”で言わないようにビジネスサイドの人は気を付けていきたいものですねという自省とも警句ともつかない発言をしたところで、本日の「予告宣言する」の解説はおしまいです。次回は、「第9章：5ポンド袋に詰め込んだ10ポンド」ですよ。
連載記事一覧は、コチラの最下段から
