オーダーメイドのソフトウェアを作るときに困るのは、ソフトウェアの特性を理解していないお客様との対話だ。あたりまえだけれどもお客様自身はソフトウェアを作ったことが無いので一般常識で「できそう」と考えられることと、実際に「できること」の差をうまく説明しないと、もめる。もちろん全ての誤解を解くのは難しいのだけれども、説明する努力は行うべきだと考えている。そこで、私はログハウスを例えにして説明している。
今回は長くなったので、6つの誤解をまとめてみましょう。
- 既にあるソフトウェアを流用した方が速く作れる
- ソフトウェアはハードと違って後から容易に直せる
- 誰が作っても中身は同じ品質になる
- 共通部品から先に作ることが出来る
- 人を増やせば一度に沢山の機能が作れる
- 正確な見積もりを出すことが出来る
ソフトウェア開発プロジェクトをとりまく６つの誤解〜プログラミングを経験しないとわからないこと | Social Change!
ログハウスの例えの概略
だいたいこんな感じ。
- オーダーメイドのソフトウェアは、例えるならログハウスを作ろうとしているようなもの
- 対象としているビジネス領域が「土地」であって、その中にログハウスというシステムを建てる。システムとビジネス領域はイコールではない
- まずログハウスを建てる土地を確認させてもらう。土地に適した家を建てるので、不可能ではないものの、建てたあとに他の土地に移設するのは難しい
- コンセプトに応じて土台をつくる。後でそれなりの増築は出来るけど制約はある
- 土台の上に、手組みでログハウスを建てていく。手順があるので人を多くしても建てる早さには限界がある
- サッシやドアノブなどのレベルは汎用的な部品を使うけれど、あとは人手で仕上げた一品モノの材料で建てる
- 手組みなので作業途中である程度は失敗するが、失敗を是正しながら建てていく。失敗することも考慮に入れて作業を行う
- お客様と打合せたのこだわりのポイント以外は、過去の事例や技術的な判断で開発側で都度決めてつくっていく。完全な設計を行おうとすると、一棟建てるくらいの時間と金が設計だけに必要になってしまう
- 完全設計が出来ないのと同じ理由で、正確な見積りもできない
- 完全設計が出来ないのと同じ理由で、共通部品を先に作って工期短縮するのもかなり難しい
- 内装や外構の変更は簡単だけど、建物部分の変更は難しい場合もある。ドアの場所を変えるとなると、相当な部分を捨ててやり直す必要がある
- 引渡しの前に、お客様と打合せたポイントがその通りになっているかはチェックするし、構造強度のチェックもする。ただ、開発側の勘違いもありえるので引渡し後はお客様自身でもチェックいただく必要がある
- 引渡しの時期は調整できる。完成した棟から住んでいただいてもいいし、全体が完成するまで待つことももちろん出来る
- やはり住んでみないとわからないこともある。問題を発見することは間違ったことではない。改修費用と効果を秤にかけて、手直しをするつもりでいてほしい
もちろんあくまで例えなのだけれども、こういった説明で少しでもお客様の「ソフトウェア開発に関する誤解」がなくなれば良いと思う。ソフトウェア構築のプロジェクトはお客様にとっては一回限りのことかもしれないけれども、誤解を解かないままに進めてトラブル化して、ソフトウェアを構築すること自体に嫌悪感を持たれたりするのは不幸なことだと考えている。
ブルックスの家
そういえば、上記のログハウスの例は私の脳内妄想なのだけれども、人月の神話で有名なブルックスは自分の自宅、別荘の設計に関して実地のケーススタディをしており興味深い(つきあった家族や関係者は本当に偉い)。当初の要求には漏れがあったり、設計の変更も発生している。
私の顧問建築家であるArthur Cogswellは、本章で述べ、彼にも伝えた詳細なデザインの根拠を理由に、あるときView/360のことをからかって「いまいましい論理的なビーチハウス」と呼んだことがある。彼が何と対比していたのか、いまだに私には謎である。
デザインのためのデザイン 第21章 ケーススタディ：ビーチハウス"View/360"
ちなみにこの本はタイトルが良くない。一般的な(視覚的な)デザインに関する本ではなく、「設計」に関する本である。というわけで興味があれば手にとって見ると良いと思う。
