AI時代のエンジニア組織のあり方：議論の整理
出発点
「エンジニアはすぐ手を動かしたがるが、AIで実装コストが下がった今、何をつくるかの方向性や発散的な議論にもっと時間を使うべきだ」という問題提起から議論が始まった。スクラムでいえば、スプリント丸々テキストベースの対話と議論だけに使う回があってもいいくらいだ、という主張である。
論点1：ボトルネックの移動
AIによって実装速度が上がった結果、ボトルネックは「つくる力」から「何をつくるかを見極める力」に移った。
- 「手を動かす＝生産的」「議論＝非生産的」というエンジニア文化の暗黙の前提自体を問い直す時期にある
- AIで「とりあえずつくってみよう」のコストが下がる分、つくったものに愛着が湧いてサンクコストで引き返せなくなるリスクもある
- 方向が間違ったまま高速に実装を回すことが、最大の無駄になりつつある
論点2：意思決定モデルの転換
従来は人間のつくる速度がボトルネックだったため、チームプレイでn人1製品が合理的だった。しかしAIがペアになることで1人でも実装の質と速度が担保できる今、探索フェーズでチームを組む理由が薄れている。
- 合議にすると「無難な方向」に収束しがちで、発散的な探索には向かない
- 1人が仮説を持って1人で検証まで回せるなら、探索の多様性も並列度も上がる
- 求められるエンジニア像が変わる。実装力よりも問題発見力、仮説構築力、そして「筋が悪い」と早めに捨てる判断力が重要になる
- 端的に言えば、研究者寄りのケイパビリティが求められる
論点3：組織モデルの再設計
開発プロセスを2つのフェーズに分離する。
前半：探索ループ
- 探索と実装は個人が行う。 各自が1人1テーマで仮説を立て、AIを活用してプロトタイプまで個人で作成する
- 評価と選別は集団で行う。 定期的なレビューの場で「続けるか・捨てるか・深掘りするか」を判断する
- このサイクルを繰り返す。「これをつくるべきだ」という確信が醸成されるまで回す
後半：実行フェーズ
- 確信が得られたテーマに対して、従来型のチーム開発で品質を磨き上げる
- 手法はウォーターフォールでもアジャイルでも何でもよい
マネージャーの役割
- 進捗管理ではなく、各人の探索の質を高めるキュレーション型の関わり方になる
- 研究室の教授が院生の研究を見るようなイメージ
論点4：探索ループ内の発散と収束
探索ループの中にも構造がある。発散と収束の2つのフェーズが存在する。
- 発散を十分に行うことが重要。 安易に収束させると、見えている範囲の中の最適解しか出てこず、探索した意味がなくなる
- しかし発散だけでは収束しない。 どこかで収束のプロセスが必要になる
- 収束のタイミングを早めすぎると発散を殺す。 このジレンマが設計上の課題
この緊張関係の解消方法として、発散の判断は個人、収束の判断は集団、と主体を分けるアプローチがある。個人は「まだ広げていい」という安心感の中で探索でき、収束は集団の目で行うから独りよがりにならない。