Merry Christmas！
エンタープライズ第一本部 業務変革ソリューション2部の倉内です！
本記事は 電通総研 Advent Calendar 2025 18日目の記事です！
17日目である昨日の記事は、クロスイノベーション本部 大岡叡さんの「【AWS資格】新卒1年目がAWS資格を全冠したので振り返る」でした！
新卒1年目でAWS全12資格を取得するまでの背景や、挑戦を通じて得られたこと・つらかったことを振り返った記事です。
新卒1年目で全冠…1つ上の先輩として負けていられないなと思いつつ、ただただ尊敬です。ぜひご一読ください！
さて、私は現在新卒2年目で、普段はエンジニアとして金融領域のソリューション開発に携わっています。
タイトルの通り、実は来年から働きながら大学院に通うことにしました。
今回はそこで学ぼうとしている「システム×デザイン思考」という考え方について書いてみます。なぜこれを学ぼうと思ったのか、そしてこの考え方がITエンジニアにとってどう役立ちそうか、自分なりに整理してみました。
なぜ大学院に行くのか
学部時代から、いつか大学院で研究したいという気持ちはありました。ただ、当時は「研究よりも社会実装に近いところでやりたい」という思いがあり、まずは就職する道を選びました。
では、なぜ今なのか。きっかけは「地方創生」への興味でした。
地方出身の人間として、学生時代から地域の課題に関心があり、社会人になってからもその思いは変わりませんでした。ただ、地方創生について調べたり、関わっている人の話を聞いたりする中で、壁にぶつかりました。
地方創生が複雑な問題であることは、誰もが知っていることだと思います。私自身もそれは理解していたつもりでした。しかし、「複雑だ」とわかっていることと、「その複雑さにどう向き合えばいいか」がわかっていることは、まったく別の話でした。
人口減少、産業の衰退、若者の流出、行政と民間の連携……。これらが互いに影響し合っていることは頭では理解していました。でも、「だから何をすればいいのか」となると、途端にわからなくなる。一つの課題に手を打とうとすると、別のところに影響が出る。関係者によって「何が問題か」の認識も違う。
エンジニアとして技術を学んできましたが、技術だけではこの複雑さを扱えないと感じました。
「複雑な問題を扱うための方法論が必要だ」
そう思って調べる中で出会ったのが「システム×デザイン思考」という考え方でした。
「難しい問題」と「複雑な問題」
この考え方を学ぶ中で、最初に腑に落ちたのが「難しい問題」と「複雑な問題」の違いです。
難しい問題というのは、たとえばアルゴリズムの実装やパフォーマンスチューニングのようなものです。専門知識が必要で、時間もかかりますが、正解があります。手順を踏めば解けます。再現性もあります。
一方、複雑な問題というのは、正解がありません。要素が多く、それぞれが影響し合っていて、一つを変えると別のところに影響が出る。しかも、関わる人によって「何が問題か」の認識が違っていたりします。
地方創生はまさにこれです。「若者が出ていくのが問題だ」という人もいれば、「仕事がないのが問題だ」という人もいる。「そもそも人口が減っても別にいいのでは」という意見もある。何を解決すべきかすら、合意を取るのが難しい。
ITの世界でも、似たような状況はあります。DX推進やレガシーシステムの刷新、組織をまたいだプロジェクトなどは、技術的な正解を出しても、それだけではうまくいかないことが多いと聞きます。
私たちエンジニアは、難しい問題を解く訓練を受けています。でも、複雑な問題には、別のアプローチが必要らしい。そのことに気づいたのが、最初の発見でした。
「システム思考」とは何か
では、複雑な問題にはどう向き合えばいいのか。その一つの答えが「システム思考」です。
システム思考とは、物事を個別の要素としてではなく、全体として捉える考え方です。要素と要素がどのように影響し合っているか、その関係性に注目します。
たとえば、地方の人口減少を考えてみます。
若者が都市部に出ていく。地元の働き手が減る。企業が撤退する。さらに仕事がなくなる。ますます若者が出ていく。
これは悪循環です。どこか一箇所を切り取って対処しても、構造が変わらなければ同じことが繰り返されます。「若者に残ってもらおう」と呼びかけても、仕事がなければ残れない。「企業を誘致しよう」としても、働き手がいなければ来てくれない。
システム思考では、こうした因果関係を図にして可視化します。これを「因果ループ図」と呼びます。図にすることで、どこに手を打てば全体が良くなるか、いわゆる「レバレッジポイント」が見えてきます。
たとえば、上の例で言えば、「リモートワーク可能な仕事を増やす」というのは一つのレバレッジポイントかもしれません。都市部の企業に勤めながら地方に住めるなら、「仕事がないから出ていく」という構造を変えられる可能性があります。
もちろん、これが正解かどうかはわかりません。でも、構造を可視化することで、「どこに手を打つと効果がありそうか」を議論できるようになります。
「デザイン思考」とは何か
一方、システム思考だけでは足りない部分もあります。
構造を分析することはできても、「そもそも何が問題なのか」を発見するのは得意ではありません。また、論理的に正しい解決策を導いても、それが人の心に響くとは限りません。
そこで出てくるのが、デザイン思考です。
デザイン思考は、人間を中心に置いた問題解決のアプローチです。まず現場に行き、人の話を聞き、観察する。言葉にならない困りごとや、本人も気づいていない潜在的なニーズを探る。そこから問題を定義し、解決策を考え、素早く形にして試す。
地方創生の文脈で言えば、「住民が本当は何に困っているのか」「行政の人は何を考えているのか」を、データや報告書ではなく、直接会って聞くことから始める。そういうアプローチです。
デザイン思考でよく使われるプロセスとして、「共感→問題定義→アイデア創出→プロトタイプ→テスト」という5つのステップがあります。いきなり解決策を考えるのではなく、まず相手の立場に立って共感することから始めるのが特徴です。
エンジニアの感覚からすると、少しふわっとした印象を受けるかもしれません。私も最初はそうでした。
でも、考えてみると、要件定義書に書かれていることが本当にユーザーの求めていることなのか、疑問に思った経験は誰にでもあるのではないでしょうか。
2つを組み合わせる
システム思考とデザイン思考。
この2つは、一見すると異なるアプローチに見えます。片方は構造を分析し、もう片方は人間に寄り添う。片方は全体を俯瞰し、もう片方は個人に深く入り込む。
でも、複雑な問題を解くには、両方が必要です。
デザイン思考で現場の声を集め、問題を発見・定義する。システム思考でその問題の構造を可視化し、どこに手を打つべきかを考える。
再びデザイン思考で解決策を発想し、プロトタイプを作る。そしてシステム思考で、その解決策が全体にどんな影響を与えるかを検証する。
この行き来が重要だと言われています。
システム思考の提唱者の一人であるピーター・センゲは、著書『学習する組織』の中で、全体（wholes）・相互関係・変化のパターンに目を向ける視点（システム思考）を組織学習の土台として示しています。実践面については、別著『The Dance of Change』の中で、現場に近い人々の小さな試行と対話の重要性を論じています。
またデザイン思考の公式フレームでは、問題の理解・定義を飛ばしてアイデアに走ると“誤った問題”を解きやすいと明確に示されています。
どちらか一方だけでは不十分で、両者を行き来することで、複雑な問題に対処できるようになる。これがシステム×デザイン思考の基本的な考え方です。
たとえば、地方創生で「移住促進」を考えるとします。
まず、デザイン思考で移住を検討している人や、実際に移住した人に話を聞く。すると、「仕事の不安」だけでなく、「子どもの教育」「医療へのアクセス」「地域コミュニティへの馴染みやすさ」など、さまざまな要素が出てくる。
次に、システム思考でそれらの要素の関係性を整理する。「教育環境が整うと、子育て世代が移住しやすくなる」「子育て世代が増えると、地域の活気が出る」「活気が出ると、さらに移住者が増える」といった好循環が見えてくるかもしれない。
そして、再びデザイン思考で「では、教育環境を整えるために何ができるか」を発想し、小さく試してみる。
正直なところ、私はまだこれを実践できているとは言えません。でも、この枠組みを知っているだけで、物事の見え方が少し変わってきた気がします。
エンジニアとの相性
この考え方を学んでいて思うのは、エンジニアは意外とこの思考法と相性がいいのではないか、ということです。
まず、システム思考について。私たちは日常的に、システムを設計しています。要素を分解し、関係性を定義し、全体として動くように組み立てる。コンポーネント間の依存関係を意識し、一箇所を変えたときの影響範囲を考える。これはまさにシステム思考そのものです。
また、デザイン思考について。私たちは「動くもの」を作れます。アイデアを形にして試すことができる。これはデザイン思考で言うプロトタイピングです。紙に書いた企画書ではなく、実際に触れるものを作って見せられるのは、エンジニアの大きな強みだと思います。
日々の業務でも、この考え方は使えそうです。
たとえば、プロジェクトで問題が起きたとき。「誰が悪い」という犯人探しではなく、「どういう構造がこの問題を生んでいるのか」と考える。因果ループ図を描いてみると、個人の努力ではどうにもならない構造的な問題が見えてくるかもしれません。
あるいは、新しい機能を開発するとき。要件定義書をそのまま実装するのではなく、「この機能を使う人は、本当は何がしたいのか」を考える。可能であれば、実際に使う人に話を聞いてみる。
つまり、必要なスキルの土台はすでに持っている。足りないのは、それを技術以外の領域にも適用するという発想なのかもしれません。
これから学ぶこと
来年から大学院でシステムエンジニアリング、デザインプロジェクト、システムダイナミクスなどを学ぶ予定です。座学だけでなく、実際のプロジェクトを通じて実践する機会もあると聞いています。
特に楽しみなのは、異なるバックグラウンドを持つ人たちと一緒に学べることです。エンジニアだけでなく、デザイナー、コンサルタント、行政職員、医療従事者など、さまざまな分野の社会人が集まると聞いています。
複雑な問題に取り組むには、多様な視点が必要です。自分とは違う考え方に触れることで、視野が広がることを期待しています。
おわりに
本記事では、私が大学院で学ぼうとしている「システム×デザイン思考」について、なぜ興味を持ったのかという背景も含めて書いてみました。
まだ学び始めたばかりで、偉そうなことは言えませんが、「技術だけでは解決できない問題が数多くある」ということに気づけたのは、自分にとって大きな一歩でした。
来年からは実際に大学院で学びながら、この思考法を実務にどう活かせるか試行錯誤していく予定です。学んだことや気づいたことは、本ブログで共有していければと思います。
この記事が、同じようなもやもやを感じているエンジニアの方にとって、何かのきっかけになれば幸いです。
さて、電通総研 Advent Calendar 2025もいよいよ明日が最終日！
明日の記事は、クロスイノベーション本部 宮原光さんの「AWS re:Invent2025 Keynote現地速報」です！
アドベントカレンダーのトリを飾るにふさわしい、現地からの熱気が伝わってくる記事になること間違いなしです！お楽しみに！
最後までお読みいただき、ありがとうございました。
それでは、よいクリスマスを。
執筆：@kurauchi.tatsuya
レビュー：@miyazaki.hirotoshi
（Shodoで執筆されました）
