個人を責めることなく、根拠に基づくプロセスの原因を追跡する
実用的な根本原因の定義では、観察された「症状」、発生を後押しした「条件」、そして証拠に裏付けられた「原因」の3つを区別します。地域のクラフトワークショップを例にすると、同じ席に対して2人に予約完了通知が届く（症状）、電話予約とオンライン予約が別々の記録で管理されている（条件）、電話で予約された後も更新の遅れによりオンライン上で空席のまま残っていた（原因）、ということになります。最後の記述は、記録によってそのメカニズムが裏付けられている場合にのみ「原因」となります。これは小規模なプロセスの問題をまとめるための実践的な方法であり、すべての分析で固定された単一のラベル体系を使用しなければならないと主張するものではありません。
小規模プロジェクトにおける「根本原因」とは？
米国品質協会（ASQ）は、根本原因を「不適合の原因となった要因であり、是正処置を通じて対処すべきもの」と定義しています。根本原因分析は問題が発生した理由を解明する方法であると説明し、事象・原因要因分析（event-and-causal-factor analysis）では証拠とタイムラインを使用して原因要因と寄与要因を特定すると述べています。これらの考え方は、実用的な作業定義を裏付けています。根本原因とは、プロセスのうち証拠によって裏付けられた一部であり、提示された問題がどのように発生したかを説明し、実践的な変更によって対処できるものです。ASQの根本原因分析ガイダンス
「根本（Root）」という言葉は、原因が1つしかないような印象を与えることがあります。しかし、実際のプロセスの問題では、複数の要因が絡み合っている場合があります。ASQ自身も原因要因と寄与要因の両方に言及しているため、証拠に基づくのであれば、慎重な記録作成によって複数の原因を特定してもかまいません。誰かが最初に思いついたからという理由だけで、都合のよい説明を選んでしまうことは避けましょう。
症状、寄与する条件、原因はどう違うのか？
これらの分類は、簡潔な問題ステートメントをより明確にするのに役立ちます。これらは文章をまとめるための補助ツールであり、実際に何が起きたかを調査する作業の代わりになるものではありません。
条件は問題に寄与している可能性はありますが、メカニズム全体を説明しているとは限りません。例えば、ワークショップの多忙さが更新の遅れと重なることはあっても、「忙しかった」ということ単体では、なぜ2件目の予約完了通知が可能だったのかを説明できません。原因ステートメントは、プロセスと結果を結びつけるものでなければならず、タイムスタンプ、予約記録、予約手順の検証など、検証可能な何かによって裏付けられている必要があります。その証拠がない場合は、検証されるまでその説明を「原因の候補」と呼んでください。
裏付けのある原因を見つけるための短い質問の順序
人に対する判断ではなく、出来事から始めます。ASQ（米国品質協会）は、時系列を体系的に確立し、原因と結果を分析することを推奨しています。以下の質問は、そのアプローチを小規模な予約問題に適用したものです。ASQの根本原因分析の概要
これは「なぜなぜ分析（5つのなぜ）」に似ていますが、5回が必須というわけではありません。出来事を説明でき、修正のテストを導くことができる、具体的で検証可能なプロセスの説明が得られた時点で終了します。質問によって証拠ではなく推測が生じた場合は、不確実性をマークし、回答を確定したものとして扱う前に記録を確認するかプロセスを観察してください。
誇張せずに調査結果を記述する
簡潔なレポートには、以下のパターンを使用できます。
> 症状: [観察可能な結果。] 寄与条件: [それをより起こりやすくした状況。] 証拠に裏付けられた原因: [プロセスの仕組みと、それを裏付ける証拠。]
上記の具体例に適用すると以下のようになります。
この例は仮説に基づくものです。その根拠は説明の一部であり、実際のワークショップに関するレポートではありません。実際の調査では、想定された順序をご自身で確認した記録に置き換えてください。電話予約が2回目の確認よりも前に行われたことや、オンラインリストでまだ空席と表示されていたことをまだ立証できない場合は、「考えられる原因」と記載し、検証が必要な事項を明記してください。
元に戻せる修正策を選択し、それがメカニズムに対処しているか確認する
リスクの低い試行として、ワークショップはすべての予約チャネルで1つの共有空席台帳を使用することが考えられます。リクエストが電話によるものかオンラインによるものかにかかわらず、スタッフは予約を記録し、確認を出す前にその座席を利用不可としてマークします。これにより、恒久的なシステム変更を必要とせずに、提案されたメカニズム（2つのチャネルが異なる、または古い情報画面をもとに確認を出していること）にアプローチできます。
明確な開始点と終了点を設けて、今後開催される限られたセッションでこの手順を試してみてください。各確認内容を共有台帳と照合し、予約を担当するスタッフが一連の手順を一貫して遵守できたかどうかをヒアリングします。重複確認が依然として発生する場合や、確認前に台帳が確実に更新されていない場合、その試行ではこの変更が原因を抑止できているとは立証されていません。手順と根拠を再度見直してください。同じ修正策を繰り返しても、異なるメカニズムが解決されると思い込まないようにしてください。
したがって、適切な定義は単に問題を命名するだけにとどまりません。何が観察されたのか、どのような状況が影響した可能性があるのか、証拠がどのようなプロセスの説明を裏付けているのか、そして小規模で元に戻せる変更によってその説明をどのように検証できるのかを、第三者が理解できるようにするものです。
出典および適用範囲
独自の二重予約の例は、証拠に基づいて元に戻せるプロセステストへと進む流れを追っています。記載された情報源は記載された事実を裏付けるものであり、例や演習は独自の編集上の応用です。