テストだけで品質は上がらない?! エセ⾃⼰組織化した品質組織からの脱却 ソフトウェアテストシンポジウム 2024 東京 JaSST'24 Tokyo: Day2, 2024/3/15 Visionalグループ 株式会社ビズリーチ リクルーティングプロダクト本部 PMO室 SODA推進グループ / ⽇科技連 SQiP アジャイルSQC研究部会 ⾼橋裕之

2 アジャイルSQC研究部会とは l設⽴主旨 アジャイル開発においてもFour Keysなどの定量化が適⽤されてきており、その 範囲はどんどん広がっていくと考えられます。しかし我が国ではまだあまり事例 が共有されておらず、どのような定量化がどのような状況に適しているのか、ど のような分析技法があるのか、などの議論はほとんど⾏われていません。そこで アジャイルSQC研究会では、企業や組織の枠組みを超えてアジャイル開発におけ る定量化および分析の議論や研究を⾏い、その成果を産学に還元することで貢献 して参ります。 l運営委員（敬称略、五⼗⾳順） •荻野 恒太郎（カカクコム） •坂⽥ 晶紀（富⼠通） •⼭⼝ 鉄平（LayerX） https://www.juse.or.jp/sqip/agile_sqc/index.html

3 本⽇の構成 前編：指標構造の全体感 • ⾼橋 裕之（ビズリーチ） • テストだけで品質は上がらない?!： fake self-organization（エセ⾃⼰ 組織化）とは • 「アウトプット」より「アウトカ ム」：指標構造で捉える事業状況 • Software Outcome Delivery Architecture：SODA構想 後編：品質管理のための指標構造 • 荻野 恒太郎（カカクコム） • ⾷べログの品質管理のための指標 構造 ~昔ながらの品質管理とアジャイル 開発の開発⽣産性の融合~

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） 趣味 ⼭、海、⼩説、漫画、映画、ランニング 経歴

fake self-organization （エセ⾃⼰組織化） とは テストだけで品質は上がらない?! 5

6 本来の「⾃⼰組織化(self-organization)」とは？ “⼀⾒、複雑で無秩序な系において、⾃律的に形成される秩序だったパターン。いずれも外部からの意図的な制御なし に、基本的な物理法則に則って時間的・空間的秩序が形成され、また、維持される。ベナール対流、結晶成⻑、ベロ ウソフジャボチンスキー反応、⼼筋の律動、ニューラルネットワークの構築をはじめ、物理学、化学、⽣物学、情報 科学など、幅広い分野で⾒いだされ、いわゆる複雑系に現れる特徴の⼀つに挙げられる。⾃発的秩序形成。” 出典：デジタル⼤辞泉（⼩学館） “無秩序に向かう⾃然界の流れ(熱⼒学第2法則)に逆らい、系がエネルギーを取り込みながら⾃分を組織だて、秩序を⽣ むこと。結晶の⽣成や化学反応のリズムなどさまざまな場⾯でみられ、体表の模様づくりなど⽣物界でも⽬⽴つ。系 を形づくる要素同⼠の働き合いが鍵を握る。カオスなどと並んで複雑系科学の主役。ナノテクノロジーに利⽤して量 ⼦点(量⼦ドット)をつくる試みなどもある。” 出典：知恵蔵（朝⽇新聞出版）

7 本来の「⾃⼰組織化(self-organization)」とは？ Alexey Kljatov, CC BY-SA 4.0 Mikkabie, CC BY-SA 4.0 TANAKA Juuyoh (⽥中⼗洋), CC BY 2.0 雪の結晶 みそ汁の中の模様 イワシの群れの動き

8 本来の「⾃⼰組織化(self-organization)」とは？ “「⾃⼰組織化」とは「ランダムになろうとする⼒に、 秩序化しようとする⼒が打ち勝つこと」である。” （参考）都甲 潔. 林 健司. 江崎 秀. ⾃⼰組織化とは何か―⽣物の形やリズムが⽣まれる原理を探る. 講談社, 1999, 241p. ランダム 秩序 ⾮線形性 エントロピー⼤ 平衡系（静的） ⾮平衡系（動的） 雪の結晶、⽣体膜、リポソーム、 ⼈⼯味細胞膜、(将来の) 分⼦素⼦、 マイクロマシン リズム、パターン、カオス 協同現象 (相転移)

9 スクラム⽂脈における「⾃⼰組織化」 •⽐較的初期※1のスクラムガイドから「⾃⼰組織化」という⾔葉は使われてきた。 •例えば「スクラムガイド2017年10⽉版」では以下のように説明されている(⼀部)。 •しかし、最新※2の「スクラムガイド2020年11⽉版」で「⾃⼰組織化」という⾔葉 が消える。何が起きたのだろうか。 “スクラムチームは⾃⼰組織化されており、機能横断的である。⾃⼰組織化チームは、作 業を成し遂げるための最善の策を、チーム外からの指⽰ではなく、⾃分たちで選択する。 機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能⼒を持っている。” ※1 Scrumの元となった⽵内弘⾼⽒、野中郁⼆郎⽒の論⽂「The New New Product Development Game」に⾃⼰組織化は登場しており、スクラムガイド2009年5⽉版以降で使われてきた。 ※2 2024年3⽉15⽇現在 “開発チームには、以下のような特徴がある。 • ⾃⼰組織化されている。プロダクトバックログをリリース判断可能な機能のインクリ メントに変える⽅法は、誰も（スクラムマスターでさえも）教えてくれない。 • (以降、略)”

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 「エセ⾃⼰組織化」症候群 俺たち ⾃⼰組織化 してる Goals (⽬的) おーい 真の⽬的を忘れ、⾃分たちは「⾃律している」と 思い込み次々と間違った決断をしてしまう状態を 「エセ⾃⼰組織化」症候群と名付けた。 「やりたいことだけやりたがるエンジニア」 「⾃⼰組織化を盾に約束を守らないチーム」 「待てど暮らせど成果がでないチーム」 どうやら、世界中のあちこちで起きていた症状

12 Τηࣗݾ૊৫Խͨ͠඼࣭૊৫ͱ͸ʁ

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

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 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？

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

17 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 仕様化 プロセス 設計 プロセス テスト プロセス 開発組織？ 品質組織？ BUG ⾒つけた！

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

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

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

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

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

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

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

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

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

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

28 fake self-organization Dev QA QA Dev Dev QA QA QA QA Dev Dev Dev Dev 開発組織？ 品質組織？ リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる 品質 スピード

Four Keys 品質 スピード リードタイムが短くなると学 習スピードが増し、品質が向 上する 品質が向上するとリードタイ ムは短くなり、頻繁なデプロ イが容易になる 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 ඼࣭ 2 ͱεϐʔυ % ͸τϨʔυΦϑͰ͸ͳ͍

30 DORA Metrics •原書は「Accelerate: The Science Behind Devops: Building and Scaling High Performing Technology Organizations」 •2018年3⽉出版、⽇本語版は2018年11⽉に出版。 •迅速かつ⾼品質なデリバリを実施している組織とそうでない組織の違いに関する 研究結果をDORAがまとめている。 IUUQTCPPLJNQSFTTDPKQCPPLT IUUQTXXXPSFJMMZDPNMJCSBSZWJFXBDDFMFSBUF

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 DORA Metrics 変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 信頼性（可⽤性） Four Keys 27のケイパビリティ 統計的相関 （参考）Google Cloud. ” Explore DORA's research program”. Google Cloud. https://www.devops-research.com/research.html. (参照 2023-1-10)

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

指標構造で捉える事業状況 「アウトプット」より「アウトカム」 34

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 ソフトウェアエンジニアリングの歴史的「格⾔」 「計測できないものは制御できない」 “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 ソフトウェアエンジニアリングの歴史的「格⾔」 「計測できないものは制御できない」 “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 「測定できないものは制御できない｣は誤りだった？ •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 「測定できないものは制御できない｣は誤りだった？ •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 もっと重要なのは…… プロジェクトを 時間通り、予算通りに 終わらせることよりも プロダクトで 世界を変えるような、あるいは企業 やビジネスのあり⽅を変えるような ソフトウェアを作るという「変⾰」

41 もっと重要なのは…… プロジェクトを 時間通り、予算通りに 終わらせることよりも プロダクトで 世界を変えるような、あるいは企業 やビジネスのあり⽅を変えるような ソフトウェアを作るという「変⾰」 「アウトプット」より「アウトカム」

42 アウトカムとは 事業会社

43 アウトカムとは 顧客 困った 事業会社

44 アウトカムとは 顧客 困った プロダクト・サービス提供 事業会社

45 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ 事業会社

46 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ アウトカム向上 事業会社

信頼・対価(売上) 47 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ 事業会社 アウトカム向上

信頼・対価(売上) 48 アウトカムとは 顧客 プロダクト・サービス提供 良かった！ 継続 事業会社 アウトカム向上

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

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

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

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

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

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

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

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

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

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

SODA構想 Software Outcome Delivery Architecture 59

Software Outcome Delivery Architecture(SODA): BizReach ver.

Software Outcome Delivery Architecture(SODA): BizReach ver.

62 SODA Project のデータソース

σʔλιϦϡʔγϣϯάϧʔϓ %4( ϦΫϧʔςΟϯάϓϩμΫτຊ෦ SODA Project のデータソース #JH2VFSZ ʢσʔλʔϙʔλϧʣ )3.04ϓϩμΫτຊ෦ #JH2VFSZ &5- μογϡϘʔυ

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

65 ((SODA))Evidence Viewer σϞϦʔν

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

計測の重要性：Opinion vs Fact（意⾒か事実か） Problem（問題） Solution（解決策） Fact（事実） Opinion（意⾒） 設計 デプロイ 仮説を実装する （改善活動） 仮説を動かす （改善活動） 結果を 検証する 仮説 改善アプローチ の仮説を⽴てる 計測 (参考) https://slide.meguro.ryuzee.com/slides/78 吉⽻⿓太郎さん「カイゼンの基本」の図を変更 SODAの計測結果を 元にプロセス改善サ イクルが回りはじめ る SODA

68 具体的な改善⽅法は……DevOpsDays Tokyo 2024でお話します！

69 本⽇の構成 前編：指標構造の全体感 • ⾼橋 裕之（ビズリーチ） • テストだけで品質は上がらない?!： fake self-organization（エセ⾃⼰ 組織化）とは • 「アウトプット」より「アウトカ ム」：指標構造で捉える事業状況 • Software Outcome Delivery Architecture：SODA構想 後編：品質管理のための指標構造 • 荻野 恒太郎（カカクコム） • ⾷べログの品質管理のための指標 構造 ~昔ながらの品質管理とアジャイル 開発の開発⽣産性の融合~