9月8日、Nicholas C. Zakasが「Five software engineering roles for working with AI」と題した記事を公開した。ZakasはESLintの創設者であり、JavaScriptエコシステムで長年影響力を持つエンジニアだ。この記事では、AIと協働するソフトウェアエンジニアが取りうる5つの役割モデルとその使い分けについて詳しく紹介されている。
AIブームから4年が経過し、エンジニアとAIの関係は単純なコード補完から、バグレポートのトリアージや修正デプロイまで自律的に行うエージェント型AI開発へと進化した。しかし「どれだけAIに任せるか」という問いへの答えは、いまだエンジニアによって大きく異なる。
Zakasは、この「人間とAIの関与度合い」を、ソフトウェア開発で馴染みのある職務ロールに対応させて整理した。以下にその5つのロールを紹介する。
5つのロール全体像
オブザーバー（ペアプログラマー）
AIがコードを書くのをリアルタイムで監視し、逐一確認・修正指示を出す役割。ペアプログラミングにおけるオブザーバー（ナビゲーター）に相当する。
AIをまだ信頼しきれない段階のエンジニアが自然に入るポジションだ。生産性は多少向上するが、コードを一行ずつ読み続けるため、スループットは自分の読解速度に縛られる。レビュー疲れを防ぐため、自分がドライバーになる時間とAIにコードを任せる時間を意識的に切り替えることが推奨されている。
テックリード
5つの中で生産性の乗数効果が最も大きいロールだ。
人間のテックリードと同じように、AIに対して技術仕様書を書き、エージェントに実装を任せて、完成後にプルリクエストをレビューする。人間チームと同様、複数のワークストリーム（並行する作業の流れ）を同時に走らせられる点が最大の利点で、自分がボトルネックにならずに済む。
課題はやはりレビュー疲れだが、ここで効いてくるのが自動化への投資だ。コードフォーマッター、リンター、最低カバレッジ要件付きの自動テスト——これらを整備するほど手動レビューの負荷が下がり、マージへの確信度が上がる。
アーキテクト
コンポーネント間のインターフェースや全体的なシステム設計に集中し、個々のコードはほぼ見ない。テックリードが品質保証の仕組みを整えていることを前提に、完成したシステムのアーキテクチャとログを確認するのが主な仕事になる。
課題は「現場感の喪失」だ。何か問題が起きたとき、コードレベルで原因を追えない可能性がある。スポットチェックで生成コードを定期的に確認することが対策として挙げられている。
エンジニアリングマネージャー
個々のコミットやコードレビューには関与せず、ソフトウェアを生成するプロセス自体を設計・整備する役割だ。PRD（プロダクト要件定義書：Product Requirements Document）→技術仕様→実装計画という一連のフローを定め、各ステップをエージェントに割り当てて受け入れ基準を設定する。いわば「ソフトウェアファクトリーの組み立て」だ。
アーキテクト同様、コードから遠ざかるリスクがある。プロセスを修正して再実行を繰り返す判断が、手を動かすより遅くなるケースもある。
プロダクトマネージャー
技術的な詳細には一切関与せず、ユーザー体験と最終成果物だけを見る役割。ユーザーストーリーが満たされ、明らかなバグがなければOKとする立場だ。
筆者は「バイブコーダー（vibe coder：プロンプトを投げて雰囲気でコードを生成させるスタイル）」とは区別している——プロダクトマネージャーロールでも、ユーザーリサーチやテストといった本来の仕事はしっかり行うためだ。ただし何か壊れたとき自力で直せないというリスクは常に抱える。AIが引き起こした問題をAIに修正させると、根本原因ではなく応急処置になりやすい、と指摘されている。
どのロールが正解か
筆者の結論は明快だ——どのロールが優れているわけではなく、状況に応じて使い分けるべきだということ。
- 未知のコードベースを探索するときは → オブザーバー
- 複数ワークストリームを回すときは → テックリード
- ユーザー体験を最優先するときは → プロダクトマネージャー
重要なのは「意図的に選ぶ」ことと、「状況がより手厚い関与を要求しているときに気づく」ことだ。AIへの信頼とAI自体の能力が高まるにつれ、スペクトラム上を柔軟に移動できるようになる——ただし、結果への責任を手放さないことが前提となる。
詳細はFive software engineering roles for working with AIを参照していただきたい。
