#問題設定 #問題解決 #問題と課題
｢問題｣ と ｢課題｣ 、ちゃんと区別して使っていますか？
｢このサービスは問題が山積み｣ ｢この課題をどう解決するか｣ ―― ビジネスの現場では、こうした言葉が日常的に飛び交います。
普段は感覚的に使い分けているこれらの言葉ですが、実は曖昧なまま使っていると、思考が迷子になったり、チームの認識もズレていくんです。
特に ｢事象｣ ｢問題｣ ｢課題｣ 、そして ｢施策｣ という 4 つのステップを明確に区別できると、思考の解像度が格段に上がります。
そこで今回は、この 4 段階の思考フレームワークについて、具体例を交えながら、問題解決について考えていきます。
事象･問題･課題･施策の 4 段階構造
ではまずは、それぞれの言葉の定義を整理していきます。
[事象] 観測された ｢事実｣
スタートとなる ｢事象｣ は、観測された事実そのものです。数字や現象、実際に起きたことだけがここに分類されます。
大事なのは、事象にはまだ解釈を混ぜないことです。
たとえば ｢使いにくいからユーザーが減った｣ という表現には、｢使いにくい｣ という解釈が含まれています。まず事象として扱うべきは ｢ユーザー数が X% 減少した｣ という事実です。
[問題] 悪い事象を引き起こした原因と考えられる ｢仮説の束｣
次に ｢問題｣ です。
問題とは、事象の中で理想と比べたときの現状で適切ではないことです。また、その悪い事象を引き起こした ｢なぜ｣ の候補、つまり原因となる仮説の集合体を指すこともあります。
この ｢原因仮説の束｣ で重要なのは、この段階で原因として断定しないことです。｢これが原因に違いない｣ という思い込みを捨て、可能性を広く洗い出すフェーズだと考えてください。
ビジネスの現場では多くの場合、ある不都合な事象において真因は複合的であり、通常はひとつではありません。｢原因仮説の束｣ として複数の可能性を持っておく姿勢が求められます。
[課題] 解決すべき ｢方針･論点｣
洗い出した問題の中から、特定のものに対処すると決めたとき、次に設定するのが ｢課題｣ です。
課題は問題を解決するために ｢何を解決し、何を (あえて) しないか｣ という方向性を言語化したものです。
具体的な ToDo リストなどのやること (アクションリスト) をつくる前に、解決していくにあたっての大きな方針をここで決めます。
たとえば ｢サービスの UI を変える｣ というのは、課題と言うには曖昧で弱いです。この場合は ｢既存ユーザーが継続利用できる価値提供を再設計する｣ といった、解決の方針を示す課題設定がいいでしょう。
[施策] 具体的な ｢アクションプラン｣
最後に ｢施策｣ です。
方針となった課題を実行に移すための、具体的な行動計画が施策にあたります。
ここまで思考を深めて初めて、具体的な ToDo やアクションリストに落とし込まれます。施策では、課題で定めた方向性に沿って、｢誰が｣ ｢いつ｣ ｢何をするか｣ を具体化していきます。
[ケーススタディ] EC サイトの売上低迷
ここまでの ｢事象｣ ｢問題｣ ｢課題｣ ｢施策｣ の言葉の説明だけではまだイメージしづらいと思うので、架空の EC サイトのケースに当てはめて考えてみましょう。
ある EC サイトで ｢新規顧客は獲得できているのに、全体の売上が伸び悩んでいる｣ という状況が発生していたとします。
よくある ｢ダメな思考パターン｣
まず、うまくいかないパターンを見てみましょう。
事象を見た瞬間に ｢リピート率が悪いのは、メルマガがつまらないからだ｣ と、勝手な解釈を加えて原因を決めつけてしまうことです。その結果 ｢LINE 公式アカウントを始めよう！｣ ｢クーポンをもっと配ろう！｣ と、いきなり施策 (手段) に飛びついてしまいます。
これでは一時的に数字が良くなることはあっても、本質的な改善にはつながらず、リソースの無駄遣いになりかねません。
4 段階構造で整理した思考プロセス
では、先ほどの 4 つのステップである ｢事象 - 問題 - 課題 - 施策｣ で整理するとどうなるでしょうか。
Step 1. 事象 (観測)
まずは事実を冷静に見ます。月の購入者数は横ばいですが、内訳を見ると新規は増えています。しかし ｢リピート購入率｣ と ｢2 回目購入までの期間 (リードタイム) ｣ が悪化していました。これが解釈を含まない純粋な事象です。
Step 2. 問題 (原因仮説の束)
次に、なぜそれが起きたのか、問題原因の仮説として洗い出します。仮説なので、ここでは断定せず、可能性を列挙します。
まず考えられるのは、初回購入後の体験がユーザーの期待値を超えなかった可能性です。
商品の使い勝手が悪く、｢次も買う理由｣ が弱まったかもしれません。あるいは、配送や梱包、問い合わせ対応なども含めて、ユーザー体験が期待に応えられていない可能性もあります。
他には、広告媒体を変えたことで、商品と相性の悪い層、つまり一回きりの購入で終わってしまう層が流入してきていることも考えられます。さらには、競合他社のキャンペーンや低価格の新商品の登場によりユーザーが流出しているという仮説も成り立ちます。
Step 3. 課題 (方針)
データ検証の結果、初回体験の問題と流入層の質の問題が濃厚だったとします。
解決すべき方針を定めますが、ここで設定すべき課題は、単にメールを送ることではありません。より本質的な論点は、初回のお客さんが ｢次もこの商品で買いたい｣ と思える、顧客体験の中核的な価値 (コアバリュー) を再設計するという内容になります。これが課題です。
Step 4. 施策 (アクション)
課題が決まって初めて、具体的なアクションに落とし込みます。
例えば体験改善としては、初回購入後の 7 日間のフォローを強化します。具体的には使い方ガイドの送付、FAQ 整備、返品保証の明示などです。
また、EC サイトへの再訪問の導線の設計では、同梱チラシの見直しやマイページへの再購入ボタン配置を行います。
そして獲得チャネルの修正として、LTV (顧客生涯価値) が低いユーザーの多い流入チャネルの予算を、相性の良いチャネルへシフトさせて変えます。同時に訴求軸を ｢安さ｣ から ｢安心｣ へ変えていく施策も実行します。
このように段階を踏むことで、施策の精度と納得感が違ってきます。
陥りやすい 3 つの罠
ここまで見てきたプロセスを進める上で、陥りやすい罠がいくつかあります。
順番に見ていきましょう。
事象に解釈を混ぜてしまう
事象を整理する段階で ｢○○ のせいで ×× になった｣ と言っていないでしょうか。事実はあくまで ｢×× になった｣ という現象だけです。
しかし、その前にある ｢○○ のせいで｣ は本当にそうでしょうか。問題の原因を構造化する前に、憶測や印象だけで解釈をしてしまっていないでしょうか？
先ほどの EC サイトの例でいえば ｢利用頻度が落ちた。原因は機能変更だ｣ のように、事象に ｢原因は機能変更だ｣ という解釈を混ぜてしまうと、本当にそうなのかという検証プロセスを飛ばしてしまいかねません。事実は事実として、冷静に切り離す必要があります。
原因を単純化し決め打ちする
次に陥りやすい罠として ｢離脱が増えたのは新しい UI が悪いからだ｣ と、原因をひとつに決め打ちしてしまうのも危険です。
ビジネスにおいて真因は、複雑に連鎖しているのが普通です。例えば UI 、利用導線、提供価値、競合状況、季節性などです。｢原因はこれだ！｣ とひとつのことに飛びつかず、原因仮説を ｢束｣ として持ち、それらを構造化することが大事です。
課題が ｢ToDo リスト化｣ する
課題設定のフェーズで ｢プッシュ通知をする｣ ｢クーポンを出す｣ ｢機能を追加する｣ といった施策の羅列になってしまうケースがあります。
これらのひとつひとつは個別の手段であって、問題解決への方針となる課題ではありません。もし方針がないままリスト化した施策を走らせても、効果的な打ち手にはならないでしょう。
課題とは問題を解決するためにやるための論点であり、チームが目指すべきコンパスのようなものです。
しっかりと課題を言語化、構造化し、課題が複数あるなら優先順位を付け、時間軸での順番や大まかな流れを見極めてから、具体的な施策へ落とし込みましょう。
戦略フレームワークとの対応関係
では最後に、戦略という視点で ｢事象･問題･課題･施策｣ の 4 つを見てみます。
戦略を考える際のフレームワークに ｢目的･戦略･戦術･戦闘｣ がありますが、今回の 4 つのステップはこれらときれいに対応します。
事象から問題 (原因仮説) を設定し、それを本当に解決すべきかどうか考えるプロセスは、｢目的｣ にあたります。目的を達成するために、何をして、何をしないかという方針を決めることが ｢戦略｣ です。今回の話では課題に相当します。
そして、その課題を具体的にどう実行するかという ｢戦術｣ と ｢戦闘｣ が施策となります。
表面的な事象に惑わされず、事象から問題を掘り下げ、課題という戦略を立ててから、施策という戦術に落とし込み、施策を実行し戦闘に入っていく。この順序を守ることで、ビジネスの成果はより確実なものになるはずです。
まとめ
事象･問題･課題･施策の 4 段階思考フレームワークを取り上げました。
学びのポイントをまとめておきます。
- 事象には解釈を混ぜず、観測された事実だけを扱う。解釈を事実として扱ってしまうと、本当にそうなのかの検証プロセスが飛ばされてしまう
- 問題とはギャップを生んだ ｢原因仮説の束｣ であり、いきなりひとつには断定せず、複数の原因仮説を束として洗い出す。真因は通常ひとつではなく複合的
- 課題は具体的な ToDo リストではなく、｢何を解決し、何をしないか｣ という解決の方針･論点を言語化したもの
- 施策は課題で定めた方針に沿った具体的なアクションプラン。誰が･いつ･何をするかを明確にする
- 課題を言語化、構造化し、課題が複数あるなら優先順位を付け、時間軸での順番や大まかな流れを見極めてから、具体的な施策へ入る
