「このサイト、何から考えればいいんですか？」と3年目のデザイナーに聞かれたとき、自分がその年次でまったく同じ問いに沈んでいたのを思い出しました。Web制作を17年やってきて、いま振り返ると、当時の私に足りなかったのは「センス」でも「経験量」でもなく、問題解決フレームワークとしての「考える順番」を固定する型でした。
この記事は、若手Webデザイナーが「毎回ゼロから考えて疲弊する」状態を抜けるために、現場で実際に使っている問題解決の型の話です。フレームワークを片っ端から覚えるのではなく、3つに絞って手に馴染ませる方向で書きます。
毎回ゼロから考えて破綻していた頃のこと — 問題解決フレームワークを知る前夜
3〜5年目の頃、私は案件のキックオフのたびに、毎回ゼロから組み立て直していました。「今回はBtoBのリクルートサイトだから、まずはペルソナを……いや競合分析からか……でも納期がきついからワイヤーから先に……」と、考える順番すら定まっていない。
ある人材系の案件で、納期2週間前にディレクターから「結局このサイト、何のためのページなんでしたっけ？」と聞かれて、答えに詰まったことがあります。デザインは進んでいた。コンテンツもほぼ揃っていた。でも、目的が言語化されていなかったから、レビューが入るたびに「もっと信頼感を」「もっとカジュアルに」と方向がブレ続けていました。
その案件は、終わってから自分の中で「もう毎回ゼロから考えるのはやめよう」と決めた、ターニングポイントになりました。問題解決フレームワークという言葉は知っていたけれど、自分の現場でどう使うかが分かっていなかった。ここから自分用の型を作るのに、結局5年くらいかかっています。
3〜5年目のデザイナーから話を聞くと、似た悩みをよく聞きます。Figmaは触れる、AIも使える、参考サイトのトレースもできる。でも案件が始まった瞬間、「何から考えればいいか」が毎回リセットされる。これは能力ではなく、問題解決の型を持っていないことが原因です。
問題解決フレームワークとは — 「考える順番」を固定する技術
問題解決フレームワークは、教科書的には「複雑な問題を分解し、整理して、解決に導くための思考の枠組み」と説明されます。間違ってはいないのですが、現場感のある言い方をすると、「毎回考える順番を固定する技術」です。
考える順番が決まっていないと、案件ごとに脳の使い方が変わって疲れます。今日はターゲットから考え、明日は競合から、明後日はトレンドから……と、判断の起点が揺れる。「順番」を固定するだけで、案件が始まったときの第一手が決まり、ブレた時に立ち戻る場所ができます。
私が17年の中で残った定義はこれです。
- 問題解決の型 = 考える順番 × 漏れダブりを潰す仕組み
順番だけでは網羅性が足りないので、後述するMECEで「漏れていないか」をチェックする。この2つが揃って、はじめて型として機能します。逆に、SWOT・3C・ファイブフォース・PEST……といったフレームワーク名を覚えても、この2つの土台がないと、ただの単語コレクションで終わります。
私自身、20代の頃にMBA系の書籍でフレームワーク名を50個くらいノートに書き出したことがあります。1年後、案件で使ったのはロジックツリーだけでした。現場に残るフレームは、本当に少ないんです。
デザイン現場で使う3つの問題解決フレームワーク
ここからは、私がWeb制作の現場で17年使い続けて残った3つだけを紹介します。本やセミナーで紹介される定番フレームは10〜20個ありますが、デザイン現場で実用に耐えるのはこの3つに絞られました。
① ロジックツリー — 大きな問いを階層分解する
ロジックツリーは「サイトの目的」のような大きな問いを、頂点に置いて、下に向かって「何を達成すれば目的を満たせるか」を階層分解していく図です。要するに、トーナメント表の逆向きの矢印を想像してもらえれば近いです。
私が初めてロジックツリーを使ったのは、3年目の通販系リニューアル案件でした。「売上を上げる」が頂点。下に「新規購入を増やす／既存顧客の購買頻度を上げる」と分け、さらにそれぞれを「集客／コンバージョン」「会員特典／再訪導線」と分けていく。4階層ほど分解した時点で、自分が作っていたデザインが「新規購入のコンバージョン」だけにしか効いていないことが見えました。
その時、ディレクターと一緒に「今回の案件は新規購入を増やすところに振り切ろう」と決められた。それまで「全部を良くする」つもりで散らかっていた画面が、急に整理されたのを覚えています。問題解決フレームワークの第一の効用は、「捨てる場所」を決められることだと、この時に体感しました。
② MECE — 漏れダブりを潰す
MECE（ミーシー）は「Mutually Exclusive, Collectively Exhaustive」の頭文字で、「漏れなく、ダブりなく」分解できているかをチェックする原則です。ロジックツリーで分解した枝が、MECEに従っているかを後から見直すイメージで使います。
例えば「サイト訪問者」を分解するときに、「新規／リピーター」と分ければ漏れなくダブりがない。でも「新規／20代女性／スマホユーザー」と分けると、20代女性で新規でスマホの人はどこに入るのか、という重複が起きる。これがMECEの違反です。
私の現場での使い方は単純です。ロジックツリーを書いた後に、各階層を見直して「この枝を全部足したら、上の親に戻るか？」を確認する。戻らない枝が出てきたら、分け方を見直す。たったこれだけですが、サイトマップやコンテンツ構成のレビューで「何かが抜けている気がする」というモヤモヤを、構造的に潰せるようになります。
③ 自分の型 — 目的 → 課題 → ターゲット → 導線 → CTA
3つ目は、ロジックツリーとMECEを土台に、自分のWeb制作用にカスタマイズした順番です。目的 → 課題 → ターゲット → 導線 → CTA。この5ステップを案件のキックオフでメモに書き出すことを、3年目以降ずっと続けています。
それぞれ簡単に補足します。
- 目的: クライアントが本当に達成したいビジネス目標（売上／応募／問い合わせ等）
- 課題: 目的に対して、いま何が足りていないか（認知不足／離脱が早い／信頼感不足等）
- ターゲット: 課題を解消できる可能性のあるユーザー像（属性ではなく状態で書く）
- 導線: そのターゲットがサイトに来てから、どんな順番で情報に触れていくか
- CTA: 最終的にどのアクションを取ってほしいか（資料請求／会員登録／購入等）
この順番のポイントは、ターゲットを「目的と課題の後」に置いていることです。ペルソナ先行で組み立てると、クライアントが本当に解きたい課題からズレることがあります。目的→課題で先に「何を解くか」を固定してから、ターゲットを当てる方が、私の現場ではブレが少ないです。
この型を持っているだけで、案件が始まった瞬間にメモを開き、5項目を書き出す。それだけで第一手が決まる。「毎回ゼロから考えなくていい」というのは、想像以上に脳のリソースを節約します。
フレーム盲信の罠 — 型に当てはめすぎた失敗
ここまで「型を持つと楽になる」という話を書いてきたので、もう片方の話も書いておきます。型を盲信すると、今度は別の場所で破綻します。
4年目くらいの頃、私はロジックツリーにハマりすぎて、ある飲食店のサイト案件でも全部分解しようとしました。「集客」を頂点に、「Webからの集客／既存顧客のリピート」と分けて、さらにSNS／SEO／広告……と階層化していった。図としては綺麗にまとまった。
でも、クライアントは小さな個人店のオーナーで、「自分が10年やってきた店の雰囲気を、ちゃんとサイトで出してほしい」が本音の要望でした。ロジックツリーには「店主の人格」や「店の空気感」のような、構造化しにくい要素を組み込めなかった。フレームに収まる情報だけで判断した結果、人間の感情を抜け落としたんです。
仕上がったサイトは論理的には正しかったけれど、オーナーが「これは自分の店じゃない」と言ったときの表情を、まだ覚えています。そこから書き直しになり、最終的に「数値で測れない店主の語り」を冒頭に大きく置く構成に作り直しました。
問題解決フレームワークは、構造化できる情報を整理するための道具です。型に乗らない情報こそ、判断の決め手になる場面がある。これは pillar 記事（5つのビジネスフレームワーク全体像）でも書いていますが、フレーム思考は「使う／使わない」を判断する力とセットで初めて武器になります。
5つのビジネスフレームの中での位置づけ
この問題解決フレームワークの話は、私がpillar記事でまとめている5つのビジネスフレームのうち③にあたる位置づけです。5つの全体像は以下の通りです。
- クリティカルシンキング: 「本当にそうか？」と前提を疑う（確証バイアスとデザイナーの判断ミス で深掘り）
- ロジカルシンキング: 主張と根拠を整理する（説明が苦手なデザイナーのためのロジカルシンキング で深掘り）
- 問題解決フレームワーク: 考える順番を固定する ← この記事
- 言語化: 判断を言葉に変換する
- SMART法則: 目標を測れる形に置く（SMART法則で目標設定する技術 で深掘り）
5つの関係を一言で言うと、①②で「正しく考える」、③で「考える順番を固定する」、④⑤で「考えたことをアウトプットする」という流れです。問題解決フレームワークは、その中間にあって、思考と実行をつなぐハブの役割をしています。
順番としては、最初はクリティカルシンキング（前提を疑う癖）と問題解決フレームワーク（考える順番）の2つから入るのがおすすめです。私自身もこの2つを土台にして、後から言語化とSMARTを足していきました。5つを同時に学ぶ必要はありません。
まとめ — 問題解決フレームワークを「次の案件で使える1つの型」に落とす
長くなったので、最後に1つだけ持って帰ってもらえる話をします。
問題解決フレームワークの本質は、「毎回ゼロから考えなくていい状態」を自分の中に作ることです。SWOTもファイブフォースも3Cも、覚えなくていい。代わりに、自分の現場用の「考える順番」を5項目だけメモに書き出して、案件のたびに使い回す。これだけで、3〜5年目のデザイナーが感じている「毎回疲弊する」感覚は、かなり減らせます。
私の場合の5項目は「目的→課題→ターゲット→導線→CTA」でした。これは私の現場用の答えなので、皆さんはWebデザインなら別の5項目になってもいいし、3項目に絞ってもいい。大事なのは「順番を固定する」こと自体で、内容ではないです。
次の案件のキックオフで、紙でもメモアプリでもいいので、自分用の5項目を書き出してみてください。書き出した瞬間に「あ、これ前回と同じ順番で考えればいいんだ」と気づくはずです。そこから先は、案件を回すたびに項目を微調整して、自分の型に育てていく。私もまだ育てている途中です。
5つのビジネスフレームの全体像と、他の4つのフレームとの関係は、ビジネスフレームワーク全体像のpillar記事にまとめています。あわせて読むと、問題解決フレームワークが「思考の流れの中でどこに位置するか」が見えてきます。
参考文献・関連書籍
- 照屋華子・岡田恵子『ロジカル・シンキング』東洋経済新報社 — MECEとロジックツリーの古典的入門書
- バーバラ・ミント『考える技術・書く技術』ダイヤモンド社 — ピラミッド構造の元になった本
- 高田貴久『問題解決』英治出版 — 現場での使い方が一番リアル
この記事は「判断力を鍛える思考法」シリーズの一部です。
→ シリーズ全体を見る：判断力を鍛える思考法
フレームワーク思考を Web 制作現場の判断軸として使う技術は、こちらの pillar 記事でまとめています。
→ フレームワーク思考を含む5つのビジネスフレームワーク全体像
あわせて読みたい
「自分の強みは何か」が、見えなくなる時期があります。
診断を受けても、本を読んでも、「結局どう動けばいいか」が分からない。考えるほど止まる。これは個人クリエイターによくある状態です。
個人開発8本、月収2,000円。Web制作17年のクリエイターが、AI と「作る」「届ける」を honest に実験している過程をメルマガで公開しています。「観測する」生き方の実践ログです。
登録特典:「AI時代に取り残されないための構造整理シート」（PDF 12p / 5ステップ）― スキル棚卸しから、自分のポジション設計まで。
