緊急対応でも通常タスクを止めないチームを設計する

フロントエンドエンジニアの茶木です。

先日、あるプロジェクトの中で緊急対応が発生し、緊急対応はうまくいったのですが、通常タスクが停滞してしまったということがありました。

私たち Gaji-Labo は、プロダクトチーム支援単なる開発リソースの提供ではなく、事業の成功を目指す「チームの一員」としてクライアントのプロダクトチームを支援しており、この経験から得られた反省をもとに「緊急対応が発生したときに、チームとしてどう動くべきか」について話し合いました。

今回は、その「緊急対応発生時の基本フロー」についてご紹介します。

背景

先日、あるプロジェクトで緊急対応が必要な事態が発生しました。
責任感の強いメンバーが一斉に対応にあたり、事なきを得ましたが、その裏で通常タスクが停滞する事態を招いてしまいました。

緊急対応にも適切な対応人数がある

この経験から、緊急対応であっても、状況に応じた適切な人数で対応し、他のメンバーは通常タスクを進めるべきだったという反省を得ました。

この反省を踏まえ、緊急タスク発生時の動き方を以下のように整理しました。

緊急タスク発生から対応までの3ステップ

ステップ1：アラートを迅速に共有する

問題に気がついたメンバーは、速度優先で関係者に状況を共有します。この段階では、関連するシステムのURLやエラーメッセージのスクリーンショットなど、最低限の情報だけでも問題ありません。

ステップ2：初動担当者が難易度を把握する

次に、初動の担当者を一人立てます。この担当者の役割は、問題の難易度や対応にかかりそうな規模を大まかに把握することです。ここでのポイントは以下の2点です。

• 誰が初動担当者なのかを明確に示すこと
• 初動担当者は時間をかけずに当たりをつけること

ステップ3：最適なメンバーで対応する

初動担当者の報告から、実対応にあたるメンバーを決定します。
このまま初動担当者が実対応にあたることもありえますが、把握した難易度や規模に応じた適切な人数を割り振ることが重要です。

フローを支える3つのキーポイント

このフローを効果的に運用するためのキーポイントがあります。

作業速度は投入した人数に比例しない

適切に手分けができたタスクでなければ、複数人で対応しても速度はあまり上がりません。これは通常タスクはもちろん緊急対応でも同様なのですが、緊急対応時は責任感も相まって複数人が対応に向かい、結果として複数人が同じ動きをしてしまいがちです。

初動担当者を決める

適任と思われる1名が初動調査を行います。初動調査は時間をかけずに行います。難易度や規模を把握し、適切な対応人数と実作業のメンバーを判断したら、実作業のメンバーにバトンタッチします。

実際は、初動担当者=実作業となるケースが多いと考えており、バトンタッチ不要のため最速の対応となるでしょう。そうなるようなメンバーが適任で、初動担当者に選ぶと良さそうです。

緊急対応に参加しないメンバーは通常業務を進める

対応に直接あたらないメンバーは、自分の通常タスクを進めることが、結果的にチーム全体への協力となります。全員がそれぞれの役割を全うすることが、チームの生産性を維持する鍵です。

悩んだルール

この基本フローを考えるにあたって、悩んだルールがありました。
ここでは特に、初動担当者の決定方法について述べますが、他の運用についても、メンバー構成や案件によっては別のルールが適しているかもしれませんし、変化に合わせてアップデートが必要なものです。

初動担当者をどう決定するか？

「お見合い状態」は避けたいため、初動担当者の指名するメンバーをひとり決めておく、といったことも考えましたが、自分を含めたメンバーの中での初動担当の適任者は各人が判断できる（メンバーの知見や担当範囲やアサイン状況を把握している）と考えて、あえて厳格なルールは設けませんでした。

今の私たちであれば、各メンバーがオーナーシップを発揮し、立候補や指名で柔軟に決められると考えて、このようになっています。

まとめ

緊急タスクは時として起きてしまうものですが、事前にチームとしての動き方を決めておくだけで、混乱を最小限に抑え、チーム全体の生産性低下を防ぐことができます。

Gaji-Labo では、チームに深くコミットするからこそ、プロジェクトで発生する「予期せぬ事態」にも当事者として向き合います。

Gaji-Labo フロントエンドエンジニア向けご案内資料