「ソフトウェア開発ファシリテーション」アドベントカレンダー3日目の記事です。
作りたいソフトウェアについて、上手く伝えるのは大変です。
「作りたい画面や仕様を詳細に伝えられれば伝えられるほど、作りたいソフトウェアを正確に伝えられるのでは」
そう考えるのも自然なことだと思います。
一方で、専門家に「こんなソフトウェアを作りたいんだけど、どう思う？」と相談するときの期待は、「ここはこうした方がもっと良くなりますよ」と、プロフェッショナルならではのアドバイスをもらえることだったりしないでしょうか？
（つべこべ言わずに書いてあるものを作ってくれれば良いのよ！という話であれば、伝える資料が詳細であればあるほど良いという話になると思いますが、言ったものを正確に作れば作るほど「思ったのと違う！」となるケースが多いと経験的には感じます。この話はまた、別の機会に）
そんなとき、フィードバックをする上で専門家の知りたい情報は「なにをつくるのか」ではなく、「なぜつくるのか」だったりします。
「こういうソフトウェアをつくろう！」と思っているからにはソフトウェアによって解決したい課題があるはずです。その課題に対して有効かどうか、もっとコスパの良い解決方法があるか、もしくは既に代替手段があるのではないか、適法性の観点からはどうか、といったことを考えるにあたっては、解決したい課題の解像度が上がっていないと思考が進みません。
だとして、じゃあどんな風に解像度を上げれば良いの？というときによくお伝えしているのが以下の8つのポイントです。
- 誰の課題を解決するのか？（ターゲット）
- その人たちはどんな課題を持っているのか？（課題の把握）
- その課題の根本原因はどんなところにあるのか？（課題に対する独自の視点、考察）
- それはどうすれば解決できるのか？（ソリューションの仮説）
- なぜ今する必要があるのか？（タイミング）
- 現在は何によって代替できるのか？（代替品／競合）
- 課題を持っている人はどのぐらいおり、いくら払ってくれそうか？（市場規模）
- なぜあなたがこのアイデアに取り組む必要があるのか（想い）
一つ一つの詳細については長くなるのでまた次回に！
このリストを作るにあたって参考にした書籍は以下の通りです。ご参考ください。
