はじめに
こんにちは。PharmaXでエンジニアリングマネージャーをしている古家(@enzerubank)です。
本記事では、20%ルールを開発チームに導入する際の意義についてまとめてみました。
Googleの20%ルールの定義
20%ルールはGoogleが始めた施策として有名です。Googleにおける20%ルールとは、「業務時間の内の20%を普段の業務とは異なる業務(Googleにおいては新規事業立案)にあてて良い」という制度です。
GmailやGoogleマップといったサービスは20%ルールによって生み出されたと言われています。
20%ルールの導入事例
20%ルールの目的は現在の業務で精一杯になっていて未来のために投資すべきことに時間を使えていないという課題を解決することです。そのための手段として「業務時間の内の20%を普段の業務とは異なる業務にあてて良い」という制度になっています。
大企業では自由な発想から新規事業を生み出すこと、ベンチャーやスタートアップ企業では今の開発を優先して後回しにされていた緊急度の低い改善系の課題に手をつける時間として使われているケースが多そうです。
PharmaXにおける課題意識
弊社ではSentryを導入しているのですが、エラーの原因調査と根本解決を特定のシニアエンジニアだけが自主的に進めていたり、障害として連絡のきた緊急度の高いものだけ焦って対応するという状態になっていて、発生頻度が少なかったり、頻度が多くても原因究明が難しいエラーは放置されていました。
また、技術的負債に関してもどうしても緊急度が低いので機能開発の方が優先されてしまい、開発効率に影響を与えるレベルでの技術的負債が溜まってしまうという状態でした。
技術的負債に関してはプロダクト開発が落ち着いた時期があったので、そのタイミングで全員で解消に動いたため、重要度の高い負債に関しては解消することができたのですが、20%ルールのような安定的に対応していくプロセスがなければ同じような問題がまた発生してしまいます。
エラーや技術的負債を解消することはなぜ大事なのか？
この問題について考える際にフィリップ・クルーシュテンが定義した以下の4象限が参考になります。「見える/見えないの軸」と「プラスの価値/マイナスの価値の軸」の2つによるマトリクスです。
エラーは左下の「欠陥」に該当します。左軸は「見える」ので振る舞いが直接ユーザー体験に影響を及ぼします。エラーが多いほどユーザーにネガティブな価値を与え、ユーザー体験が悪化します。
技術的負債は右下に該当します。右軸は「見えない」ので、直接ユーザー体験に影響は与えませんが、システムの構造を悪化させるため、開発者体験が悪化します。
開発者体験の悪化による悪影響はこの記事では深掘りはしませんが、
- コードが複雑化することでバグを生みやすくなり、機能開発の開発速度も落ちる
- エース級のエンジニアが技術的負債の解消に追われ、チームのパフォーマンスも下がる
- 負債の解消ばかりでエンジニアが疲弊する
- パフォーマンスもエンゲージメントも下がり、ビジネス成果や組織持続可能性が下がる
といったような悪いループに入っていくことになります。
20%ルールだけで解決するのか？
スプリント期間の20%の時間しか当てられないので、大規模な改善活動には取り組みづらいです。そのため、大規模な改善を行う場合は事業部長やPdMと事業目標の達成のボトルネックとなっている技術的負債の返済のゴールをどうするか、何をするのか、どれくらいの期間とリソースを使うのかということをこちらから身を削るような提案を行うことで、お互いがお互いに歩み寄った対話を行ってスケジュールに落とし込んでいく必要があります。
ただ大規模な改善を何度も行っていられるほど、リソースは潤沢にないというのが普通だと思います。なので、大規模改善をやらざるおえないというのは最終手段として考えておき、普段からコツコツ20%ルールで自主的に自分たちのシステムを良いものにしていく習慣が開発チームには求められるのではないでしょうか。
FAQ （2024.10.18追記）
記事を出してから質問をもらったので追記しておきます。
Q. 技術的負債を返済することに時間を使うのは本来の20%ルールとは言えないのでは？
A. 本来の20%ルールは普段の業務とは異なる業務をやっていいよというもので、Googleでは新規事業のイノベーションを起こすことを目的にしていたので技術的負債を返すことに限定してしまっているのは厳密には20%ルールとは言えないかもしれません。ただスタートアップでは技術的負債を返すという業務自体が普段の業務で当たり前にできていないケースも多く、その意味で20%ルールを設けることには意味があると考えています。
さいごに
弊社はまだ制度としては20%ルールはこれから導入する段階なので、チームに共有する際の説明資料としてそもそも何のために導入するのかという意義の部分の話を今回は書いてみました。
ただ実際の導入の際には気をつけておくべきポイントが色々あるので、実際の実施方法についてはまた別の機会で記事にまとめようと思います。
今回の記事の内容が少しでもエンジニアやEMの方の参考になれば幸いです。
PharmaXエンジニアチームのテックブログです。エンジニアメンバーが、PharmaXの事業を通じて得た技術的な知見や、チームマネジメントについての知見を共有します。 PharmaXエンジニアチームやメンバーの雰囲気が分かるような記事は、note（note.com/pharmax）もご覧ください。
Discussion