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

© Kakaku.com Inc. All Rights Reserved. 1
マトリクス型組織の導⼊後の変化を
定量的に捉える
株式会社カカクコム⾷べログシステム本部
ウェブ開発部プロダクトチームマネージャー
関⼾康介
技術部 Developer Productivityチーム
hagevvashi
2022年09⽉29⽇（⽊）

View Slide

⾃⼰紹介
関⼾康介（せきどこうすけ）
ウェブ開発部プロダクトチームマネージャー
ユーザー向け⾷べログメディア領域の開発担当
エンジニアが企画やデザイナーなど他職種と関わっていく中で、
多様な価値観に触れて個⼈として成⻑したり、
常に変化していくチームづくりをしています。

View Slide

発表背景
今回ご紹介したいのは、
⾷べログの開発プロセスの品質を定量的に分析した話
になります
その分析した結果を事業の成果につなげるためにも、
QAエンジニアだけではなく、
開発エンジニアも⼀緒に取り組みました

View Slide

QA観点での本発表の位置づけ
プロセス
品質
内部
品質
外部
品質
利⽤時
品質
詳しくは下記を参照
https://www.juse.or.jp/sqip/squbok/file/squbok_rev2016_1.pdf
プロセス品質：各開発⼯程のプロセス実⾏状況の品質
内部品質：開発中の仕様書などの中間成果物の品質
外部品質：ソフトウェア実⾏時の振る舞いの品質
利⽤時品質：顧客がソフトウェアを利⽤するときの品質
品質モデル JISX0129-1
影響影響影響
依存依存依存

View Slide

発表背景
開発プロセスの品質を定量的に分析するにあたって、
QAエンジニアと開発エンジニアで
分析のWhy,What,Howについて考えました

View Slide

本⽇の発表内容
Why：開発プロセスを改善して事業の成果につなげること
What：今までの開発プロセス改善の取り組みとその成果
→開発エンジニアより具体的な事例として、マトリクス型組織
導⼊後の開発プロセス改善の取り組みについてご紹介します
How：開発プロセスの具体的な形である開発チケットや
プルリクエストのデータを集計して傾向を捉える
→QAエンジニアより傾向を捉えるために⽤いた指標と分析結
果をご紹介します

View Slide

本⽇の主題
マトリクス型組織を導⼊して、
開発プロセス改善に取り組んできたが、
改善による変化を定量的に捉えられるか？

View Slide

マトリクス型組織の導⼊と
開発プロセス改善の取り組み

View Slide

マトリクス型組織導⼊の背景
組織のサイロ化による部⾨間のコミュニケーションコストの増⼤
https://qiita.com/tkyowa/items/c0eab592d5bc356eefd6
→「社内受託」のような状態を解消したい

View Slide

⾷べログにおけるマトリクス型組織
職能横断で構成される複数のクロスファンクショナルチームが
それぞれミッションとKPIを持ち、ミッション達成（＝事業の成果につなげる）
に向けた開発のライフサイクル全体に責任を持つ
https://qiita.com/tkyowa/items/c0eab592d5bc356eefd6

View Slide

依頼型の案件開発から職種⼀体型へ
導⼊前導⼊後
案件開発
の依頼
企画
エンジニア
デザイナー
企画エンジニアデザイナー
案件アイデア出し・要件定義・案件進⾏
・リリース確認・クローズ

View Slide

組織の形だけを変えても変化の実感は得られない
事業の成果につなげることを⽬指して、
開発プロセス改善に取り組んでいく

View Slide

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

View Slide

⼩さくする
リリース数
増やす
障害数
事業の成果

View Slide

リリース数を増やす
2020年10⽉
マトリクス型組織の導⼊
2021年10⽉
リリース数をチーム⽬標に設定
効率的に成果を上げる⽅法を模索
綿密な計画にもとづく機能改修から
⼩さく⾼速にPDCAを回す
開発プロセスへ
各職種が⼀体となって
開発プロセスを⾒直す⽂化
リリース数の増加
につながりはじめた

View Slide

リリース数を増やす上での課題
機能改修のコンフリクト
→リリース数を増やす上でのボトルネックとなる

View Slide

© Kakaku.com Inc. All Rights Reserved.
17
機能改修のコンフリクトを防ぐ
SEO
チーム
アプリUI/UX
チーム
機能軸
レストラン
チーム
レストラン
検索機能
チーム：機能
1：1
ユーザー
通知機能
ユーザー
チームプレミアム会員
チーム
ミッション軸
チーム：機能
N：N
レストラン
検索機能
ユーザー
通知機能
機能改修は
チームで完結
できる
各チームで様々な機
能を改修するため、
コンフリクトが
発⽣しやすい
機能軸で主管チームを整理し、主管チームへのレビューを運⽤することで、
リリース数を増やすことを可能にする

View Slide

⼩さくする
リリース数
増やす
障害数
事業の成果

View Slide

リリース数を増やす
2020年10⽉
マトリクス型組織の導⼊
2021年10⽉
リリース数をチーム⽬標に設定
効率的に成果を上げる⽅法を模索
綿密な計画にもとづく機能改修から
開発プロセスへ
各職種が⼀体となって
開発プロセスを⾒直す⽂化
リリース数の増加
につながりはじめた

View Slide

⼤きな機能改修よりも
⼩さなユーザー体験の改善
を繰り返す
コスパよく効果を出していくために、
リリースサイズを⼩さくする
ABテストを活⽤する
素早くフィードバックを得るために、
リリースサイズを⼩さくする

View Slide

⼩さくする
リリース数
増やす
障害数
事業の成果

View Slide

リリース数の増加による課題
障害数増加の懸念
→リリース数が増えるに伴って障害数が増えることは避けたい

View Slide

障害数の増加を防ぐ
マトリクス型組織で希薄になりがちな
エンジニア間での共通認識の構築
システム品質のバラつきを抑えて、
障害数の増加を防ぐ
エンジニアが関わっていなかった
要件定義の早い段階での参画
⾮機能要件上のリスクを
早期に検知して障害数の増加を防ぐ

View Slide

⼩さくする
リリース数
増やす
障害数
事業の成果

View Slide

組織の形だけを変えても変化の実感は得られない
事業の成果につなげることを⽬指して、
開発プロセス改善に取り組んでいく

View Slide

まとめ
• リリース数の増加や効果を⾒ながらの検証、職種を
超えた⼀体感など、マトリクス型組織の導⼊による
変化は実感できている
• 事業の成果につなげるというゴールに向けては、
開発プロセスを指標で捉えることが
さらなる変化の機会となることを期待している
→hagevvashiさんの発表に続きます！

View Slide

改善による変化を定量的に捉える

View Slide

⾃⼰紹介
@hagevvashi 所属
株式会社カカクコム
⾷べログシステム本部技術部
Developer Productivityチーム
QAユニット
発表実績
「⾷べログのソフトウェアテス
ト⾃動化デザインパターン」
https://speakerdeck.com/hagevvashi/software-test-
automation-patterns-at-tabelog-dot-com

View Slide

おさらい
問い取り組み

View Slide

取り組みを定量的に捉える
⼩さくする
リリース数
増やす
障害数
事業の成果
PRマージ数
実装・レビュー・テストの
合計⽇数
(開発チケットより)
PRリバート率
リリース数 ✖ 障害率 = 障害数
PoCとして関⼾さん所属のプロジェクトで定量的に捉える活動を開始

View Slide

取り組みを定量的に捉える - リリース数
⼩さくする
リリース数
増やす
障害数
事業の成果
PRマージ数

View Slide

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

View Slide

取り組みを定量的に捉える - リリースサイズ
⼩さくする
リリース数
増やす
障害数
事業の成果
実装・レビュー・テストの
合計⽇数
(開発チケットより)

View Slide

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

View Slide

取り組みを定量的に捉える - 障害率
⼩さくする
リリース数
増やす
障害数
事業の成果
リリース数 ✖ 障害率 = 障害数
PRリバート率

View Slide

取り組みを定量的に捉える - PRリバート率 - 結果
分析の⽬的
• 障害率を考える上での参考として、PRリバー
ト率が業界標準でのEliteの中を推移している
ことを確認
• PRリバート率が下がったことを確認
結果
• Eliteの中を推移している
• 2022年のPRリバート率が2021年に⽐べ減少
した
評価指標
【計測⽅法】PRリバート率
業界標準
【Four key metrics】Change failure rate
【基準】Elite: 0%-15%, High: 16%-30%
PRリバート率

View Slide

おさらい

View Slide

ここまでのまとめ
⼩さくする
リリース数
増やす
障害数
1.28倍の増加 PRリバート率はEliteの中を推移
1/2以下へ短縮
→ 変化の実感を定量的に⽰せた

View Slide

さらなる変化の機会

View Slide

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

View Slide

さらなる変化の機会 - まとめ
事業の成果につなげるというゴールに向けては、
→ テストからリリースまでのリードタイムがHighから
Eliteへの改善の可能性があることが分かった
絶賛テスト⾃動化取り組み中

View Slide

本⽇の主題
マトリクス型組織を導⼊して、
開発プロセス改善に取り組んできたが、
改善による変化を定量的に捉えられるか？

View Slide

全体を通した学び
開発プロセス改善による変化を定量的に捉える試みを
実現することができた
その過程で下記の学びを得ることができた
• データ分析上の学び
• 試みの実現を推進する上での学び

View Slide

データ分析上の学び - 初めてのデータ分析への挑戦
ヒストグラム(テストからリリースまでのリードタイム)
外れ値
⽇
中央値: 0.9
平均値: 5.8
←外れ値に引っ張られている
学び
初⼼者は安易に平均値を使いが
ちだが、
QC7つ道具等を使い適切な統計
量を選ぶことが⼤切
分かったこと
平均よりも中央値の⽅が外れ値
に対して頑健である
困ったこと
平均値を使うと外れ値がノイズ
となってしまう
件
数

View Slide

試みの実現を推進する上での学び
開発プロセス
改善
開発エンジニア QAエンジニア
データ
分析
開発エンジニア & QAエンジニア
開発チケット、PRデータ
組織のサイロ化は
案件開発に限った話ではない...
チームを超えた共有
事業の成果につなげる
開発チケット、PRデータ
実現に向けた第⼀歩
実現のイメージが持ちづらい...
開発プロセス
改善
データ
分析
チーム間
定例での
情報交換
事業の成果につなげる

View Slide

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

View Slide

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

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

ハゲワシ

More Decks by ハゲワシ

Other Decks in Technology

Featured

Transcript