【いなくなったら困る人】が突然いなくなった！に対処する「何か」が欲しかった
退職や、ネガティブ・ポジティブな意味合いの長期休暇は、これまでの社会人経験の中で幾度となく発生していました。
これらは自分の視点だと、いつ発生するか分からないですし、もちろん他メンバーから見た私も例外ではないと思います。
仮に私がいなくなっても業務は止まらないとは思いますが、私だからできている判断や行動もあるかもしれません。
ここに対して事前に引き継ぎをしようと、考え方や手法、各種権限などの資料を作成しようとしていると、時間がかかるかかる。
また作成し切っても、実感が得づらいのではないか？とも思っていました。
そこで考えついたのが「カオスチーミング」です。
カオスエンジニアリングっぽく、チームでも何かできないかな？
まずカオスエンジニアリングとは、Netflixをはじめとする先進企業が実践する手法であり、システムに意図的に障害や混乱（カオス）を起こし、その耐障害性や回復力をテストするアプローチです。
実運用環境下で「起きるかもしれない問題」を早めに炙り出して、サービスやシステムをより堅牢にする目的があります。
ここから着想を得たカオスチーミングとは、あえて混乱や障害を意図的に導入し、チームの回復力や学習力を高めることをとします。
私たちは往々にしてチーム内で「不測の事態が起きない」ことを前提に業務やプロジェクトを進めてしまいます。
しかし、現実の組織やプロジェクトには常にメンバーの離脱、突然の計画変更、チーム内外のコミュニケーションロスなどの 「チーム障害リスク」 が潜んでいます。
ハイパフォーマンスなチームを解散するのは単なる破壊行為では済まない。企業レベルのサイコパスと呼ぶべきものだ
by アラン・ケリー
この言葉を受け、じゃあ「外発的な要因でハイパフォーマンスなチームが解散してしまうことになったら？」に対しては何かしら手を打ちたいと思っていました。
これらのリスクが実際に顕在化してから慌てるのではなく、事前に発生させてみよう！というのがカオスチーミングです。
カオスチーミングの狙い
-
変化や困難への対処、意思決定力の向上
環境の変化や予定外の困難に対処し、チームが素早く柔軟に対応できるよう強化します。 - 知識のサイロ化防止
キーとなる業務知識や人脈が特定メンバーに依存しすぎている場合に、それが顕在化しやすくなり、対策を立てられます。 -
プロセスの透明性向上
チームの各種プロセス（意思決定の流れや役割分担など）を見直すことで、継続的な改善を促します。
また表出化していないコミュニケーションチャネルの洗い出しも期待できます。
他にもありそうですが、こんなところですかね。
カオスチーミングの実施ステップ
1. 仮説を立てる
可能であれば「私が1週間いなくなったら、Xプロジェクトはどうなるのか？」「急に顧客から仕様変更が入ったとき、チーム内で誰が調整できるのか？」のような、障害・混乱が実際に起きた場合の「チームとしての課題仮説」を立てます。
ただし、この仮説を立てるというのも容易なことではないと思いますので、「なんとなくHOGEが発生したらヤバそうだけど、何がヤバいかは言語化できてないので、カオスチーミングやってみてヤバかったことをリストアップしたい」くらいで実施しても良いかと思います。
2. チームに「意図的な混乱」を導入する
1. を元に、以下のような「意図的な混乱」を導入します。
2-1. メンバー離脱シミュレーション
あるメンバーを意図的に休暇扱いにし、他メンバーが代役を務めます。また、その離脱者は別のことをするか本当に休暇する必要があるので、普段できない長期計画や個人的な仮説検証などリストアップしていおくと良さそうです。
2-2. ロールシャッフル
リーダーや特定担当者を入れ替えてみる。短期の「リード交代」を実施します。
2-3. 情報共有チャネルの制限
通常使っているチャットツールやメールを一時的に制限し、別のコミュニケーション手段をテストします。
2-4. スプリントやゴールの変更
進行中のプロジェクト目標やタスクを突然変更し、新しい方針を即時共有・実行してみます。
3. ふりかえりで学びと改善策を言語化する
チーム内の反応・コミュニケーション量・成果物の遅延などを定量・定性の両面で記録し、分析します。
また分析結果を踏まえた具体的な改善策をチーム全体に共有し、改善策をチームのプロセスやルールに組み込み、次回以降のカオスチーミングも継続して実施し、チームとしての成熟度を上げることを目指します。
カオスチーミングを安全に導入する3つのこと
-
チーム課題の探索が目的であり、個人攻撃が目的ではない
「意図的な混乱」であっても、個々のメンバーが攻撃されていると感じないように配慮します。目的はチーム力向上であり、特定の人を責めるものではないことをしっかり周知します。 -
段階的に導入する
いきなり大きな混乱を起こすと業務に深刻な支障が出てしまう、また課題の要因が複雑に絡まってしまい、分析が困難になる可能性があります。まずは小規模・短期間で検証します。 -
定期的な振り返りの場の設計
「やりっぱなし」ではなく、すぐに学んだ知見をフィードバックし、チームのプロセスやルールをアップデートし続ける仕組みを用意します。
まとめ
「カオスチーミング」は、カオスエンジニアリングの発想を人間のチームに適用し、組織やプロジェクトに潜む潜在的リスクや課題を意図的に浮き彫りにして強化する手法です。
普段の業務では見過ごしがちな依存関係やコミュニケーションロスを早い段階で発見し、学習することで、いざ本当に危機が訪れたときの対応速度や柔軟性が格段に高まります。
-
「本当に起きたら困る事態」をあえて起こして学ぶ
-
チームメンバー全員が当事者意識を持ち、小さな実験を繰り返す
-
失敗からの学習を素早く組織全体に展開する
これらを定期的・継続的に行うことで、しなやかなチーム体制を築くことが可能になります（多分）。
技術の領域だけでなく、人やプロセスを含めた総合的なレジリエンス強化を目指すうえで、カオスチーミングというアプローチも選択肢の1つにしてみてはいかがでしょうか。
