ADWAYS DEEE 技術改善Div（ディビジョン）でリードアプリケーションエンジニアをやっている山本です。
4月になりました。新年度が始まり、新しい目標を立てている方も多いのではないでしょうか。
さて、今回は私が所属するクラウドチームで2025/9/16〜2025/12/29の約15週間、エージェント型のコーディングAIを活用してチームの生産性を3倍にした取り組みについてご紹介します。
具体的な施策の紹介に加えて、目標に向けてチームをどうマネジメントしたかという観点もお伝えできればと思います。
前提
本記事で扱う「生産性」は、広木大地さん（ @hiroki_daichi ）が執筆された開発生産性の記事「開発生産性について議論する前に知っておきたいこと」における「レベル1：仕事量の生産性」を指します。
クラウドチームについて
私が所属するクラウドチームは自社プロダクトのインフラ領域を担当するチームです。
TerraformやAnsibleを用いたインフラの構築・運用を中心に、クラウド移行プロジェクトなどを推進しています。
メンバーの数は私を含む3人です。
生産性2.5倍の目標
2025年の下半期、Div全体の技術戦略として「AI活用による生産性の向上」が掲げられました。
まずは3Qにシニアエンジニア層が個人の生産性を3倍にする挑戦をし、AIでどこまで生産性が伸びるかの感触を掴みました。
その上で4Qからは各チームの生産性を2.5倍にすることがKR（Key Result）として設定されました。
生産性の定義
生産性2.5倍と言っても、具体的に何を2.5倍にするのかを明確にしておく必要があります。
クラウドチームはインフラ領域を担当しているため、調査や設計に時間を使う場面も多く、単純にコード量やデプロイ回数だけでは実態を反映しづらい面があります。
そこで、チームの活動から生まれるアウトプットを洗い出し、何を指標として追うかを整理しました。
この整理を踏まえ、追う指標を以下の2つに定めました。
| 指標 | 何を測っているか |
|---|---|
| マージ済みPR数 | チームの開発アウトプット |
| 展開数 | 組織に対してどれだけ価値を還元できたか |
ここで展開数とは、チームの活動を通じて組織に還元できた知見の数です。
例えば、チーム内で開発したClaude Codeのスキルをチーム外に展開した場合に1件カウントする、といった具合です。
PR数だけではチーム内の開発量しか測れないため、組織への価値還元を測る指標として加えました。
比較基準はいずれもチームの過去実績の平均値とし、それを2.5倍した値を目標にしました。
具体的な目標値と最終実績は以下の通りです。
| 指標 | 比較基準 (1倍) | 目標 (2.5倍) | 最終実績 |
|---|---|---|---|
| マージ済みPR数 | 過去3四半期平均 43.2件 | 108件 | 128件（2.96倍） |
| 展開数 | 上半期平均 9件 | 22.5件 | 23件（2.55倍） |
※ 計測期間は2025/9/16〜2025/12/29の約15週間
2.5倍に向けた取り組み
まずはチーム内でブレストを実施し、2.5倍に向けて何をすべきかの意見を出し合いました。
そこで大きな方向性として挙がったのは「AIにどんどんPRを作ってもらう」という方針です。
また、そのためにはAIが取り組みやすい形にタスクを分解・整理する仕組みが必要だという認識がチームで揃いました。
この認識をベースに以下の取り組みを進めていきました。
1. AIのためのタスク分解
まず考えたのは「AIが取り組みやすいタスク」とは何かということです。私たちの経験上、AIがうまく機能するタスクには2つの特徴があります。
- ゴールが明確であること
- 何をどのように変更するかが分かっている状態。「いい感じに改善して」では的外れな変更が返ってきたり、意図と違う方向に進んでしまいます。
- 関心ごとが少ないこと
- 複数の関心ごとが混ざったタスクをAIに渡すと、それぞれの変更の精度が落ちます。関心ごとを絞れば変更量も小さく収まり、AIがうまく機能しやすくなります。
この基準をもとに、週1回のリファインメントで既存のタスクをAIが取り組みやすい粒度まで分解していきました。
分解の作業自体もAI（Claude Code）と壁打ちしながら進めていき、「この粒度で渡して大丈夫か」「もっと分けた方が良いか」といった判断をAIと相談しながら行いました。
分解したタスクには「何をどのように変更するか」を明記し、AIが迷わず着手できる状態にしました。
こうして切り出したタスクはAIに安心して任せることができます。
例えば、タスクの内容をDevinに渡すだけでコード変更からPR作成まで完結してくれるため、人間がやることは「タスクを渡す」と「PRをレビューする」だけです。
2. タスクの生成すらAIに任せる
1つ目の取り組みでは、人間がAIと壁打ちしながら既存のタスクを分解していきました。
次に考えたのは、タスクの生成自体もAIに任せるというアイデアです。
そこで、Claude Codeのスキルとして /terraform-guideline-issue を開発しました。
このスキルは、Terraformのコードを組織で定めたガイドラインに照らし合わせてチェックし、違反箇所をGitHub Issueとして自動起票します。
このスキルを実行するだけで、AIが取り組みやすい粒度のIssueが次々と生成されます。
そして、そのIssueをDevinに渡せばコード変更からPR作成まで完結します。こうして、タスクの生成から消化までをAIが一気通貫で回すパイプラインができました。
なお、ここでClaude CodeとDevinの2つを使っているのは、当時はDevinの方がIssueを渡してからPR作成まで放置できる運用が確立しやすかったためです。
Claude Codeでもタスクを自律的に完結させることは可能ですが、permissionsの細かい設定が必要で、権限を与えすぎると意図しない動作をするかもしれないという懸念がありました。
そのため、ゴールが明確なタスクの消化はDevinに、対話しながら進める必要がある複雑なタスクはClaude Codeに、という使い分けをしていました。
3. レビュースルーの導入
AIがPRを量産できるようになると、今度はレビューが追いつかなくなってきました。全てのPRに他者レビューを挟んでいたため、PR数が増えるほどレビュー待ちが溜まります。
PRを作る速度が上がったことで、レビューがボトルネックになっていたのです。
この問題を解消するきっかけになったのが、Divのテクニカルマネージャー（テックリードの複数チームを見る人たち）が策定した「AIが書いたコードの他者レビューに関するガイドライン」です。
このガイドラインでは、職位・リスクレベル・変更規模の3軸に基づいて、一定条件下でセルフレビューのみでPRのマージを許容する基準が定められていました。
ただし、IaC（Terraform/Ansible）に関しては方針が未整備でした。IaCは単純なユニットテストによる品質担保が難しく、Plan結果やDry-Run結果をもとに判断する必要があるためです。
そこで、私からテクニカルマネージャーにIaCのレビュースルー基準について相談を持ちかけました。テクニカルマネージャーとクラウドチームで議論を重ね、以下の基準を策定しました。
# IaCのレビュースルー基準（一部抜粋） ## 原則セルフレビューで問題ない条件 - Terraform: Plan差分がない - Ansible: Dry-Runで変更がない 以下は上記に該当しない場合の判断基準となります。 ## セルフレビューを許容するかどうかの判断に用いる条件 - Lintが通っている - プラン結果を確認して、**内容を自信をもって理解している**と宣言できる - Terraform - **replace/destroyが発生しない** - update - 対象のリスク観点 - 対象リソースが、ビジネス上重要な機能に関わっていないと確信が持てている時のみ - 不安だったり確信が持てないならレビューする - add - 既存の機能に影響しないリソースの追加である
これにより、低リスクなIaCのPRをセルフレビューのみでマージできるようになり、PR消化のスピードが一段と上がりました。
一番の成功要因
ここまで紹介した取り組みの甲斐もあって、最終的に目標の2.5倍を大きく上回る生産性3倍を達成できました。
ただし、これらの施策は最初から全て計画していたわけではありません。
毎週数値を確認し、ふりかえって、改善する。このサイクルを回し続けたことで必要な施策が見えてきたのだと思っています。
進捗を毎週追える仕組み
4Qの開始に合わせて、生産性の進捗を詳細に追える仕組みを構築しました。
「2.5倍の目標に対して今どのくらいか」「理想のペースから遅れていないか」などを一目で把握したかったため、マージ済みPR数を集計して達成率や理想ペースとの差分を算出するスクリプトを自作しました。
これを毎週火曜日に実行し、結果をNotionのデータベースに記録して達成率を可視化していました。
加えて、Notionの各週ページに「感想・改善点」セクションを設け、メンバー全員がその週の所感を記載する運用にしました。
所感では「先週と比べてなぜ増えたか/減ったか」「来週どうするか」を毎週言語化してもらいました。この可視化→ふりかえり→改善のサイクルが取り組みの土台になっていました。
週次サイクルが効いた場面
マージ済みPR数は比較的順調に推移していましたが、展開数は11月末時点でも2.5倍達成の見通しが立っていませんでした。
週次のふりかえりでもたびたび「展開数のネタが足りない」という課題が挙がっていましたが、なかなか具体的な打ち手に落とせずにいました。
このままでは間に合わないと判断し、12月初旬に展開数に特化したブレストを実施しました。
チームで展開可能なTODOを洗い出し、「あとはこのリストを消化すれば達成」というゴールが見える状態を作りました。
結果、12月後半に展開数も2.5倍を達成できました。
週次で課題を認識し続けていたからこそ、「このままでは間に合わない」という判断を適切なタイミングで下せたのだと思います。
ふりかえり
よかった点
早期の方針決定
4Qの開始時にチームでブレストを実施し、早い段階で方針を固められたのは大きかったです。
方針が明確だったからこそ、タスク分解やスキル開発といった具体的なアクションにすぐ移ることができました。
週次サイクルによる素早い軌道修正
週次の可視化→ふりかえり→改善のサイクルを15週間回し続けたことが効きました。
数値が落ちた週はすぐに原因を分析し、展開数が伸び悩んだときにはブレストを追加で実施しました。この素早い軌道修正がなければ、最終的な達成は難しかったと思います。
チーム内の改善が組織に波及した
取り組みの中で開発したClaude Codeのスキルは、プラグインとして社内のGitHubリポジトリに公開しました。各メンバーの環境で有効化するだけで同じスキルが使える仕組みです。
新しいスキルを追加するたびに組織に向けて発信していったところ、他チームも触発されてプラグインを開発し始めるチームが出てきました。
自分たちの取り組みが組織に波及していくのは純粋に嬉しかったです。
Claude Codeプラグインマーケットプレイスの記事はこちらをご覧ください。
反省点
開発フロー自体の改善には踏み込めなかった
今回の取り組みは、既存の開発フローの中にある作業をAIに置き換える改善（BPO）が中心でした。
例えば、人間がやっていたコード変更やPR作成をAIに任せる、レビューの基準を整理してマージを速くする、といった具合です。
しかし、AIがいる前提で開発フローそのものを再設計する（BPR）という視点にはあまり踏み込めていません。
最近ではAWSが提唱するAI-DLC（AI-Driven Development Life Cycle）など、開発フローの再設計に取り組む動きも広がっています。
そもそもこのフローは必要なのか、AIを前提にするならもっと良いやり方があるのではないか。そうした問い直しが次のステップだと考えています。
指標の限界
調査や設計が中心のフェーズではPR数が伸びないという指標の限界も感じました。
実際、11月に調査タスクが続いた週はPR数が大きく落ち込みましたが、チームとして価値のある仕事をしていなかったわけではありません。
PR数は分かりやすく追いやすい反面、コードに表れない仕事の価値を捉えられないため、今後は別の指標も組み合わせていく必要があると感じています。
おわりに
AIの活用によって「レベル1：仕事量の生産性」は向上し、2.5倍の目標を達成しました。
しかし、私たちの取り組みはここで終わりではありません。次は「レベル2：期待付加価値の生産性」を追うフェーズに移っています。
プロジェクトの消化数や価値提供数を指標に、現在は生産性10倍を目標に掲げています。
10倍は単にPRを積み上げるだけでは到達できない領域だと思います。プロジェクトの進め方を大きく見直したり、サイクルタイムを大幅に短縮したりと、これまでとは異なるアプローチが求められます。
しかし、この3か月で確立した「可視化して、ふりかえって、改善する」というサイクルは目標のスケールが変わっても活きると信じています。
生産性向上の目標に取り組んでいる方の参考になれば幸いです。最後まで読んでいただき、ありがとうございました。
