デザイン思考を学んでいるときに陥る罠
「東京工業大学エンジニアリングデザインプロジェクト」にソフトウェアの支援者として参加している渡辺です。「自分のような凡人でも新しいものを創る可能性を高められるのでは?」、とデザイン思考に興味を持ち、参加させていただきました。
この授業で多くのことを学んでいますが、その学びの中で陥りがちな罠のようなもの(ソフトウェア業界で言うところのアンチパターン)に実際にいつくもハマったので、ここでは気づいた点について書いてみたいと思います。
1. 作らないで議論し過ぎる
あーでもない、こーでもないと言って話が行き詰まり、いつまで経っても「これじゃない感」に苛まれ、何も進まないパターンです。とにかく、「作る → 人に見てもらう → それを直す(か捨てる)」のサイクルでバンバン回さないと、他のグループから取り残されていきます。
2. アイデアに固執する
ユーザなどから指摘を受けても、自分たちのアイデアにしがみつく(defenceする)パターンです。大域的な視点に立てず、 プロトタイプであそぼう の「P2: Darkhorse Prototype 🐴」を作っても、無意識のうちに本命のアイデア中心の状況になってしまったりします。
「このソリューションで、当初の課題を解決しているのか?、本当にユーザーがハッピーになるのか?」など、定期的に立ち止まって考える必要があると思います。
最後は「自分たちの思い」を信じて突き進む必要がありますが、序盤ではコメントを真摯に受け止めることも重要だと思います。
経験的に、良い課題を見つけるグループは、自分たちのアイデアを必要に応じて躊躇無く捨て、大きく方向変換しているグループに多いと思います。
3. ソリューションが「普通に便利」で万人に受け入れられてしまう
課題の分野に詳しくない人でも、初めて聞いたときに「ふーん、まぁ良さそうだね」的な感じで目新しさがないパターンです。既存製品の改良であったり、しばらくしたら企業が出してきそうなもので、小さくまとまってしまった状況です。
逆説のスタートアップ思考 でも述べられていますが、初見のユーザは一見不合理で違和感を覚えるくらいのアイデアの方が、経験的によいアイデアが多い気がします。授業ではこれを「ざわざわ感」と呼び、大切にしています。
4. ソリューションが課題に対して間接的
課題 Zを解決したいのだけど、その原因が Yにありそうという見当をつけ、Yを解決するための ソリューションXを作成するパターンです。一見、 X → Y → Zとうまく最初の課題を解決できそうですが、X → Y や Y → Z が本当に成り立つのかの確認が必要で、経験的に難しいことが多いです。例えば、 Yの他に根本的な原因があったり、そもそも X → Yが機能しなかったりなどの場合があります。
まずは、直線的にソリューションを探すのが良い気がします。
罠に陥らないためには?
では、「結局どうするの?」という問には、「知らん」としか言いようがありません(自分たちも現在進行形でハマっているので)。個人的には、「とにかくユーザーに使ってもらって機能(work)しているかを確認する」ということしかないと思います。
経験豊富な先生方も所詮は一評論家(ユーザーではない立場)であるので、アドバイスを参考にしつつも、自分たちを信じながら、ユーザに当てては跳ね返されることを繰り返すのが一番だと思っています。
「今、<上に述べたような状況>に陥っているよ!」と先生方に毎回授業でアドバイスをしてもらいながら、この授業で多くのことを学んでいます!
