可視化から始めたAI駆動開発_ochi_ver1.01 / AI-Driven Development Starting with Visualization_ver1.01

弥生株式会社　もくテク
AI駆動開発を組織に根づかせるには ──CTO・推進者が語る取り組んできたこと・見えてきたもの
https://mokuteku.connpass.com/event/404798/

Transcript

1. 「AIを使っている」だけでは分からない ──可視化から始めた AI駆動開発 122件のアンケートと現場インタビューから見えた「利用率」の先の構造的課題 プラットフォーム開発本部 プラットフォームエンジニアリング部 越智 峻介
2. AIDD 推進レポート 01 本日のアジェンダと発表スコープ 登壇者プロフィール & アジェンダ 本日の発表スコープ ・登壇者: 越智 峻介 （プラットフォームエンジニアリング部/ AIDD推進 / リードエンジニ ア） ⭕ 本日お話しすること： ・何から測り始め、どうやって問いを分解したか ・利用率だけでは見えない「委任」の壁の正体 ・可視化を踏まえた推進チームの具体的打ち手 アジェンダ： 1. 可視化のきっかけとアプローチ（指標の分解） 2. 定量・定性データで分かったリアルなギャップ 3. 現場の2つの壁と、推進側の具体的アクション ❌ 本日お話ししないこと： ・LLM基盤や個別ツールの詳細アーキテクチャ比較 ・「AIで開発生産性が◯倍になった」という極端な成功談 要点： 可視化のプロセスとそこから得た学びを客観的に共有します。
3. AIDD 推進レポート 02 ライセンスは配った。「で、みんな使えてる？」 1. 利用の広がり 2. 実態の不透明さ 3. 評価軸の不在 ・Cursor/ Devin /Copilotライセンスを 広く配布 ・利用ログや請求金額から「利用されてい る」ことは確認できた ・社内でのAI関心度も高まりを見せてい た ・チームとしてどう使われているか不明 ・単なるコード補完にとどまっているの か、業務が変わっているのか分からない ・成果が出ているチームとそうでないチー ムの差が見えない ・「開発生産性」という言葉の抽象度が高 すぎる ・投資対効果（ROI）をどう経営や現場に 説明すべきか迷う ・どこに次の手を打つべきかの判断基準 がない 要点： 導入初期の壁は「使われているか」ではなく「どう使われ、何がボトルネックか見えないこと」でした。
4. AIDD 推進レポート 03 「使っている（利用率）」はゴールではなくスタート 従来の捉え方（利用率メイン） 可視化を深めた捉え方（本発表） ・「アクティブユーザー率 90% 突破！」で満足してしまうと ・利用率が高い ＝ AI活用が成功しているとみなす ・利用率は「前提条件（スタート地点）」に過ぎない ・見るべきは「業務のどの部分を、どの深さでAIに任せられているか」 ⚠ 発生した課題： ・「で、開発は早くなったの？」という問いに答えられない ・次に予算やサポートをどこへ集中すべきか分からない 💡 得られる価値： ・チーム間の活用差やボトルネック（ルール・コンテキスト等）が浮き彫 りになる ・根拠のある具体的支援策（ガイドライン・環境整備）が打てる 要点： 利用率だけでは次の一手を打つには不十分、可視化を通じて「解くべき課題」を発見することが可視化の目的です。
5. AIDD 推進レポート 04 成果を急がず、測る順序を決めた（計測ロードマップ） Step 1 Step 2 Step 3 Step 4 AI利用 活動指標 開発成果 事業成果 ツール利用量 アクティブ率 トークン消費量 Pull Request (PR) 数 コミット数・変更行数 作業セッション数 リードタイム（Four Keys） デプロイ頻度 障害発生率 機能リリース速度 ROI（投資対効果） 顧客価値創出 ★ 現在の計測焦点 要点： いきなりStep 4の事業成果を目指さず、取得しやすい「 Step1 ~ Step 2」から分解して計測を開始しました。
6. AIDD 推進レポート 05 今どこまで測れているか 可視化できていること（現在地） まだできていないこと（今後の課題） ✅ チーム別・個人別のAI利用量（トークン量・リクエスト数・コスト） ✅ チームごとのPull Request (PR) 作成数および推移 ✅ 122名のエンジニアアンケートによる定性的実感値 ✅ 14チームのリードインタビューによる詳細な質的定性情報 ⏳ ツール横断の自動追跡計測基盤（OTel等による統合ダッシュボー ド） ⏳ チーム全体の開発リードタイム（Four Keys）とのリアルタイム連携 ⏳ AI利用と「事業成果（業績・売上）」の直接的な因果関係証明 要点： 活動指標までは追えているものの、事業成果への影響はまだ仮説検証の段階です。
7. AIDD 推進レポート 06 仮説：AI利用が進めば活動指標（ PR数）にも変化が出る 要点： AI導入後、全社的にPR数は増加傾向にある
8. AIDD 推進レポート 07 チーム別の PR数比較 📊 チーム別 AI活用度、 PR数 分析のポイント ・全社平均（+62%）の内訳を分解すると、チーム ごとに大きな開きが存在した ・AI利用が少なく、PR数もそこまで変わらない チームがいる一方、突出して高いチームも出現 ・なだらかな変化ではなく、一部のチームが大きく 牽引する 要点： チームごとに活用度と PR数は顕著に差が発生
9. AIDD 推進レポート 08 AI利用が進めば活動指標（ PR数）にも変化が出る 全社平均 PR数の変化 仮説の検証で見えたこと 導入前: 6.90 件 / 月・人 ↓ 導入後: 11.19 件 / 月・人 1. AI活用度が高いチームにPR数の伸び幅が大きい傾向が見られる 全社で平均約 62% のPR数増加が確認された。 4. (仮説)活動量の差は開発成果にも繋がってくるのでは？ 2. 全社一律の伸びではなく、チームごとの「格差」が存在する 3. AI活用の差で活動量は数倍 ~ 数十倍の差が発生する 要点： 重要なのは「チームごとの差」。次の一手としてチームごとの格差を埋める必要がある
10. AIDD 推進レポート 09 限界の明言：活動量（ PR数）だけでは「理由」は語れない 定量データ（ PR数・トークン量）で分かること 定性データ（アンケート・ヒアリング）の必要性 ⭕ 「どのチームがどれくらい使っているか」というFact ⭕ 「PR数が増えているか減っているか」という結果の推移 ⭕ チームごとの数値的な相対比較 💡 定量データは「問いを発見するためのヒント」に過ぎない ❌ 分からないこと： ・なぜそのチームはPR数が増えたのか（理由） ・なぜ別のチームは伸び悩んでいるのか（阻害要因） ・数値の背景にある「現場の困りごと」を探るため、122名のアンケート と14チームのインタビューを実施 ・定性調査を重ねて初めて、真のボトルネックが見えてきた 要点： ダッシュボードの数字だけを追うのではなく、定性調査を組み合わせて「理由」に迫る必要があります。
11. AIDD 推進レポート 10 「利用」と「委任」の大きなギャップ 日常的AI利用率 90.2% 業務効率への貢献実感 81.2% 日常的な「タスク委任」率 18.9% 📊 AIへの委任経験の割合（アンケート Q14より） 【アンケート内訳表現】 🟩 日常的に委任している（18.9%） ｜ 🟦 何度か試した・試行段階（35.2%） ｜ 🟧 難しさを感じている・未着手（46.0%） 💡 考察: 9割が使い、8割が効果を実感しているにもかかわらず、「AIにタスクを任せる（委任）」レベルに達しているのはわずか2割。約8割のエンジニアが「利 用」と「委任」の間のギャップにとどまっています。 ※ ヒアリング調査により、活動量の多いチームほど設計・実装・テストなどの多様な工程で AIを活用し、タスク単位で業務を委任していることが分かりまし た。 要点： 単なる「利用率」の陰に隠れていた、「委任率 18.9%」という構造的ギャップが可視化されました。
12. AIDD 推進レポート 11 AI委任できない理由は「個人スキル」ではなく「環境」 要因1: ツール予算の制約（ 32.8%） 要因2: ノウハウ・プロンプト（ 23.0%） 要因3: コンテキスト・構造（ 21.3%） ・上位モデル（Claude Opus等）の利用 枠・予算の不足 ・社内で使えるMCPや拡張機能のルー ルが不明確 ・ツール選定・申請の手続きが複雑 ・どのようなタスクを委任できるかのイ メージが湧かない ・抽象度の高い指示の出し方が分からな い ・成功事例・プロンプトが他チームと共有 されていない ・既存コードが巨大でAIに理解させづら い ・仕様書やドキュメント（README/ADR） が未整備 ・AI向けのコンテキスト整備（ハーネス） がない 要点： 「エンジニアのスキル」の問題ではなく、社内のルール・予算・コンテキストという「環境」が原因でした。
13. AIDD 推進レポート 12 現場の2つの段階差（ボトルネックの構造） フェーズ 1：ルール・予算の壁（手前で止まる多数派） フェーズ 2：コンテキスト・ハーネスの壁 【現場のリアルな悩み】 ・「MCPや外部ツールを使っていいセキュリティ基準が分からない」 ・「Opusなどの上位モデルを使いたいが、予算上限が気になって躊 躇する」 ・「日々の開発に追われ、AI活用を模索する時間が確保できない」 ・従来の仕様書、業務フローがAI前提になっていない為に前段を整 える必要がある 【現場のリアルな悩み】 ・「タスクを任せても、想定外の変更をされて修正レビューの手間が増 える」 ・「コードベースの文脈（コンテキスト）を伝えるのが難しく、指示文の作 成に時間がかかる」 ・「AI向けのドキュメント（README等）が整備されていない」 👉 状態: AI委任を試す以前の、制度・環境面でのストッパーが発生 👉 状態: 技術的・運用上のコンテキスト設計（ハーネス）が必要な段 階 要点： チームによって直面している壁が異なるため、一律の施策ではなく段階に応じた支援が必要。
14. AIDD 推進レポート 13 可視化を、次の具体的な打ち手につなげる 可視化で見えた課題（現場の壁） 推進チームの具体的打ち手（アクション） モデル選定・利用可否で悩む モデル選定フローチャート & 明確なガイドライン整備 使えるMCPのルールが曖昧 セキュリティ部と連携した「MCPホワイトリスト」策定 予算上限・コストの懸念 Cursor/Devin等の年間契約化 & 利用枠の柔軟運用 業務で触る時間が取れない ハンズオン勉強会の開催 コンテキスト渡し・レビュー負担 ゴールデンパス（標準コンテキスト設計書）の提供 要点： 可視化でボトルネックが特定されたことで、推進側が具体的に何を解消すべきかが明確になりました。
15. AIDD 推進レポート 14 まだ整備中の部分・未着手の部分 🟡 現在進行形で整備中の部分 🔴 まだ未着手・今後の検討課題 1. OTel（OpenTelemetry）等を活用した、ツール横断の計測自動 化基盤 1. 「事業成果（売上・顧客価値）」との定量的な相関の証明 2. 開発成果指標（Four Keys：リードタイム・デプロイ頻度）の計測自 動連携 3. 全社横断のゴールデンパスの策定、横展開 2. 非エンジニア職種（プロダクトマネージャー・QA等）へのAI駆動開 発の拡張 3. AI主導開発時代における人事評価・エンジニアスキルの再定義 要点： 課題に向き合いながら一歩ずつ進めている段階です。
16. 本日のまとめ：人間主導から、 AI主軸の開発体系へ 1. 可視化は手段、目的は「構造的課題の発見」 活動指標や定性調査からボトルネックを見つけ出す。 2. 「利用率 90.2%」の先にある「委任率 18.9%」のギャップを埋める 個人、チームに閉じず、全社的な「環境整備、ノウハウ化」を推進する。 3. HITL（Human-in-the-Loop）から HOTL（Human-on-the-Loop）へ 人間が指示してAIが手伝う段階から、AIが駆動し人間が監督・伴走する開発体系への移行 を目指します。 ご清聴ありがとうございました。