今回のお題はこれ。著名プログラマのエッセイを集めた『プログラマが知るべき97のこと』。例によって積ん読本から。手元にあるのは初版第3刷（2011）。英語版のタイトルは "97 Things Every Programmer Should Know”。

作者: 和田卓人,Kevlin Henney,夏目大
出版社/メーカー: オライリージャパン
発売日: 2010/12/18
メディア: 単行本（ソフトカバー）
購入: 58人クリック: 2,107回
この商品を含むブログ (342件) を見る

全部で海外の著名プログラマのエッセイ97本と日本人プログラマのエッセイ10本、合計107本のエッセイが収録されており、大変お得です。

5年ほど前に一世を風靡した本になります。

個人的に特に勉強になったエッセイ

タイトルは「〜知るべき」なので全部読めと言わんばかりですが、自分の興味のあるテーマについてのエッセイをピックアップして読めばいいと思います。

他のエッセイで私が特にいいと思ったものは以下の通り。

14: 『コードレビュー』by マティアス・カールソン
22: 『1万時間の訓練』by ジョン・ジャガー
49: 『見積もりとは何か』by ジョヴァンニ・アスプローニ
36: 『ハードワークは報われない』by オルブ・モーダル
64: 『プロのプログラマとは？』by ロバート・C・マーティン

このエントリではNo. 49の『見積もりとは何か』をピックアップして個人的見解を書きたいと思います。

48.『見積もりとは何か』 by ジョヴァンニ・アスプローニ（Giovanni Asproni）

まずは「見積もり」ということばの定義を引用すると、

「見積もり」とは、何かの価値、数字、量、程度などについて概算、あるいは大まかな判断をすることを指します。見積もりのためには「事実の裏づけに基づく測量」が必要です。具体的には、信頼の置ける数値データや、過去の経験などに基づく予測のことです。裏づけを基に得られた判断からは、希望や願望が排除されなければなりません。また、見積もりは、あくまで概算、大まかな判断なのである程度以上の正確さは期待できません。たとえば「機能Aの開発に要する時間は234.14日」というような見積もりはあり得ないのです。

続いて「ターゲット（目標／締め切り？）」

「ターゲット」とは、実現したいビジネス上の目標を明文化したものです。たとえば「システムAha、同時に400人のユーザが利用できなければならない」というのはターゲットと言えます。

もうひとつ。「コミットメント」について。

「コミットメント」とは、「約束」と言い換えてもいいでしょう「ある機能を、ある期日までに（あるいは、あるイベントまでに）、一定以上の品質で提供する」と約束することです。たとえば「制品の次のリリースまでに、検索機能を利用可能にする」というのはコミットメントでしょう。

なかなか分かりやすい定義ですよね。

しかし実際は…このエッセイの著者がまさに例を挙げていますが、

 PM　　　 ：「機能xyzの件だけど、開発期間はどのくらいだと見積もってる？」  
 プログラマ：「一ヶ月ですね。」  
 PM　　　 ：「長すぎる。1週間でなんとかならないか。」  
 プログラマ：「どんなにがんばっても3週間は必要ですよ。」  
 PM　　　 ：「2週間、それ以上は無理だな。」  
 プログラマ：「わかりました。それで手を打ちましょう！」

こんな感じですよね。一種の恫喝です。見積もりを訊いているにもかかわらず、「いつまでに仕上げます」と宣言させる、すなわち約束（＝コミットメント）を強要しています。昨今の企業不正にも相通じるものがあるとは思いませんか。

たいていの現場では期間をディスカウントされることをおそれ、あえて長めに期間を見積もり、そしてPMはそれを念頭に期間の短縮を迫るという悪循環が蔓延しているのではないでしょうか。

ターゲット、コミットメントを現実的なものにすることが、見積もりの目的とも言えます。そして正しい見積もりが土台にあれば、適切な管理、プランニングができます。

逆に言うと、これができていないからこそ、ウォーターフォール開発におけるマネジメントの失敗が引き起こされるのではないでしょうか。担当者の「見積もり」を捻じ曲げて無茶な期限で「コミットメント」を強いる。結果モチベーションは大きく低下し、凡ミスも多発する。

スケジュールへの不満は職場の雰囲気を悪化させr、メンバー同士の相互不信やモラルハザードも引き起こしかねません。

ではどうするか。このエッセイの著者は相手が「見積もり」（＋「ターゲット」「コミットメント」）という言葉を使うとき、その意味を確認しろということを書いています。危ない客を見分けるには十分かと思いますが、何か足りない気がします。

というのは、たとえばPMBOKなどのプロジェクトマネジメントのベストプラクティスをお互いが知らないと、上記の会話のように相手をねじ伏せて「とにかくやれ」という展開になってしまうと思うからです。

私が以前会社の研修*1で学んだことは、

まずプロジェクトの不確定要素をすべて書き出す
作業項目とすべて書き出し、必要なリソースと期間を書き出す
不確定要素と変動要素はひとまず脇に置いて、既知の作業期間を積み上げ式で実行計画を立てる
プロジェクトの予算と期間（スケジュール）を勘案して、現実的に実現可能かどうか判断する。非現実的である場合は、
1. 期間の延長を検討する
2. やること（ターゲット）を減らす
3. 予算や人員などのリソース増強を検討する
妥当な結果が得られるまで1-4のプロセスを繰り返し、計画を完成させる
プロジェクトの開始後も状況変化に応じて計画を修正する

ざっくり書くと上記のように理解しました。もちろん当時の所属企業では全く実践できていませんでしたが。

現場の担当者の「見積もり」を捻じ曲げ、恫喝によるコミットメントの強制では上記のプロセスは機能しないでしょう。デスマーチまっしぐらです。

このエッセイの「見積もり」という言葉の定義、そして再確認は、私にとっての盲点でした。多くのプログラマが感じている不満、「納得いかない」の正体はこの言葉の誤用からきているのではと思います。

このエッセイだけども本書を購入して良かったと思えるレベルです。

知識のブラックホール

知識収集活動全般。

書評『プログラマが知るべき97のこと』

個人的に特に勉強になったエッセイ

48.『見積もりとは何か』 by ジョヴァンニ・アスプローニ（Giovanni Asproni）

関連URL