$30 off During Our Annual Pro Sale. View Details »

マトリクス型組織の導入後の変化を定量的に捉える

ハゲワシ
September 29, 2022

 マトリクス型組織の導入後の変化を定量的に捉える

2021/9/29開催の「緊急Ques」での発表スライドとなります。

イベントURL
https://ques.connpass.com/event/258439/

ハゲワシ

September 29, 2022
Tweet

More Decks by ハゲワシ

Other Decks in Technology

Transcript

  1. © Kakaku.com Inc. All Rights Reserved. 1 マトリクス型組織の導⼊後の変化を 定量的に捉える 株式会社カカクコム

    ⾷べログシステム本部 ウェブ開発部 プロダクトチーム マネージャー 関⼾ 康介 株式会社カカクコム ⾷べログシステム本部 技術部 Developer Productivityチーム hagevvashi 2022年09⽉29⽇(⽊)
  2. © Kakaku.com Inc. All Rights Reserved. 2 ⾃⼰紹介 関⼾ 康介(せきど

    こうすけ) 株式会社カカクコム ⾷べログシステム本部 ウェブ開発部 プロダクトチーム マネージャー ユーザー向け⾷べログメディア領域の開発担当 エンジニアが企画やデザイナーなど他職種と関わっていく中で、 多様な価値観に触れて個⼈として成⻑したり、 常に変化していくチームづくりをしています。
  3. © Kakaku.com Inc. All Rights Reserved. 3 発表背景 今回ご紹介したいのは、 ⾷べログの開発プロセスの品質を定量的に分析した話

    になります その分析した結果を事業の成果につなげるためにも、 QAエンジニアだけではなく、 開発エンジニアも⼀緒に取り組みました
  4. © Kakaku.com Inc. All Rights Reserved. 4 QA観点での本発表の位置づけ プロセス 品質

    内部 品質 外部 品質 利⽤時 品質 詳しくは下記を参照 https://www.juse.or.jp/sqip/squbok/file/squbok_rev2016_1.pdf プロセス品質:各開発⼯程のプロセス実⾏状況の品質 内部品質:開発中の仕様書などの中間成果物の品質 外部品質:ソフトウェア実⾏時の振る舞いの品質 利⽤時品質:顧客がソフトウェアを利⽤するときの品質 品質モデル JISX0129-1 影響 影響 影響 依存 依存 依存
  5. © Kakaku.com Inc. All Rights Reserved. 5 発表背景 開発プロセスの品質を定量的に分析するにあたって、 QAエンジニアと開発エンジニアで

    分析のWhy,What,Howについて考えました
  6. © Kakaku.com Inc. All Rights Reserved. 6 本⽇の発表内容 Why:開発プロセスを改善して事業の成果につなげること What:今までの開発プロセス改善の取り組みとその成果

    →開発エンジニアより具体的な事例として、マトリクス型組織 導⼊後の開発プロセス改善の取り組みについてご紹介します How:開発プロセスの具体的な形である開発チケットや プルリクエストのデータを集計して傾向を捉える →QAエンジニアより傾向を捉えるために⽤いた指標と分析結 果をご紹介します
  7. © Kakaku.com Inc. All Rights Reserved. 7 本⽇の主題 マトリクス型組織を導⼊して、 開発プロセス改善に取り組んできたが、

    改善による変化を定量的に捉えられるか?
  8. © Kakaku.com Inc. All Rights Reserved. 8 マトリクス型組織の導⼊と 開発プロセス改善の取り組み

  9. © Kakaku.com Inc. All Rights Reserved. 9 マトリクス型組織導⼊の背景 組織のサイロ化による部⾨間のコミュニケーションコストの増⼤ 詳しくは下記を参照

    https://qiita.com/tkyowa/items/c0eab592d5bc356eefd6 →「社内受託」のような状態を解消したい
  10. © Kakaku.com Inc. All Rights Reserved. 10 ⾷べログにおけるマトリクス型組織 職能横断で構成される複数のクロスファンクショナルチームが それぞれミッションとKPIを持ち、ミッション達成(=事業の成果につなげる)

    に向けた開発のライフサイクル全体に責任を持つ 詳しくは下記を参照 https://qiita.com/tkyowa/items/c0eab592d5bc356eefd6
  11. © Kakaku.com Inc. All Rights Reserved. 11 依頼型の案件開発から職種⼀体型へ 導⼊前 導⼊後

    案件開発 の依頼 企画 エンジニア デザイナー 企画 エンジニア デザイナー 案件アイデア出し・要件定義・案件進⾏ ・リリース確認・クローズ
  12. © Kakaku.com Inc. All Rights Reserved. 12 開発プロセス改善の取り組み 組織の形だけを変えても変化の実感は得られない 事業の成果につなげることを⽬指して、

    開発プロセス改善に取り組んでいく
  13. © Kakaku.com Inc. All Rights Reserved. 13 開発プロセス改善で⽬指したこと 変化を⽬指す 取り組みの継続

    リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す
  14. © Kakaku.com Inc. All Rights Reserved. 14 開発プロセス改善で⽬指したこと 変化を⽬指す 取り組みの継続

    リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す
  15. © Kakaku.com Inc. All Rights Reserved. 15 リリース数を増やす 2020年10⽉ マトリクス型組織の導⼊

    2021年10⽉ リリース数をチーム⽬標に設定 効率的に成果を上げる⽅法を模索 綿密な計画にもとづく機能改修から ⼩さく⾼速にPDCAを回す 開発プロセスへ 各職種が⼀体となって 開発プロセスを⾒直す⽂化 リリース数の増加 につながりはじめた
  16. © Kakaku.com Inc. All Rights Reserved. 16 リリース数を増やす上での課題 機能改修のコンフリクト →リリース数を増やす上でのボトルネックとなる

  17. © Kakaku.com Inc. All Rights Reserved. 17 機能改修のコンフリクトを防ぐ SEO チーム

    アプリUI/UX チーム 機能軸 レストラン チーム レストラン 検索機能 チーム:機能 1:1 ユーザー 通知機能 ユーザー チーム プレミアム会員 チーム ミッション軸 チーム:機能 N:N レストラン 検索機能 ユーザー 通知機能 機能改修は チームで完結 できる 各チームで様々な機 能を改修するため、 コンフリクトが 発⽣しやすい 機能軸で主管チームを整理し、主管チームへのレビューを運⽤することで、 リリース数を増やすことを可能にする
  18. © Kakaku.com Inc. All Rights Reserved. 18 開発プロセス改善で⽬指したこと 変化を⽬指す 取り組みの継続

    リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す
  19. © Kakaku.com Inc. All Rights Reserved. 19 リリース数を増やす 2020年10⽉ マトリクス型組織の導⼊

    2021年10⽉ リリース数をチーム⽬標に設定 効率的に成果を上げる⽅法を模索 綿密な計画にもとづく機能改修から ⼩さく⾼速にPDCAを回す 開発プロセスへ 各職種が⼀体となって 開発プロセスを⾒直す⽂化 リリース数の増加 につながりはじめた
  20. © Kakaku.com Inc. All Rights Reserved. 20 ⼩さく⾼速にPDCAを回す ⼤きな機能改修よりも ⼩さなユーザー体験の改善

    を繰り返す コスパよく効果を出していくために、 リリースサイズを⼩さくする ABテストを活⽤する 素早くフィードバックを得るために、 リリースサイズを⼩さくする
  21. © Kakaku.com Inc. All Rights Reserved. 21 開発プロセス改善で⽬指したこと 変化を⽬指す 取り組みの継続

    リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す
  22. © Kakaku.com Inc. All Rights Reserved. 22 リリース数の増加による課題 障害数増加の懸念 →リリース数が増えるに伴って障害数が増えることは避けたい

  23. © Kakaku.com Inc. All Rights Reserved. 23 障害数の増加を防ぐ マトリクス型組織で希薄になりがちな エンジニア間での共通認識の構築

    システム品質のバラつきを抑えて、 障害数の増加を防ぐ エンジニアが関わっていなかった 要件定義の早い段階での参画 ⾮機能要件上のリスクを 早期に検知して障害数の増加を防ぐ
  24. © Kakaku.com Inc. All Rights Reserved. 24 開発プロセス改善で⽬指したこと 変化を⽬指す 取り組みの継続

    リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す
  25. © Kakaku.com Inc. All Rights Reserved. 25 開発プロセス改善の取り組み 組織の形だけを変えても変化の実感は得られない 事業の成果につなげることを⽬指して、

    開発プロセス改善に取り組んでいく
  26. © Kakaku.com Inc. All Rights Reserved. 26 まとめ • リリース数の増加や効果を⾒ながらの検証、職種を

    超えた⼀体感など、マトリクス型組織の導⼊による 変化は実感できている • 事業の成果につなげるというゴールに向けては、 開発プロセスを指標で捉えることが さらなる変化の機会となることを期待している →hagevvashiさんの発表に続きます!
  27. © Kakaku.com Inc. All Rights Reserved. 27 改善による変化を定量的に捉える

  28. © Kakaku.com Inc. All Rights Reserved. 28 ⾃⼰紹介 @hagevvashi 所属

    株式会社カカクコム ⾷べログシステム本部 技術部 Developer Productivityチーム QAユニット 発表実績 「⾷べログのソフトウェアテス ト⾃動化デザインパターン」 https://speakerdeck.com/hagevvashi/software-test- automation-patterns-at-tabelog-dot-com
  29. © Kakaku.com Inc. All Rights Reserved. 29 おさらい 問い 取り組み

  30. © Kakaku.com Inc. All Rights Reserved. 30 取り組みを定量的に捉える 変化を⽬指す 取り組みの継続

    リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す PRマージ数 実装・レビュー・テストの 合計⽇数 (開発チケットより) PRリバート率 リリース数 ✖ 障害率 = 障害数 PoCとして関⼾さん所属のプロジェクトで定量的に捉える活動を開始
  31. © Kakaku.com Inc. All Rights Reserved. 31 取り組みを定量的に捉える - リリース数

    変化を⽬指す 取り組みの継続 リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す PRマージ数
  32. © Kakaku.com Inc. All Rights Reserved. 32 取り組みを定量的に捉える - リリース数

    - 結果 分析の⽬的 結果 • 改善活動により、リリース数は1.28倍に増加 • Four Key Metricsの分類ではEliteに所属 評価指標 実測値 年毎のリリース数 【計測⽅法】PRマージ数 業界標準 【Four key metrics】Deployment frequency 【基準】Elite: 245以上(※), High: 12以上 年毎のリリース数 • 改善活動によりリリース数が増えたことの確 認 件数 推測 1.28倍 ※(平⽇5⽇✖52週)➖祝⽇15⽇=245⽇
  33. © Kakaku.com Inc. All Rights Reserved. 33 取り組みを定量的に捉える - リリースサイズ

    変化を⽬指す 取り組みの継続 リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す 実装・レビュー・テストの 合計⽇数 (開発チケットより)
  34. © Kakaku.com Inc. All Rights Reserved. 34 取り組みを定量的に捉える - リリースサイズ

    - 結果 分析の⽬的 • リリースサイズが⼩さくなったことの確認 結果 評価指標 実測値 リリースサイズ 【計測⽅法】実装・レビュー・テストの合計⽇ 数(開発チケットより)の中央値 業界標準 【Four key metrics】なし 【基準】なし リリースサイズが1/2以下に縮⼩された リリースサイズ ⽇ 1/2以下
  35. © Kakaku.com Inc. All Rights Reserved. 35 取り組みを定量的に捉える - 障害率

    変化を⽬指す 取り組みの継続 リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 事業の成果 につなげることを⽬指す リリース数 ✖ 障害率 = 障害数 PRリバート率
  36. © Kakaku.com Inc. All Rights Reserved. 36 取り組みを定量的に捉える - PRリバート率

    - 結果 分析の⽬的 • 障害率を考える上での参考として、PRリバー ト率が業界標準でのEliteの中を推移している ことを確認 • PRリバート率が下がったことを確認 結果 • Eliteの中を推移している • 2022年のPRリバート率が2021年に⽐べ減少 した 評価指標 【計測⽅法】PRリバート率 業界標準 【Four key metrics】Change failure rate 【基準】Elite: 0%-15%, High: 16%-30% PRリバート率
  37. © Kakaku.com Inc. All Rights Reserved. 37 おさらい • リリース数の増加や効果を⾒ながらの検証、職種を

    超えた⼀体感など、マトリクス型組織の導⼊による 変化は実感できている • 事業の成果につなげるというゴールに向けては、 開発プロセスを指標で捉えることが さらなる変化の機会となることを期待している
  38. © Kakaku.com Inc. All Rights Reserved. 38 ここまでのまとめ 変化を⽬指す 取り組みの継続

    リリースサイズ ⼩さくする (数ヶ⽉→1週間程度) リリース数 リリースサイズを⼩さくして 増やす 障害数 1.28倍の増加 PRリバート率はEliteの中を推移 1/2以下へ短縮 → 変化の実感を定量的に⽰せた
  39. © Kakaku.com Inc. All Rights Reserved. 39 さらなる変化の機会 • リリース数の増加や効果を⾒ながらの検証、職種を

    超えた⼀体感など、マトリクス型組織の導⼊による 変化は実感できている • 事業の成果につなげるというゴールに向けては、 開発プロセスを指標で捉えることが さらなる変化の機会となることを期待している
  40. © Kakaku.com Inc. All Rights Reserved. 40 さらなる変化の機会 - 結果

    実測値 テストからリリースまでのリードタイム 【計測⽅法】テスト・デプロイ待ち・デプロイ 中の合計⽇数(開発チケットより)の中央値 業界標準 【Four key metrics】Lead time for changes 【基準】Elite: 1時間以内, High: 1⽇~1週間 分析の⽬的 • 今までに挙げたもの以外にも指標を探索 し、開発プロセスにおける改善の可能性 を探す 評価指標 結果 • Highの中を推移 • Eliteへの改善の可能性あり テストからリリースまでのリードタイム ⽇
  41. © Kakaku.com Inc. All Rights Reserved. 41 さらなる変化の機会 - まとめ

    事業の成果につなげるというゴールに向けては、 開発プロセスを指標で捉えることが さらなる変化の機会となることを期待している → テストからリリースまでのリードタイムがHighから Eliteへの改善の可能性があることが分かった 絶賛テスト⾃動化取り組み中
  42. © Kakaku.com Inc. All Rights Reserved. 42 本⽇の主題 マトリクス型組織を導⼊して、 開発プロセス改善に取り組んできたが、

    改善による変化を定量的に捉えられるか?
  43. © Kakaku.com Inc. All Rights Reserved. 43 全体を通した学び 開発プロセス改善による変化を定量的に捉える試みを 実現することができた

    その過程で下記の学びを得ることができた • データ分析上の学び • 試みの実現を推進する上での学び
  44. © Kakaku.com Inc. All Rights Reserved. 44 データ分析上の学び - 初めてのデータ分析への挑戦

    ヒストグラム(テストからリリースまでのリードタイム) 外れ値 ⽇ 中央値: 0.9 平均値: 5.8 ←外れ値に引っ張られている 学び 初⼼者は安易に平均値を使いが ちだが、 QC7つ道具等を使い適切な統計 量を選ぶことが⼤切 分かったこと 平均よりも中央値の⽅が外れ値 に対して頑健である 困ったこと 平均値を使うと外れ値がノイズ となってしまう 件 数
  45. © Kakaku.com Inc. All Rights Reserved. 45 試みの実現を推進する上での学び 開発プロセス 改善

    開発エンジニア QAエンジニア データ 分析 開発エンジニア & QAエンジニア 開発チケット、PRデータ 組織のサイロ化は 案件開発に限った話ではない... チームを超えた共有 事業の成果につなげる 開発チケット、PRデータ 実現に向けた第⼀歩 実現のイメージが持ちづらい... 開発プロセス 改善 データ 分析 チーム間 定例での 情報交換 事業の成果につなげる
  46. © Kakaku.com Inc. All Rights Reserved. 46 まとめ ・マトリクス型組織の導⼊後、 リリース数、リリースサイズ、障害数についての

    開発プロセス改善の取り組みがあった ・改善による変化について、 時系列や業界標準という観点でデータを参照し、 定量的に捉らえることができた ・開発プロセス改善による変化を定量的に捉える試みでは、 チームを超えた共有が実現に向けた第⼀歩となった