クラウド時代に求められる 「実行可能な仕様書」とは？：“実行可能な仕様書”を作る！（1）（1/3 ページ）

SI各社が業務システムのクラウドサービス提供について模索している。業務システムをクラウド基盤に載せること自体は難しくないが、「システムの保守性をどう確保するか」が課題となる。従来のようなコーディング主体のやり方では、クラウドユーザーのカスタマイズ要請に応えることは困難なためだ。この問題を解決する一つの方策として、「実行可能な仕様書」の技術を紹介する。

[渡辺 幸三，＠IT]

Excel方眼紙の問題

　業務システム開発の世界には「Excel方眼紙」と多少軽蔑的に呼ばれるものがある。行間と列間を細かく設定したExcelシートのことで、さまざまなドキュメントの汎用様式とされる（図1）。特にソフトウェアの「仕様書」を書くために多用されている。

図1　日本では文書作成や仕様書を書くツールの“デファクトスタンダード”と言っても良いほどの「Excel方眼紙」

　表計算ソフトはもともと表形式の数値計算や、これに付随する文字列操作に特化したソフトウェアだ。にもかかわらず、日本においては文書作成や仕様書を書くためのツールの“デファクトスタンダード”と言っても良いほどに「Excel方眼紙」は普及している。罫線へのこだわりと同様に、これはどうも日本だけでの現象らしいことから、一部では、日本の「格子偏愛文化」が生んだものではないかとも推測されているようだ。

　Excel方眼紙上で仕様書を作成するのは面倒ではあるが、セル結合やフォント指定を駆使すれば思った通りにまとめられるし、印刷してもそれなりにキレイだったりする。プログラム本数が少な目であれば、それなりに効果的なやり方と言っていい。

　ところが、システムに含まれるプログラムが20本を超える辺りから、開発者の平安は失われる。まず、仕様書の品質にムラが出る。まともに実装できない仕様が書かれていたり、意味を正確に理解できない日本語が書かれていたり、あいまい過ぎたり、クドすぎたりする。

　仕様書の書き手としても悩ましい。はしょって書くと構想通りのプログラムができ上がらなかったりする。かといって緻密に書いていると、「これなら自分でプログラミングしたほうが早い」というばかばかしい気持ちになる。こうした矛盾は、Excel方眼紙に限らず、仕様書が自由形式で書かれている限りつきまとう。

　もっとやっかいな問題は、「仕様書とコードとの整合性を維持する」ためのコストやストレスの増大だ。定義要素間のクロスレファレンス（注1）を取れない点も頭が痛いし、コードをどの程度修正すれば仕様書上の文言を変更すべきかの判断基準もあいまいである。

注1：「個々のフィールド定義がどのプログラムで利用されているか」等の定義要素間の関連情報を「クロスレファレンス」という。クロスレファレンスを取れないのは開発・保守の過程では致命的といっていい。Excel方眼紙に限らず、その種の汎用ツールを使って仕様情報を保守する場合のあまり取り沙汰されない問題のひとつである。

コードが仕様書？

　特に、担当者が仕様書の維持とプログラミングとを兼任する保守フェイズで、これらの問題は顕在化しやすい。うんざりするほどに手間ひまがかかる割に効果が見えにくいため、遅かれ早かれ担当者は仕様書の保守をやめてしまう。プログラムとの不整合を問われた保守担当者は「コードが仕様書です」と答えるようになるだろう。

　確かに、コードを仕様書とみなす考え方はある。代表的なものが「ドメイン駆動設計」で、業務用語をふんだんに折り込みつつ構造化されたコードによってシステム仕様（ドメインモデル）が端的に示されると期待されている。効果があることに間違いはないだろうが、業務システム開発に適用するにはちょっとした覚悟がいる。開発者にはDB設計やOOP（Object Oriented Programming）や会計知識を含めた、さまざまなスキルや社会性が高いレベルで求められる。

　そんな逸材だけでシステム保守を持続できるわけではないし、「ドメインモデルとして適切なコーディング」を評価する基準も、強制する仕組みもない。保守担当者が交代していく過程で、かつては伽藍のように美しかったドメインモデルが「スパゲティ・ドメインモデル」にデグレードしないとは言い切れない。仕様書が欠落した状態でそうなってしまっては目も当てられない。