ソフトウェア開発における問題の大部分は技術的なことよりも社会学的ないしは心理学的な問題で占められています。すなわちソフトウェア開発における諸問題の解決にあたってはテクノロジ的なアプローチ以前に人間力の改善が必要です。
本連載は、はヒューマンウェア（人間行動）についての経験則をまとめたもので、読者における新たな視点や気づきのきっかけになればと思います。より一層の客観性を持たせる意味で、筆者における経験則に加えて世の中の賢人たちの言葉も収録しました。
開発の流れに沿って、「見積もり」に始まり「総合テスト」までを順次連載していく予定です。各項目はごく短い文章ですが、これらの言葉によって皆さんの重荷がいくばくかでも軽減されることを願っています。
はじめに― 見積もりとは？
「見積もり」は開発行為の中で最も重要なものです。見積もりの失敗はプロジェクトの失敗に直結します。見積もりは契約行為であり、開発者や組織の実力が映し出される鏡であり、不条理な要求に無定見に従うのではなく、利をあせることなく、どこに妥当な落としどころがあるのかを探る、実に人間臭い行為だと考えたほうがいいでしょう。
#1：見積もり回答は契約なのだ
「見積もり回答は契約だ」という意識は、開発者にはおそらくない。
単にこの仕事はどれくらいかかりそうだという見込みの回答程度の気持ちなのかもしれない。一旦見積回答書を発行し、発注書ないしは開発指示書を受領したら、その時点で契約が成立する。契約は法的な拘束力をもち、発注者および受注者はお互いの義務を履行しなければならない。見積回答書は開発に関係するドキュメントの中で最も重要な書類と言える。
契約についての意識は欧米においては神にその履行を誓うものであり、日本においては我と我が身に誓うものであるという違いはあるが、いずれにしても見積回答書は開発組織の実力を映し出す鏡となっている。
見積回答書の基本要件は、わかっている内容のみを見積もり、わかっていない内容は見積もりに含まれていないことを明記しておくことだ。
契約交渉は、双方が自分自身を見つめる絶好の機会である。
G.M.ワインバーグ、『コンサルタントの道具箱』
#2：目には目を、歯には歯を
「目には目を、歯には歯を」は、物ごとに対する対応の原則のひとつである。短時間の雑な見積もり要求に対しては、山ほどの条件付きの“超々”概算見積もりしか出すことはできない。当たり前のことだ。要求内容もあいまいで、短時間で詳細な見積もり回答を出せという要求に困ることはない。時間内にできるものしかできないのが天の道理である。
「無理が通れば道理が引っ込む」は許さない。
中坊公平、元日弁連会長
言われてみれば「そんなことはあたりまえさ」といいたくなるが、その「あたりまえ」に案外気づいておらず、そのためにとんでもない誤解をうけたり、廻り道をしたり、無駄なエネルギーを費やしたり、時には生涯を誤ったり破滅したりする。こういう例は、一民族にとっても、一個人にとってもけっして少なくないであろう。
山本七平、『あたりまえの研究』
#3：結果をあせるな、利をあせるな
土台を先に作らなければ家は建たない。基礎の杭打ちをいい加減にした結果、マンションが傾いてしまったというニュースが世間を騒がせている。ものごとを成し遂げる場合には必ず守るべき手順がある。特にその基本となる部分に手抜きや検討不足があると、物事は無事には終わらない。あせりは我々の正常な判断を狂わせる。
- ナスよ早くなれ
- 植えたナスの苗に向かって、早くなれなれといくら叫んでもなるわけはない。雑草を取り除き、肥料を与え、こまめに水をやり、病虫害を除いた後でやっと実りが収穫できる。この道理に従って努力を続ければ仕事も商売もうまくいく。
二宮尊徳、『二宮翁夜話』
#4：今日やるべきこと、明日やればよいこと
今日やるべきことは今日中に済ませること。“明日やる”は、ほとんどやられない可能性が高い。
- 明日やればいいことを今日やるな
- 明日にはやる必要がなくなっているかもしれないことを今日やるな。
G.M.ワインバーグ、『コンサルタントの道具箱』
#5：当たり前は難しい
当たり前なことは簡単なことと同じではない。簡単なことが複数集まれば難しいことになる。そのことを理解していなければ簡単なことで簡単に失敗をすることになる。
- 当たり前のこと
- 群を抜く方法は、当たり前の仕事を、当たり前ではない情熱で行うことである。
レターマン、 米国の作家
#6：とりあえず高いという人種
モノを購入する消費者の賢い交渉方法は、開口一番“高い！”と大声で言うことだ。さらに賢い販売者は、そのような消費者心理を織り込み済みで3割増しの価格設定をしている。思い切って2割まけましょうということで、消費者はまんまと1割も高いものを買うことになってしまう。
賢い開発マネージャは見積もり担当者に対して最初から決して高いとは言わない。これ安すぎないのか？ 何か抜けや見落としがないの？ 金額の高低よりも内容の妥当性を検証する。高い安いは、その後の話だ。とりあえず最初に高いとしか言わない人種は開発者ではなく商売人なのだろう。
- 見積り金額が安い理由
- 前回の見積もり金額に比べて今回再提示された金額はだいぶ下がったようだけど。下がった根拠を説明していただきたい。ただ安ければ良いというわけにはいかないでしょう。
某顧客責任者
#7：許容範囲～どこまでも許されるわけもない
量、質、時間、いずれにも許容範囲というものがある。的の中心に当たらなくても的のどこかに当たれば合格とされる。そこで注意しなければならないことは、自分勝手に的の大きさを変えないことだ。勝手に広げた的に当たったと言っても誰も認めてはくれない。
プロジェクトに許される許容範囲の中で、さらに自分に許される許容範囲について知っておく必要がある。許容範囲とは妥当性についての考え方の一つである。
- 時間を無駄にする方法
- 妥当であれば、大幅な時間の節約になる。完璧主義のせいでパニックに襲われたことが何度かある。完璧な質を求めるのではなく、許容できる質を考えるようにするのが主な治療法である。
G.M.ワインバーグ、『コンサルタントの道具箱』
おわりに～見積回答書の重要性
受注者の最大の目的は、その仕事によって利益を上げることです。見積回答書は、達成すべき仕事内容、その対価および実行期間を約束してしまうため、見積もりミスや仕事の失敗は直ちに赤字を招き、企業の存続を危うくする場合もあります。
さらに見積回答書は開発チームの仕事の原点であり、その後の開発における人・モノ・カネ・時間を規定するものであり、すべての書類やドキュメントの中でも最重要な書類です。見積回答書は、その会社や組織のすべての実力を映し出す鏡といっても過言ではありません。見積回答書の基本要件は次の2点だけです。
- わかっている内容のみ見積もる
- わかっていない内容は見積もりに含んでいないことを明記する
