【仕事】問題解決の為の思考整理【MECEと具体→抽象→具体】

こんにちは、シンヤです!
今回は【仕事】問題解決の為の思考整理【MECEと具体→抽象→具体】を解説いたします。
仮の問題を設定
あなたはWebサービスのマーケティング担当者です。
営業から以下のような相談を受けました。
プロダクトの売り上げがここ数ヶ月2%ずつ落ちてきている。
このままでは困るので、なんとかして欲しい。
要望を整理すると、以下のようになります。
- 問題:売り上げが下がっている
- 要望:売り上げを上げたい
上記の問題を解決し、要望を叶える施策を考えていきます。
問題解決の思考整理
いくつか方法やフレームワークがありますが、僕は以下の2つをよく使っています。
- MECE
- 具体→抽象→具体
それぞれ詳しく解説いたします。
MECE
MECEとは、
- Mutually
- Exclusive
- Collectively
- Exhaustive
の頭文字を取ったもので、直訳すると「漏れなく、ダブりなく」という意味です。
思考の内容を整理し、お互いを干渉させることなく解決策を洗い出す手法です。
言葉に表しただけでは、うまく伝わりませんね。
実際に実践してみようと思います。
「ロジックツリー」を使い課題を深掘りする
今回の課題は「売り上げを上げる」です。
そのために必要な要素を「ロジックツリー」を使って、洗い出していきます。
上記のようなロジックツリーを仮に作りました。
「売り上げを上げたい」という最終目標から、
- 新規会員を増やす
- ⭐️プラン申込の動線を最適化する⭐️
- プランの値段を上げる
上記3つを思いついたとします。
このうち「プラン申込の動線を最適化する」が、最も良い施策だと仮定します。
次にプラン申込に関しての問題点を洗い出します。
- プラン選択までたどり着けない
- プラン選択のボタンが押されない
- プランの数が多すぎる
ロジックツリーで表した、赤色の部分です。
この問題点を解決する方法を、以下のように考えました。
- プラン選択までたどり着けない
- 会員登録と同時に、プラン画面へ遷移
- プラン選択のボタンが押されない
- プラン遷移と同時に、ボタンを選択状態に
- プランの数が多すぎる
- プランの数を減らす
ロジックツリーで表した、青色の部分です。
次に「マトリクス図」を使い、洗い出した問題解決方法に優先順位をつけていきます。
「マトリクス図」を使い優先順位をつける
「マトリクス図」とは以下のような図のことです。
別名「4象限」ともいいます。
誰しも一度は目にしたことがあると思います。
対極な状態と比較して、問題解決方法の優先順位付けをしていきます。
以下の2つの要素で分析しました。
- 即効性:すぐ効果が出るか
- 実現可能性:すぐ実現できるか
つまり「即効性が高く」て「すぐ実現できるもの」が、最も優先的に取り組んだほうがいい施策と考えました。
- 会員登録と同時に、プラン画面へ遷移
- プラン遷移と同時に、ボタンを選択状態に
マトリクス図に照らし合わせ、上記の2つの施策を優先的に取り組んだ方がいいと仮定しました。
具体→抽象→具体
ロジックツリーで表した、赤色の部分です。
この問題点を解決する方法を、以下のように考えました。
- プラン選択までたどり着けない
- 会員登録と同時に、プラン画面へ遷移
- プラン選択のボタンが押されない
- プラン遷移と同時に、ボタンを選択状態に
- プランの数が多すぎる
- プランの数を減らす
先ほど上記のように、洗い出した問題点に照らし合わせ、解決方法を考えました。
どのようにして考えたかというと、これからご紹介いたします「具体→抽象→具体」の思考法を実践しました。
これから詳しく解説いたします。
具体→抽象
こちらを要約すると「問題点から解決方法の仮説を洗い出す」ということになります。
赤線の枠内で行っている作業ですね。
前述のMECEのフレームワークに照らし合わせると、以下のように説明できます。
- 具体
- 売り上げを上げたい
- 抽象
- 新規会員を増やす
- プラン申込の動線を最適化
- プランの値段を上げる
この工程でやりたいことは「課題に照らし合わせた問題解決方法の洗い出し」です。
目的に照らし合わせて、思いついた解決案を考えていきます。
抽象→具体
こちらを要約すると「洗い出した仮説から問題解決案を導き出す」ということになります。
赤線の枠内で行っている作業ですね。
前述のMECEのフレームワークに照らし合わせると、以下のように説明できます。
- 抽象
- プラン申込の動線を最適化
- 具体
- 会員登録と同時にプラン画面へ遷移
- プラン遷移と同時にボタンを選択状態に
- プランの数を減らす
この固定でやりたいことは「具体的な問題解決方法の実行案を決定する」です。
実行案を決めたら、前述の「マトリクス図」に照らし合わせて優先順位を決めていきます。
問題を解決できるUIを作る
私の仕事は「デザイナー」なので、問題を解決できるUI(ユーザーインターフェース)を考えます。
解決案は以下2つと定義しました。
- プラン選択までたどり着けない
- 会員登録と同時にプラン画面へ遷移
- プラン選択のボタンが押されない
- プラン遷移と同時にボタンを選択状態に
導き出した解決案を元に、UIを作り込んでいきます。
導き出した問題解決方法に基づいたUI
Before | |
---|---|
![]() |
![]() |
会員登録とプラン選択画面が、上記だったとします。 |
After | |
---|---|
![]() |
![]() |
最も選ばれているプランを上に配置し、デフォルトで選択状態にする。 |
会員登録と同時に「プラン申込」へ遷移。
最も選ばれているプランをデフォルトで選択状態にし、さらに最も選ばれているプランを目立たせ、注目度を高めています。
要件を定義した後に技術者にタスクが割り振られる
上記のような「問題を洗い出し整理する工程」を、IT業界では・・・
要件定義
といいます。
要件を具体的に定義した後、エンジニアやデザイナーなどの技術者に、タスクが割り振られます。
要件定義ができる人材がいないと仕事が進まないため、一般的に「上流工程」と言われています。
問題の本質を見極め、要件を整理する能力が求められます。
要件定義の力は、筋トレと同じで「場数を踏むだけ伸びる」と思います。
実戦経験値を積めば積むほど、本質を見極め問題点を整理する力は向上します。
まとめ
- 問題解決にはフレームワークがある
- 「MECE」と「具体→抽象→具体」の2つ
- 上記2つは「要件定義」におけるフレームワークの一つ
- 技術者にタスクを振り分ける前は、要件定義をする必要がある
- 基本的に上記2つのフレームワークに照らし合わせ、要件を定義した後技術者にタスクを振り分ける
今回は以上になります。
- 【仕事】問題解決の為の思考整理【MECEと具体→抽象→具体】