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

デザイン思考の素人が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週間でした。それ以外の期間、長い紆余曲折を経てこのソリューションにたどり着いたのです。その話は、 デザイン思考の授業で踊り続けた「あいまいさとのダンス」に続きます。