Kaizen Platformには、「Kaizen Week」と呼ばれる1週間すべてのプロダクト開発がストップする期間があります。
そう聞くと、なぜ？　目的は？　といった疑問が湧いてくるかもしれません。

Kaizen Weekとは、クォーターに一度「重要度は高いけど、緊急度は高くないこと」に取り組む期間のことを指します。

Kaizen Platformではエンジニア行動指針を定めているのですが、Kaizen Weekは下記の行動指針に紐づく取り組みで、今回は17回目の開催となりました。

・働き方を改善し続ける
・成果を出し続けるために、設計を守り抜く
・共に学び、高め合う

※エンジニア行動指針とは
Kaizen Platformの「改善者たれ」というValueを体現する考え方・行動としてあるべき姿をまとめたもの。
https://recruit.kaizenplatform.com/engineer/doctrine

Kaizen Weekは、敢えて優先度の低いタスクを実行する期間

普段の業務では重要度に関わらず緊急度の高い仕事をしがちですが、「重要度は高いけど、緊急度は高くないこと」を放置していると、精神衛生上マイナスに作用するのはもちろん、いずれ大きなリスクを負ったり機会損失をしたりする場合があります。最たる例は、リファクタリングです。

そのような中長期的なリスクを防ぐためにも、カスタマー向け業務以外の通常業務を一旦離れて、優先順位の関係で手をつけられていないタスクや、温めていたアイデアを1週間かけて形にしていきます。

このときに重要なポイントは、個人的に興味があるタスクではなく「重要度の高いタスク」に取り組むことです。

そのため、主なタスクとしては

・普段の開発を効率良くするもの
・普段ユーザーに使われるサービスのかゆいところに手が届く機能改善
・日常的に繰り返し行われている作業を自動化して運用改善

などが挙げられます。

Kaizen Weekは1週間とタスクによっては短いこともありますが、アイデアが優れていた場合にはそこからプロダクト開発に取り込まれ、ブラッシュアップを経てリリースされることもたくさんあります。
取り組まれたタスクはほとんどの場合において作りっぱなしにすることなく、何らかの形でユーザーの利便性や運用、開発の改善に寄与しています。

取り組み事例

今回のKaizen Week（実施期間：2022年2月14日〜2月21日）のテーマは、「コスト削減」。なお、テーマはあくまで、課題設定のアイデアの種として推奨しているもの。それ以外のタスクに取り組んだメンバーも多くいました。

その中からいくつかピックアップしてご紹介します。

---------------------------------------------

ECS EC2 => Fargate 化でコスト削減（本田雄一郎）

解決したい課題
ECS のデプロイは標準ではローリングアップデートを行うため、必要なリソース数の2倍のリソースを常に確保しておくという冗長構成をとっていた。
これはデプロイを安全におこなえるものの、コスト増というデメリットがあった。

解決方法
ECS Fargate への移行を実施。
今回の移行対象は、Kaizen Ad で広告配信データを収集・レポート化する機能。

※データ収集基盤については、こちらの開発談もあわせてご覧ください
データウェアハウスの開発で苦しんだ話 - Google Ads配信データの収集

具体的におこなったこと

・Fargate 移行にともない、CircleCI のデプロイスクリプトを修正
・ecspresso を使用したデプロイで、デプロイ時環境変数の更新を自動化
・上記にともなうMakefileの細かい修正

Fargate 移行後もデプロイは問題なくできており、インスタンスのコスト削減に貢献できた。

Data Platform 改善: ref function 実装とETL Docker化案（Yasuhiro Manai）

解決したい課題
Data Platform(当社のデータ集計基盤の呼称)の現状のパイプライン機能では、1段目の集計結果を投入する中間テーブルを、2段目の集計で動的に指定する事ができなかった。
そのため、あらかじめ中間テーブルを空の状態で作成しておく手間が発生していた。

※データ集計基盤については、こちらの開発談もあわせてご覧ください
Kaizen Platformのデータ処理基盤「Data Platform」のご紹介

解決方法
1段目の集計で出力するテーブル名を、2段目の集計クエリで動的に指定できるようにした。具体的には、 Data Platform ではクエリに変数を設定する仕組みがあったが、今回の改善により変数だけでなく ref 関数も使える仕組みにした。

以下はクエリのイメージ
SELECT * FROM {{ref(‘etl1’)}}

これにより、パイプラインを組む際に中間テーブル名を意識することなく、多段式のETL処理を書くことができるようになった。

Chrome 拡張 + Slackbot によるリリース管理プロセスの改善（Yuto Kogure）

解決したい課題
当社では多くのマイクロサービスを運用しているが、定時リリースに各レポジトリのどの PR(プルリクエスト)をデプロイすべきかの管理が煩雑になっていた。整理・自動化による改善したいが、手がつけられていなかった。

解決方法
リリース管理専用 レポジトリ の Issue に、定時リリース物の全 PR を記載する運用に変更。Issueには PR ページから直接追加できる Chrome 拡張を作成し、作業を効率化。

リリース前後の確認・リマインドはslackで通知し、漏れを防止。

これにより、リリースの管理作業負荷が大きく改善することができた。

“重要度は高いが、緊急度は高くない”タスク精度を上げていく

今回のテーマ「コスト削減」に則ったタスクでは、過去にコスト削減が実現した事例を転用できるかという観点での取り組みや、大きくコストが削れる箇所にフォーカスした取り組みなどが見受けられました。

それ以外の全ての取り組みも、着手したことにより対応方針が明確になったり、次にクリアすべき課題が発見できるなど、「重要度は高いけど、緊急度は高くないこと」の中身の精度が上がる結果となりました。