ケプナー・トリゴー法:合理的な問題解決と意思決定分析

Kepner-Tregoe法を、請求書の税額欄の誤りだけを切り分けるレンズとして表した図

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

ケプナー・トリゴー(KT)法は、ビジネス上の問題や意思決定を構造的に考えるための手法です。作業を4つの合理的プロセス、すなわち状況把握、問題分析、意思決定分析、潜在的問題分析に分けます。各プロセスはシンプルなワークシートを使うため、チームは意見ではなく証拠をもとに議論できます。

ケプナー・トリゴー法とは

KTは、問題解決と意思決定のための名前のついた手法で、ある一つの考え方に基づいています。悪い結果の多くは、問いが明確になる前に答えへ飛びつくことから生まれる、という考え方です。KTは決まった順序の問いを提供し、それぞれの順序は、書き留めて説明できる成果物で終わります。

この手法の歴史は、創設者の名を冠した企業によって詳しく記録されています。Kepner-Tregoeの沿革によると、ベン・トリゴーとチャック・ケプナーは1958年、カリフォルニア州パシフィック・パリセーズにあるトリゴーのガレージでKTのパートナーシップを始め、著書『The Rational Manager』は1965年にMcGraw Hillから出版されました。

この手法は、気づかないうちに広く使われてもいます。Kepner-Tregoeによると、ドイツ自動車工業会VDAの8D文書は、KTのIS / IS NOT法が監査で「優秀」の評価を得るのに役立つ点を強調しています。つまり、8Dレポートを作成したことがあれば、そうと知らないままKTの一部をすでに使っているのかもしれません。

重要な事実

  • 4つのプロセス: 状況把握、問題分析、意思決定分析、潜在的問題(または機会)分析です(Purple Griffonの解説)。
  • 起源: KTのパートナーシップは1958年に始まり、『The Rational Manager』が1965年に続きました。
  • 代表的なツール: IS / IS NOTの比較です。考えられる各原因を、問題が何であり何でないかに照らして検証します。
  • 判断ルール: MUSTは合否を分ける足切り条件です。WANTは重みづけをして採点します。
  • 最適な場面: 原因が明らかでなく、複数の関係者が対策に合意しなければならない、重大で曖昧な、あるいは再発する問題です。
  • 不向きな場面: なぜなぜ分析で足りるような、手早く済む軽微な問題です。

4つの合理的プロセス

KTは4つのプロセスを一組の道具として扱います。すべてを実行するとは限らず、順番どおりに進めるとも限りません。ただし、4つはそれぞれ異なる問いに答えるものであり、その問いを混同したときにチームは最も多くの時間を失います。

相互に独立したKepner-Tregoeの4つの思考ツールを、必須の手順ではなく開かれた道具箱として表した図

プロセス 答える問い 主なアウトプット
状況把握 何が起きていて、まず何に取り組むべきか。 懸念事項の優先順位リスト(担当者と次のステップ付き)
問題分析 なぜこれが起きたのか。 検証済みの、最も可能性の高い原因
意思決定分析 どの選択肢を選ぶべきか。 リスクが把握された、順位づけ済みの選択
潜在的問題分析 計画でうまくいかない可能性があるのは何か。 予防策と対応策

1. 状況把握

最初は混沌とした状態から始まります。10件の苦情、遅れている3つのプロジェクト、怒っている顧客が1社といった具合です。Purple Griffonの概要によると、このステップでは、現在の懸念事項をまだ解決せずにすべて洗い出し、それぞれを明確にするのに十分な情報を集め、緊急度、影響度、利用できるリソースに基づいて優先順位を決めます。

肝心なのは「まだ解決しない」という部分です。チームの本能は、最も声の大きい問題から直し始めることです。状況把握は、それを1時間だけ遅らせ、本当に優先すべき問題から直せるようにします。懸念事項ごとに、次にどのプロセスへ進むかも決めます。原因の特定が必要なのか、選択が必要なのか、それとも計画を守る必要があるのか、という判断です。

2. 問題分析(IS / IS NOT)

問題分析は、逸脱に対して使います。本来こう動くはずのものがそうならず、その原因がまだわからない状況です。この手法では、問題を定義し(何が、どこで、いつ、どの程度か)、データを集め、考えられる原因を列挙し、それぞれをデータに照らして検証することで、最も可能性の高い原因を見つけます。

中心になるのがIS / IS NOT表です。各項目について、問題がISである(実際に起きている)ことと、同じくらい丁寧に、ISではない(起きてもおかしくなかったのに起きていない)ことを記録します。そのうえで、2つの列の違いである差異を探します。Kepner-Tregoeは、差異はIS側にのみ当てはまるものでなければならないと指摘しており、「違いがある」というだけでは曖昧すぎて役に立ちません。

具体的な例を見てみましょう。ある請求チームが、一部の請求書で税率が誤っていることに気づきました。

項目 IS IS NOT 差異
何が 請求書の税率の誤り 金額の誤り、顧客の誤り 影響を受けるのは税額欄だけ
どこで 新しい地域別価格表の注文 旧価格表の注文 価格表によって税の参照先が異なる
いつ 第12週のテンプレート更新以降 第12週より前 更新の時期と発生時期が一致
範囲 請求書の一部で、増加中 すべての請求書 特定の製品コードのみ

次に、考えられる各原因に同じ検証を行います。その原因は、ISとIS NOTの両方のデータを説明できるでしょうか。新しい価格表で不具合が出る理由は説明できても、旧価格表で問題が出ない理由を説明できない原因は、無理のある仮定を重ねることになります。仮定が最も少なく、最も妥当な原因が採用され、対応に移る前にそれを検証します。

3. 意思決定分析(MUSTとWANT)

意思決定分析は、選択肢の中から選ぶために使います。Purple Griffonによると、目的を必須条件と望ましい条件に分け、代替案を出し、評価して、選択します。

この評価におけるKTの標準的な進め方は次のとおりです。

  1. 意思決定を1文で定義します。 たとえば「地域向け貨物の新しい運送会社を選定する」です。
  2. MUSTを書きます。 必須で、測定可能で、合否が明確な条件です。「5つの地域拠点すべてをカバーしている」はMUSTです。1つでも満たさない選択肢は、どれほど安くても除外します。
  3. WANTを書きます。 「最低コスト」や「リアルタイムの追跡」のような希望条件です。それぞれに、重要度を反映した重みをつけます。
  4. 残った各選択肢を各WANTについて採点し、重みを掛けて合計します。
  5. 上位2、3案のリスクを確認してから決定します。ここで4つ目のプロセスに引き継ぎます。

これが意思決定マトリクスに似ていると感じたなら、そのとおりです。ただし、一つ有益な違いがあります。先にMUSTによる足切りを行うため、高得点でも厳格な要件を破る選択肢を救うことはできません。

4. 潜在的問題分析

潜在的問題分析(PPA)は、未来に目を向けます。対策や計画を選んだあとで、何がうまくいかない可能性があるか、その確率はどれくらいか、影響はどの程度か、そのときどうするかを問います。そのうえで、発生確率を下げるための予防策と、それでも発生した場合に被害を抑えるための対応策を書き出します。Purple Griffonも同様の流れを説明しています。何がうまくいかない可能性があるかを特定し、予防策を計画し、コンティンジェンシープランを用意します。

これはFMEAの仲間ですが、より軽量です。FMEAはプロセスや製品設計の全体を詳細に採点します。PPAは、一つの計画を立ち上げる前に30分で行う点検です。

ケプナー・トリゴー法とその他の問題解決手法

どの手法を使うべきかは、チームがよく尋ねる質問です。正直に答えれば、これらは異なるレベルに位置しています。

特性要因図は考えられる原因を出し、Kepner-Tregoeは証拠で検証し、PDCAは選んだ対策を確認する、という役割分担の図

手法 得意なこと 一般的な所要時間 KTとの違い
5 Whys 単純な因果の連鎖 数分 KTは問題が「何でないか」との比較を求めるため、最初にもっともらしく見えたストーリーに流されにくい
特性要因図(フィッシュボーン図) 原因のカテゴリーのブレインストーミング 1時間 特性要因図は原因を出し、KTはそれを証拠に照らして検証する
8D 顧客に影響する品質問題の流出、封じ込め 数日から数週間 8Dは完全な報告プロセス。IS / IS NOTは、その問題記述と根本原因のステップの中で使う一つのツール
A3 1枚の紙でのチーム学習 数日 A3は書式であり育成の習慣。KTは分析用ワークシートのセット
根本原因分析 包括的なカテゴリー 状況による KTはRCAを規律をもって行う方法の一つで、意思決定やリスクも扱う
意思決定マトリクス 選択肢の採点 1時間未満 KTはMUSTによる足切りとリスク確認を加える

実践的な組み合わせとして、まず特性要因図で考えられる原因の候補を広げ、次にIS / IS NOTで絞り込みます。そして、PDCAサイクルで対策が定着したかを確認します。

ケプナー・トリゴー法のセッションの進め方

実際の問題に取り組むなら90分を確保し、管理職だけでなく、そのプロセスに関わる人たちも集めましょう。

KTのISとIS NOTの証拠で、影響を受けた新価格表の請求書と、影響を受けていない旧価格表の請求書を比較している図

  1. 懸念事項を列挙します。 あらゆる課題を壁に貼り出します。まだ解決はしません。
  2. 優先順位をつけます。 緊急度、影響度、リソースで順位づけします。それぞれに次のプロセスと担当者を割り当てます。
  3. 問題を特定します。 「請求システムが壊れている」ではなく、「請求書の税率の誤り」のように、1つの対象と1つの欠陥を示す1行の問題文を書きます。
  4. IS / IS NOT表を埋めます。 実質的なIS NOTを出すよう促します。IS NOTのデータが薄いことが、最もよくある失敗です。
  5. 差異と変化を探します。 IS側にどんな違いがあるか、始まった時期の近くに何が変わったかを問います。
  6. 考えられる原因を挙げて検証します。 各原因をすべての行に照らして検証します。無理のある仮定が必要なものは除外します。
  7. 最も可能性の高い原因を検証します。 お金をかける前に、簡単な確認や小さな実験を行います。
  8. 対策を決定します。 選択肢が複数ある場合は、MUSTとWANTを使います。
  9. 選んだ対策に潜在的問題分析を実施します。
  10. アクションとレビュー日を割り当てます。

そのまま使えるテンプレート

状況把握

懸念事項 緊急度(高/中/低) 影響度(高/中/低) 必要なリソース 次のプロセス 担当者 期限

意思決定分析

基準 種類 重み(1-10) 選択肢Aの得点 選択肢Bの得点 選択肢Cの得点
基準1 MUST(可否判定) 該当なし 可 / 不可 可 / 不可 可 / 不可
基準2 WANT
基準3 WANT
重みづけ合計

潜在的問題分析

計画のステップ うまくいかない可能性があること 発生確率 重大性 予防策 対応策 トリガー

部門別の活用例

部門 状況 最も役立つKTのツール
オペレーション 包装ラインが夜勤のときだけ詰まる IS / IS NOT(シフト、機械、材料を比較)
財務 月次決算が四半期ごとに2日ずつ遅れる 状況把握で重なり合う5つの原因を切り分け、最大の原因に問題分析を適用
セールス 特定の地域だけ受注率が下がった 地域、セグメント、担当者の経験年数、案件規模についてのIS / IS NOT
人事 3社のHRISベンダーから選ぶ データ所在地と給与計算連携をMUSTとした意思決定分析
IT ソフトウェアのリリースでログインの挙動が変わる 次の展開前の潜在的問題分析
カスタマーサポート ポリシー変更後に再問い合わせが急増 「何が変わったか」に着目した問題分析

やるべきこと、やってはいけないこと

やるべきこと

  • 問題を、1つの対象と1つの逸脱として書く。
  • IS NOTの列には、実際にあり得る代替の事象を書く。
  • MUSTは測定可能にする。「良いサポート」はMUSTではありませんが、「24時間以内の対応を契約に明記」ならMUSTです。
  • 有力な原因は、対応する前に検証する。
  • 費用がかかる、または元に戻しにくい計画には、潜在的問題分析を実施する。

やってはいけないこと

  • 状況把握の段階で、解決策のブレインストーミングをしない。
  • すべてのWANTをMUSTとして扱わない。選択肢が一つも残らなくなります。
  • ささいな単発の問題に、手法をフルに適用しない。やりすぎのプロセスは現実のコストです。
  • レビュー日を省かない。誰も確認しない対策は、推測にすぎません。
  • ワークシートで判断力を代替させない。主観的な重みづけはバイアスを持ち込む可能性があり、Purple Griffonの欠点の一覧も、この手法に必要な研修時間とともにその点を指摘しています。

KTを選ぶべき場面

原因が不明で、複数の説明が競合し、次のシフトでも追える記録がチームに必要なときに選びましょう。原因の連鎖が短く、間違えたときのコストが小さい場合は、なぜなぜ分析のような軽いやり取りを選びます。数時間の練習は見込んでおいてください。最初のIS / IS NOT表は時間がかかると感じますが、3回目には自然にできるようになります。

関連する品質の考え方としては、総合的品質管理があります。KT型の分析が根づく土壌となる文化を築くものです。欠陥とばらつきに焦点を当てた近い手法をお探しなら、Six SigmaがDMAICと統計ツールで同じ目的を果たします。

About the author

Linh Ngo

Linh Ngo

Customer Success Operations Manager

Linh Ngo is Customer Success Operations Manager at Rework, focused on AI-led process automation for operations teams, especially order fulfillment and finance workflows. Linh writes about process management and the AI productivity tools that take manual steps out of daily operations, so teams can see where work stalls and fix the process before adding headcount.