ソフトウェア開発の見積り精度を上げるには
〜中島聡氏へのQAと考察〜

今回はソフトウェア開発における見積り精度について、Windows 95のチーフアーキテクトなどを務められた中島聡さんのメールマガジンでお伺いしたQAと、それを踏まえたプロジェクトマネジメント実務における考察をご紹介します。

※プロジェクト管理の基本となるWBSについては、こちらの記事「WBSの勘所」も合わせてご覧ください。


1. 中島聡氏のご紹介

中島聡さんは言わずと知れたWindows 95の父です。以下は、Wikipediaからの引用です。

中島 聡(なかじま さとし、1960年 - )は、日本のコンピュータ技術者、ITエンジニア、起業家、ライター。Xevo(旧UIEvolution)の創設者。アメリカ合衆国シアトル在住。学位は、工学修士(早稲田大学・1985年)、経営学修士(ワシントン大学・2009年)。
マイクロソフトでWindows 95、Windows 98、Internet Explorer 3.0/4.0のチーフアーキテクトなどを務めた。マウスの右クリック、ドラッグアンドドロップという概念を広めた人物である。

また、本QAの舞台となった中島さんのメールマガジンについてもご紹介します。今回ご紹介する内容は、すべてメールマガジンに掲載された本文そのままを引用しています。

週刊 Life is beautiful(まぐまぐ!)

中島聡氏のメールマガジン 週刊 Life is beautiful
図1: 中島聡氏のメールマガジン「週刊 Life is beautiful」

2. ソフトウェア開発の見積り精度を上げるには(QA)

それでは、実際の質問と回答をご紹介します。

質問

日本のソフトウェア開発にて主にプロジェクトマネージャーを担当している者です。

受託開発の見積り精度を上げたいのですが、どうしても上手く行きません。WBSを洗い出し、様々な見積り手法を試すのですが、往々にして見積り工数をオーバーします。

もちろん、見積り結果に対してバッファを設ければ工数オーバーを防ぐことが可能なのですが、個人的な考えとして、根拠のないバッファを設けることがどうしても後ろめたい、というか納得できません。というのも、それはソフトウェア本来の価値(適正価格)ではないと考えるからです。

お客様が納得すればそれで良し、と割り切ればそれまでですが、ぜひ一度、日本、海外のソフトウェア開発に精通された中島さんのご意見を伺えればと思います。

回答

ソフトウェア開発の見積もりは本当に難しいですよね。難しそうなものがアッサリと動いてしまうこともあれば、たった一つの問題が解決しないために、予定よりも何倍の時間がかかってしまうことがあります。特に大勢の開発者が関わっている場合、エンジニアごとの開発効率が大きく異なるため、工数を単純に頭数で割って納期を割り出すことは、ほぼ不可能です。

結局のところは十分なバッファを設けて、見積もりを出すしかないと私は思います。約束した納期に遅れたり、納期に間に合わせるためにクオリティを落としたり、という仕事を続けていれば、顧客は離れて行きます。

私自身が仕事をする場合には、正式な納期を決める前に「準備期間」をもらい、その準備期間に少数精鋭で、顧客が欲しがっているものを、ある程度ハリボテでも良いので作ってしまい、その期間中に「大まかな設計をする」「プロジェクトの難易度を肌感覚で知る」ことをした上で、より確実性のある開発コストを算定し、さらにそれに多少のバッファを設けて納期として提出します。

ちなみに、このテクニックは、受注開発であっても、自社製品・サービス向けの開発でも使える手法なので、覚えておくと良いと思います。私が世の中に送り出したソフトウェアは、いずれもこの手法で開発しています。

以上が中島さんからのご回答です。多忙を極める中、非常に丁寧かつ本質的なアドバイスをいただくことができました。


3. いただいた回答の取り扱いについて

なお、今回のQAではいただいた回答のWeb上での取り扱いについても確認を行いました。念のために掲載許可に関するQAもご紹介します。

質問

先日、質問をさせて頂いたものです。この度は回答有難うございました。

頂いた回答は私の考える手法とも近しく、何やらそれだけで安心してしまいました。結局の所、信用を得る為には自分のやり方を地道にやるのが一番だな、そう考えさせられた次第です。

ところで、頂いた回答についてですが、宜しければ私のブログ等にて公開させて頂きたく。原文そのままの掲載について可能かどうか、お手数ですがお返事頂けないでしょうか?

回答

私のメルマガの回答やコメントなどを、note やブログで公開することは、引用元(このメルマガ)を明確にしていただける限り歓迎です。唯一迷惑なのは、このメルマガの全文を単にコピペしただけのブログのようなものですが、「こんな質問に対してこんな回答があった」、「この記事に関して、こんなコメントがあった」などの引用であれば、自由にしていただいて結構です。

当初はメルマガ掲載ではなく運営側への確認としてお送りした質問でしたが、翌週のメルマガ誌面で取り上げていただく形となりました。


4. 考察:見積りの世界に「打ち出の小槌」は存在しない

今回のQAでは、見積りの精度を上げる方法として「バッファは積むしかないのか」という問いに対し、「バッファを積むのはやむを得ない(不可欠である)」とご回答をいただきました。これには正直ホッとした部分があり、第一線で活躍されてきたトップアーキテクトの方でも同じ結論に至るのだと深く共感しました。

また、「少数精鋭でハリボテ(モックアップ・プロトタイプ)を作る」というアプローチについても強く同意します。私自身、要件定義の段階でモックアップを作成することに注力しています。初期段階で動くモックアップを作成し、顧客や開発メンバーと共通の認識を持つことで、認識の齟齬を防ぎ、プロジェクトのゴールを常に明確に保つことができるからです。

いただいた回答を咀嚼していくと、結局のところ「見積りの世界に打ち出の小槌など存在しない」という結論に行き着きます。見積りの精度を高めるためには、地道な準備と検証を積み重ね、その上でリスクや不確実性に応じた適切なバッファを設けることが不可欠です。

もちろん、プロジェクトマネジメントは見積りを作って終わりではありません。見積りを実際の形に変えていく実行力が求められます。計画が絵に描いた餅とならないよう、技術力の高いエンジニアと強固なチームを組み、ガントチャートによる平準化や進捗管理を適切に行うことが重要です。メンバーが数十人、数百人といった大規模な体制下であっても、高い精度でプロジェクトを推進していくことこそが、プロジェクトマネージャーの腕の見せ所であり、挑み続けるべきテーマだと考えています。


最後までお読みいただきありがとうございました。