前回のブログで「AIの台頭によってIT技術者の将来はどうなるのか？」と前振りした件です。
私の考えは一貫しています。Wagbyを市場に投入した2005年から「大半のコード生成は自動化されるので、（業務アプリ開発に関わる）技術者は上流シフト、つまり、業務の複雑さに向き合うことが求められる」というものです。
業務アプリケーション設計の起点はデータモデルです。業務アプリケーションは次のように階層化することができます。
すべての業務アプリケーションは、それがどういうデータを扱うのかを定め、その格納場所（テーブル）を決めることが土台になります。処理とは、どのデータとどのデータを、どのタイミングで（オンライン／バッチ or 同期／非同期）、どう計算するのか、の塊です。UIとは、これらのデータをある業務視点で整理したビューのことです。土台となるデータの構造を「データモデル」と呼びます。すべての開発者がデータモデル作成に関わることはありませんが、データモデルを読んで理解する必要があります。データモデルをあいまいな状態にして業務アプリケーション開発を行うとプロジェクトは混乱します。
DX人材とかAI人材とか呼称は変わっても、こと業務アプリケーション開発においてはデータモデルを作成すること、もしくは読めること（これは業務理解と同義）ができてはじめて応用が効きます。この点は共通項であり、技術が変わってもこの考え方は変わっていません。
なおオブジェクト指向とかDDDとか、他にもさまざまな技術的観点がありますが、それらはすべてテクニックのことだ、というのが私の解釈です。技術者なのでテクニックを学ぶことはもちろん意義があります。しかし、その根源にあるのはデータモデルであり、そこをおろそかにしてテクニックだけ学んでも現場では使いようがありません。
ここまでを前提として、ではAIの登場によって設計部分の何が変わるのでしょうか。
データモデルを生成AIに作成させる
AIに業務概要を日本語で説明し、これを表現するデータモデルをマーメイド形式で出力するよう指示すれば、多くのビューアーで見やすいER図を画面上で確認することができます。これをとっかかりとしてAIと会話しながら、より精度の高いデータモデルをつくることができそうです。
プロジェクトの初期段階では、データモデラー経験者をメンターとして、現場の業務担当者も交えながら、AIが作成したデータモデルの妥当性を検証するとよいと思います。ポイントは、今回対象としてる業務全体をカバーしているかどうかです。なお業務を縦割りにして個別にデータモデルを作成してはいけません。あくまでも一つの統合されたデータモデルをつくる必要があります。AIは支援役として役に立ちますが、そのデータモデルを理解し、採用するのは人間の仕事です。
業務処理のまとめ方
データモデルの作成と同時に、業務用語集も作成するとよいでしょう。これもAIがまとめてくれます。この二つを入力として、処理を記述していきます。記述方法はさまざまですが、業務用語集の範囲で説明できるようにする、という制約を守ります。この点でもAIが支援することでしょう。
そして、この処理部分を最終的には一つの統一書式にまとめていくのがよいと考えています。これは上で示した三階層の情報をすべて含むものです。記述フォーマットは markdown や yaml が候補になります。markdown は自由記述なので人間にとっては優しいのですが、定式化して誤解をなくすということで yaml 形式をメインにすることを推します。yaml でアプリケーションの構造を記述し、markdown は補助説明とするという構図です。
ルールベース生成と、AI生成のバランス
ここからコードの自動生成を目指します。現時点では一度に多くのプロンプトを与えることは難しいため、少しずつ小分けにして生成させることになります。やってみるとわかるのですが、常に安定的に生成されるコードと、同じプロンプトでも結果が大きく変わるコードがあります。生成AIの利用も無料ではありませんので、安定的に生成されるコードは、実はルールベースのプログラム生成部に代替する方がよいのではないかと考えています。そしてこの部分はまだまだWagbyが役に立つだろうと考えています。
まとめ
2005年時点で到達した一つの結論は、開発者の仕事はデータモデルを核とした業務の理解と、非定型的なプログラミングの二方面対応になるというものでした。AIの登場によっても、この構図は変わりません。ただし非定型的なプログラミングはますますAIがカバーするので、残るのは業務理解の部分です。プログラミング部分が完全にゼロになる、というのはまだ先でしょうが、長い目でみればゼロに近づくでしょう。コードの書き方、つまりテクニック的な面もAIがカバーするでしょう。そして冒頭で示した三階層のうち、UI層と処理層についてはAIが逆提案し、人間（開発者）がそれを受け入れるという進展も期待できます。
しかし最後まで人間が手放せない領域 = 主導権（イニシアティブ）をもつべき領域があります。それが最下層つまり基盤となるデータです。特にデータの構造を表現するデータモデルだけはAIではなく人間が決定権と責任をもつべきです。
このイニシアティブという言葉は、20年前であれば「重要なノウハウを外部ベンダーに握られていないか？そうであれば発注企業自らで取り戻そう！いざ、内製回帰！」という文脈で使われていました。AIの登場によって多くの面倒さをAIが引き受けることになりそうですが、それでも最後の境界線は残ります。データに対するイニシアティブを人間側が持ち続けられるように、業務アプリケーション技術者は関わっていくと思います。
次回の Wagby Developer Day 2025 ではデモを交えながら、これらの話を行う予定です。
