スタメンの松谷(@uuushiro)です。この記事ではアプリケーションのアラート(エラー通知)運用に関する問題を「システム思考」で構造的に捉え、どのように改善していこうとしているのか、ということを紹介します。「システム思考」についても記事内で簡単に説明を入れています。
システム思考とは？
複数の要素が相互に作用することで、ある機能を構成し、特定の結果を生み出すものをシステムと言います。一見シンプルに見える要素単体での働きも、他の要素と相互作用することで、全体のシステムとして想像以上に複雑で思わぬ結果を生み出すことがあるのがシステムの特徴です。例えば、人体も植物も市場の動きもシステムです。一つの要素だけを見ると単純な働きに見えますが、それらが相互作用することで全体としてとても複雑な働きになっています。 システム思考とは、なにか問題を認識した時に、反射的・局所的に対処をするのではなく、まずは全体を俯瞰して捉え、要素の複雑な繋がりを見極め、どのようなシステムを構成しているのかを理解することです。そのシステムに対して効果的に働きかけ、問題解決を図ろうというものがまさに今回やりたいことです。
背景と課題
弊社が提供しているサービス TUNAG では、アプリケーションでエラーが発生した際にはSlackに通知される仕組みがあります。アラート運用の理想としては、一つ一つのアラートがアラートとしての意味を為し、受け取ったエンジニアがそれに対して適切なアクションを取れることが理想です。しかし現状は、 一日あたりの通知数が多いため、通知に対する集中力が削がれ本当に重要なアラートを見逃しやすくなっています。その結果、不具合・障害対応の初動の遅れや漏れが発生してしまう可能性が高くなってしまいます。この問題を私たちは「オオカミ少年アラート」と呼んでいます。
今までも過去に何度かこの「オオカミ少年アラート」問題を解決しようとして、アラート担当を置いて一時的に改善したこともありましたが、開発プロジェクトの状況によっては一時的にアラート対応の優先順位を下げなければならない状況も発生します。ですので、特定の開発リソースを期待して、継続的にアラート状況を改善していくことは基本的には難しいと考えています。また、アラートを減らせば、アラートに集中できるようになり、結果としてアラート数を低く保つことができるのではないか？という仮説を元に、エンジニア複数人で一気にアラートに対応し、一時的にアラート数を減らしたことも何度かありました。しかし、数ヶ月経つとまた元のアラート状況に戻ってしまいました。このように同じ問題が何度も繰り返し発生してしまうことを考えると、「アラートを減らせば、アラートに集中できるようになり、結果としてアラート数を低く保つことができる」 という仮説は間違いだったということになります。アラート数が増える方向へなにか他の「見えない力」が働いているようにみえます。この見えない力は、なんらかの「構造」が生み出しているはずです。その構造を理解するために、システム思考で問題を考えてみます。
氷山の一角モデル
システム思考で問題を捉える際に、「氷山の一角モデル」をイメージするとわかりやすいです。氷山と同じく水面上に見えている問題「アラート数の増加」は全体のほんの一部であってその下に本当の問題があります。なので、アラートが減った・増えたというものは、システムが生み出した事後的な結果であり、局所的な最適化を図ったとしても本質的な問題解決にはならないのです。氷山の一角である「アラート数が増えた・減った」という出来事に一喜一憂し、出来事を抑え込む解決策に安易に飛びつかず、出来事の下に潜んでいる構造・メンタルモデルを見抜き適切な打ち手を講じていこうという取り組みが今回の記事の話になります。
どんなシステムが「アラート数の増加」を引き起しているのか？
今までの過去の出来事をよく観察し、どのようなシステムを構成しているのかを考えてみました。もちろん誰が悪いとかではなく、僕ら以外のチームを観察したとしても同様の結果に帰着する「システム」の話です。 結論から言うと、僕は以下4つの「ループ」が相互に影響を及ぼすことで一つのシステムを構成し、「アラート数の増加」という事象を引き起こしているのではないかと考えました。「ループ」とは、影響が回り回って輪のように閉じている因果関係のことを指しています。システム思考ではこのループを図式化することでシステムの構造を捉えることが多いのでここでもそれに倣います。 続いて下図の説明です。システム思考では因果関係のある要素と要素の繋がりを矢印で繋げ、その因果関係が同じ方向への変化なのか？逆方向への変化なのか？を区別します。同じ方向への変化なら「同」、逆の方向への変化なら「逆」と印をつけています。(この図の書き方については、「なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方」※2を参考にしています。)
各ループについて簡単に説明します。
割れ窓ループ(心理的)
- まさに割れ窓理論のこと
- アラートを放置すると、誰も注意を払っていないというサインになり、やがて他の通知も全て放置される
見逃しのループ(物理的)
- 全体のアラートの流量が多いと見逃す確率が大きくなる
- そして見逃すと全体のアラート数が増え、さらに見逃す確率が大きくなる
曖昧のループ
- アラート対応について十分な情報共有がされていないため、メンバーがどう動けばいいのか把握することができない
- インフラ監視・アプリケーションエラー通知、SaaSのエラー、チャット機能...etc が混ざっており、対応の責任の所在があいまい。
- 自分はどこの通知を受け取ってどのようにアクションすればいいのか分からない。
- なので新しいメンバーに教えられない。
- 人数が増えれば増えるほど、チーム内の曖昧さが大きくなっていく
学習のループ
- 自分の行動の結果のフィードバックを受け取ることで、次の行動を改善しようとする心理が働く。
- しかしアラート数が多い状況では、アラートを見逃す可能性が高く、結果として自分のリリースによるアラート通知に気が付けず、フィードバックを得ることができない。
- そうすると、通知数を出さないようにしようという心理が働きづらいし、学習も進まなく、1リリースが増加させるバグアラート数が減少しない。
このように、4つのループが相互に強め合い・弱め合い、自分のシステムを強化していく方向で永遠とループしていることが分かりました。このため、どれだけ一時的にアラート数を減らしたとしても、時間が経ち、新しいメンバーが入ってくるたびに曖昧のループが強化され、結果的に「見逃しのループ」も「割れ窓のループ」も強化され、そして「学習のループ」が弱まり・・・元の状態に戻ってしまいます。まだ仮説ではありますが、「見えない力」の正体はこのシステムのことだったとして話を進めます。
システムにどう働きかけていくか？
先程も言及したように、表面上の問題「アラート数の増加」を生み出しているシステムそのものを改善しない限り、状況は変わらず元に戻ってしまいます。システムとしてこの問題を捉えると、「アラート数の増加」を押さえるためにするべきことは、「割れ窓ループ」「見逃しのループ」「曖昧のループ」という3つのループを弱め、「学習のループ」を強めていくことになります。
まだ仮決めの段階ではありますが、具体的には以下3つのアクションを考えています。
一気にアラート数を減らす
- アラート数を減らすことで、「見逃しのループ」と「割れ窓のループ」を弱めることができる
- 今まさにチームで取り組んでいます。
責任範囲及びアクションを定め明文化する
責任境界や対応方針を明文化することで曖昧のループを弱める(断つ)
- 責任境界を明確にチームで分ける
- 担当領域に基づいて適切なチームメンバーに割り当てることで責任境界を明確に。
- 自分の担当領域の通知のみ受け取ることで、不要なノイズを最小限に抑える。
- 各責任境界内で方針を定めドキュメント化する
- アラートの受け取り方や通知設定の徹底(PC/スマホともに有効に)
- 一時対応者
- 動き方
- 重要度の判定方法
- ドキュメントを、新メンバー加入のオリエンテーション時またはチーム所属変更の際に共有する
自分自身の行動に対するフィードバックを強める
- 自分自身の行動の結果を受け取り学習のループを強めるために、アラート内容に関連性の高いメンバーにアサインする
- 責任境界外のメンバーが対応したほうが良い場合などは、別チームにアサインするなど柔軟に対応する
- 古いエラーなどで、関連が高い人を特定できない もしくは 既に退職している場合、チャンネルに責任を負うチームで対応をする。
効果について
まだ「一気にアラート数を減らす」という施策に取り組んでいる最中なので、これらの取り組みがどれほど効果があるのかは現時点ではわかっていません。もしシステムの理解が間違っていれば、これらに注力したところで結果は出ないので、その時は改めてシステムを見直して理解の修正をしたいと思います。また面白い結果がでれば改めてブログで紹介したいと思います。
まとめ
今回システム思考の題材にした「アラート数の増加」自体がそれほど複雑ではないこともありますが、図に書いたシステムやアクションリストを眺めると、当たり前な感じがしませんか？しかし、システム思考で問題を捉える前には、「アラート数の増加」という表面的な出来事から、チームのドキュメント文化や学習のフィードバックの強さが相互に影響を及ぼしているのではないか？という仮説も含めた観点は生まれませんでした。 今後のアクションについても、個人の積極性や、特定の開発リソースに頼るなどの長期的に持続しない施策ではないというところも重要なポイントだと思います。まさに小さな力で大きな成果を生み出す、システム思考ならではの可能性です。少ないリソースで戦うベンチャーだからこそ、表面的な解決策に飛びつかず、本質的な問題解決をして、二度と同じ問題を発生させないようにしていきたいと思います！
また、今回のようにシステムを図で示すことで、議論が空中戦になりませんし、全員で問題の全体像のイメージを揃えやすくなるはずです。引き続きチームの皆と話し合いながら、システムの理解を深め、あらゆる問題を正確に捉えていきたいと思います。(弊社プロダクト部の行動指針に(StarCode)に「問題を見極める」というものがあるのですが、システム思考はまさにその行動指針にぴったりな思考法ですね！)
最後に
私自身、「システム」といえばソフトウェアを想像していたのですが、システム思考を知ってからは、世の中のあらゆるものはシステムなのかもしれないという新しい視点を持てるようになりました。この視点を持っていると、身近なソフトウェアアーキテクチャもチーム構成も他部署についてもそれぞれ単体で機能が完結しているものではなく、相互作用する要素として、複雑なシステムを型作っているとイメージできそうですね。ソフトウェアに限らずあらゆるものはエンジニアリング対象なんだなあと思うとワクワクしてきませんか？
最後に、スタメンでは、エンジニア、デザイナー、プロダクトマネージャーを大募集中です。 もし弊社に興味を持っていただけましたら、こちらのWantedlyをご確認ください！
参考資料
- ※1. 世界はシステムで動く ―― いま起きていることの本質をつかむ考え方 ドネラ・H・メドウズ , Donella H.
- ※2. なぜあの人の解決策はいつもうまくいくのか?―小さな力で大きく動かす!システム思考の上手な使い方 枝廣 淳子 、 小田 理一郎
