こんにちは！
ourly株式会社 執行役員CTO(@tigers_loveng)の相澤です。
この記事は開発生産性 Advent Calendar 2024の16日の記事です。
先日行われたFindy Team+ Award 2024において、Frontier AwardのSelf Management Division部門において弊社を選出いただきました！
なんとど真ん中いただきました...！
Self Management Division部門は、開発組織全体で自己組織化が促進されている組織を表彰対象とする部門で、弊社ではトップダウンからボトムアップでの生産性向上を実現できており、そこを評価いただけたのかなと思います。施策の具体的な話は、以下記事をぜひご覧いただければ幸いです！
サイクルタイムが360hだった1年前
華々しく語っておりますが、実は開発生産性向上に真剣に取り組み始めたのは去年の5月からで、その時(2023年5月)のサイクルタイムは驚異の360h！！！！！
変更をcommitしてからmergeされるまでに15日かかる計算ということになります。
もちろん平均値なので、めっちゃ長いものもあれば短いものもありますが、それでも長すぎますよね。。
ちなみに最新値(2024年11月)は17hまで縮められており、約1/20になりました！
2023年5月と2024年11月で詳細に比較すると、単純にPR数が少なくて外れ値的に短くなっているわけではないということがお分かりいただけると思います。また、チームの人員(顔ぶれ、人数)は変わっていないため、一人一人の生産性が改善されたと言えます。
なぜサイクルタイムが長くなっていたのか
ではそもそもなぜ、改善に取り組む前はサイクルタイムが360hと長期化してしまっていたのでしょうか？
EMが管理すべきマネジメント領域でいうところのピープルマネジメントとプロセスマネジメントの2つの領域に大きな課題を抱えていたからでした。
ピープルマネジメントの課題: 権限移譲できないEM
当時の開発体制では、メンバーが担える仕事はほぼ「新機能開発のためのPR作成」に限られていました。以下のメイン開発以外のタスクは基本的に、当時EMだった僕かテックリードといった上位ロールが主に推進していました。
- タスク管理やプロジェクト進行などのPM(プロジェクトマネジメント)タスク
- 開発フローやプロセスの改善
- チーム体制や組織上の改善活動
- コードベースの継続的リファクタリング
- 外部との調整やその他の運用タスク
明確に役割を限定していたわけではないのですが、僕とテックリード以外はジュニアエンジニアが多かったため、自然とそういう役割分担になってしまっていました。
また、僕自身、ジュニアエンジニアは新機能開発をバリバリこなしてガンガンスキルアップしてもらうべきと思っていたのでなるべくメイン開発タスク以外は任せないようにしていました。
その結果、メンバーが自分たちの作業範囲を「新機能開発におけるコーディング」に限定されたものと感じ、組織改善や開発フローの改善へ主体的に参加しづらくなっていたように思います。
プロセスマネジメントの課題: マネジメントレイヤーのブロック
ピープルマネジメントの課題でも触れましたが、権限移譲がなされていない状態の開発体制だと、当然他のところにも影響が出てきます。弊社はスタートアップということもあり、仕事の種類が非常に多岐にわたるため、権限移譲が進まないと必然的にマネジメント層が業務過多に陥ります。
単純にタスク量が多いだけでなく、タスクの種類が多いため、スイッチングコストやMTG時間が増加し、ペアプロなどのメンバー成長サポート、コードレビューが後回しになっていきました。
プレイングマネージャーでもあった僕は、メインの開発タスクも持っており、当然PRは出すもののレビュー修正が追いつかないという事態に陥ってしまったのです。
コードレビューやレビュー修正が後回しになると、後続タスクが進められなくなるため、レビュー待ちのPRに依存する形で新しくPRが作られていくなど雪だるま式に増えていきます。
こうして、一時はなんと100PRほどオープンされた状態になっていました。
D-Plus Tokyo #4 ~しくじり事例から学ぶ！開発生産性の取り組みLT会~の発表資料より抜粋
また、当時は本番環境へのあらゆる変更に対し、プロダクトオーナー（PO）の承認を求める運用ルールが存在していました。もちろん、UI/UXに影響のある変更であれば、POやカスタマーサクセスチームとリリース時期を調整し、影響範囲を明確にすることは重要ですし、今も継続しています。
しかし、UI/UXやユーザー体験に直接影響しない内部的な変更（例えばリファクタリングやテスト拡充など）にまで一律で承認をもらっていたのです。弊社では代表がPOを担っていますが、例に漏れず忙しいため、承認待ちが発生し、その結果変更のリードタイムが長期化します。
なぜそうしていたかというと、どんな些細な変更であれ、本番環境でトラブルが発生した際、誰が責任を負うのか明確にしておきたい、という狙いがありました。しかし、内部改善のような変更は、PO側からすると「そもそもコードの内容が分からない」ため、承認といっても実質的には「はい、どうぞ」という名ばかりの手続きになりがちでした。
コードベースの改善や内部的な変更をわざわざPOに報告・承認を求めることで、チーム全体の効率が下がり、開発スピードや責任所在の明確化という本来の目的にかなわない状態が生じてしまっていました。
つまり、EMボトルネック化によるブロックと、POの承認待ちブロックの2つのブロックが存在していたということです。
課題への対応
ピープルマネジメントの課題への対応
「権限移譲」の解決策は「権限移譲」以外にはありません。とはいえ、一概に全てのタスクを移譲できるかというと、そうではありません。
ジュニアメンバーが多いということもあり、コードレビューなど技術的ハードルの高い領域を任せるのは難しいと判断しました。しかし、すべてを一足飛びに丸投げするのではなく、段階的に任せられる領域から移譲していきました。
開発タスク以外の移譲
弊社メンバーは幸い、主体的な人が多かったのでPM領域のタスクや、改善活動などを渡しても推進してくれるだろうと考えました。ただし、丸投げではなく、随時EMから進捗の確認や助言などをしながら旗振り役を担ってもらうという形でお願いすることにしました。
イメージでいうと情報収集をプル型からプッシュ型に切り替えたような感じです。チームMTGや評価面談などのタイミングでこういう役割を任せたいという話をし、それから関連タスクを任せていきました。
最初は報告頻度を多めに設定し、フォーマットを擦り合わせて報告してもらい、徐々に頻度を抑えていく形でうまく移譲ができました。
Whyと意思決定プロセスの可視化
これまではマネジメントレイヤーが進めていた仕事は、マネジメントレイヤー間で議論・検討が行われ、最終的な結論だけをメンバーに伝えるスタイルでした。しかし、そのスタイルだと、どういう視点で見て、どういったことを考え、どのような意思決定軸があるかがブラックボックス化してしまいます。
すると、いざメンバーに任せた時に、期待していたアウトプットとずれたものが上がってきてしまい、手戻りが大きくなります。これではマネージャーの仕事は減らず、メンバーのモチベーションも次第に下がっていくことになるでしょう。
ということで、「なにを課題だと思ったのか」「なぜその結論に至ったのか」という意思決定プロセスそのものを開示することにしました。意思決定の背景が明確になることで、メンバーは課題点を理解しやすくなり、自らの考えを提案しやすくなりました。また、意思決定軸が擦り合わせやすくなるので手戻りやレビューコストも抑えられます。
具体例では、サイクルタイムの短縮化に取り組むことに関して、なぜやるのか、どこまで縮めるのか、どういう考えのもと決めたのかなど、明確に僕の意思と理由と、意思決定プロセスを開示しました。
プロセスマネジメントの課題への対応
権限移譲を進めると同時に全体的なレビュープロセスの見直しを行いました。
コードレビュープロセスの改善
それまではなんとなく全員がapproveを出さないとマージしないというなぁなぁな感じでやっていたところを明確化していきました。EM/テックリードどちらかのapproveでマージOKにしたり、先にメンバー間で相互レビューしてもらい、EM/テックリードのレビュー負荷を軽減したり...etc。
ルールはメンバーのスキルレベルに合わせて変えていき、現在は以下のルールで運用しています。
- PR作成者がそのPRに適切なレビュアーを選ぶ
- 1レビュアー以上のapproveがあればマージOK
このレビュールールは色々な変遷を辿っているのでそれはまた別途記事にしたいと思います。
プロダクトレビュープロセスの改善
本来、ユーザー体験に直接影響しない技術的変更（リファクタリングやテスト拡充など）は、開発チーム自身が責任を持って判断できるはずです。そこで、POと直接話し合いを行い、以下の方針に合意しました。
- UI/UXや動作にユーザー影響がある変更
- 従来通り、POやカスタマーサクセスと連携し、リリース時期や影響範囲を検討
- 内部的な技術改善やユーザー影響がない変更
- プロダクトチーム（EMやテックリード）の判断でリリース可能。
これにより、技術的な観点から見て問題なければ、PO承認を待たずにリリースできるようになりました。これで無意味な承認待ちが減り、開発スピードが向上する土台が整ったのです。
その他成果に結びついた要因
プロダクト立ち上げ時からテストを書き、CI/CDを整備していた
去年のAdvent Calendarの記事でちらっと触れましたが、テストコードとCI/CDを整備していたので、純粋に開発フローやコミュニケーション方法の見直しで、数値を改善することができました。
初期から不具合やクリティカルな障害は発生させなかったことが、承認フローの短縮や権限移譲につながったのだと考えています。
なので、開発生産性向上において、まず取り組むべきはテクノロジーマネジメントの領域だと今では考えています。
開発生産性に強い興味関心を持ったメンバーがいた(採用できた)
現在、僕と一緒にD-Plusコミュニティの運営をしている神本さん(@naoto__911)や社内の生産性警察を務める藤野さんといったメンバーが、開発生産性に強い興味関心を持っていることが1on1で分かり、色々任せることができたのも大きな要因の一つです。
トップダウンで始めた施策も最終的にはメンバーがそれを理解し、実行しなければチームの文化としては根付きません。誰か一人でも良いので巻き込める人を作れるかどうかが鍵だと思います。
そういう意味では採用シーンにおけるブランディングや、採用時の見極めなどがとても重要になってくると考えています。
来年のAwardに向けて
最後に来年のAwardに向けた豊富で締めくくります！
来年は...Organization Award Small Divisionでの表彰を目指します！
そのための施策もすでにいくつか走り出しています。施策の内容や効果などはまたおいおい記事化しますのでぜひ楽しみにしていてください！
最後までご覧いただきありがとうございました🙇♂️
おまけ(というか自慢)
弊社では開発生産性の可視化にFindy Team+を使っているのですが、データが残っている最古の月から現在までのサイクルタイムの変遷を月毎に見てみると...
ひとえに一緒に働く素晴らしいメンバーたちのおかげです。
いつも本当にありがとう。来年以降もよろしくお願いします！！！！！！！！
Discussion