「リモートチームでインシデント管理を向上」~世界のインシデント対応~incident.io-Part14

はじめに

英国のスタートアップ企業であるPineapple Technology Ltd様が運営するincident.ioに関連したブログ　The Practical Guide to Incident Management　のポイントと解説

ポイント!!

リモートメンバーを持つチームでは、包括的なインシデント管理のためにリモートファーストの取り組みを採用することが重要です。
事前に合意したコミュニケーションチャネル(インシデントチャネルやステータスページなど)を利用して、主要な更新情報を共有し、進捗を確認します。また、特にリモート環境でチーム内で作業が重複しないように役割をきちんと割り当て、追跡することが必要です。
インシデントチャネルでの充分なコミュニケーション量を重視し、テクニカルな詳細やインシデント対応のリソース、リンクを主体的に共有することで全体の包括的な調整を図ります。また、インシデントチャネルの参加者は一定の人数に制限することで、組織全体が乱れずに通常業務を続けられるようにします。

参考：Working with distributed teams

解説

　incident.ioとしては、リモートワークが流行った現代の障害対応は「リモートファースト」で、リモート環境メンバーへの役割分担＋情報提供・コミュニケーション量を確保する事となっています。

　特に金融・官公庁で、マシン室で障害対応に当たる人と、Web会議等で遠隔で障害対応に当たる人が発生していて、どのように対応すべきか？をここ３年ほどよく議論が出ています。

　問題としては２つあり「マシン室ファーストにすべきだがリモートへの情報展開が足りない」「障害対応の会議（以下、アクション会議）に参加者多すぎ」です。

　「マシン室ファーストにすべきだがリモートへの情報展開が足りない」について、前述のようなマシン室での作業がある場合は、「リモートファースト」ではなく「マシン室ファースト」で、上手く情報を抽出・情報提供をすることで、マシン室でやらなくてよい作業やアウトソースできる作業を「リモート」でこなすモデルで考えるべきです。

　ただ、現代はマシン室の情報がうまくリモートメンバーに伝わらずうまくできてない状況でこれを解決することがうまくできていないのが現状で、より良い解決策には私も至っておらずです。

　「障害対応の会議に参加者多すぎ」について、リモートワークが少ない時代のアクション会議では現地の会議室に集まるには限界があったため、障害の大きさに合わせてまだ適切な人数に近かった気がしますが、リモートワークが増えてからは「とりあえず聞いて仕事をした気になる人」が多すぎます。

　弊害としては２点で「不要な人の参加で時間が無駄になる」「作業指示がしづらい」です。
　前者はわかりやすいですが、後者について書きますと、以前はリアルな会議室だったで「忙しそうなのか手が空いてそうか」がわかったので作業指示がしやすい状態でした。今はリモート及び画面オフだとどんな状態かがわからず、作業指示がしづらくなっています。incident.ioでもあるように、障害対応に関わる人であれば作業を明確にし、作業内容の進捗を追跡、それ以外の人は解散させて通常業務当たらせるようなタスク管理をインシデントコマンダーはしていく必要があります。

　最近明確化してきたリモートワークに関わる障害対応の問題はまだまだ問題が多く、是非皆様と意見交換しながら解決できればと考えております、是非皆様のご意見もください！