「ソフトウェア開発ファシリテーション」アドベントカレンダー4日目の記事です。
先日に引き続き「どうして作りたいソフトウェアが伝わらないのか」というお題です。
作りたいソフトウェアを伝えるためには、「なにをつくるのか」ではなく「なぜつくるのか」を伝える方が有効だという話でした。
ではどうやって上手く「なぜつくるのか」を伝えれば良いのかと言ったときに、以下の8つのポイントがあるとお伝えしました。
- 誰の課題を解決するのか？（ターゲット）
- その人たちはどんな課題を持っているのか？（課題の把握）
- その課題の根本原因はどんなところにあるのか？（課題に対する独自の視点、考察）
- それはどうすれば解決できるのか？（ソリューションの仮説）
- なぜ今する必要があるのか？（タイミング）
- 現在は何によって代替できるのか？（代替品／競合）
- 課題を持っている人はどのぐらいおり、いくら払ってくれそうか？（市場規模）
- なぜあなたがこのアイデアに取り組む必要があるのか（想い）
後編では一つ一つ見ていきましょう！
目次
誰の課題を解決するのか？（ターゲット）
口頭で伺うときは「このソフトウェアを使う人たちのことを思い浮かべたとき、どんな人の顔が思い浮かびますか？」などと言い換えることがあります。
要は誰が使うのか、ということですね。
よくペルソナと言って「30代女性、専業主婦、都内に住んでおり3人の子供を育てている。上の兄は双子で7歳、下の子は2歳。加圧トレーニングに通い、ダイエットに励んでいる。最近ではオートミールダイエットを試みるも、逆に体重が増えてしまい戦慄している」みたいな詳細度でユーザー像を描くこともあります。
このように文字情報で整理しても良いですが、まだまだふわっとしている場合はGoogleの画像検索でいろんな顔写真を検索して、「こんな感じの人がターゲットっぽい」という感じでmiro上にペタペタと貼り付けながら何となくのユーザー像を空想するに留めることもあります。
その人たちはどんな課題を持っているのか？（課題の把握）
で、具体的にどんな課題を持っているのか？という問いが次のお題になります。
「こんな課題を持っているに違いない」という仮説の話よりは、課題だと考えられた事実を列挙する方が効果的に思います。「こういうとき、こうだった」と、実際に観察した結果を並べたいところです。
緻密に観察するのは結構メンドーな作業だし「これが当たるに違いない！」と興奮しているときにはスルーしがちな部分ではあるので、後からインタビューなどを通じてファクトを集めていくことになったりもします。オンラインでのインタビューにはビザスクが便利です。
その課題の根本原因はどんなところにあるのか？（課題に対する独自の視点、考察）
具体的な課題の把握の次のお題が「では、その課題を引き起こしている構造とは何か？」という問いです。
その課題の根本原因は何なのか？ということですね。この根本原因にアプローチできれば、ソリューションはよりパワフルになると思われます。
構造を追っていくにあたっては、システム思考のループ図を活用すると便利なケースがあります（例：システム思考・ループ図事例 社会編：ますます混雑）。
ちょっとお題とはズレますが、ループ図を活用した例として過去にこんな記事を書きましたので、参考にしていただければ幸いです。
TECH PLAYさんのイベント「時代とともに変化する技術的負債」でお話させていただきました #techplayjp
それはどうすれば解決できるのか？（ソリューションの仮説）
課題を引き起こしている構造を把握した上で、ソリューションについて考えます。
例えば、
「勤怠を正確につけて欲しいと従業員に伝えても、打刻した時間と労働時間がズレてしまうことがある」（課題）
「労働時間の実態が打刻された労働時間より大きい場合、未払い残業などの法令違反に繋がる」（課題）
「そもそも人の手で打刻をする限り、何らかの原因で申請された労働時間にはズレが生じる」（根本原因）
「であれば、人の手で打刻するのではなく、客観的なデータに基づいて労働時間を計測すれば良いのではないか」（ソリューション）
という形でソリューションを導き出していきます。
（上記の例は「打刻レス」勤怠管理サービス ラクローを参考にしました）
課題だけを見ると「上長がしっかりと管理するべきでは」「上長へのアラートの仕組みを作るべきなのでは」みたいな方向に流れかねず、その方向性になってしまうとあまり心に響かなさそうなソリューションになってしまうこともご理解いただけると思います。
なぜ今する必要があるのか？（タイミング）
「なるほど、ちなみに何故今このソリューションに取り組まれようと思ったんですか？」
と、よく聞いていることが分かったのでタイミングについてもポイントの一つに入れています。
社内の状況が合併などの理由で変わって追い風になっている、だとか、外部環境が変わって（例えばコロナ渦による在宅勤務の普及で）追い風になっている、だとか、そういった内容も「なぜつくるのか」の思考プロセスを理解するための一助になります。
現在は何によって代替できるのか？（代替品／競合）
代替品がそもそもの競合になる可能性があります。
代替品がなくとも、いろんな手段の組み合わせによる代替手段があるとして、それが新しいソリューションより多少面倒な代替手段だとしても、利用頻度やコストメリットなどの問題でそちらが選択されてしまう可能性があるかも知れません。
「すっごく面倒くさいことだけど年1回のことだから、まぁいいか」
みたいな話って、よくありますよね。
年1回のすっごく面倒くさいことの代表格が確定申告ですが、さすがにここまで行くと、私はいくらか払っても良いという気持ちになります。freeeの確定申告の機能は便利ですよねぇ。
相談する相手がいろいろなサービスに詳しい人だと必ず「いや、でもこのサービスが既にあるじゃないですか」と返されるので、そういう意味でも「既に調べてありまして」と返せると、相談を次のステップに進めやすくなると思います。
課題を持っている人はどのぐらいおり、いくら払ってくれそうか？（市場規模）
「寄り合いの経営者に聞いてみたら、ニーズがありそうでした」
みたいな話のとき、同じ業種の経営者であれば必ず同じ課題を持っていそうなのか、それともその経営者のニーズだけが特殊なのかを見ていくと、課題を持っている人がどのぐらいいるか分かりそうですよね。
特殊なニーズだとして、同じ特殊なニーズを持っている人には刺さりやすいかも知れませんが、パイによっては物凄く高価なソリューションになってしまうかも知れません。ちょっと面倒でも総費用としては安価な代替手段がある場合、厳しい戦いになるかも知れませんね。
開発に対してどれぐらいのコストをかけられるかのざっくりとした目安になりますし、状況によってはソフトウェアを作らずに手で対応した方が利益が出そう、という判断にもなるかと思います。
なぜあなたがこのアイデアに取り組む必要があるのか（想い）
最後にはなりますが、8つのポイントで一番重要なのが「なぜあなたがこのアイデアに取り組む必要があるのか」という問いだと思います。
経済合理性などからではなく、ご自身のエピソードから企画しようと考えた経緯を伝えてもらうと、企画への共感度が深まります。
共感が深まることによって相手の問いも的を射たものになりやすくなり、「何だかこの人であれば話が通じそうだ」と思える頻度が高くなります。
ロジックと共感の両輪で「なぜつくるのか」を伝えてもらうと、相談されていることの解像度が上がりやすい、というのが「なぜ？」をうまく伝える8つのポイントのキモなのでした。
ファシリテーターの役割
とはいえ最初からこの8つの問いに答えるのも難しい・・・。
というわけで、この問いにどうやって答えれば良いのか？をサポートするのが、ソフトウェア開発におけるファシリテーターの役割かなと考えています。
8つの問いへの解像度が上がらないうちに開発に進んでしまうと、
「開発者が全然分かってくれない・・・」
「確かに伝えた通りにはなっているけど、思ったのとは違うんだよなぁ・・・」
「よかれと思って勝手にやってくれることが全部裏目に出てる・・・」
みたいなお悩みに繋がってしまい、結果として
「ああ、ソフトウェア開発って難しいなぁ・・・」
という落胆に繋がってしまうように思えます。
8つの問いが銀の弾丸というわけではありませんが、ソフトウェア開発の場に必要な情報を引き出すためのツールとしてご参考いただければ幸いです。
