うぉ、またシステム障害・・・エンジニアと組織の向き合い方
こんにちは！ユートニック テックリード 衛藤です！
もう夏ですね！
最近はいろいろ忙しく全く更新できておりませんでした・・・
さて、今回は開発のディープな部分にフォーカスした記事です。
それは、システム開発とは切っても切れない関係である「障害」を不運にも引き起こしてしまったエンジニアと組織についてです。
エンジニアなら大小問わず障害を起こしたことがある人も多いかと思います。かくいう僕も、これまでに数え切れないほどの障害を起こし、なんとか乗り越えてきました。そんな自分の経験も踏まえ、障害を起こしてしまったエンジニアの心理状態、組織と当事者はどうやって乗り越えるべきなのか、色々と考えていた頭の中を整理しつつ書いていきたいと思います。
いま、ちょうど何かに挑戦し失敗して落ち込んでいるエンジニアも、エンジニアでない方も、たまたまnoteを見た方も、何かの参考や勇気づけになれば嬉しいです！
少しでも興味がありましたらカジュアル面談もやっておりますので、お気軽にご連絡ください！
障害を起こしてしまったエンジニアの心理状態
障害リスクのないシステムはこの世に存在しません。普段どんなに気をつけていても起こるときは起こる、それが障害です。
そして、悲しくも障害が発生してしまった場合、引き起こしてしまった当事者であるエンジニアはかなりのストレス状態に陥ってしまいます。
その時の内容にもよりますが、
損害のインパクトから来るプレッシャー
悔しさ
信頼が失われることへの怖さ
恥ずかしさ
などさまざまなことが心を圧迫します。
さらにはこういった心理状態にある場合、ネガティブな認知バイアスによりもっと気分が沈みがちになります。
例えば 気分一致効果 と言われる認知バイアス。
これは、気分が上がっているときは物事の良い面だけが見え、気分が下がっているときは逆に物事の悪い面だけが目立って見えてしまうというものです。
特に障害直後の心理状態はこんな感じではないでしょうか。気分が下がりすぎて普段は気にしない部分までマイナスに見えてしまい、さらに落ち込んでしまいます。正気に立ち戻るには、視点を一段階上げてバイアスを理解することも大事です。
以下は、気分が下がっている場合に陥りやすい負の感情の連鎖の例です。
ストレスによる症状「考え方」の例
・どうせうまくいかないと考える
・同じ事ばかり考える
・悪い結果ばかり考える
・呆然として何も考えられない
・大事なことを考えるのを避ける
・集中できない
・自分は役に立たないと考える
・自分を責める
良い文化だけではエンジニアは救われない
たとえ障害が人的ミスによるものだったとしても「チーム全体の責任である」「仕組みが悪い」など、人ではなく事象にフォーカスする文化を醸成している組織も多いと思います。これはこれで確かに大事で、僕も大事にしていることの1つです。
でも実際には、そういった文化であったとしても当事者のストレス状態がなくなるわけではありません。
それは、障害となるトリガーは、ほとんどがその人（当事者）による何らかのアクションであることにほかならないからです。そのため、責任を感じてしまうのです。
「責任を感じてしまう」ことについては、当事者意識を持っているからこその感情で、すごく大事なことだと思っています。
僕は運良く周りにも支えられてこれまでエンジニアを続けられていますが、中にはこのストレスを乗り越えられずに会社を辞めていく人、限界を迎えて心を病んでしまう人、エンジニアの道を諦めてしまう人などもいます。
障害が発生した場合、当事者と組織はどう動くべきなのか
以前、ポストモーテムについて記事を書きました。前述の通りこれはとても大事で、実践する組織とプロダクトはさらに成長します。
しかし、今回の話の主役はあくまで障害を起こした当事者です。
障害や失敗が発生した場合、頭の中ではさまざまな考えが駆け巡ります。（人それぞれ感じ方は違うとは思いますが・・・）
血の気が引く感じがする
障害だと信じたくない
かすかな望みを賭けて、障害ではない事実を探そうとする
しかし大抵の場合、それは障害である
障害発生時、当事者はどうするべきなのか。
すごく簡単です。とりあえず直ちにチーム、周りの関係者に報告・共有することです。
しかしながら、おそらく世界共通であろうこの常識、言うは易しで実はなかなか難しく、報告が遅れてしまったり、時にはされないことすらもあるのが現実です。
なぜなのか、原因はさまざまあると思いますが、そこには人間の心の根底にある心理効果や、組織・人のあり方が関係してきます。
MUM効果（マム効果）
これは人間なら誰でもあり得ることで、悪い情報を伝えることを避けようとする心理効果が働きます。MUM効果と言われるそうで、自分を守ろうとするため、報告をためらってしまうようになります。
不思議なもので、悪い犯罪を犯したわけでも、わざとやったわけでもないのに、なぜかためらってしまいますよね。経験ある人も多いのではないでしょうか。
また、この心理的効果の前提に加えて後述の組織文化的な側面がある場合、さらに報告しづらさが増してきます。
まずはこの第一段階のハードルを低くするために、ネガティブな内容を報告してくれた人を称えたり、最初に感謝を述べるという文化を根付かせている会社もあるようで、確かに一定の効果はありはありそうです。
自分で勝手に判断をしている
これは、どちらかというと人それぞれというのが正直なところですが、障害の程度によらず自分自信で勝手に判断してしまい、報告自体をしないケースです。
特にまだ歴が浅いエンジニアの場合、勝手な判断が命取りになることもありますので、迷ったらチャットで一言共有だけでもしておきましょう。誰かが反応して助け舟を出してくれるはずです。
※ それでももし何も反応がなければ、組織文化として黄色信号かもしれません。
後になって隠れていた問題が浮き彫りになった場合「なんで早く言わなかったの！」と言われてしまいますよ。
障害を隠そうとする
この話は有名な書籍である「HARD THINGS」から拝借したものですが、会社や組織そのものに良くない文化が根付いている場合に発生します。
知らず知らずのうちにチーム内に報告しづらい雰囲気が蔓延っている可能性があります。この場合はリーダー・管理者クラスがまず現状を正しく認識し、動く必要があると思います。
良い企業文化は、昔のRIPルーティングプロトコルに似ているー悪いニュースは速く伝わり、良いニュースは遅く伝わるー
失敗した会社を調べてみると、多くの社員が、致命的問題が会社を死に至らしめるずっと前から、その問題を知っていたと判明する。命取りになる問題に気づいていたのに、なぜ何も言わなかったのか。多くの場合、会社の文化が悪いニュースを広めることを妨げ、手遅れになるまで情報が眠っているからだ。
課題が全体に広く共有されることで、いろいろな視点から問題が分析され、より良い解決策に結びつくことも多いです。解決どころか、思ってもみなかったプラスのメリットが創出されたりすることもあります。
品質を改善するためのアプローチ
ここまでは障害が発生した場合の話でしたが、プロダクトチームは、そもそもリリースされるまでの間、できる限り品質活動を強化する取り組みをすることで、緊急トラブルの可能性を減らすこともできます。
Whole-Teamでの品質アプローチ
ユートニックは現在QAチームが不在の組織です。現時点では小さな組織でもあるため、エンジニアやデザイナーが兼任して機能テストや探索的テスト(ET)を行っています。
探索的テストは僕がユートニックに入った直後に提案したテスト手法ですが、人も時間も限られているスタートアップでは特に有効に機能します。
機能テスト仕様書を書いてレビューする時間を減らし、その分をテストに充てられる
複雑なステップを頭で考えながらテストするので、実際のユーザーの使用に近い状態で検証できる
エンジニア・デザイナー・プランナー様々な視点でテストができる
不定期ではありますが、企画職も交えて全員で新機能について触る会も開催されています。この会は非常に画期的で、さまざまな職種の視点でテストが行われるので、バグ探しよりもUX改善にも役立っています。
このように、QAチームが不在だったとしても、品質において成功するためには、組織全体で品質に対して向き合うことが重要だと考えられます。
Whole-Teamでの品質アプローチに関しては以下のスライドに詳しく書かれています。
Whole-Teamでの取り組みの重要性
チームによる探索的テストは、バグを見つけるだけでなく、体験を通して仕様の改善点を見つけることで大きな手戻りをなくせる可能性がある
また、同スライドに記載されている以下についてもすごく大事な考え方だなと思っています。
Whole-Teamでの品質アプローチ
お客様にとっては仕様かバグかは関係ない
お客様にとっては「使いやすいか」「使いづらいか」「使えない」という体験だけが残る
大小どんな組織でも参考になると思いますので、是非目を通してみてください。ちなみにユートニックで実践している探索的テストは、このスライドを書かれている御本人から直々に教えてもらったものです。
探索的テストはある程度の経験も必要になるため、難易度の高いテスト手法ではあるものの、繰り返していけばかなり効率よくテストを行うことが出来ます。
シフトレフトを意識する
シフトレフトとは、開発工程の早い段階でセキュリティ対策やテストを行うことです。基本的に開発工程が後になればなるほど手戻りによる改修コストが増えてしまうため、なるべく早い工程で潰しておくという考え方です。
特に、リリース前とリリース後の改修コストの違いはかなり大きく、DBの変更なども絡んでくると天と地ほど変わってきます。
開発の最終工程とはいえ、リリース直前に正すべき問題が見つかったのであれば超ラッキーです。だって、ユーザーに全く影響がない状態で修正できるのですから。エンジニア的には「リリース前にまじかよ・・・」という感情も抱くかもしれません、しかし、リリース後に発覚したと想像してみてください。「リリース前に分かってれば・・・」と絶対思うはずです。
このように、開発段階から品質について意識することも、失敗の確率を減らす良い方法だと思います。
最後に
とりあえず、失敗に負けるな
いろんな方向に話が広がりましたが、障害が起こってしまうのは仕方がありません。とりあえず緊急対応で正常な状態に戻ったら、まずは凹むだけ凹むと良いと思います。落ち込んで悔しい思いをしているなら、その感情を持つことは正しいです。
ただし、それを成長に繋げられるかは本人次第です。
大事なのは失敗を学びに変え、同じ過ちを繰り返さないことだと思っています。
たくさんチャレンジして失敗し、乗り越えることでさらに強いエンジニアになると思いますし、組織としても強くなると思っています。
僕自身は凡庸なエンジニアなので、今後も失敗すると思います。
だからこそ、失敗は逃げずに向き合いたいと思いました。
「失敗に明るく、緊急対応は百戦錬磨、同じ過ちは繰り返さない」というエンジニア像を目指したいと改めて感じる今日この頃です。
以上、最近大きなミスを連発してしまい、いろいろと考える良い機会にもなったので、それを書き起こした記事でした・・・
共感できる方、一緒に働きませんか！？
ユートニックでは現在、一緒にエンタメ業界を盛り上げて行くエンジニア仲間を絶賛募集中です！
会社も急成長してきており、嬉しいことに時間も人も足りません！
みなさんのお力が必要です💪
XのDMでも大歓迎ですので気になれば一度ご連絡ください！
Xはnoteの僕のプロフィールに設定してあります。（カジュアル面談も歓迎です）
普段の業務に物足りなさを感じている方や、スタートアップに興味のあるエンジニアさん、ぜひご連絡ください！
技術スタックはコチラ↓
フロントエンド
Typescript
Capacitor
Next.js
Netlify
バックエンド
Typescript
GraphQL
CloudRun、Functions、Firestore
上記のほかGoogle Cloud全般
ではまた！
この記事が気に入ったらサポートをしてみませんか？