見積もりの進化と客の入らないレストラン：山浦恒央の“くみこみ”な話（42）（1/2 ページ）

これまで解説してきた見積もりの知識と技法を駆使した「デスマーチ・プロジェクト」への対処法を検討する。まずは、デスマーチ・プロジェクトで見積もりをきちんと適用できるようになるまでの進化の過程を見ていこう。

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

　「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。

　今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。

前回までの振り返り

　これまで、見積もり技法の基本として、過去の類似プロジェクトから予測する方法（類推法の一種）、LOC（Lines of Code）やFP（Function Point）を計測する方法（積み上げ法の一種）、SLIM（Software Life Cycle Management）による見積もり法（パラメトリックス法の一種）の3つを具体的に解説してきました。

　特にSLIMの解説では、簡単に「工数（コスト）」「開発期間（月）」「機能総数（規模）」「（プロセス）生産性」の4つの相互関係を分析できるよう、マイクロソフトの表計算ソフト「Excel」の計算式を使った算出方法を紹介しました。また、SLIMには「開発エンジニアを何千人・何万人投入したとしても、『この期間（最短開発期間）』よりも絶対に短く開発することはできない」という考え方がありますが、これについてもExcelを使った算出方法を紹介しました。

	関連記事：
⇒	ついに登場！ 究極の見積もり技法（その1：解説編）
⇒	ついに登場！ 究極の見積もり技法（その2：実践編）
⇒	ついに登場！ 究極の見積もり技法（その3：最短開発期間）
⇒	ついに登場！ 究極の見積もり技法（その4：最短開発期間の算出）

　さて、今回からはこれらの知識や技法を駆使した「デスマーチ・プロジェクト」への対処法を検討していきます。果たして、発注側と開発側の双方が満足できるプロジェクトは実現可能なのでしょうか。まずは、デスマーチ・プロジェクトで見積もりをきちんと適用できるようになるまでの過程（進化過程）を見ていきましょう。

見積もりプロセスの進化の過程

　“ワイン愛好家”の進化の過程は、まずドイツの白ワインのような半甘口の白を冷やして飲み、ワインの美味さに目覚め、しばらくしてシャブリのような辛口白に移行し、パラダイムシフト的にボジョレーのような渋味のない軽い赤を経て、最後はどっしり濃厚でタンニン分が強いボルドー系の赤に進むのが一般的です。

　これと同様に、見積もりにおいても、始めは「見積もり精度の向上」を目指し、続いて「見積もり値の適用法の改善」を経て、最終的に「プロジェクト成功のための見積もり」へと進化していくようです。

　以下に、それぞれの進化過程について解説します。

第1段階：見積もり精度の向上

　ソフトウェア開発は「エンジニアリング」ですので、利益を出さなければなりません。少なくとも「このプログラム開発にどのくらいのコスト（ソフトウェアの場合、コスト＝人月と考えて構いません）が掛かり、いつ納入できるか」を予測しないと、ビジネスとしてソフトウェア開発を請け負うことはできません。

　しかし、いつもきちんと規模やスケジュールを見積もっているにもかかわらず、精度が非常に低く、大赤字や納期遅延を連発してしまうケースも少なくありません。「このままでは倒産してしまうかも……」などという危機感から、「何としてでも、見積もり精度を上げなければ」と考えている会社も多いのではないでしょうか。

　このような事態に陥っている会社がまず考えるのは、「精度が低いのは、今の見積もり技法がよくないからに違いない。もっと優れた方式を使えばよいのだ」ということです。そして、熱心に他社の見積もり方式を調査したり、文献を探したりして、最終的に、自社にマッチしそうな高精度な技法を採用することでしょう。例えば、従来は、過去の類似プロジェクトの情報をベースに、新プロジェクトのコスト、人数、開発期間を見積もっていたが、精度が高いとの評判を聞いて、FPによる見積もりに切り替えるといったケースです。

　確かに、見積もり精度は向上するでしょうが、根本的な解決になっていません。実は「見積もり精度が上ったことで、赤字額がより正確に見積もれる」、あるいは「納期遅延が日単位で細かく予測できるようになった」だけに過ぎません。

　客足がジリジリと少なくなっているレストランなどでは、その改善に向けた「対策」が2つあり、ほとんどのオーナーがそのどちらかを必ず選択するそうです。

　1つ目が、「価格を下げる」です（高価なフレンチや、イタリアンレストランに多いようです）。例えば、「大好評につき、コース料理の“料金20％オフ”をさらに3カ月延長します!!」と書いてあるチラシを見掛けることがありますが、そもそも客がたくさん入っているのであれば、値引きをする必要などありません。つまり、「値引き」は、客が来ないことを堂々と宣言しているのと同じであり、「屈服」といえます。

　2つ目が、「客が来ないのは、メニューのバラエティが少ないからだ」と考え、「メニューの数を倍増させる」パターンに走ることです（大衆料理店でよく見掛けます。壁一面にメニューの短冊をぎっしり貼っている店がそれです）。根本的な問題を解決しない限り（例えば、接客態度が悪い、店内が不潔、落ち着かない、価格が周囲に比べて高いなど）、メニューが増えても客は戻ってきません。このメニューを増やすという手段は、「見積もり技法を変更する」に相当します。

　上記のレストランの例では、対策をしてはいますが、いずれも根本的な解決にはなっていません。外国人プログラマとのコミュニケーションがうまくいかない場合、それを自分の英語スキルのせいにして、一念発起して英語の勉強を始めるようなものです。英語はコミュニケーションの一手段であり、単なるツールにすぎないということに気が付かないと、多国籍プロジェクトでの意思疎通やプロジェクト管理はうまくいきません。それと同じことです。