いらない機能を作るとき |
||
|
無駄はいけない |
||
|
なるべく効率良く作りたい。そう思いますよね。 |
|
たぶんそう思っているのは我々だけではなく、我々のボスはさらに強くそう願っているでしょう。もし必要なものだけ過不足なく作ることができたら一番効率が良いはずです。ですからボスはこう呪文を唱えます。
この呪文を唱え続けているうちに、それが果たすべき目的のような気になってきます。しかし実際は、もちろん目的ではありません。 |
||
一見無駄、でも必要 |
||
|
実装すべき機能の候補 A, B, C, D があったとしましょう。そしてお客さんと十分な話し合いを行った結果、本当に必要な機能は A と C だけだったとします。設計担当者がもっとも効率の良い方法を検討したところ、これらの機能を実現するためには同時に B も作ってしまった方が手っ取り早いということになったらどうでしょうか。こういう場合は当然 B も一緒に作るわけです。もちろん D を作るようなことは無駄なのでしません。 |
||
|
こういうことは、良くあるのです。いくつかの機能を同時に満たす機能を考えれば作る量が減る場合が多いので、この場合は A と C を同時に満たすような機能 X を設計します。で、それがたまたま機能 B も満足してしまうというわけです。もう A, B, C をいっぺんに作ってしまわない手はないということになります。それだけではなくて、もしかしたら全然新しい機能 Z も自動的にできてしまうかもしれません。それもまた OK です。 |
||
|
もちろん、お客さんには「案外簡単にできることがわかったんで、B もサービスしときますよ」とか「Z もできそうなんですけど、ついでに作りましょうか?」なんて言う必要はありません。あまり安売りし過ぎると、本当に安い仕事だと思われてしまいます。お客さんが欲しいと言い出した時に、「それじゃ、作りましょうか」などと返事でもして、ころあいを見計らって「完成した」ことにできればラッキーです。一番楽な方法を選んだ上に、労せずして利益を得るチャンスまでできるというわけです。 |
||
|
そんなに上手くいくものか、とお思いでしょうか?ええ、上手くいきます、本当に。この作戦は、以前に設計の仕方のひとつとして説明した「先を読む」ということと少し似ています。先を読んで必要になりそうな選択肢をあらかじめ作っておくというやつです。今回説明したのは現在もっとも楽な方法をとった上に後でまた楽ができるかもしれないというやりかたです。どちらも長い目で見た時に楽であるような方法を選ぼうとしているという点で、同じ発想です。 |
||
|
「不要なものも作ってしまおう。ただし、その方が楽ができるという場合に限り」 |
||
|
|
|
|
|||||
(「コーディングの向こう側」は2000年4月から2001年5月にかけて作成されたコンテンツです。)