システム思考とデザイン思考の違いと使い分け

システム思考とデザイン思考の違いと使い分け ビジネススキル

ー この記事の要旨 ー

  1. システム思考は「全体の構造から入る」思考、デザイン思考は「ユーザーへの共感から入る」思考であり、両者の違いは問題を見る出発点にあります。
  2. 二つを使いこなすポイントは、組み合わせることではなく、目の前の課題が「すでにある問題を解く」のか「新しい価値を生み出す」のかに応じて、適切な起点を選ぶことです。
  3. この記事では、5つの観点で違いを整理するだけでなく、課題に応じた使い分けの判断軸、工程ごとの役割分担、統合時に陥りやすい失敗パターンとその回避策まで解説します。

「とりあえず両方やる」が、いちばん成果から遠い

「全体を俯瞰しなさい」と言われても何から手をつければいいか分からない。逆に「ユーザーに共感しなさい」と言われても、共感した先で何が変わるのか見えない。システム思考とデザイン思考は、どちらも複雑な問題に立ち向かう強力なフレームですが、この二つを「なんとなく良さそう」で混ぜると、どちらの強みも消えてしまいます。

システム思考は「全体の構造から問題を見る」思考法、デザイン思考は「ユーザーから問題を見る」思考法です。違いは、問題を見る出発点にあります。

観点 システム思考 デザイン思考
出発点 全体の構造・つながり 個人の体験・困りごと
問いの形 なぜこの構造が問題を生むのか この人は本当は何に困っているのか
向いている課題 再発する問題・複雑に絡んだ問題 新しい価値・新商品・顧客理解

この記事では5つの観点で違いを整理し、現場で目の前の課題に対してどちらを起点にすべきかの判断基準まで示します。違いを丸暗記することがゴールではありません。大事なのは「いま自分が向き合っている課題は、構造から入るべきか、人から入るべきか」を選べるようになること。ここが選べると、フレームに振り回されず、課題に合わせて思考の入口を切り替えられるようになります。

なお、それぞれの思考法そのものをもっと深く知りたい方は、システム思考は関連記事『システム思考とは?』で、デザイン思考は関連記事『デザイン思考とは?』で詳しく解説しています。

まず押さえる:二つは「どこから問題を見るか」が正反対

細かい違いに入る前に、両者の出発点の差をもう少し具体的に押さえておきましょう。

ざっくり言えば、システム思考は「引いて全体を眺める」思考、デザイン思考は「寄って一人に共感する」思考です。森にたとえるなら、システム思考は森全体の生態系がどうつながっているかを見る考え方、デザイン思考は森の中を歩く一人の利用者が何を感じているかを見る考え方です。

同じ「売上が伸びない」という課題でも、システム思考は値引き→客足→ブランド毀損→さらなる値引きという悪循環の構造を疑い、デザイン思考は「そもそも顧客は何に価値を感じて買っているのか」を観察から問い直します。

この「視点の向き」が正反対だからこそ、補い合えます。次の章から、5つの観点でその違いを具体的に見ていきます。

5つの観点で見る違い

違いは「定義の暗記」ではなく「使いどころの判別」のために整理します。以下の5観点が、後半の使い分け判断に直結します。

観点 システム思考 デザイン思考
起点 構造・全体最適 人間・ユーザー中心
視座 動態を俯瞰(時間軸・遅延を含む) 共感から発想(その場の体験)
時間軸 長期的な変化を重視 短い検証サイクルの反復を重視
主な問い どこに介入すれば全体が変わるか 誰の何を解決すれば価値が生まれるか
代表的なアウトプット 因果ループ図・氷山モデル(構造図・介入点) ペルソナ・共感マップ・プロトタイプ
得意領域 複雑に絡み合った既存の問題の構造解明 まだ言語化されていない新しい価値の創出

起点:構造から入るか、人から入るか

最大の違いは、問題を見る「入口」です。システム思考は要素同士のつながりという構造から入ります。一つの不具合を単独で見ず、それを生み出している関係性の網の中に位置づけます。一方デザイン思考は、特定の人間の体験から入ります。統計上の平均ではなく、一人の具体的なユーザーが何に困り、何を感じているかを起点にします。

視座と時間軸:動態の俯瞰か、共感からの反復か

システム思考は時間軸を含めて動きを捉えます。「いま起きている結果は、過去の何が遅れて表面化したものか」という遅延やフィードバックループを重視し、長期的な変化を読み解きます。デザイン思考は、まずユーザーに深く共感し、そこからアイデアを発散・収束させて形にしていきます。静的な構造把握というより、短いサイクルでつくっては試す反復のプロセスです。

この発散と収束の進め方は、ダブルダイヤモンド(問題を広げて絞り、解決策を広げて絞る2回の往復で表すモデル)として知られています。早く試して学ぶことで、机上の分析だけでは見えなかったニーズを掘り起こすのがデザイン思考の流儀です。

代表的なアウトプットの違い

ツールと成果物を見ると性格がよく分かります。システム思考の因果ループ図(CLD:Causal Loop Diagram)や氷山モデルは、目に見える出来事の下にある構造やメンタルモデルを掘り下げる道具で、最終的に手元に残るのは構造を可視化した図と「どこを変えれば効くか」という介入点です。提唱の系譜としてはジェイ・フォレスターのシステムダイナミクスを源流に、ピーター・センゲの『学習する組織』で広く知られるようになりました。

デザイン思考の共感マップやペルソナは、ユーザー理解を可視化するための道具です。その基盤には人間中心設計(HCD:Human-Centered Design)の考え方があり、当事者の観察と共感から価値を設計します。手元に残るのは、実際に触れて試せるプロトタイプという具体物です。IDEOやスタンフォード大学d.schoolを中心に普及し、ティム・ブラウンが代表的な提唱者として知られます。

得意領域:解く力か、見つける力か

システム思考は「絡まった既存の問題」をほどくのが得意です。なぜ何度対策しても再発するのか、という構造的なしつこさに強い。デザイン思考は「まだ誰も言語化していない価値」を見つけるのが得意です。顧客自身も気づいていない潜在ニーズを掘り当てる場面で力を発揮します。

どちらを起点にするか:課題から逆算する判断軸

ここからがこの記事の核心です。多くの解説は「組み合わせると強い」で終わりますが、現場で本当に必要なのは「目の前のこの課題で、まずどちらを手に取るか」という起点の判断です。

判断のコツは、課題が「すでにある問題」なのか「これから生む価値」なのかを見極めることです。まずは次の3つで、ざっと当たりをつけてみてください。

  • 問題が繰り返し起きている → システム思考から
  • 顧客のニーズや本音が見えない → デザイン思考から
  • 構造の問題と体験の問題が両方ありそう → システム思考で全体を見てからデザイン思考へ

システム思考から入るべき課題

次のような課題は、構造から入ったほうが早く本質に届きます。

  • 対策を打っても問題が繰り返し再発する(根本に構造的な悪循環がある)
  • 一つの部署を良くすると別の部署が悪くなる(部分最適が全体を壊している)
  • 原因と結果の間に時間差があり、犯人が特定しにくい
  • 関係者・要素が多く、誰の責任とも言い切れない

これらに共通するのは「全体のつながりを見ないと打ち手を間違える」という性質です。実務でも、営業部門の売上は伸びているのに全社の利益率が下がる、といった「部分は伸びているのに全体が悪化する」場面では、システム思考から入ると見落としを防ぎやすくなります。

デザイン思考から入るべき課題

一方、次のような課題は人への共感から入るのが近道です。

  • 顧客が離れているが、その理由が数字からは見えない
  • 新しい商品・サービスのアイデアそのものが必要
  • 既存の解決策がどれもしっくりこない(課題の捉え方自体を疑うべき)
  • ユーザーの「言葉にならない不満」を掘り当てたい

これらに共通するのは「人を深く観察しないと、解くべき問いがそもそも分からない」という性質です。新しい企画やサービスを生む場面では、数字の分析より先に一人のユーザーに向き合うほうが、実感のある手がかりが得られやすいものです。

迷ったときの一問

どちらとも言いにくいときは、自分にこう問うてみてください。「いま自分は、すでに見えている問題を解こうとしているのか、それともまだ見えていない問題を見つけようとしているのか」。前者ならシステム思考、後者ならデザイン思考が起点として噛み合います。それでも30秒で判断がつかないときは、まずシステム思考で全体構造を整理してからデザイン思考へ移るほうが、手戻りが少なく済みます。土台の見取り図がある状態で人に向き合うほうが、観察の焦点を絞りやすいからです。

二つをつなぐ:統合プロセスの工程マッピング

起点を選べたら、次は二つを連動させる段階です。これは「両方やる」という曖昧な掛け声ではなく、どの工程をどちらが担うかを対応づけると見えてきます。

工程 主に担う思考 やること 次に渡すもの
問題の発見 システム思考 構造を俯瞰し、どこに介入すべきか当たりをつける 「ここを変えると効く」というレバレッジ仮説
課題の定義 デザイン思考 その介入点に関わる人を観察し、真の困りごとを掘る ユーザー起点で再定義された課題
解決策の創出 デザイン思考 発散と収束でアイデアを出し、試作する 形になった解決策の候補
影響の検証 システム思考 その解決策が全体構造に副作用を生まないか確かめる 全体最適から見た採否判断

このマッピングの肝は、デザイン思考で生み出した解決策を、最後にもう一度システム思考で「全体への波及」として点検する点です。言い換えると、構造を見る(システム思考)→ 人を観察する(デザイン思考)→ 解決策を試す(デザイン思考)→ 全体への影響を確かめる(システム思考)という、抽象から具体へ下りてまた抽象へ戻る往復になっています。

一見ユーザーに喜ばれる施策が、別の場所で新たな悪循環を生むことは珍しくありません。発想(デザイン思考)と俯瞰(システム思考)を往復させることで、部分最適の罠を避けられます。

なお、こうした「前提から組み立て直す」発想をさらに広げたい場合は、関連記事『第一原理思考とは?』が参考になります。また、試作を通じて考えるアプローチについては、関連記事『プロトタイピング思考とは?』にまとめています。

「統合したつもり」で形骸化する失敗パターン

成功イメージばかりが語られる一方で、実際の現場では「組み合わせたのにうまくいかない」が頻発します。ここを正面から扱うことが、この二つを本当に使いこなす分かれ目です。

失敗1:共感だけで終わり、構造に戻らない

ユーザーへの共感ワークショップで盛り上がったものの、出てきた施策を全体構造に照らさないケースです。個別の困りごとには応えても、システム全体では別の問題を誘発し、結局成果につながりません。共感の熱量が高いほど起きやすい罠です。

失敗2:構造分析が精緻すぎて、人が消える

因果ループ図を緻密に描くことに没頭し、肝心の「その構造の中で誰がどう困っているか」が抜け落ちるケースです。図は美しいのに、現場の実感と乖離した打ち手になります。レバレッジポイント(介入点)を取り違える典型でもあります。

失敗3:抽象度のズレで議論が噛み合わない

これは二つを同時に使うときに最も起きやすい失敗です。システム思考は構造やパターンという抽象度の高いレイヤーを扱い、デザイン思考は具体的なユーザー体験という低い抽象度を扱います。実際の会議でも、全体構造の話をしている人と、目の前の顧客の話をしている人が混在し、議論がすれ違う場面は少なくありません。防ぐコツは、話の「ズームレベル」を一言で宣言することです。「ここからはユーザー視点に切り替えます」と区切るだけで、認識がそろいやすくなります。

これらの失敗に共通するのは、起点選択(前章)と工程の受け渡し(前々章)を曖昧にしたまま「両方使えばいい」と進めてしまうことです。逆に言えば、どちらを起点にするかを決め、工程ごとに主役を入れ替える設計さえできていれば、形骸化はかなり防げます。

他の思考法との関係

システム思考とデザイン思考だけが思考法ではありません。位置づけを知っておくと使い分けの解像度が上がります。

ロジカルシンキングやクリティカルシンキングは、どちらの思考法の中でも下支えとして働きます。ロジカルシンキングは筋道を通すため、クリティカルシンキングは前提を疑うために使われ、システム思考の構造分析でもデザイン思考の課題定義でも土台になります。つまりこの二つは「起点」ではなく「全工程で効く基礎体力」に近いものです。

整理すると、問題を「見つける」局面で強いのがデザイン思考、問題の「構造を見る」局面で強いのがシステム思考、そして筋道を通す・前提を疑うという土台で全体を支えるのがロジカルシンキング・クリティカルシンキング、という関係になります。型を増やすほど、課題に応じた切り替えがしやすくなります。

よくある質問(FAQ) 

システム思考とデザイン思考、初心者はどちらから学ぶべきですか?

目的によります。

新しい企画やサービスを生む仕事が多いならデザイン思考から、組織や仕組みの「繰り返す問題」に悩んでいるならシステム思考から入ると、学んだ実感を得やすいでしょう。どちらも独立した完成形ではなく、最終的には行き来できる状態が理想です。

システム思考とデザイン思考は一緒に使えますか?

使えます。ただし「同時に」ではなく、工程ごとに切り替えて併用するのが現実的です。全体構造の把握(システム思考)→ ユーザー視点での解決策づくり(デザイン思考)→ 全体への影響の検証(システム思考)という順で回すと、両者の強みを引き出せます。1つのプロジェクト内で「今どちらの視点で議論しているか」を明示するのが、併用を成功させるコツです。

システム思考とロジカルシンキングはどう違いますか?

扱う因果関係の形が違います。

ロジカルシンキングが「AだからB、BだからC」と一方向に論理を積み上げるのに対し、システム思考は「AがBに影響し、BがCを変え、それがめぐってAに戻る」という循環するループ構造を捉えます。直線で考えるか、循環で考えるか、と押さえると区別しやすくなります。

小さなチームや個人でも使えますか?大企業向けの手法に見えます。

使えます。個人でも、繰り返す失敗を氷山モデルで「出来事・パターン・構造」に分けて捉えるだけで打ち手が変わります。デザイン思考も、一人のユーザーに丁寧に話を聞く共感の一歩から始められます。大掛かりなワークショップは必須ではありません。

どちらか片方だけ身につければ十分ではないですか?

片方でも価値はありますが、得意領域が正反対なので、片方だけだと苦手な課題で手詰まりになります。構造に強いシステム思考は「人の本音」を取りこぼしやすく、人に強いデザイン思考は「全体の副作用」を見落としやすい。だからこそ、起点を選べることに意味があります。

まとめ

システム思考とデザイン思考は、「構造から入るか、人から入るか」という出発点が正反対のフレームです。違いを暗記するより、目の前の課題が「すでにある問題を解くもの」か「これから価値を生むもの」かを見極め、前者ならシステム思考、後者ならデザイン思考を起点に選ぶ。そして起点を選んだら、工程ごとに主役を切り替え、最後にもう一度システム思考で全体へ戻る。この「起点を選ぶ→工程で役割分担する→全体で検証する」という往復こそが、二つを最も効果的に使う方法です。

明日からの一歩としては、いま抱えている課題を一つ思い浮かべ、それが「再発する問題(構造起点)」なのか「まだ見えない価値(共感起点)」なのかを仕分けてみてください。起点さえ正しく選べれば、あとは工程をたどるだけです。この往復ができれば、「組み合わせたのに形骸化する」という最もありがちな失敗は、かなり避けられます。

ビジネス思考法全体の中での位置づけや、他の型との使い分けを整理したい方は、関連記事『ビジネス思考法とは?』もあわせてご覧ください。

思考法の使い分けをさらに深めるための関連記事

システム思考とデザイン思考の使い分けが見えてくると、次は他の思考法との組み合わせや切り替えが気になります。判断の引き出しを増やす関連記事をまとめました。

タイトルとURLをコピーしました