デザイン思考の授業内容を読んでデザイン思考を3分で分かった気になれる(...はずがない)

Masahiro Watanabe
Feb 22, 2017 · 7 min read

デザイン思考の素人が9ヵ月間の授業で学んだことを元に、何も知らない人に「デザイン思考とは何か」を分かった気にさせようという無謀な試みです。

真面目に知りたい人は、 IDEOの本イマドキのデザイン思考事情 などを読んでください。

授業の前提

チーム

各チーム概ね次のようなチーム構成だったと思います。

  • 東工大の学生: 2~3人
  • 美術の専門家(美大、藝大、プロのアーティスト): 1人
  • ソフトウェアエンジニア(社会人): 1人

テーマ

いくつかテーマがあり、その中からチームでやりたいものを選びます。自分たちは、次のテーマを選びました。

富士スピードウェイへ向かう自動車愛好家の旅行体験を再デザインせよ

こんなバクッとした課題で、とにかく何かを新しいものを作れというものでした。

デザイン思考のプロセスの概観

デザイン思考のプロセスは、 6角形の5つのブロックでよく説明されます。順序は一応ありますが、違和感があれば、いつでもどこまでも戻ってやり直します。

  • 共感(Empathize)
  • 問題定義(Define)
  • 発想(Ideate)
  • プロトタイプ(Prototype)
  • テスト(Test)

共感(Empathize)

「ユーザのこと知らずしてユーザの課題を解決できるはずがない」、と正論を言われ、否応なしにユーザに聞きに行きます。2週間でチームで10~15人に聞くという課題を出されました。

そこでまず、身近にいる車好きな人(出来ればサーキットに行ったことがある人)、旅行好きの人に話を聞きました。インタビューは、聞く人、観察する人、メモを取る人と分担できるように、複数人で行うのが望ましいのですが、自チームでは時間的な制約のため、各々が1人で3人程度に聞きました。

その後、テーマにある富士スピードウェイにも行き、ドリフトをしに来ている人たちに話も聞きました。

自分は車の知識も興味もなかったので、車好きな人の考えることを色々聞けて楽しかったのですが、その程度であるため「インサイト」と呼ばれる「ユーザすら気づいていないこと」に気づけるわけもなく、結果的に苦労をしました。

問題定義(Define)

ユーザすら気づかなかったこと」を見出す、「ここがデザイン思考におけるポイント」と勝手に思っているステップです。

KJ法カスタマージャーニーマップタテマエメソッド を駆使して、「インサイト」ならびに「Point of View(PoV)」を探ります。

Point of View(タテマエメソッド)のテンプレートは次のようなものです。

[状況]にある[ユーザー]は、
[行動]をしている or する必要がある。
なぜなら[タテマエ]だからだ。
とはいえ、本当は[インサイト]である。

我々のPoint of Viewは、次のようなものとなりました。

自動車愛好家は、
自分一人で運転に没頭したい。
車をこよなく愛しているからだ。
とはいえ、仲間とも走りたい。

一言で言えば、「自動車愛好家は、寂しがり屋の一人好き」なんだ、と定義しました。矛盾を帯びているのがポイントです。

実のところ、サーキットで聞いた人たちは全員「一人で来る」と言っていました。自分で運転したい、サーキットに興味を持つ人が身近にいない、一般の人が同乗するのに快適とは言えない(例. エンジン音が大きい、シートが狭い)、自動車愛好家の住んでいる場所がバラバラ、などの理由からです。

それにも関わらず、「本当はみんなで行きたいはずだ」とユーザすら思っていなさそうなことを多少強引に見つけました。正確には「見つけたことにしました」。

実際にヒアリングしたユーザがそう思っているかは、プロトタイプを持っていって確かめれば良いので、重要ではないのです。

発想(Ideate)

ここでは、How Might We Question(HMW) と呼ばれる

我々はどうすれば、… をできるだろうか?

という問いを考え、それに対する解決策を考えます。

我々のグループでは、

どうすれば、「簡潔」に自動車愛好家同士のコミュニケーションを実現できるだろうか?

という問いを考えました。

「自動車愛好家は、走りに没頭したいけど、時にはコミュニケーションをとりたい(はずだ)。そういう時に使いたいと思うソリューションは何か?」という疑問から来たものです。

これに対して、次のようなソリューション「pit」を考え、プロトタイプを作成しました。

プロトタイプ(Prototype)

pitは「グループで話したい時に、ボタンを押しながら話すと、その声がグループ全員に伝わる」というソリューションです。無線トランシーバーと同じ機能ですが、ボタンとスマートフォンというシンプルな構成で実現しています。

作成したプロトタイプpit。こんな見栄えでも、ボタンを車のハンドルにつけてスマートフォンと共に使うと、きちんと他の車に声が届きます。

実際は、pitボタン、スマートフォン上で動作するpitアプリケーションの他に、裏でインターネット上の通知サービスを使っています。

ボタンを押すとpitアプリケーションが声の録音を始め、ボタンを離すと録音した声を通知サービスに飛ばします。通知サービスは、登録された音声を他の人のpitアプリケーションへ送り、スマートフォンから音声が再生されます。

結果として次のとおり「簡潔」に自動車愛好家同士のコミュニケーションを実現しています。

  • 車の運転中を考慮した「操作の簡単さ」: ボタンを押して話すという簡単な操作
  • 自動車愛好家の車装備に対するこだわりを満たす「デザインのシンプルさ」:ボタン一つをハンドルにつけるだけのシンプルさ
  • コミュニケーション対象者が全員装備する必要があるので、多くの人が「簡単に試せる」こと: 比較的安価なボタン(flic.io)や、既存のスマートフォンの機能(マイク、スピーカー、インターネット通信機能)、既存の通知サービス(firebase)を使うことで、安価でユーザに提供可能

テスト(Test)

作ったプロトタイプを実際に車につけて試し、運転中にグループの声が聞こえることを確認しました。次はユーザテストです。

次のような、急な意思決定を要するユースケースで有用だと考えていました。

  • 渋滞時の進路変更
  • ガス欠
  • トイレ

残念ながら、時間の都合上、自動車愛好家に実際に使ってもらい、有用性を確かめたり、我々が考えもしなかった新たな使い道などのフィードバックをもらうまでには至りませんでした。

本来は、フィードバックから、新たなインサイトを見い出し、さらに改良(もしくは捨てる)を続けて行きます。


実際のところは...

と、ここまで書いてみると、教科書に書いてあるような流れで、完成したかのように見えますが、実際は正反対です。授業終盤では、思いついたソリューションからPoVやHMWを考えたりすることが多々あります。慣れから、ソリューション、PoV、HMWの間を自由に動ける(どこから始めても他を埋められる)ようになります。どの順番で始めようと問題ではありません。結局は、ユーザに対して、そのソリューションが機能(work)するかが全てだからです。

半年間の授業で、pitのアイデアからプロトタイプ完成までに要した期間はわずか2週間でした。それ以外の期間、長い紆余曲折を経てこのソリューションにたどり着いたのです。その話は、 デザイン思考の授業で踊り続けた「あいまいさとのダンス」に続きます。

東京工業大学エンジニアリングデザインプロジェクト

Solve various problems in society through engineering…

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store