本当に重要なことではない。通常は問題ないので、確認する必要はない。私/私たちの責任ではない。後で誰かが確認するだろう。以前に誰かが確認した。心配性な人はだんだん不安になってきました。私もこれを書いていて不安になります。どこかの猫が「ヨシ!」と言っていそうですね。効率性を求めるETTOingだけを行っていると、もちろん事故や障害を引き起こすリスクが増えますし、その対応のためにかえって効率性が下がることになりかねないです。そこでエリック・ホルナゲル氏は、現在の効率性は過去の徹底性を前提としており、現在の徹底性が将来の効率性に必要だと述べています。徹底-効率性トレードオフ原則)が必要になります。ETTOing(効率性を求めること)とTETOing(徹底性を求めること)をバランスよく行う必要があります。次のサイトに説明がありますので興味のある方はご覧ください。TETO"にも詳細な説明があります。作業手順書の作成ITシステムの運用のお仕事の例で考えてみましょう。作業手順書の作成について考えてみます。作業手順書を作らずに作業を行ったとしましょう。作業手順書を作成する時間を省くというETTOingが行われています。このときは、ヒューマンエラーによる作業の失敗や作業に伴うシステム障害の発生のリスクが常にあります。何も失敗せずに作業が完了したり、その後のシステムにも障害が起きなかったら、結果としては効率性が良かったということになります。作業に失敗したり、その後にシステムに障害が発生したら、その対応に時間と労力を費やすために、総合的には効率性が悪かったという結果になります。逆に、あらゆる作業に作業手順書を作成してから行うとしましょう。TETOingが行われています。このときは、ヒューマンエラーによる作業の失敗や作業に伴うシステム障害が発生するリスクは小さいでしょう。この場合は、業務としての効率は悪くなります。1回限りの参照系(非更新系)の作業(例えばシステムの状況を確認する作業)にも手順書を作成してから作業するのは決して効率のよい作業とは言えないでしょう。pingコマンドを実行するのに作業手順書を作ることを想像してください。作業手順書を再利用できるのであれば、長期的な視点で見ると、将来に対しては効率性がよいということになります。ここでETTOingとTETOingのバランスを考えてみた例を示してみます。更新系の作業については、ヒューマンエラーによる作業に伴うシステムへの影響が生じるリスクが高いため、作業手順書を作成するというTETOingを行います。参照系(非更新系)の作業については、ヒューマンエラーによる作業に伴うシステムへの影響が生じるリスクが低いため、作業手順書を作成しないというETTOingを行います。簡易でない作業については作業の漏れを防ぐために作業手順書を作成するというTETOingを行います。更新系・参照系を問わず定型作業については、作業手順書を作ることはTETOingではありますが、同じ手順書を再利用できるため、将来の効率性の向上になります。影響されるため、技術スキルへの高い依存はしない方がよいでしょう。深夜に障害対応をしていて徹夜明けかもしれないですし、家族が風邪を引いていて頭が心配事でいっぱいかもしれません。作業手順書を作成しても、様々な要因で障害が起きるときは起きますけどね。システム障害と根本原因分析ITシステムを運用していて、どうしても発生してしまうのがシステム障害です。システム障害が発生したら、その対応を行い、システムを正常化させようとします。一連の対応が終わったら、その振り返りとして、組織によってはポストモーテム(postmortem)を作成します。Engineering)本に掲載されていますので、ご興味のある方はお読みください。日本語訳の書籍もあります。Workbook)ポストモーテムの特徴の一つは学び(learning)があることです。Failure"(失敗からの学び)とあることからも学びが重要視されているのがわかります。非難しないこと(blamelessness)も特徴の一つです。原因を究明していると、個人やチームに対して責任を追及して非難しがちになり、その結果として問題が隠蔽されかねません。これは決して建設的ではありませんし、改善する方向に物事が動いていきません。非難しないことはとても重要なことです。Conklin)の言葉で次のものがあります。障害の要因となる潜在的な条件が元々あって、人はその発動条件を踏んでしまうだけだというものです。time.(労働者が障害を引き起こすのではない。労働者は組織内に眠っている潜在的な条件のトリガーを引くだけだ。Analysis)を行うことがあります。Whys"がよく用いられています。「なぜなぜ分析」は、問題の事象を引き起こした要因を「なぜ」を繰り返して掘り下げて、問題に対する対策を導き出す手法です。Whysを行っています。(GitLab)根本原因分析において、「なぜなぜ分析」やそれに類する分析方法では、このように要因の掘り下げを行って分析を行います。Rule"(停止ルール)について次のように述べています。階層や分類の最下層に到達したときその説明が望まれる心理的な安心を提供した一般的に受け入れられる原因(「ヒューマンエラー」など)を特定したその説明が政治的(または制度的)に便利である分析を続ける時間(または人手、資金)がないその説明が道徳的または政治的価値観に合致している探索を続けると未知の領域につながる多くの場合は1つ目の「階層や分類の最下層に到達したとき」に分析を止めることを目指しています。これは徹底性を求めてTETOingを行っています。実際の問題として、原因と結果の間に線形な因果関係が明確にあるような単純なケースだけではなく、複雑な要因が絡み合っているケースもあるため、徹底的な分析は難しいです。これを分析するために多くの時間と人材を費やすのは効率が悪いです。分析に費やす時間や人材は有限であるため、先の2つ目以降のような効率性を求めるETTOingが行われることになります。徹底性を求め過ぎると、時間やコストがかかり過ぎて対応が非常に遅れてしまいますし、効率性を求め過ぎると、間違った分析結果による間違った対応を行うことになりかねません。効率性と徹底性のバランスを取る必要があります。先の作業手順書の例の最後に次のように述べました。作業手順書を作成しても、様々な要因で障害が起きるときは起きますけどね。作業手順書を作成して作業したのにシステム障害が発生した場合には、どのような要因だったのかを考えてみます。作業手順書通りに手順を実行しなかったという単純なケースもあるでしょう。この要因の一つとしてペアオペレーションでダブルチェックしながら作業するのが運用規則だったのに一人で作業したとしたら、どうして1人で作業することになったのかという話になります。根本原因分析の結果として、組織的な要因が入ってくるかもしれません。作業手順書通りに作業したのにシステム障害を引き起こしてしまったというケースもあるでしょう。想定外のケースが発生することもあります。複数の特定の条件が組み合わさったときのみ問題が生じる場合は事前に想定するのが難しいでしょう。根本原因分析の結果として、時間をかけて要因を特定できたとしても、問題が生じる条件をすべて洗い出して対応するのにさらに時間がかかるかもしれません。レジリエンス・エンジニアリングシステム障害というのは頻繁に発生するものではないため、たいていの人は根本原因分析をやり慣れていません。根本原因分析のトレーニングを受けている人も多くはないでしょう。そのため、根本原因分析がうまくできずに、適切な要因を分析できないケースもあると思われます。principle"(「人間は自分が探そうとしているものしか見出せない」原則)があるため、自身が思い込んでいる要因や説明しやすい要因のみを示し、適切な要因を導き出せないこともあります。作業ミスは説明しやすい要因ではあるのですが、潜在的な要因がいくつかあって作業ミス自体はそのトリガーを引いているだけであり、作業ミス自体は根本的な要因ではないということもあります。根本原因を調べて対応を行うことはとても重要なことではあります。ETTO原則があるため、根本原因分析の要因のように「うまくいかないこと」のみに注目して対応を行うことには限界があります。そこで、本記事で時々登場しているレジリエンス・エンジニアリングでは「うまくいくこと」にも着目して、組織がざまざまな変化に対してうまくいくように調整していくことを考えています。レジリエンスポテンシャルを強化する」(エリック・ホルナゲル著)では、レジリエンスについて次のように定義しています。レジリエンスは、人々が単独または共同して、条件に応じてパフォーマンスを調整することによって大小さまざまな日常の状況変化をどのように扱うかについての表現である。組織のパフォーマンスが、予期されたもしくは予期されていない条件下(変化/妨害/好機)で同じように機能できれば、その組織はレジリエントである。本記事ではレジリエンス・エンジニアリングの紹介はしませんが、興味のある方は参考文献の資料を読んでみてください。まとめETTO原則により効率性と徹底性はトレードオフの関係にある。ITシステムの運用の例として作業手順書作成の例を示し、効率性と徹底性のバランスを考える必要があることを示した。システム障害と根本原因分析について紹介し、根本原因分析を徹底的に行うのが難しいということを示した。最後に2年前(2018年)から気になっていたETTO原則について、いくつかの文献を調べながら本記事を書いてみました。筆者の理解不足で誤ったことを書いている可能性があります。レジリエンス・エンジニアリングについては勉強し始めたばかりの段階で特に語れる言葉はありませんが、そういう分野があるということのみを紹介してみました。興味のある方はぜひ参考文献や参考サイトとして紹介したものを読んで確認してみてください。株式会社ハートビーツの技術情報やイベント情報などをお届けする公式ブログです。こちら「みんな仲良く」「プライドを持って」「変化を楽しむ」という企業理念に共感していただけるエンジニアを募集しています。