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

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

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

Hiroyuki TAKAHASHI

March 14, 2024
Tweet

More Decks by Hiroyuki TAKAHASHI

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 開発組織? 品質組織? 品質 スピード 品質(Q)とスピード(D)は トレードオフ?
  21. 26 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 開発組織? 品質組織? 品質 スピード 品質(Q)とスピード(D)は トレードオフ? テスト工数が少ないので 修正をやめてください! 最近バグが多いので 信用なりません! テストケースを倍にします! 開発が リリース回数増やすから 障害増えたじゃないか! 品質を守るために 開発と仲良くするな! テストしすぎ! QAがボトルネックになって リリースが遅れた! 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した! 「役割分担」バイアス unconscious bias
  22. 27 fake self-organization Dev QA QA Dev Dev QA QA

    QA QA Dev Dev Dev Dev 開発組織? 品質組織? 品質 スピード 品質(Q)とスピード(D)は トレードオフ? テスト工数が少ないので 修正をやめてください! 最近バグが多いので 信用なりません! テストケースを倍にします! 開発が リリース回数増やすから 障害増えたじゃないか! 品質を守るために 開発と仲良くするな! テストしすぎ! QAがボトルネックになって リリースが遅れた! 仕様書書く時間ないから コード読んで必要な部分だけ テストしてほしい QAで検出できなかったから バグが市場に流出した!
  23. 28 fake self-organization Dev QA QA Dev Dev QA QA

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

    変更リードタイム デプロイ頻度 デプロイ失敗からの 回復時間 変更失敗率 品質(Q)とスピード(D)はトレードオフではない
  25. 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/
  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 アウトカムとは 事業会社 顧客 プロダクト・サービス提供 良かった! 継続 品質(Q)とス ピード(D)

    開発 進捗 障害 開発 チーム パフ ォーマ ンス 顧客 満足度 営業 指標 マー ケティ ング指 標 市場 占有率 売上 利益 契約 企業/HH数 登録 ユーザ ー数 UHS 求人 数 内定 率 入社 人数 レジ ュメ数 応募 数 内定 承諾率 障害 数 障害 レベル DORAメト リクス (FourKeysなど ) オン プロダ クト指 標 スコ ープ(S) 時間(D) 予算(C) デリ バリー の変更 率 進捗 率 スコ ープの 達成率 マイ ルスト ーン達 成率 人件 費 固定 費 開発 ツール 費 e-NPS パル スサー ベイ DiSC ( 行動 特 性) 勤怠 勤務 年数 プロ ダクト 組織のコン ディシ ョン 開発 チーム 組成 年齢 性別 職位 エン ジニア 個人ケ イパビ リティ コミ ット数 平均 コミッ トサイ ズ PR作成 数・マ ージ数 コー ド行数 平均PRクロ ーズ時 間 Is sue tic ket クロ ーズ 数 品質(Q)とス ピード プロ ダクト 開発指 標 アウトカム向上 事業状況を可視化することで、 アウトカムに影響を及ぼす指標が見えてくる
  35. 50 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  36. 51 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  37. 52 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  38. 53 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 ブラックボックスになりがち アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  39. 54 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  40. 55 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  41. 56 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 プロダクト開発が見えていないと、 対策が間違っている可能性がある…… アウトカム アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。
  42. 57 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。 アウトカム
  43. 58 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 勤怠 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 職位 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム指標は、3つの指標群(営業、マーケティング、 プロダクト開発)により可視化できると考えています。 アウトカム これらを計測するためには 事業組織を構造的に 捉える必要がある
  44. 64 指標構造|プロダクト下 - 3つの指標領域 品質(Q)とスピード(D) 開発進捗 障害 開発チーム パフォーマンス 顧客満足度

    営業指標 マーケティング指標 市場占有率 売上 利益 契約企業/HH数 登録ユーザー数 UHS 求人数 内定率 入社人数 レジュメ数 応募数 内定承諾率 障害数 障害レベル DORAメトリクス (FourKeysなど) オンプロダクト指標 スコープ(S) 時間(D) 予算(C) デリバリーの変更率 進捗率 スコープの達成率 マイルストーン達成率 人件費 固定費 開発ツール費 e-NPS パルスサーベイ DiSC (行動特性) 工数 勤務年数 プロダクト組織のコンディション 開発チーム組成 年齢 性別 等級 エンジニア個人ケイパビリティ コミット数 平均コミットサイズ PR作成数・マージ数 コード行数 平均PRクローズ時間 Issue ticket クローズ 数 品質(Q)とスピード プロダクト開発指標 アウトカム アウトカム指標は、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構想 後編:品質管理のための指標構造 • 荻野 恒太郎(カカクコム) • 食べログの品質管理のための指標 構造 ~昔ながらの品質管理とアジャイル 開発の開発生産性の融合~