「帳簿組織の育成」としてのシステム開発

　仕様書でシステムを動的制御するためのプラットフォーム「XEAD Driver」の正式版ＯＳＳ公開を控え、最初のユーザとしての使用感を伝えたい。ひとことで言えば、これまで負荷の大きかったプログラミングに対する意識が薄らぎ、代わって業務システムが「帳簿組織」の維持管理システムであることが強く意識されるようになる。

　まず、プログラムを作ることだけを見れば、ズッコケそうになるほど簡単だ。専用の仕様書エディタ「XEAD Editor」上で、作りたいプログラムのパターン（機能タイプ）を１０種類の中から選んで、プログラムのid、名称、それに一次テーブル（プログラムで処理される基本テーブル）を指定してＯＫボタンを押す。それだけで、デフォルト設定された「実行可能な仕様書（機能定義）」が出来上がる。

　この仕様書を、動作確認しながら仕上げる。動かしながらデザインを決めてゆくという「アジャイル」なやり方を取れば、当然ながら時間がかかる。しかし事前にデザインが決まっていれば、簡単なもので数分、複雑なものでも３０分あれば完成する。ちょうどパワポで動きを確認しながらスライドを作ってゆく感じだ（コーディングやコンパイルが要らないという意味でも似ている）。

　機能タイプの中には、スクリプトを実行する「Scriptランチャー」と呼ばれるものがある。Rhino/JavaScriptで記述されるその処理内容はいわゆるＪＣＬで、これを仕上げるのに３０分以上かかることはありそうだ。それでも複雑なコードを伴うものは少ないので、全体から見れば工数の比率は小さい。

　じつはプログラムよりも「テーブル」の仕上げに時間がかかる印象がある。ただし、テーブルオブジェクトを作るためにテーブル定義を設定するところまでは早い。複雑なものでも数１０分あれば、Create Tableするところまでいける。時間がかかるのはここからだ。とくに、テーブルが複雑なスクリプト（テーブルスクリプト）を含んでいる場合、仕上げるまでにはそれなりに時間がかかる。

　テーブルスクリプトとは、テーブル操作の前後のタイミングで実行されるスクリプトのことで、いわゆる「業務ロジック」を記述するためのものだ。導出属性の計算、パネルから入力された値の妥当性検査、追加・更新・削除時の残高更新といった多彩な処理が、Rhino/JavaScriptを用いてテーブル定義の一部として組み込まれる。

　当然ながら、これらの要素を含むテーブル定義が適切に記述されたかどうかは、関連プログラムを用意して動作させてみるまで最終的にはわからない。テーブル１本あたりで直接的に関連するプログラムは平均４本程度なのだが、それらが仕上がるまでは、テーブルが仕上がったかどうかわからない。プログラムを仕上げるよりもテーブルを仕上げるほうに時間がかかるという印象は、そこからきている。言い方を換えると、開発されるべきものが「プログラム」ではなくなって、「テーブルとプログラムの複合体」とか「サブシステム」になった感じがある。

　重要な点は、これまでプログラムの仕様として設計・実装されていた多くの要素が、プログラムからテーブルに移行したことだ。プログラム側に残るのは、画面遷移と一次テーブルの操作様式をまとめた「動きのパターン」に沿った設定情報だけ。喩えるならパターンがそれぞれ「関数」で、仕様書は関数に渡される「変数」に相当する。業務システムに含まれるほとんどのプログラムは、そこまで様式化・矮小化されてしまう。

　いっぽうで、テーブル定義が保持する仕様量が増える。しかし使ってみればわかるが、システム全体の仕様の見通しがたいへんよい。従来はあちこちに散らばって記述されていたデータ処理仕様が、テーブル上に一元化されるためだ。このことは、とくに保守フェーズで威力を発揮するだろう。

　そんなテーブル定義を仕上げてゆく過程には、まさに「育成」の感覚がある。けっきょくのところ業務システム開発・保守の中心課題は、プログラミングではなく「帳簿組織の育成」なのだろう。より進化した開発環境を用いることで、そんな当たり前の事実に思い至る。