各種ライブラリのバージョンアップや軽微な修正など出来ていますか？

STORESのフロントエンドチームは、週替わりで運用・カイゼン担当者を割り当てています。
担当になった人は、日々の上がってくる不具合の調査や対応、手が回りにくい技術的負債の返済などのカイゼンを行っています。

サービス開発をしつつ、不具合対応やカイゼンをどう回しているのか、ひとつの事例として参考になれば幸いです。

※ 本記事は STORES.jp Advent Calendar 2019 - Adventar の3日目の記事です。

カイゼン担当は持ち回りで行う！

カイゼン担当は1週間ごとに持ち回りで行うようにしています。
つまり常に誰かしらがカイゼンを行い続ける状態にしています。

通常のサービス開発と切り離し、全員で行うメリットは次のような点です。

カイゼンを止めない
- 常にカイゼン用の人を確保し、技術的負債の返済をする
サービス開発を止めない
- サービス開発時の工数見積もりはカイゼン週の作業があることを考慮する
- 本番環境で発生した不具合を直す作業をする
カイゼンを属人化させない

チケットの管理にはGitHubプロジェクトを利用！

チケットの管理ってどこでするか悩みますよね。RedMine？Jira？Asana？GitHub？etc？
次の条件にマッチするものを考えると、GitHubプロジェクトが手軽で良いかなと判断しました。

無料
カンバン形式
オンラインで利用可能
API がある
使い慣れている
GitHub の Issue と紐付け可能

GitHubプロジェクトは Organization 直下に作り、複数のリポジトリのIssueを統合できるようにします。
GitHubのIssueは開発用のIssueもあるので、プロジェクトに紐付けて埋もれないようにします。

カンバンの列（カラム）は8つに分類！

GitHubプロジェクトでは、次の8カラムを用意しました。

カラム	用途
New Issues	カイゼン Issue はすべてここから始まる
Ignore	※
Icebox	要検討の Issue
Backlog	カイゼンすると判断した Issue
In progress	着手している Issue
Review in progress	レビュー中の Issue
Reviewer approved	レビュー完了した Issue
Done	マージ（リリース）した Issue

※ STORESではエラー通知にSentryを導入していて、原則すべてのエラーをSlackに流しています。
しかし、再現性がなく対処が難しいエラーに関しては一時的に除外して、Slackの通知を見て新しいエラーを発見しやすいようにしています。この除外したエラーをIssue化してIgnoreカラムで管理しています。

それぞれの Issue のステータスは次のように遷移します。

ポイントは次のようなところです。

いつでもだれでも改善の Issue を切れる
- 「やる、やらない」は気にしなくていい
プロダクトオーナーが改善 Issue の管理・切り分けを行う
- 誰かしらが切り分けをやらないと New Issues が溜まり続ける
  カイゼンをプロダクトとして捉えてプロダクトオーナーを置く
- 基本プロダクトオーナーが「やる、やらない」や優先順位を決めるが、迷ったらチームに相談

カイゼンを見える化！

GitHubプロジェクトも作ったし、フローも考えた。完璧！！
ではありません。カイゼンも一つのプロジェクトとして扱い、見える化まではセットでやります。

チーム開発実践入門に次のような記述があります。

筆者の経験上、「うまくいかない、終わらない」プロジェクトには以下のような共通する特徴があると思えます。
・プロジェクトの見える化ができていない
・タスクの整理、進捗の管理、情報の共有などができていない
出典元：チーム開発実践入門 - https://gihyo.jp/book/2014/978-4-7741-6428-1

そこで見える化をするために、Google Apps Script（GAS）, SpreadSheets と DataStudio を使っています。