コミューンの２０％ルールって何？？

スクラム マネージメント 採用・働き方

初めに

こんにちは。ソフトウェアエンジニアの近藤です！ 2022 年 8 月からコミューンに入社し、当社サービスの commmune の開発チームで、フロントエンドおよびバックエンドの開発に携わっております。 今回は具体的な技術の話ではなく、コミューンの開発チームの取り組みである 20%ルールについてご紹介します。

20%ルールについて

Google などのイノベーティブな企業でも導入している 20％ルールですが、当社では下記のような運用ポリシーで行っています。

  1. 各自の業務時間の 20%を技術課題の改善に充てる。自分のマネージャーと相談しながら時間の調整などを行う
  2. 緊急度が低いが生産性に寄与する課題の解決をする。緊急度が低いが生産性に寄与する課題は長期的な生産性を上げるものの、これまで放置されてきた。後回しにされがちなこれらの問題の解決に取り組む。これにより生産性向上やメンバーのモチベーション向上を期待する

コミューンの開発は基本的にはユーザーストーリーをもとに開発計画が策定され、開発が進められます。 技術的な負債がないように開発を進めていくことが理想的ですが、もちろん開発には期限があり、その中で選択可能な実装をしております。

その際、手が回りきらなかったことや、スピードを重視し、簡易に実装するようなタイミングもあります。 （一応言っておくと、コミューンにおいてスピード重視で強引に実装するようなことはあまり発生しないです） そこで、コミューンでは明示的に開発の 20％の時間を割いて、技術的負債の解消に取り組んでいます。

その取り組みのことを 20%ルールと呼称しております。 20％ルールでは技術的負債の解消だけでなく、エンジニアの効率アップに関わる実装も実行可能です。

なぜ緊急度の低い課題を解決することが大事なのか

なぜ 20％ものリソースを割いて、緊急度の低い課題を解決することが大事なのでしょうか？

「いやいや 100％の時間を使って緊急度高いものからやるべきでしょ！」という意見もあると思うので、例え話で説明します。

エンジニアが 20 名いる C 社でソフトウェアエンジニアとして働く A さん。 A さんにはクライアントのニーズから洗い出されたタスクの中で一番緊急度の高いタスクに携わっています。

ふと A さんは開発効率が上がるライブラリの導入を思いつきました。 このライブラリを導入すると、一日 1 分だけ開発時間が短くなります。 また、A さんだけでなく、チームメンバーや今後のタスクでも開発の効率化が見込めます。 しかし、このライブラリを導入するには 5 時間ほどかかりそうなので、緊急度の高いタスクの開発を優先しました。

しばらくして無事、A さんはこの開発を終了できました。 これでようやく A さんは、開発中に思いついた開発効率を上げるライブラリを導入できるようになり、、ませんでした。

なぜなら、次の緊急度の高いタスクがあるからです。

もし、A さんがここでライブラリを導入できていた場合、
月々 20（エンジニア数） ✖️ 20（月の営業日） ✖️1 分＝ 400 分
の時間効率が稼げるわけです。 A さんが開発に割く 5 時間（300 分）はペイできますし、効果はしばらく続きます。

しかし、A さんにはこれから先も緊急度の高いタスクを順番に取り掛かるため、一向にこの作業はできませんでした。 一日一時間でもその作業ができたら、全体の開発効率が上がったのに。

--- BAD END ---

これは極端な例なので、ここまでシンプルになることはないですし、ツッコミどころが多い例え話です。 ただ、緊急度の低い課題に取り組むことで、短期的な効率は落ちるものの中長期的な効率の改善につながっていくことが伝わったら嬉しいです。

また、この例は開発効率をあげることの例であり、技術的負債についての例ではありません。 技術的負債についてもこの例と同様に放置されることで開発の生産性を下げる一方で、機能面での変化が見えにくいことから、短期では緊急度は低いように見えます。 しかし、実際は中長期的な生産効率をあげるためには技術的負債を解消していくことは必要不可欠です。

具体的な運用方法

具体的な運用方法については下記のようなフローで実行されます。 取り分けて特殊な内容でもないですが、参考までに共有させていただきます。

  1. 課題リストに課題を登録
  2. 担当者決定
    1. 課題リストの中からこの課題をやりますと宣言する。宣言した人を課題担当者とする。
    2. 複数人いればそのメンバーでグループを作る（途中から入るのも可）
  3. 計画
    1. 動機、方針、計画をドキュメントにまとめる
    2. 概要と上記を共有する
    3. 課題担当者と会議のメンバーは計画について議論する
  4. 実行
    1. 実行
    2. 毎週順調かどうかの進捗確認を行う
  5. 完了

私が実際に 20％ルールを行い感じたメリットと課題

私自身は現在 20％ルールの取り組みとして 500 error busters というチームに所属をしています。
＊20％ルールでは個人の活動もできますが、チームを作ることも可能です。
このチームの目的は Sentry を導入し、発生頻度が高いエラーや緊急度が高いエラー発生時の原因究明の迅速化や、エラーの根本解決ができるようになることを目的としています。 500 error busters の活動を通し、個人的には、下記のようなメリットが感じられています。

  1. 自分の興味のある課題から優先して解決に向かえるのですごくモチベーションがあがる
  2. 開発効率の向上に貢献できる
  3. 普段の業務で関わらないチームメンバーと関われる

1 と 2 についてはポリシーに基づくメリットですが、3 は意外なメリットでした。

commmuneの開発はスクラム開発で開発を進めており、私は普段チーム内のメンバーとの交流が多いです。 しかし、この 20％ルールでは社内のチーム外のエンジニアと関わることもできます。 実際に 500 error busters チームにはグローバライズチームや、SRE のメンバーなども所属しております。 このような環境で、普段関わらないメンバーと知見の共有や経験の共有ができるのも大きなメリットです。 （いつか 500 error busters の活動についても記事にまとめたいと思っています）

一方で、現時点では下記のような課題もあると感じています。

  1. 日々の業務の中で確実に 20％ルールに時間を避けない時がある
  2. モチベーションに差がある

1 については、私自身もそうなのですが、20％の時間が確保されているとはいえ、実際は日々のがありますので 20%ルールの時間を通常の業務に割り当てることもあります。 コミューンでは 8 月からこの 20％ルールの取り組みが開始された背景もあり、まだ文化として浸透しきっておらず、私のようなメンバーもまだまだ多いと思います。 ただ、少しづつ取り組みによる成果が見え始め、メンバーの中でもしっかりと 20%ルールに割く時間が増えてきているように感じています。

また、20%ルールに対し、モチベーションの高いメンバーとそうえないメンバーに差がある点も一応課題としてあげます。 一方で、一概に悪いこととも思えず、モチベーションの高いメンバーが各々の裁量で成果を出していける環境があるのは良いことだと思っています。

具体的に実施された事例の紹介

20%ルールで既に実施された事例のイメージを持ってもらうためにタイトルのみ紹介します。 詳細は、いつか実施したエンジニアが本ブログで紹介するかもしれないので、割愛します。笑

  1. Cloud Build 上で Next.js のコンテナイメージのビルド速度を改善した話
  2. 開発において必要な IDE の拡張のインストールを促すようにした
  3. cspell を Git 管理して pre-commit で実行するようにした ...etc

大なり小なり、開発者の技術的な課題や開発者の体験を上げるための開発が既に実施され、開発効率が向上しております。

私が今後 20%ルールを使って取り組みたいこと

私の個人的な目標としては Next image を使えるようにしたいと思っています。 言わずもがなですが、Next.js に搭載されている画像最適化コンポーネントです。

しかし、現時点の当社では採用をしておりません。 Next image は default だとフロントエンドサーバーに最適化の処理を担わせることになります。 基本的には画像処理の選択として有効な場合が多いのですが、フロントエンドサーバーの負荷を鑑みた結果採用には至りませんでした。

代わりに ImgIx を CDN として利用し、画像の最適化処理を行なっています。 ImgIx と Next Image を組み合わせた例もあるようなので、どこかのタイミングで検討をしていきたいなと思っております。 （Next.js のバージョンアップで Next Image も進化しているので、Next.js のバージョンアップが先かもしれません。道のりは長そう。）

また、いつかこの記事で共有できたら嬉しいです。

まとめ

本記事では、コミューンでの 20％ルールという取り組みについてご紹介しました。 明示的に業務の 20％の時間を生産性に起用する課題や技術的負債を解消することに割り当てることで中長期的な開発効率の向上を目指しています。

この記事を書いているときに、木の剪定をしていた亡き祖父の話を思い出しました。 立派な木を育てるためには定期的に邪魔な枝を剪定し、成長してほしい枝の成長を妨げないようにする。 そしてより多くの栄養が成長してほしい枝にいくようにすると。 エンジニアの開発も似ています。 大きな枝を育てるためには闇雲に木を育てるだけでなく、剪定をしていく作業が必要です。 我々コミューンはその剪定を 20%ルールで行い、立派な木＝よりよいプロダクト作りに励んでいます。