変化を受け入れよう

先のことなど誰も知らない

仕様を最初に決めるときから何を作るべきかが完全にわかっているということはほとんどありません。大きなシステムの場合は絶対にないと言ってもいいくらいです。第一、システム開発を依頼したお客さん自身でさえも、自分が欲しいものが何かということを把握しているわけではないのですから。

それに、作っている間にも時間は流れます。大規模な開発では何年にもわたるものだってあります。時間が経過すれば欲しいものが変わるのも当然です。ニーズはいつも変動しています。

仕様変更は「起こりうるもの」と認識すべきです。実際、いつだって起こっているのではないでしょうか。客先で打ち合わせをする営業担当の人は、お客さんがいつも違うことを言うので困った経験があるでしょう。設計者なら、営業担当者の言うことがころころ変わるので困っているでしょう。プログラマは、設計変更のたびにいらいらしていることでしょう。しかしそういう変更は起こって当然なのです。仕様変更は「悪」ではありません。

むしろ、仕様変更を受け入れなければ生き残れません。ちょっと変更を依頼されるたびに「それは予想外ですね。かなり余計にコストがかかることになりますが・・・」などと言ってはいられません。可能な限り、変更は予測しておくべきです。

予測する

お客さんが後になってどんな変更を持ちかけてくるか予測するために、設計者は自分が設計しようとしているシステムの運用形態を把握しておいた方が良いでしょう。この仕様は何をするために必要なのかとか、この機能は現場ではどのようにして使われるのかというようなことを知っていた方が、変更内容を予測しやすくなります。

あとは、想像力です。どんな変更が起こりうるのか、想像力をフル回転させて設計に取り組みます。そうして考えられる変更はあらかじめ設計中に「選択肢」として組み込んでおきます。小さな選択肢なら全部のパターンを作ってしまえば、要望に応じて切り替えるだけです。ある程度大きな選択肢なら、あらかじめ全部作っておくということはできないので、どちらに転んでもすんなりいくような仕組みというか、土台を整えておきます。

--- 設計とは、予測なり ---

仕様変更を持ちかけられたとき、事前に準備ができていれば「してやったり」な気分が味わえます。それに、「おっとっと、それは予想外でした。ちょっと余計にお金がかかりそうですが・・・。うーん、まぁ今回はサービスしましょう」なんて言ってみせることもできます。