Slide 1

Slide 1 text

1 高速ゴミ製造機と逆割れ窓理論 CTO・VPoE 話さナイト✨ Vol.3 ourly株式会社 相澤 宏亮 (@tigers_loveng)

Slide 2

Slide 2 text

2 自己紹介 相澤 宏亮 (あいざわ こうすけ) 役割 執行役員CTO 兼 CTO(Chief T-Shirt Officer) 経歴 2016年:京都大学大学院理学研究科中退 2017年:株式会社PLAN-Bに新卒入社 2020年:株式会社ビットエーに転職 & ourly事業立ち上げ 2023年:ourly株式会社に転籍 2024年:執行役員CTOを拝命 (7月〜) # Ruby # PHP # Java # 新卒/中途採用 # 社内ハッカソン その他 # キングダム # ジョジョ # HUNTER×HUNTER # 刃牙 # 新規事業立ち上げ # 野球観戦 # 阪神タイガース好きと繋がりたい

Slide 3

Slide 3 text

3 会社概要 ourly株式会社(株式会社ビットエー100%子会社) 東京都品川区西五反田一丁目5番1号 A-PLACE五反田駅前ビル5階 2022年4月 代表取締役社長  坂本 良介 取締役COO 髙橋 新平 取締役 吉田 雅史 取締役 橋本 和樹 執行役員CTO 相澤 宏亮 執行役員 乗松 諒 正社員15名、業務委託5名 インナーコミュニケーションプラットフォーム「ourly」の企画・開発・販売 「ourly」を用いた組織開発支援 社名 所在地 設立年月 役員構成 従業員数 事業内容

Slide 4

Slide 4 text

4 ・設立4年目、HR領域のBtoB SaaS ・組織文化を変えることで、組織 /経営課題を解決 ・プロダクト × コンサルティングの両輪で支援

Slide 5

Slide 5 text

5 今日お話しすること ● 🗑 Four Keysと高速ゴミ製造機 🔑 ● 👥 開発生産性に向き合った2年間の結果 👥 ● 🏚 逆割れ窓理論 🏠

Slide 6

Slide 6 text

6 🗑 Four Keysと高速ゴミ製造機 🔑

Slide 7

Slide 7 text

7 🗑 Four Keysと高速ゴミ製造機 🔑 ● Four Keysとは、DevOps Research and Assessment (DORA)で定義さ れたソフトウェアデリバリーパフォーマンスを示す4つの指標 デプロイ頻度 本番リリースの頻度 変更リードタイム コード変更をコミットしてから本番にデプロイされるまでの時間 障害復旧時間(MTTR) 障害発生から復旧までの時間 変更失敗率 デプロイ後にバグやロールバックが発生する割合

Slide 8

Slide 8 text

8 🗑 Four Keysと高速ゴミ製造機 🔑 ● 数値をハックして見かけ上の改善を行うことは十分に可能 ○ 例1)レビューをスキップして一旦マージすることで変更リードタイムを短縮する ○ 例2)1PRごとにデプロイを行い、デプロイ頻度を無理やり上げる ● このようなハックが可能なことから、時に、Four Keysの改善だけに やっきになるチームを「高速ゴミ製造機」と揶揄する声も... ※ プロダクトマネジメントが機能していないという意味を込めてそう言っている場合もあります

Slide 9

Slide 9 text

9 🗑 Four Keysと高速ゴミ製造機 🔑 ● 2023年5月にFindy Team+の導入を決めてからちょうど2年間、Four Keys(正確には変更リードタイムのみ)に向き合い続けてきた組織の 現在地と僕の気付きを共有します

Slide 10

Slide 10 text

10 👥 開発生産性に向き合った2年間の結果 👥

Slide 11

Slide 11 text

11 👥 開発生産性に向き合った2年間の結果 👥 ● 開発生産性の数値の変化 指標 Findy Team+導入時(2023/05) 現在(2025/04) PRの滞留数※ 100以上 ほぼ0 サイクルタイム 360.8h 12.8h デプロイ頻度 5回/月 33回/月 リリース頻度※ 0.7回/月 2回/月 ※ 「PRの滞留数」の定義: ※ 「リリース頻度」の定義: 特別な理由なく1週間以上放置されているPRの数 全体もしくは限定されたクライアントへのリリース回数を、 前後1ヶ月の平均値で算出

Slide 12

Slide 12 text

12 👥 開発生産性に向き合った2年間の結果 👥 ● 開発生産性の数値の変化 D-Plus Tokyo #4 ~しくじり事例から学ぶ!開発生産性の取り組みLT会~ の発表資料より抜粋 変更をcommitしてからmergeされるまでに15日かかる計算

Slide 13

Slide 13 text

13 👥 開発生産性に向き合った2年間の結果 👥 ● 開発生産性の数値の変化 サイクルタイム 約50分の1 デプロイ頻度 約6倍

Slide 14

Slide 14 text

14 ● 開発プロセスの変化 ○ 1週間スプリント→2週間スプリント ○ スプリントゴールをタスクリストからユーザーストーリーへ ○ スプリントレビューにスクラムチーム以外のメンバー(CS)も参加 ○ フィーチャーフラグを導入して、小刻みにデプロイ/リリース ○ レビュー承認フローを簡略化 ■ CTO/テックリードのどちらかでOKとすることにした 👥 開発生産性に向き合った2年間の結果 👥

Slide 15

Slide 15 text

15 ● 意識の変化 ○ リソース効率よりもフロー効率重視 ■ レビュアー: ● PRが出されたらすぐにレビュー ● コメントで温度感を提示 ■ レビューイ: ● 1PRにつき1変更意図 ● レビュアーが見やすいようにセルフレビュー時に補足コメント ● 事前に実装方針をすり合わせ 👥 開発生産性に向き合った2年間の結果 👥

Slide 16

Slide 16 text

16 ● 意識の変化 ○ マネジメント層からメンバー層への権限移譲 ■ マネジメント層の意思決定を透明化 ■ 施策の再現性をあげて、属人性を下げた 👥 開発生産性に向き合った2年間の結果 👥

Slide 17

Slide 17 text

17 🏚 逆割れ窓理論 🏠

Slide 18

Slide 18 text

● なぜこのような変化が起きたのか ○ 最初は変更リードタイムだけに向き合っていた ○ 結果指標である数値は気にせず、プロセスに向き合うことを口酸っぱく 言い続けた ■ 元々チームメンバーは目的志向が強いメンバーが集まっていた ○ 原因の深掘りを行い、対策を立てるシステム思考で向き合っているうち に本質的な課題に近づいていった 18 🏚 逆割れ窓理論 🏠

Slide 19

Slide 19 text

● 例1) ○ レビューに時間かかってるのはPRが大きすぎるから ○ PRを小さくするにはもっとタスクを細かく分解しないといけない ○ タスクを細かく分解するには設計力をあげないといけない ○ 設計力を上げるにはチーム全体のスキルアップしないといけない ■ → じゃあチーム全体のスキル平準化にも取り組もう! 19 🏚 逆割れ窓理論 🏠

Slide 20

Slide 20 text

● 例2) ○ レビューに時間かかってるのは、レビューを後回しにしてPRを出すこと を優先しているから ○ レビューを優先したいけど、レビュー優先するとタスクが終わらない ○ そもそもスプリントゴールの設定がタスクリストになっているのが良く ない ■ → じゃあスプリントゴールはユーザーストーリーを設定しよう 20 🏚 逆割れ窓理論 🏠

Slide 21

Slide 21 text

● 割れ窓理論とは、1つの窓ガラスが割れたまま放置されると他の窓もどんど ん割られてしまい、建物全街、ひいては街全体が荒れてしまうという環境犯 罪学の理論 ● 今回起きたのはその逆で、1つの指標(窓ガラス)を改善することで、他の指 標にもどんどん改善の目が向き、最終的に全体的に改善が進んでいったとい うまさに ”逆”割れ窓理論 21 🏚 逆割れ窓理論 🏠

Slide 22

Slide 22 text

● “逆”割れ窓理論が機能する条件 ○ 最初はマネージャーが率先して割れ窓を直し続けること ○ 目的志向であること、もしくは目的志向を植え付けること ○ あきらめないこと 22 🏚 逆割れ窓理論 🏠

Slide 23

Slide 23 text

● “逆”割れ窓理論の本質 ○ 本質は、チーム内での目的思考と改善活動の文化醸成 ○ 当たり前に目的を認識し、当たり前に数字に向き合う文化を作ること で、割れ窓が当たり前に修復される ○ いわば、組織文化が浄化作用を持ち始めることで、割れ窓が自然に直る 仕組みを作り上げることが”逆”割れ窓理論の本質 ○ その文化を作ることができれば、高速ゴミ製造機は高速価値製造機に変 われるはず...!(まだ道半ば) 23 🏚 逆割れ窓理論 🏠

Slide 24

Slide 24 text

今日の発表で語っていないことは記事に書いているので ぜひこちらも合わせてご覧いただければ幸いです! https://zenn.dev/ourly_tech_blog/articles/6a0a89a8955047