SDM(System Design and Management)について

（この記事はtwitter @Sydecas.Inc での連続ツイートまとめです。一部誤字脱字を修正しています)

僕の専門は、デザイン思考でもシステムズエンジニアリングでもなくてシステム×デザイン思考。学位も「修士（システムデザイン・マネジメント）」だもの。

どこからがシステム思考でどこからがデザイン思考かというのは、自分で考えるときあまり意識していない。
対象や問題に感心を持つ、というのはこれらに限らずあらゆる思考の必要条件なわけだが、問題を定義していく方法にもシステム思考的な方法とデザイン思考的な方法がある

システム思考的な問題定義とは、例えば因果ループ（システムダイナミクスのツール）で原因と結果の関係で要素を可視化していって、どのレバレッジポイントを「押せば効くか」をかんがえていく

デザイン思考的な問題定義って、インタビューや直接体験してみて感じたことを可視化していく。

組み立てもそう。さくっとデザイン思考的に組み立てたほうが早いこともあれば、システムズエンジニアリングの手法にがっつり乗っていく手もある。

（ここで空白の11日間…）

あー、すっかり説明を忘れていたが、「システム思考」って、いろんな定義がる。広義のシステム思考の下に、「システムズエンジニアリング」と「（因果ループであらわされる狭義の）システム思考」がある。

システムズエンジニアリングやシステム思考についての詳細は、また別のときに書くとして、「WHY/HOW/WHATを考える」と「ITERATIONする」というのは共通。前者については、システムズエンジニアリング的にいうと「WHY/WHAT/HOW」。

これ、わざとシネックのゴールデンサークルに則って「WHY/HOW/WHAT」とプレゼンしたら、この前教授に怒られた。

ま、意味は同じ。つまり、目的だったり本質的な価値（お役立ち度）だったり、と方法論、そして方法（もしくは手段、リソースと言ってもいい）のレイヤーをごっちゃにするなと。これって普段からめちゃくちゃ重要な考え方。

で、明確な目的があるということは、「問題の定義」がきちんとされているということでもある。ちょっとビジネスかじった人って、この問題定義を即「計測可能な市場規模」に結びつけてしまいがちだが、そこを焦ってはいけない。問題のすべてを解決する必要はない。

その辺はシステムライフサイクルとか因果ループのレバレッジポイントだとかの考え方に踏み込むし、最近はインクルーシブデザインの考え方に感化されてきた。ので、またそのうち書こうかな。