こんにちは、滝澤です。
今回は"The ETTO Principle"（効率-徹底性トレードオフ原則）について紹介します。ここでは「ETTO原則」と呼ぶことにしましょう。 ETTO原則はレジリエンス・エンジニアリングで著名なエリック・ホルナゲル氏（Erik Hollnagel）が提唱したもので、効率性（Efficiency）と徹底性（Thoroughness）はトレードオフの関係にあるというものです。 これは、元々は安全に関する分野での話ではあるのですが、IT分野においても無縁というわけではありません。そのあたりの話を紹介します。
本記事を3行でまとめると次のようになります。
- ETTO原則により効率性と徹底性はトレードオフの関係にある。
- ITシステムの運用の例として作業手順書作成の例を示し、効率性と徹底性のバランスを考える必要があることを示した。
- システム障害と根本原因分析について紹介し、根本原因分析を徹底的に行うのが難しいということを示した。
ETTO原則との出会い
まず最初に、"The ETTO Principle - Efficiency-Thoroughness Trade-Off"（効率-徹底性トレードオフ原則）を知った経緯を簡単に紹介します。
2018年にサンノゼで開催されたイベント"O'Reilly Velocity Conference San Jose, CA 2018"でのウィル・ガジェゴ氏（Will Gallego）のセッション"Architecting a postmortem"でした。このセッションの中で"The ETTO Principle"が紹介されていて興味を持ちました。 根本原因分析（RCA, Root Cause Analysis）を行う際の効率性の話で「十分な情報がない」「情報が多すぎる」「時間がない」「達成への圧力がある」といった文脈で登場しました。
このセッションの動画はO'Reilly Media社のサブスクリプションサービス O'Reilly Online Learning で観ることができます。
- Architecting a postmortem (O'Reilly)
この根本原因分析に対する話はウィル・ガジェゴ氏のブログ記事にもまとまっています。
- No, seriously. Root Cause is a Fallacy. (Will Gallego)
ETTO原則とは
ETTO原則の定義はエリック・ホルナゲル氏のサイトに掲載されています。
The ETTO principle refers to the fact that people (and organisations) as part of their activities frequently - or always - have to make a trade-off between the resources (primarily time and effort) they spend on preparing to do something and the resources (primarily time and effort) they spend on doing it. The trade-off may favour thoroughness over efficiency if safety and quality are the dominant concerns, and efficiency over thoroughness if throughput and output are the dominant concerns. It follows from the ETTO principle that it is never possible to maximise efficiency and thoroughness at the same time. Nor can an activity expect to succeed, if there is not a minimum of either.
DeepLさんに日本語に訳してもらうと次のようになります。
ETTOの原則は、人々（と組織）が活動の一部として、頻繁に-あるいは常に-何かをするための準備に費やす資源（主に時間と労力）と、それをするために費やす資源（主に時間と労力）の間でトレードオフをしなければならないという事実を指しています。トレードオフは、安全性と品質が主な関心事であれば効率性よりも徹底性を、スループットとアウトプットが主な関心事であれば徹底性よりも効率性を好むかもしれません。それは、効率性と徹底性を同時に最大化することは決して不可能であるというETTOの原則に従っています。また、活動は、どちらかの最小値がない場合、成功することを期待することはできません。
資源（時間と労力）は有限であるため、効率を求めると時間や労力が足らずに徹底できないし、徹底させると時間や労力がかかって効率が悪い、という当たり前の話ではあります。しかし、それをきちんと定義して明文化にしたことにとても価値があります。
ETTO原則についての書籍が出版されていますので、興味のある方は読んでみてください。電子書籍版（Kindle版）もあるため、手軽に入手可能です。
- "The ETTO Principle: Efficiency-Thoroughness Trade-Off: Why Things That Go Right Sometimes Go Wrong", Erik Hollnagel
なお、本記事では"Thoroughness"を「徹底性」と訳しています。レジリエンス・エンジニアリング分野では"The ETTO Principle - Efficiency-Thoroughness Trade-Off"は「効率-完全性トレードオフ原則」と訳されており、"Thoroughness"は「完全性」と訳されています。しかし、IT分野においては「完全性」は"Integrity"の訳として使われることの方が多いため、あえて違う訳として「徹底性」を用いました。
ETTO
効率性と徹底性をトレードオフする理由として、書籍では次の例を紹介しています。（Chapter 1より引用、DeepLによる翻訳）
- 必要な資源の限られた利用可能性、特に限られた時間またはどのくらいの時間が利用可能であるかについての不確実性。
- 必要以上の努力をしたくないという自然な傾向（実際には人間の傾向）。
- 予想外のことが起こった場合のために予備(資源、時間の)を維持する必要性-多くの場合、暗黙のまたは明示されていない-。
- 上司、同僚、または部下からの社会的な圧力、例えば、特定の方法で、または特定の時間までに物事を行うように。
- 組織的な圧力、例えば、公式の優先事項（「安全第一」）と実際の慣行（「時間内に準備する」）との間の衝突、または資源の不足など。
- 個人の優先順位、仕事の習慣、野心など。
身につまされますね。効率性を求めるケースが多いわけです。これをETTOingと呼んでいます。日々の業務をこなすために、効率性を求めてETTOingを行うことは必要なことです。
さらにエリック・ホルナゲル氏は作業に関連したETTO規則としてWork-related ETTO rulesを紹介しています。いくつか引用します。
- It looks fine. / 見た目は問題ない。
- It is not really important. / 本当に重要なことではない。
- It is normally OK, there is no need to check. / 通常は問題ないので、確認する必要はない。
- It is good enough for now. / 今のところは十分だ。
- It is not my/our responsibility. / 私/私たちの責任ではない。
- It will be checked, or done, by someone else later. / 後で誰かが確認するだろう。
- It has been checked, or done, by someone else before. / 以前に誰かが確認した。
心配性な人はだんだん不安になってきました。私もこれを書いていて不安になります。どこかの猫が「ヨシ！」と言っていそうですね。
効率性を求めるETTOingだけを行っていると、もちろん事故や障害を引き起こすリスクが増えますし、その対応のためにかえって効率性が下がることになりかねないです。
そこでエリック・ホルナゲル氏は、現在の効率性は過去の徹底性を前提としており、現在の徹底性が将来の効率性に必要だと述べています。
そのために、徹底性を求めるTETO原則（Thoroughness-Efficiency Trade-Off principle, 徹底-効率性トレードオフ原則）が必要になります。ETTOing（効率性を求めること）とTETOing（徹底性を求めること）をバランスよく行う必要があります。次のサイトに説明がありますので興味のある方はご覧ください。
- ETTO and TETO (Erik Hollnagel)
また、先の書籍の"Epilogue"のセクション"From ETTO to TETO"にも詳細な説明があります。
作業手順書の作成
ITシステムの運用のお仕事の例で考えてみましょう。 作業手順書の作成について考えてみます。
作業手順書を作らずに作業を行ったとしましょう。作業手順書を作成する時間を省くというETTOingが行われています。このときは、ヒューマンエラーによる作業の失敗や作業に伴うシステム障害の発生のリスクが常にあります。何も失敗せずに作業が完了したり、その後のシステムにも障害が起きなかったら、結果としては効率性が良かったということになります。しかし、作業に失敗したり、その後にシステムに障害が発生したら、その対応に時間と労力を費やすために、総合的には効率性が悪かったという結果になります。
逆に、あらゆる作業に作業手順書を作成してから行うとしましょう。TETOingが行われています。このときは、ヒューマンエラーによる作業の失敗や作業に伴うシステム障害が発生するリスクは小さいでしょう。この場合は、業務としての効率は悪くなります。例えば、1回限りの参照系（非更新系）の作業（例えばシステムの状況を確認する作業）にも手順書を作成してから作業するのは決して効率のよい作業とは言えないでしょう。pingコマンドを実行するのに作業手順書を作ることを想像してください。 しかし、作業手順書を再利用できるのであれば、長期的な視点で見ると、将来に対しては効率性がよいということになります。
ここでETTOingとTETOingのバランスを考えてみた例を示してみます。
更新系の作業については、ヒューマンエラーによる作業に伴うシステムへの影響が生じるリスクが高いため、作業手順書を作成するというTETOingを行います。
参照系（非更新系）の作業については、ヒューマンエラーによる作業に伴うシステムへの影響が生じるリスクが低いため、作業手順書を作成しないというETTOingを行います。ただし、簡易でない作業については作業の漏れを防ぐために作業手順書を作成するというTETOingを行います。
更新系・参照系を問わず定型作業については、作業手順書を作ることはTETOingではありますが、同じ手順書を再利用できるため、将来の効率性の向上になります。
なお、作業するエンジニアの技術スキル次第でも調整可能ですが、ヒューマンエラーの発生は作業当日のエンジニア自身の身体的・精神的状況にも影響されるため、技術スキルへの高い依存はしない方がよいでしょう。深夜に障害対応をしていて徹夜明けかもしれないですし、家族が風邪を引いていて頭が心配事でいっぱいかもしれません。
まあ、作業手順書を作成しても、様々な要因で障害が起きるときは起きますけどね。
システム障害と根本原因分析
ITシステムを運用していて、どうしても発生してしまうのがシステム障害です。システム障害が発生したら、その対応を行い、システムを正常化させようとします。一連の対応が終わったら、その振り返りとして、組織によってはポストモーテム（postmortem）を作成します。
ポストモーテムについては以下のGoogleのSRE(Site Reliability Engineering)本に掲載されていますので、ご興味のある方はお読みください。日本語訳の書籍もあります。
- Chapter 15 - Postmortem Culture: Learning from Failure (Site Reliability Engineering)
- Chapter 10 - Postmortem Culture: Learning from Failure (The Site Reliability Workbook)
ポストモーテムの特徴の一つは学び（learning）があることです。先の書籍の章のタイトルにも"Learning from Failure"（失敗からの学び）とあることからも学びが重要視されているのがわかります。また、非難しないこと（blamelessness）も特徴の一つです。原因を究明していると、個人やチームに対して責任を追及して非難しがちになり、その結果として問題が隠蔽されかねません。これは決して建設的ではありませんし、改善する方向に物事が動いていきません。非難しないことはとても重要なことです。
トッド・コンクリン氏（Todd Conklin）の言葉で次のものがあります。障害の要因となる潜在的な条件が元々あって、人はその発動条件を踏んでしまうだけだというものです。
Worker's don't cause failures. Worker's trigger latent conditions that lie dormant in organizations waiting for this specific moment in time.（労働者が障害を引き起こすのではない。労働者は組織内に眠っている潜在的な条件のトリガーを引くだけだ。その条件はこの特定の瞬間を待っているのだ）
ポストモーテムでは原因究明のために根本原因分析（RCA, Root Cause Analysis）を行うことがあります。根本原因分析の手法の一つとして、日本では「なぜなぜ分析」が、海外では「なぜなぜ分析」を元にした"5 Whys"がよく用いられています。「なぜなぜ分析」は、問題の事象を引き起こした要因を「なぜ」を繰り返して掘り下げて、問題に対する対策を導き出す手法です。次のGitLab社のポストモーテムでも5 Whysを行っています。
根本原因分析において、「なぜなぜ分析」やそれに類する分析方法では、このように要因の掘り下げを行って分析を行います。
エリック・ホルナゲル氏の書籍"The ETTO Principle"では、事故調査の原因分析の際にどこで分析を止めるかという"The Stop Rule"（停止ルール）について次のように述べています。
- 階層や分類の最下層に到達したとき
- その説明が望まれる心理的な安心を提供した
- 一般的に受け入れられる原因（「ヒューマンエラー」など）を特定した
- その説明が政治的（または制度的）に便利である
- 分析を続ける時間（または人手、資金）がない
- その説明が道徳的または政治的価値観に合致している
- 探索を続けると未知の領域につながる
多くの場合は1つ目の「階層や分類の最下層に到達したとき」に分析を止めることを目指しています。これは徹底性を求めてTETOingを行っています。 実際の問題として、原因と結果の間に線形な因果関係が明確にあるような単純なケースだけではなく、複雑な要因が絡み合っているケースもあるため、徹底的な分析は難しいです。これを分析するために多くの時間と人材を費やすのは効率が悪いです。分析に費やす時間や人材は有限であるため、先の2つ目以降のような効率性を求めるETTOingが行われることになります。
徹底性を求め過ぎると、時間やコストがかかり過ぎて対応が非常に遅れてしまいますし、効率性を求め過ぎると、間違った分析結果による間違った対応を行うことになりかねません。効率性と徹底性のバランスを取る必要があります。
作業手順書による作業の例
先の作業手順書の例の最後に次のように述べました。
まあ、作業手順書を作成しても、様々な要因で障害が起きるときは起きますけどね。
作業手順書を作成して作業したのにシステム障害が発生した場合には、どのような要因だったのかを考えてみます。
作業手順書通りに手順を実行しなかったという単純なケースもあるでしょう。この要因の一つとしてペアオペレーションでダブルチェックしながら作業するのが運用規則だったのに一人で作業したとしたら、どうして1人で作業することになったのかという話になります。根本原因分析の結果として、組織的な要因が入ってくるかもしれません。
作業手順書通りに作業したのにシステム障害を引き起こしてしまったというケースもあるでしょう。想定外のケースが発生することもあります。複数の特定の条件が組み合わさったときのみ問題が生じる場合は事前に想定するのが難しいでしょう。根本原因分析の結果として、時間をかけて要因を特定できたとしても、問題が生じる条件をすべて洗い出して対応するのにさらに時間がかかるかもしれません。
レジリエンス・エンジニアリング
システム障害というのは頻繁に発生するものではないため、たいていの人は根本原因分析をやり慣れていません。根本原因分析のトレーニングを受けている人も多くはないでしょう。そのため、根本原因分析がうまくできずに、適切な要因を分析できないケースもあると思われます。また、"What-You-Look-For-Is-What-You-Find (WYLFIWYF) principle"（「人間は自分が探そうとしているものしか見出せない」原則）があるため、自身が思い込んでいる要因や説明しやすい要因のみを示し、適切な要因を導き出せないこともあります。例えば、作業ミスは説明しやすい要因ではあるのですが、潜在的な要因がいくつかあって作業ミス自体はそのトリガーを引いているだけであり、作業ミス自体は根本的な要因ではないということもあります。
根本原因を調べて対応を行うことはとても重要なことではあります。しかし、ETTO原則があるため、根本原因分析の要因のように「うまくいかないこと」のみに注目して対応を行うことには限界があります。
そこで、本記事で時々登場しているレジリエンス・エンジニアリングでは「うまくいくこと」にも着目して、組織がざまざまな変化に対してうまくいくように調整していくことを考えています。
書籍「Safety-IIの実践 レジリエンスポテンシャルを強化する」（エリック・ホルナゲル著）では、レジリエンスについて次のように定義しています。
レジリエンスは、人々が単独または共同して、条件に応じてパフォーマンスを調整することによって大小さまざまな日常の状況変化をどのように扱うかについての表現である。組織のパフォーマンスが、予期されたもしくは予期されていない条件下（変化／妨害／好機）で同じように機能できれば、その組織はレジリエントである。
本記事ではレジリエンス・エンジニアリングの紹介はしませんが、興味のある方は参考文献の資料を読んでみてください。
まとめ
- ETTO原則により効率性と徹底性はトレードオフの関係にある。
- ITシステムの運用の例として作業手順書作成の例を示し、効率性と徹底性のバランスを考える必要があることを示した。
- システム障害と根本原因分析について紹介し、根本原因分析を徹底的に行うのが難しいということを示した。
最後に
2年前（2018年）から気になっていたETTO原則について、いくつかの文献を調べながら本記事を書いてみました。しかし、筆者の理解不足で誤ったことを書いている可能性があります。 また、レジリエンス・エンジニアリングについては勉強し始めたばかりの段階で特に語れる言葉はありませんが、そういう分野があるということのみを紹介してみました。
興味のある方はぜひ参考文献や参考サイトとして紹介したものを読んで確認してみてください。
参考文献
- "The ETTO Principle: Efficiency-Thoroughness Trade-Off: Why Things That Go Right Sometimes Go Wrong", Erik Hollnagel
- 「Safety‐1 & Safety‐2―安全マネジメントの過去と未来」 エリック・ホルナゲル著
- 「Safety-IIの実践 レジリエンスポテンシャルを強化する」 エリック・ホルナゲル著
- 「現場の実践知を生かすレジリエンスのデザイン」（計測と制御 第54巻 第7号 2015年7月号、北村正晴著）
- 「Safety-IからSafety-IIへ―レジリエンス工学入門―」（オペレーションズ・リサーチ 2014年8月号、エリック・ホルナゲル著）
- 「医療安全へのレジリエンスアプローチ」（平成25年度国公私立大学附属病院医療安全セミナー）
参考サイト
- The ETTO Principle - Efficiency-Thoroughness Trade-Off (Erik Hollnagel)
- Work-related ETTO rules (Erik Hollnagel)
- ETTO and TETO (Erik Hollnagel)
- The Arbitrariness of Accident Analysis (Erik Hollnagel)
- Architecting a postmortem (O'Reilly)
- No, seriously. Root Cause is a Fallacy. (Will Gallego)
