＃13 ねじれを解く 【3．発想】
前回からの続きです．
以下の5つのプロセスの発想について書きます．
共感 Empathize
問題定義 Define
発想 Ideate
プロトタイプ Prototype
ユーザテスト Test
ユーザーに共感して得た潜在的なニーズ（インサイト）を解決するための方向性を決めるフェーズです．発想に関しては，デザイン思考だけでなく様々な分野で応用が利きそうな学びがたくさんありました．
発想の方法
いくつかの方法があります．チームで取り組む場合，個人で取り組む場合など用途によって分かれます．組み合わせて使っていました．
How Might We Question（HMWQ）
インサイトとプロダクトの間をつなぐフレームワークです．和訳すると「どうすれば私たちは～できそうか？」となります．これは，POVの後ろについてくるものなので毎回やっていました．
課題に対して以下の複数の視点で考えます．
良い面を伸ばす
悪い面を除去する
反対を考えてみる
前提を疑う
形容詞で考える
他のリソースを活用する
ニーズやコンテクストから連想する
課題に対して遊んでみる
現状を変更する
課題を分割する
引用元↓ （EDPのツールがまとまっています）
強制発想法
その名の通り，強制的にアイデアを出す方法です．以下の方法で進めます
①POVと一つのHMWQを決める．
②5分間で10枚のアイデアイラストを個人ワークで描く
③チームでシェアする
④再度個人ワークに戻って10枚描く
⑤「いいね！」と思った3つ～5つ程度選ぶ
正直ここまではできませんでしたが以下も推奨されていました．
⑥プロトタイプして、スキットまでやりきる
⑦本命、対抗、穴馬の3つのアイデアを作りこんでユーザーテスト
SCAMPER法をもちいてアイデアを出すと良いです．
「アイデアはある程度完成度が高くないと出しにくい」というチームの空気を壊してくれたのが良かったです．あまりアイデアを共有したがらない人でも短い時間に強制的に出さなければならないとなると，アイデアの質が落ちることは割り切れます．
「適当なアイデアでも良いからとにかく数をだそう」という空気感になりました．授業の規模では非現実的なアイデアやドラえもんの秘密道具的な突飛なアイデアもいくつか生まれました．
2ndラウンドを行うのがポイントで，1stで見たメンバーのアイデアをパクったり組み合わせたりすることで新たなアイデアが生まれました．
思考の書き出し
チームであまりやっている人はいませんでしたが，個人的にはこれが合っていました．多分自分は思考が浅く早いタイプなのだと思います．
とにかく思いついたことを次々に文字起こししていきます．自分の頭に3人の人を出現させて議論し合うようなイメージです．自分と，自分のことをなんでも肯定して発散させる人，なんでも否定して議論を深める人の3人です．
人に話すだけor文字に起こさないと，次々に思考が飛んで大事なアイデアの種を逃してしまいます．この方法だと文字として残るので，思考スピードがいくら早くてもいつでも戻ることができます．
0からアイデアを出すのは難しいと思うので，自分の書き出しをチームに共有して種として利用してもらっていました．
書きながらプロダクトアイデア的なものが浮かんでくるので「～があるといいかも」，「○○と○○を組み合わせたプロダクト」などの文章が増えていきます．最後はそれをChatGPTに投げてまとめてもらっていました．この方法で30個くらいは出した気がします．
アイデア出しの罠
今まで自分が経験してきた要件を満たしていくモノづくりとは違い，ニーズから生み出す必要があるので，手探りの状態で進みました．
タンジブルを目指す
講義ではタンジブルなプロダクトが求められました．タンジブルとは実態があるモノの事で，アプリケーションのみだとダメで，スマホも開発しなくてはなりません．
情報科が授業にいないという授業の都合的な理由もありますが，インサイトを深めていけば必ず，一つの機能のみを持ったタンジブルなものが生まれるという考えもあるようです．結局IT化は汎用性を高めた結果とも言えるので一理あるのかもしれません．
とはいえ，コミュニケーション問題や情報処理に関する問題を取り扱うと必然的にソフトフェア的な解決になりやすいので避けるようにしていました．
ボツ理由の言語化
「トラックドライバーの新しい働き方をデザインせよ」というかなり広いテーマでした．働いている人の方が課題が明確だと思ったので選びました．（もっと人の生活や体験に沿ったテーマもありました）
テーマが広いので初めに，「デザイン思考を活かせるか？」，「POVが作りやすいか？」，「新しいプロダクトになりやすいか？」など仮説を立てながら進めました．
プロダクトアイデアは没にする時は理由をしっかりと言語化することが大事だと気が付きました．「なんとなく面白くない」「先が見えなそう」「デザイン思考っぽくない」などボツ案がふわっとしていると，アイデアを出した人に不満が残るのでチームの雰囲気も悪くなるし，少し経った頃にまた同じ穴にハマります．
それぞれのカテゴリ ＞ POV ＞ プロダクトの順に没にしていき最後に残ったアイデアをプロトタイプに仕上げます．
カテゴリごとのボツ原因を思い出しながら書いてみます．
倉庫作業
大きな課題を解決しようとして中々抜け出せませんでした．
課題は明確で大きいですが，現時点ではロボット化やIT化での解決が適しているものばかりでした．システム化されている作業が多く人の感情や考えが見えず，機能的に解決を目指すエンジニアリングに寄ったプロダクトになってしまいました．
車内環境
トラックドライバーだけでなく乗用車に乗る人でも感じる課題が多く，類似商品が多かったです（例：ゴミ箱，スピーカー，消臭など）
コミュニケーション
同僚や先輩，取引先とのコミュニケーションが課題になります．しかし，タンジブルなもの（手で触れるもの）を作れという授業の方針に反してアプリケーションのアイデアが多く出てきました．
また，双方が課題を抱えている必要があるため，インセンティブ設計が難しかったです．
安全管理・業務管理
管理システムは，基本的にIT技術での解決が主です．先端技術の導入は企業によってバラつきがあり，最大の原因は導入コストが高いことでした．
知的作業（運転中の思考，情報の記憶・共有）
生存バイアスの影響が小さい新人の課題から発想を得ました．しかし，結局は情報を扱うのでタンジブルなものになりにくく，デジタルアプリケーションでの解決が適していると判断しました．
その後出てきたPOVとアイデア一つ一つについてもボツの原因を言語化してチームで共有しながら進めました．POVは型にあっているか評価基準に進めました（完全に理解はできていないです）
各アイデアのボツ理由についてはチームで数十個あったので省きます．頻出だったのを以下にまとめました．
課題が小さい
課題の重要度がわからない
代替品で簡単に解決できる
類似商品が既にある
デザイン思考的でない（機能の改善になってしまっている）
導入する人と課題を抱えている人が別で導入者のインセンティブがない
1人の方がいい
アイデア創出でよく使われるチームでのブレーンストーミングというものがあります．しかし，個人でのアイデア創出の方が質が上がるという研究結果があるようです．
チーム作業なので満足度が上がりますが，他人に気を使って質が落ちるようです．その点，強制発想法はブレーンストーミングと個人作業の間なのでよく考えられています．
アイデア先行の場合の注意
色々なことを考えた末に直感的にアイデアが思いつくことがあります．その場合，後からPOVやHMWQを作ることになるので，こねくり回してプロダクトの良さを後から言語化することが多くなります．
チームメンバーに伝える際は，このアイデアを思いつく過程を話して誘導していかないと，ぽっと出のアイデアと捉えらえてしまい賛同を得られなくなります．自分の中である程度答えが出ているアイデアでもチーム活動なのでそこら辺を気にして進めていました．
完全無欠なアイデアを求めない
プロダクトを製作していくにつれ段々と欠点が見え，アピールポイントも弱く感じ始め，欠点を埋めようと機能を足し算してしまいます．すると，より汎用的になる反面，ターゲットシーンやアピールポイントがブレてしまいます．
強いアピールポイントが一つあれば欠点のない汎用的なプロダクトより上だと思ってブレないよう意識していました．結局世の中に出ている商品も何かしらデメリットがあるものです．特定の人に強く刺されば良いのです．
課題に対して直線的に
先輩から面白い話を聞きました．例年，ゲームで問題を解決するアイデアが出るみたいですが教員からは不評で終わるみたいです．
なぜかと言うと，コミュニケーション問題の解決のためのゲームになっている場合がほとんどだからです．ゲームの楽しさで利用コストを下げることで会話を増やすというロジックなので，会話を必要とするゲームなら何でもよくなってしまいます．なにより課題のために直線的でなくゲームで間接的に解決している点が良くないです．
自分たちも思考力を鍛えるという目的でゲームを提案しましたが，ゲーム制作には時間がかかる＆問題を構造化＋パターン化する必要があるので難しいと判断し没にしました．構造化とパターン化ができるならその枝葉のところで何か商品が生まれているはずで，その商品を作るべきだとごもっともなことを言われてしまいました．
ターゲットユーザーを意識する
プロダクト作りながらいろいろとインタビューをしていると，段々とターゲットユーザーがズレてきてしまいます．
別のユーザーにインタビューする場合は，ターゲットユーザーと重なっている要素をしっかりと意識してから意見を受け取るべきです．
まとめ
POVやHMWQから考えだしたり，時にはインタビューまで戻ったりと最も「曖昧さとダンス」をしていたのはこのフェーズでした．そのぶん学びも多くかなり文章量が多くなってしまいました．
他グループの発表や世の中のアイデア商品（グッドデザイン賞）などからインスピレーションをもらうことも有効でした．
次はプロトタイプです．
この記事が気に入ったらサポートをしてみませんか？