テストと品質管理は「保険」と考えるべきだ。つまり、後で何か問題が発生した時に被害を軽減できるよう、前もって保険をかけておく行為だと言える。何も起こらなかった場合、保険が不要だったと感じても、それは問題ない。無保険のリスクは計り知れない。

　今回の事故を経て、今考慮すべき教訓を紹介する。リスクとその影響について考えることが、リスクを軽減するために、経営陣が自ら考え、行動するために役に立つかもしれない。

教訓1．影響度分析をする

　起こり得る最悪の結果を想定し、そこから逆算してリスクを測定、評価する。極端なシナリオを用いたテスト手法「ソープオペラテスト」や、予期しない劇的な状況を分析する「ソープオペラ分析」は、部門横断的なワークショップとして数時間で実施できる。

教訓2．信頼性とレジリエンスのバランスを見直す

　信頼性は、継続的な稼働時間、高可用性、不具合がないことを重視する。レジリエンス（回復力）は、障害は避けられないものと考え、被害を最小限に抑えるために、迅速な問題発見、サービス復旧、バックアップ、切り替え、冗長性に重点を置く。

　CrowdStrikeは「move fast and break things」（素早く動き、破壊せよ）という、開発と運用に関するマーク・ザッカーバーグ氏の言葉を重視し過ぎていたように見える。問題が起きれば、更新をロールバックすればよいと考えていたようだ。Micorosftは、今回被害を受けたWindows搭載デバイスは、全体の1％未満だったと推測している。CrowdStrikeは、Windowsが他のシステムと、どれほど異なる特別なものかを想定していなかった。この機会に、本番環境と人手による分析の両方を見直す必要があると言える。

教訓3．利害関係のない人にテストを実施してもらう

　テスターは不要な存在や余計なコストのように扱われがちな一方で、企業はテスターがいれば発見できたはずの不具合を見落としている。テスターの採用が難しいのであれば、開発者がお互いの仕事を相互チェックしたり、互いを知らない人の気持ちになって仕事を相互テストする「クロスチームテスト」を実施したりするとよい。

教訓4．テスト戦略を策定する

　バグ追跡ツールで捕捉できず、本番環境に展開してしまった直近の不具合を幾つか振り返ってほしい。そこにはコーディング要件の誤りに起因しているものがあるはずだ。不具合をチェックするプロセスを自動化できていなかったからではなく、誰もそれをテストしようとは思わなかったことが原因だ。想像力が不足していたのだ。

　CrowdStrikeの障害は、自社は誰がテストに関するアイデアを出しているのか、アイデアがどのようにふるいにかけられているのか、誰が採用するものを決めているのかを再考するきっかけになる。これはテスト戦略の見直しだ。一貫した明確なテスト戦略がないことに気付く企業もあるだろう。単体テスト、機能テスト、ストレステスト、E2E（エンドツーエンド）テストなど、いろいろなテストを実施していたとしても、それは一貫したテスト戦略とは言えない。今回の障害は、一貫したテスト戦略を策定するチャンスだ。

教訓5．潜在的なリスクと、テストと品質への投資を再考する

　企業がテストに投資している金額は、意識的に決めたのではなく、無意識の選択が重なることによる、わずかな出費がたくさん積み上がった結果のはずだ。このようなやり方では、きちんと手入れをしていない畑で、収穫物の品質、大きさ、風味について文句を言うようなものだ。テスト戦略を策定したら、コストではなく投資している時間と投資効果を測定し、適切かどうかを確認する。

教訓6．過ちを認める

　障害発生後、CrowdStrikeは状況を乗り越えるために努力してくれたパートナー企業に対し、感謝のしるしとして、10ドル相当のギフトカードを送ったと報じられている。このような状況に見合わない対応は、かえって混乱や不信を引き起こした。

　これは広報チームが独断的に決めた不適切な動きだった可能性はある。とはいえ企業は、深刻なシステム障害が発生した場合に外部パートナーと連携する方法を前もって検討しておくべきだ。

商用ソフトウェアに関する教訓

　商用ソフトウェアで発生する障害のリスクと被害の最小化のために、企業ができることを列挙する。

1．ステージング環境での本番前テストを再検証する

　やはり問題はリスク、リターン、労力、タイミングのバランスだ。SaaS（Software as a Service）の場合、ステージング環境でテストできないことがある。その場合は、SaaSベンダーがリスクを抑えるために実施していることと、自社でできることを再検討しよう。

2．段階的ロールアウトを検討する

　アプリケーションやOSについて、特定のシステムには段階的に展開することを検討する。障害が発生しても問題ないシステムから更新を開始し、高可用性システムやミッションクリティカルなシステムの更新は最後に実施するとよい。

3．ベンダーが指定する更新順番を無視できるかどうかを確認する

　インターネットに接続した全てのデバイスをベンダーが強制的に更新できる場合、段階的ロールアウトは役に立たない。この場合は、起こり得る事象を調査し、ミッションクリティカルなシステムはインターネットに接続させないなど、追加の対策を検討する。

4．サイバー保険の導入を検討する

　品質保証ではなく、サイバー保険を提供している企業もある。自社でソフトウェアを開発せず、運用をベンダーに任せている企業には有力な選択肢だ。

　DevOps（開発と運用の融合）と自動化は、少なくとも理論的には、一貫性がなくエラーを起こしやすい人への依存を減らし、リスクを軽減できる。だが結局のところ、自動化プログラムを書くのは人だ。そして、人が書いたプログラムにバグは付き物だ。CrowdStrikeの障害をきっかけに、セキュリティと品質について再検討しよう。