教えてくれそうで教えてくれないソフトウェア産業の常識。
今回は開発プロジェクトでもっとも大切な「計画と見積」です。

①見積（計画）ってそもそも何なんだ？

何のために見積（計画）するのか

会社が利益を出すために見積（計画）をします。
見積（計画）をすることによって、そのプロジェクトがいくらぐらい儲かるかがわかるので、
そのプロジェクトを会社としてやるべきかどうかの判断材料のひとつになります。

計画しないと見積できない

プロジェクト計画の成果物が見積であって、見積という単体の作業は存在しません。
計画書と見積書はセットになっていなければなりません。
「見積もってください」と言われたら、それは「計画を立ててください」という意味です。

②見積（計画）って何を書けばいい？

見積（計画）に含めることを簡潔に書くと以下の通りです。

何をもとに何を開発するのか
どのように開発するのか
どういうスキルを持った人が必要で、誰に何を担当してほしいか
理想通りだとどのぐらいかかりそうで、理想通りでないときどのぐらいかかりそうか
このプロジェクトの勘所、ボトルネックになりそうな要素は何か
意図しないリスクのためにどのぐらいバッファを積むか

何をもとに何を開発するのか

インプットとアウトプットの関係を意識して、プロジェクトの中で生まれるものをすべて書き出します。
成果物ベースで書けば、ドキュメントもカバーすることができます。

インプットとなる情報とアウトプット
ベースとなる既存資産とアウトプット
プロジェクトの中で作られるものとアウトプット

どのように開発するのか

プロジェクトの進め方を記載にし、開発に必要ものは何なのかを洗い出しておきます。
使用する機材や環境、ツール類、サービス類もここで記載しておきます。

開発手法
環境、言語
指示体系とチーム構成、大まかな役割
場所、コミュニケーション手段

どういうスキルを持った人が必要で、誰に何を担当してほしいか

会社は人で成り立っています。どのようなメンバー構成にするかは、プロジェクトの成否をストレートに左右します。
プロジェクトの難易度に応じて適切な人をアサインするようにしましょう。

ただし会社ではほかのプロジェクトと人の取り合いとなるので、実績のある人や、評判の良い人であれば、
その時期に稼働できるかどうか、ほかのプロジェクトと調整する必要があります。
社内での調達が難しい場合、外注することも検討しなくてはなりません。

理想通りだとどのぐらいかかりそうで、理想通りでないときどのぐらいかかりそうか

見積で一番大切なポイントとなる
見積に幅を持たせるのが大切
機能と作業を洗い出して、積み上げで見積する
- ただしタスクは細分化しすぎると大変になるのでほどよくやる

このプロジェクトの勘所、ボトルネックになりそうな要素は何か

以下のような要素を確認して、プロジェクトの難易度を明確にするようにします。

社内にノウハウがない初めての技術分野
純粋に複雑で難しいと思われる作業
同時並行できず、他の作業の前提となる作業
他社に依存してしまうもの

難易度が高い作業があればあるほど、特定の人への依存度が高まり、
理想的な体制でプロジェクトを進行できないとき失敗のリスクが高まります。

意図しないリスクのためにどのぐらいバッファを積むか

プロジェクトは思いもしなかったことが起きるものです。
どんなプロジェクトでもバッファを安全係数としてかならずかけるようにしてください。
バッファは必要なものであって、無駄ではありません。
プロジェクトの難易度が高いほど、規模が大きいほど係数は高くしてください。
繰り返しになりますが、見積もりが足りないと会社は赤字で倒産します。

③見積ってどうしたらよくなる？

見積（計画）には十分すぎる余裕が必要

当たり前すぎることですが、実績が見積（計画）をむやみに超過してはならないというのが大前提にあります。
実績が見積（計画）を超過するということは、会社が得られると予定していたお金が減る、利益が減るということだと覚えてください。
利益が減る、つまりあなたの給料も減る可能性がある、最悪の場合、倒産したり解雇される可能性もあるということです。

一方、見積（計画）の中で収まるなら、見積（計画）よりも早く終わってしまってもいいわけです。
その場合は会社が得られるお金は予定よりも増える、利益が増えるということになります。
どう考えても余裕のある見積（計画）にしたほうがいいですよね。

純粋な見積（計画）として適正なものを把握しよう

実際の現場で見積金額を提示するときには相手の予算感と合わせることも必要なのは真実です。
しかしながら純粋な見積（計画）として適正なものを把握できていなければ、その先の駆け引きも生まれません。
まず自分の考えをしっかりと持ったうえで、相手の考えに寄り添うことが大切です。

ソフトウェア開発の見積（計画）を正確にできる人はこの世に存在しない

見積（計画）は予想と同じなので正確にあてることは誰にもできません。
見積（計画）とは正確性を追求するもののではなく、不確実性を明らかにするものです。
言い換えれば、見積（計画）とは現時点での可能性の幅を明確にすることであり、プロジェクト管理の肝をなしています。

見積（計画）精度は経験に依存する

経験が多い人ほど、これから起こりそうな課題を想像することができます。精度の高い予想ができます。
経験がないときに予想が外れやすいのは当然ですから、自分の見積（計画）精度が低いことを悩む必要はありません。
「誰」が「いつの時点」で「どういう情報」に基づいて作成した計画なのか、
その計画を実行するといくらかかるのか、それは「ひとつの見積」にすぎません。

見積（計画）精度を上げるには

いくつものプロジェクトを経験していけば自然に見積（計画）精度は上がっていきます。
また、ベテランとあなたが同じプロジェクトを対象に別々に見積（計画）をして、
そのふたつを比較するのもいい勉強になると思います。
経験や情報量は、場数と時間によって解決するしかない部分が多いので近道はありません。

一方、きちんと見積（計画）してプロジェクトを進めるということはベテランでもできていない人がいるので、
当たり前の見積（計画）を当たり前にやるというだけでもあなたの評価を上げます。

見積（計画）は何度も繰り返さなくてはならない

見積（計画）は情報量が多くなるほど、つまりプロジェクトが進行するほどに正確になっていきます。
古い見積（計画）のままプロジェクトを放置せず、こまめに見積（計画）を繰り返して軌道修正をしてください。
一方で、プロジェクト中盤以降では見積（計画）を大きく見直す必要がなくなるので、残タスクの整理と解消に集中するべきです。

見積（計画）をやり直した結果、利益が減ることがわかったら

プロジェクトが進行していったときに見積をやり直してみたら、どうやら費用が足りなそうだ、ということはよくあります。
素直にプロジェクトの利益が減るということを稟議で承認してもらいましょう。
ここをごまかすと、少ない費用で無理にプロジェクトを続けることになり破綻します。

提示したい見積額が決まっているプロジェクトの見積（計画）をする場合

営業上の理由などであらかじめ見積提示額が決まっているプロジェクトというものがあります。
このようなプロジェクトの見積（計画）をする場合は以下のようにします。

提示額のことは関係なく、普通に見積（計画）をする
1. をもとに提示額に収まるように機能を削るが、このとき3パターン作るようにする
- 松）フルスペックの見積（1. そのままであり提示額に収まることは通常ない）
- 竹）採用させたい見積（提示額とほぼ同額になるまで現実的に機能を減らしたもの）
- 梅）捨て見積（提示額よりもだいぶ安いが、まず選ばれないであろう貧弱な仕様）