カオスエンジニアリングの発動条件

プロダクト運用時に使われているカオスエンジニアリングとは異なるが、組織やチームのカオスエンジニアリングとして考えてみた。

こんな状態のときはカオスエンジニアリングをお勧めしたい。

マネージャーやリーダーがボトルネックであり、常に稼働が高い。更にタスクを分解したり見える化したり、それを誰かに分散するだけのスキルがない。そして、チームメンバーからは嫌われているわけでもなく、メンバーも協力したいがどうやって協力していいか分からない状態が続いている。

この状態のときはカオスエンジニアリングがいいかもしれない。1、2週間程度の休みを取ってもらう。

そして、振ってくるタスクに対して、チームメンバーは都度対応していく。一時的に稼働は上がるし、多方面からクレームがくる可能性はあるが、そうすることでブラックボックスだったタスクの見える化が進む可能性がある。そして、嫌われているわけではないので、大きな文句は言わずに助け合いが生まれる可能性が高い。更に戻ってきたときにタスクが見えるので、分担がしやすくなる。みんなにとって、プラスな投資ではないだろうか。

属人化回避もうまくいかずに歯がゆい状態が続いているとき、いくつかの条件が揃えばカオスエンジニアリングという選択肢はありではないか。