一人から始めるデザイン思考
この記事は個人開発AdventCalendarの25日目です。
最近巷でよく聞く「デザイン思考」ですが、実際に仕事で取り組んでいる方は少ないと思います。また、導入しようと思っても既存のプロセスを大きく修正しなければならなかったり、多くの調整が必要だったりと、乗り越えなければならない壁が多いかと思います。
そこで、今回のAdventCalendarにもある通り個人開発で用いてみてはどうだろうという提案を今日はします。内容の多くは私が受講していた授業をまとめた書籍「エンジニアのためのデザイン思考入門」から引用しています。詳しく知りたい場合はそちらも参考にしてください。
デザイン思考とは
「デザイン思考」とは、以下の5つのステップ（共感、問題定義、発想、プロトタイプ、テスト）を繰り返すことで、問題の本質をインサイト（何かをきっかけに新たに気づいた情報）としてとらえ、そのインサイトにもとづいたソリューションをデザインすること、そのプロセス、その考え方を指します。※詳しくはd.schoolのプロセスガイドを参照
デザイン思考を用いた個人開発のフロー
テーマを設定する
デザイン思考をするにはテーマが必要です。受講中は、「毎日の通勤体験をデザインする」など、どんな方法で解決するかや、何を解決するかという具体的な方法などない、漠然とした課題を与えられました。
ステップ１：共感（Empathize）
テーマにもとづき、ユーザーインタビューします。インタビュー対象は人数が多いほど多様性が生まれるため良いのですが、個人開発では友人や家族にしてみると良いかと思います。その際自分の中で当たりを付けてヒアリングするのではなく、あくまで相手に「共感」することで、相手の言動だけでなく考えたこと、感じたことも分かるようにとことん聞きます。
ステップ２：問題定義（Define）
デザイン思考において肝となるフェーズです。共感した内容にもとづき、インサイトとPoint of View（POV）を探ります。ここではKJ法、カスタマージャーニーマップなどを駆使します。例えば、通勤体験の場合、
都内で働くソフトウェアエンジニアは、通勤がしたくない。
なぜなら、満員電車による疲れで仕事に集中できないからだ。
とはいえ、仕事をする上では顔を合わせていた方が仕事がやりやすい。
というようなPoint of Viewを設定することが出来ます。
ステップ３：発想
ここでは「How Might We Question（HMWQ）」と呼ばれる「どうすれば私たちは◯◯できそうか？」という問いを使い、それに対する解決策を考えます。例えば、通勤体験の場合、
どうすれば私たちは在宅でソフトウェアエンジニアと同僚間の温度感を実現することができそうか？
というようなHMWQを設定することが出来ます。そして、これに対する解決策を検討する際はとにかく落書きを繰り返し、ソリューション自体やソリューションのイメージなどを膨らませます。
ステップ４：プロトタイプ
「発想」ステップで決めた解決策のプロトタイプを作ります。講義ではHWのあるTangibleなものを推奨されていましたが、Webサービスの場合はペーパープロトタイプが労力も少なくて最適だと思います。この際、ワイヤーフレームのように枠だけを作るのではなく、具体的な数値やイラストも書いておくことで実際の使用イメージがつかめるものだと良いです。
ステップ５：テスト
可能であれば、作成したプロトタイプを実際にユーザーとなりそうな人に触ってもらいましょう。ステップ１のインタビューで協力してくれた人にお願いするのが最短かもしれません。実際のテストを利用している際の表情や行動、感想などを聞き取って、プロトタイプに反映しましょう。
ざっくりとしたデザイン思考の流れをまとめてみました。個人開発をするのであれば是非お試しを！
