「仕様書問題」の本質
前回記事で、ソフトウェアは「自らを合理化する本能」を持っていると説明した。ソフトウェアが適用される分野（ドメイン）がある程度狭く、かつその分野に経済的活力があれば、その分野向けのソフトウェア開発を合理化するための「ドメイン特化開発基盤（DSP：Domain Specific Platform）」が遅かれ早かれ生み出される。本連載のテーマである「業務システム」はその条件に合う分野の1つで、ローコード開発技術は「業務システム開発向けDSP」の実例である。その役割は「書いた仕様書をそのままアプリとして動作させる」というものだ。
「そのままアプリとして動作する」かどうかはさておき、仕様書は欠かせないものだ。これまで説明したように、業務システムは巨大で複雑なソフトウェアであって、高層ビルや航空機の複雑さと変わるところはない。その種の工学構築物を仕様書なしで開発すれば、開発した当事者でないと保守できない「開発者ロックイン」が起こる。これはベンダーロックインよりも悲惨で、その人物が突然いなくなれば（その可能性は低くない）ユーザー企業もベンダーも途方にくれるしかない。コードが分かりやすければ問題がないと思われがちだが、担当者が替わってもコードがいい感じに維持され続ける保証はない。
だからといって、とにかく仕様書を書けばいいという話ではない。少なくない仕様書が、テンプレートのコピー＆ペーストででっち上げられたようなシロモノで、それを誠実に読み解いても書き手の意図通りのプログラムが出来上がらない。かといって丁寧に書けば、自分でプログラミングした方が早いようなバカバカしい気持ちになる。しかも、仕様が変化することは避けられないが、それが仕様書にもれなく反映されるとは限らない。結局、最新版の仕様はコードを見なければ分からない、といったいつもの状況に陥る。これら全てをまとめて「仕様書問題」と呼ぼう。
このやっかいな問題をDSPはどのように解決したのか。業務システム開発向けDSPは一般に、「仕様書を書くためのエディター」と「仕様書を解釈して実行するためのドライバー」の2つの道具立てを含んでいる。リッチなユーザーインターフェース（UI）を持つエディターを用いて仕様書を書く様子はExcelで仕様書を書くのと変わらないが、DSL（ドメイン特化言語：Domain Specific Language）で様式化されたアプリ定義を生み出す。それをドライバーに渡せば、ドライバーはアプリ定義に従って自らを一瞬で変形させ、立ち上がる。エディターが構文レベルの正しさを保証しているので、ユニットテストも要らない（図1）。
従来の仕様書は人間にしか読み解けない（ときには人間にさえ読み解けない）ものだったが、DSP上で書かれる仕様書（アプリ定義）は人間にも機械にも読み解けるものだ。人間にとっての分かりやすさと、機械にとっての分かりやすさが両立されている。エディターの使い方さえ理解すれば、誰でも仕様書を書けてしまう。
ただし、「誰でも仕様書を書ける」は「誰でも設計できる」の意味ではない。これまでの連載でも説明したように、まずはデータベース（DB）設計が適切になされなければいけない。DB設計がいい加減であれば、大量の仕様書を書いても意味はない。適切なDB設計を生み出せる要員だけが、適切な仕様書（＝そのまま動作するアプリ）を書ける。それが実装合理化に伴う「少数精鋭化」の実相である。
仕様書問題はたいてい、Excelで書かれた仕様書（“Excel方眼紙”と揶揄〈やゆ〉される）への批判で終始するのだが、本質はそこではない。「仕様を実現する要員」が「仕様を生み出す要員」とは別だったこと、しかもそれが“人間”だった点にある。DSPは「仕様を実現する要員」を「仕様書に従ってデータ処理するロボット」に置き換えた。ただし、全てのプログラミングが機械化されたわけではない。パターンに沿ったデータ処理については機械にまかせる一方、人間は「システム設計」と「複雑なデータ処理のプログラミング」を担うという分業体制だ。従来の仕様書は「プログラマーへのプログラミング指示書」であったが、DSP上の仕様書は「コンピューターへのデータ処理指示書」だ。考えてみれば後者は字義上「プログラム」以外の何物でもなく、実装技術が発展した結果、仕様書そのものがプログラムになっただけの話である。
DSPを使うユーザー企業にとっても、この体制は意義深い。システム設計には専門性が必要なので、本番システムが完成するまでをベンダーにまかせ、その後はユーザー自身が保守を担うといった分担が可能になる。DB構成を大きく変更するような仕様変更については専門家の助けが必要だが、それ以外の日常的な修正はユーザー自身でアジャイルに進められるようになる。わずかの仕様変更に何百万円も請求されるような心配は要らない。なにしろ、ユーザー側の担当者が仕様書を変更するだけで「仕様変更」が終わってしまうのだ。
