AIで組織を加速させる勘所

お客様社内でのプライベート講演の資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. AIで組織を加速させる勘所 2026/10/8 株式会社アトラクタ 吉羽 龍太郎 (@ryuzee)
2. 自己紹介 吉羽龍太郎 / Ryutaro YOSHIBA / ryuzee ▸ 株式会社アトラクタCTO /アジャイルコーチ / 翻訳者 ▸ Scrum Alliance 認定スクラムトレーナー （CST） 認定チームコーチ (CTC) ▸ Microsoft MVP （DevOps） ▸ X（Twitter）: @ryuzee ブログ: https://www.ryuzee.com/ 2
3. 自己紹介 最新書籍紹介（買ってください!!） 3
4. AIで組織を加速させる勘所 今日のテーマ ▸ 最近よく相談されること ▸ AIで生まれた時間をどう価値創出につなげるべきか ▸ AIの効果を最大化するために、組織や意思決定はどう変わるべきか ▸ 価値や生産性をどう測るのか。AI時代に技術者は何を担うのか ▸ これらはチーム単独でも重要な話だが、組織全体にまたがる話でもある ▸ ということで、ここでは主に組織全体に焦点を当てる 4
5. AIで組織を加速させる勘所 5 大事なことは最初に。 6つの勘所 勘所1 勘所2 勘所3 部分ではなく流れを見る 判断を仕事の近くに寄せる 検証のコストを下げる 個人の作業ではなく、アイデアが顧 客に届くまでの流れを速くする 判断の所在を役職ではなく影響範 囲で決める 作るコストが下がった分、確認や検 証のコストがボトルネックになる 勘所4 勘所5 勘所6 流れに沿ってチームを組む アウトカムで測る 時間を学習と余裕に使う 小さく、専任で、価値を届けるのに 必要な人がそろったチームにする 作った量ではなく、作ったものが起 こした変化を見る 生まれた時間をもっと作ることで埋 めない ■ 1〜4: 時間を生む ■ 5〜6: 時間を価値に変える
6. AIで個人が速くなると 組織も速くなるのか？
7. AIで組織を加速させる勘所 7 そもそも体感速度が正しいとは限らない ▸ METR（Model Evaluation and Threat Research、メーター）のランダム化比較試験（2025年2〜6月） ▸ 経験豊富なOSS開発者16人が、自分のリポジトリの実際のタスク246件に取り組んだ ▸ 利用ツールはCursor ▸ AIを使ったときのほうが、完了までの時間が19%長くなった ▸ 本人たちの認識は逆だった ▸ 事前の予想は24%速くなる。終わった後も20%速くなったと感じていた ▸ 条件の限られた研究なので、これだけで「AIは遅い」とは言えない ▸ ただし、体感で効果を判断するのは危険。計測しないとわからない 出典: METR "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"（2025）
8. AIで組織を加速させる勘所 AIの効果を測ること自体が難しくなってきた ▸ METR（メーター）のランダム化比較試験の第2弾（2025年8月〜） ▸ 規模を拡大し、57人（前回の16人含む）、143リポジトリ、800以上のタスクで検証 ▸ 利用ツールはClaude Codeなど ▸ AIなしでは仕事をしたくない人が増え、実験への参加、継続が難しくなった ▸ エージェントを並列に動かすようになり、「あるタスクに何分かかったか」を測りにくくなった ▸ 暫定結果としては、第1弾から継続した10人では約18%高速化し、新規参加者では約4%高速化 ▸ METRは、「現在のAIによる生産性向上率を信頼できる形では推定できない」としている 8
9. AIで組織を加速させる勘所 では、組織全体は速くなったのか ▸ DORA 2024 ▸ AIの導入が25%増えると、デリバリーのスループットは1.5%、安定性は7.2%低下すると推定 ▸ DORA 2025（State of AI-assisted Software Development） ▸ 開発者のAI利用率は約90%。スループットとの関係はプラスに転じた ▸ 一方で、デリバリーの不安定さとの関係は続いている ▸ （注意）DORAの計測範囲はコミットから本番リリースまで。企画や承認の待ちは含まない ▸ コードの構造にも変化が出ている（GitClear、2026） ▸ 重複したコードのブロックが増え、リファクタリングで移動されるコードが減った ▸ リリースされる量は増え始めたが不安定。アイデアが顧客に届くまでが縮んだかはわからない 出典: DORA "Accelerate State of DevOps Report 2024" / "State of AI-assisted Software Development 2025" / GitClear（2026） 9
10. AIで組織を加速させる勘所 AIの主な役割は増幅器である。パフォーマンス の高い組織の強みを拡大し、課題を抱える組織 の機能不全を悪化させる State of AI-assisted Software Development 2025（DORA）
11. AIで組織を加速させる勘所 11 アイデアが顧客に届くまでの中で、AIが直接的に速くするのは一部 企画 ■ AIが直接速くする部分 承認待ち ■ その他の作業 要求整理 ■ 待ち 調整待ち 実装 レビュー待ち テスト リリース判定待ち ※ 比率はイメージ ▸ AIが直接的に速くするのは、主に手を動かす部分 ▸ 調査やテスト、ドキュメントにも効くが、中心は実装 ▸ リードタイムの多くは「待ち」（特に大企業ほど） ▸ 根回し、お伺い、「ご説明」、承認待ち、レビュー待ち、他部署待ち、環境待ち、リリース待ち…… ▸ 実装が半分になっても、リードタイムはあまり縮まない可能性も リリース
12. AIで組織を加速させる勘所 ボトルネックで失った1時間は、システム全体の1時 間の損失になる。一方、ボトルネック以外で1時間短 縮しても、全体が速くなるとは限らない。 制約理論 （Theory of Constraints） の考え方
13. AIで組織を加速させる勘所 実装が速くなると、ボトルネックは別の場所に移る ▸ 実装の前後に仕事が溜まりはじめる ▸ レビュー待ちのプルリクエストが積み上がる ▸ テストと検証が追いつかない ▸ 何を作るか、どの順番で作るかを決める側が追いつかない ▸ AIの生成量に人間の確認や検証が追いつかない ▸ 確認や検証を省略すると、品質の問題が後工程と本番環境で顕在化する ▸ ただし、新しく生まれた問題ではなく、隠れていたものが見えるようになっただけ 13
14. AIで組織を加速させる勘所 規模の大きな組織で、特にリードタイムに影響があるもの ▸ 承認の階層が深い ▸ 決裁、稟議、リリース判定会議など。1日で作れるのに承認で数週間かかる ▸ 仕事が部門で分かれている ▸ 企画、開発、品質保証、運用が別組織。引き継ぎのたびに待ちと資料作成が発生する ▸ 外部委託と受発注の境界 ▸ 契約と検収の単位でしか物事が動かない ▸ ルールと規程 ▸ セキュリティ審査、ツールの利用制限、品質基準。存在理由はあるがAIを前提としていないときのもの ▸ 個人やチームのAI活用だけでは、この構造は変わらない 14
15. 組織の構造が速度の上限を決める 個人が速くなっても、この上限は上がらない
16. AIの効果を組織の速度につなげるには 何を変えればよいのか
17. AIで組織を加速させる勘所 【勘所1】 部分ではなく流れを見る ▸ 最適化する対象は、アイデアが顧客に届くまでの流れ ▸ そのために、まず流れを見えるようにする ▸ バリューストリームマップで、作業している時間と待っている時間を分けて書き出す ▸ リードタイム、待ち時間、仕掛かり中の仕事の量を測る ▸ ボトルネックを見つけて、そこに手を入れる ▸ ボトルネック以外にAIを入れても、仕掛かりが増えるだけ ▸ 「AIでどれだけコードを書いたか」を追っても、流れは見えない ▸ 生成した行数や利用率などの活動量の数字では、成果はわからない 17
18. AIで組織を加速させる勘所 始めるよりも終わらせる ▸ 流れを速くする確実な方法は、同時に抱える仕事を減らすこと ▸ 仕掛かりが多いほど、1つ1つが終わるまでの時間は長くなる（リトルの法則） ▸ AIで着手が簡単になると、仕掛かりは増えやすい ▸ エージェントを並列に走らせて、たくさん同時に作る ▸ 検証とレビューが溜まって、結局どれも終わらない ▸ 着手より完了を優先する ▸ 始めたものを終わらせてから、次を始める ▸ 仕掛かりの上限（WIP制限）を決めて守る 出典：『カンバン仕事術』（マーカス・ハマーベルグ、ヨアキム・サンデン、2016、オライリー・ジャパン） 18
19. AIで組織を加速させる勘所 【勘所2】 判断を仕事の近くに寄せる ▸ 実装が速くなると、判断の遅さが目立つようになる ▸ （例） 1日で作れるものの承認に2週間かかる ▸ 判断する場所が遠いほど、判断の材料は古くなる ▸ 上に上がるあいだに情報が要約されて、そのあいだに状況が変わっていく ▸ 状況がよく見えているのは、実際に仕事をしている人たち ▸ 現場で決められることは現場で決める ▸ ただし、全部を現場に任せるという話ではない（後述） 19
20. AIで組織を加速させる勘所 20 判断の所在を影響範囲で決める（役職で決めない） 判断の例 影響範囲 決める人 実装の方法、リファクタリング、ツールの使い方 チームの中 チーム 機能の仕様、優先順位の入れ替え プロダクトの中 プロダクトオーナーとチーム チーム間のAPI、担当範囲の変更 複数のチーム 関係するチーム間の合意 大きな投資、組織構造、外部との契約 組織全体や社外 マネジメント（現場からの提案を受 けて） ▸ 誰が決めるかは影響範囲で、どれだけ時間をかけるかは戻しやすさで決める ▸ 基準を先に決めて共有しておけば、都度の承認は不要になる
21. AIで組織を加速させる勘所 マネジメントの仕事が変わる ▸ 判断を現場に寄せても、マネジメントの仕事はなくならない。仕事の中身が変わる ▸ 目的と制約をはっきり伝える ▸ 何のためにやるのか。越えてはいけない線はどこか ▸ 判断の基準を先に決めて、共有しておく ▸ どこまでを現場で完結し、どこからが要相談か（その場の気分で変えない。いちばん嫌われる） ▸ 流れを止めているものを取り除く ▸ 部門間の調整、規程の見直し、予算の付け方。現場では変えられないものこそマネジメントの仕事 ▸ 「細かく承認する」から「判断できる状態をつくる」へ ▸ AIでたくさん作れるようになるほど、承認で品質を守るやり方では追いつけなくなる 21
22. AIで組織を加速させる勘所 【勘所3】 検証のコストを下げる ▸ 作るコストが下がると、相対的に高くなるのは確認、検証のコスト ▸ 正しく動くか、要求を満たしているか、ほかを壊していないか ▸ 検証を人間の目に頼っていると、そこが新しいボトルネックになる ▸ レビューの量が増えるほど、レビューは形だけになる ▸ 機械で検証する範囲を広げる ▸ テストの自動化、CI/CD、静的解析、アーキテクチャのルールの自動チェック ▸ 越えてはいけない線を越えたら、ビルドが落ちる状態にする ▸ 人間は、機械では検証できないことの判断に集中する 22
23. AIで組織を加速させる勘所 ドキュメントは、検証コストを下げるための投資 ▸ AIに渡す情報の質が、出てくるものの質を決める ▸ 曖昧な要求からは、曖昧なものが大量に出てくる ▸ 何を作るのか、何が正しいのかが書かれていれば、それが検証の基準になる ▸ 受け入れ基準、例と反例、設計判断の記録（ADR） ▸ ドキュメントの役割が変わる ▸ 人に説明するための資料から、作ったものを検証するための基準へ ▸ 同じ記録が、新しく来た人のオンボーディングとAIへのコンテキストの両方に有効 ▸ 書く手間は増えるが、検証で減る手間のほうが大きい 23
24. AIで組織を加速させる勘所 【勘所4】 流れに沿ってチームを組む ▸ 機能ごとの分業は引き継ぎと待ちを生む ▸ 企画、設計、実装、テスト、運用が別チームなら、流れはチームの数だけ止まる ▸ 価値を顧客に届けるのに必要な人がチームにそろっている状態（クロスファンクショナル）を目指す ▸ AIで職能をまたぐのは軽くなった ▸ （例）開発者がテストやインフラの定義を書く、企画担当がプロトタイプを作る ▸ 専門知識の壁で分けていた仕事を1つのチームに寄せやすくなった ▸ チームの構造は、作られるシステムの構造にも表れる（コンウェイの法則） ▸ AIが参照するのは、そのチームが持つコードと情報 ▸ チームの境界がAIの作る範囲になり、システムの境界になる 24
25. AIで組織を加速させる勘所 判断できるサイズにチームを小さくする ▸ AIが軽くするのは実装の負荷 ▸ 問題を決める、判断する、説明責任を負う。この負荷はチームに残る ▸ 「AIがあるから広い範囲を担当できる」は誤り ▸ 作るのは追いついても、判断が追いつかなくなる ▸ チームで判断できる範囲に担当を絞る。結果として、小さく専任のチームになる ▸ チームの形は、プロダクトの状況に合わせて変わり続ける ▸ 再編を数年に一度の大イベントとしてではなく、日常の中で扱う ▸ ダイナミックリチーミングが描いてきた世界 25
26. AIで組織を加速させる勘所 人をリソースとして扱わない ▸ 「Aに50%、Bに50%」の兼務 ▸ 稼働率は100%に見えるが、どちらの仕事もなかなか終わらない ▸ 切り替えのたびに文脈を失い、責任もあいまいになる ▸ AIで1人がこなせる量が増えると、兼務を増やしたくなる ▸ それは流れを止める方向の変更 ▸ 稼働率を最大化すると、待ちが増える ▸ 余裕のない道路は渋滞する。仕事の流れも同じ ▸ 仕事を割り当てる単位を人からチームに変える 26
27. AIで組織を加速させる勘所 チームを支えるチームを作る ▸ 各チームが個別にAIの環境を整えていたら、判断に集中できない ▸ プラットフォームチーム ▸ 本番環境、開発環境、CI/CD、AIエージェントの実行環境、社内データストア…… ▸ これらをサービスとして提供する ▸ イネイブリングチーム ▸ 短期間チームに入って立ち上げを支援し、自走できるようになったら離れる ▸ ルールを作る部門も、支える側に回る ▸ セキュリティや品質の基準を安全に使うための道として用意する ▸ 「使っていいもの」と「使い方」が決まっていれば、現場は審査を待たずに動ける 27
28. 流れ、判断、検証、チームを変えて はじめて時間が生まれる
29. 生まれた時間をどう価値に変えるか
30. AIで組織を加速させる勘所 30 生まれた時間はどこへ行くのか ▸ 何も決めなければ、時間は「もっと作る」ことに吸収される ▸ やりたいことはいくらでもある。作れるなら作ってしまう ▸ 機能をたくさん出すこと自体が目的になる（ビルドトラップ） ▸ リリースした数で評価される組織ほど、この罠にはまる ▸ 作ったものの多くは、期待したほど使われない ▸ 機能の80%はほとんど、もしくは、まったく使われない（Pendo 2019） ▸ 使われない機能にも、保守とテストと理解のコストはかかり続ける ▸ AIで作るのが速くなるほど、この問題は大きくなる 出典: Pendo “2019 Feature Adoption Report” https://www.pendo.io/resources/the-2019-feature-adoption-report/
31. AIで組織を加速させる勘所 なぜ、急いでたくさん作ろうとするのか ▸ 作っていると、仕事をしている感じがする ▸ 忙しさが、成果の代わりに評価される ▸ 作ったものを捨てる判断ができない ▸ 作るのに使ったお金と時間がもったいなくて、やめられない ▸ コードは資産であると同時に負債 ▸ 作れば作るほど変更しにくくなり、検証しなければいけないものが増える ▸ 必要なのは、当たるものを見つけること ▸ 本格的に作る前に確かめて、外れたら作らない 31
32. AIで組織を加速させる勘所 そもそも、生産性とは何か ▸ 生産性 ＝ 産出 ÷ 投入 ▸ 何を「産出」と見るかで、意味がまったく変わる ▸ 物的生産性 ▸ 作ったものの数や量。機能の数、コードの行数、ストーリーポイント ▸ 付加価値生産性 ▸ 作ったものが生んだ価値。顧客の行動の変化、売上、コストの削減、リスクの低下 ▸ AIが直接上げるのは物的生産性 ▸ 付加価値生産性は、何を作るかの判断で決まる ▸ 作る量が2倍になっても、作ったものの価値が半分なら何も変わらない 32
33. AIで組織を加速させる勘所 【勘所5】 アウトカムで測る ▸ アウトプットは作ったもの。アウトカムは、作ったものによって起きた変化 ▸ AI活用を「生成した量」や「利用率」で測ると、たくさん作る方向に最適化される ▸ 見るものを「流れ」「価値」「持続性」の3つに分ける ▸ 流れ: アイデアが顧客に届くまでのリードタイム、待ち時間、仕掛かりの量 ▸ デリバリー部分: デプロイ頻度、変更リードタイム、変更失敗率、復旧時間…… ▸ 価値: 顧客の利用状況、解決できた課題、事業の指標 ▸ 持続性: 品質、技術的負債、チームの負荷 33
34. AIで組織を加速させる勘所 指標が目標になると それは良い指標ではなくなる グッドハートの法則 （マリリン・ストラザーンによる定式化）
35. AIで組織を加速させる勘所 数字を使うときに守ること ▸ 観測のための数字と、目標のための数字を分ける ▸ 観測している数字を目標にした瞬間、人は数字を動かしにいく ▸ 数字は、その数字で仕事をする人たちのために使う ▸ チームが改善に使う数字を個人やチームの評価や比較に使わない ▸ 片方だけを追うと壊れるものは、組にして見る ▸ 速度と品質、アウトプットとアウトカムなど ▸ 片方を無理に動かすと、もう片方に表れる ▸ 数字が動いたら、現場で何が起きているかを見に行く 35
36. AIで組織を加速させる勘所 「AIで何が良くなるのか」をどう説明するか ▸ 最初から効果を言い切れる人はいない ▸ 言い切れないのに言い切ると、あとで数字を作ることになる ▸ 効果は仮説として置く ▸ 何が良くなるはずか。それはどの数字に表れるはずか。いつまでに検証するか ▸ 先に動く数字と、後から動く数字を分けて見せる（先行指標と遅行指標） ▸ 先に動く: リードタイム、待ち時間、仕掛かりの量 ▸ 後から動く: 顧客の利用状況、売上、コスト ▸ AIの効果は、流れと価値の変化として報告する ▸ AIだけの効果を切り出すのは、METRの比較試験でも難しかった 36
37. AIで組織を加速させる勘所 【勘所6】 生まれた時間を学習に使う ▸ 価値があるかどうかは確かめるまでわからない ▸ 作る前でも、インタビューやプロトタイプで確かめられることは多い ▸ それでも最後は、出して反応を見ないとわからない ▸ AIは実験のコストを下げる（プロトタイプを作る、仮説を試す、複数の案を比べる） ▸ 生まれた時間を仮説検証の回数を増やすことに使う ▸ 小さく作る → 出す → 学ぶ → 捨てるか伸ばすかを決める ▸ 捨てる判断ができるようにしておく ▸ 作ったものを捨てられない組織では、AIで高速にゴミが積み上がる ▸ 「動いた」は「検証できた」ではない。検証すべきは技術ではなく価値の仮説 37
38. AIで組織を加速させる勘所 生まれた時間を余裕として残す ▸ 生まれた時間を全部仕事で埋めると、また稼働率100%に戻る ▸ 余裕がないと、改善も学習も起きない ▸ 改善: 流れを止めているものを取り除く ▸ 学習: 新しい技術、ドメイン、顧客を知る ▸ 育成: 若手が経験を積む ▸ 生まれた時間を何に使うかを先にチームで決めておく ▸ 決めておかないと、目の前の仕事が勝手に埋めていく 38
39. 生まれた時間を もっと作ることに使うな
40. AIが実装の多くを担うようになったとき 人は何をするのか
41. AIで組織を加速させる勘所 AIに任せやすいのは、既知のパターンが多い仕事 ▸ AIが得意なのは、答えがあることやベストプラクティスがあること ▸ 定型的な実装、よく知られたパターン、調べればわかること ▸ 人に残るのは、まだ答えがわからない仕事 ▸ 何が問題なのかを決める。曖昧な要求や状況を解釈する ▸ いくつかの選択肢から選び、その理由を説明する ▸ AIの出力を疑って評価し、使うものと捨てるものを選ぶ ▸ 「AIがそう言ったから」は判断の根拠にならない ▸ AIに責任は渡せない。説明責任は人に残る 41
42. AIで組織を加速させる勘所 技術者にこれまで以上に求められること ▸ 顧客と事業に近づく （勘所5、6） ▸ 何のために作るのかがわからないと、AIに良い指示は出せない ▸ 言語化する （勘所3） ▸ 要求、受け入れ基準、設計判断を書けることが、AIを使いこなす力になる ▸ 確認する （勘所3） ▸ テスト、検証、計測。作ったものが正しいかを自分で確かめられる ▸ 構造を守る （勘所3、4） ▸ AIの生成速度でも壊れない設計、境界、ガードレールを作る ▸ どれも昔から大事だったもの。AIで重みが増した 42
43. AIで組織を加速させる勘所 育成の経路が消えていく問題 ▸ AIに実装を任せると、若手が手を動かして学ぶ機会が減る ▸ シニアは、たくさん作ってたくさん失敗した結果としてシニアになった ▸ 短期の効率を優先すると、数年後に判断できる人がいなくなる ▸ 焼畑農業に目をつぶらない ▸ 学ぶ機会を意図して作る ▸ ペアやモブで、判断の過程そのものを共有する ▸ AIの出力について「なぜこうなるのか」を自分の言葉で説明する ▸ 勘所6の「余裕」は、ここにも使う 43
44. AIで組織を加速させる勘所 自分の手が届く範囲で明日からできること ▸ チームレベル ▸ 自分たちの流れを書き出す （どこで待っているか。どこで詰まっているか） ▸ 仕掛かりを減らす （始めたものを終わらせてから、次を始める） ▸ 検証を自動化する （テストとCIに時間を使う。生まれた時間の最初の使い道） ▸ 「何のために作るのか」を毎回確かめる （作らないという選択肢を議論に乗せる） ▸ 見えた問題を適切な人に届ける （現場で見えたボトルネックは、上に届けないと変わらない） ▸ マネジメントレベル ▸ 判断の基準を書き出して共有する （どこまで現場で決めてよいか） ▸ 届いた問題を取り除く （部門間の調整、規程の見直し、予算の付け方） ▸ AIの効果を利用率や生成量で測らない （流れと価値の変化を見る） 44
45. AIで組織を加速させる勘所 45 【まとめ】 6つの勘所 勘所1 勘所2 勘所3 部分ではなく流れを見る 判断を仕事の近くに寄せる 検証のコストを下げる 個人の作業ではなく、アイデアが顧 客に届くまでの流れを速くする 判断の所在を役職ではなく影響範 囲で決める 作るコストが下がった分、確認や検 証のコストがボトルネックになる 勘所4 勘所5 勘所6 流れに沿ってチームを組む アウトカムで測る 時間を学習と余裕に使う 小さく、専任で、価値を届けるのに 必要な人がそろったチームにする 作った量ではなく、作ったものが起 こした変化を見る 生まれた時間をもっと作ることで埋 めない ■ 1〜4: 時間を生む ■ 5〜6: 時間を価値に変える

Comment

No comments...