「後でやる」を放置しない。情報システムチームを強くした「もやもやリスト」

この記事は Safie Engineers' Blog! Advent Calendar の7日目の記事です。

情報システムグループの松尾です。

以前、当ブログにて、情シスチームがアジャイル型の仕事の話へ変革した際の記事を書かせていただきました。

今回はその続編として、アジャイルなチーム作りをさらに進める中で生まれた、「もやもやリスト」を用いた継続的改善（カイゼン）の取り組みについてお話しします。

「隠れた負債」への気付き

スプリントを回す中で、日々の業務に埋もれがちな「小さな違和感」を放置することでも問題が発生することに気づきました。

「これは後で対応したほうがいいね」と会話には出るものの、タスク化されずに流れてしまい、忘れた頃に同じトラブルが発生して手戻りになることがありました。これはアジャイルで言うところの「透明性」が欠けている状態であり、見えない技術的負債がチームに蓄積されている状態でした。

そこで私たちは、「完璧な解決策」を最初から求めるのではなく、まずは「小さな違和感をチームで検知し、カイゼンする仕組み」を作ることにしました。方針は以下の2点です。

この仕組みを回すため、Notionにデータベースを作成しました。

ここで重要なのは、「タスク」として登録するのではなく、「もやもや」として登録することです。

「タスク登録」と言われると、「完了条件は？」「期限は？」と考えてしまい、登録の心理的ハードルが上がってしまいます。

アジャイルなチームには心理的安全性が不可欠であるため、「もやもやリスト」という名前にすることで、未完成の状態でも気軽に放り込めるようにしました。

運用も、徹底的にハードルを下げる工夫をしました。

これにより、フロー情報として流れてしまいがちなSlack上の会話を、強制的にストック情報として蓄積する仕組みを整えました。

リストに入った項目は、2週間に一度のサイクルで棚卸しを行います。ここで初めて「見守り（今は何もしない）」か「進捗中（タスク化する）」かを判断します。

チームのリソースには限りがあるため、「もやもや」は全ての項目を改善するのではなく、現時点では現状維持でも問題ないとチームで判断できたものは一旦、「現在の対応で継続する」とすることもありました。

このサイクルを回すことで、実際にどのような改善が行われたかをご紹介します。

新入社員向けのITオリエンテーションについて、毎月の振り返りを通じてプロセスを改善しました。

一度決めたルールを再確認し、発生した事象に合わせてフロー自体をアップデートし続けています。

ネットワーク障害は、どうしても特定のエキスパートに依存しがちな領域です。しかし、アジャイルなチームは「誰かがいないと回らない」状態を良しとしません。

そこで、「もやもやリスト」に上がった障害対応を振り返り、「従業員の業務を止める時間を極力短くする（MTTRの短縮）」ことにフォーカスを絞った初動対応マニュアルを作成しました。

これにより、ネットワーク専任担当者以外でも一次切り分けが可能になり、チーム全体での対応力が向上しました。

「もやもやリスト」の運用は、現在はグループリーダーである私がファシリテートすることが多いですが、長期的にはチームメンバーの誰もが課題を発見し、自律的に改善サイクルを回せる（自己組織化）」状態を目指していきたいと考えています。

今後は運用ルールのドキュメント化を進め、誰でもこのプロセスを運用できるようにしていきます。また、溜まっていく「見守り」ステータスの棚卸しも定期的なイベントとして組み込み、「もやもやリスト」を健全に保つ仕組みを作っていく予定です。

来年以降も、こうした小さな「カイゼン」を繰り返し、変化に強い情シスチームを作っていきたいと思います。