見積もりは工数を可視化しているのに可視化されない工数が含まれている

システム開発の見積もりは難しいです。と始めると見積もり手法について書きたくなるけれど、見積もり手法については今日は棚の上に上げておきます。ええ、面倒なんです。

しかし、なぜ人は見積もりをするのかといえば、掛かるコストを予算の内輪で収めたいからです。いくらかかってもいいなら、見積もる必要なんてないのですから。

最終的にはお金を算出している

でも、システム開発では一体何を見積もっているのでしょうか。最終的には金額を弾いいているわけです。だって顧客の代替として業務委託をして作って費用を請求するからです。

金額の前には(契約によるけれど)システム開発の規模を見積もっているのですよねぇ。規模は人の共通価値に変換できるお金で共有されますけど、その変換される前は規模なのです。

規模の単位は1つではないですが、多くは工数として表現されます。人月、ですね。ステップ数でもいいですが1000万ステップと言われてもでいくらなのと聞かれるのがせいぜいです。人月の方がエンジニア1人のコスト負担するんだな、と誰もが同じように想像できるので。ただ、想像しているエンジニアの保有スキルやスキルレベルはひとりとして同じ想定ではないです。

どこからどこまで

 お金の元データが規模であるなら、見積もりしている対象はソースコード、パラメータやドキュメントということになります。じゃあ、見積もり金額はソースコードやドキュメントだけかといえば、そうでもないのはご存知のとおりです。

だって、いきなりドキュメント書けないし、プログラムも書けないです。書くために作業が必要です。

プロジェクトに必要な人的リソースであるエンジニアの調達から始まり、プロジェクトの説明、ルール説明などあれこれプロジェクトのお作法を作り、教え実行してもらう必要があります。

プロジェクトマネジメントの管理方法に沿ってプロジェクトの進度を計測することも必要です。こうしたことも含まれているわけです。工数の基礎情報となる規模には(入っているかは不明)。

可視化する見積もりが可視化できていない

多くの見積もりはそうしたことを全部ひっくるめて見積もっているはずです。はずですが、でも見積もり項目には出てこないのですよねぇ。

それ、プロジェクトをどう運営するか全く考慮されていない、つまり、脳内のお花畑的な理想のエンジニア、理想のコミュニケーション、トータルでのプラマイ0の進捗で見積もっているわけです。

まあ、見積もる人の過去の経験がバイアスとなって補正を掛けたりすることもあるでしょうが。多ければ儲かるかといえば、工数を提示されたらエンジニアは全部使い切っちゃうし。

でも、何がプロジェクトで必要な振る舞いで何が起きるかを知らないと見積もりなんてできないんですよねぇ。でも見積もっている不思議。

見積もりなんてどんな手法を持ってきても、そこに当てはめる数値は誰かが(仮だとしても)持ってきて、そしてそれで一人歩きするんですよねぇ。