デザイン思考についてみんな難しく考えすぎじゃないの？って話
どうもこんにちは。EDP（Engineering Design Project）を語るうえでは必要不可欠（ではない）な男、2016年度受講生の奥出です。
2016年度に受講生として、2017年度にはTeaching AssistantとしてEDPに参加してた僕ですが、社会人として約1年働いてみたら「あれ、これって実はEDPで習ったデザインプロセスとそっくりじゃない？おやおや？」と感じることが多くありました。さらに、実務の中でデザインプロセスを踏んでみると、「あぁ、あのとき教えてもらったことってこういうことだったのか」と自分の中で理解が深まってみたりも。
そこで、自分の考えを整理するために「いろいろ難しいことあるけど、デザインプロセスって要するにこういうことかな？」と勝手に解釈して記事を書いてみたのがこれってわけです。
※本記事ではEDP用語的に使用される言葉もあるため、詳しく知りたいという方は「エンジニアのためのデザイン思考入門」をお読みすることをオススメします。ちなみに詳しく知りたくなくても読んでみることをオススメしてます。
デザインプロセスってなんだっけ？
東工大EDPではスタンフォード大学d.schoolの講義を参考に、下記の内容で説明される5stepsと呼ばれるデザインプロセスの紹介をしています。
1.Emphasize
2.Define
3.Ideate
4.Prototype
5.Test
要するに「ユーザーニーズを自分事として考えられるまで深く洞察して、早めにモノ作って仮説検証しようや！」ってことだと思います。
EDPでは各パートでテンプレートを用意しながら「顧客のインサイトを掘り出そう！」「”How might we ~?”という形で問いを立ててアイデアを出していこう！」と講義を進めるわけです（テンプレートについては本でご確認を）。
デザインプロセスもこうやって言葉にしてみると全然当たり前のことを言ってるように感じるんですよね。
デザイン思考って要するに何をしているのか？
サクッと説明してみたデザインプロセスですが、東工大EDPでは各パートで受講者たちがどんどんと罠にはまっていきます。
（この辺の話は「デザイン思考を学んでいるときに陥る罠」「デザイン思考を学んでいるときに陥る罠 その2」もご参考にいただければと。）
ここからは各パートについて、「みんなこんなことしがちだよね」「でも要するにこういうことだよね」と考察をしていきたいと思います。
Emphasize — Define
ここのパート、めちゃくちゃ苦労しますよね。しかもここで躓くと後の工程にもどんどん響くこともあり、良いプロダクトができるかどうかってここで9割くらい決まるんじゃないかなってくらい大事なパートでもあります。
みんなが何で苦労するかって、ここで急に「解決に値する問題点」を挙げようとして、それが見つからずに詰まるといった場面が多くみられます。
だって現場を見てみたら誰も何も困っていないように見えたりするんですもん。え、やることないじゃん…って思っちゃうんです。
でも本当にそれがこのパートでやりたいことでしょうか？
下記に、僕なりに考えたこのパートで気にするべきことを2つに分けて書いてみました。
（１）現場を見て初めて知った気づきを手に入れる
現場訪問で見つけるべきは、問題点ではなく「実際に行ってみるまで知らなかったことって何？」って点でしかないと思うのです。
新たな気づきだけピックアップしてみてください。多くの人が知らない真実がそこには隠されています。
（あくまで自論ですが、ここでの気づきは別に困りごとではなくてもいいように思います。より良い体験を提供できればいいだけで、現時点で困っていることのみに対応する必要はないわけで。）
（２）なんで？自分だったら？って考える
現場に行かないと想像もできないような気づきって、自分だったら別のやり方を取ってしまうような不思議な行動だったりすることが多いと思います。そうしたら次はこう考えてみましょう。
「なんでそんなことが起きてるんだろう？自分が同じ立場だったらどうしてるかな？」
自分だったらこうするのになぁ。なんでしないんだろうなぁと考えながら仮説を立ててみてください。自分事にして考えてみた瞬間にユーザー理解が一歩先に進みます。（もちろん、「自分だったらどうする？」と自然と考えられるレベルまでの情報を集めることが前提なのは言うまでもありません。）
そこまで整理できたら想定ユーザーにまた会いに行ってみましょう。
「なんでこんなことしてるんですか？ こっちのやり方はしないんですか？それってなんでですか？」
としつこくしつこく（怒られない程度に）「なんで？」と聞き続けてみましょう。この仮説検証が進むと現場でしか知れない重要な真実が浮き彫りになるはずです。
さてさて、ぐだぐだ長く書いてしまったので、一旦ここまでをサマってみましょう。
- 最初の現場訪問では「現場に行かないと知れなかったことは何か？」だけ考えようね
- 新たな気づきに対して「自分だったらどういう行動するか？」を考えてみようね
- 実際の行動と、自分だったらどうする？の間にあるギャップから重要な真実が見つかったりするよ
Ideate
（３）不思議な行動について抽象化してみる
Ideateは大喜利になりやすいですよね。突飛なとこからアイデア出せば思いがけない発想が出る気がして…
当たり前じゃない考え方をしようと無理した結果、インタビューの話から離れたところで急にアイデア出しが進んで、結局グループで何について話していたか忘れてしまう。結果として現場からは共感を得られないアウトプットが出てきてしまうというのがよく見る光景。
どうしてわざわざ現場に行ったのにその話を無視してしまうの。無理に話を飛躍させる必要はないのに…
ここで無理に突飛なことを考えようと気張る必要はないはずです。だって不思議なことは（２）までで出てきてるはずですから。
まずは（２）までで見つけた不思議な行動について、
「○○（Who）は××（Why）するために～～（What・How）をしている」
みたいな形に落とし込んでみましょう。そうすると、行動の目的が整理されて見えてくるはずです。
ここで「この目的の達成方法として～～という行動は本当に最適か？」と感じたらそこでクエスチョン。～～には一通りの方法しか入ることはできないでしょうか？
～～にあてはめられるアイデアをどんどん書き出してみましょう。それがプロダクトの種になっていきます。
要するに…
- 想定ユーザーの不思議な行動について、目的レベルだけ取り出してみようね。
- 目的の達成方法を複数考えてみようね。
Prototype — Test
（４）ユーザーの反応を確かめ続けよう
ここのパートで大事なことは、テストを多くこなすことです。
しかし、ここでEDPでよくあるのが下記の二つのパターン。
- なかなかプロトタイピングに進まない
- 「このプロダクトでいっぱいテストしてきました！！」とフィードバックを反映させないままただテストを繰り返す
1はなんとか手を動かしてもらうしかないにせよ、2のような状態で「結局ユーザーテストをアイデアに活かす方法がわからないです」ってパターンが結構厄介。行動はしてる分、何がダメか見えづらい。
でも、テストってただ多くこなせば良いというわけではないはずです。
なんでテストするの？って、あくまでテストはユーザーが触らないと気づかない新たな発見を見出して、プロダクトを改良するためでしかないと思うのです。ユーザーの意見にはどうやって答えられるか？と思考して、その仮説を高速で検証していくしかないのです。
2のような行動をしているとき、プロトタイプを改良していこうという思考が持てていないのではないでしょうか？
恐らく「このプロダクトを良いと思ってくれる人がどこかにいるはずだ」
と賛同者を見つけ出すことが目的になりがちです。
あと、テストをしているときによく聞く発言として、
「このプロダクトはユーザーに不評だったのでボツにしました」
というやつ。もう一歩「なんでダメだったのか？何が改善されれば良かったのか？」と考えて改良余地を探してみてください。考えてみたけど結局ダメだったというのもよくありますが。
Prototype — Testを進めるときには、「正解はユーザーの中にしかない」と考えて、自分たちでプロダクトの候補を無理に絞らず、いくつかのプロダクトのテストを同時に回してみましょう。
- 複数のダーティプロトタイプをユーザーに見せて、こちらの意図がユーザーに伝わるプロダクトを選別する
- 選別されたプロダクトを、フィードバックを反映させて動くものへと実装し、実際に触ってもらいながらテストをする
- 評判が良かったものに絞り込み、フィードバックを基にさらに実装を細部まで進め、ユーザーテストを行う
私は普段の仕事の中でECサイトの商品企画を担当しており、デザイナーとともに商品ページの作成をする機会もあるのですが、そのときも複数のアイデアをまずは絵で用意し、数人に「このページみたときに、最初にどういう操作ができることを期待しますか？そのためにどのような操作を行えばいいと思いますか？」という質問をし、そのフィードバックを反映しながら動くものとして実装してまた触ってもらう、そのフィードバックを基に…というようなテスト手順を踏むことがあります。
最終プロダクトが実装までにいくつのバージョンでテストしたか？（フィードバックを基に何回アップデートしたか）を考えてテストを回してみるといいかもしれませんね。
要するに…
- テストの場では複数のプロトタイプの比較検証をしようね
- 同じバージョンで多くの人にテストをやらなくてもいいから、フィードバックを反映して作り直すサイクルを早く回そうね
最後に
さて、ここまで偉そうにまとめてみましたが、EDPを受講されたことがある方、本を読んでくださった方などは「先生方がいつも言ってることじゃない？」って思うのかもしれません。多分ほとんどがその通りです。
それでも多くの東工大生が同じようなところで躓く（例に漏れなく僕も同じようなことをしてました）のが現状でもあったり。躓いたときに「あのときどうしたらもっと上手くできたんだろうなぁ」なんて整理してこなかったので、今後に役立てばと思い文章としてまとめてみました。
まだまだ陥りやすい罠はたくさんありますが（ユーザー体験で語る時間軸が点。使う瞬間にしか注目していない、既存の解決方法に目を向けていない など）まずはプロセスごとの理解だけで筆をおかせていただきます。
どこかでデザイン思考について気づきを得られたらまた自分のための整理として記事にまとめてみようかと思うのでまたいつの日か。
