マネジメントの急所 – 見積


「優れた見積は優れた設計により生み出される」
正論です。今ここで正論は必ずしも正しくないことを証明して見せましょう。

「見積は設計の前に行われる。」
証明終了

前回のスケジュール以上に難しい見積もり。
スケジュールの難しさについては、
マネジメントの急所 – スケジューリング

今回は見積の難しさについて簡単にご説明します。

見積の難しさについて

ソフトウェア開発において一口に見積と言っても、
以下の二種類に分けて考える必要があります。

①金額を決めるための見積
②作業時間を決めるための見積

この二つの違いについて簡単にご説明します。

①金額を決めるための見積

もっとも有名なものです。

お金を払う人:やりたいことを実現するのに、いくらまで払うのか
労力を提供する人:このやりたくないことを実現するには、いくらもらえばやっても良いのか
『いくらまで払う』と『やっても良い』を金額で折り合わせる行為が見積です。

但し、提供される『労力』が誰でもできるような簡単なものであれば安くなり、
提供される『労力』がその人にしかできない難しければ高くなります。
また、将来性のある金銭的、技術的に魅力的なものあれば
多少無理してでもその仕事を取りたいと思うでしょう。

これは設計の前でも構わない『価値』に対する見積です。

②作業時間を決めるための見積

プロジェクトマネージャーやプログラマーには、こちらの方が重要です。
その作業は、どれくらいの時間をかけないと実現できないのか
その作業は、どれくらいの時間ならかけても良いのか

その時間が大きければ、
学生症候群で「コスト」は増加、
少なければ「品質」は低下します。
最悪「納期」を守れません。

これは設計が必要な『作業量』に対する見積もりです。

ソフトウェア開発の見積

実を言うと、ソフトウェアの見積は慣習として
「金額を決めるための見積」と「作業時間を決めるための見積」
が一緒の場合が多いのです。

理由は作業時間を見積の根拠としているからです。
以前、述べました人月という考え方になります。

1人月とは1人で1か月の作業量というものです。
例えば15人月、1人でやったら15ヵ月だけど15人でやったら1ヵ月だね。
となります。

ちなみに値段の付け方は以下の通りです。
15ヵ月分の作業量ですよ。
ウチは1ヵ月分の作業量100万円なので1500万円くださいね。
となります。

つまり、作業量がそのまま金額に変換されます。

結果、
「優れた見積は優れた設計により生み出される」
「見積は設計の前に行われる。」
の矛盾の穴にどっぷり嵌ってしまいます。

また、作業量と金額の概念が入り交じり論点がブレます。

課長「この仕事見積もって欲しいんだが」
僕「見積に3日ください。」
課長「何で見積にそんなに時間がかかるんだ。」
僕「作業内容を洗い出してから見積もるからに決まっているでしょう。」
課長「お金ももらってないのに見積に時間をかけるな。どうせ目安なんだから半日でやれ。」
(何だかんだで1日で見積)
僕「○案件の見積出しました。5人月です。」
課長「この機能に500万円の価値はないよな。どう考えても250万だよな。」
僕「(価値なんか知らんがな)僕は作業工数を出しただけなので、値引きなり金額面はご自由に。」
(数日後、300万円で受注)
僕「スケジュール出しました。2人でXX月までです。」
課長「300万円の仕事に5人月もかけるな。3人月でやれ。」

・・・ん?

総括

「価値」と「労力」を中心に見積の話を進めてきましたが
そもそも人月という見積法は昔から疑問視されています。

私たちが使っている見積もり手法は、コスト計算を中心に作られたものであり、労力と進捗を混同している。
人月は、人を惑わす危険な神話である。
なぜなら、人月は、人と月が置き換え可能であることを暗示しているからである。

遅れているソフトウェア・プロジェクトに人員を投入しても、そのプロジェクトをさらに遅らせるだけである。
(「人月の神話」フレデリック・P・ブルックスJr.)引用

人月が悪習によるものだとしても
今もソフトウェア開発の見積の標準として多く利用されています。
我々サラリーマンはそれに従わざるを得ません。
あ、失礼。僕はニートです。

つまらない疑問を持たず、
サラリーマンの皆さんは改善されない日々を堪能してください。

おわり


コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です