Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却 / JaSST'24 ...

テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却 / JaSST'24 Tokyo

2024年3月14日より開催された「JaSST'24 Tokyo」の登壇資料です。
https://jasst.jp/symposium/jasst24tokyo.html

▼関連資料
開発者体験を見える化し「計器飛行」の実現を目指すSODA構想 〜事業の成長とプロダクト組織能力の相関関係を見いだすには〜
https://speakerdeck.com/visional_engineering_and_design/developer-experience-day-2023

ファクトから始める改善アプローチ 〜「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. テストだけで品質は上がらない?! エセ⾃⼰組織化した品質組織からの脱却 ソフトウェアテストシンポジウム 2024 東京 JaSST'24 Tokyo: Day2, 2024/3/15 Visionalグループ

    株式会社ビズリーチ リクルーティングプロダクト本部 PMO室 SODA推進グループ / ⽇科技連 SQiP アジャイルSQC研究部会 ⾼橋裕之
  2. 3 本⽇の構成 前編:指標構造の全体感 • ⾼橋 裕之(ビズリーチ) • テストだけで品質は上がらない?!: fake self-organization(エセ⾃⼰

    組織化)とは • 「アウトプット」より「アウトカ ム」:指標構造で捉える事業状況 • Software Outcome Delivery Architecture:SODA構想 後編:品質管理のための指標構造 • 荻野 恒太郎(カカクコム) • ⾷べログの品質管理のための指標 構造 ~昔ながらの品質管理とアジャイル 開発の開発⽣産性の融合~
  3. 7 本来の「⾃⼰組織化(self-organization)」とは? Alexey Kljatov, CC BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0> Mikkabie, CC

    BY-SA 4.0 <https://creativecommons.org/licenses/by-sa/4.0> TANAKA Juuyoh (⽥中⼗洋), CC BY 2.0 <https://creativecommons.org/licenses/by/2.0> 雪の結晶 みそ汁の中の模様 イワシの群れの動き
  4. 8 本来の「⾃⼰組織化(self-organization)」とは? “「⾃⼰組織化」とは「ランダムになろうとする⼒に、 秩序化しようとする⼒が打ち勝つこと」である。” (参考)都甲 潔. 林 健司. 江崎 秀.

    ⾃⼰組織化とは何か―⽣物の形やリズムが⽣まれる原理を探る. 講談社, 1999, 241p. ランダム 秩序 ⾮線形性 エントロピー⼤ 平衡系(静的) ⾮平衡系(動的) 雪の結晶、⽣体膜、リポソーム、 ⼈⼯味細胞膜、(将来の) 分⼦素⼦、 マイクロマシン リズム、パターン、カオス 協同現象 (相転移)
  5. 9 スクラム⽂脈における「⾃⼰組織化」 •⽐較的初期※1のスクラムガイドから「⾃⼰組織化」という⾔葉は使われてきた。 •例えば「スクラムガイド2017年10⽉版」では以下のように説明されている(⼀部)。 •しかし、最新※2の「スクラムガイド2020年11⽉版」で「⾃⼰組織化」という⾔葉 が消える。何が起きたのだろうか。 “スクラムチームは⾃⼰組織化されており、機能横断的である。⾃⼰組織化チームは、作 業を成し遂げるための最善の策を、チーム外からの指⽰ではなく、⾃分たちで選択する。 機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能⼒を持っている。” ※1

    Scrumの元となった⽵内弘⾼⽒、野中郁⼆郎⽒の論⽂「The New New Product Development Game」に⾃⼰組織化は登場しており、スクラムガイド2009年5⽉版以降で使われてきた。 ※2 2024年3⽉15⽇現在 “開発チームには、以下のような特徴がある。 • ⾃⼰組織化されている。プロダクトバックログをリリース判断可能な機能のインクリ メントに変える⽅法は、誰も(スクラムマスターでさえも)教えてくれない。 • (以降、略)”
  6. 10 「⾃⼰組織化」という⽂⾔の消滅 •InfoQ 2020/12/24 の記事 •スクラムガイド 2020の変更点: Ken Schwaber⽒とJeff Sutherland⽒とのQ&A

    “Sutherland⽒: 2020年版スクラムガイドは、より短く、より焦点を 絞り、One Teamを掲げています。3つの成果物をコミットメントで ⽬標に結びつけることに加え、業界の最⼤の課題である「リードし ないサーバントリーダー」と「⾃⼰組織化した開発者が好き勝⼿ やってコミットメントを守らない」という2つの課題に取り組みまし た。” (参考) Ben Linders InfoQ ”Changes in the 2020 Scrum Guide: Q&A with Ken Schwaber and Jeff Sutherland” 2020-12 https://www.infoq.com/articles/changes-2020-Scrum-guide/ (参照 2023-1-10) “⾃⼰組織化(Self-organization)とは、複雑系理論(Complex Systems Theory)の概念で知的システムがゴールを達成するために⾃⼰組織化 する、といったものです。そこで私たちは、チームが「⾃⼰組織 化」という⾔葉を盾に、あらゆるコミットメントを回避することを 避けるために「⾃⼰管理」という⾔葉を使うようになりました。 チームは、ゴールを達成するためのコミットメントを実現するため に⾃⼰管理するのです。”
  7. 11 「エセ⾃⼰組織化」症候群 俺たち ⾃⼰組織化 してる Goals (⽬的) おーい 真の⽬的を忘れ、⾃分たちは「⾃律している」と 思い込み次々と間違った決断をしてしまう状態を

    「エセ⾃⼰組織化」症候群と名付けた。 「やりたいことだけやりたがるエンジニア」 「⾃⼰組織化を盾に約束を守らないチーム」 「待てど暮らせど成果がでないチーム」 どうやら、世界中のあちこちで起きていた症状
  8. 13 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev プロダクト開発チーム
  9. 14 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev プロダクト開発チーム 成果物α 仕様化 プロセス 設計 プロセス テスト プロセス 成果物β 成果物γ 成果物δ 成果物ε in out in in out out in プロダクトは、成果物とプロセスの連鎖で⽣み出される (実際はもっと複雑)
  10. 15 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織?
  11. 16 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? プロセスの境界では 「役割分担」バイアスで エセ⾃⼰組織化されやすい
  12. 17 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? BUG ⾒つけた!
  13. 18 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? BUG ⾒つけた!
  14. 19 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? BUG ⾒つけた!
  15. 20 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? テスト⼯数が少ないので 修正をやめてください! 最近バグが多いので 信⽤なりません! テストケースを倍にします! 開発が リリース回数増やすから 障害増えたじゃないか! ※個⼈の経験です。当社のエピソードではありません。 品質を守るために 開発と仲良くするな! ⾒つけた!
  16. 21 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? テスト⼯数が少ないので 修正をやめてください! 最近バグが多いので 信⽤なりません! テストケースを倍にします! 開発が リリース回数増やすから 障害増えたじゃないか! ※個⼈の経験です。当社のエピソードではありません。 品質を守るために 開発と仲良くするな! テストしすぎ! QAがボトルネックになって リリースが遅れた! 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した! ⾒つけた!
  17. 22 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? ※個⼈の経験です。当社のエピソードではありません。 テスト⼯数が少ないので 修正をやめてください! 最近バグが多いので 信⽤なりません! テストケースを倍にします! 開発が リリース回数増やすから 障害増えたじゃないか! 品質を守るために 開発と仲良くするな! テストしすぎ! QAがボトルネックになって リリースが遅れた! 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい ⾒つけた! QAで検出できなかったから バグが市場に流出した!
  18. 23 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織? 品質組織? 私 vs あなた …という対⽴が起きやすい
  19. 24 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev プロダクト開発チーム 品質 スピード
  20. 25 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 開発組織? 品質組織? 品質 スピード ඼࣭ 2 ͱεϐʔυ % ͸ τϨʔυΦϑʁ
  21. 26 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 開発組織? 品質組織? 品質 スピード ඼࣭ 2 ͱεϐʔυ % ͸ τϨʔυΦϑʁ テスト⼯数が少ないので 修正をやめてください! 最近バグが多いので 信⽤なりません! テストケースを倍にします! 開発が リリース回数増やすから 障害増えたじゃないか! 品質を守るために 開発と仲良くするな! テストしすぎ! QAがボトルネックになって リリースが遅れた! 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した! 「役割分担」バイアス unconscious bias
  22. 27 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 開発組織? 品質組織? 品質 スピード ඼࣭ 2 ͱεϐʔυ % ͸ τϨʔυΦϑʁ テスト⼯数が少ないので 修正をやめてください! 最近バグが多いので 信⽤なりません! テストケースを倍にします! 開発が リリース回数増やすから 障害増えたじゃないか! 品質を守るために 開発と仲良くするな! テストしすぎ! QAがボトルネックになって リリースが遅れた! 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した!
  23. 28 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 開発組織? 品質組織? リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる 品質 スピード
  24. Four Keys 品質 スピード リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる

    変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 ඼࣭ 2 ͱεϐʔυ % ͸τϨʔυΦϑͰ͸ͳ͍
  25. 30 DORA Metrics •原書は「Accelerate: The Science Behind Devops: Building and

    Scaling High Performing Technology Organizations」 •2018年3⽉出版、⽇本語版は2018年11⽉に出版。 •迅速かつ⾼品質なデリバリを実施している組織とそうでない組織の違いに関する 研究結果をDORAがまとめている。 IUUQTCPPLJNQSFTTDPKQCPPLT IUUQTXXXPSFJMMZDPNMJCSBSZWJFXBDDFMFSBUF
  26. 31 DORA Metrics •DORAは2018年よりGoogle Cloudと共同で実施しており、毎年調査レポート (State of DevOps)を公表している。 (参考)Google Cloud.

    ”2023 年の State of DevOps Report: 組織⽂化の重要性”. Google Cloud blog. 2023-10-19, https://cloud.google.com/blog/ja/products/devops-sre/announcing-the-2023-state-of-devops-report , (参照 2023-10-19)
  27. 32 DORA Metrics 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 信頼性(可⽤性) Four

    Keys 27のケイパビリティ 統計的相関 (参考)Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10)
  28. 計測の重要性:Opinion vs Fact(意⾒か事実か) Problem(問題) Solution(解決策) Fact(事実) Opinion(意⾒) 設計 デプロイ 仮説を実装

    する 仮説を 動かす 結果を 検証する 仮説 対策の仮説 を⽴てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉⽻⿓太郎さん「カイゼンの基本」の図を変更 仮説を⽴てるには、 計測データを検証す る必要がある。
  29. 35 Tom DeMarco (1940 - ) *1: https://www.oreilly.com/library/view/peopleware-productive-projects/9780133440706/pref02.xhtml Photo of

    Tom DeMarco by Hans-Rudolf Schulz (*1) ソフトウェア・エンジニア コンサルタント DFD(data flow diagram)の⽣みの親
  30. 36 ソフトウェアエンジニアリングの歴史的「格⾔」 「計測できないものは制御できない」 “You canʼt control what you canʼt measure.”

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

    Tom DeMarco(1982) ”Controlling Software Projects: Management, Measurement, and Estimation” (Prentice Hall/Yourdon Press, 1982) 呪⾔
  32. 38 「測定できないものは制御できない」は誤りだった? •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)
  33. 39 「測定できないものは制御できない」は誤りだった? •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)
  34. 信頼・対価(売上) 49 アウトカムとは 事業会社 顧客 プロダクト・サービス提供 良かった! 継続 ඼࣭ 2

    ͱεϐʔυ % 開発進捗 障害 ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 アウトカム向上 事業状況を可視化することで、 アウトカムに影響を及ぼす指標が見えてくる
  35. 50 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  36. 51 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  37. 52 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  38. 53 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  39. 54 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  40. 55 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  41. 56 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 ϓϩμΫτ։ൃ͕ݟ͍͑ͯͳ͍ͱɺ ରࡦ͕ؒҧ͍ͬͯΔՄೳੑ͕͋Δʜʜ アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  42. 57 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。 アウトカム
  43. 58 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。 アウトカム これらを計測するためには 事業組織を構造的に 捉える必要がある
  44. 64 指標構造|プロダクト下 - 3つの指標領域 ඼࣭ 2 ͱεϐʔυ % 開発進捗 障害

    ։ൃνʔϜ パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 ച্ 利益 契約企業/HH数 登録ユーザー数 6)4 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 ো֐਺ ো֐Ϩϕϧ %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標 スコープ 4 時間 % 予算 $ デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) ޻਺ 勤務年数 ϓϩμΫτ૊৫ͷコンディション 開発チーム組成 年齢 性別 ౳ڃ ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 2 ͱεϐʔυ プロダクト開発指標 アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  45. 計測の重要性:Opinion vs Fact(意⾒か事実か) Problem(問題) Solution(解決策) Fact(事実) Opinion(意⾒) 設計 デプロイ 仮説を実装

    する 仮説を 動かす 結果を 検証する 仮説 対策の仮説 を⽴てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉⽻⿓太郎さん「カイゼンの基本」の図を変更 仮説を⽴てるには、 計測データを検証す る必要がある。
  46. 計測の重要性:Opinion vs Fact(意⾒か事実か) Problem(問題) Solution(解決策) Fact(事実) Opinion(意⾒) 設計 デプロイ 仮説を実装する

    (改善活動) 仮説を動かす (改善活動) 結果を 検証する 仮説 改善アプローチ の仮説を⽴てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉⽻⿓太郎さん「カイゼンの基本」の図を変更 SODAの計測結果を 元にプロセス改善サ イクルが回りはじめ る SODA
  47. 69 本⽇の構成 前編:指標構造の全体感 • ⾼橋 裕之(ビズリーチ) • テストだけで品質は上がらない?!: fake self-organization(エセ⾃⼰

    組織化)とは • 「アウトプット」より「アウトカ ム」:指標構造で捉える事業状況 • Software Outcome Delivery Architecture:SODA構想 後編:品質管理のための指標構造 • 荻野 恒太郎(カカクコム) • ⾷べログの品質管理のための指標 構造 ~昔ながらの品質管理とアジャイル 開発の開発⽣産性の融合~