価値創造プロセスのボトルネックはどこに
主なインプット
47 コーディングではボトルネックではなくなる ではボトルネックは何処に？ （みたいな事を考え続ける必要があるのだと思う）
https://scrapbox.io/files/68bd34ce08f5e04436156713.png
t_wadaさんとやっとむさんの対談
つまり
AIの爆発的なコード生成能力を最大限生かすには、パイプラインへの人類の関与をできるだけ減らす必要があるのでは
では、人類は何をエンジニアリングの対象とすべきか？
ひとつは「何を作るか？なぜ作るか？」という良質な問いを立てることが人類の手に残ると思われる
問いを立てることの主体性は今しばらく人類の手に残るとして
問いを実証し、探索するためのプロトタイプを超高速に生成し、仮説実証できる仕組みが必要となるだろう
それは品質は二の次なVibeCoding的に生成されるのかもしれない
さらに、プロトタイプにより価値を実証されたプロダクトでは、品質を確保する必要がある
それは「人類の関与をできるだけ減らしたパイプライン」によって生成されるだろう
つまり人類は、「プロダクトの品質を作り込むパイプラインを保証するシステム」をエンジニアリングすべきということか
だがそれはあくまでも既知の領域の話
未知の領域。つまりクネビンフレームワーク的には混沌や複雑の領域では、人がAIに伴奏して未知を既知に切り取っていく必要があると
/icons/hr.icon
以下、Geminiさんのまとめ
読みにくいからドキュメントにした。
無邪気に「自律開発プラットフォーム」とかいうけど、誰がどうやって構築するんだろうな。。
と思ったのでドキュメントにはタブを追加しておいた。
曰く
まずは2025年9月現在で一般的なAgenticCondigの活用を組織に浸透させる
他方、TDD実践者を増やす
CI/CDパイプラインを高度化させる
非機能要求にも評価関数(適応度関数)を用意する
ビジネス要件のゴール定義から…とか書いてあるけど、この辺からめちゃ抽象度高くて適当感があふれてくるので割愛
ソリューション要求を書いたら自動でテストが生成されて、パイプラインに組み込まれるぐらいのことをやれないと実現しなさそう
AI時代の開発モデル：2つの領域におけるV字モデルと役割分担
領域の定義：探索と活用
開発対象となるドメインを、その不確実性と目的に応じて2つの領域に分類する。
table:table
教官モデル適用領域 <br> (価値探索・ドメイン発見領域) 交通システムモデル適用領域 <br> (価値提供・ドメイン活用領域)
主目的 未知の課題を解決し、ビジネスの競争優位の源泉（中核ドメイン）を発見・構築する 既知の課題を効率的に解決し、ビジネス価値を安定的に提供・スケールさせる
特性 - 不確実性が高い<br>- ビジネス要求が頻繁に変化・進化する<br>- 正しい設計（境界）が不明確 - 確実性が高い<br>- ビジネス要求が明確で安定的<br>- ベストプラクティスや設計パターンが確立済み
人間の役割 AIの伴奏者・教官 <br> (Accompanist / Instructor) エコシステムの設計者 <br> (Ecosystem Designer)
/icons/hr.icon
【教官モデル適用領域】 (価値探索・ドメイン発見領域)
目的： 人間とAIが密接に対話しながら、手探りで正解を見つけ出す。キーワード： 伴奏、対話、試行錯誤、意図の埋め込み。
table:table
V字モデル工程 主担当 支援 役割と活動内容
ビジネス要求定義 <br> (仮説立案) 仮説デザイナー ﾃﾞｻﾞｲﾅｰ, AIｺﾝﾀﾞｸﾀｰ 顧客課題を洞察し、「検証可能な価値仮説」を立てる。成功の基準となるビジネスKPIを定義する。
ステークホルダ要求定義 <br> (振る舞いの記述) 仮説デザイナー AIｺﾝﾀﾞｸﾀｰ 価値仮説を、BDDのGherkinのような形式で「システムの振る舞い」として記述する。これが最上位の受け入れ条件となる。
ソリューション要求定義 <br> (コンポーネント設計) AIコンダクター AIｴｰｼﾞｪﾝﾄ 振る舞いを実現するための大まかなコンポーネント構造やAPIの草案をAIと対話しながら設計する。人間とAIの伴奏が最も密になる工程。
クラス/メソッド設計 AIエージェント AIコンダクター AIが詳細設計の大部分を行う。AIコンダクターは、その設計がドメインの「意図」から外れていないかを教官としてレビュー・修正指示を出す（例：「ここはStrategyパターンで」）。
実装 AIエージェント - AIがTDDサイクルを回しながら100%実装する。AIコンダクターはプロセスを監視する。
--- --- --- ---
単体/結合テスト AIエージェント (ｸｵﾘﾃｨｱｰｷﾃｸﾄ) AIが実装と同時にテストコードを生成する。品質の基準はクオリティアーキテクトが定義した「テストの網」に従う。
システムテスト AIコンダクター 仮説ﾃﾞｻﾞｲﾅｰ 「振る舞いの記述」が正しく実装されているかを検証するテストを、AIの支援を受けながら作成・実行する。
受け入れテスト 仮説デザイナー (ｽﾃｰｸﾎﾙﾀﾞ) 「価値仮説」が検証できる状態にあるかを確認する。コードではなく、ビジネス価値が実現されているかを検証する。
/icons/hr.icon
【交通システムモデル適用領域】 (価値提供・ドメイン活用領域)
目的： 人間が設計したエコシステムの中で、AIが完全に自律的に価値を生産する。キーワード： 自律、自動化、ガードレール、スケーラビリティ。
table:table
V字モデル工程 主担当 支援 役割と活動内容
ビジネス要求定義 <br> (目標設定) 仮説デザイナー (ﾋﾞｼﾞﾈｽ部門) 「この仕様で新しい決済手段を追加して」といった、パラメータ化された明確なビジネスゴールを定義し、自律開発プラットフォームに投入する。
ステークホルダ要求定義 <br> (自動生成) 自律開発プラットフォーム - ビジネスゴールから、既存のガードレール（テンプレート、設計パターン）に基づき、振る舞いの定義を自動生成する。
ソリューション要求定義 <br> (自動生成) 自律開発プラットフォーム - プラットフォームに組み込まれたアーキテクチャルールに基づき、コンポーネントからメソッドレベルまでの全設計を自動生成する。人間の関与はゼロ。
クラス/メソッド設計 <br> (自動生成) 自律開発プラットフォーム - 〃
実装 <br> (自動生成) 自律開発プラットフォーム - 〃
--- --- --- ---
単体/結合テスト <br> (自動実行) 自律開発プラットフォーム (ｸｵﾘﾃｨｱｰｷﾃｸﾄ) **クオリティアーキテクトが事前に設計した「ガードレール」**に基づき、テストの生成・実行を全て自動で行う。
システムテスト <br> (自動実行) 自律開発プラットフォーム - 振る舞いの定義に基づき、システムテストを自動生成・実行する。
受け入れテスト <br> (自動検証・デプロイ) 自律開発プラットフォーム 仮説ﾃﾞｻﾞｲﾅｰ 全てのガードレールをパスした場合、自動的に本番環境へ段階的リリースされる。仮説デザイナーは、リリース後にビジネスKPIのダッシュボードを監視することで結果を受け入れる。
/icons/hr.icon
結論
ソフトウェア開発は、「探索」と「活用」の2つのフェーズに大別される。
教官モデルは、不確実性の高い**「探索」フェーズ**において、AIの能力を借りながら人間がドメインの本質を理解し、秩序を創造していくためのプロセスである。
交通システムモデルは、秩序が確立された**「活用」フェーズ**において、人間が定義したルールの中でAIが価値を大規模かつ高速に生産し続けるためのプロセスである。
開発組織の究極的な目標は、教官モデルで得られた知見（安定したドメインモデルや設計パターン）を、交通システムの新しい「ガードレール」として継続的に組み込み、より多くの領域を自律開発可能な状態へと進化させ続けることにある。人間は常に、AIがまだ扱えない、よりフロンティアな領域へと挑戦を続けていく。