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

テストだけで品質は上がらない?! エセ⾃⼰組織化した品質組織からの脱却ソフトウェアテストシンポジウム 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 <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 本来の「⾃⼰組織化(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 プロダクト開発チーム

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

QA QA Dev Dev Dev Dev 仕様化プロセス設計プロセステストプロセス開発組織？品質組織？

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

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

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

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

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

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

QA QA Dev Dev Dev Dev プロダクト開発チーム品質スピード

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

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

QA QA Dev Dev Dev Dev 開発組織？品質組織？品質スピード ඼࣭ 2 ͱεϐʔυ % ͸ τϨʔυΦϑʁ テスト⼯数が少ないので修正をやめてください！最近バグが多いので信⽤なりません！テストケースを倍にします！開発がリリース回数増やすから障害増えたじゃないか！品質を守るために開発と仲良くするな！テストしすぎ！ 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 ͱεϐʔυ プロダクト開発指標アウトカムアウトカム指標は、３つの指標群（営業、マーケティング、プロダクト開発）により可視化できると考えています。

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

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

։ൃνʔϜ パフォーマンス顧客満足度営業指標マーケティング指標市場占有率売上利益契約企業/HH数登録ユーザー数 UHS 求人数内定率入社人数レジュメ数応募数内定承諾率障害数障害レベル %03"ϝτϦΫε ʢFourKeysͳͲʣ オンプロダクト指標スコープ 4 時間 % 予算 $ デリバリーの変更率進捗率スコープの達成率マイルストーン達成率人件費固定費開発ツール費 e-NPS パルスサーベイ DiSC （行動特性）勤怠勤務年数 ϓϩμΫτ૊৫ͷコンディション開発チーム組成年齢性別職位 ΤϯδχΞݸਓέΠύϏϦςΟ ίϛοτ਺ ฏۉίϛοταΠζ 13࡞੒਺ɾϚʔδ ਺ ίʔυߦ਺ ฏۉ13Ϋϩʔζ࣌ ؒ *TTVFUJDLFUΫϩʔ ζ਺ ඼࣭ 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.

62 SODA Project のデータソース

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

։ൃνʔϜ パフォーマンス顧客満足度営業指標マーケティング指標市場占有率 ച্ 利益契約企業/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構想後編：品質管理のための指標構造 • 荻野恒太郎（カカクコム） • ⾷べログの品質管理のための指標構造 ~昔ながらの品質管理とアジャイル開発の開発⽣産性の融合~

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

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

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript