PHONE APPLI Engineer blog

エンジニアブログ

ブレストの手法をブレストして新しいブレストを生み出したお話

だんだん暑くなってきましたね。リサーチデベロップメントの たかはしとし( @doushiman_jp ) です。

夏の生まれですが、夏は大の苦手です(暑いから)

ブレストをリデザインする

以前、「マンダラートを使ったアイディア発想ワークショップをやってみた」という記事を書かせていただいているのですが、僕たちリサーチデベロップメントは、メンバーがそれぞれに感じた社会課題や疑問を持ち寄って、どうやって解決できるのか、そこからどのような価値が生まれるか、といったことを日々ディスカッションしています。

以前はマンダラートを使ったり、色々な手法を模索しながらブレストを行っていたのですが、それらのブレスト手法そのものをもう少しブラッシュアップできないか、という観点でディスカッションを行い、現在は自分たちでデザインしたブレスト手法を採用して、ブレストを行なっています。

弊社 PHONE APPLI は緊急事態宣言下で、ほぼ100% リモートワークで業務をおこっていますので、離れていても、みんなで効率的にアイディアを共有し、育てていけるような手法が必要だったため、その点を考慮したデザインにしています。

この手法もまだまだ発展途上ではあるのですが、同じような環境下で困っている方達の参考になればと思いますので、僕たちのブレスト手法を簡単にご説明してみたいと思います。

ブレストがうまくいかないあるある

そもそも「こういうことがしたい!」という願望があって、その願望を実現するための方法を模索するために、ブレストを行うことが多いと思います。

なにもやりたいことがないのに試行錯誤はしないと思いますし。

ですが、「願望」を安易に「解決方法」に結びつけてしまうと、自分の「やりたい」気持ちだけが先行して(その気持ちも大切なモチベーションですが)、根拠の薄い課題解決に着地してしまい、手段と目的が入れ替わってしまって、結果的に「それやる必要あります?」になってしまうのもブレストあるあるかな〜と思います。

また、思いついたことを書く、というのがブレストの基本ですが、そこに至る道筋が省略されて、最終的に「これ、どこから生まれてきたんだ??」という鬼子的アイディアが爆誕したりします。

一人でブレストを行なっているのであれば、自分の中では理解できているので問題ないかもしれないのですが、グループで行うブレストの場合、そのアイディアに至ったストーリを第三者が理解できず、そこからあまり発展しづらかったりという悲しい事態もありがちです。

そこで、ブレストの持つ「自由に発想する」という良さを残しつつ、解決に至るストーリーを見える化する手法として、【HEXAMAP】 というやり方を考案し、ブレストを実施しています。

【HEXAMAP】って?

「へきさまっぷ」と呼びます。

ブレストの方法を模索する時に、まず僕たちは以下の仮説を建ててみました。

  • 有効な課題解決には、一定のストーリーがあるのではないか

よく、漫画やお話などには「起承転結」が必要、と言われるかと思います。

4コマ漫画で、1コマ目と4コマ目だけ繋げても、唐突なオチに戸惑うことになるかと思いますが、同じように、課題とその解決の間には必要な要素があるんじゃないかな〜、と考えたわけです。

僕たちは有効な課題解決に必要な要素を

  • 願望

  • 放置リスク

  • 課題

  • 仮説

  • 事実

  • 解決手段

  • 障害

  • 期待される効果

に分かれるよね〜と考えました。

また、これらの要素同士には有効な繋がり方(解決手段には障害が紐づくなど)があるよね〜と。

そういった関連しあう要素同士を隣に配置したモデルが下図になります。

f:id:doushiman_jp:20210622140404p:plain

基本的に、隣り合う要素同士は、繋がっていると、より「強い」意見である、と見なします。

これらの要素のうち何かが欠けていた場合、たとえば放置リスクがヒモづかない場合、それほっといてもよくない?とも考えられますし、課題に対して仮説(こういうことだから解決できていないのかな?)や事実(こうなっている事実があるから課題となっている)がない場合も、解決手段に至る接続がうまくいっていない(=有効な解決手段に至らない)のでは、と考えられます。

HEXAMAP はこういった、物語でいう起承転結のような要素を色別のパーツとし、ブロックを組み合わせるようにブレストを行うことで、スタート(課題)からゴール(課題解決)の道筋をトレースできる、というところが特色です。

例題

簡単な例を示します。

たとえば「体重が減らない」という課題があったとします。僕にとっても永遠の課題です。

例えば体重が減らない、という課題があったとしても、「放置した場合のリスク」として「健康面のリスク」がなければ、別に痩せなくてもいいじゃん、が結論になるかもしれません。

また、課題を課題たらしめている「事実」として、「運動不足」が無ければ、「運動を日課に取り入れる」という「課題解決」は的を射ていない、ということになります。

解決手段」に「障害」が紐づいていない場合、実現に向けたリスクが洗い出せていないのかな?ということが直感的にわかったりします。

f:id:doushiman_jp:20210622135504p:plain

矢印のように、それぞれの要素が周囲の要素と繋がることで「何を解決するべきか」「どう解決すべきか」の根拠を補強し、ブレない結論を導くようなサポートをできるところも、HEXAMAP の特色の一つだと思います。

まとめ

いかがでしょうか。

もちろん、実際の課題解決は例のように単純ではなく、「体重が減らない」に関して「間食が多い」事実があったり、「面倒くさがる心」に対して、じゃあどうしたら面倒くさく思わずに運動を行えるか、といった様々な要素がブレスト参加者によって継ぎ足され、ブレストが進んでいき、いろんな方向にマス目は伸びていき、その方向に沿ったいろいろな解決方法がでてきます。

ブレスト自体はHEXAMAP 専用に自前で作成したWebツールだったり、miro というコラボレーションツールを使用して行っているのですが、これらのツールを使った場合、リアルタイムで考えをメンバー間で共有できるので、どんどん新しい考えが追加されていきます。

色で直感的に足りない要素が把握できるので、「ここで解決方法がくると根拠が薄いな」「仮説を追加して議論を膨らませよう」といった戦略を取れたりするので、ちょっとしたゲーム的な面白さもあります。

以前使用していたブレスト手法に比べ、特に多人数で行うブレストで、メンバー間で実現までのイメージの共有や解決までの理論が強化されたように感じます。

一方、要素間の繋がりなど、意識することが多いので、ファシリテーターや参加者側にも慣れが必要かな、といったあたりは課題として感じています。

今回はブレストの「手法そのものをデザインする」という少し趣の違う企画だったのですが、更にこの手法もブラッシュアップしつつ、モリモリ色々な課題解決に取り組んでいこうと思います。

最後までご覧いただき、ありがとうございました!


PHONE APPLIについて

phoneappli.net
phoneappli.net