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

https://speakerdeck.com/visional_engineering_and_design/jasst24-tokyo
のクローンです。

Transcript

1. テストだけで品質は上がらない?! エセ自己組織化した品質組織からの脱却 ソフトウェアテストシンポジウム 2024 東京 JaSST'24 Tokyo: Day2, 2024/3/15 Visionalグループ 株式会社ビズリーチ リクルーティングプロダクト本部 PMO室 SODA推進グループ / 日科技連 SQiP アジャイルSQC研究部会 高橋裕之
2. 2 アジャイルSQC研究部会とは ⚫設立主旨 アジャイル開発においてもFour Keysなどの定量化が適用されてきており、その 範囲はどんどん広がっていくと考えられます。しかし我が国ではまだあまり事例 が共有されておらず、どのような定量化がどのような状況に適しているのか、ど のような分析技法があるのか、などの議論はほとんど行われていません。そこで アジャイルSQC研究会では、企業や組織の枠組みを超えてアジャイル開発におけ る定量化および分析の議論や研究を行い、その成果を産学に還元することで貢献 して参ります。 ⚫運営委員（敬称略、五十音順） •荻野 恒太郎（カカクコム） •坂田 晶紀（富士通） •山口 鉄平（LayerX） https://www.juse.or.jp/sqip/agile_sqc/index.html
3. 3 本日の構成 前編：指標構造の全体感 • 高橋 裕之（ビズリーチ） • テストだけで品質は上がらない?!： fake self-organization（エセ自己 組織化）とは • 「アウトプット」より「アウトカ ム」：指標構造で捉える事業状況 • Software Outcome Delivery Architecture：SODA構想 後編：品質管理のための指標構造 • 荻野 恒太郎（カカクコム） • 食べログの品質管理のための指標 構造 ~昔ながらの品質管理とアジャイル 開発の開発生産性の融合~
4. 4 自己紹介 数々の受託プロジェクトを経験し、フリーランスを経て、1996年に日立通信システム株式会社 （現・日立情報通信エンジニアリング）に入社。同社で交換機やIP機器の開発に携わった。2002 年にソニーデジタルネットワークアプリケーションズ株式会社に入社し、コンシューマ向けカメラ 開発や全社プロセス改善に取り組む。2013年にウイングアーク１ｓｔ株式会社に入社。2018年か ら品質管理部部長、製品品質管理責任者、およびOSS管理責任者を兼任。2021年7月に株式会社ビ ズリーチに入社しSPI（ソフトウェアプロセス改善）に従事、SODA構想を立案・推進。 Certified ScrumMaster® Advanced Certified ScrumMaster® Certified Scrum Product Owner® Certified Scrum Professional® - ScrumMaster Certified Scrum Professional® - Product Owner Certified Agile Leadership Essentials® Certified Agile Leadership for Organizations® Mobius Outcome Delivery Certified Practitioner PRINCE2® Foundation Certificate in Project Management 高橋 裕之（Hiroyuki TAKAHASHI） 趣味 山、海、小説、漫画、映画、ランニング 経歴
5. fake self-organization （エセ自己組織化） とは テストだけで品質は上がらない?! 5
6. 6 本来の「自己組織化(self-organization)」とは？ “一見、複雑で無秩序な系において、自律的に形成される秩序だったパターン。いずれも外部からの意図的な制御なし に、基本的な物理法則に則って時間的・空間的秩序が形成され、また、維持される。ベナール対流、結晶成長、ベロ ウソフジャボチンスキー反応、心筋の律動、ニューラルネットワークの構築をはじめ、物理学、化学、生物学、情報 科学など、幅広い分野で見いだされ、いわゆる複雑系に現れる特徴の一つに挙げられる。自発的秩序形成。” 出典：デジタル大辞泉（小学館） “無秩序に向かう自然界の流れ(熱力学第2法則)に逆らい、系がエネルギーを取り込みながら自分を組織だて、秩序を生 むこと。結晶の生成や化学反応のリズムなどさまざまな場面でみられ、体表の模様づくりなど生物界でも目立つ。系 を形づくる要素同士の働き合いが鍵を握る。カオスなどと並んで複雑系科学の主役。ナノテクノロジーに利用して量 子点(量子ドット)をつくる試みなどもある。” 出典：知恵蔵（朝日新聞出版）
7. 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> 雪の結晶 みそ汁の中の模様 イワシの群れの動き
8. 8 本来の「自己組織化(self-organization)」とは？ “「自己組織化」とは「ランダムになろうとする力に、 秩序化しようとする力が打ち勝つこと」である。” （参考）都甲 潔. 林 健司. 江崎 秀. 自己組織化とは何か―生物の形やリズムが生まれる原理を探る. 講談社, 1999, 241p. ランダム 秩序 非線形性 エントロピー大 平衡系（静的） 非平衡系（動的） 雪の結晶、生体膜、リポソーム、 人工味細胞膜、(将来の) 分子素子、 マイクロマシン リズム、パターン、カオス 協同現象 (相転移)
9. 9 スクラム文脈における「自己組織化」 •比較的初期※1のスクラムガイドから「自己組織化」という言葉は使われてきた。 •例えば「スクラムガイド2017年10月版」では以下のように説明されている(一部)。 •しかし、最新※2の「スクラムガイド2020年11月版」で「自己組織化」という言葉 が消える。何が起きたのだろうか。 “スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作 業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。 機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。” ※1 Scrumの元となった竹内弘高氏、野中郁二郎氏の論文「The New New Product Development Game」に自己組織化は登場しており、スクラムガイド2009年5月版以降で使われてきた。 ※2 2024年3月15日現在 “開発チームには、以下のような特徴がある。 • 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリ メントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。 • (以降、略)”
10. 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)の概念で知的システムがゴールを達成するために自己組織化 する、といったものです。そこで私たちは、チームが「自己組織 化」という言葉を盾に、あらゆるコミットメントを回避することを 避けるために「自己管理」という言葉を使うようになりました。 チームは、ゴールを達成するためのコミットメントを実現するため に自己管理するのです。”
11. 11 「エセ自己組織化」症候群 俺たち 自己組織化 してる Goals (目的) 真の目的を忘れ、自分たちは「自律している」と 思い込み次々と間違った決断をしてしまう状態を 「エセ自己組織化」症候群と名付けた。 「やりたいことだけやりたがるエンジニア」 「自己組織化を盾に約束を守らないチーム」 「待てど暮らせど成果がでないチーム」 どうやら、世界中のあちこちで起きていた症状
12. 12 エセ自己組織化した品質組織とは？
13. 13 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev プロダクト開発チーム
14. 14 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev プロダクト開発チーム 成果物α 仕様化 プロセス 設計 プロセス テスト プロセス 成果物β 成果物γ 成果物δ 成果物ε in out in in out out in プロダクトは、成果物とプロセスの連鎖で生み出される （実際はもっと複雑）
15. 15 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？
16. 16 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ プロセスの境界では 「役割分担」バイアスで エセ自己組織化されやすい
17. 17 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ BUG 見つけた！
18. 18 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ BUG 見つけた！
19. 19 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ BUG 見つけた！
20. 20 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ テスト工数が少ないので 修正をやめてください！ 最近バグが多いので 信用なりません！ テストケースを倍にします！ 開発が リリース回数増やすから 障害増えたじゃないか！ ※個人の経験です。当社のエピソードではありません。 品質を守るために 開発と仲良くするな！ 見つけた！
21. 21 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ テスト工数が少ないので 修正をやめてください！ 最近バグが多いので 信用なりません！ テストケースを倍にします！ 開発が リリース回数増やすから 障害増えたじゃないか！ ※個人の経験です。当社のエピソードではありません。 品質を守るために 開発と仲良くするな！ テストしすぎ！ QAがボトルネックになって リリースが遅れた！ 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した！ 見つけた！
22. 22 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ ※個人の経験です。当社のエピソードではありません。 テスト工数が少ないので 修正をやめてください！ 最近バグが多いので 信用なりません！ テストケースを倍にします！ 開発が リリース回数増やすから 障害増えたじゃないか！ 品質を守るために 開発と仲良くするな！ テストしすぎ！ QAがボトルネックになって リリースが遅れた！ 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい 見つけた！ QAで検出できなかったから バグが市場に流出した！
23. 23 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ 私 vs あなた …という対立が起きやすい
24. 24 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev プロダクト開発チーム 品質 スピード
25. 25 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 開発組織？ 品質組織？ 品質 スピード 品質(Q)とスピード(D)は トレードオフ？
26. 26 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 開発組織？ 品質組織？ 品質 スピード 品質(Q)とスピード(D)は トレードオフ？ テスト工数が少ないので 修正をやめてください！ 最近バグが多いので 信用なりません！ テストケースを倍にします！ 開発が リリース回数増やすから 障害増えたじゃないか！ 品質を守るために 開発と仲良くするな！ テストしすぎ！ QAがボトルネックになって リリースが遅れた！ 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した！ 「役割分担」バイアス unconscious bias
27. 27 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 開発組織？ 品質組織？ 品質 スピード 品質(Q)とスピード(D)は トレードオフ？ テスト工数が少ないので 修正をやめてください！ 最近バグが多いので 信用なりません！ テストケースを倍にします！ 開発が リリース回数増やすから 障害増えたじゃないか！ 品質を守るために 開発と仲良くするな！ テストしすぎ！ QAがボトルネックになって リリースが遅れた！ 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した！
28. 28 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 開発組織？ 品質組織？ リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる 品質 スピード
29. Four Keys 品質 スピード リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 品質(Q)とスピード(D)はトレードオフではない
30. 30 DORA Metrics •原書は「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 •2018年3月出版、日本語版は2018年11月に出版。 •迅速かつ高品質なデリバリを実施している組織とそうでない組織の違いに関する 研究結果をDORAがまとめている。 https://book.impress.co.jp/books/1118101029 https://www.oreilly.com/library/view/accelerate/9781457191435/
31. 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)
32. 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)
33. 計測の重要性：Opinion vs Fact（意見か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意見） 設計 デプロイ 仮説を実装 する 仮説を 動かす 結果を 検証する 仮説 対策の仮説 を立てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」の図を変更 仮説を立てるには、 計測データを検証す る必要がある。
34. 指標構造で捉える事業状況 「アウトプット」より「アウトカム」 34
35. 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）の生みの親
36. 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)
37. 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) 呪言
38. 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)
39. 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)
40. 40 もっと重要なのは…… プロジェクトを 時間通り、予算通りに 終わらせることよりも プロダクトで 世界を変えるような、あるいは企業 やビジネスのあり方を変えるような ソフトウェアを作るという「変革」
41. 41 もっと重要なのは…… プロジェクトを 時間通り、予算通りに 終わらせることよりも プロダクトで 世界を変えるような、あるいは企業 やビジネスのあり方を変えるような ソフトウェアを作るという「変革」 「アウトプット」より「アウトカム」
42. 42 アウトカムとは 事業会社
43. 43 アウトカムとは 顧客 困った 事業会社
44. 44 アウトカムとは 顧客 困った プロダクト・サービス提供 事業会社
45. 45 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ 事業会社
46. 46 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ アウトカム向上 事業会社
47. 信頼・対価(売上) 47 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ 事業会社 アウトカム向上
48. 信頼・対価(売上) 48 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ 継続 事業会社 アウトカム向上
49. 信頼・対価(売上) 49 アウトカムとは 事業会社 顧客 プロダクト・サービス提供 良かった！ 継続 品質(Q)とス ピード(D) 開発 進捗 障害 開発 チーム パフ ォーマ ンス 顧客 満足度 営業 指標 マー ケティ ング指 標 市場 占有率 売上 利益 契約 企業/HH数 登録 ユーザ ー数 UHS 求人 数 内定 率 入社 人数 レジ ュメ数 応募 数 内定 承諾率 障害 数 障害 レベル DORAメト リクス （FourKeysなど ） オン プロダ クト指 標 スコ ープ(S) 時間(D) 予算(C) デリ バリー の変更 率 進捗 率 スコ ープの 達成率 マイ ルスト ーン達 成率 人件 費 固定 費 開発 ツール 費 e-NPS パル スサー ベイ DiSC （ 行動 特 性） 勤怠 勤務 年数 プロ ダクト 組織のコン ディシ ョン 開発 チーム 組成 年齢 性別 職位 エン ジニア 個人ケ イパビ リティ コミ ット数 平均 コミッ トサイ ズ PR作成 数・マ ージ数 コー ド行数 平均PRクロ ーズ時 間 Is sue tic ket クロ ーズ 数 品質(Q)とス ピード プロ ダクト 開発指 標 アウトカム向上 事業状況を可視化することで、 アウトカムに影響を及ぼす指標が見えてくる
50. 50 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
51. 51 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
52. 52 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
53. 53 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
54. 54 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
55. 55 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
56. 56 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 プロダクト開発が見えていないと、 対策が間違っている可能性がある…… アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
57. 57 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。 アウトカム
58. 58 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。 アウトカム これらを計測するためには 事業組織を構造的に 捉える必要がある
59. SODA構想 Software Outcome Delivery Architecture 59
60. Software Outcome Delivery Architecture(SODA): BizReach ver.
61. Software Outcome Delivery Architecture(SODA): BizReach ver.
62. 62 SODA Project のデータソース
63. データソリューショングループ(DSG) リクルーティングプロダクト本部 SODA Project のデータソース BigQuery （データーポータル） HRMOSプロダクト本部 BigQuery ETL ダッシュボード
64. 64 指標構造｜プロダクト下 - ３つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度 営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス （FourKeysなど） オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC （行動特性） 工数 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 等級 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、３つの指標群（営業、マーケティング、 プロダクト開発）により可視化できると考えています。
65. 65 ((SODA))Evidence Viewer デモ リーチ
66. 計測の重要性：Opinion vs Fact（意見か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意見） 設計 デプロイ 仮説を実装 する 仮説を 動かす 結果を 検証する 仮説 対策の仮説 を立てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」の図を変更 仮説を立てるには、 計測データを検証す る必要がある。
67. 計測の重要性：Opinion vs Fact（意見か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意見） 設計 デプロイ 仮説を実装する （改善活動） 仮説を動かす （改善活動） 結果を 検証する 仮説 改善アプローチ の仮説を立てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉羽龍太郎さん「カイゼンの基本」の図を変更 SODAの計測結果を 元にプロセス改善サ イクルが回りはじめ る SODA
68. 68 具体的な改善方法は……DevOpsDays Tokyo 2024でお話します！
69. 69 本日の構成 前編：指標構造の全体感 • 高橋 裕之（ビズリーチ） • テストだけで品質は上がらない?!： fake self-organization（エセ自己 組織化）とは • 「アウトプット」より「アウトカ ム」：指標構造で捉える事業状況 • Software Outcome Delivery Architecture：SODA構想 後編：品質管理のための指標構造 • 荻野 恒太郎（カカクコム） • 食べログの品質管理のための指標 構造 ~昔ながらの品質管理とアジャイル 開発の開発生産性の融合~