例外管理（マネジメント・バイ・エクセプション）とは：定義、事例、メリットとデメリット

著者: Tara Minh · 更新日: 2026年10月10日

例外管理（マネジメント・バイ・エクセプション）とは、成果が合意された許容範囲を超えて計画から逸脱したときにだけリーダーが介入する、というマネジメントの原則です。許容範囲内のことはすべてエスカレーションなしで進みます。管理者はあらゆる詳細ではなく、短い比較形式のレポートを確認するため、判断が必要な少数の問題や機会に集中できるようになります。

サーモスタットを思い浮かべてください。5分ごとに室温を確認する人はいません。目標温度を設定し、小さな幅を許容すれば、室温がその幅から外れたときにだけシステムが知らせてくれます。例外管理は、この同じ考え方を予算、納期、品質、そして人に当てはめるものです。

例外管理の起源

この考え方は、現代のほとんどのマネジメントフレームワークよりも古いものです。フレデリック・ウィンスロー・テイラーは『Shop Management』の中でこれを説明しており、同書はProject Gutenbergで無料のテキストとして公開されています。テイラーはこれを「例外原則」と呼び、手紙や報告書に埋もれて「机で溺れかけている」管理者と対比しました。テイラーによれば、例外原則の下では、管理者は「凝縮され、要約され、常に比較形式のレポート」だけを受け取るべきであり、過去の平均や基準からの例外、つまり特に良いものと特に悪いものの両方が指摘されているべきだとしています。

この一節には、多くの要約で見落とされている点が2つあります。第一に、テイラーは例外を両方向で示すことを求めていました。基準を上回る成果も例外であり、理解する価値があります。第二に、テイラーは要約が管理者に届く前にアシスタントが選別することを想定していました。フィルタリングは後付けではなく、設計の一部だったのです。

その後、この原則は2つの分野に広がりました。

• プロジェクトガバナンス。 PRINCE2の手法では、プロジェクト委員会がプロジェクトマネージャーに権限を委譲する仕組みに「例外による管理」が組み込まれています。PRINCE2自身のガイダンスでは、許容範囲を時間、コスト、スコープ、品質、便益、リスクについて設定される意思決定の境界と説明し、リスクがそれを超えるおそれがあるときにエスカレーションが必要になるとしています。
• リーダーシップ研究。 バスとアボリオのフルレンジ・リーダーシップ・モデルで使われる多因子リーダーシップ質問票（MLQ）では、Mind Gardenがこの考え方の2つのバージョンを挙げています。交換型リーダーシップに分類される「逸脱や誤りを監視する（例外管理：能動型）」と、受動的・回避的リーダーシップに分類される「火消しをする（例外管理：受動型）」です。名称は同じでも、行動はまったく異なります。この違いについては後ほど改めて取り上げます。

重要なポイント

重要なポイント

• フレデリック・テイラーは『Shop Management』で「例外原則」を名付けました。同書はProject Gutenbergで無料公開されています。テイラーは、管理者は基準からの例外を指摘した、凝縮された比較形式のレポートを見るべきだと主張しました。
• PRINCE2は時間、コスト、スコープ、品質、便益、リスクの6つの領域に許容範囲を設定し、リスクがそれを超えるおそれがあるときにエスカレーションが必要になります。
• 多因子リーダーシップ質問票は、能動型の例外管理を交換型の行動、受動型の例外管理を受動的・回避的な行動として扱っています。
• この原則は、作業開始前にベースライン、許容範囲、エスカレーション経路が文書化されている場合にのみ機能します。
• 主な失敗パターンは沈黙です。例外を報告することを人々が恐れていると、静かなダッシュボードは成功に見えますが、実際には問題を隠しているのです。

実務での仕組み

どのバージョンの例外管理も、同じ4つの要素の上に成り立っています。

1. 計画または基準。 存在しないものから逸脱することはできません。これがベースラインです。予算、サービスレベル目標、納期、品質スコアなどが該当します。
2. 許容範囲。 ベースラインの周りで許容される幅です。たとえばプロジェクトマネージャーは、誰にも確認せずにマイルストーンを3日遅らせたり、作業パッケージの予算を5%超過したりすることが認められている場合があります。
3. トリガー。 何を例外とみなすかを定めるルールです。良いトリガーは実際の超過だけでなく、予測も使います。ラインを越えてから初めてエスカレーションするのでは、対応に必要な時間を失ってしまいます。
4. エスカレーション経路。 誰に、どれだけ早く伝わり、その人が何を判断することが期待されているかです。

許容範囲は入れ子にもなります。委員会がプロジェクトマネージャーに幅を与え、プロジェクトマネージャーは各チームリーダーにさらに狭い幅を与えます。これにより、小さな問題は解決できる階層にとどまり、大きな問題だけが上に送られます。

例外管理と関連する考え方の比較

この原則は、いくつかの近い概念と混同されがちです。以下の表で違いを整理します。

最も明確な区別は、マイクロマネジメントとの違いです。表面上は正反対で、一方はすべてを見て、もう一方はほとんど何も見ません。しかし、うまく設計されていない例外管理の仕組みは、別のルートでマイクロマネジメントに変わってしまいます。許容範囲が厳しすぎてすべてがトリガーになれば、管理者はダッシュボードを使っているだけで、結局あらゆる詳細を確認する状態に戻ってしまいます。

能動型と受動型の例外管理

ここで、リーダーシップ研究は、プロジェクトガバナンス版にはない警告を加えています。

能動型の例外管理とは、リーダーが事前に逸脱を注視し、問題が大きくなる前に介入することです。テイラーやPRINCE2が説明しているのはこちらで、例外を早期に浮かび上がらせる仕組みです。

受動型の例外管理とは、リーダーが何かがすでにうまくいかなくなり、問題が自分の机に届くまで待つことです。Mind Gardenはこれを「火消しをする」と呼び、質問票では受動的・回避的なグループに位置づけています。フルレンジ・リーダーシップ・モデルでは、これらのスタイルが最も能動的なものから最も能動的でないものまで、どのように一つのスペクトル上に並ぶかを説明しています。

違いは原則そのものではありません。誰かが監視の仕組みを構築したかどうかです。「例外があれば持ってきて」と言いながら、ベースラインも許容範囲もレポートもないリーダーは、ただ驚かされるのを待っているだけです。自分がどちらを実践しているか分からない場合は、シンプルな質問をしてみてください。今日、あるプロジェクトが計画からずれ始めていることを、自分はどうやって知るだろうか？ 答えが「誰かが教えてくれるだろう」なら、あなたは受動型の側にいます。

導入手順

ステップ1：例外管理に適したものを選ぶ

すべてが対象になるわけではありません。適しているのは、繰り返し発生し、測定可能で、よく理解されている業務です。月次決算、サポートの対応キュー、納品スケジュール、調達支出などが該当します。適していないのは、初めて行う業務、明確な基準のないクリエイティブな業務、まだ実績を積んでいない新入社員です。

ステップ2：ベースラインを設定する

計画を数値で書き出してください。「チケットを迅速に解決する」はベースラインではありません。「初回応答時間の中央値が4時間未満」がベースラインです。過去のデータがあれば活用し、ベースラインが実際にその業務にかかる時間を反映するようにします。

ステップ3：許容範囲を定義する

判断が必要になるまで、成果がどこまでずれてもよいかを決めます。意味がある場合は、許容範囲を非対称にしてください。早まる分には制限なく受け入れても、2日を超える遅れは受け入れない、といった形です。指標ごとに設定し、数は少なく保ちます。

ステップ4：エスカレーションのしきい値を書き出す

各指標について、少なくとも2つのレベルを定義します。警告レベル（上司に伝えるが判断は不要）と、エスカレーションレベル（期限付きで判断が必要）です。予測によるトリガーも含めてください。「期日に間に合わない見込みです」は、期日がまだ過ぎていなくても例外です。

ステップ5：責任者と経路を明確にする

各指標には、報告を担う責任者が1人と、例外を受け取る人が1人必要です。受け取る人がその場で何を判断してよいか、何をさらに上に上げるかを書き出しておきます。

ステップ6：例外を報告しやすくする

例外を早めに報告することは期待されている行動であり、失敗の告白ではないと、はっきり伝えてください。問題を指摘して責められるチームは、指摘しなくなります。このステップが、仕組み全体が機能するかどうかを左右します。

ステップ7：許容範囲を定期的に見直す

許容範囲は時間とともに古くなります。四半期ごとに見直してください。誰も例外をトリガーしないなら、範囲が緩すぎる可能性があります。すべてがトリガーになるなら、厳しすぎます。

テンプレート：コピーして使える例外トラッカー

指標ごとに1行ずつ記入してください。表は最も重要な5〜10個の指標に絞ります。

上記の数値はあくまで例です。自社の過去データに基づく数値に置き換え、その数値で評価される人たちと合意してください。

ビジネス機能別の例

以下のシナリオは、パターンを示すための仮想的なものです。

プロジェクトマネジメント。 委員会が納期と予算を設定してプロジェクトを承認します。プロジェクトマネージャーは許容範囲内の小さな遅れを予備費で吸収でき、納期や予算が守れないと予測されたときにだけ例外を上げます。

財務。 コントローラーは、予算との差が一定の割合を超えた勘定科目だけを一覧にした差異レポートを確認します。計画どおりの科目は表示されません。レポートは40ページではなく2ページになり、議論は重要な3行に集中します。

営業。 営業ディレクターはすべての商談を確認するわけではありません。確認するのは、あるステージに通常より長く滞留している商談、週ごとに一定以上変動した予測、しきい値を超える値引きです。それ以外は担当者とそのマネージャーに任されます。この手法が属するより広いスタイルについては、マクロマネジメントのガイドで解説しています。

カスタマーサポート。 サポートリーダーは、アラートラインのあるキューのダッシュボードを見ています。応答時間の中央値が目標内であれば対応は不要です。警告レベルを超えたらリーダーが人員を再配置し、エスカレーションレベルに達したらサポート責任者に報告されます。

オペレーションと製造。 テイラーが出発点としたのはこの分野です。品質管理図、スクラップ率、機械の停止時間はすべて基準に対して測定されます。オペレーターと監督者が通常のばらつきに対応し、範囲外の数値が出ると定められた対応が開始されます。

人事。 人事チームは、採用までの日数、入社90日以内の離職率、経過日数別の未充足求人を追跡します。経営陣に連絡が入るのは、あるポジションが通常の範囲を大きく超えて空席のままのとき、または早期離職率が通常の幅を超えて上昇したときだけです。

メリットとデメリット

このうち2つのデメリットは、詳しく見ておく価値があります。

ずれの問題。 6か月間ずっと許容範囲ぎりぎりの内側にある指標は何もトリガーしませんが、実際の傾向を示している可能性があります。傾向のルールを追加してください。たとえば、各期間が範囲内であっても、指標が3期間連続で同じ方向に動いたらエスカレーションする、といったルールです。

沈黙の問題。 例外管理の仕組みは、それに情報を提供する人々と同じ程度にしか正直になれません。例外を報告すると自分の評価が下がるとチームメンバーが考えれば、隠しきれないほど大きくなるまで抱え込むでしょう。そのような文化での緑色のダッシュボードは良いニュースではありません。チームの心理的安全性を確認すべきサインです。

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

よくある間違い

適さない業務に使う。 例外管理には基準が必要です。初期段階の実験や新入社員に適用すると、指針のないまま人を放置することになります。

放任による権限委譲と混同する。 許容範囲内で権限委譲する場合でも、明確な責任の所在が必要です。マネジメントの機能の概要は、計画と統制がセットであることを思い出させてくれます。立てていない計画に対して統制することはできません。

全員に同じ許容範囲を設定する。 長い実績のあるシニアのプロジェクトマネージャーは、初めてリーダーを務める人よりも広い範囲を任せられます。許容範囲には経験を反映させることができます。

許容範囲の内側を一度も見ない。 うまく運用されている仕組みであっても、リーダーは時々通常の業務をサンプルとして確認すべきです。指標では捉えられないことが分かります。

実践に移す

1つのチームと3つの指標を選んでください。上記のテンプレートを使い、それぞれについて計画、許容範囲、責任者、エスカレーション経路を書き出します。それを1四半期運用してみてください。そして2つの質問をします。以前より早く気づけたことは何か、そして範囲内にとどまっていたために見逃したことは何か、です。

2つ目の質問が最も重要です。例外管理は、注意を正しい場所に向けるための方法であり、注意を払うのをやめるための方法ではありません。