【備忘】良いアイデアを選ぶ意思決定プロセス
こんにちは！👋
引っ越しが終わり、MBAの期末試験に追われたり、家族がシカゴに遊びにきてくれたりと夏休みを満喫している間にしばらく更新が途絶えてしまいました、、、🙇♀️
前々回は課題のリフレーミングの方法、How Might Weステートメントの書き方を、前回はそのHow Might Weをもとにアイデアを機械的に量産する方法についてまとめましたが、今回はその続きで、たくさん作られたアイデアをどのように選別して、プロトタイピングに進めていくのか、Institute of Designで教わったことをまとめようと思います！💐
個人的に、数日のデザイン思考ワークショップではアイデアを出すところまでに注力がされていて、結局どのアイデアを優先するのか、という選定のプロセスは割と手薄というか、クイックに済まされる印象があります。
IBM Enterprise Design ThinkingではFeasibility（技術的に作れるか・開発難易度という言葉で置き換え可能）とImportance（このアイデアが実装されることでどれくらい業務が効率化されるか）という2軸でグラフを作り機械的にFeasibilityがそこまで高くなく、Importanceが大きいアイデアから着手しよう、ということになり、プロトタイピングが始まります。Importanceはワークショップに参加しているお客様が主導で決め、Feasibilityはエンジニアが中心になって決めるようなイメージです。
2-3日のワークショップの立て付けではこのクイックな優先順位付けが上手くいくのかもしれないのですが、もう少し様々な角度から考えて優先順位付けをするべきではないのかと常々思っていました。なぜなら、優先順位付けの後は、プロトタイピング・テスト（そのアイデアが本当にいいアイデアなのか検証するプロセス）になり、時間と労力がかかるプロセスだからです。時間と労力を投資する前にもう少しだけ慎重にアイデアを選定するべきではないのかと思っていたら、Institute of Designで学んだ方法論は、もちろんPrioritization Gridのようなメソッドも含まれているのですが、もう少しだけ丁寧にアイデア選定をしていたので、今回はそれをご紹介できればと思います。
事前準備 - アイデアの精緻化
ここからはステークホルダーにインタビューをしたりと、より人を巻き込んで議論をすることが増えてくるので、アイディエーションのフェーズに参加していなかった人でもそのアイデアが理解できるように説明を加える必要があります。
サービスの場合 : ストーリーボードを作る
アイデアが物理プロダクトではなく、サービスの場合、ストーリーボードというツールを使って、アイデアを物語化します。どのデザイン思考ワークショップでも必ずと言ってよいほどでてくるアクティビティなのでご存知の方も多いでしょう。ストーリーボードは、ユーザーが踏むステップ、サービスとの接点、そしてその体験がどのようにユーザーに利益をもたらすかを簡単に描写したものです。
ストーリーボードに含むべき要素が以下の通りです。
ユーザー : 一人暮らしをする会社員
葛藤（私たちが解決しなければならない課題）：忙しいユーザーは朝もバタバタでゆっくりコーヒーを淹れてリラックスする余裕なんてなし。
救済（葛藤からユーザーを救い出してくれるのがサービスアイデア）：スターバックスのオンラインオーダーサービス。
ジャーニー（ユーザーがどのようにサービスを使って問題を解決するかのプロセスのこと）：アプリ開いてコーヒーをオンラインで注文。長い列に並ぶことなく、コーヒーが受け取れる。
結果（ユーザーが体験を通して何を学んで、どんな感情を抱いたか）：忙しい朝もストレスフリーに美味しいコーヒーが購入でき、リラックスした朝を迎えることができた。
それぞれの要素を洗い出したら、要素が物語になるように情報の抜け落ちを補っていきます。例えば以下のようなステップを踏むとよいでしょう。
状況設定（最初の1-2コマ）：ユーザーを紹介する。できるだけユーザーの人柄や生活環境が理解できるように詳細に設定を決める。
課題への直面（次の1コマ）：引き起こされた課題は何で、この課題がユーザーに及ぼす影響はなにか。
課題の解決（次の2-4コマ）：どのようにサービスがユーザーの課題を解決したか？どのようなプロセスで？
結果：ユーザーは課題をサービスで解決できてどのような気持ちになったか？なにか状況への変化はあったか？
ストーリーボードを作るときは、一環してサービスの利点を説明することに重点を置くことが重要です。また、ユーザーの視界の外にある世界、つまりユーザーには見えない世界で繰り広げられるプロセスを示すのも効果的です。（例えば、スターバックスの店員がモバイルオーダーを受け取ってからドリンクを提供するまでのプロセス）
プロダクトの場合：機能レベルでのコンセプトシートを作る
コンセプトライティングは、ブレーンストーミングで得たアイデアの形状や価値を明確にするのに役立つプロセスです。また、スケッチの段階ではわからなかったことを明確にし、情報の補足などを通して、アイデアを精緻化することができます。
このコンセプトシートに含まれるべき要素は以下のとおりです。
プロダクト名：コンセプトにわかりやすい名前をつけます。ex: Everyday Gourmet
このプロダクトは何か(What it is)：これは端的に何か説明します。（ex: これはハイエンドのドッグフードトッピングである。）
どのように使うか(How it works)：このプロダクトは何をするのか、どのようにユーザーのニーズに訴求するのか説明します。（ex: プレミア顧客むけの食料品ストアなどで購入できる。人間用の食事に組み合わせることにより、栄養のバランスが取れた食事を愛犬に提供することができる。）
利益（Benefit）：このプロダクトを使うことにより、ユーザーにどんな効果がもたらされるか。（ex: バラエティ: 日々の人間の食事にこのプロダクトを組み合わせることにより、毎日違う食事を愛犬に提供できる。プレミアム感: 高品質の素材を使って作られたこのプロダクトは、できるだけ最高の食材を愛犬に与えられているという自身を飼い主に与える。etc）
解決される課題（Jobs done for the users）：ユーザーは何がしたくてこのプロダクトを使うと考えられるか。（ex: 愛犬にワンランク上の特別な食事を提供する、愛犬へ手作りのごはんを作ることに対する自信を与える、愛犬へ人間の食べ物を与えることに対する不安を払拭する。 etc）
スケッチ：プロダクトがどんな形状をしているか、イメージを可視化する。Photoshopで実際のプロダクトのイメージを作ってもよい。
意思決定プロセス
前置きがだいぶ長くなってしまいましたが、Institute of Designではアイデアの有効性を3つの方法で分析します。
ステークホルダーインタビューを通したスクリーニング
DVF(Desirability, Viability, Feasibility）スクリーニング
マトリックススコア付スクリーニング + リスク分析
1,2,3と順番はあるものの、各フェーズで全員一致で明らかにいいアイデア（Obvious Wins）だと思ったものは次のフェーズに進む必要はなく、自動的にプロトタイピングに進みます。また、各フェーズでフィードバックを受けたり、リスク分析をしたりしますが、得られた示唆をもとに随時アップデートしていくことが重要になります。また、評価されなかったアイデアも、それを排除する必要はなく、改善策を考えてまた意思決定プロセスを回すことができます。
プロトタイピングに進むアイデアは、その組織の大きさにもよりますが2-3個くらいが目安かなと思います。
ではそれぞれのフェーズについて詳細にご説明します。
ステークホルダーインタビューを通したスクリーニング
フィードバックを得ることは、デザインプロセスにおいて、コンセプトを改善するための最良の方法のひとつです。早い段階でフィードバックを得ることができれば、筋違いのアイデア（定義した問題を解決していないアイデア）に費やす時間を減らすことができます。また、デザインの専門家ではない人々に自分たちのアイデアを伝えることで、自分たちのバイアスを理解し、ユーザーに受け入れられやすいサービス・プロダクトにアップデートすることができます。
ステークホルダーに聞くべき質問例
あなたはどのようにこれを使いますか？このプロダクト/サービスが役立ったであろう出来事は最近ありましたか？
なぜあなたはこれを使うのですか？最も魅力的な機能、役立ちそうだと思う機能はなんですか？
あなたがこれを使用できない理由はありますか？それはどんな時で、理由は何ですか？どのような障壁が考えられますか？
このプロダクト/サービスに対してどんな疑問点がありますか？これを安心して使うためには、どのような情報が必要でしょうか？
留意点
ステークホルダーの回答を記録すること。一連の質問が終わったら、最後に今まで議論したフィードバックで変更したり、追加したい点はあるか確認すること。
できるだけ多くのレビューセッションを行うこと。その領域の専門家、この一連の活動の序盤にインタビューした人（最初の段階でインプットを与えてくれた人）、ユーザーになりうる人などなど。通常5-20のインタビューセッションをすることが多い。
私たちがつくったコンセプトに価値はなく、インタビューイーから得られるフィードバックに価値があるのだということを忘れないこと。
フィードバックは重要だが、それを文字通りに受け取らないこと。抽象化して、要点を抽出すること。また、フィードバックが全て正しいとも限らないため、それを本当にプロダクト/サービスに反映するべきかは慎重に吟味すること。（Don't fall into repair service behavior!）
インタビュー後、どのように分析するか
まずはインタビューの振り返りをします。例えば以下のような論点で議論をするのがよいです。
ユーザー、専門家から何を聞き、何を観察したか？
ユーザー、専門家はプロダクト/サービスに関して上手くいく/上手く行かないポイントは何だと言っていたか？彼らはどんな疑問を持っていたか？プロダクト/サービスのコンセプトをより良くするために、どんなアイデアが議論されたか？
一番大きな反応が得られたプロダクト/サービスはどれか？なぜか？反応が一番大きいコンセプトは（ポジティブな反応であれネガティブな反応であれ）筋のいいコンセプトであることが多い。
そして、次のフェーズにすすめるべきアイデアを決定します。
次のフェーズに進むべきコンセプトを決定する上で最も有力なフィードバック/データは何か？
一番有力なコンセプトに、他のコンセプトからどのような要素を追加すれば、コンセプトの一貫性を損なうことなく、より強固なものにできるか？（コンセプトの全体像を混乱させることなく、ソリューションに何を追加できるか？）
前回・前々回の記事でも取り上げたD2C植物販売サイトThe Sillの改善案。オンラインでは実際に植物がどのような大きさ、色、形なのか正確に理解することができないので購入に心理的なハードルを感じるというユーザーの悩みに訴求した、購入前に植物をレンタルできる（そして気に入った場合はそれをそのまま購入できる）サービスコンセプト。
このアクティビティで、満場一致で明らかにいいコンセプトが特定できた場合は、そのコンセプトはプロトタイピングフェーズに進むことができますが、もう少し多角的にコンセプトを評価したい場合は次のDVF(Desirability, Viability, Feasibility）スクリーニングに進みます。
DVF(Desirability, Viability, Feasibility）スクリーニング
優れたアイデアや戦略は、ユーザーにとっての望ましさ(Desirability)、技術的な実現可能性(Feasibility)、そして実行可能なオペレーティングモデル(Viability)の3つのバランスがとれています。このアクティビティは、この3つの要素ごとに各コンセプトを評価するものです。
この評価は、定性的なディスカッションベースで行われます。よいアイデアは、それぞれ3つの要素に対して明白な答えを持っているはずです。（そのアイデアは直接プロトタイピングに進めることができます。）足りない部分がある（ex: DesirableでViableだけど、Feasibleではない）場合、足りない部分を補う形でアイデアをアップデートする必要があります。
ユーザーにとっての望ましさ / Desirable
革新的か / Transformational
そのコンセプトは、現在解決されていない重要なユーザーニーズを解決するか。ユーザビリティ / Usable
直感的で、（他のサービス・プロダクトからの）切り替えコストが低く、導入しやすいか。
技術的な実現可能性 / Feasible
技術 / Technology
このコンセプトを実現するための技術が既に存在するか、または新しい技術を実現するだけの能力があるか。ケーパビリティ / Capability
私たち（パートナーを含む）に、これを実現するための組織的なスキル、知識、リソースがあるか。
実行可能なオペレーティングモデル・収益性 / Viability
所有可能性 / Own-able
市場において、独自的かつ保護が可能で、特徴的なポジションを有することができるか。構造的な魅力・収益性（リターンが期待できそうか） / Structurally attractive
開発、テスト、持続的な成長に投資する為に、十分な利益を獲得することができそうか。
DVFのフレームワークは状況によって変更することができます。例えば、社会的なプロジェクトに取り組む場合は"Viable"を"Just"（正しいさ）に置き換え、そこにサステナビリティの観点でこのコンセプトが正しいか、このコンセプトはインクルーシブか、このコンセプトは誰かに不利益をもたらさないか、などという観点で分析することが可能です。
個人的に社会的プロジェクトでなくても"Just"の観点は重要な気がするのでDVFJモデルで分析してもよい気がします。
各要素をきちんと評価するためには、各エリアの専門家（ユーザーのニーズを一番理解しているデザイナー・デザインリサーチャーなど、技術力を評価できるエンジニア、オペレーションモデルを評価できるビジネスコンサル、PMなどなど）でじっくり議論するのがよいと思います。ただし、一番重要なのはユーザーにとっての望ましさ / Desirabilityなので、他の要素を補う為にDesirabilityを妥協することだけは避けなければなりません。
マトリックススコア付スクリーニング
アイディエーションの前のフェーズでHow Might Weステートメントをいくつか考えたと思いますが、このアクティビティではそれぞれのコンセプトがどれくらいそれぞれのHMWの条件を満たすか評価するものです。
一番左の列にアイデアコンセプトを、上の行に今まで検討したHMWやデザイン原則（≒HMWを非疑問形にしたもの）を記載します。
各HMW/デザイン原則とコンセプトの組み合わせについて、コンセプトがHMW/デザイン原則を満たす（または実現する）可能性が高いか低いか、以下の指標に従ってスコアを付けます。
0 = 可能性が低い（確率50%以下、信頼度が低い）
1 = 可能性がある (50%の確率、どちらとも言えない)
2 = 可能性が高い (70%の確率、おそらく成功するだろう)
3 = 絶対成功 (90%以上の確率、高い信頼性)
スコアが高い上位3つのコンセプトは次のステップであるリスク分析に進みます。
リスク分析
マトリックススコア付スクリーニングが終わったら、上位3つのコンセプトのリスクを分析します。
起こりうる問題 / Possible Consequences
それぞれのコンセプトについて、起こりうるネガティブな結果を想像して記載してください。何がうまくいかないでしょうか？
重要性・発生確率 / Significance, probability
これが起こったら、アイデアの成功にどの程度影響を与えるか、また、これが起こる可能性はどの程度かを判断します。(High / Medium / Low)
解決策 / Potential solutions
リスクを軽減または管理する可能性があるかどうか、そしてその方法を記述します。どうすればリスクを低減し、ネガティブな影響を最小化することができるでしょうか。
マトリックススコア付スクリーニング + リスク分析時の留意点
アイデアは全てコンセプトレベルなため、評価をするのは正直少し難しいかもしれません。十分な情報を持っていないような気持ちになると思います。ただ、とにかくやってみてください。笑 スコアをつけることだけが目的ではなく、スコアをつける上で生まれる議論に価値があります。
スコアをつける時、一貫性が重要です。数字を使って評価をしますが、これは絶対的な尺度ではなくチームで話し合いながら決める相対的な尺度で、概念を比較しているのです。
基準値を議論しましょう。わかりやすいコンセプトをを選び、全員でスコアを決め、そのスコアをを元に残りの点数を決めるのがおすすめです。（このアイデアより点数が高くあるべきか、低くあるべきか）
チームで議論をしましょう。意見の相違がある場合は、チームメンバーがそれぞれ付けたスコアの平均値を採用します。
スコアが低い場合でも、そのコンセプトを排除する必要はなく、改善策を検討しましょう。
採点が終わったら、何度も見直し、点を調整をしましょう。
個人的に留意点に追加したいのは、必要に応じてDVF分析に立ち返って分析結果をアップデートすることと、デザイナーだけでスコア付・リスク分析をするのではなく、技術面で評価できる人、オペレーション/ビジネスモデルを評価できる人も議論に含めることです。なぜなら、デザイナーだけで議論すると、リスク分析の際、リスク軽減のアイデア（Potential Solutions）を考える時、ぶっ飛んだアイデアが生まれがちだからです。（コンセプトそのものを実現するより、リスク軽減のための機能を追加するほうが技術的・オペレーション的に難しいのでは…と思うタイミングが多々ありました）
DVFスクリーニングとマトリックススコア付+リスク分析はウォーターフォール的に進めるのではなく、何度か反復して議論するのがよい気がしました。
終わりに
今回は、たくさん生まれたアイデアの中から、次のフェーズ・プロトタイピングに進むアイデアを選定するための意思決定プロセスについてご紹介しました。授業を受けてみて私が個人的に注意したいなと思った点は以下の4つです。
自分が提案したコンセプトに執着しない。無意識にも自分のアイデアを推しがちなので特に注意する。
スクリーニングから排除されたアイデアも、代替案を考えてまた意思決定プロセスを回す。
意思決定の締め切りを決めて、できるだけ各アクティビティを反復する。前述したとおり、各アクティビティで、コンセプトを分析・評価して、よりよいコンセプトになるようにブレインストーミングをするのですが、そこでFeasibility（技術的実現可能性）とViability（実行可能性・収益性）を忘れがちなので、特にマトリックススコア付＋リスク分析とDVF分析は反復が必要だと思います。
最後はDesirability（ユーザーにとっての望ましさ）が一番大事なので妥協しすぎない。FeasibilityとViabilityも重要ですが、そこを重視しすぎると特に誰の約にも立たないコンセプトが生まれかねません。バランスがとっても難しいですが。😶
この記事がお役に立てていれば幸いです！
来週から学校が始まるので、更新頻度が落ちてしまうかもしれませんが、引き続きご支援いただけますと嬉しいです！💐
最後まで読んでくださり、ありがとうございます！
スキ・フォローなどいただけると励みになります🕊💐
いただいたサポートは怒涛のインフレ&円安で圧迫されつつある留学軍資金の足しにさせていただきます…！😂