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

高速ゴミ製造機と逆割れ窓理論 / High-speed garbage machine and...

高速ゴミ製造機と逆割れ窓理論 / High-speed garbage machine and reverse broken window theory

【AI要約】
* Four Keys はあくまで手段。数字を目的化すると“高速ゴミ製造機”化する危険がある。
* ourly 開発チームは「変更リードタイム」にフォーカスし、2年でサイクルタイム約50分の1・デプロイ頻度6倍を実現。
* 改善の過程で プロセス刷新・権限移譲・目的志向の徹底が連鎖し、他指標や組織文化まで好転。
* これを「逆割れ窓理論」と呼び、小さな成功の積み上げが全体最適を呼び込むことを示した。
* 成功の鍵は リーダーの率先垂範・目的共有・粘り強さ。この文化が定着すれば、“高速価値製造機”になれる。

Avatar for KosukeAizawa

KosukeAizawa

May 27, 2025
Tweet

More Decks by KosukeAizawa

Other Decks in Technology

Transcript

  1. 2 自己紹介 相澤 宏亮 (あいざわ こうすけ) 役割 執行役員CTO 兼 CTO(Chief

    T-Shirt Officer) 経歴 2016年:京都大学大学院理学研究科中退 2017年:株式会社PLAN-Bに新卒入社 2020年:株式会社ビットエーに転職 & ourly事業立ち上げ 2023年:ourly株式会社に転籍 2024年:執行役員CTOを拝命 (7月〜) # Ruby # PHP # Java # 新卒/中途採用 # 社内ハッカソン その他 # キングダム # ジョジョ # HUNTER×HUNTER # 刃牙 # 新規事業立ち上げ # 野球観戦 # 阪神タイガース好きと繋がりたい
  2. 3 会社概要 ourly株式会社(株式会社ビットエー100%子会社) 東京都品川区西五反田一丁目5番1号 A-PLACE五反田駅前ビル5階 2022年4月 代表取締役社長  坂本 良介 取締役COO

    髙橋 新平 取締役 吉田 雅史 取締役 橋本 和樹 執行役員CTO 相澤 宏亮 執行役員 乗松 諒 正社員15名、業務委託5名 インナーコミュニケーションプラットフォーム「ourly」の企画・開発・販売 「ourly」を用いた組織開発支援 社名 所在地 設立年月 役員構成 従業員数 事業内容
  3. 7 🗑 Four Keysと高速ゴミ製造機 🔑 • Four Keysとは、DevOps Research and

    Assessment (DORA)で定義さ れたソフトウェアデリバリーパフォーマンスを示す4つの指標 デプロイ頻度 本番リリースの頻度 変更リードタイム コード変更をコミットしてから本番にデプロイされるまでの時間 障害復旧時間(MTTR) 障害発生から復旧までの時間 変更失敗率 デプロイ後にバグやロールバックが発生する割合
  4. 8 🗑 Four Keysと高速ゴミ製造機 🔑 • 数値をハックして見かけ上の改善を行うことは十分に可能 ◦ 例1)レビューをスキップして一旦マージすることで変更リードタイムを短縮する ◦

    例2)1PRごとにデプロイを行い、デプロイ頻度を無理やり上げる • このようなハックが可能なことから、時に、Four Keysの改善だけに やっきになるチームを「高速ゴミ製造機」と揶揄する声も... ※ プロダクトマネジメントが機能していないという意味を込めてそう言っている場合もあります
  5. 11 👥 開発生産性に向き合った2年間の結果 👥 • 開発生産性の数値の変化 指標 Findy Team+導入時(2023/05) 現在(2025/04)

    PRの滞留数※ 100以上 ほぼ0 サイクルタイム 360.8h 12.8h デプロイ頻度 5回/月 33回/月 リリース頻度※ 0.7回/月 2回/月 ※ 「PRの滞留数」の定義: ※ 「リリース頻度」の定義: 特別な理由なく1週間以上放置されているPRの数 全体もしくは限定されたクライアントへのリリース回数を、 前後1ヶ月の平均値で算出
  6. 14 • 開発プロセスの変化 ◦ 1週間スプリント→2週間スプリント ◦ スプリントゴールをタスクリストからユーザーストーリーへ ◦ スプリントレビューにスクラムチーム以外のメンバー(CS)も参加 ◦

    フィーチャーフラグを導入して、小刻みにデプロイ/リリース ◦ レビュー承認フローを簡略化 ▪ CTO/テックリードのどちらかでOKとすることにした 👥 開発生産性に向き合った2年間の結果 👥
  7. 15 • 意識の変化 ◦ リソース効率よりもフロー効率重視 ▪ レビュアー: • PRが出されたらすぐにレビュー •

    コメントで温度感を提示 ▪ レビューイ: • 1PRにつき1変更意図 • レビュアーが見やすいようにセルフレビュー時に補足コメント • 事前に実装方針をすり合わせ 👥 開発生産性に向き合った2年間の結果 👥