シス開発：設計の質を高める仕様書の書き方 |
システムを設計した場合、設計した内容を仕様書として残す。その書き方は、とくに決まっていないため、設計者が自由に書いている。かなり自信を持って書いている人もいれば、自信がなくて迷いながら書いている人もいる。また、初めて書く場合は、どんな風に書いて良いのか分からず、先輩に尋ねたり、先輩の書いたものを真似したりする。
システム設計の仕様書には、これが絶対に正しいという形式など存在しない。そのことが、多くの人に迷いや混乱を生じさせている。絶対に正しい形式があれば、安心できる人が多いだろうが。
仕様書であれ何であれ、使わないものなら作る必要はない。後で何かの目的に用いるから、わざわざ作っているのである。良い仕様書に仕上げるためには、その目的に適した形で作らなければならない。
では、仕様書を使う目的とは何であろうか。一般的には、設計内容のレビュー、製作したシステムのテスト、運用を開始したシステムの保守が挙げられる。設計内容が確定する前にレビューすることにより、設計ミスを早期に発見できる。製作したシステムが正しく動くかはテストで確かめるが、明確な仕様が分からなければ、どれが正しい動作なのか判断できない。システムが稼働し、後から変更の要求が出たり、トラブルが発生して復旧するときなど、システムの内部が不明なら非常に困る。以上のようなことを効率良く行うために、システムの仕様書を作るわけだ。けっして仕方なく書くものではない。
どのように利用するかが分かれば、それに適した形で作ればよい。レビューする場合にはどんな点を見るのか、テストする場合には何が分かればよいのか、システムを保守する場合にはどんな情報があれば助かるのか、といった点を考慮して、仕様書の形式を設計する。
具体的には「どんな内容が書いてあれば、３つの利用目的で問題なく役立つか」を検討する。すべての情報を１つの書類にまとめると大変なので、複数の書類に分けた形で作成する。どのように分けるかも、検討すべき内容に含まれる。全部を一気に書くことは無理なので、設計の進み具合に合わせて、順番に書けるように分割するのが賢い方法だ。
「どんな内容が書いてあれば」を求めるためには、それぞれの利用方法で何をするのか明らかにしなければならない。これは、システム開発の基本作業を考え直すことに等しい。その作業を何のために行い、どんな風になれば成功したと言えるのかを検討し、必要な項目を洗い出す。それをもとにして、仕様書の形式を設計すればよい。
設計内容と言うと、設計した最終結果だけを考えがちだ。しかし、レビューと保守では、設計の途中で使った情報も必要となる。その機能をなぜ付けたのか、機能をそのような仕様に決めたのはなぜか、その実現方法をどうして選んだのか、といった理由などだ。こうした情報があれば、適切にレビューできるし、システムを改良する際に大事な点を考慮し忘れる失敗が減る。
もう１つ考慮すべきなのは、作成の手間である。詳しく書くほど量が増えて、作業が大変になる。“利用目的の質が低下しない範囲”で、最小限の内容に絞る。また、余計な時間を使わずに書く方法を習得することも大切だ。
システムの仕様書の形式は、こうした考え方で設計する。実際には、似たようなシステムなら同じ形式が流用できるので、システムごとに設計する必要はない。しかし、こうした検討をしたことがないなら、一度深く考えてみよう。きっと、仕様書の改良点が思い浮かぶはずだ。
以上のような考え方は、仕様書に限らず、ドキュメント全般に通じる話である。そのため、仕様書以外の開発用ドキュメントも、同じような考え方で設計すればよい。
仕様書を作る対象も、検討すべき点の１つに挙げられる。一般的には、システムに関する仕様書なので、システム開発が始まってからを対象と考えがちだ。しかし、開発するか決める前段階で、いろいろな検討が行われる。システムが必要とされる理由や、どんなシステムなら役立つかなどだ。
こうした開発開始前の作業は、問題解決の段階と捉えることができる。何か困っている問題を解決するために、コンピュータを利用したシステムが役立たないかと検討している工程だ。そのため、問題点や原因を明らかにして、その解消に必要な機能や状態を導き出す。こうして明らかになった機能が、システムを構築することで実現できるか検討し、システムの機能として規定される。
現実には、全部の機能を実現できるわけではなく、機能の一部で妥協しなければならないことが多い。また、システム化によって、別な問題点や欠点が生じる。システムが停止したときの影響が膨大だとか、手作業よりも融通が利かないとかだ。こうした点も含めて検討し、本当にメリットがあると確認できた場合に開発を決定する。当然ながら、本当に実現可能かの確認も事前に調べる。
以上のような検討内容も、仕様書と同じレベルで記録しておくと、システムの開発で有効に利用できる。システムの細かな機能を決める際、本来の目的である問題解決の検討内容に照らし合わせ、整合性が取れているか調べたり、どれが一番適しているか選んだりできる。システムの細かな機能が、本来の目的から外れにくくなるわけだ。
開発開始前の検討内容も、システム仕様書と同じように、利用目的に適した形で設計する。システム設計で参照するため、通常の書類と比べて正確で細かい記述が求められることは、言うまでもない。
（2001年７月24日）
仕様書は形式を設計して作るもの |
