先日、エグゼクティブ向けのセミナーを受講した際、こういう話がありました。
今どきのIT部門の管理者はエンジニアに向かって「完璧か？」と質問してはいけない。確認すべきは「リスクを把握して対処方法を確立しているか」である。
間違いがなくなることはないから、何か起こった時に影響を極小化することを優先せよということのようです。
先日、東京証券取引所のシステムが停止しました。そのシステムを構築したときの合言葉は「Never Stop」だったそうです。「Recover Soon」を目指すとよかったかもしれないですね。
さて、MTTR（Mean Time To Recovery:平均障害復旧時間）は障害によってシステムが利用できない時間のことを指します。障害ゼロを目指すための努力（ゼロになることはない）とMTTRを限りなくゼロに近づける努力について考えてみましょう。
品質を上げるためには様々な施策があります。時間とコストが許せば思いつくことをすべてやるということもできるでしょう。例えば、テストケース一つとっても全パターンをテストするには莫大なコストがかかります。システム障害を発生させてはいけないという前提に立つと最大限のコストと期間をかけるべきということになります。システム開発を受注するベンダーはかかったコストに営業利益をのせることになるのでうれしい話です。逆に我々のような発注側、あるいは自分たちで開発する立場に立つと効率が重要となります。
MTTRを重視すると、障害を起こさない努力に加え、発生した場合の復旧のプロセスまで意識することになります。リスクの発生頻度やインパクトの大きさ等を意識するようになります。エンジニアの目線で考えるとこちらの方がエンジニアの設計能力が伸びるような気がします。
ただし、MTTRの良くない点もあります。あるシステムを担当していた時のこと、それは外国人の開発部隊だったのですが、本番でエラーが発生し、非常にレアなケースであったために原因がわからず、まず、今後同様なことが起こった場合の対処を実装しました。で、その後原因究明を行って欲しいところだったのですが、上記の対応（発生した場合に調査用のログも取得できる）が終わっているのだからこれ以上時間をかけるのは無駄だ。他にやるべきことがある。ということで原因究明には至りませんでした。非常に合理的な考え方ではありますが、問題を先送りしているようで納得できなかったことを覚えています。
これからは変化とスピードが求められる時代。自分たちのビジネスが置かれた環境をよく理解し、バランス良く適切に判断していきたいと思います。
