生成AIでシステム開発を効率化しようって話に溢れていて、中でも仕様駆動とかスペック駆動とか言われる領域なんかは実用性もあるってことで盛り上がってる感じがある。 でも、この期待を数百・数千人規模のエンタープライズのウォーターフォール開発に持ち込もうとすると、2つの大きな壁に思い当たる。ひとつは技術的な壁で、もうひとつは組織的な壁。今回は、この2つの壁がどんな構造になっているのかというのを考えている。
第一の壁: ドキュメント分割がもたらすジレンマ
大規模なウォーターフォール開発では、設計ドキュメントに2つのことが求められる。1つは、設計全体が矛盾なく整合性を保ってること。もう1つは、後から仕様変更があっても対応できるように、DRY（Don't Repeat Yourself）な構造を保つこと。
DRY原則っていうのは、要するに同じ情報を複数の場所に書かないってやつ。こうしておくと整合性は保ちやすい。何か変更したくなったときに、修正箇所が1箇所で済むから。数百・数千ページもあるドキュメント群で、あちこちに同じ情報が散らばってたら、変更の影響範囲を追いかけるだけで定時が過ぎる。
ところが、DRY原則を厳格に守ると、情報は各ドキュメントに分散していく。システム全体を理解しようと思ったら、複数のドキュメントを行ったり来たりして情報を集めないといけない。これが読み手にとっては結構しんどい。
コードだったら、IDE上で定義ジャンプができる。変数や関数の定義元へ瞬時に飛べるし、参照箇所も一覧できる。でも、自然言語で書かれた設計ドキュメントの世界には、そんな便利な仕組みがない。「この処理の詳細は基本設計書の第3章を参照」と書かれていても、その第3章がどのファイルにあるのか、さらにそこから参照される別のドキュメントがどこにあるのかを、読み手は手作業で追いかけていくしかない。そもそも俺たちを取り巻く現実は、俺たちが第３章を見るときには、その第３章が第５章あたりに移動してたりする。
ウォーターフォール開発は一般に、要件定義から基本設計、詳細設計と進んでいって、工程も分かれる。要件定義をもとに基本設計を、基本設計をもとに詳細設計を作っていくという、段階的詳細化が行われる。この過程で情報はさらに細分化されて、複数のドキュメントに散在していく。
結果として読み手たるエンジニアは、大量のドキュメントの魔界に迷い込んで、全体像を把握できなかったり、コンテキストを抑えられなかったりする。 生成AIにとってもこの構造は同じ。細かく区切られたドキュメント群から必要な情報を集めて、全体の整合性を理解しないといけない。コードジャンプのない自然言語の世界で、これは容易なことじゃない。
頭の良いみなさんはGraphRAGとかを使うんだろう。そうであれば、それでうまくいくんだと教えてくれ頼む。
第二の壁: 標準化と、イノベーションのジレンマ
ドキュメント分割による困難を解決する1つの方法は、標準化なんだろう。基本設計と詳細設計で明確な役割分担を定義して、ドキュメント構造を標準化する。そうすれば、読み手や生成AIが、どこに何が書かれてるかを予測しやすくなる。
理想を言えば、基本設計でハード制約（法規制とか契約とか）、技術制約（クラウド基盤、データベース、言語、既存APIがなんだとか）、運用制約あたりを確定させておく。そして、機能一覧とその責務を粒度一定で分解していって、さらに個々の機能についての入出力と機能横断で影響する副作用を決めて、機能間の全体整合を確認する。機能のロジックはブラックボックスでも全体整合性は保てるからね。 詳細設計では、その全体整合が取れる枠組みを個々の機能でどう構成するかを設計する。まあそんな感じなんじゃなかろうか。
でも現実は、このあたりプロジェクトごとバラバラ。基本設計と詳細設計の垣根は非連続ってより連続で、だからこそ境界線はプロジェクトごと大きく変動するし、その結果として設計ドキュメントの構造もプロジェクトごとに違ってくる。 ある組織では基本設計段階でデータベーススキーマまで確定させるけど、別の組織では詳細設計で初めてスキーマを設計する。プロジェクトの性質、チームのスキルセット、顧客の要求、これら全部が設計ドキュメントの構造に影響を与える。
だからこそ、多くの、そして多様なプロジェクトを担う組織ほど、この標準化に二の足を踏む。あるいは、標準化したところで普及の難易度が高くなる。既存のプロジェクトを抱える組織は、その成功体験と既存の仕組みがあるがゆえに、新しい標準化を進めるのが難しい。 一方で、小回りのきく組織は超高速で標準化を達成する。プロジェクト数が少なくて、組織もフラットなら、新しい標準を導入するコストは低い。そして、その標準化の恩恵を真っ先に享受するのもこうした組織になる。イノベーションのジレンマって、こんな話じゃなかったっけ。
生成AIは何を変えられないのか
ドキュメント分割の問題に対して、生成AIは大量のドキュメントを横断して情報を収集して、関連する記述を結びつけて全体像を提示することが期待される。できれば、EmbeddingされたSemanticな世界じゃないところで実現したいけど。
ただ、完全にアドホックな構造のドキュメント群から整合性のある全体像を構築するのは、生成AIにとっても困難。ドキュメント群が一定の構造を持ち、参照関係が明確じゃないと、生成AIでも対応しきれない。結局のところ、ある程度の標準化は必要になる。
で、この標準化の壁は、生成AIだけでは越えられない。これは技術的な問題じゃなくて、組織的・政治的な問題だから。どれだけ優れた生成AIがあっても、組織内の合意形成を代行できない。既存プロジェクトの成功体験を持つチームを説得できない。 小規模なプロジェクトなら、要件から直接コードを生成するアプローチが現実的になりつつある。でも、数百・数千人が関わる大規模プロジェクトでは、依然として設計フェーズでの調整と合意形成が不可欠。そこでは、設計ドキュメントは単なる生成AIへのインプットじゃなくて、関係者間のコミュニケーションツールとしての役割も担ってる。
生成AIが変えられるのは、ドキュメント作成の効率化とか、情報の検索・統合といった技術的な側面。でも、組織構造とか、プロジェクトの進め方、関係者間の合意形成といった構造的な側面は、生成AIだけじゃ変えられない。 人間が作る組織に向き合う必要がある。こんな仕事が人間に残っていく。エンジニアリング、Craftmanshipという概念が変わっていて、その真っ只中に僕たちはいる。僕はラッダイト運動側にいるので、いつしか淘汰されるんだろう。
まとめ
生成AIとウォーターフォール開発の組み合わせには、2つの大きな壁がある。
ひとつは、DRY原則による整合性担保と、読み手の理解しやすさという相反する要求から生まれる技術的ジレンマ。情報を分散させることで整合性は保ちやすくなるけど、全体像の把握は困難になる。コードジャンプのない自然言語の世界で、この困難は読み手と生成AI双方に同じように存在する。
もうひとつは、標準化とイノベーションのジレンマという組織的な壁。標準化は問題解決の鍵なんだけど、既存のプロジェクトを抱える組織ほど標準化が難しくなる。小回りのきく組織が先に標準化を達成して、その恩恵を享受する構造がある。
生成AIは、ドキュメント作成の効率化や情報統合という技術的側面では貢献できる。でも、組織構造や合意形成といった構造的課題は、生成AIだけじゃ解決できない。結局、人間が作る組織に向き合う必要がある。こんな仕事が人間に残っていく。
エンジニアリングとか、Craftmanshipという概念が変わっていて、その真っ只中に僕たちはいる。僕はラッダイト運動側にいるので、いつしか淘汰されるんだろうけど。
