情報システムの仕様書で必要な考え方

読者の皆さんの文書作成環境は、Wordの方が多いのではないだろうか。その場合、WYSIWYG（What You See is What You Get）環境が当たり前であり、XMLはなんとも歯がゆいものである。XMLで書く文書は見た目とは異なり、文書の構造を書いたものである。構造、表示、内容が分かれており、面倒なだけに違いない。確かにWYSIWYGでことが済めばそれにこしたことはない。しかし、そういう環境において文書の整合性を維持するのは結構大変である。

では、UNIX系OSのテキストを基本とした環境に慣れている人にとってはどうだろうか。WYSIWYGは便利だと思うが、それほど魅力的でもない。短くコンパクトで完結したものを連結して使うのがUNIXの文化であり、文書もそのようなものであるべきと考える。つまり、文書もプログラムのようにモジュール化されているべきである。小さなモジュールの完結性が全体の整合性を担保してくれるからだ。この方が思考経済（思惟経済）としてずっと合理的に思える。思考経済とは「できるだけ少ない情報量で事実を表現することで、思考のコストを節約すること」である。

情報システムの仕様書はUNIX的文化に馴染むと筆者は思う。仕様書は各サブシステムごとにモジュールとして完結であるべきである。他と関係がある場合でも、整合的でなければならない。仕様書はそれを担保するための約束ごとであるため、「忍耐」ではなく、プログラムのような明確な制約を作って整合性を担保するべきである。

仕様書作成の前に、文書構造を把握する

仕様書を作成するにあたって、筆者を含めた技術系の人間の陥る罠が「ウォーターフォール」である。ウォーターフォールでは、文書の規約を定め、それに従って内容を書き、そして表示方法を整備する。このように上流から下流に作業が一方向に流れると嬉しく、わかりやすい。

しかし、それは無理である。システム要件を記述するのが目的であって、仕様書はその手段に過ぎないからだ。つまりシステム要件を記述するために、文書の規約は変更されるべきである。また、共同作業者の意見を聞いて文書規約も変更しなければならない。柔軟に対応する必要があるのだ。

まず、文書の全体構成を把握しよう。書きやすい部分を例として文書構造の大枠がわかるように、馴染みの道具で作成する。これはWordでも、LaTeXやHTMLのような形式でも良い。前回述べたように、階層構造がどうなっているかを把握することがこの作業の主眼である。

各階層には、どのような内容が必要だろうか。前回述べたように、仕様書は基本的に箇条書きである。最下層の項目以外の階層では、表題が1つとその下層の項目が複数個で構成されている。

サーバ類の記述でいくと、サブシステムが「Section」に、各サーバが「SubSection」に、そのソフトウェアやハードウェアが「TopItem」に、そしてソフトウェアやハードウェアの詳細が「li」に対応する。このような構造を意識して文書をXMLのようなタグを使って作っていく。次に文書構造を定義していこう。 次のページ