1980年代後半のことだ。もう半世紀近くも前になる。
当時私は、システム経験も浅いまま、次期業務システムの開発を外注先との共同で進めることになった。ところが、外注SEやPGによる開発を間近で見るにつけ、じわじわと不安が積み上がっていった。修正箇所の波及がまったく読めない複雑なシステム構造。発注側と受注側でまったく異なるロジックで組まれた属人的なプログラム。このまま進めば、本番稼働の初日からレガシーシステム状態になる——そんな予感しかなかった。しかし、ではどうするかについては、まったく無策だった。
一冊の雑誌記事との出会い
そんな時期に、日経コンピュータ誌の小さなコラムに目が止まった。「データ中心のシステム設計技法」という記事だ。
そこにはこんなことが書かれていた（当時の記事も手元にないので、半世紀近くも前の記憶を頼りに書いている）。
概念的な記事で、実際の開発にどう活かすか、実装をどうするかについてはまったく触れていなかった。しかしこの記事を読んだとき、前述の問題意識と頭の中でリンクして、ほぼ瞬間的に「これはいけるかもしれない！」という思いが走った。
私が関心をもったのは、DOA（データ中心アプローチ）のデータ構造論そのものというよりも、そこから導き出された一つの問いだった。
答えは比較的すぐに形になった。複雑な業務をシステムに投入するエントリープログラム、データを単純なルールでファイルに反映させる更新プログラム、そしてその2つをつなぐ正規化・振分けプログラム——この3段階のシステム構造だ。各層が「やるべきこと・やってはいけないこと」を持ち、その結果プログラム構造そのものも標準化されていく。
蒲田のシスラボへ
頭の中で構造は見えた。しかし、それが当時の汎用機（富士通Mシリーズ）とOS（OSIV/ESPIII〜XSPの頃）の上で本当に動くのか。私はあえてそれらの制約を一旦脇に置き、まず理想的なシステム構造を考えることにした。
検証のために、蒲田にあった富士通のシステムラボラトリ（通称シスラボ）を訪問し、外注会社のSE諸氏にも意見を求めた。そこで現実の壁にぶつかった。トランザクション管理やプログラム間連絡機能の弱さ、メモリ空間の制限、レスポンス問題——障壁は一つではなかった。
それでも、システム思想を損なわない範囲で構造を工夫し、独自のトランザクション管理の仕組みを組み込みながら、なんとか実装のめどが立った。
半分進んだプロジェクトをひっくり返す
決断は大きかった。半分ほど進捗していた開発プロジェクトを途中で大幅に変更し、新しいシステム構造でゼロから組み直すことにしたのだ。
ファイル設計は原則やり直さず、構造変更に必要な最小限の修正にとどめた。ただしファイル項目定義は詳細に書き直した。本来の意味でのDOAではなく、その亜流だったのかもしれない。
綱渡りではあったが、開発プロジェクトは納期通りに稼働を迎えることができた。むしろあのまま続けていたら、納期遅延とシステム品質の低下は免れなかったと思う。
壁にぶつかりながら——実装上の妥協と発見
実装は理想通りにはいかなかった。いくつかの壁が待っていた。
トランザクションの分離——理想的には3段階すべてを1トランザクションで処理したかったが、当時のOSの機能ではそれができなかった。仕方なくイベントPGと正規化・振分PG以降でトランザクションを分離し、後半2段は COBOLの外部サブルーチンとしてコンパイル時に結合することでトランザクションを保証した。
冗長性との戦い——標準化のため、更新しない項目も連絡レコードとして持たせる構造にしたため、メモリを圧迫した。たとえば受注入力で「受注日」だけ変更したい場合でも、このシステムでは受注の削除データ・修正後の登録データ・関連する各ファイルへのマイナス更新とプラス更新、明細行があれば明細行の数だけトランザクションデータが飛び交う。「受注日だけの例外的な書き替えを許すか否か」——私は許さない選択をした。構造の純粋性を守るために。
移動平均単価問題——これには苦慮した。仕入伝票の単価や数量が変わったとき、移動平均単価の再計算には在庫マスターの現在値が必要だが、イベントファイルにはその項目がない。3層のどこかに例外として手を入れることは、プログラマが構造規約を破る免罪符になると恐れ、できなかった。結果として姑息な解決策——「移動平均単価は日次バッチで設定する」という方法に逃げた。
今考えれば、正規化・振分けPGに「値の補完を目的としたファイル参照」を許すことは、構造の敗北ではなく、構造に汎用性をもたせる正しい実装だったと思う。あの時そう判断できていれば、移動平均単価のみならず、多くの場面で活用できたはずだ。
ドキュメントが変わった——字消し板の時代の終わり
このシステム構造が生んだ副産物として、設計ドキュメントの管理が劇的に変わった。
横軸にファイル名・縦軸にイベントプログラム名を並べ、交点に参照なら○、更新なら◎を記入したマトリクス図。イベントごとに更新するファイルの項目と更新方法を定めた更新定義——この2種類のドキュメントがあれば、個々のプログラム仕様書がなくてもコーディングができた。
当時の富士通F9450パーソナルコンピュータに搭載されていたEPOCというソフトウェア群の中に、EPOACEという簡易プログラム言語があった。これを使ってファイル・項目・更新定義を登録すると、マトリクス図と更新定義書が自動出力される仕組みを作った。
それまで、多くのドキュメントは手書きで管理されていた。システム変更のたびに字消し板とテンプレートを駆使して図面を修正し、それでも追いつかずにドキュメントとシステムが乖離して致命傷になる——そんな時代だった。構造を標準化したことで、ドキュメントをパーソナルコンピュータで管理することがはじめて現実的になった。
あれから30年以上——この構造はどこへ向かったか
当時のシステム構造や設計ドキュメント、プログラム標準書はすべて散逸してしまった。今回、半世紀近くも前の記憶を頼りにエッセンスだけでもまとめておこうと思ったのは、この構造が決して「過去のもの」ではないと気づいたからだ。
現代のイベント駆動アーキテクチャ、マイクロサービス、イベントソーシング——これらの設計思想は、1980年代に私が手探りでたどり着いた3段階の構造と、本質的に同じ問いに答えようとしている。「複雑な業務」と「シンプルなコンピュータ」をどう繋ぐか。この問いは、技術が変わっても変わらない。
その問いに対して、言語やフレームワークに依存しない形で現代的に整理したものが、別記事「業務システムをシンプルに保つ3層構造設計」だ。当時の経験がベースにある。