記事サマリー
博報堂テクノロジーズの採用メディア「HADOH」に掲載された、同社のAI駆動開発組織への転換を描いたインタビュー記事。開発プロセス設計を主導したケヴィン・クラッツァさん（開発第3センター部長）と、現場推進を担う鏡川悠介さん（チームリーダー）へのインタビュー形式で、ツール導入にとどまらない「全社的な開発プロセス再設計」の全貌が語られている。
+81%
平均週次リリース数の向上
（21件 → 38件）
約4倍
週次リリース数の最低値
（4件 → 17件）
約40名 / 8チーム
先行導入規模（開発第3センター）
測定は導入前36週間・導入後34週間の計70週間にわたるモニタリングで実施。「感覚的な改善」ではなく客観的なファクトとしてアウトカムを可視化している点が特徴。
1. 背景：局所的な効率化ではなく「全体プロセスの刷新」
- エージェント型AIの登場で、開発は「人間が設計・判断を担い、実装はAIエージェントが担う」分担へ変化。
- コーディングだけ高速化しても全体プロセスがAI前提で最適化されていなければ、リリース速度は上がらない → 「AIで解決することを前提にプロセスを組み立てる」AIファースト開発へ。
- 開発第3センター約40名で先行開始。予定（3ヶ月で3チーム）を大幅前倒しし、開始わずか1ヶ月半で8チーム全エンジニアに展開。
- 定着の鍵は各チームに配置した「AIエヴァンジェリスト」。有志ではなく正式な業務目標として評価制度に組み込まれているため、本業と推進のジレンマなしで活動可能。チームごとの技術スタック・品質基準に合わせて導入をローカライズ。
2. アウトカムの定義：「リリースできたこと」を指標に
- コード行数・ストーリーポイント消化数は「数字達成のための不健全なハック」（冗長コード増加、見積もりインフレ）を生むリスク。
- 「AI生成コードの割合」や「トークン消費量」も本質的でない（無駄にAIを回しても生産性高く見えてしまう）。
- そこで「本当にユーザーに価値がデプロイされたか」= リリース間隔・サイクルタイム を評価指標にシフト。
- GitHubのプルリクエスト情報等を抽出・分析するモニタリングツールを内製し、アウトカムを可観測化。
3. レビューの再設計：「3層の自動品質ゲート」
AIの大量生成コードを人間が全部目視レビューしていてはレビューがボトルネック化するため、人間のレビュー負荷を下げる3層構造を構築。
- 第1層：AI自動レビュー — プルリクエスト作成時にAIがコードを自動チェックし改善点を指摘。
- 第2層：静的解析 — SonarQubeをセンター全体に導入。循環的複雑度・セキュリティ脆弱性・コーディング規約を機械的に弾く。
- 第3層：自動テスト — PlaywrightなどによるUIテスト・インテグレーションテストでリグレッションを機械検出。
リスクベースのレビュー濃淡
- インフラ変更・セキュリティ・認証・ロギング・金銭に関わる大きなビジネスロジックは、AIに加え人間が徹底確認。
- デザイン崩れ程度のリスクしかないフロント領域は、3層ゲート全通過を条件に人間のダブルチェックをスキップしてマージOKとする実験的ルールも導入。「なにをやらないか」の定義で人間の本質的レビューに余白を創出。
4. 暗黙知の形式知化：開発するほどナレッジが溜まるループ
- チームの作法に合わせた自作スキル・ツールを約20個用意（ドメイン知識レビュー、要件定義深掘り、プルリクエスト自動作成など）。
- GitHubのイベント（PR作成・実装計画完了）をフックで検知し、スキルを確実に自動実行。使い忘れを防止し、誰が担当しても同じ品質のAIサポートが働く。
- Claudeスキル参照ナレッジとして、過去のインシデントパターン・類似機能仕様・アーキテクチャ・言語化されていなかった暗黙のチーム規約を蓄積。
- PRレビュー時に、開発中のチャットセッションなどから「未登録の仕様ルール・新しい暗黙知」をAI自身に自動抽出させ、Markdownとして形式知化・プール。次回の開発で自動適用される。
人間がwikiにマニュアルを書く作業なしで、「エンジニアが日常的にAIと開発セッションを行うこと自体がナレッジ強化のドキュメンテーション活動に直結する」ループを実現。
UIレビュー支援の環境ハック
- PR作成時にコード差分からAWS ECSへ一時検証環境（プレビュー環境）を自動デプロイし、URLをPRコメントへ自動通知。
- 自作の「UIレビュー用Chrome拡張」: 画面要素を1クリック選択 → その場でコメント記入 → セレクタ・ビューポート情報入りのMarkdownを自動生成。指摘の起票コストを大幅削減。
5. AI前提化で見えてきた「新たな痛み」と対策
- 理解・認知負債: 自分で書いていないコードへの理解低下 → 週次の「モンキーテスト会」で全員が最新機能を触り倒し、コードを読まない分のシステム理解を補完。
- 保守工数の増大: 生成コード量に比例してメンテ対象が増加。
- 若手育成の機会損失: AIが正解を出すため試行錯誤による地力育成機会が減る → ジュニアが「AI生成コードがなぜ正しいか」をシニアに説明する機会を創出。
6. これから求められるエンジニア像
- 「コードを書く」スキルの希少価値は低下。価値の源泉は「なにが正しいか」を正しく判断する力（判断力）と、ユーザー喜び・ビジネスインパクトを考え抜くプロダクト志向へ。
- 実装という手段に固執せず、ドメイン知識と顧客のリアルな課題に泥臭く寄り添えるエンジニアこそ、AIに代替されない「真の価値」を発揮。
- 同社バリュー「Challenge & Support」「Be Proactive」がAI前提時代の武器になる。
コメント（レポート作成者より）
数値（リリース頻度ベースの効果測定）・仕組み（3層ゲート・フック駆動のスキル自動実行）・組織（エヴァンジェリストの評価制度への組み込み）の3面が揃った、AI駆動開発の組織導入事例として非常に完成度の高い記事。「AI生成コード率」や「トークン消費量」ではなくリリース間隔を見る、という指標設計の発想は多くの組織で参考になるはず。