今回は、ITサービス開発に適したデザイン思考のフェーズ3「定義」とフェーズ4「発想」について解説しよう。

3 定義(Define)
解決すべき課題を特定する

 定義フェーズでは、直前の共感フェーズで得られた成果を基に「ユーザーが感じている真のニーズ・課題」を特定する。これが、チームが解決策を考える対象となる。

 このフェーズで目指すべきゴールは、明確な「課題定義文」を作り上げることだ。漠然とした課題定義を行うと、それに対応する解決策を考えることが困難になる。例えば「あるべき姿を考える」といった表現ではダメである。個別具体的でシャープな課題定義を行う必要がある。

 ユーザーが話している表層的なことから課題を選ぶのではなく、ユーザーが現場で感じている核心(インサイト)を発見するのが重要だ。発見された課題に対して「なぜ」「なぜ」を繰り返し、因果関係を整理しながら最終的にたどり着いたのが、検討すべき真の課題になる。

 定義フェーズは、以下の二つのタスクから構成される。

(1)現場観察結果の棚卸し:現場観察やデプスインタビューの結果を取りまとめ、現場に赴いていないチームメンバーを含めて全員で共有できるようにする。

(2)解くべき課題の決定:現場で得られた事象のうち、気になったこと、違和感を覚えたことなどを抽出し、その中から課題を見いだす。さらに構造化された課題の中から、今回チームとして取り組む真の課題を特定し、課題定義文として整理する。

 ここまでで、前半の3フェーズが終了する。あとは、解決策を導き、それを実現していくフェーズとなる。

4 発想(Ideate)
アイデアをつぶさない 工夫を凝らす

 4番目の発想フェーズでは、定義フェーズで定義した課題に対する解決の方向性を検討し、具体的なサービスなどを創造する。いよいよ課題解決に向けたアイデア創出に入るわけだ。

 このフェーズで最も大切なのは、「なるべく多くのアイデアを出す」ことに尽きる。質より量、アイデア自体の良しあしの判断は先送りし、どんな些細なアイデアでも否定せず、すべて積み上げておくことが重要だ。

 どんなに素晴らしいサービスであっても、最初のアイデアはあやふやで不明瞭である。当然“柔らかいアイデア”を却下しないことを心掛けたい。

 筆者の経験上、ITエンジニアの多くは「アイデアを却下しない」という行動が苦手なようだ。目の前に出たアイデアに対して、すぐに「どのようにそれを実現させるか」を考え出す傾向がある。「こんなアイデアは実現できない!」「やったことがない!」と即座に否定することなく、ぜひ前向きに発想を生み出す対話の輪に加わるようにすることが大切だ。