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