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

[渡辺 幸三，＠IT]

「実行可能な仕様書」を書こう

　いったい何が問題だったのだろう。エクセル方眼紙にまつわる個別の不平に感情を奪われていては本質を見誤る。問題はまず「仕様書を作成するための専用ツール」が存在しないという点にあるのではないか。そして、仕様書が苦労して作成されるものである割りに、「そのまま実行可能」なものではなく、「それに基づいていちいちプログラミングすることが前提になっている」点にもあろう。

　ここまで問題の様相が見えれば、状況を改善するための道筋は明らかになる。まず、仕様書を自由形式で書くことをやめて、XMLやJSONといったデータ記述言語を用いたデータ様式を定める。次に、その様式で書かれた仕様書を解釈してプログラムを立ち上げるための「仕様翻訳エンジン」を開発する。同時に、仕様書情報を規定様式で整形してくれるだけでなく、定義要素間のクロスレファレンスまでを示してくれる「仕様書専用エディタ」を開発する。これらのデータ様式やソフトウェアが「実行可能な仕様書」を支えてくれるはずだ。

　従来の開発スタイルでは全てのプログラムをいちいち手作りしていたが、これはもうやめたほうがいい。大方の機能については「実行可能な仕様書」などのノンプログラミング方式で対処し、残りの特殊な機能についてのみ「ドメイン駆動設計」なりの高等プログラミングで対処するといった、“メリハリのついた開発方針”を採りたい。

意外と身近な「実行可能な仕様書」

　「実行可能な仕様書」は夢物語でも何でもなく、すでにさまざまな場所で活用されている。例えば電子部品製造の世界では、部品要素を回路図のように並べて全体の振る舞いをシミュレートしながら開発を進める「モデルベースデザイン」のスタイルが確立している。自動車業界や医療機器業界など幅広い分野で実践され、効果を上げている。

　工場の生産現場でも活用されている。製造用ロボットは製造管理者が作成するシーケンスデータに基づいて動いている。専用のエディタを開けば、シーケンスデータは「ロボットの動きの仕様書」として見える。ただし、その仕様書に基づいて制御用プログラムを個別開発する必要はない。ロボットにインストールされている翻訳エンジンが仕様書を解釈して、動きを動的に制御するからだ。

　また、楽譜の形で演奏データを入力して音楽を演奏させることも昔からなされている。この場合の楽譜は「そのまま演奏可能な音楽の仕様書」に他ならない。例えば「イパネマの娘」をPCに演奏させたいのであれば、その演奏用シーケンスデータ（イパネマの娘.mid）を、楽譜やピアノロールを模した専用エディタを介して登録するだけでいい。あとは専用の翻訳エンジンが「仕様書」を解釈して勝手に演奏してくれる。イパネマの娘演奏プログラム（イパネマの娘.exe）を個別開発する必要はない。

　業務システム開発の世界でも「実行可能な仕様書」はもっと活用されるべきではないたろうか。なぜなら現状のままでは、この上なく労働集約的なやり方ゆえに、不必要なコストを経済社会に押し付ける結果を招いているからだ。また、非効率でストレスフルなやり方は、技術者を過労やうつ病に追い込む原因にもなっているからだ。そして当然ながら、業務システムをクラウド提供しても、怒涛のようにもたらされるカスタマイズ要望に応えることはほとんど不可能だからだ。

プログラムを類型化する

　では、業務システム開発の世界で「実行可能な仕様書」を実現するには、何をどう考えたら良いのだろう。その鍵は「プログラムの類型化」にある。

　1基の業務システムには、ときに数百本以上の機能（データ処理プログラム）が含まれるが、筆者の経験から言うと、それらの6割以上はいくつかの「典型的なパターン」に分類可能である。また筆者の観察では、典型的なパターンのバリエーションは10種類程度に整理できる。一見すると個々にユニークな機能が集まっているように見えるが、遠めで見れば、多くは似たり寄ったりのものでしかない。

　それらの典型的なパターン（機能パターン）に従って仕様情報を様式化することで、「実行可能な仕様書」は実現できる。特定のパターンに沿ってその過程を説明しよう。

　ここでは「特定テーブル中の全レコードを一覧表示する（便宜上「一覧表示処理」と呼んでおこう）」というパターンを取り上げる。このパターンに分類される機能は、起動すると、例えば、以下の図2のようなパネルを出力するとしよう。実用的とは言えないほどに単純なものだが、話を分かりやすくするために、ここではこのパターンを使って話を進めたい。

図2　このようなパネルを出力する「特定テーブル中の全レコードを一覧表示する」機能を実行する仕様書とは……？

仕様書を様式化する

　まず、この機能の「仕様書」を考える。この機能が「一覧表示処理」のパターンを持つものであることは分かっているので、このパターンに沿いながらも、この機能に固有の部分だけを「仕様書」に書き込めば済む。そう考えると、仕様書に盛り込まれるべき項目は以下だけで良いことがわかる。

• 機能パターン（一覧表示処理）
• 機能のIDと名前（パネルタイトル）
• 一次テーブル（処理の起点となるテーブル）
• 一覧表示されるべきフィールドと欄見出し

　これらを含む仕様書情報をXMLで様式化すれば、例えば図3のようになる。1行目の属性「Type="LISTING"」は、この機能が「一覧表示処理」のパターンに含まれることを示している。

図3　XMLで様式化した仕様情報