組織に対するカオスエンジニアリングの実践 - 変化に対応する組織をつくるための課題を探る「カオスWeek」という取り組み

組織に対するカオスエンジニアリング

Agile Journeyをご覧いただき、ありがとうございます。本メディアの運営を担うユーザベースBtoB SaaS事業のCTOを務める林です。本メディアでは、これまで多くの方がアジャイルに関する経験、知見を披露してきてくれましたが、本稿では私たち自身のアジャイルの実践手段のひとつであり、「組織の耐障害性」を高める手段である「カオスWeek」という取り組みを取り込みについてお伝えしたいと思います。

カオスエンジニアリングを組織に適用した「カオスWeek」とはなにか
- カオスWeekの目的と、キーパーソンを隔離する意味
カオスWeekの実践方法
カオスWeekのルールや例外
- 例外的なコミュニケーションの許可を判断する人を設ける
- コミュニケーションが許される状況をあらかじめ設定しておく
カオスWeekにて得られるもの
変化を抱擁できる組織になるために
合わせて読みたい関連記事

カオスエンジニアリングを組織に適用した「カオスWeek」とはなにか

カオスWeekと聞いてピンと来なかったとしても、カオスエンジニアリングという言葉を耳にしたことがある方は多いのではないでしょうか。カオスエンジニアリングは、Netflixが2010年代に提唱した、システムに意図的に障害を起こし可用性を検証し、向上させるための手法です。この手法は「Netflix」というサービスそれ自体の認知が拡大していくとともに、国内のソフトウェアエンジニアリング界隈でも少しずつ浸透しつつあります。

また、カオスエンジニアリングの文脈には、Googleが実施した「Chaos Engineering for People Systems」というアプローチも存在します。こちらは、システムではなく組織にいる「人」に対するカオスエンジニアリングで、あるメンバーを一定期間不在にさせる、などの負荷（カオス）を組織や人に注入し、それでも業務は滞りなく進行するか、といった「組織の可用性」を検証するものです。

本稿ではこれらカオスエンジニアリングに関する詳細な説明や言及は省きますが、興味のある方はぜひ調べてみてください。すでに実践している企業の事例など、興味深い知見が得られると思います。

さて、私たちの組織では、これらカオスエンジニアリングに着想を得て、カオスWeekという取り組みを実施しています。カオスエンジニアリングはカオスを注入する対象がシステムになりますが、私たちが行ってるカオスWeekというのはカオスを注入する対象はシステムではなく、チームもしくは組織になります（この観点では、Googleの「Chaos Engineering for People Systems」に、より大きな影響を受けているといっていいでしょう）。

カオスWeekの目的と、キーパーソンを隔離する意味

私たちの組織が取り組むカオスWeekのやり方はシンプルです。チームのキーパーソン（CTOの私も含みます）を1週間、意図的にチームのコミュニケーションから遮断（カオスを注入）します。そして、キーパーソンがいなくなった状態で、チームがどのように振る舞えるのかを確認し、なにか問題が生じれば、課題点を洗い出します。カオスWeekとは、いわば、チームの耐障害性を向上させるための取り組みです。ですから、「カオスWeek中に滞りなく上手く仕事を進めること」が目的ではありません。最も重要なのは、「カオスWeek中にチームの課題をあぶり出すこと」なのです。

さて、なぜキーパーソンを1週間も隔離するという、一見すると無謀なことを実施するのかというと、「人や組織は変化する」という前提があるからです。たとえば

急な病気や、家庭の事情で休みを取らねばならなくなった
緊急性の高い他のタスクを担わねばならなくなった
今のタスクとは違う新しい事に挑戦してみたくなった
重要な役割を担っていたメンバーが退職する事になった

こうした変化は誰にでも、どんな組織にも頻繁に起こりえることですが、変化があったとしても、ビジネスは継続・発展させねばなりません。つまり、仕事や開発を進めていく上での不確実性は「人」に起因するものが少なくない、と言えるのです。であれば、不確実性をできるだけ小さくすることで、人や組織は不安を少なく、勇気を持って物事を進めやすくなると考えるのです。

上述の「変化」に共通するのは、想定外のタイミングで自分を含めた特定の誰かがいなくなる（コミュニケーションが取れなくなる）という点です。カオスWeekでキーパーソンを隔離するのは、この「コミュニケーションがとれない」状態を再現するためです。チームや組織がこうした状態に対応できるか、対応するためにはどのような課題があるかを検証し、改善点を探り、やがて変化に対応できる柔軟性を持った、レジリエントな組織をつくっていくための取り組みなのです。

また、逆説的にこのような状況に対応出来る組織とは、そこで働く人が休みを取りやすい、産休や育休などの長期の休みも安心して取りやすい組織ともいえます。

カオスWeekの実践方法

ここからは、カオスWeekの進め方を具体的にお伝えしていきます。まず、カオスWeekの大まかなプロセスは以下の通りです。

チーム内でカオスWeekの実施タイミングを決める
カオスWeek中に抜けるキーパーソン（コミュニケーションが遮断される人）を決める
実施時期が来たら、1週間の間は抜けた人とチームメンバー間のコミュニケーションを遮断する
カオスWeek終了後にふりかえりを行い、チーム内で課題点の認識を揃える。その際に改善アクションも考える

以降、各プロセスのポイントを解説していきます。

カオスWeekの実施タイミングを開発計画に織り込む

まずはカオスWeekを実施するタイミングを決めます。このとき重要なのは「開発の計画時にカオスWeekの実施タイミングを決める」ことです。

すでに開発が進んでいて、ステークホルダーに対してなにかしらの約束（期限など）をした後では、カオスWeekをうまく実践するのが難しくなります。計画に対して、よほど前倒しで進んでいる状況でなければ、カオスWeekを実施するのは大きな勇気が必要になってしまいます。また、仮にカオスWeekを実施して、当初の開発計画よりも遅れてしまったら「カオスWeekをやらなければよかった」という思考になってしまいますし、メンバーは「カオスWeek中だけど遅らせられない。無理をしてでも進めよう」という心理状態になってしまいます。こうなっては本末転倒で、そもそもカオスWeekであぶり出したい課題が表面化しない or 蓋をしてしまう状況になってしまいます。

こうならないためにもしっかりと最初の段階でカオスWeekの実施タイミングを決め、カオスWeel中にどの程度の進捗が得られるかを考慮し、計画に織り込むことが重要です。

私たちの組織では、四半期が始まるタイミングに大まかな計画（OKRやバーンダウンチャートなど）を立てることが多く、このタイミングでカオスWeekの実施タイミングも決定します。ときには1ヶ月単位で計画を立てることもありますが、この場合も同じく、月間計画の中にカオスWeekの実施タイミングを織り込みます。

「抜ける人」は影響力の大きさで決める

次にカオスWeek中にチームを抜ける人を決めます。抜ける人を決めてから、実施タイミングを決めても問題ありません。

キーパーソンを決める上で重要なのは「その人が抜けることで課題をあぶり出せるか」です。仮にチームに入って間もない人が抜けたとしても、特に問題は起きず、課題を探れない可能性が高いです。しかしそれではカオスWeekの目的を果たせません。では人選をどうするかですが、下記に1つでも当てはまるような人を選ぶといいでしょう。

チームやプロジェクトの在籍期間が長い
プロジェクト内で重要な技術に関してスキルが高い
リーダーシップがある
チーム外の人とのコミュニケーション時にハブになっている

これらに当てはまる人は、さまざまなシチュエーションで意識的にも無意識的にも頼られることが多いです。だからこそあえてそのような人を隔離し、「頼りになる人がいない状態」でチームにどのような課題が生じるかを認識する機会にします。

コミュニケーションを遮断し対象メンバーを隔離する。あえて準備しない

カオスWeek実施期間が来たら、隔離対象のメンバーとチームメンバーのコミュニケーションを遮断します。遮断方法に関して思いつくことはいくつもあるかと思うので、それぞれの状況に適した形で遮断すれば問題ないです。

常に出社している状況であればチームメンバーと距離を離した場所に座ってもらう
出社 / リモートの選択が可能な状況・環境であれば、隔離メンバーだけリモートで作業してもらう
常時リモートの状況であれば、Slack、メールなどには反応しない

など、結果的にコミュニケーションを遮断できればOKです。

そして、カオスWeek期間中は、可能なかぎり通常時と同じように行動します。カオスWeekのためにスケジュールを強引に早めたり、何事も起きないような開発計画を立てたりしては、本末転倒になってしまいます。あくまでいつも通りに開発を進めてみて、どんな課題が発見されるのかを確認することが重要です。

隔離されたメンバーは独立して進められるタスクにあたるのがおすすめ

隔離されたメンバーがその期間になにをするかは、チームの状況によってさまざまです。しかし、他のチームメンバーと同じ作業をしないことが重要です。とくに、チームがなにか特定の機能を開発している場合、カオスWeek中はその機能開発に直接的に関わらないようにするのが望ましいです。そうでなければ、たとえばPull Requestが出せない / 承認できない、レビューができない、といった不具合が起きてしまいます。ですから、隔離メンバーは一時的に通常の開発フローから抜けてみて、日頃どうしても後回しにしてしまっているタスクを終わらせたり、この先必要になりそうな技術の調査を行うなど、他のチームメンバーとは独立した作業を行うと、カオスWeekの利点を活かせるでしょう。

ユーザベースのProduct Teamで隔離メンバーがやっていること

私たちのチームでは隔離されたメンバーがデプロイメントパイプラインの改善や、パフォーマンスチューニングを行ったり、不安定なE2Eテストを修正したりします。また、トランクベース開発を採り入れており、常時ペアプロを行っていることもあり、Pull Requestが存在しないので、ちょっとした機能改善を単独で黙々とやるといったこともしています。また、ユーザベースではロングバケーション制度といって、5営業日連続で休めるという制度があるため、この休みに合わせてカオスWeekを設定するというケースも多いです。休み中でもSlackのメンションやエラー通知などを気にしてしまいがちですが、カオスWeek中はそれらに対応してはなりません。ですから、仕事から遮断され、良い意味で休日に集中出来るといったメリットがあります。

また、「レンタル移籍」という取り組みを実施する場合もあります。これは、自分の所属外のチームに1週間限定で移籍して、移籍した先で技術・ノウハウを伝えたり吸収したりする制度です。この制度はカオスWeek期間外でも実施されますが、通常業務から隔離されるタイミングであれば、チーム外でのナレッジの共有、吸収にフォーカスできることから、カオスWeekと並行することも多いです。

ふりかえりでは、「課題の発見」を歓迎する

繰り返しになりますが、カオスWeekの目的はチームの耐障害性を“向上”させることです。そのためには、発見された課題を「ふりかえり」で、チームで共有し、改善に繋げることを忘れてはなりません。とくに最初の2〜3回くらいまではしっかりと「カオスWeek用のふりかえり」の時間を確保するといいでしょう。カオスWeekの実施回数が増えてきて文化としても根付いてきたらカオスWeek明けの朝会で短くふりかえる程度でもいいでしょう。

そして、このカオスWeekでのふりかえりで重要なのは「課題が見つかったら喜ぶ」というマインドを持つことだと思っています。逆に「課題が出てしまうのは良くない」という思考でいると、カオスWeek中に努めて課題が出ないように振る舞ってしまい、結果的にせっかくの取り組みが形骸化してしまうリスクがあります。そうならないためにも、課題が発見されることを歓迎し、改善の端緒が得られたことをチームで喜び、より良いチームになるためのアクションを考える、といったポジティブな思考でふりかえりを実施しましょう。

【Tips】カオスWeekを取り入れるなら、小さく始めてみる

ここまでご覧になって、「自分の組織でもカオスWeekを試してみたいけど、1週間も時間を確保できない」とお感じになった方もいるかもしれません。もしも時間的な制約があるのならば、最初は1週間ではなく、1日から取り組んでみるのもいいでしょう。カオスWeekならぬカオスDayといったところでしょうか。たとえ1日だけでも、「あのドキュメントの閲覧権限が付与されていなかった」など、チームにおける課題が発見される可能性は十分にあります。

こうして得られた課題をチームでふりかえり、カイゼンのサイクルを回してみてください。これに慣れたら、次は2日で実施する、といったように、少しづつ期間を長くしていくといいでしょう。短い期間であれば当初の計画に与える影響も少なくなるはずなので、取り組みやすいはずです。

カオスWeekのルールや例外

カオスWeekの実施にあたっては、いくつかのルール、そして例外を設けることでより実践しやすくなります。そのルールと例外の例をいくつか紹介します。下記はチームの状況に応じて必要 / 不要が出てくるので、自分たちの課題と照らし合わせながら適宜調整するといいでしょう。

例外的なコミュニケーションの許可を判断する人を設ける

カオスWeekは開発や業務を停滞させるのが目的ではありません。ですから、カオスWeek中にどうしても隔離対象の人とコミュニケーションをしなければならないという場合は、そのコミュニケーションを例外として認めるかどうかを判断する人を設定しておくと便利です。こうしたコミッショナー的な役割を設置することで、例外的なコミュニケーションの適切な閾値を設定しやすくなります。

コミュニケーションが許される状況をあらかじめ設定しておく

この設定は基本的にはないほうが望ましいのですが、どうしてもコミュニケーションが必要であり、かつ発生するのが事前にわかっている場合は、設定しておきます。たとえば、私はCTOとして採用の最終面接を担う立場にいるのですが、その最終面接を「カオスWeekだから」という理由で他の人に変えるのは、候補者の方に対してあまりに失礼です。まだ、可能なかぎり候補者の方の都合に合わせて面接を実施したいと考えているため、最終面接に関する連絡や共有は、私がカオスWeek中だとしても連絡してよい、としています。このように自分たちの組織内でコントロールできず、かつ、発生が見込まれる事象に関しては連絡してOKと周知しておくことで、無駄なコミュニケーション増加を避けられます。

カオスWeekにて得られるもの

こうして実施されたカオスWeekでは、実にさまざまな課題が発見されます。課題としては大まかに下記のようなものが発見される傾向があります。

ドメイン知識や業務知識の属人性
純粋な技術力に対する属人性
運用に対する属人性
コミュニケーションに関する属人性

そもそもキープレーヤー、つまり、上記のような課題と関係性の深いメンバーを隔離対象にすることが多いので、当然の結果ともいえます。しかし、誰かが1週間抜けることで、想定していなかったような部分で「特定の人しか知らなかった要素」が出てきます。こうした課題はチーム内で振り返るだけでなく、組織全体にも共有され、改善の端緒として活用されることもあります。

また、これら課題以外に、副次的に得られるものとして「休みやすくなる」ことが挙げられます。家庭の事情などで突発的に休みが必要だけれど、自分の役割を考えると休みにくい。あるいは、休んでみたけど後ろめたい、Slackが気になって休んだ気がしない、といった気持ちになることもあるでしょう。責任感があるからこそ、こうした気持ちになりますが、、やはり休みのときは仕事を離れ、リフレッシュや家族に向き合うなどするのが本来的です。カオスWeekを実践し、課題のあぶり出しと改善のサイクルを回し、いい意味で「自分がいなくても仕事は滞らない」と検証されれば、気兼ねなく、後ろめたさもなく健全に休めるようになるはずです。

変化を抱擁できる組織になるために

かつて、システム開発には「システムは壊れてはいけないもの」「（物理的な原因も含めて）障害が発生しないように工夫する」という考えが基本にありました。しかし、カオスエンジニアリングの文脈では「システムは壊れるもの」であり「障害は発生するもの」という前提で開発や運用を捉えています。

では、チームや組織はどうでしょうか。障害など起こりえない、盤石の存在でしょうか。もちろん、違います。繰り返しになりますが、組織やチームを構成する人は変化するからです。体調を崩す、誰かの看病をする、産休や育休をとる、そして異動や転職をするといった変化は、誰にでも訪れる可能性があります。そして同時に、これら変化に起因し、組織内部に「特定の人とコミュニケーションがとれなくなる」という突発的な変化が発生することは、どんな組織にも可能性として常に存在しています。だからこそ私は、組織に必要なのは「変化を防ぐ」ことではなく、「変化が起こることは当然だ」と認識し、変化を受け入れ抱擁し、ビジネスを継続・発展させていくことだと考えています。そして、変化に対応し、変化を抱擁できる、耐障害性の高い組織になるための1つの施策として、カオスWeekが意味を持つと考えているのです。

私たちの取り組みが、皆さんのチームや組織が、変化を抱擁できるようになる助けになれば、これ以上ない喜びです。

最後に、カオスWeekはエンジニア組織かどうかは関係なく実施可能です。私はユーザベースのグループ会社であるUB Datatechという会社のCEOも兼務しており、この会社にはエンジニアが在籍していませんが、カオスWeekを導入しています。非エンジニアだけで構成された組織でも、やってみるとさまざまな興味深い課題が発見され、効果を実感しているところです。

1日だけの「カオスDay」から始めてみるだけでも、レジリエントな組織づくりに必要なヒントが見つかるでしょう。ぜひ、気軽に取り組んでみてください。