AI ドリブン開発を2か月でチームに定着させた話（SmartHR）— 生産性 +68.9% の内訳¶
作成日: 2026-07-11 出典 / きっかけ: SmartHR Tech Blog「AI 乗り遅れチーフが、AI ドリブン開発を2か月でチームに定着させ、開発生産性を +68.9% まで引き上げた話」（著者: masaru, 2026-07-10） https://tech.smarthr.jp/entry/2026/07/10/161316 関連: ai駆動開発ループ_interview-dev-loop_整理 / ai生産性パラドックス_メトリクス起点の改善ループ_整理 / aiコーディング_依存性とバーンアウト_整理 / deutsche-telekom_openai_ai-native通信
0. 要点（3行）¶
- 「個々人がバラバラに AI を使う」段階から、チームの標準プロセスへ引き上げた 8 週間の実践記録。鍵は 上流工程を Claude Code スキルで型化（PRD→Design Doc→PBI→実装の 3 スキル）し、それをモブ開発と“場づくり”で暗黙知ごと横展開したこと。
- 一度は失敗している。型を雑に本実装へ広げた Week 5 でベロシティ急落。根本原因は 「使い方の暗黙知がチーフ個人にしか無い」。立て直しは技術ではなく 週30分 MTG・Slack チャンネル・スキルの継続改善（分割/オプトイン化） という運用施策。
- 成果は 1スプリント1人あたりのマージ済み PR 数（中央値）が 3.75 → 6.33（+68.9%）。ベロシティを使わなかった理由が秀逸 —「ストーリーポイント＝工数」文化では AI 導入で同じタスクが低ポイント見積りになる（ストーリーポイントのデフレーション）ため、ベロシティは伸びを過小評価してしまう。
1. 誰の・どんな課題か¶
- 対象: 3〜5 人の開発チームを束ねるチーフ。
- 痛み:
- 他社の AI 活用事例を見て焦るが、スケジュールに追われ試す時間がない。
- メンバーが思い思いに AI を使う段階どまり → チーム間で生産性の差が顕在化。
- AI 活用の時間・場・コミュニケーションが不足。
「個人技」を「チームの型」にどう変えるか、が主題。
2. 8週間のロードマップ¶
Week 1-2 ┃ 上流の型作り（PdM＋チーフの2人だけで検証）
┃ └ Claude Code スキル3本を自作
Week 3-4 ┃ チームへ拡張（モブ開発で巻き込む）
┃ └ PoC:「2〜3週間の機能が3時間で動作」
Week 5 ┃ ✗ 挫折（本実装向けに雑展開 → ベロシティ急落）
┃ └ 原因: 使い方の暗黙知がチーフ個人に集中
Week 6-8 ┃ 立て直し（技術でなく“運用・場”の3施策）
┃ └ 週30分MTG / Slackチャンネル / スキル継続改善
2-1. Week 1-2 — 上流工程を Claude Code スキルで型化¶
いきなり全員に配らず、PdM とチーフの 2 人で検証（型が固まるまで少人数＝リスク管理）。作った 3 つの Claude Code スキルで要件から実装までを一本のパイプラインにした:
| スキル | 変換 | 役割 |
|---|---|---|
prd-to-design-doc |
PRD → Design Doc | 要求仕様から設計ドキュメントを起こす |
design-doc-to-pbi |
Design Doc → PBI | 設計をプロダクトバックログアイテムに分解 |
jira-ticket-implementation |
PBI（JIRA チケット）→ 実装 | チケットから実装を進める |
2-2. Week 3-4 — モブ開発でチームへ¶
モブ開発でチーム全体を巻き込みながら展開。PoC の劇的短縮を体験:
「2〜3 週間かかっていた機能が 3 時間で動作」（PoC レベル）
ただし PoC は割り切り: バリデーション・認可は不十分、エッジケースは想定外。一方でメインストリームのユースケースは本実装に近いレベルで作る、というメリハリ。
2-3. Week 5 — 挫折（ここが一番の学び）¶
型を本実装向けに雑に展開したらベロシティが急落。
- 根本原因: 「使い方の暗黙知（プロンプトの間合い・スキルの当て方）がチーフ個人にしか存在しない」。
- スキルという“成果物”は配れても、それを効かせる“行間”は配れていなかった。
2-4. Week 6-8 — 立て直しは「技術」ではなく「場」¶
| 施策 | 内容 | 狙い |
|---|---|---|
| ① 週30分「開発生産性向上 MTG」 | 実 PBI を題材にデモ実演。プロンプト作成→成果物までの全フローを見せる。Notion にマニュアル化 | 暗黙知（行間）を対面デモで移植 |
② Slack #dev__claude活用 |
困りごと共有・知見ストック。チーフが率先して返信 | 質問のハードルを下げ、知見を貯める |
| ③ スキルの継続改善 | FB 蓄積 / ローカル未 push 差分への対応 / 長いスキルを複数に分割 / 配布をオプトイン方式に切替 | スキル自体の使い勝手を磨く |
→ ③の「長いスキルを分割」「オプトイン配布」は、Claude Code スキル運用の実践知として一般化できる（＝全員に全部を押し付けない）。
3. 成果 — なぜ「PR 数」で測ったか¶
| 指標 | AI 活用前 | AI 活用後 | 変化 |
|---|---|---|---|
| 1スプリント・1人あたりマージ済み PR 数（中央値） | 3.75 | 6.33 | +68.9% |
指標選定の勘所（ここが学び）: ベロシティ（消化ストーリーポイント）を使わなかった。理由は 「ストーリーポイント＝工数」という見積り文化があり、AI 導入で同じタスクがより低いポイントで見積もられるようになるから。つまり ストーリーポイントのデフレーションが起き、ベロシティでは生産性向上が打ち消されて見える。so → 実際のアウトプット量に近い PR 数を採った。
教訓: AI 導入の効果測定は、見積り単位（ポイント）ではなく、実アウトプット（PR・マージ）で測れ。工数ベースの指標は AI で単価が変わると壊れる。
4. 技術スタック・参照¶
| 区分 | ツール |
|---|---|
| AI コーディング | Claude Code（スキル運用の中心）、Cursor（メンバー個別利用、.cursor/rules にコーディング規約を記載して応答に反映） |
| ドキュメント/指標 | Notion（マニュアル、指標ダッシュボード化） |
| コミュニケーション | Slack（#dev__claude活用） |
| 開発管理 | JIRA、GitHub |
| 参考プロセス | Amazon の AI-DLC（AI-Driven Development Life Cycle と思われる。要確認） |
5. まとめ — チーフ/EM が“盗める”型¶
| 局面 | この事例の答え |
|---|---|
| 何から始めるか | 上流（PRD→Design Doc→PBI→実装）をスキルで型化。まず少人数で検証してから広げる |
| 横展開の方法 | 成果物（スキル）だけでなく 暗黙知（行間）を対面デモで移す。モブ＋週次 MTG＋Slack |
| つまずきの正体 | 「スキルを配れば普及する」は誤り。属人的な使い方が普及の律速 |
| 効果測定 | 工数ベース（ベロシティ）は AI で壊れる。PR 数など実アウトプットで測る |
| スキル運用 | 長いスキルは分割・配布はオプトイン。ドキュメントは Notion に、質問は Slack に貯める |
| 最終形 | チーフが全部は面倒見きれない → メンバーの自発性に委ねるカルチャー。指標を期初の個人目標・評価制度に接続 |
一言で: AI ドリブン開発の定着はツール導入問題ではなく組織学習問題。「まずやってみる × 場を作る」で、個人技を型 → 暗黙知の移植 → 自発性の順にチームへ流し込む。
注意・留保¶
- 本記事は SmartHR の一次体験記（experience report）。数値（3.75 → 6.33、+68.9%、「3 時間で動作」）はすべて著者チームの自己申告値で、外部検証はされていない。
- 「Amazon の AI-DLC」は記事内の参照。AI-Driven Development Life Cycle を指すと思われるが、正式名は要確認。
- 「+68.9%」は1スプリント1人あたりマージ済み PR 数の中央値の伸びであり、コード品質・不具合率・リードタイム等は本記事の測定対象外。
参考リンク¶
- SmartHR Tech Blog: AI 乗り遅れチーフが、AI ドリブン開発を2か月でチームに定着させ、開発生産性を +68.9% まで引き上げた話 — https://tech.smarthr.jp/entry/2026/07/10/161316
作成: 2026-07-11 ／ 最終更新: 2026-07-11