#author("2023-04-09T16:47:45+09:00;2023-04-09T16:43:22+09:00","default:inoue.ko","inoue.ko") #author("2024-06-26T12:30:31+09:00;2023-04-09T16:47:45+09:00","default:inoue.ko","inoue.ko") *デザイン思考 ~ **概説 デザイン思考｜Design Thinking という言葉は1990年代に[[IDEO>Google:IDEO]]のデビッド・M・ケリー、ティム・ブラウンらが提唱したもので、デザイナーの思考のプロセスを体系的に言い表したものです。 [[GoogleImage:デザイン思考]] //https://commons.wikimedia.org/wiki/File:Design_thinking.png 何か画期的な思考法かと思われがちですが、同様の思考法は、それ以外の分野、例えばソフトウエア開発、実験研究、野外調査など、あらゆる科学的な思考に見られるもので、特段新しいというわけではなく、またデザインの演習を体験したみなさんにとっては「あたりまえ」の思考方法と言えますが、「デザイン思考」という、何やらビジネスマンにウケそうな「言葉」と、それをわかりやすい図に「視覚化」したことが功を奏したようで、とても斬新なものとして世間を賑わせているようです((さて、この「デザイン思考」、これ、そんなに声高に言わなくても、例えば「みんなで遊ぼう」とか、何か事を起こそうとした場合には、子供でもふつうそんなふうに考えるものだと思うのですが、どうやら最近の人たちは「みんなで遊ぶ」という体験が乏しいのか、あるいは、教育の弊害で、教科書的な説明がないと不安になるのか、「こういう順番で進めましょう」という「箇条書きと図解」がなされたことがみんなのツボにはまったようです。))。 何か画期的な思考法かと思われがちですが、同様の思考法は、それ以外の分野、例えばソフトウエア開発、実験研究、野外調査など、あらゆる科学的な思考に見られるものです。 //特段新しいというわけではなく、またデザインの演習を体験したみなさんにとっては「あたりまえ」の思考方法と言えますが、「デザイン思考」という、何やらビジネスマンにウケそうな「言葉」と、それをわかりやすい図に「視覚化」したことが功を奏したようで、とても斬新なものとして世間を賑わせているようです((さて、この「デザイン思考」、これ、そんなに声高に言わなくても、例えば「みんなで遊ぼう」とか、何か事を起こそうとした場合には、子供でもふつうそんなふうに考えるものだと思うのですが、どうやら最近の人たちは「みんなで遊ぶ」という体験が乏しいのか、あるいは、教育の弊害で、教科書的な説明がないと不安になるのか、「こういう順番で進めましょう」という「箇条書きと図解」がなされたことがみんなのツボにはまったようです。))。 ともあれ、おかげで、デザインというものについての世間一般の見方が変わったことは喜ばしいことです。以後、デザインとは、単に綺麗なカタチをつくればいいというような表面的なものではなく、モノ・コトの問題を正しく捉え、総合的な視点で試行錯誤を繰り返しながらそれを解決していく作業であるということが、多くの人に理解されるようになりました。 //ともあれ、おかげで、デザインというものについての世間一般の見方が変わったことは喜ばしいことです。以後、デザインとは、単に綺麗なカタチをつくればいいというような表面的なものではなく、モノ・コトの問題を正しく捉え、総合的な視点で試行錯誤を繰り返しながらそれを解決していく作業であるということが、多くの人に理解されるようになりました。 ~ ~ **デザイン思考のプロセス デザイン思考を説明する文献やWebサイトは数多く存在します。 まずは、それを図解で確認しましょう。 ＞ [[GoogleImage:デザイン思考]] 以下、様々なキーワードで解説されたデザイン思考を紹介します。 いずれも同様のフレームで描かれています。 ~ ***一般的なモデル -Empathize：共感 -Define：定義 -Ideate：アイデア創出 -Prototyping：プロトタイピング -Test：検証 -Implement：実装 ~ ***IDEO https://designthinking.ideo.com/ '''Design thinking is a human-centered approach to innovation that draws from the designer's toolkit to integrate the needs of people, the possibilities of technology, and the requirements for business success.''' — Tim Brown, chair of IDEO ~ ***Google https://designsprintkit.withgoogle.com/ -Google Design Sprints (I) --Understand --Define --Diverge --Decide --Prototype --Validate -Google Design Sprints (II) --Understand --Diverge --Decide --Prototype --Validate ~ ***デザイン思考研究所 https://designthinking.eireneuniversity.org/ -イノベーションを起こすための３ステップ &small(人間中心デザイン思考：Human-Centered Design Thinking〜 by IDEO.org); --HEAR：理解 --CREATE：創造 --実践：DELIVER -５つのフェーズ --Discover：発見フェーズ --Specify：詳細化フェーズ --Explore：探索フェーズ --Experiment：実験フェーズ --Develop：展開フェーズ -デザイン思考のポケットガイドより --深いニーズを知る : 人々の気持ちに共感す ることで、彼らが本当に求めているものは何かを明らかにする --問題点とゴールを決める : 人々の欲求が満たされていない現状を明らかにし、どのような状態を目指すべきかを定める --アイデアを生み出す : 理想の状態にたどりつくことを支援するアイデアを生み出す --アイデアを形にする : 生み出したアイデアを実際に形にすることで、 うまくいきそうな部分を確認したりさらにアイデアを得るきっかけする --アイデア を評価する : 本当に目的を達成できるのかどうか、ユーザーの声を元にアイデアを検証する ~ ***その他のパターン 以下、いずれも同様のパターンですが・・・ -understand：理解する --empathize：共感する --define：問題定義する -explore：探求する --ideate：創造する --prototype：プロトタイプを作る -materialize：具現化する --test：テストする --implement：実装する ~ -1) 調査（要求分析） ユーザーの現実の行動を把握し、そのニーズを知る -2) コンセプトメイキング -3) ビジュアライゼーション -4) 評価 成果物をユーザーが利用する時の問題点を把握する -5) 3)-4)の繰り返しで問題を極限まで除去 ~ -1) 問題を発見し、「何が問題なのか？」を明らかにする -2) 複数の問題解決策を起案する -3) 試作を用いて、それぞれの案を評価する -4) 評価の結果にもとづいて問題解決策を再構築する -5) 3)-4)の繰り返しで問題を極限まで除去する ~ ~ **プロセスの概要 以下、一般的なプロセスにおける個々のキーワードについて概説します。 ~ ***共感（__[[DesignThinking/Empathize]]__） まず「現場」の調査を行い、ユーザー（現地の方）が何を感じるかについて、知識を深めます。例えば地域デザインでは、現地のさまざまな人たちと会話し、今何が問題なのか、何が求められているのかを体験的に把握します。 ここで重要なことは、その問題や要望にみんなが「共感」できるかということです。例えば、「観光客を呼び込みたい」という人と「静かに暮らしたい」という人が分裂している状態では、単純に問題が設定できません。多数決によって「観光客を呼ぶために、◯◯を設置しましょう」では、ダメなのです。この課題設定は「静かに暮らしたい」という人にとって共感が得られません。 実は、今世の中にある「問題」の大半がこのレベルで頓挫しています。多数派（あるいは、力をもつ人たち）の要望に沿ってルールをつくって実行する・・というのが議会と行政のやりかたですが、これはみんなの共感が得られないので、結果的に別の問題を生み出すことになります。 問題そのものに共感が得られない事象については、全体を同じルールでデザインするのではなく「棲み分け」を考える・・という選択が賢明です。つまり、余計なものは作らない。 文化は多様で価値観も様々です。人間集団は大きくなると、うまくいきません。基本的に、デザイン行為は問題意識や希望を共有できる小さな規模の集団を対象に実践するのが賢明だと感じています。 Think Globally, Act Locally. ~ ***定義（__[[DesignThinking/Define]]__） 共感が得られた問題・要望について、これらを整理し、何が問題なのか、何をすべきなのか、問題と課題を明確にします。 ちなみに、問題(problem)と課題(issue)は違います。問題とは、あるべき姿と現状のギャップで、そのギャップを埋める方法が課題です。 例えば 「村が孤立して住民が困っている」というのは「問題」。 「物資を届ける」「住民を移動させる」「橋を架ける」などは「課題」。 一般にひとつの「問題」に対して、いくつもの「課題」が設定できます。 ~ ***アイデア創出（__[[DesignThinking/Ideate]]__） まずブレインストーミングなどを行って、様々なアイデアを出します。このとき、批判はいけません。どんな荒唐無稽なアイデアでも、そこから突破口が見出せることもあります。自由に発想することが大切です。 ~ ***プロトタイピング（__[[DesignThinking/Prototyping]]__） いくつかのアイデアを、実際にさわれるカタチ、あるいは運用できる状態にします。プロダクトの場合は模型、実寸模型、Webサイトなどの場合は、内容はダミーで、インターフェイスを中心にサンプルをつくります。 ~ ***検証（__[[DesignThinking/Test]]__） プロトタイプをユーザー（現地の方）に試してもらいます。プロトタイプは、即OKとなることは稀です。そこで生じる問題を洗い出し、プロトタイプに修正を加える・・この作業をくりかえします。 ~ ***実装（__[[DesignThinking/Implement]]__） 試行錯誤を重ねたプロトタイプを現場に実装します。これで終わりではありません。その後の経緯を追跡し、運用後に新たな問題が生じていないか注意深く見守る必要があります。その結果は次のプロジェクトに応用されることになります。 ~ ~ **APPENDIX ***デザイン思考とPDCA デザイン思考の図式とよく似たものに __[[PDCA>GoogleImage:PDCA]]__の図式があります。PDCA は、事業活動における生産管理や品質管理などの管理業務を円滑に進めるための手法で、いわば工場でモノをつくる場合に適用されるものです。昨今は、これをそのまま人と社会の問題解決にまで持ち込もうとする発想が横行していて、個人的には不快感を感じています。 人も社会も「製品」ではありません。人や社会に関わるデザインの評価を「工業製品」と同様の方法で行うのは無理がある。この違いを私なりの視点でメモします。 ~ ***PDCA -いきなり Plan から入る。つまり、プロジェクトを実行することがはじめから決まっていて、課題（またその目的や方針）は、トップから（外部から）与えられます。課題自体がトップの単なる思いつきだったら現場はどうなるのでしょう？この国のあるあるです。問題自体を疑う余地が与えられていないというのは、健全とは思えません。 -Check では、主に数値目標の達成度が検証されます。良品率が上がっているか（不良品率が下がっているか）が問われ、結果、プロジェクトの現場に指示されるのは、責任追及、犯人捜し、そしてこの数字を上げるための方策を考えよ・・ということになる。 点数を上げるための方法は様々で、それが競争原理とセットになっているプロジェクトも多くあります。現場は「問題をなくす」という本来の目的からはずれて、とにかく点数を上げる・・ということ自体を目標にしてしまう。例えば、試験の平均点を上げるためであれば、本質的な理解を後回しにして、パターンで学習させても結果は出ます。歴史上の出来事で、年号を語呂合わせで覚えるとか、「はい、これ試験に出るから覚えとけ！」的な・・・それって意味あるのでしょうか？ PDCAの思考回路では、そうした本質から外れた対策が横行することが多々生じます。 競争原理（点数主義）は「情報の共有」を阻害します。結果、人と人のスキマで大きなクラッシュが起こる。現在、ありこちで起こっている「想定外の事故」の原因は、この数値目標と競争原理にあるように思えてなりません。重要なことは「問題をなくす」ことであって、そのためには、コソコソ競争するではなく、オープンな場で情報を共有することが必要であると思います。 -哲学なきPDCAの導入がなされた現場では、誰も読まない計画書（Plan）と報告書（Check）の作成に多大な時間を割く傾向があります。結果、Do と Action が手薄になる。これを ''PdCa'' と書いたりします。 ~ ***デザイン思考 -はじめに「共感」がある。プロジェクトに着手する前段として、そもそも理想は共有されているのか？ みんなが共感できる取り組みなのか? それがはじめに問われる・・ということがプロジェクトを健全なものにしています。 -目標（ゴール）は「ゆるやかに」設定する 目標を具体的に決めすぎると、ブレイクスルーが起きにくくなります。ブレインストーミングやプロトタイピング、テストの過程で、斬新なアイデア、あるいは当該プロジェクトと無関係のアイデアが生まれる可能性もあるので、ここはあえて「ゆるく」しておくことが大切です。 &small(革新的なアイデアというのは、ニーズからは生まれません。例えば、SONY のWALKMAN は、当時の井深大の“個人的な所望"と、これがビッグヒットに繋がると直感した盛田昭夫の"直感"から生まれた商品です。ニーズはないと思われたものでも、それが世にでることで新たな文化が生まれ、結果的に新なニーズが生まれることもあるのです。); -デザイン思考における「検証」では、「数値目標が達成されたか」ではなく「問題が解消されているか」に重きが置かれています。 //「お客様満足度」のようなどうにでもなる数値を向上させることに一喜一憂せず、「問題がなければそれで良し、じゃ、次いきましょう」。それぐらいでいいのではないかと思います。 ~ #navi() ~ ~