■ 1. AIファースト開発への転換
- AIの役割の変化:
- 従来のAIツールはエンジニア主体で、コード補完など1行単位の補助として機能
- エージェント型AIはタスクを自ら分解・実行し、エラーを修正しながら実装を進める
- 人間が設計や判断を担い、AIエージェントが実装を担う分担型の開発へ移行しつつある
- ツール配布だけでは不十分:
- ソフトウェア開発には要求からリリースまでの全体プロセスが存在する
- コーディングだけを高速化しても、全体がAI前提でなければリリース速度は上がらない
- 価値を届けるリードタイムも縮まらない
- そのため、AIで解決することを前提にプロセスを組み立てる「AIファースト開発」に踏み込んだ
- 先行導入と展開:
- アジャイル・内製開発主体の開発第3センター約40名で先行スタート
- 当初計画は3ヶ月で3チームに展開し、その後に他チームへ広げる想定
- 現場から早く使いたいという声が相次ぎ、1ヶ月半で8チーム全員へ前倒しで展開
- AIエヴァンジェリストの配置:
- 各チームに配置したエヴァンジェリストが定着を支えた最大の要因
- チームごとにシステム、技術スタック、品質基準が大きく異なる
- 金銭トラブルが許されない厳格なシステムもあれば、早期リリースを優先するプロトタイプ的なものもある
- 一律ルールを押し付けず、各チームの文脈に合わせて導入プロセスをローカライズした
- エヴァンジェリスト業務は正式な業務目標として評価制度に組み込まれている
- 既存業務に追われて推進できないというジレンマを避け、推進に時間を投資できた
■ 2. アウトカムの定義と可視化
- 従来指標の問題:
- コード行数を指標にすると冗長なコードが増える
- ストーリーポイントを追うと見積もりがインフレする
- 数字を達成するための不健全なハックが生まれるリスクがある
- AI関連指標の問題:
- AI生成コードの割合やトークン消費量も本質的ではない
- AIを無駄に回してコストを上げ、重要でないタスクを繰り返すだけでも生産性が高く見えてしまう
- リリースを効果と定義:
- 重要なのは価値が実際にユーザーへデプロイされたこと
- プルリクエストの量ではなく、リリース間隔やサイクルタイムを評価指標とした
- 毎週・毎月どれだけ早いサイクルで顧客に価値を届けられているかを観測する
- 70週間のモニタリング結果:
- 導入前36週間、導入後34週間で比較
- 平均週次リリース数は21件から38件へ増加（+81%）
- 週次リリース数の最低値は4件から17件へ増加
- 不調な週でも約4倍を記録し、スループットの向上と安定化が可視化された
- 観測ツールの内製:
- AIを使った高度な開発ができる組織になっていたため、ツールは自作すればよいと判断
- GitHubのプルリクエスト情報やコミット数、変更動向を抽出・分析する独自ツールを開発
- 感覚ではなく客観的なファクトとしてアウトカムを可観測化している
■ 3. レビューの再設計
- レビューのボトルネック化:
- AIが生成する大量のコードを人間がすべて目視レビューすると時間が足りない
- レビューが詰まればリリースが止まり、AIを使わない方がよいという転倒した結論になる
- 3層の自動品質ゲート:
- 人間が見る前に問題のあるコードを機械的に排除し、レビュー負荷を下げる仕組み
- 第1層はAI自動レビューで、プルリクエスト作成時に改善点を指摘する
- 第2層は静的解析で、SonarQubeにより循環的複雑度や脆弱性、お作法違反を弾く
- 第3層は自動テストで、PlaywrightなどによるUIテストや結合テストでリグレッションを検出する
- 守りのアーキテクチャ:
- 他の箇所を壊していないかというリスクを低減し、人間が安心してレビューできる
- 自動確認をすべて通過したコードだけが人間に届くため、レビュー負担が大幅に軽くなった
- リスクベースのレビューの濃淡:
- AIが作ったものすべてを必ずしもレビューする必要はないという考え方
- リスクの高さに応じてレビューの濃淡をつける方針へシフトした
- 緩めてはならない領域:
- インフラ変更は、S3バケットの誤った公開設定によるデータ漏洩などのリスクがある
- セキュリティ、認証、ロギングも対象となる
- 大きなビジネスロジックや金銭トラブルに関わる領域も対象となる
- これらはAIに加えて人間が徹底的に確認する
- ダブルチェックを省略する領域:
- あるチームでは、ロジックを持たずデザイン崩れが主なリスクとなるフロントエンドを対象とした
- 3層のゲートを通過し作成者が責任を持てば、人間のダブルチェックなしでマージできるルールを試行
- デザインが多少崩れても致命的なリスクは考えにくく、テストで問題なければ重大化しにくい
- やらないことを定義することで、人間が本質的なレビューに集中する余白を生み出している
■ 4. AIへのコンテキスト付与
- 自作スキルの整備:
- AIをチームの作法に合わせて動かすため、約20個の自作スキル・ツールを用意している
- 業務固有の知識やチームの暗黙知をチェックする「ドメイン知識レビュー」
- 要件定義の漏れやすい観点を自動チェックする「要件定義深掘り」
- 決まったフォーマットでプルリクエストを自動作成するスキル
- フックによる自動実行:
- 手動呼び出しに頼ると使い忘れが発生する
- プルリクエスト作成や実装計画完了などのイベントを検知し、スキルを自動実行する仕組みを構築
- 誰が開発を担当しても同水準のAIサポートとチェックがプルリクエスト上で実行される
■ 5. 暗黙知から形式知への転換
- ドキュメント読み込みの限界:
- 既存ドキュメントをAIに読ませるだけでは、日々変化する開発の文脈に追いつかない
- 開発を回す中で暗黙知が自然に形式知化され、AIのナレッジとして蓄積されるループを構築した
- ナレッジベースの内容:
- Claudeのスキルが参照するナレッジとして蓄えている
- 過去のインシデントパターン、類似機能の仕様、アーキテクチャを含む
- これまで言語化されていなかった暗黙のチーム規約も含む
- 2段階の自動レビュー:
- 実装計画の策定時と、実装後のプルリクエストレビュー時にフックで自作レビュースキルを実行する
- ナレッジの自動抽出:
- プルリクエストレビュー時に、コード、テスト結果、開発中のAIとのチャットセッションを解析する
- 未登録の仕様ルールや新たな暗黙知をAI自身に自動抽出させる
- 抽出したナレッジはMarkdownなどの構造化データに自動変換されプールされる
- 次に別のエンジニアが類似領域を開発する際、チェックルールとして自動適用される
- 日常開発がドキュメンテーションになる:
- 人間がwikiにマニュアルを書く作業は不要
- エンジニアがAIと開発セッションを行うこと自体が組織のナレッジ強化に直結している
■ 6. UIレビューの効率化
- プレビュー環境の自動デプロイ:
- プルリクエスト作成時にコード差分からAWS ECS上へ一時的な検証環境を自動デプロイする
- プレビュー用URLがプルリクエストのコメントに自動通知される
- レビュアーはURLを開くだけで最新の挙動を即座に確認できる
- UIレビュー用Chrome拡張:
- 不具合やデザイン崩れを起票するコストを下げるために自作した
- ブラウザ上の画面要素を1クリックで選択し、その場でコメントを記入する
- 要素のセレクタやビューポート情報を含むMarkdownが自動生成されコピーできる
- プルリクエストのコメント欄に貼り付けるだけで起票が完了し、指摘作成の手間を大幅に削減した
■ 7. AI前提で生じた新たな課題
- 理解・認知負債:
- AIが瞬時にコードを生成するため、自分で書いていない分コードやシステム全体への理解が低下する
- 保守工数の増大:
- 開発速度の向上で生成コード量が増え、保守すべきコードも増える
- 若手育成の機会損失:
- AIが先に正解を出すため、若手が試行錯誤を通じて地力をつける機会が奪われる
- 認知負債への対策:
- 3層のゲート通過を前提に、プルリクエスト段階でのコード目視レビューを必須としない
- 代わりにマージ後の検証・ステージング環境でバグを徹底的に潰し切る
- 毎週チーム全員で最新機能を触り倒す「モンキーテスト会」を開催している
- 画面を動かしながら議論することで、コードを読まなかった分のシステム理解を補完する
- 若手育成への対策:
- ジュニアエンジニアが、AI生成コードをなぜ正しいと思うかをシニアに説明する機会を設けている
■ 8. これからのエンジニア像
- 価値の源泉の移行:
- コードを書くスキルの希少価値は薄れていかざるを得ない
- 何が正しいかを正しく判断する能力が重要になる
- ユーザーを喜ばせビジネスにインパクトを出す方法を考え抜くプロダクト志向が重要になる
- バリューの有用性:
- 「Challenge & Support」や「Be Proactive」という行動指針がAI駆動開発で武器になる
- AIの不確実な挙動を恐れず挑戦し、新しいプロセスを自らデザインできる人が主役になる
- チームのために主体的に動ける人がAI前提時代の中心となる
- AIに代替されない価値:
- 実装という手段に固執しないことが重要
- ドメイン知識や顧客の現実の課題に泥臭く寄り添えるエンジニアが真の価値を発揮する
- 今後の展望:
- AI駆動開発はまだ始まったばかり
- 開発プロセスだけでなく組織全体をAIネイティブに変革するロードマップの次段階へ進む