広告技術部の toshimaru です。本記事では広告技術部内で行っている取り組み、Kaizen Day制度についてご紹介いたします。
- Kaizen Day制度とは
- Kaizenタスクとはどんなものか
- Kaizen Day制度を作ったモチベーション
- なぜKaizen Dayなのか
- Kaizen Dayをどのように運用しているか
- Kaizen Dayの成果
- さいごに
Kaizen Day制度とは
Kaizen Dayとは開発チームが何らかの改善を集中して行う日のことです。
Kaizenタスクとはどんなものか
「何らかの改善」と書きましたが具体的にはどのようなものでしょうか? Kaizen DayでやるKaizenタスクは具体的に下記のようなタスクを想定しています。
- 負債返済
- リファクタリング
- 小さなバグFix
- 小さなデザイン修正
- 既存のツールの改善
- 新しいツールの導入
- コードベースの一部のモジュールのOSS化
- 普段やっている開発タスク
負債返済やリファクタリングはすぐに思い浮かぶKaizenタスクの例だと思います。本制度のユニークな点はそれらに加えて「普段の開発タスク」もKaizenタスクのスコープに入れている点です。
私が本制度で大事にしたかったのは<改善を誰かにやらされるのではなく、自分がやりたい改善をやる>ということです。つまりチームの開発メンバーひとりひとりが受動的に改善をやらされるのではなく、主体的に改善を行ってほしいという思いが本制度の背景にあります。したがってメンバーには「改善したいことが特に思い付かないのであれば普段のタスクをやってもよい」と伝えています。なぜなら誰かにやらされるような改善はして欲しくはないですし、普段推し進めているタスクも広い意味ではプロダクトにとって一つの改善と言えるからです。
またコードベースのOSS化というタスクもKaizenタスクの例として入れています。OSS活動をすることでエンジニア個人のスキルアップにもつながりますし、コミュニティへの還元にもなります。再利用性の観点からも一部のモジュールを切り出して公開することは意味があります。裏目的として「みんなもっとOSS活動やってこうぜ!」という私の個人的な思いも入ってます。
Kaizen Day制度を作ったモチベーション
Gunosyでは日々様々なKPIを追っています。どんなKPIをどう追っているかについては下記の記事に詳しいです。
しかしKPIを日々追っているだけで良いかと言うとそうではないと考えます1。なぜなら技術的負債の返済やコードのリファクタリングなど直接KPIには寄与しないタスクもあるからです。だからといってそれらのタスクをやらなくて良いかと言うとそんなことはありません。その後のコードメンテナンスに伴う開発生産性やエンジニアのモチベーション維持などの面でそういった改善は継続的になされるべきです。
また細かなデザインの修正やバグの修正にも同じことが言えます。キレイにしたところでどれだけユーザー影響があるかわからないデザイン修正や1%のユーザーが困っているようなバグはしばしば優先度が低くなり無視されがちです。しかしそういった小さな箇所から生じる小さなガッカリ体験の積み重ねがユーザーを離脱させているかもしれません(そしてこういった離脱はKPIにはなかなか見えにくいものです)。
日々のKPIウォッチだけでは拾いきれないプロダクト改修を積極的にチームのメンバーにやってもらいたい―その願いがKaizen Dayを作ったモチベーションです。
なぜKaizen Dayなのか
世の中の開発組織には本制度に似たような制度があります。私が聞いたことのある制度の例だと下記のようなものです。
- バグFix Day: バグをひたすらFixする日
- 負債返済Day: 負債返済する日
- Issue消化Day: 溜まったGitHub Issueを消化する日
- OSS Day: OSSコントリビュートする日。Speeeさんの制度紹介
制度の名称に関しては何でも良かったのですが、改善の内容を規定したくなかった(開発メンバーそれぞれが思う最高の改善を行ってほしかった)のであえて一番ゆるく改善ができそうなKaizen Dayという名称で制度をスタートさせてみることにしました。
つまりそれが何かしらの改善につながるのであればバグFixであろうと負債返済であろうとIssue消化であろうとOSS貢献であろうと何をやっても良いということです。
余談になりますが、この制度を考えついたときは他社にはない制度だろうと思っていたのですが、本記事執筆時に調べてみると2016年のサイボウズさんの発表ですでに全く同じ名称の制度が存在していることに気付きました(笑)。
Kaizen Dayをどのように運用しているか
Kaizen Dayをチームでどのように運用しているかですが、1スプリントに必ず1日Kaizen Dayを設けるようにして運用しています。私のチームの場合、1スプリント=2週間なのでスプリントの最後の金曜日をKaizen Dayとして一日確保するようにしています。
またKaizen Dayでやるタスクは一日で終わるくらいのサイズのタスクにしてもらうようにしています。タスク完了までに何日もかかるようなサイズのタスクに取り組んでしまうと、1 Kaizen Day/スプリントのペースだとリリースまでのリードタイムが長くなってしまうからです。そのようなKaizenタスクをやりたい場合は別途相談してもらい、スプリント内の通常タスクとして組み込めないかを検討するようにしています。
Kaizen Dayの成果
Kaizen Dayを制度運用してみて上がった成果の例としては下記のようなものがあります。
- Railsのバージョンアップ
- 管理画面の新デザインのプロトタイプ作成
- ES6 の導入
- エラートラッキングサービスSentryの導入
- MySQL Collation の修正
上記はあくまでも一部で、上記以外にもたくさんのリファクタリングやバグ修正などが行われました。
先日記事として公開した下記プロジェクトもKaizen Dayの一環としてスタートしました。
さいごに
最初は私のチームだけでスタートさせた制度でしたが、気づいたら隣のチームもKaizen Dayを導入して成果を上げており本制度を導入して本当に良かったと感じています。
チームの継続的改善をサポートするためにも今後もKaizen Day制度を続けていく所存です。
最後になりますがGunosyでは一緒にKaizen Dayでプロタクトやコードを改善してくれる仲間を募集中です。下記からお気軽にご応募お待ちしております。
-
ここでいうKPIとはビジネス的なKPIのことを指しています↩