Upgrade to Pro — share decks privately, control downloads, hide ads and more …

開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力...

開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜 / Developer eXperience Day 2023

2023年6月14日より開催された「Developer eXperience Day 2023」の登壇資料です。
https://dxd2023.cto-a.org/

▼関連資料
ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜
https://speakerdeck.com/takabow/devopsdays-tokyo2022-huakutokarashi-merugai-shan-apuroti-leantodevopsfalseke-xue-woshi-jian-site

ファクトから始める改善アプローチ EP2 〜 Four Keys の先にある アウトカムに向き合ってみた 〜
https://speakerdeck.com/visional_engineering_and_design/devopsdaystokyo-2023

「エセ自己組織化」症候群から脱却し、約束を守るプロフェッショナルなアジャイルチームになるには -アジャイル時代のマネジメント進化論-
https://speakerdeck.com/visional_engineering_and_design/number-rsgt2023

ユーザー数100万人規模の事業成長を止めずに、レガシーコードと戦う
https://speakerdeck.com/visional_engineering_and_design/jjug-ccc-2022-fall

-----
Visionalのエンジニアリングに関する最新情報はTwitter、ブログで発信しています!📣

▼Visional Engineering Blog
https://engineering.visional.inc/blog/

▼VISIONAL ENGINEERING Twitter
https://twitter.com/VISIONAL_ENG

More Decks by Visional Engineering & Design

Other Decks in Technology

Transcript

  1. 2 本コンテンツの目的 本日お伝えしたいこと Learning Outcome エグゼクティブ、マネジャーの方へ • プロダクト開発チームの「内側」で起きやすい事象を認識しよう • ビジネス(事業)とプロダクト開発の相関関係を見出そう

    • DORA Metrics(Four Keysなど)以外にもいっぱい測ろう • ビジネスを成長させるために「計器飛行」を実現しよう 1. 自己紹介 2. 株式会社ビズリーチ紹介 3. 開発者体験とは 4. 開発者体験の誤解 5. 計測指標(メトリクス)の内側と外側 6. エビデンスベースの計器飛行 7. SODA構想とは 8. ビズリーチ版SODA アジェンダ プロダクト開発者・エンジニアの方へ • プロダクト開発チームの「外側」も意識しよう • 開発者体験はイメージよりエビデンスに価値を置こう
  2. 3 ビズリーチ・ジャーニー JJUG CCC 2022 Fall (2022/11/27) DevOpsDays Tokyo2022 (2022/4/21)

    本 日 発 表 す る の は こ れ ら の 続 編 で す Regional Scrum Gathering Tokyo 2023 (2023/1/11) DevOpsDays Tokyo2023 (2023/4/18)
  3. 会社概要 株式会社ビズリーチ / BizReach, Inc. 創業 :2009年4月 代表者 :株式会社ビズリーチ 代表取締役社長

    酒井 哲也 グループ従業員数:1,821名(2022年7月末時点) 拠点 :東京、大阪、名古屋、福岡、静岡、広島 資本金 :1億3,000万円 事業内容:HR Techのプラットフォーム・SaaS事業
  4. 14 ウガンダのAirQoプロジェクト アフリカの都市部では大気汚染が深刻で 毎年700万人もの人が亡くなっている。 ウガンダの首都カンパラも例外ではなく 人々は大気汚染に苦しんでいる。 が、そもそもカンパラの人たちは『空気 がどれぐらい汚れているか』を知らな かった。 マケレレ大学のバイノムギシャ氏は安価

    な大気センサーを開発し、バイクタク シー(ボタボタ)や建物の屋上に大気セ ンサーを取り付け市内全域の大気汚染 データを収集し、汚染の予測や大気質の 改善に役立つようにした。 https://about.google/intl/ja_AI/stories/clean-air-for-kampala/
  5. 15 ウガンダのAirQoプロジェクト アフリカの都市部では大気汚染が深刻で 毎年700万人もの人が亡くなっている。 ウガンダの首都カンパラも例外ではなく 人々は大気汚染に苦しんでいる。 が、そもそもカンパラの人たちは『空気 がどれぐらい汚れているか』を知らな かった。 マケレレ大学のバイノムギシャ氏は安価

    な大気センサーを開発し、バイクタク シー(ボタボタ)や建物の屋上に大気セ ンサーを取り付け市内全域の大気汚染 データを収集し、汚染の予測や大気質の 改善に役立つようにした。 https://about.google/intl/ja_AI/stories/clean-air-for-kampala/ まず「測る」ことが大事
  6. 16 開発者体験とは •"DevEx: What Actually Drives Productivity: The developer- centric

    approach to measuring and improving productivity" (DevEx: 何が実際に生産性を向上させるのか: 生産性を測定し改善 するための開発者中心のアプローチ) • Association for Computing Machinery(ACM)が発行する雑誌 "acmqueue" 2023年3月-4月号に載った論文 •著者 •Abi Noda: DX社創業者兼CEO。以前は2019年にGitHubに買収されたPull Panda を設立 •Margaret-Anne Storey: ビクトリア大学コンピューターサイエンス教授。DX社チーフサイエ ンティスト •Nicole Forsgren: Microsoft ResearchのパートナーでDeveloper Velocity Labを率いる。 "Accelerate: The Science of Lean Software and DevOps"(和名 「LeanとDevOpsの科学」)の筆頭筆者 •Michaela Greiler: DX社研究責任者。以前はチューリッヒ大学およびMicrosoft Researchの研究員 https://mydigitalpublication.com/publication/?m=38068&i=791199&p=1&ver=html5
  7. 17 DevExの3コア・ダイヤモンド DevEx Flow State Feedback Loops Cognitive Load (参考)

    Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. フロー状態 認知負荷 フィードバックループ
  8. 18 DevExの3コア・ダイヤモンド DevEx Flow State Feedback Loops Cognitive Load 1.

    Feedback Loops(フィードバックループ):ソフトウェアの開発とテスト、 コードレビュー、マニュアルテスト、実際のユーザーフィードバックなど、ソ フトウェア配信には多くのフィードバックループが関与しています。これらの ループはすべて短くなければならず、特にタスクがまだ活動中の間に完了する ことが理想的です。フィードバックループがタスクの一部として中断すると、 それは次の作業を中断し、認知負荷を増加させます。 2. Cognitive Load(認知負荷):ソフトウェアを作成し維持する作業は大量の精神 的処理を必要とします。開発者が多くのツールや技術を持っていると、タスク の自然な認知負荷が増加します。ソフトウェアのアーキテクチャも負荷を増加 させることがあります。ツールチェーンの摩擦を減らす、ドキュメンテーショ ンを最新の状態に保つ、システムのアーキテクチャを改善する、プロセスの遅 延を排除することで認知負荷を軽減できます。 3. Flow State(フロー状態):フロー状態は、エネルギーに満ちた集中した感覚を 伴う完全な没頭感として説明されます。この状態は、作業の構造に対するコン トロール、明確な目標、魅力的な作業があるときに自然に発生します。フロー をもたらすためには、中断や遅延からの邪魔を防ぐことが必要です。 (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
  9. 19 DevExの3コア・ダイヤモンド DevEx Flow State Feedback Loops Cognitive Load Ian

    Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons フィードバックループ
  10. 20 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会.

    P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ
  11. 21 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会.

    P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ
  12. 22 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会.

    P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ
  13. 23 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会.

    P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ
  14. 24 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会.

    P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ
  15. 25 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会.

    P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons 認知負荷 フィードバックループ
  16. 26 DevExの3コア・ダイヤモンド (参考)原田悦子, 橋本英奈, & 須藤智. (2016). 矢印を用いた「組み合わされた方向サイン」の わかりやすさ:構造,アイコン,加齢の効果. 日本認知科学会第33回大会.

    P2-42. (図1) DevEx Flow State Feedback Loops Cognitive Load Georgios Liakopoulos, CC BY-SA 2.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons Ian Maddox, CC BY-SA 4.0, via Wikimedia Commons フロー状態 認知負荷 フィードバックループ
  17. 27 DevEx Metrics Feedback Loops フィードバックループ Cognitive Load 認知負荷 Flow

    State フロー状態 Perceptions 認識(態度、感情、意見) Human attitudes and opinions • 自動テストのスピードと出力 に対する満足度 • ローカル変更の検証にかかる 時間に対する満足度 • 変更を本番に導入するまでの 時間に対する満足度 • コードベースの複雑さの認識 • プロダクションシステムのデ バッグのしやすさ • ドキュメントの理解しやすさ • 集中力と中断を回避する能力 の認識 • タスクやプロジェクトの目標 が明確であることの満足度 • オンコールがもたらす混乱に ついての認識 Workflows ワークフロー System and process behaviors • CIの結果生成にかかる時間 • コードレビューのターンアラ ウンドタイム • デプロイメント・リードタイ ム(変更が本番環境にリリー スされるまでの時間) • 技術的な質問に対する回答を 得るまでにかかる時間 • 変更を適用するために必要な 手動手順 • ドキュメントの改善頻度 • ミーティングや割り込みがな い時間帯の数 • 予定外のタスクやリクエスト の発生頻度 • チームの対応を必要とするイ ンシデントの発生頻度 KPIs North star metrics • ソフトウェア提供の容易さに関する総合的な認識 • 従業員エンゲージメントまたは満足度 • 生産性の認識 (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53.
  18. 28 DevExメトリクスの例 Feedback Loops フィードバックループ Cognitive Load 認知負荷 Flow State

    フロー状態 Perceptions 知覚 Human attitudes and opinions • 自動テストのスピードと出力に 対する満足度 • ローカル変更の検証にかかる時 間に対する満足度 • 変更を本番に導入するまでの時 間に対する満足度 • コードベースの複雑さの認識 • プロダクションシステムのデ バッグのしやすさ • ドキュメントの理解しやすさ • 集中力と中断を回避する能力の 認識 • タスクやプロジェクトの目標が 明確であることの満足度 • オンコールがもたらす混乱につ いての認識 Workflows ワークフロー System and process behaviors • CIの結果生成にかかる時間 • コードレビューのターンアラウ ンドタイム • デプロイメント・リードタイム (変更が本番環境にリリースさ れるまでの時間) • 技術的な質問に対する回答を得 るまでにかかる時間 • 変更を適用するために必要な手 動手順 • ドキュメントの改善頻度 • ミーティングや割り込みがない 時間帯の数 • 予定外のタスクやリクエストの 発生頻度 • チームの対応を必要とするイン シデントの発生頻度 KPIs North star metrics • ソフトウェア提供の容易さに関する総合的な認識 • 従業員エンゲージメントまたは満足度 • 生産性の認識 (参考) Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. 「開発者体験」は測れる
  19. 30 ソフトウェアエンジニアリングの歴史的「格言」 「計測できないものは制御できない」 “You can’t control what you can’t measure.”

    Tom DeMarco(1982) ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982)
  20. 31 ソフトウェアエンジニアリングの歴史的「格言」 「計測できないものは制御できない」 “You can’t control what you can’t measure.”

    Tom DeMarco(1982) ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982) 呪言
  21. 32 「測定できないものは制御できない」は誤りだった? •2009年7月、Tom DeMarco がIEEE Software誌7月8月合 併号に、衝撃的な記事を寄稿しました。タイトル は ”Software Engineering:

    An Idea Whose Time Has Come and Gone?(ソフトウェアエンジニアリング:その 考えは、もう終わったことなのか?)” •この文章は当時、Tom DeMarco 自身が「測定できないも のは制御できない」は誤りだったと認めた!ということで 業界に衝撃が走りました。 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf 「計測できないものは制御できない」 “You can’t control what you can’t measure.” このセリフには本当の真実が含まれているのですが、私はこのセリ フを使うことに違和感を覚えるようになりました。 (中略)例えば、 過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算 通りに終わらせることができないことで自らを苦しめてきました。 (Tom DeMarco, 2009)
  22. 33 「測定できないものは制御できない」は誤りだった? •2009年7月、Tom DeMarco がIEEE Software誌7月8月合 併号に、衝撃的な記事を寄稿しました。タイトル は ”Software Engineering:

    An Idea Whose Time Has Come and Gone?(ソフトウェアエンジニアリング:その 考えは、もう終わったことなのか?)” •この文章は当時、Tom DeMarco 自身が「測定できないも のは制御できない」は誤りだったと認めた!ということで 業界に衝撃が走りました。 https://www.cs.uni.edu/~wallingf/teaching/172/resources/demarco-on-se.pdf 「計測できないものは制御できない」 “You can’t control what you can’t measure.” このセリフには本当の真実が含まれているのですが、私はこのセリ フを使うことに違和感を覚えるようになりました。 (中略)例えば、 過去40年間、私たちはソフトウェアプロジェクトを時間通り、予算 通りに終わらせることができないことで自らを苦しめてきました。 (Tom DeMarco, 2009) 例えば、過去40年間、私たちはソフトウェアプ ロジェクトを時間通り、予算通りに終わらせる ことができないことに自責の念を抱いてきまし た。しかし、先ほども申し上げたように、これ は決して至上命題ではありませんでした。 もっと重要なのは、世界を変えるような、ある いは企業やビジネスのあり方を変えるようなソ フトウェアを作るという「変革」です。 Tom DeMarco(2009)
  23. 36 開発者体験の誤解 DevEx Flow State Feedback Loops Cognitive Load (参考)

    Noda, A., Storey, M. A., Forsgren, N., & Greiler, M. (2023). DevEx: What Actually Drives Productivity: The developer-centric approach to measuring and improving productivity. ACM Queue, Vol.21, No.2, p.35-53. フロー状態 認知負荷 フィードバックループ
  24. 37 開発者体験の誤解 プロダクト開発チーム 開発者 DevEx Flow State Feedback Loops Cognitive

    Load one for all, all for one !! スクラムは 楽しいぜ! チーム外の 要求は受け 付けない! 俺たち 自己組織化 してる 心理的安全 性が高い
  25. 38 開発者体験の誤解 ねぇ、◯◯の機能って 6月のリリースに乗 るっていってたよね? 入ってなくない? セールス あぁ、アレはボクたち 開発チームのスプリン トプランニングで入ら

    なかったんだ ええっ! お客様、あの機能ずっーと 待ってるんだぞ! 6月には必ず!ってお伝え しちゃってるんだよ〜! 開発者 他のPBIを優先させ たしね。アレは6月 リリースからはド ロップさせてもらっ たよ
  26. 39 開発者体験の誤解 そんなわけで、私た ちのチームは今回余 裕があったので例の △ △ 対応画面の実装 を終えたわ ちょいちょい、待てよ!

    俺たちバックエンドチー ムは聞いてないぞ! キミらだけ出来てどーす んだよ! スプリントプランニングどおり なんだから仕方ないじゃない、 私たちのチームは自律性を大切 にしてるのよ! 開発者 他チームの開発者
  27. 40 開発者体験の誤解 one for all, all for one !! スクラムは

    楽しいぜ! チーム外の 要求は受け 付けない! 成果が出てない んだよなぁ…… 俺たち 自己組織化 してる 他のチームのこ と考えてないん だよなぁ… 約束、守らない んだよなぁ… 心理的安全 性が高い
  28. 41 開発者体験の誤解 one for all, all for one !! スクラムは

    楽しいぜ! チーム外の 要求は受け 付けない! 成果が出てない んだよなぁ…… 俺たち 自己組織化 してる 他のチームのこ と考えてないん だよなぁ… 約束、守らない んだよなぁ… 心理的安全 性が高い 内側しか見てないとこうなる
  29. 43 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops

    Cognitive Load 顧客 アウトプットが恐ろしく速いプロダクト開発チーム
  30. 44 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops

    Cognitive Load 顧客 機能A アウトプットが恐ろしく速いプロダクト開発チーム
  31. 45 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops

    Cognitive Load 顧客 機能A 機能B アウトプットが恐ろしく速いプロダクト開発チーム
  32. 46 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops

    Cognitive Load 顧客 機能A 機能B 機能C アウトプットが恐ろしく速いプロダクト開発チーム
  33. 47 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops

    Cognitive Load 顧客 機能A 機能B 機能C 機能D アウトプットが恐ろしく速いプロダクト開発チーム
  34. 48 開発者体験の誤解 PO SM 開発者 DevEx Flow State Feedback Loops

    Cognitive Load 顧客 コレ じゃない! 機能A 機能B 機能C 機能D アウトプットが恐ろしく速いプロダクト開発チーム
  35. 49 ビルドトラップ •組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況* •実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状態* 誰もプロダ クトを使わ ない 足りない機 能を作る 顧客に足り

    ない機能を 聞く プロダクトの死のサイクル(デイビッド・ブランド) https://twitter.com/davidjbland/status/467096015318036480 * Perri, M. (2018). プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける(吉羽龍太郎, Trans.). O'Reilly Japan, Inc​​.
  36. 50 ビルドトラップ •ビルドトラップ: •組織がアウトカムではなくアウトプットで成功を計測しようとして、行き詰まっている状況* •実際に生み出された価値ではなく、機能の開発とリリースに集中してしまっている状態* 誰もプロダ クトを使わ ない 足りない機 能を作る

    顧客に足り ない機能を 聞く プロダクトの死のサイクル(デイビッド・ブランド) https://twitter.com/davidjbland/status/467096015318036480 * Perri, M. (2018). プロダクトマネジメント―ビルドトラップを避け顧客に価値を届ける(吉羽龍太郎, Trans.). O'Reilly Japan, Inc​​. 内側しか見てないとこうなる
  37. 55 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback

    Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった!
  38. 56 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State Feedback

    Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! アウトカム向上
  39. 信頼・対価(売上) 57 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State

    Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! アウトカム向上
  40. 信頼・対価(売上) 58 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State

    Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! 継続 アウトカム向上
  41. 信頼・対価(売上) 59 計測指標(メトリクス)の内側と外側 プロダクト開発チーム PO SM 開発者 DevEx Flow State

    Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! 継続 アウトカム向上 内側 自組織を測る メトリクス 外側 顧客を測る メトリクス
  42. 60 DORA Metrics •Four Keys とは DORA社(DevOps Research and Assessment,

    現Google)が長年の の研究から導いた開発チームのパフォーマンス指標 •アジャイルでもウォーターフォールでも計測可能 リードタイム コードがコミットされてか ら本番環境で正常に実行さ れるまでの時間 デプロイ頻度 コードを本番環境にデプロ イまたはエンドユーザーに リリースした頻度 平均サービス 回復時間(MTRS) サービスインシデント または不具合が発生したと きにサービスの復元にどれ くらいの時間がかかるか 変更失敗率 本番環境に変更を加えた、 またはユーザーへのリリー スを実施した結果サービス が低下し、その後修正を行 う必要が生じた割合
  43. DORA Metrics “生産性”に代わる開発チームのパフォーマンス計測を! ソフトウェア開発の“生産性”指標の難しさ 「書いたコードの量」が 生産性とは限らない 「ベロシティ(速度)」は 生産性とは限らない 「リソース効率(利用率)」が 生産性とは限らない

    品質 スピード リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる リードタイム デプロイ頻度 平均サービス 回復時間(MTRS) 変更失敗率
  44. 62 DORA Metrics リードタイム デプロイ頻度 平均サービス 回復時間(MTRS) 変更失敗率 信頼性(可用性) Four

    Keys 27のケイパビリティ 統計的相関 (参考)Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10)
  45. 信頼・対価(売上) 63 Four Keys は内側か外側か? プロダクト開発チーム PO SM 開発者 DevEx

    Flow State Feedback Loops Cognitive Load 顧客 プロダクト・サービス提供 良かった! 継続 アウトカム向上
  46. 良かった! 顧客 プロダクト・サービス提供 信頼・対価(売上) 66 Four Keys は内側か外側か? プロダクト開発チーム DevEx

    Flow State Feedback Loops Cognitive Load プロダクトのアウトカムや品質の定量的計測を中心とした 「市場価値」(アウトカム)も計測したい=外側の指標
  47. 良かった! 顧客 プロダクト・サービス提供 信頼・対価(売上) 67 Four Keys は内側か外側か? プロダクト開発チーム DevEx

    Flow State Feedback Loops Cognitive Load プロダクトのアウトカムや品質の定量的計測を中心とした 「市場価値」(アウトカム)も計測したい=外側の指標 もっと重要なのは、世界を変えるような、ある いは企業やビジネスのあり方を変えるようなソ フトウェアを作るという「変革」です。 Tom DeMarco(2009)
  48. 69 エビデンスベースドマネジメント(EBM) 市場に出すまでの時間(反応性) (T2M: Time to Market) 新しい能力、サービス、製品を迅速 に提供する能力 イノベーションの能力(効果性)

    (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値 重要価値領域(KVA)
  49. 70 エビデンスベースドマネジメント(EBM) 市場に出すまでの時間(反応性) (T2M: Time to Market) 新しい能力、サービス、製品を迅速 に提供する能力 イノベーションの能力(効果性)

    (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値 重要価値領域(KVA) 市場価値(外側) 組織的な能力(内側)
  50. 71 EBMの重要価値指標(KVM)の例 KVM Measuring 従業員1人あたりの収益 この⽐率(総収益 / 従業員数)は業界内の主要な競争 指標である。業界によって大きく異なる。 プロダクトコスト⽐率

    計測対象のプロダクトやシステムにかかる総費用およ びコスト。運用コストも含まれる。 従業員満⾜度 従業員のエンゲージメント、エネルギー、熱意を計測 するのに役立つ感情分析の一種。 顧客満⾜度 プロダクトに 対する顧客のエンゲージメ ントと幸福度を計測す プロダクトに対する顧客のエンゲージメントと幸福度 を計測するのに役立つ感情分析の一種。 顧客使用指標 機能別の利用状況を計測して、顧客がプロダクトをど の程度有益だと思っているかを推測する。また、機能 にかける実際の使用時間が、期待と一致しているかを 確認する。 現在の価値(CV) 未実現の価値(UV) KVM Measuring 市場占有率 プロダクトが市場を占める相対的な割合。顧客 のニーズをよりよく満たした場合、そのプロダ クトが達成できるであろう潜在的な市場シェア。 顧客(ユーザー)満⾜度ギャップ 顧客またはユーザーが望む体験と実際の体験の 格差。 望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。 KVM Measuring ビルドと統合の頻度 単位時間あたりのビルド(統合されてテストされたもの)の回数。 頻繁にあるいは継続的にリリースしているチームであれば、実際のリ リース回数を計測する。 リリースの頻度 単位時間あたり(継続的、日次、週次、月次、四半期ごとなど)のリ リース回数。これは、新規的で競争力のあるプロダクトにおいて、顧 客を満足させるために必要な時間を評価するのに役立つ。 リリースの安定期間 開発者がリリースの準備ができたと言ったときから、プロダクトの問 題を修正して、実際に顧客にリリースされるまでにかかった時間。こ れは、貧弱な開発プラクティス、その基盤となる設計やコードベース の影響を表すのに役立つ。 平均修復時間 エラーが発見されてから修正されるまでの平均時間。これは、組織が エラーを修正するときの効率性を明らかにする。 顧客サイクルタイム リリース作業に着手してから実際にリリースするまでの時間。組織が 顧客にリーチするための能力を計測するのに役立つ。 リードタイム アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを 享受できるようになるまでの時間。顧客やプロダクトによって、この 指標は大きく異なる。顧客満足度の要因でもある。 変更のリードタイム コードがコミットされてから本番環境で正常に実行されるまでの時間。 Four Keysのひとつ。 デプロイ頻度 組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ (またはリリース)する回数。Four Keysのひとつ。 サービス復元時間 サービスの停⽌が開始されてからサービスの可用性が完全に回復する までの時間。Four Keysのひとつ。 学習時間 アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ の利用を学習するまでにかかる時間。 障害物除去時間 障害物が発生してから解決さるまでの平均時間。リードタイムや従業 員満足度の要因でもある。 ピボットまでの時間 真のビジネスアジリティの指標で、組織がフィードバックや新しい情 報を得てから、そのフィードバックに対応するまでの経過時間を表す。 例えば、競合他社が新たな市場獲得のための機能を提供したことを 知ってから、組織が顧客体験を計測できるほどに改善する新機能ある いはそれを超える機能を提供したりするまでの時間。 市場に出すまでの時間(T2M) KVM Measuring イノベーション率 新しいプロダクトの機能に費やした労力やコストを、すべてのプロダ クトに費やした労力やコストで割ったもの。新しいプロダクトの機能 を提供する組織のキャパシティについてのインサイトが 得られる。 ⽋陥のトレンド 前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー ザー、組織にとってのプロダクトの価値を低下させるものである。一 般的には、意図したとおりに動作しないことを指す。 オンプロダクト指標 チームがプロダクトと価値に費やす時間の割合。 インストールされた バージョンの指標 現在サポートしているプロダクトのバージョン数。これは、組織が古 いバージョンのサポートや保守にかけている労力を表している。 技術的負債 プログラミングにおける概念であり、「クイック・アンド・ダー ティ」なソリューションをあとで修正することになったときに発生す る。追加の開発やテストの作業を表したもの。価値の提供に 望ましくない影響を与え、回避可能な無駄とリスクの増加を生み出す。 本番環境のインシデ ントの数 インストールされたプロダクトの問題を修正するために開発チームが 特定の期間中断された回数。本番環境でのインシデントの回数は、本 番環境の安定性を⽰すのに役立つ。 プロダクト(コー ド)のアクティブな ブランチ数 プロダクトやサービスの異なるバージョン(または種類)の数。変更 による潜在的な影響とそれに伴う作業の複雑さについてのインサイト が得られる。 ブランチ間でコード をマージする時間 プロダクトやサービスの異なるバーション間で変更を適用するために 費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに ついてのインサイトが得られる。 コンテキストスイッ チにかかる時間 例えば、ミーティングや電話による中断された時間、タスクの切り替 えに費やした時間、チームメンバーがチーム外の人を助けるために中 断された時間がある。問題の規模を把握するのに役立 つ。 変更失敗率 リリースされたプロダクトのうち、サービスが低下し、修正を行う必 要が生じた割合(例: ホットフィックス、ロールバック、パッチ)。 Four Keysのひとつ。 イノベーションの能力(A2I) (参考) Scrum.org 長沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)
  51. 72 EBMの重要価値指標(KVM)の例 KVM Measuring 従業員1人あたりの収益 この⽐率(総収益 / 従業員数)は業界内の主要な競争 指標である。業界によって大きく異なる。 プロダクトコスト⽐率

    計測対象のプロダクトやシステムにかかる総費用およ びコスト。運用コストも含まれる。 従業員満⾜度 従業員のエンゲージメント、エネルギー、熱意を計測 するのに役立つ感情分析の一種。 顧客満⾜度 プロダクトに 対する顧客のエンゲージメ ントと幸福度を計測す プロダクトに対する顧客のエンゲージメントと幸福度 を計測するのに役立つ感情分析の一種。 顧客使用指標 機能別の利用状況を計測して、顧客がプロダクトをど の程度有益だと思っているかを推測する。また、機能 にかける実際の使用時間が、期待と一致しているかを 確認する。 現在の価値(CV) 未実現の価値(UV) KVM Measuring 市場占有率 プロダクトが市場を占める相対的な割合。顧客 のニーズをよりよく満たした場合、そのプロダ クトが達成できるであろう潜在的な市場シェア。 顧客(ユーザー)満⾜度ギャップ 顧客またはユーザーが望む体験と実際の体験の 格差。 望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。 KVM Measuring ビルドと統合の頻度 単位時間あたりのビルド(統合されてテストされたもの)の回数。 頻繁にあるいは継続的にリリースしているチームであれば、実際のリ リース回数を計測する。 リリースの頻度 単位時間あたり(継続的、日次、週次、月次、四半期ごとなど)のリ リース回数。これは、新規的で競争力のあるプロダクトにおいて、顧 客を満足させるために必要な時間を評価するのに役立つ。 リリースの安定期間 開発者がリリースの準備ができたと言ったときから、プロダクトの問 題を修正して、実際に顧客にリリースされるまでにかかった時間。こ れは、貧弱な開発プラクティス、その基盤となる設計やコードベース の影響を表すのに役立つ。 平均修復時間 エラーが発見されてから修正されるまでの平均時間。これは、組織が エラーを修正するときの効率性を明らかにする。 顧客サイクルタイム リリース作業に着手してから実際にリリースするまでの時間。組織が 顧客にリーチするための能力を計測するのに役立つ。 リードタイム アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを 享受できるようになるまでの時間。顧客やプロダクトによって、この 指標は大きく異なる。顧客満足度の要因でもある。 変更のリードタイム コードがコミットされてから本番環境で正常に実行されるまでの時間。 Four Keysのひとつ。 デプロイ頻度 組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ (またはリリース)する回数。Four Keysのひとつ。 サービス復元時間 サービスの停⽌が開始されてからサービスの可用性が完全に回復する までの時間。Four Keysのひとつ。 学習時間 アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ の利用を学習するまでにかかる時間。 障害物除去時間 障害物が発生してから解決さるまでの平均時間。リードタイムや従業 員満足度の要因でもある。 ピボットまでの時間 真のビジネスアジリティの指標で、組織がフィードバックや新しい情 報を得てから、そのフィードバックに対応するまでの経過時間を表す。 例えば、競合他社が新たな市場獲得のための機能を提供したことを 知ってから、組織が顧客体験を計測できるほどに改善する新機能ある いはそれを超える機能を提供したりするまでの時間。 市場に出すまでの時間(T2M) KVM Measuring イノベーション率 新しいプロダクトの機能に費やした労力やコストを、すべてのプロダ クトに費やした労力やコストで割ったもの。新しいプロダクトの機能 を提供する組織のキャパシティについてのインサイトが 得られる。 ⽋陥のトレンド 前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー ザー、組織にとってのプロダクトの価値を低下させるものである。一 般的には、意図したとおりに動作しないことを指す。 オンプロダクト指標 チームがプロダクトと価値に費やす時間の割合。 インストールされた バージョンの指標 現在サポートしているプロダクトのバージョン数。これは、組織が古 いバージョンのサポートや保守にかけている労力を表している。 技術的負債 プログラミングにおける概念であり、「クイック・アンド・ダー ティ」なソリューションをあとで修正することになったときに発生す る。追加の開発やテストの作業を表したもの。価値の提供に 望ましくない影響を与え、回避可能な無駄とリスクの増加を生み出す。 本番環境のインシデ ントの数 インストールされたプロダクトの問題を修正するために開発チームが 特定の期間中断された回数。本番環境でのインシデントの回数は、本 番環境の安定性を⽰すのに役立つ。 プロダクト(コー ド)のアクティブな ブランチ数 プロダクトやサービスの異なるバージョン(または種類)の数。変更 による潜在的な影響とそれに伴う作業の複雑さについてのインサイト が得られる。 ブランチ間でコード をマージする時間 プロダクトやサービスの異なるバーション間で変更を適用するために 費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに ついてのインサイトが得られる。 コンテキストスイッ チにかかる時間 例えば、ミーティングや電話による中断された時間、タスクの切り替 えに費やした時間、チームメンバーがチーム外の人を助けるために中 断された時間がある。問題の規模を把握するのに役立 つ。 変更失敗率 リリースされたプロダクトのうち、サービスが低下し、修正を行う必 要が生じた割合(例: ホットフィックス、ロールバック、パッチ)。 Four Keysのひとつ。 イノベーションの能力(A2I) (参考) Scrum.org 長沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10)
  52. 73 EBMの重要価値指標(KVM)の例 KVM Measuring 従業員1人あたりの収益 この⽐率(総収益 / 従業員数)は業界内の主要な競争 指標である。業界によって大きく異なる。 プロダクトコスト⽐率

    計測対象のプロダクトやシステムにかかる総費用およ びコスト。運用コストも含まれる。 従業員満⾜度 従業員のエンゲージメント、エネルギー、熱意を計測 するのに役立つ感情分析の一種。 顧客満⾜度 プロダクトに 対する顧客のエンゲージメ ントと幸福度を計測す プロダクトに対する顧客のエンゲージメントと幸福度 を計測するのに役立つ感情分析の一種。 顧客使用指標 機能別の利用状況を計測して、顧客がプロダクトをど の程度有益だと思っているかを推測する。また、機能 にかける実際の使用時間が、期待と一致しているかを 確認する。 現在の価値(CV) 未実現の価値(UV) KVM Measuring 市場占有率 プロダクトが市場を占める相対的な割合。顧客 のニーズをよりよく満たした場合、そのプロダ クトが達成できるであろう潜在的な市場シェア。 顧客(ユーザー)満⾜度ギャップ 顧客またはユーザーが望む体験と実際の体験の 格差。 望ましい顧客体験または満⾜度 顧客が望んでいる体験を⽰す指標。 KVM Measuring ビルドと統合の頻度 単位時間あたりのビルド(統合されてテストされたもの)の回数。 頻繁にあるいは継続的にリリースしているチームであれば、実際のリ リース回数を計測する。 リリースの頻度 単位時間あたり(継続的、日次、週次、月次、四半期ごとなど)のリ リース回数。これは、新規的で競争力のあるプロダクトにおいて、顧 客を満足させるために必要な時間を評価するのに役立つ。 リリースの安定期間 開発者がリリースの準備ができたと言ったときから、プロダクトの問 題を修正して、実際に顧客にリリースされるまでにかかった時間。こ れは、貧弱な開発プラクティス、その基盤となる設計やコードベース の影響を表すのに役立つ。 平均修復時間 エラーが発見されてから修正されるまでの平均時間。これは、組織が エラーを修正するときの効率性を明らかにする。 顧客サイクルタイム リリース作業に着手してから実際にリリースするまでの時間。組織が 顧客にリーチするための能力を計測するのに役立つ。 リードタイム アイデアが提案されて仮説が形成されてから、顧客がそのアイデアを 享受できるようになるまでの時間。顧客やプロダクトによって、この 指標は大きく異なる。顧客満足度の要因でもある。 変更のリードタイム コードがコミットされてから本番環境で正常に実行されるまでの時間。 Four Keysのひとつ。 デプロイ頻度 組織がプロダクトの新規バージョンを顧客またはユーザーにデプロイ (またはリリース)する回数。Four Keysのひとつ。 サービス復元時間 サービスの停⽌が開始されてからサービスの可用性が完全に回復する までの時間。Four Keysのひとつ。 学習時間 アイデアや改善をスケッチして、構築して、ユーザーに提供して、そ の利用を学習するまでにかかる時間。 障害物除去時間 障害物が発生してから解決さるまでの平均時間。リードタイムや従業 員満足度の要因でもある。 ピボットまでの時間 真のビジネスアジリティの指標で、組織がフィードバックや新しい情 報を得てから、そのフィードバックに対応するまでの経過時間を表す。 例えば、競合他社が新たな市場獲得のための機能を提供したことを 知ってから、組織が顧客体験を計測できるほどに改善する新機能ある いはそれを超える機能を提供したりするまでの時間。 市場に出すまでの時間(T2M) KVM Measuring イノベーション率 新しいプロダクトの機能に費やした労力やコストを、すべてのプロダ クトに費やした労力やコストで割ったもの。新しいプロダクトの機能 を提供する組織のキャパシティについてのインサイトが 得られる。 ⽋陥のトレンド 前回の計測から⽋陥の変化を計測したもの。⽋陥とは、顧客、ユー ザー、組織にとってのプロダクトの価値を低下させるものである。一 般的には、意図したとおりに動作しないことを指す。 オンプロダクト指標 チームがプロダクトと価値に費やす時間の割合。 インストールされた バージョンの指標 現在サポートしているプロダクトのバージョン数。これは、組織が古 いバージョンのサポートや保守にかけている労力を表している。 技術的負債 プログラミングにおける概念であり、「クイック・アンド・ダー ティ」なソリューションをあとで修正することになったときに発生す る。追加の開発やテストの作業を表したもの。価値の提供に 望ましくない影響を与え、回避可能な無駄とリスクの増加を生み出す。 本番環境のインシデ ントの数 インストールされたプロダクトの問題を修正するために開発チームが 特定の期間中断された回数。本番環境でのインシデントの回数は、本 番環境の安定性を⽰すのに役立つ。 プロダクト(コー ド)のアクティブな ブランチ数 プロダクトやサービスの異なるバージョン(または種類)の数。変更 による潜在的な影響とそれに伴う作業の複雑さについてのインサイト が得られる。 ブランチ間でコード をマージする時間 プロダクトやサービスの異なるバーション間で変更を適用するために 費やした時間。変更による潜在的な影響とそれに伴う作業の複雑さに ついてのインサイトが得られる。 コンテキストスイッ チにかかる時間 例えば、ミーティングや電話による中断された時間、タスクの切り替 えに費やした時間、チームメンバーがチーム外の人を助けるために中 断された時間がある。問題の規模を把握するのに役立 つ。 変更失敗率 リリースされたプロダクトのうち、サービスが低下し、修正を行う必 要が生じた割合(例: ホットフィックス、ロールバック、パッチ)。 Four Keysのひとつ。 イノベーションの能力(A2I) (参考) Scrum.org 長沢智治、⾓征典(翻訳)“Evidence-Based Management Guide” 2020-9 p.13-P.16 https://www.scrum.org/resources/evidence-based-management-guide (参照2023-1-10) 市 場 価 値 ( 外 側 ) 組織的な能力(内側) DevEx Flow State Feedback Loops Cognitive Load
  53. 75 IT企業の価値は言葉に宿る •Mission、Vision、Valueの大切さ ✓ Mission(目的): 自分たちの会社は何のためにあるのか。 ✓ Vision(夢): どういう未来を築きたいと、自分たちは思っているか。 ✓

    Value(信念): どういうバリューや信念(ビリーフ)を、自分たちは大事にしているか。 “現代では世界のほぼすべての企業が「社是」とか、「経営理念」とか、 「行動指針」とか、「企業理念」とか、その他、それに類したもの掲げてい る。小さいカードにその言葉を印刷して、全員に常に持ち歩かせている企業 もある。そのねらいは、バリューを社内の隅々にまで浸透させることで、社 員全員が日々、そのバリューに従って行動できるようにするためである。” ワイズカンパニー: 知識創造から知識実践への新しいモデル (野中 郁次郎 (著), 竹内 弘高 (著), 黒輪 篤嗣 (翻訳), 2020, p.034)
  54. 77 Value 変わり続けるために、学び続ける お客様の本質的課題解決 その行動で、ブレイクスルー 事業づくりは、仲間づくり 価値あることを、正しくやろう 一度きりの人生、せっかく何かに取り組むなら、 誰にでも胸を張って伝えられる仕事をしよう。 お客様、株主、社内外の仲間、家族、そして自分。

    関わるすべての人が幸せになる事業を創る。 この思いを常に忘れず、 これからも道の真ん中を堂々と突き進もう。 変化し続ける時代で、何かを変えたいと思うのなら、 自分自身が一番変わっていこう。 学びは変わることを後押ししてくれる。 変わり続けることは難しく、時に苦しいけれど、 あなたの視野と可能性を広げ、 結果として人生の幸せへとつながっていく。 ユーザーという言葉も含め、 一人一人が有機的な心を持つ「お客様」であると定義し、 お客様の体験を常に想像しながら、 本質的な課題を引き出し、抜本的に解決しよう。 それこそが期待以上の成果や品質、 ひいては私たちが受け取る対価となるのだから。 誰かの主体性に頼ることなく、 自らが事業やサービスのオーナーシップを持って 考え、発言し、行動していこう。 そうすれば 、短期的な成果のために 長期的な価値を犠牲にすることもない。 いま自分にできることを考え、最初の一歩を踏み出し、 一人一人がブレイクスルーしていこう。 事業づくりにおいて、 一人の力で成し遂げられることには限界がある。 だからこそ、志を遠慮なく発信し、仲間を見つけ、 どんどん巻き込んでいくことによって、 想像もできないほどの大きな推進力を生み出そう。 そして、最高の仲間と歴史を創ろう。 01 02 03 04 05
  55. 計測の重要性:Opinion vs Fact(意見か事実か) Problem(問題) Solution(解決策) Fact(事実) Opinion(意見) 設計 デプロイ 仮説を実装

    する 仮説を 動かす 結果を 検証する 仮説 対策の仮説 を立てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」の図を変更 仮説を立てるには、 計測データを検証す る必要がある。
  56. 85 指標構造|全体のイメージ 企業 事業 サービス プロダクト プロジェクト 開発チーム プロダクト開発指標 各ブロックが複数指標を保有し、

    さらに各ブロックの指標やアウトカムが下層から上層へ影響を及ぼすも のとして設計しています。 将来的には企業ミッションや企業アウトカム指標との相関性を可視化し ますが、まずはプロダクト開発指標の可視化を行います。
  57. 86 指標構造|プロダクト下 - 3つの指標領域 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満足度

    プロダクト開発指標 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します アウトカム指標は、3つの指標群(営業、マーケティング、プロダクト開発)により可視化できると考えています。 • 記載の指標、順序等は仮です • 指標単体のみでなく、相関性をもたせた可視化も行います
  58. 87 指標構造|プロダクト下 - 3つの指標領域 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満足度

    プロダクト開発指標 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します アウトカム指標は、3つの指標群(営業、マーケティング、プロダクト開発)により可視化できると考えています。 • 記載の指標、順序等は仮です • 指標単体のみでなく、相関性をもたせた可視化も行います ブラックボックスになりがち
  59. 88 指標構造|相関性の例 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満⾜度 プロダクト開発指標 営業指標

    マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 (工数) スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します 例えば、このような相関性が見られる可能性があります。 • 記載の指標、順序等は仮です • 指標単体のみでなく、相関性をもたせた可視化も行います ブラックボックスになりがち
  60. 89 指標構造|相関性の例 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満⾜度 プロダクト開発指標 営業指標

    マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 (工数) スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します 例えば、このような相関性が見られる可能性があります。 • 記載の指標、順序等は仮です • 指標単体のみでなく、相関性をもたせた可視化も行います
  61. 90 指標構造|相関性の例 アウトカム指標 現在の品質、維持向上 開発進捗 障害 開発パフォーマンス 顧客満⾜度 プロダクト開発指標 営業指標

    マーケティング指標 市場占有率 売上 利益 契約企業数 登録ユーザー数 スカウト数 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 計画リリース率 緊急リリース率 FourKeys オンプロダクト指標 (工数) スコープ 時間 予算 デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 ケイパビリティ e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 開発チームの能力・コンディション 開発チーム組成 年齢 性別 職位 アウトカム指標はプロダクト/プロジェクトにより変わります 1〜複数存在します 例えば、このような相関性が見られる可能性があります。 • 記載の指標、順序等は仮です • 指標単体のみでなく、相関性をもたせた可視化も行います プロダクト開発が見えていないと、 対策が間違っている可能性がある……
  62. 122 SODAのキーメソッド •Software Outcome Delivery Architecture (SODA) を組織にインストールするため のキーメソッドを以下のように定義している。 •「仮説と実験」を繰り返しながら成長する組織を目指す。

    ((SODA)) Team Performance ✓すべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value ✓プロダクトごとに有意な品質指標を見極めフィードバックプロセスを増やし、プロダ クト品質を向上させる ((SODA)) Outcome Delivery ✓プロダクトごとにアウトカム指標を見極め、計測する ((SODA)) Project Value ✓プロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント を行えるようにする ((SODA)) Evidence Viewer ✓プロダクト開発チームのエビデンスデータを見える化する ((SODA)) Playbook ✓プロダクトに関するナレッジベースを作成しSECIモデルを作る
  63. 127 SODAのキーメソッド •Software Outcome Delivery Architecture (SODA) を組織にインストールするため のキーメソッドを以下のように定義している。 •「仮説と実験」を繰り返しながら成長する組織を目指す。

    ((SODA)) Team Performance ✓すべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value ✓プロダクトごとに有意な品質指標を見極めフィードバックプロセスを増やし、プロダ クト品質を向上させる ((SODA)) Outcome Delivery ✓プロダクトごとにアウトカム指標を見極め、計測する ((SODA)) Project Value ✓プロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント を行えるようにする ((SODA)) Evidence Viewer ✓プロダクト開発チームのエビデンスデータを見える化する ((SODA)) Playbook ✓プロダクトに関するナレッジベースを作成しSECIモデルを作る
  64. 129 SODAのキーメソッド •Software Outcome Delivery Architecture (SODA) を組織にインストールするため のキーメソッドを以下のように定義している。 •「仮説と実験」を繰り返しながら成長する組織を目指す。

    ((SODA)) Team Performance ✓すべてのプロダクトにFour Keysの計測を定着させ、改善サイクルを作る ((SODA)) Quality Value ✓プロダクトごとに有意な品質指標を見極めフィードバックプロセスを増やし、プロダ クト品質を向上させる ((SODA)) Outcome Delivery ✓プロダクトごとにアウトカム指標を見極め、計測する ((SODA)) Project Value ✓プロジェクトごとに有意なマネジメント指標を計測し段階や例外によるマネジメント を行えるようにする ((SODA)) Evidence Viewer ✓プロダクト開発チームのエビデンスデータを見える化する ((SODA)) Playbook ✓プロダクトに関するナレッジベースを作成しSECIモデルを作る これらのメソッドを 組織にインプリメントする
  65. テーラリング Software Outcome Delivery Architecture(SODA): BizReach ver. •SODA BizReachは、今後プロダクト組織の成熟度 に合わせて仕組みを変えていく必要がありますが、

    現在は右図のような構成で考えています。 深さ 広さ 構造 時間 型 • 上記のSODA Prototypeを元に、ビズリーチに合 わせてテーラリングを行いました。 • テーラリング後のSODA PrototypeをSODA BizReachと呼ぶことにします。
  66. 147

  67. 148

  68. 149

  69. Software Outcome Delivery Architecture(SODA): BizReach ver. 市場に出すまでの時間(反応性) (T2M: Time-to-Market) 新しい能力、サービス、製品を迅速

    に提供する能力 イノベーションの能力(効果性) (A2I: Ability to Innovate) 顧客やユーザーのニーズにより良く 応えられるような新しい能力を提供 する能力 現在の価値 (CV: Current Value) 現在、顧客やユーザーに提供された 価値 未実現の価値 (UV: Unrealized Value) 顧客やユーザーの潜在的なニーズを すべて満たすことによって実現しう る価値