正解: BCorrect: B
MECE に分解して寄与度を測り、影響の大きい枝に深掘りを集中させる進め方が、ロジックツリーの本来の効果を引き出します。Decomposing MECE-style, measuring each branch's contribution, and concentrating deeper analysis on high-impact branches is how a logic tree delivers its value.
ロジックツリー(原因究明に使う場合はイシューツリーやWhyツリーとも呼ばれます)の目的は、漠然とした問題を検証可能な部分問題に分解し、限られた分析資源を最も影響の大きい部分に集中させることです。効果的な進め方には二つの原則があります。第一に、分解の軸は MECE であること。「セグメント別」「時期別」「チャネル別」といった軸を使えば、全体の解約がどこに集中しているかを漏れなく把握できます。第二に、分解した後は必ずデータで各枝の大きさを測り、重要な枝だけを深掘りする「重点化」を行うことです。選択肢1は重点化を欠き、資源を均等に浪費します。選択肢3は自社の問題構造を理解せずに他社の解を借りる類推の誤用です。選択肢4は網羅的アプローチの典型で、時間がかかる上に回答の偏りも大きい方法です。この進め方は戦略コンサルティングで標準的に用いられています。The purpose of a logic tree (called an issue tree or why-tree when used for root cause analysis) is to break a vague problem into testable sub-problems and concentrate limited analytical resources where the impact is greatest. Two principles make it effective. First, decomposition axes should be MECE; axes such as segment, timing, or channel reveal where churn is concentrated without gaps. Second, after decomposing, always measure each branch's size with data and drill only into the important ones, a step called prioritization. Option 1 lacks prioritization and spreads resources evenly. Option 3 borrows another company's solution without understanding your own problem structure, a misuse of analogy. Option 4 is the classic exhaustive approach: slow, and churned customers respond at low and biased rates. This method is standard in strategy consulting firms such as McKinsey, and Kazuto Ataka's Issue Driven advocates the same discipline.
ロジックツリーで分解できるのは既知の切り口だけで、構造の外にある原因(例:競合の新サービスの登場、決済手段の変化)は枝として現れません。また、データで寄与度を測るには適切なデータ基盤が必要で、それがない組織では分解しても検証できず、結局は憶測の議論に戻ります。分解の美しさに時間をかけすぎる問題もあります。A logic tree can only decompose along known axes; causes outside the structure, such as a competitor's new service or a shift in payment methods, never appear as branches. Measuring contribution requires adequate data infrastructure, and organizations without it cannot verify the branches and drift back to speculation. Spending too long perfecting the tree is another common problem.
ツリーの分解と並行して、解約した顧客5〜10人への短いインタビューを行い、構造の外にある原因のヒントを得ましょう。データがない枝は「要検証」と明示し、最低限の計測を先に整備します。分解には時間の上限(例:半日)を設け、粗くても早くデータ検証に進み、必要に応じてツリーを修正する反復型の運用が現実的です。Alongside decomposing the tree, run short interviews with five to ten churned customers to pick up hints about causes outside the structure. Flag branches without data as 'to be verified' and set up minimal measurement first. Cap decomposition time (half a day, say), move quickly to data validation even with a rough tree, and iterate the tree as needed.