IT会社でSEを続けて来た中、昔先輩から、最も高度な設計技能は「見積」だと教えられました。
経験した事の無い新しい技術に挑戦したり、一度も実現された事がないシステムの開発の計画と準備。それまでに培ったスキルと経験をフル活用して、成功への道筋をデザインし、途中で起こり得る様々な困難（リスク）を想像し対策を練る行為だから、だと言うのです。
過去に見積もりのポイントを整理した資料があったので、若干ハードル高いかも？とは思いましたが、出来るだけ平易に表現したつもりではあります。まあ、大半の方には全く興味の無いつまらない話だと思いますが、ご容赦頂きたく存じます。
ＩＴ開発における「見積もり」とは
IT開発における「見積もり」とは、実際に開発に着手する前に見通しを示す行為の事です。単に金額や納期を概算で示すだけではなく、どんな開発方法でどの程度の性能・品質のシステムを作ろうとしているのか？の中身についても顧客にできる限り分かり易く伝えて、納品後のトラブルを防止する事が求められます。
「良い見積もり」とは
「値段が予算内に収まっている」事は契約成立に向けた重要な要素である事に違いはありませんが、それだけで「良い見積もり」とは言い切れない場合があります。当初の予算が過少に確保されていて、結果として、「安物買いの銭失い」になったのでは、顧客はハッピーになれないためです。
従って、契約した結果、どんな成果物が手に入るのか？の期待とのギャップが少ない事が「良い見積もり」の条件となります。具体的な話を聞いた結果、機能的な不足が事前に把握できれば、追加予算を確保してでも満足の行く成果物をはじめから要求した方が、後から増築・改築するよりもトータルコストが安く済むのが一般的だからです。
「金額」や「納期」も当然大切なのですが、見積もりで良くトラブルが起きるのは、そもそもの見積もり範囲（開発する範囲と言っても良いと思います）の認識が合っていないケースです。範囲の認識が合っていないのに金額が安い・高いを議論しても殆ど意味がありません。「コミコミ」などと言って具体的な議論をはぐらかす業者は、そもそも信用してはイケマセン。
「良い見積もり」を作るためのポイント
どんなモノづくりでも同じ事が言えますが、そのモノを実際に使う顧客の事を詳しく知る事が良いモノづくりには欠かせません。同じ事が見積もりにも言える訳で、何故そのモノが今回必要になったのか？の目的や背景を詳しく確認する事で、納品後の期待ギャップの発生を極力抑える事ができるのだと思います。5W2H（いつ、誰が、どこで、何の目的で、何を、どうする、幾らで）の観点で漏れなく確認するのが、基本中の基本となります。
最後のスライドページだけは、ITベンダっぽくなってしまって恐縮ですが、大まかに言うと、こんな観点で開発プロジェクトの計画を考えたりします。
冒頭に「それまでに培ったスキルと経験をフル稼働」と記載しましたが、ここが非常に重要で、過去に作った見積もりと、実際に開発を終えた後での「成功・失敗体験」の突合せチェックが、次回以降の「見積もり」や「開発」時のノウハウに役立ちます。
従って、忘れてしまいたい「苦い経験」も含めて、記録に残し、他者と共有し、再利用する事が更なる成長の重要ポイントとなります。
