AI時代のベストアーキテクチャって、モノリシックに回帰するんとちゃうか。
最近、生成AIと一緒にプログラムを作ったり、既存コードを見たりしていて、そんなことを考える。
画面があって、業務の処理があって、データを読み書きする。その流れが、一気通貫で分かる。
あのシンプルさ、今になって考え直しても、結構ええもんやったんとちゃうか。
わしの出発点は、VB5とかAccess VBAの時代やった
わしが仕事として初めてプログラムを組んだのは、VB5とか、そのへんの時代やった。AccessのVBAも触ったし、VB6のシステムを長く保守した思い出もある。
あの頃、わしが触っていたコードは、UIも、ビジネスロジックも、データ操作も、だいたい同じところに書いてあった。
ボタンを押したら、入力をチェックして、計算して、SQLを発行して、結果を表示する。
上から読んだら、その画面で何をしているか分かる。せいぜい、マスタから名称を取ってくる処理を共通部品にするくらいや。
今の感覚なら、「責務が分かれてへん」「密結合や」と言われそうな書き方やな。
でも、自分の担当機能を一気通貫で見渡せた。
少なくとも、担当して保守するわし本人の感覚では、保守性は悪くなかった。むしろ、分かりやすかったんよ。
気づいたら、分けるための部品をつなぐ部品を覚えていた
潮流が変わったと感じたのは、わしの現場でJavaや.NET Frameworkを使うようになってからや。
オブジェクト指向。MVC。レイヤー分離。疎結合。
画面はここ。業務の処理はこっち。データへのアクセスはさらに別。
その間をつなぐインターフェースや、各種の共通部品や、フレームワークがあって、依存関係を組み立てるDIコンテナも出てくる。
DIコンだか、ダイコンだか知らんけどさ。
いや、仕組みとして何をしたいかは分かるんよ。役割を分けて、差し替えやすくして、再利用しやすくする。
ただ、実際に担当機能を直す側からすると、
「これを分けて、その間をつなぐために、これも覚えてください」
って話が、どんどん増えていった感覚がある。
その役割ごとに、担当者がおる現場ってどれだけあるんや
ここで、ずっと引っかかっていることがある。
MVCで分けるとして、画面の専門家、データベースの専門家、ビジネスロジックの専門家が、それぞれ担当する。
そんな役割分担ができるプロジェクト、実際どれだけあるんやろ。
メンバー50人とか、10億円を超える案件とか。そういう規模なら、専門の担当者を置けることもあるやろう。
でも、わしが思い浮かべる現場は、せいぜいこんな感じや。
- PM：名前は載っているけど、日々の実務はあまり見えない。
- PL：実際にいちばん大変な役。全体を回して、顧客とも話して、問題も拾う。
- 会計系サブチーム：サブリーダーとPG1人。
- 販売系サブチーム：サブリーダーとPG2人。
顧客の予算ギリギリで組んだ体制や。
ここに、画面デザイン専任、DB専任、ビジネスロジック専任の人を、さらに雇う余裕あるか？
せいぜい共通フレームワークに専任を置けたら、だいぶありがたい。
もちろん、MVCはコードの責務を分ける話で、そのまま人の職種を分ける決まりではない。それは分かっている。
でも、コードを分けても、担当者の人数は増えへんのよ。
MもVもCも、その間の部品も、結局ぜんぶわしが見る
実際には、会計系、販売系という業務単位で担当を分けている。
会計の担当者は、会計の画面を直す。会計の業務処理を直す。会計のSQLも直す。
だから、MVCも、それをつなぐ部品も、フレームワークのルールも、全部分からなあかん。
一つの機能を直すために、画面、コントローラー、サービス、インターフェース、データアクセス、その登録設定……と、あちこちを巡る。
設計図ではきれいに箱が分かれている。
その箱を全部またいで作業する人間は、同じ一人や。
これ、現場のわしからしたら、複雑性が増えただけになってへんか？
分けたことで得られるメリットはあるとしても、そのメリットと、覚える量、追いかける量、修正する場所の数は、ちゃんと釣り合ってるんやろか。
再利用できる共通部品が、保守では触れない部品になる
「疎結合にしてあるから、部品として使いやすい」
それは、アーキテクチャの売りとしてよく分かる。
でも、保守フェーズで現場に降ってくる話は、もう少し生々しい。
「この共通部品、ちょっと修正したいです」
「それ、ほかのサブシステムでも使ってますよね。影響確認とテストは？」
「……その工数、今回の見積もりに入ってません」
部品の呼び出し方がきれいでも、多くの機能が同じ実装を使っていたら、振る舞いを変えたときには利用先の確認が要る。
でも、与えられた工数では、その範囲のテストを確保できん。
そうすると、どういう判断になるか。
「ほぼ同じ処理やけど、自分とこ担当のサブシステム群に取り込んで、こっち用に作ってしまおう」
共通部品をコピーして、必要なところだけ直す。
サブリーダーの立ち位置なら、わしでもそう判断すると思う。自分の責任範囲でテストして、納期までに出さなあかんからや。
もちろん、その後に同じ不具合を別々に直すことになったり、少しずつ処理がずれたりする。その先の面倒もある。
でも、その面倒を承知でコピーするくらい、今ある予算と影響範囲の壁はでかい。
再利用しやすいはずの部品が、共有されすぎて触れない部品になる。
この現場の都合、きれいな構成図のどこに載ってるんやろな。
AIが一気通貫で見られるなら、シンプルな形に戻ってもええんちゃうか
今は生成AIがあるから、コードを探したり、呼び出し元を洗い出したり、影響しそうな箇所を挙げてもらったりできる。
昔より、変更の調査を手伝ってもらえるようにはなった。
そこで、わしは逆のことも考える。
AIと一緒に、画面から業務処理、データ操作まで追って直せるなら、その一つの仕事を、もっと近い場所にまとめておいてもええんちゃうか。
人間に機能を説明するときも、AIに改修を頼むときも、「この業務は、ここを読んだら流れが分かる」という形にしておく。
一つの修正のために、ファイルと設定と抽象化の階段を、何往復もせんでええ形や。
AIが複雑なものを扱えるようになったからこそ、わざわざ複雑にしておく理由も、もう一回考えたくなる。
「AIなら、この複雑な構成も理解できます」
それはありがたい。でも、
「そもそも、その構成、ここまで複雑である必要あるん？」
って問いも、してええはずや。
設計図より、担当機能を見渡せること
独立して動かしたい機能がある。別々のチームで開発したい。負荷の大きいところだけ増やしたい。そういう事情があるなら、それに合う分け方をすればええ。
ただ、少人数で業務単位に担当を分けている現場なら、まず一人が担当機能を見渡せることを、もっと大事にしてええんちゃうか。
画面で何を受け取って、どう計算して、どのデータを変えて、何を返すのか。
それを一気通貫で読めて、修正できて、確認できる。
わしがVB5やVB6の頃の書き方に感じていた保守のしやすさは、そこやったんやと思う。
せっかくAIが手伝ってくれる時代になったんやから、手伝ってもらいながら、構造そのものもシンプルにしていけばええ。
AI時代のベストアーキテクチャは、案外モノリシックに回帰するんとちゃうか。
昔のコードを保守してきたわしには、そんな未来も、結構しっくりくるんよな。
用語の補足：モノリシックは、一般には一つの単位として動作・配備する構成を指す。MVCや内部のレイヤー分離と両立するので、「モノリシック＝全部を同じ関数に書く」ではない。本稿では、昔の開発経験を出発点に、機能の流れを近い場所で見渡せる設計についても話している。参考：Microsoft Learn：一般的なWebアプリケーションのアーキテクチャ。