AI時代の開発生産性を捉え直す — 経営と現場をつなぐ「開発組織のオブザーバビリティ」— 2026.7.22 AI DevEx Conference 2026 株式会社カカクコム CTO 京和 崇行 1 

自己紹介 京和 崇行 Kyowa Takayuki 株式会社カカクコム 上級執行役員CTO AI・テクノロジー管掌 Mission 「AIネイティブカンパニー化」をミッションに、全社の プロダクト開発やオペレーション業務のAI活用を推進。 Hobby 2003-2007 2007-2012 SIer Full Stack Engineer (食べログ) 独立系SIer ボルダリング、マンガ、仕事 2012-2014 2015-2019 2019-2023 2024- PdM/ TechLead CEO/ BizDev 食べログ 技術責任者 CTO レシピサービスの会社（CEOは子会社） 2 

Sponsored by ユーザーファーストで、新しい常識を作る ..and more 3 

本日のアジェンダ 第１部: AI時代の開発生産性を捉え直す 第２部: 経営と現場をつなぐ「開発組織のオブザーバビリティ」 第３部: グッドハートの法則を超えて、未来へ 4 

01 AI時代の開発生産性を捉え直す 5 

開発生産性の議論の変遷 「計測できない」と言われていた開発生産性は、Four Keysの普及や様々なメトリクス サービスの発展によって、「計測して改善するもの」へと変わった。 前史 2018〜 2021〜 そして、AI時代 そ 生産量の 計測 Four Keys SPACE / DevEx ？ コード行数・ベロシティなど、 デリバリーの量と健全性。 開発者体験を含む、多次元 AIが変えた現実に、 アウトプットの量。 『LeanとDevOpsの科学』 の計測（SPACE 2021、 答えられるか (2018)が提示、国内では DevEx 2023） 2019〜2020年頃から普及 出典：Forsgren, Humble, Kim『LeanとDevOpsの科学』(2018) ／ 和田卓人「質とスピード」EOF 2019 (2019.10.31) 6 

Four Keysが果たした役割 Four Keysの功績は、捉えどころのなかった生産性を「ソフトウェアデリバリー能力」と いう計測可能な一部分として定義し、改善のサイクルを始められるようにしたことにある。 観点 Four Keys以前の見方 Four Keysが広めた見方 生産性の表現 個人の作業量・アウトプット量 チームが安全に価値を届けられる流量 速度と品質 速くすると、品質が下がる 速度と安定性は、同時に改善できる （トレードオフではない） 指標の役割 個人の管理・評価 ボトルネックの発見と、継続的改善 指標の設計 ハックされやすい （コードを水増しする） ハックされづらい （速度を不適切に上げると安定性が下がる） ※2026年のガイドからDeployment Rework Rateが追加され、現在は「スループット3指標＋不安定性2指標」の計5つとなっている 7 

Four Keysだけでは見えないもの Four Keysが観測するのは、ソフトウェアのデリバリーパフォーマンス。企画から事業 成果までのプロダクト開発全体を測るものではない。 企画から事業成果までの価値創出プロセス 企画・構想 要件定義 開発・実装 レビュー・ テスト リリース 事業成果 (アウトカム) Four Keysの主な観測対象 フィードバック Four Keysでは、プロセス全体のリードタイム、企画や要件定義の質、開発中に発生した様々な遅延 や、リリースで得られたアウトカムなど、プロダクト開発の全体像は計測できない。 また、リリースの内訳（機能追加か運用タスクか）や、成果物の内部品質も計測できない。 8 

AIによるボトルネックの移動：実装から、検証・意思決定へ AIは実装を劇的に高速化した。結果、ボトルネックは実装から、その前後にある検証や意思決定に 移った。よりプロダクト開発の全体、つまりエンジニアリングの外側に重心が変化している。 ボトルネック これまで 意思決定 実装 検証・レビュー 何を作るか つくる 確かめる AIによる生成の高速化 ボトルネック AI時代 ボトルネック 意思決定 実装 検証・レビュー 何を作るか AIで高速化 確かめる 9 

進化する計測と、広がる経営の問い 開発の内側は、深く、多面的に見えるようになった。一方、AIによるパラダイムシフ トで、経営にとっての重要性と向き合うべき問いは、さらに大きく広がっている。 計測の進化 ・デリバリーの速さと安定性 経営が向き合う問い ・「AIへの投資を、何に、どこまで振り向けるか」 ・フローとボトルネック ・「開発の速さは、事業成果につながっているのか」 ・開発者体験と認知負荷 ・「開発体制や人材戦略は、いまのままでよいのか」 ・品質やAI活用の状況 Four Keys / Flow Metrics / SPACE / DevEx / AI Metrics AIによって市場や環境変化のスピードも増加し、自社の開発組織の全体像と、そこで起きている 変化をどう捉えるべきか、経営の問いに対しては今もなお十分に答えられていない状況。 10 

少し離れて、経営者の頭の中を考えてみる ある月の経営会議。「売上が前月比+8%」という報告が上がってきた。 売上（前月比） +8% 経営者は、この数字を「答え」ではなく、「問いの入り口」として扱う。 もし皆さんが経営者なら、どう考え、何を確認しますか？ 11 

売上UPという一つの数字の奥で、経営者が考えていること 経営者の頭の中では、性質の異なる問いがいくつも同時に浮かび上がる。 何が売上を 動かしたのか？ 単価か、数量か。どのセグメントか、施策か、トレンドか。伸びた部分と沈 んだ部分が相殺して、見えなくなっているものはないか。 一時的か、 構造的か？ 季節性や反動によるものか。それとも継続率や利用頻度、収益構成が変わり、 新しい水準に移ったのか。先行指標は、この変化が続くことを示しているか。 健全な変動か？ この伸びは、何かを削って買ったものではないか。利益率、顧客の信頼、現 場の余力は問題ないか。不確実な変数を見落としていないか。 マーケットは どうか？ 市場全体が+10%成長であれば実体としてはシェアの喪失。事業、あるいは 市場の長期的な構造変化の前触れでないか。いまの事業モデルは正しいか。 次の一手を どう変えるか？ 計画を前倒すか、リソースを組み替えるか。転換が必要なら、その判断はい つまでに下すべきか。 問いは単独では完結しないことがほとんど。ある問いが別の問いに派生し、問いは連鎖していく。 どのような問いがあり、問いの連鎖がどこまで続くか、事前には分からない。 12 

経営者の仕事は「未知の未知と向き合うこと」 経営者が問いを重ねて探しているのは、個々の答えだけでなく、会社がまだ気づけてい ない変化の兆しである。つまり、経営の問いは、事前に列挙できない。 未知の未知に潜む大きな経営インパクト 現実の事業・市場 まだ見ぬ ユースケース 構造的な 変化 経営で見えている世界 静かに進む 顧客の離反 業界外から 代替の台頭 ↑この差分が「未知の未知」 新しい機会の探索 危機的リスクの回避 優位性とは根源的に、他社 変化は見えていなくても、 がまだ気づいていないこと 蓄積され続ける。そしてあ を先んじて知覚する、その る日、既存の説明が通用し 一点にしか宿らない。大き ない形で表面化する。 な機会はその業界における 「危機」と呼ばれるものの 未知の未知から始まる。 多くは、これである。 未知の未知と向き合うとは、知らない情報を集めることではない。自分たちの世界の捉え方が 間違っている可能性に向き合い、経営の前提を書き換え続けることである。 13 

未知の未知を疑い、捉え、修正し続ける 予測は必要だが、100%当たることはない。 予測は外れるものという前提に立ち、未知の未知を捉えて修正するサイクルを素早く回す。 想定外の事象を 捉える 戦略・リソースを 見直す 生じた経路を 理解する 自己修正の循環 経営の認識を 更新する 既存の前提を 疑う 経営とは、自社の「世界モデル」を更新し続ける営みである。 モデルは常に不完全であり、それを現実と未来に合わせ続けることが、経営の要諦になる。 14 

経営目線で開発組織を見ると、同じ事が起きる 「開発生産性が上がった」という報告を受けた経営者の頭の中は、売上のときと同じである。 何が生産性を 動かしたのか？ どのチーム、どの工程で上がったのか。AIの寄与か、プロセス改善か、計測方 法の変化か。伸びたチームと沈んだチームが、相殺していないか。 一時的か、 構造的か？ 大型リリースの反動や、ツール導入直後の一時的な伸びか。開発のやり方が変 わり、新しい水準に移ったのか。品質や手戻りの指標は、何を示しているか。 健全な変動か？ この速さは、レビューの質やテストの厚みを薄めて得ていないか。技術的負債 を積み上げていないか。現場の無理な稼働で支えていないか。 マーケットは どうか？ 他社も同じくAIで速くなっているなら、実体は相対的な停滞。業界の開発様式 そのものの構造変化の前触れではないか。いまの開発のやり方は正しいか。 次の一手を どう変えるか？ AIの投資はどこまで増やすべきか、プロダクトロードマップや採用計画に変更 は必要か。開発のやり方の転換が必要なら、その判断はいつまでに下すべきか。 事前に定義する指標だけでは、これらの問いには答えられない。 経営の「世界モデル」の中で、開発組織が更新できない領域のまま残る。 15 

必要なのは、「指標の追加」ではなく「探索能力の獲得」 根本的な問題は、あらかじめ用意された指標しかないこと。 未知の未知は、事前に定義ができない。定義できた時点で、それは既知の問いとなる。 では、開発組織が「未知の未知を捉え、学習するサイクル」に入るためには、何が要るのか。 必要なのは、次の6つの能力である。 気づく 掘り下げる 書き換える ① 想定外の変化に気づける ② 現場の例外や違和感が、経営まで届く ③ 集計値から、個別の事象へ掘り下げられる ④ 部門やシステムの境界を越えて、結果に至る経路を追える ⑤ 新しい仮説を、後から検証できる ⑥ 検証の結果で、戦略とリソースを変えられる 16 

AI時代の開発生産性を捉え直す 本来測りたかったのは、Four Keysでも、エンジニア組織の生産能力でもない。 AI時代に必要なのは、経営戦略から顧客・事業成果まで、ソフトウェアを通じた価値創出の因果 仮説を問いによってたどり、学びながら更新し続ける、事業全体の探索能力である。 探索対象｜価値創出の因果仮説 問1｜この戦略は、誰のどんな変化を狙うのか 問2｜どんな判断を・いくらで・何を変えたのか 問3｜その変化は、成果にどうつながったのか 経営戦略・ 投資判断 事業・顧客 仮説 プロダクトの 意思決定 開発・ リリース 顧客の利用・ 変化 重点領域・資源配分 誰に、どんな価値を 何を、なぜつくるか どこまで、どうつくるか 行動・状態・声 事業成果 売上・継続・成長 問いに応じて、因果仮説の経路を前後にたどる 探索能力 問いを立てる ｜ 文脈と根拠を横断する ｜ 因果仮説を更新する ｜ 次の問い・意思決定へ 17 

02 経営と現場をつなぐ「開発組織のオブザーバビリティ」 18 

02 1 経営と現場をつなぐ「開発組織のオブザーバビリティ」 オブザーバビリティの概要と開発組織への適用可能性 19 

ソフトウェアエンジニアリングのオブザーバビリティが生まれた背景 現代のソフトウェアでは、システムを構成する要素と、その組み合わせが急増した。その 結果、どこで、どのような障害が起きるかを、あらかじめ予測することが難しくなった。 分散システム化 揮発性のインフラ 状態空間の組合せ爆発 マイクロサービス化によって、一つ のリクエストが多数のサービスを横 断するようになった。 コンテナ、オートスケール、サー バーレスの普及によって、実行環境 は動的に生成・破棄される。 障害は、「バージョン × リージョン × デバイス」のような、複数条件の 交差で発生する。 個々のサービスは正常でも、サービ ス間の相互作用によって、システム 全体では遅延や障害が発生する。 問題を調査しようとした時点では、 障害が起きたインスタンスがすでに 存在しないこともある。 起こり得る組み合わせを、事前に ダッシュボードやアラートとして網 羅することはできない。 オブザーバビリティは、この「予測できない状態」を前提として生まれた。 20 

オブザーバビリティは「未知の未知」の問いに答える モニタリングが事前に想定した「既知の未知」をメトリクスで検出するのに対し、 オブザーバビリティは、問題が起きてから初めて生まれる「未知の未知」の問いを 起点に、答えを探索する。 書籍『オブザーバビリティ・エンジニアリング』による、オブザーバビリティを確かめる問い 任意の粒度で 掘り下げられるか トップレベルの集計値から、問題を引き起こした単一のユーザーリクエストま で、その間の任意の粒度で素早く掘り下げられるか？ 任意のユーザー群を 比較できるか 予期しない挙動を経験したユーザー群と、経験していないユーザー群を比較し、 共通する属性を特定できるか？ 事前に予測していなくて も答えられるか 上記のような任意の質問に、新たに必要なデータを収集するためのセットアッ プを行うことなく答えられるか？ 出典：Charity Majorsほか『オブザーバビリティ・エンジニアリング』（オライリー・ジャパン、2023）をもとに要約 21 

オブザーバビリティに求められる3つの要素 オブザーバビリティの要諦は、システムの状態空間をどこまで詳細に保持し、問 題の発生後にどこまで自由に探索できるかにある。そのためには、データとツー ルの両面で三つの要素が求められる。 高ディメンション あるデータに付与される属性（メタデータ）が多いこと。 トップレベルの集計値から様々な切り口でフィルタリングするために、大量の属性 があるほどよい。 2 高カーディナリティ 値のバリエーションの多い（一意性が高い）こと（user_id, project_id等)。 トップレベルの集計値から個別の活動までドリルダウンするために、高カーディナ リティな値を保持し、検索・集計できる状態になっている必要がある。 3 探索可能性を 支えるツール 属性による絞り込み、グループ化、比較、ドリルダウン、経路追跡を対話的に繰り 返せる。一つの問いから、次の問いへ進むために必要。 1 22 

オブザーバビリティの実践例 オブザーバビリティの実践では、トップレベルの集計値を入口として、問いを重ねながら状態空 間を絞り込んでいく。低カーディナリティな全体傾向から、高カーディナリティな個別事象まで、 同じ文脈の中で連続的にたどる。 低カーディナリティ 全体のエラー率が 0.1% → 2% に急上昇 ← トップレベルの集計 「どのサービスで?」 service.name = "api-gateway" ← ディメンションで分解 「どの顧客・プロジェクトで?」 project.id = "proj_99b82f" ← 高カーディナリティの領域へ 「どのリクエストで?」 trace.id = "4bf92f3577b34da6..." ← 原因の1本に到達 高カーディナリティ 集計値は答えではなく、探索を始めるための入口である。 23 

開発組織を「複雑系のシステム」とみなす 開発組織もまた、戦略・プロジェクト・組織・人・技術など、多次元的な構成要素の相互 作用によって変化する、複雑系のシステムとみなすことができる。 共通する構造 開発組織 多数のサービスが連携する 多数の構成要素が相互作用する 多数の組織・部署・人・AIが連携する 実行環境が動的に変化する 構成や状態が時間とともに変化する 優先順位・要件・体制・技術が変化する 状態空間が組み合わせで拡大する 市場 × 戦略×プロジェクト× 技術 問いを事前に列挙できない 成果を生む活動を事前に特定できない ソフトウェアシステム バージョン × デバイス × リー ジョン 障害原因を事前に特定できない → 問題構造が似ているため、オブザーバビリティの設計思想を援用できるのではないか？ 24 

02 2 経営と現場をつなぐ「開発組織のオブザーバビリティ」 私たちの実践例: 事業の戦略意図とプロジェクトへの投資 を紐づけ、観測可能にする 25 

「オブザーバビリティをやろう」で始めたものではなかった 取り組みの起点は、理論の導入ではなく、「事業の戦略意図・優先順位と、プロジェク トへのエンジニアの投下リソースはアラインできているか？ 」という問いからだった。 経営の問い 活動実態の構造化 問いをたどれる範囲の拡大 ・限られた開発力を何へ配分してい るか ・戦略上の重点領域と実際の活動は 一致しているか ・想定外に時間を使っている領域は どこか プロジェクト、活動分類、工程、投 下時間、エンジニアを接続し、まず 現在の活動を同じ形式でたどれるよ うにした。 集計値から対象プロジェクトや個別 活動へ掘り下げ、問いに応じて切り 口を変えられるようになった。 → → 後から振り返ると、これはオブザー バビリティの設計思想と重なる。 26 

「プロジェクトツリー」で、開発組織のすべての活動を構造化する プロジェクト名と投下時間だけを集計しても、その活動が事業にとって何を意味するか は分からない。そこで、全活動を戦略投資・成長投資・運用保守・間接業務として構造 化し、活動に戦略上の文脈を与えた。 プロジェクトツリー 戦略投資 新規事業創出 インフラ・ アーキ テクチャ刷新 非連続 イノベーショ ン 開発生産性の 抜本的改革 個々の プロジェクト 成長投資 システムの 抜本的革新 性能改善 事業コア 施策 安定性改善 運用保守 事業レギュ ラー施策 生産性改善 【LINE】 LINEでネット予約通知 その他改善 間接業務 システム 改善施策 プロダクト 運用保守 システム 運用保守 バージョン アップ/移行 セキュリティ 対応 サポート対応 インバウンド向けアプリ開発 （Android） 採用・広報 障害対応 PC/SPドメイン統合 (s.廃止） 付帯業務 定常保守 教育・育成 全社・カンパ ニー共有 プロジェクト 外会議 部・チーム 連携会議 APサーバ Kubernetes化 その他 デイリー ミーティング 1on1 ⋯ 27 

戦略・プロジェクト・投下時間・人を、一つの構造で接続する プロジェクトツリー上の事業・領域・プロジェクトに、投下時間と工程、エンジニアを 関連づけた。これにより、全体の活動分類から個別のプロジェクトやエンジニアまで、 異なる粒度の情報を往復できる。 プロジェクトツリー ・戦略投資 ・成長投資 ・運用保守 ・間接業務 事業・領域 プロジェクト ・事業コア施策 ・事業レギュラー施策 ・システム施策 横断してフィルタリング可能な軸 年月 ・施策・案件 ・プロジェクト名 ・対象領域 主領域／副領域 部署・チーム 投下時間・工程 ・人月／時間 ・工程（設計、実装、 テスト、リリース） 工程 活動区分 エンジニア ・部署、チーム ・個人 従業員 同じデータを、戦略から下へも、プロジェクトや個人から上へもたどることができる。 集計軸を固定せず、問いに合わせて階層と切り口を切り替える。 一つの数字を集計するのではなく、異なる粒度を行き来できる構造をつくった。 28 

【実例】戦略・プロジェクト・投下時間・人を、一つの構造で接続する プロジェクトツリー全体（問いの起点となる） 第一階層 第二階層 ⇧今エンジニア全体でどんな配分で投資してるの？ 29 

【実例】戦略・プロジェクト・投下時間・人を、一つの構造で接続する 戦略 – カテゴリ ー プロジェクト – 工数 事業 – カテゴリ - 工数 どんなプロジェクト やってるの？ 戦略 – カテゴリ ー プロジェクト – 人 - 工数 誰がどのプロジェクト やってるの？ ⇧成長投資って何やってるの？ 30 

開発活動を、全体から個別まで探索する プロジェクトツリーと投下時間・チーム・人を接続することで、全体の投資配分から対 象プロジェクト、さらに個別の活動まで、段階的に辿れる仕組みを構築できた。 最小単位の明細を持つことでしか、これは実現できない。 1｜全体の配分を捉える 2｜対象プロジェクトへ降りる 3｜個別の活動を確認する どの投資区分・領域への配分が 想定から変化しているか？ どの施策・案件が、その変化を 構成しているか？ どのチーム・エンジニアの活動が 集中しているか？ 集計値を見ることは目的ではなく、未知の変化の予兆を捉え、探索を始めるための入口である。 31 

時間軸と工程を重ねると、プロジェクトの ”Bad Smells” が見える 工程別の投下時間を時系列で観測すると、集計値では見えない偏りや順序の変化が現れ る。ただし、可視化が示すのは原因ではなく、追加調査を始めるためのシグナルである。 この変化から立てられる問い • プロジェクト中盤〜後半に設計工数が増えて いるのはなぜか？ • テスト実施後の実装時間はバグ修正？バグの 発生件数は適切な範囲に収まっていたか？ • テスト期間が想定より長期化していないか？ • 工程の重なりはプロジェクト内の過度な手戻 りや重複を招いていないか？ 32 

実際の運用例: 事業責任者との対話 月次の会議での会話例。あらかじめ決めた指標を確認して終わるのではない。 変化に気づき、切り口を変えながら掘り下げ、次に確認すべき事実と意思決定へつなげ ていく。 1 | 最初の問い 中期計画に沿った事業成長に投資で きているか？ 2｜変化への気づき → 成長投資の比率が想定より低い 3｜原因の分解・特定 → どの領域で差が生じていた？ → 運用保守の増加 → 対象プロジェクトの特定 ↓ 6｜次の確認と判断 追加の調査・優先順位・対策案を固 める 5｜原因仮説を置く ← 途中で大きな要件変更があったか 想定外の技術要因が見つかったか テスト中に重要バグが見つかったか 4｜工程・組織で比較 ← プロジェクト後半での投入人員増加 が起きていた 一つの問いから、次の問いへ。探索の結果が、会議での追加調査と意思決定を更新する。 33 

「開発組織のオブザーバビリティ」の実現 自分たちが構築した仕組みが、結果的にオブザーバビリティと一致していた。 一方で、開発組織”全体”が観測可能な状態ではまだない。 P.21「オブザーバビリティは「未知の未知」の問いに答える」の再掲 34 

現状の限界: 現在の観測範囲は、戦略から実際の活動まで プロジェクトツリー、プロジェクト、投下時間・工程、組織・エンジニアを接続し、 戦略と実際のリソース配分をたどれるようになった。一方、開発フローやAIの関与、 リリース後の顧客行動・事業成果はまだ接続できていない。 現在、同じ文脈で観測できる範囲 未接続の範囲 観測境界 戦略 → 事業・領域 → プロジェクト → 投下時間・ 工程 現在の構造でできること ・戦略と、実際のリソース配分を対応づけられる ・全体の変化から、プロジェクト・活動までたどれる ・投下時間と工程の変化から、次の問いを立てられる → 部署・ 組織・人 │ コード・PR → レビュー・ → リリース → 顧客行動 → 事業成果 テスト まだ接続できていないこと ・リリース後の顧客行動・事業成果（アウトカム） ・企画・デザインなどを含む、プロダクト開発全体の人員参加 ・人とAIの役割分担や、AIが関与した活動 ・Four Keysなどの開発フロー・品質指標 35 

02 3 経営と現場をつなぐ「開発組織のオブザーバビリティ」 開発組織”全体”のオブザーバビリティを設計する 36 

開発組織全体のオブザーバビリティを設計する 戦略仮説から顧客価値提供までを一つのシステムとみなし、組織や工程ごとに分断され た活動・成果物・リリース・顧客反応を、同じ価値創出の経路として探索できる状態を 設計する。 この戦略仮説は、どの活動・成果物を経て、どの顧客価値へ至ったのか？ 経路上のイベントを、共通のトレースIDで接続する trace_id = VT-2048 / hypothesis_id = HYP-042 経営・事業 戦略仮説 event: hypothesis 企画・デザイン 企画・設計 activity_id 開発・デリバリー 実装・レビュー・テスト artifact_id / actor_id 顧客・事業成果 リリース release_id 顧客への露出 顧客価値・学習 experiment_id outcome_event 37 

人とAIを、同じ「実行主体」として観測する AIエージェントが開発活動を直接担う時代には、人とAIを同じ実行主体として観測する 必要がある。一方で、実行主体と、その活動で担った役割は分けて記録する。これによ り、価値創出の経路で誰が何を担ったかを追跡できる。 実行主体 Aさん 記録されるイベント 担った役割 actor_type = Human PdM Designer Activity Event actor_id Bさん actor_type = Human Reviewer Engineer actor_type role Agent-123 actor_type = AI Tester Agent-123 AI Engineer activity コード生成 input / output 要件 → PR evaluation 採用・修正 38 

AIが、開発組織の観測粒度の限界を押し広げる 人が記録の主体である限り、活動を詳細に残すほど記録負荷が増え、観測できる粒度に は限界があった。AIが日常のフットプリントから活動イベントを生成することで、記録 負荷を抑えながら、これまで保持できなかった明細を観測できるようになる。 明細 【これまで：人が記録する】 【AI時代：人とAIで記録する】 意思決定・レビュー意図・調整・活動の文脈 ＜AIによって、実用可能な観測粒度を押し上げる＞ 十分な明細を継続的に残せない 企画・要件 観測粒度 会議・対話 コード・PR AI実行履歴 ＜人の記録負荷による観測上限＞ プロジェクト 工程 月次工数 詳細に残すほど、入力・分類・確認の負荷が増える AIが抽出・分類・関連づけ 探索可能な明細イベント 集計値 AIは開発を変えるだけでなく、開発組織を観測するための前提も変える。 39 

これまでの開発生産性指標を、オブザーバビリティに拡張する Four Keysは重要な観測点であるが、集計値しか持てていない。指標を構成する明細イ ベントを保持し、プロジェクト・活動・リリース・顧客への提供と接続することで、モ ニタリングからオブザーバビリティへ拡張する。 従来の開発生産性モニタリング Four Keys CI/CD Deploy E2Eテスト 集計値で変化を検知 指標を構成する 明細イベントを保持 change PR review merge test deploy incident recovery 明細へ降り、前後の経路をたどる 価値創出の経路へ接続 プロジェクト 活動 成果物 リリース 顧客への提供 40 

経営と現場をつなぐ「開発組織のオブザーバビリティ」 開発組織のオブザーバビリティとは、戦略仮説から顧客価値までを一つのシステムとし て観測し、経営と現場が、それぞれの問いから同じ価値創出の経路を探索できる状態で ある。 経営の問い 戦略仮説 現場の問い 変化を観測 どこへ投資するか？ 企画・設計 人とAIの活動 どこで滞留したか？ 問い・仮説 価値は生まれたか？ 何を見直すか？ 開発・デリバリー 何が顧客行動を変えたか？ 比較・実験 解釈・学習 顧客行動 顧客価値・事業成果 次に何を試すか？ 戦略・投資・開発を更新 41 

03 グッドハートの法則を超えて、未来へ 42 

指標は悪ではない。ハックしやすい数値を目標にするのが問題 グッドハートの法則が示すのは、指標化そのものの否定ではない。 数値が目標になると、組織は本来の目的ではなく、その数値を改善する行動を学習する。 だからこそ、直接操作しやすい単一指標を避け、複数の観点を組み合わせて、局所最適 化されにくい指標を設計する必要がある。 ハックしやすい単一の指標設計 ハックされにくい指標設計 [スピード] コード行数 コミット数 数値を増やす 行動へ最適化 数値と価値が 乖離する デプロイ頻度 ・リード タイム × [安定性] 変更障害率・復旧時間 一つの数値を改善すれば、目標を達成したように見せられる Four Keys 複数の観点が相互に牽制する 一つの数値だけを改善する局所最適化を抑える 指標がハックされるのは指標の責任ではない。その指標を設計したマネジメントの責任である。 43 

目指す未来から逆算して観測構造を設計する オブザーバビリティの世界では指標は探索の入口でしかない。 だから、目指す未来から逆算して、「何を活動として認識し、どこに位置づけ、どの成 果まで追うか」を設計できる。観測構造は現状を映すだけでなく、組織に重要な行動を 伝え、未来への行動を方向づける。 未来から逆算して設計 プロジェクトツリー 「システムの抜本的革新」 目指す未来・戦略意図 「システムの非連続な改善」 必要な活動として 組織が認識する オブザーバビリティ：活動から価値までの経路を多面的に観測する プロジェクト 投下時間・工程 システムの変化 実現価値 事業成果 未来への前進を 確かめる 44 

企業全体を、学習し続けるシステムとしてエンジニアリングする 開発組織で実証した「観測し、探索し、学習する」方法は、開発に閉じない。企業その ものを一つのシステムとみなし、エンジニアリングする時代に入る。 “真のチャンスは「最高のAIモデルを選ぶこと」に あるのではありません。人的資本とトークン資本 が相互に高め合う「学習ループ」を、モデルの上 に構築することにあるのです。 タスクや、あるいは職務そのものをAIに任せるこ とはできても、「自ら学ぶこと」をアウトソース することは決してできません。企業の未来は、人 間とAIを横断して、その学びを蓄積・増幅（コン パウンド）できる能力にかかっています。” https://x.com/satyanadella/article/2066182223213293753 45 

AIネイティブな企業を目指す AIネイティブな企業とは、AIを高度に使いこなすだけでなく、 AIで組織そのものを エンジニアリング可能にした会社のこと。どちらかではなく、どちらも必要。 組織でAIを高度に使いこなす AIで組織そのものをエンジニアリングする 46 

Sponsored by ユーザーファーストで、新しい常識を作る ..and more 47 

ご清聴ありがとうございました 48