実行可能な仕様書は“設計できるプログラマ”が書く：“実行可能な仕様書”を作る！（2）（1/3 ページ）

前回、「実行可能な仕様書」を実現するための鍵が「機能パターンの確立」だと述べた。それらのパターンを有効活用するためには、DBを正規化するとともに、ビジネスロジックを機能側からDB側に移行しなければいけない。そして、ビジネスロジックを的確に仕様化するためには設計スキルとともにプログラミングスキルが必要になる。

[渡辺 幸三，＠IT]

DBを正規化することのインパクト

　前回、業務システムに含まれる機能（データ処理プログラム）をいくつかの「機能パターン」に整理することで「実行可能な仕様書」が実現可能になると説明した。機能パターンごとに仕様情報のデータ様式を定め、これを処理する「仕様翻訳エンジン」と「仕様エディタ」を用意すれば、「実行可能な仕様書」のための基盤が完成する。この基盤を便宜上「アプリケーションドライバ（アプリケーションの実行エンジンくらいの意味）」と呼んでおこう。

　ただ、このアプリケーションドライバを実現するための鍵と言える「機能パターン」を有効活用するためには「データベースの正規化」が必要だ。正規化の詳細についてはここでは述べないが、要するに、正規化することで「データ項目間の関係」が形式化される。その結果、データベース構造が単純なテーブル間の「位相（トポロジ）」の組み合わせとして整理される。具体的には、キーの対応関係に基づいて、テーブル間の関係（テーブル関連）が、親子・参照・派生の3種類に類型化される（図1）。

図1　DBを正規化すれば、「データ項目間の関係」が形式化され、データベース構造が単純なテーブル間の「位相（トポロジ）」の組み合わせとして整理される（クリックで拡大）

　このように、どんなに複雑で個性的に見えるデータベース構造であっても、3つの位相の形式的な組み合わせでしかない――この事実は機能の類型化を進めるに当たって都合がいい。もしテーブル関連に10種類もの位相のバリエーションがあるとしたら、それを処理する機能のパターンも膨大なものになってしまう。いくら機能の類型化が「実行可能な仕様書」を実現するための鍵だとしても、類型そのものが多すぎては太刀打ちできない。

　もちろん正規化の効果はいろいろある。だが偶然にも、筆者が提案するアプリケーションドライバを実現するための基礎にもなっている。前回で述べたように、この点こそDOA（データ中心手法）がアプリケーションドライバのような合理化技術で先行した理由になったと言っていい。筆者にはむしろ、この種の合理化技術はDOAの論理的な帰結なのではないかと思える。

　話はそれるが、データベース構造の形式化を重要視しないやり方では、何度システムを刷新しても、それまでの無駄に個性的なデータベース構造がむざむざと継承される。一見すると、これはユーザー側の自己責任において生じている問題に見えるが、開発ベンダ側の姿勢の問題でもある。データベース構造を変えなくてもいいのであれば、データベース設計のスキルもいらないし、データ移行のコストもかからない。システム刷新において、データベース構造をあまり変化させたくないというのが多くのベンダの本音である。

　しかしそうした目先の利点を優先するあまり、業務システムには無駄な個性が際限なく付加されていく。結果的にシステムの保守コストがじわじわと増大し、遅かれ早かれ「変化・発展することが許されない業務システム」と化す。そんなものはもう捨てたい。しかしこれまで投入した莫大なコストを考えると捨てられない。そんな負のスパイラルを抜け出すための鍵でもあるのが、データベースの正規化なのである。

機能パターンの具体例

　話を戻そう。前回、実用的とは言いがたい単純な機能パターンを用いて説明を進めたが、ここでまともなパターンをいくつか紹介しよう。いずれも筆者が自作したXEAD Driverからのもので、まずは「一括表示処理」のパターンである（図2）。前回の説明で用いたものと似ているが、一覧を絞り込むための「検索条件」や、明細行を選択状態にしてエンターキーを押した際の動きなどを指定できる点などが異なっている。

図2　「一括表示処理」機能を実現するパネルの一例（クリックで拡大）

　この「一括表示処理」と連動して利用されることの多い機能タイプが「単票表示保守」だ。これは一次テーブルに含まれる特定レコードを表示／編集するためのパターンである（図3）。

図3　「単票表示保守」機能を実現するパネルの一例（クリックで拡大）

　参考までに、図2「一括表示処理」機能の仕様書がどのように編集されるかを紹介しよう（図4）。ナビゲーション用のツリービューや、余分な定義要素が見えている以外は、前回に例示した仕様書エディタと本質的には変わらない。

図4　「一括表示処理」の仕様を編集するエディタの例（クリックで拡大）

　こういったエディタを一度使うと、前回説明した「エクセル方眼紙」での仕様書作成に戻れなくなる。仕様書専用のエディタであるゆえに圧倒的に使いやすいだけでなく、仕様書を書くだけでコード生成もコンパイルもせずに、そのままプログラムを実行できてしまうからだ。

　では、こういう技術を使えば業務システムを完全にノンコーディングで作れるようになるかといえば、そうは問屋が下ろさない。「ビジネスロジック」の問題が残っているからだ。

▼関連リンク：業務システム開発用プラットフォーム「XEAD Driver」の詳細解説（筆者運営のホームページ）