見出し画像

LAPRASにおける20%ルール的なものとその心

rocky_manobi

この記事は 2021-LAPRAS Advent Callender 14日目の記事であるとともに、2020-LAPRAS Advent Callender の378日目の記事です。

こんにちは。LAPRASの@rocky_manobiです。AdventCallenderの時期になるとついついポケモンについて書きたくなってしまうのですが、たまにはまじめに社内の制度について紹介してみたいとおもいます。


LAPRASでは某G社の20%ルール的なものを「クリエイティブな時間」という名前で運用しています。一昔前に某G社では消えてしまったとも噂のあれです。狙いも運用も本家と完全に一致するわけではないのですが「取り組む内容を個々人が決定することのできる時間」という意味において同じようなものだと解釈しつつ、どのように運用しているか/その心について紹介したいと思います。

また、僕がこのエントリで言いたいことは 「緊急ではないが重要なことに継続的に取り組みたいのであれば、優先度を都度判断をするのは辛いのであらかじめ時間を予算として確保してしまおう」 というもので、これだけでございます。

クリエイティブな時間 とは

まずはクリエイティブな時間についてざっくりと紹介します。制度のas isの紹介なので退屈かもしれません。

  • Sprint Backlogに積まれたタスク以外で、業務効率改善や自分のスキル向上など、開発者それぞれが「会社のためになると思うこと」のために使える時間のことを「クリエイティブな時間」と呼びます

  • 二週間スプリントのうち はじめの 2日間をクリエイティブな時間とします(10営業日のうち2日間なので20%ですね)

  • ↑の2日間のはじめと終わりには「何をやるか宣言する会」「成果をドヤって称えあう会」を設けます (同期/非同期は問いません)

具体的に期待される活動としては「手を入れると後々便利になりそうだが、Issue化して新規機能開発と比較されてしまうと優先度が下がりがちなタスクに取り組む」「導入してみたい技術やツールの検証時間に使う」「学習のために普段の業務で使わない技術を触る」といったところです。

スクラムチームの開発者として取り組むPBLの開発とのすみ分けで言うとこんな感じです。

ちなみにLAPRASにはクリエイティブ大臣という「クリエイティブな時間をより効率よく使える環境を整える」ためのロール(役割)が存在します。現在は 遠藤さん にお願いしているのですが、上記の切り分けも就任直後に整理/明確化頂きました。こういった認識合わせを大事にするところ、またその技術も最高of最高で、いつも助けられております。弊社では現在エンジニア採用をしておr….

クリエイティブな時間にふさわしいタスクかどうかは誰かの承認を必要とするものではなく、「PBL以外で開発者それぞれが会社のためになると思うこと」としています。

運用の心

ここからは、どうしてこんなものを運用しているのかについてつらつらと書いていきます。

本当にやる気なら先に時間を確保する

意識的にスプリントの 前に 時間をとっていますが、こういうことです。

PBIをやっつけた後の空き時間でやろうとすると「ある人はクリエイティブな時間を確保したいので水曜日までに終わらせたい」「ある人は特にクリエイティブな時間でやりたいことが思い浮かばないので金曜日までかけていい」という認識の違が生まれやすくなります。
結果どうなるかというと、金曜日までPBIは消化されず、誰もクリエイティブな時間を確保できないというルートをたどることが多くありました。

同様に、個人が時間を見つけて～とするのも難しく、この場合はコンテキストスイッチの問題が発生します。1日に2時間ずつ作業を進めるとしても、「これまでの作業を終了する」「何をしていたか思い出す」「進める」と、連続して時間を確保するよりも負荷が高まります。
まとまった時間を個人の努力で2日とるというのもそれなりにカロリーを使います(多分)。

かつて方々から聞こえた「うちも20%ルールやっています」という声を最近聞かなくなったのは、もはや当たり前になったからなのか、↑のような運用で形骸化してしまったからなのかはわかりません。
とはいえ「できますよー！」と言っておいて「実は形骸化していて実際は誰も時間取れていません」というのはやっぱり悲しすぎるので、強い気持ちで確保していきたいです。

個人のアンテナを大切にしたい

語弊を恐れずに言えば※1、PBIの消化という分かりやすくチームに貢献できるタスクがあるからこそ、20％程度はそのレールに乗らない価値提案を個々人が行う機会を持ってほしいと考えています。

POやPdM、チームリーダー(弊社の場合はCircle Lead)も全力を尽くして優先度を判断していますが、決して万能ではありません。開発を進めていくうえでの課題を一番感じとっているのは実際に開発をしている人であり、学習の必要性については個人個人の認識が何より重要です(メンター的な人からアドバイスを受けるのも大事ですが、文脈が違うからね！)
そうした個々人の活動の成果をインプットとして、優先度を決める責務を持つ人が認識を新たにすることも多々あるでしょう(僕はそんなのばかりです)。

また、一人では解決できないような課題やタスクに取り組む場合は当然チームに提案をすることになりますが、その前段階においては個人で調査/検証する時間はどうしても必要です。個々人の努力でその時間を捻出することを求めるよりも、時間の余裕を持たせておくことでそうした活動に時間を使う心理的な負荷を下げたいと思っています。
話はそれますが、方向性を決める責務を持つ人はその業務時間のほとんどを調査やデータ分析につぎ込んでいます。同じような活動に使うための時間を用意することは必要なことだと考えています。

※1-大前提としてPBIはチームとして今取り組むべきと合意された緊急で重要なものです。また、スクラムチームの開発者の目的はPB Iの消化ではなく価値提供です。PBIは与えられるものであり、中身に無頓着であってよいという意図はありません。

※LAPRAS特有の事情
LAPRASでは組織運用に「ホラクラシー」というフレームワークを採用しています。多くのエンジニア職の社員はスクラムチームの開発者であると同時に、情報システムやSiteReliability、PR、一時は法務など、スクラムチームの仕事以外のロールを担っています。
これまでの説明に「チーム外の仕事」と出てきているのはこのためです。

余力を持ちたい

20%の時間を最初から差し出しているわけなので、有事の際にはこの調整だけで20%分のパワーを無理なく注ぎこむことが可能です。クリエイティブな時間に限らず、緊急でないが重要な仕事に普段から取り組んでおくことは、短期的に全勢力を傾けるべきと判断したときにリードタイム無しで出せる最大戦速を向上させます。

クリエイティブな時間の成果物

簡単ですがクリエイティブな時間から生まれた色々をご紹介します。ちょっと時間がないので覚えているやつだけ垂れ流します。

こういった取り組みを筆頭に...

ESLintの強化 / Djangoの学習 / インフラ及び利用サービスを俯瞰した図の作成 / フロントエンドのエラーハンドリングの仕組み改善 / Geekbot導入のためのいろいろ /オフサイトイベント運営にむけたインプットのための読書 / 怪しいコードのリファクタリング / 利用しているミドルウェアorサービスの移行 …

などなどどれも重要な取り組みです。普段の開発で感じた課題を解決する時間として、個々人に余力がある状態を作っておくことは重要だと思っています。

※上記に類することでもチームとして重要だと感じられるところは「緊急かつ重要」として対処をしているので、上記のような課題感をすべてクリエイティブな時間に頼っているわけではありません

緊急ではないが重要なことに継続的に取り組むために

というわけで弊社の20%ルール「クリエイティブな時間」のご紹介でした。

"緊急ではないが重要なこと"の優先度を都度都度判断するのは正直しんどいです。事業フェーズの意識はもちろん、単純なインパクトの比較だけでなくどの時間軸で優先度を判断していくのかなどなど、考えることが多すぎます。

なので、LAPRASのCTOとしては最低限全体の30%強程度が改善活動に使われるような構造を作りつつ、それぞれの領域で管理頂いている課題が打ちとられていくことを基本路線としています。
具体的には、スクラムチームはフォーカスをシャープにするために直接的な顧客への価値提供に全振りしつつ、改善活動はクリエイティブな時間の枠や、遊撃部隊という別動隊が担うという構造です。
この体制をベースに進捗や状況の変化を観察しつつ、責任をどう割り振ってどう相互にコミュニケーションしていけば美味しいのかなどなど、これからも試行錯誤をしていこうと思います。

宣伝

最後までお読みいただきありがとうございました。
あなたはきっととてもお優しい方か、LAPRASにご興味をお持ちの方だと思います。LAPRASでは一緒に開発をしていただけるエンジニアさんを募集しています。このような取り組みなどいろいろやっておりますので、是非ご検討くださいませ！


この記事が気に入ったらサポートをしてみませんか？