仕様書と設計書

「客観的な目標を立てるのが大事だ」と言いました。その目標となるのが「仕 様書」です。仕様書とは、何を作らなければならないのかを記述した書類です。

仕様書を書くのを面倒に思う人がいるかもしれません。しかしその理由のほと んどは体裁を気にするから起きることです。仕様書は内部文書であり、体裁を 気にする必要はありません。わかればいいのです。

仕様書は、書いた結果よりも書くという行為そのものに意味があります。つま り、いきなりコードを書き始めるのではなく、まず何を作らなければいけない のかを考えることです。

仕様が変更されるわけ

「ソフトウェア開発では仕様はすぐ変わるから、仕様書は書くだけムダだ」と 言う人もいます。これは実態をよく表していますが、真実ではありません。な ぜ仕様がすぐ変わるかというと、仕様の書き方が悪いからです。確かにすぐ変 わるような仕様書は書くだけムダです。結論は「仕様書を書かない」ではなく 「変更の必要がないようなしっかりした仕様書を書く」でなくてはなりません。

ソフトウェア開発で本当に仕様変更は避けられないことなのか、よく考えてみ て下さい。なぜ仕様変更があるのでしょう？仕様が決まってから次に仕様変更 があるまで、我々はいったい何をしているのでしょう？多くの場合、仕様が決 まってプログラムにとりかかって、おおかた出来たところで仕様の重大な欠点 に気がつきます。もし仕様が決まった時にすぐプログラムにとりかからず仕様 をよく検討したならば、こうした欠点はプログラムを作る前に見つかるはずで す。

プログラムを作っている時に仕様のミスや書き足りない点に気がつくことはよ くあります。これはGUIプログラムで特によく起きます。フォームにボタンや フィールドを配置して画面を作った時点でなんとなく仕様ができたような気に なってしまう人が多いからです。画面デザインだけでは情報が足りなさすぎま す。ほとんどの場合、仕様はあまり深くまで掘り下げられず、「このボタンを 押すと○○を行う」で済まされてしまいます。

本当は「○○」をどうやって行うのかを詳しく書くことが必要なのです。 仕様は絵と文書で記述されるため、どんなあいまいな記述でもできてしまいま す。仕様を詳しく書かないからそこにある大きな論理的矛盾や間違いを発見で きず、プログラムという厳密な記述をして初めて仕様の間違いが発見されるの ようになるのです。

仕様を単に書くのではなく、細かく検討してください。直観に頼るのではなく 論理的な裏付けが必要です。「こんな画面を表示させよう」という時に、「な ぜその画面でなくてはならないのか」という理由付けをします。いろいろと考 えられる他の形式の画面ではなく、なぜその画面なのかという理由です。そし て、単に画面の絵を書いて「○○をする」で終わるのではなく、あいまいさが なくなるまで詳細に書かねばなりません。

アプリケーションロジック

仕様を考える際の根本となるのが「何をしたいか」です。例えば「在庫を管理 したい」「業務の損益を計算したい」「エレベータを制御したい」というよう にです。そして、これを具体的に詳細化したものが「アプリケーションロジッ ク」「ビジネスロジック」「ビジネスモデル」といった言葉で呼ばれるもので す。

アプリケーションロジックはよく軽視されます。仕様書を見ると、「はじめに」 の章にある「在庫を管理したい」という一言の次に、在庫管理画面や入力画面 が並んでしまっています。いきなり画面を考える前にしなければならないこと があります。それは「在庫を管理するとはどういうことか」という疑問に答え ることです。

アプリケーションロジックが固まっているなら、仕様の変更は起きるはずがあ りません。「こういうことがしたい。だからこういう画面を作ってこう処理す るんだ」という順番で仕様を作る限り、仕様変更の起きる余地はありません。 つまり、確固たる土台から始め、そこから正しい論理展開で仕様を作っていく ということです。

すると問題は、「こういうことがしたい」の部分が変わるのかどうかになりま す。もし「在庫管理がしたい」が急に「会計処理がしたい」に変わるのなら、 これは単なるクライアントのわがままです。制作中に法律が改正されて消費税 が外税から内税になることもあるかもしれません。しかし逆に、このような例 外を除けば、仕様が途中で変更になることはないはずです。

まず「何がしたいのか」をはっきりさせてください。それがアプリケーション ロジックです。これはUMLではクラス図で表現されます。その後で、「それを 実現するためにはどうすればよいか」を考えます。

仕様書を書くための人員

多くのプロジェクトでは、仕様書は一人で書きます。これがそもそもの間違い です。このようにすると、仕様書は一人で書けるほどの簡単なものしか出てき ません。それより何より、仕様は成果物に意味があるのではなく、書くことそ のもの、つまり仕様について考えることに意味があるのです。仕様書は、誰か が書いてそれを下々の者に渡すのでは意味がありません。開発に携わる本人が 書かなくてはいけません。

一人で作った仕様には様々な思い間違いや過度の省略が含まれています。例え 最初は一人で作ったとしても、それを多人数で一度レビューすべきです。そし て、仕様書の書き足らないところや変なところを直していきます。

仕様書のレビューがないと、書き足らないところは発見できることもあります が、仕様の間違いは発見することができません。なぜなら仕様は「プログラム をこう作れ」というゴールを決めるものであり、絶対的なものだからです。下々 の者にとっては「正しい」とは「仕様通りである」と同義です。そこでいくら 「仕様が間違っていると思ったら言ってください」と言っても、それが実際に 挙がってくるはずがありません。「仕様が間違っている」というのは彼らにし てみれば言葉の矛盾だからです。

仕様書は、プログラミングというステージに移行する前に、徹底的に見当すべ きです。

まとめ

仕様が「変更された」と捉えるのは間違いです。変更されたのではなく、今ま で仕様だと思っていたものが間違いだったのです。仕様変更が頻繁にあるとい うことは、今まで仕様だと思っていたものが実は間違いだらけだったというこ とです。

「これでいいかどうかはプログラムを作って動かしてみないとわからない」と 言う人もあるかもしれません。確かに、デザインやユーザインターフェースの 部分で一部そういった事があるのは認めます。しかし大部分はプログラムを動 かしてみなくても少し考えてみればわかります。今までわからなかったのは、 考えてみるということをしなかったからです。

ほとんどの人は、「今考えなくてもそのうちわかるさ」と考えることを放棄し てしまいます。そして後になってわかって大騒動になった時に「ソフトウェア 開発とはこういうものだ」と自分で自分をごまかしてしまいます。ソフトウェ ア開発とはそういうものではありません。「考えるよりまず行動」というのは 良いスローガンにも見えますが、それは愚か者のすることです。