NGWを作るアプリ「CreateDBWeb」 — テーブルを定義すれば、動くアプリが生まれる

アプリを作るアプリ

前回、NGWの画面は「規約を守っているというより、同じ型で生成されているから同じ顔をしている」と書いた。その生成器が CreateDBWeb である。正体は「MySQLのデータI/Oシステムを自動生成する道具」——つまり、DBのテーブル定義を与えると、動くアプリ一式を吐き出すアプリを作るアプリだ。

NGWの多くの画面は、一行ずつ手書きされたのではなく、ここから生まれている。今日はその仕組みを、架空のテーブル NGWT_SAMPLE を題材に見ていく。

まず、テーブルを定義する

CreateDBWeb の画面で、テーブルをひとつ定義する。たとえば NGWT_SAMPLE に、こんな列を与えるとする。

列	型	画面オブジェクト
`NGWT_SAMPLE_ID`	INT（AUTO_INC）	主キー・テキスト表示
`DIVISION_CD`	VARCHAR(10)	セレクト（部門）
`NGWT_SAMPLE_NAME`	VARCHAR(256)	テキスト
`NGWT_SAMPLE_SETUMEI`	TEXT	複数行テキスト（TEXTAREA）
`NGWT_SAMPLE_FLAG`	INT	チェック（トグルスイッチ）

ポイントは、単に「型」だけでなく、その列を画面でどう入力させるか（画面オブジェクトの種別）まで一緒に定義することだ。テキストなのか、セレクト（DIVISION_CD のように部門を選ばせる）なのか、複数行テキストなのか、チェックなのか。CreateDBWeb は型と画面オブジェクトの対応表を内部に持っていて、定義に沿ってUIまで組み立てる。

CreateDBWebでNGWT_SAMPLEテーブルを定義している画面

CreateDBWebの画面。架空の NGWT_SAMPLE テーブルの列・型・画面オブジェクトを定義し、下部のタブ（CREATE TABLE / CLASS / CLS FUNC / MAIN PHP / AJAX JS / AJAX PHP）で、生成されるコードをその場でプレビューしているところ。

ボタンひとつで、一式が吐き出される

定義して生成すると、NGWT_SAMPLE 用のファイルがまとめて生成される。

DBD/NgwtSample.php … テーブル定義（DDL）。これで DB に NGWT_SAMPLE が作られる。
ngwtSample.php … 画面PHP（入り口）。
ajax/ajaxNgwtSample.php ＋ ajaxNgwtSample.js … サーバ側の処理本体（SubMode分岐。制度のロジックはここへ足す）と、クライアント。
class/clsNgwtSample.php … テーブルに対応するデータオブジェクト（プロパティの器）。
clsFunction/fncNgwtSample.php … その class の I/O を制御する（DBとの読み書き）。
include/ 一式（DB接続など）。

まさに、前回紹介したNGWの基本5点セットだ。命名も規則的で、テーブル NGWT_SAMPLE から、クラスやDBDは PascalCase の NgwtSample、画面PHPは camelCase の ngwtSample へと機械的に変換される（この名前づけは CreateDBWebFuncEditName が一手に引き受けている）。人が命名で迷う余地がない。

出来上がるのは、そのまま動くCRUD

そして生成物は、手を加えなくても動く。一覧が表示され、行を選べば編集フォームが開き、登録・更新・削除ができる。部門はセレクトで選べ、説明は複数行テキストで書ける。第1回で書いた SubMode のライフサイクル（描画 → 部分再描画 → 確定）を、生成された瞬間から備えている。コードを一行も書いていないのに、NGWT_SAMPLE を出し入れするアプリが目の前で動く。

CreateDBWebが生成したNGWT_SAMPLEアプリの素の画面。左に編集フォーム、右に検索・ページング付き一覧

生成された NGWT_SAMPLE アプリの、まったく手を加えていない素の状態。左が編集フォーム（部門CDはセレクト、サンプル説明は複数行テキスト、サンプルFLAGはトグル——先ほどの定義どおり）、右が検索・ページング付きの一覧。まだデータが無いので「0 件」。ここまでを、コードを一行も書かずに得られる。

なぜ、これがNGWの土台なのか

第1回で残した問い——「数十の画面が、なぜ同じ顔なのか」。答えがこれだ。全部が同じ生成器から吐かれているから、手書きのばらつきが原理的に入り込まない。SubModeの型も、fdt* の命名も、レイヤの分け方も、生成器が保証する。10年変わらない統一感は、開発者の規律というより、仕組みで守られている。

しかも CreateDBWeb 自身も、この流儀で作られたひとつのアプリだ。アプリを作るアプリが、アプリの流儀で出来ている——この自己言及めいた構造が、NGWの背骨をぶれさせない。

生成は叩き台、肉付けは人

もちろん、生成されるのは「I/Oの土台」までだ。決裁経路、役職名の団体特例、基準日での解決、権限による可視性——これまで書いてきた制度の難所は、生成後に人が ajaxNgwtSample.php（サーバ側の処理本体）へ書き足していく。

だが、それでいい。CreateDBWeb が定型の九割（テーブルの出し入れ、フォーム、一覧、命名、レイヤ構成）を消してくれるから、人は残りの一割、つまり制度のポイントに集中できる。道具が土台を作り、人が制度を乗せる。役割分担が、ここでもはっきりしている。

AIとの協働作業での学び

「アプリを作るアプリ」は、一貫性を祈りではなく仕組みに変える道具だ。規約を口で唱えても人は逸脱するが、生成器から出てくるものは最初から揃っている。

そしてこの均質さは、あとから来る者——新しい開発者にも、AIにも——優しい。どの画面も同じ型で出来ているから、ひとつ読めれば全部が読め、ひとつ直せれば全部を同じ手つきで直せる。NGWが10年ぶん積み上げてこられた本当の理由は、たぶんこの生成器にある。次は、この土台の上に人が肉付けした実アプリを、ひとつ選んで追っていきたい。