経営課題をMECEに整理する｜部門別の改善案を二重計上しない課題空間の作り方

営業は「納期回答が遅い」、供給側は「予定の確認が多い」、情報システム部門は「情報を探しにくい」と改善案を出してきた。経営会議に向けて一覧を統合するとき、これらは別々の経営課題でしょうか。それとも、同じ出来事を違う場所から見ているのでしょうか。

経営課題をMECEに整理するには、機能・プロセス・顧客を別々の軸として使い、同じ出来事を照合します。複数の欄に関係すること自体は問題ではありません。重複して数える場所と、まだ調べていない場所を見つけ、今回の判断に使える範囲を明らかにすることが目的です。

課題空間の範囲を、今回の予算判断に合わせる

MECEは、分けた要素が互いに重ならず、合わせると全体を覆うという考え方です。MECEの考案者への公式インタビューでも、この関係が説明されています。ただし、分類の整合性と、現実の原因をすべて発見したことは分けて考える必要があります。

本稿では、調べる対象を軸で区切った範囲を「課題空間」と呼びます。部門別の改善予算案を統合するなら、まず対象事業、調査期間、扱う顧客、意思決定をそろえます。「会社の問題を全部」ではなく、「対象事業の受注前の納期回答について、次期にどの改善へ予算を付けるか」と書くところから始めます。範囲外にした論点も別に残してください。

以下の納期回答の例は、分類を説明するために作った教材です。「売上が減った」という結果、「供給確認が止まる」という現象、「検索画面を作る」という施策を同じ階層に並べず、現象を整理してから原因と対策を考えます。原因の仮説をどう確かめるかは、問題定義から原因の検証へ進める手法の使い分けとつながります。

機能・プロセス・顧客を、別々の問いとして切る

機能：業務を成立させる、どの役割に問題があるか

機能は部署名ではなく、必要な役割で区切ります。納期回答なら「供給予定を確定する」「回答内容を判断する」「回答を顧客へ伝える」などです。営業部という箱に全部を入れると、営業が担当していても供給予定の確定に関わる論点を見失います。担当部署は別の列に置きます。

役割の洗い出しには、業務プロセスを階層で分類するAPQCの業務分類フレームワークの説明も参考になります。その分類をそのまま自社の課題名にせず、実際に行っている役割と突き合わせ、足りない区分や細かすぎる区分を直します。同じ階層では「予定の確定」と、その一部分である「在庫の照会」を並列にしないようにします。

プロセス：どの受け渡しで止まっているか

次に、問い合わせ受付から供給確認、回答内容の確定、顧客への連絡までを並べます。各工程について、開始に必要な情報と、次の担当へ渡す結果を記します。「供給確認中」という状態だけで終えず、誰から何を受け取り、何がそろえば回答を確定できるのかまでたどります。

機能が同じでも、最初の問い合わせと回答変更では確認すべき事実が違います。通常の流れに加え、取消、差し戻し、担当不在などの例外がどの工程へ戻るかも記します。出来事を数える場合は、最初の受付工程など計上先のルールを固定し、後続工程への影響は参照で示します。

顧客：どの条件の顧客で困り事が現れるか

顧客の軸は、今回の判断に必要な区分を選びます。例えば「基準日時点で取引実績あり・なし・確認できない」とすれば、同じ基準で振り分けられます。「新規・大口・海外」のように異なる性質を混ぜると、同じ顧客が複数に入ります。規模や地域も必要なら、それぞれ別の属性にします。

最初からすべての組み合わせを大きな表にする必要はありません。機能を行、工程を列にし、出来事へ顧客区分を付けた一覧から始めます。表は調査範囲の点検に、出来事の一覧は重複の照合に使います。軸を増やす基準は、「その区別で調べる記録や予算判断が変わるか」です。

切り口	教材で確かめること	混ぜない情報
機能	供給予定の確定に必要な情報はそろっているか	部署の名称
プロセス	供給確認から回答確定へ何を渡すか	原因の決め付け
顧客	取引実績の有無で必要な確認が異なるか	規模・地域との混在

同じ出来事なら計上先を決め、影響先は残す

営業の「回答待ち」と供給側の「更新待ち」は、文章が似ているかだけで統合しません。元の照会番号、発生時点、対象、解消条件を照合します。同じ照会について「供給予定が共有され、回答を確定できる状態」を待っているなら、同じ課題の別の見え方としてまとめる候補です。元の記述と報告元は残します。

一方、情報がそろっても承認権限が曖昧で回答できないなら、情報の欠落と権限の不一致は分けて追います。片方を直しても他方が残るか、違う根拠で解消を確かめる必要があるかが判断の手がかりです。共通の親課題に結び付ける場合も、子課題ごとの解消条件を消さないようにします。

ここで、課題の件数と影響の量も区別します。同じ照会の待ち時間を営業欄と供給欄の両方で足したり、親課題の合計へ子課題の合計をさらに足したりすると二重計上になります。経過時間を測るのか、担当者が実際に費やした作業時間を測るのかも先にそろえます。別々の担当者が行った独立した作業は、同じ課題に関係していても別の作業として記録できます。

「回答の遅れが売上減少の原因だ」という判断には、失注理由など別の確認が必要です。分類表だけから損失額や改善効果を確定せず、推計の対象と前提を分けて残してください。改善案ごとの期待効果を合算する際にも、同じ照会や顧客を重複して含めていないかを見ます。

責任者は、報告した人ではなく、解消条件を満たすまで調整する人として決めます。関係部署は協力先として複数記載できます。課題と、調査・画面作成などの作業が混ざっていたら、未解決の問いと作業を分ける管理表の書き換え方を使い、改善施策を実施しただけで課題まで閉じないようにします。

空欄の交点を、確認対象に戻す

空欄は「問題がない」と同じではありません。まだ記録を調べていない場所、今回の範囲には該当しない場所、調べた範囲では問題を検出しなかった場所を区別します。確認した記録の範囲、確認日、判断理由を付けておけば、次に何を調べるかが決まります。

例えば、取引実績のない顧客の照会が空欄なら、その期間に照会がなかったのか、別窓口に記録されているのかを確かめます。問題を検出しなかった場合も、調べた記録が対象を覆っているかを見直します。入力した各行が課題や確認待ちのいずれかへ結び付いているか、例外の出来事がどの区分にも入らず残っていないかを確認すると、表の外へ落ちた論点を探せます。

海外の公表例では、英国の輸出信用機関UKEFが、銀行などへの調査を通じて申請時の用語や追加書類の分かりにくさを把握しました。法務や引受審査の担当と検討し、回答した条件に応じて必要書類を示す設計を試しています。英国政府が紹介したUKEFの調査と設計の過程は、部署内の作業だけでなく、利用者が次へ進めるかを見る実例です。

英国行政の事例・指針は、日本企業とは法制度や権限の置き方が異なります。本稿では手続そのものを当てはめず、利用者の到達点から部門間の境界を点検する考え方を参考にしています。

AIの下書きは、統合候補と追加質問に使う

AIへ渡す前に、人が照会の受付から回答までを一度たどり、入力、判断、承認、後続への受け渡しを言葉にします。そのうえで、利用を認められた環境と情報の範囲で、原文の行IDを保った分類案を作らせます。次のような指示から始められます。

各行について、機能・工程・顧客区分の候補を返してください。同じ出来事と思われる行ID、その根拠となる原文、統合前に必要な質問を付けてください。不明な区分や原因は補わず、確認待ちにしてください。元の行を削除せず、入力の全行IDとの対応を示してください。

人が確認するのは、区分の見栄えだけではありません。違う照会を似た文章だから統合していないか、同じ照会の言い換えを別件にしていないか、顧客区分を推測していないかを記録へ戻って確かめます。表の空白については、問題を創作させず「何を確認すれば判断できるか」という質問を出させます。

英国のService Standardは、2026年1月29日の更新で、生成AIを含む技術や先に選んだ解決策ではなく、利用者の必要に沿って設計する点を明確にしています。利用者の問題全体を捉える英国の公式指針を踏まえると、「AIで分類する」より先に、どの判断を可能にしたいかを置く順番が大切です。

分類案の作成を試す段階では元の一覧を保持し、採用・分割・統合の理由を人が記します。必要な受け渡しや承認が抜けているなら、分類処理を速める前にその流れを直します。実装の検討へ進む際は、ツール導入から開発・運用定着までの支援範囲とも対応させ、どこまでを改善対象にするかを具体化できます。

経営課題の整理は、すべてを整然と分類した時点で完了するわけではありません。今回扱う範囲、同じ出来事の計上先、残る未確認箇所、次に確かめる人が説明できるかを点検します。機能・プロセス・顧客という別々の切り方を、その予算判断のために使うことが、課題空間をMECEに近づける実務です。