「EDPキャンバス」を作りました
EDPにはデザインプロセスがありません。d.schoolのデザインプロセス（下図）を紹介してはいますが、まったく重視していません。個人的には、「プロトタイプ」と「（ユーザー）テスト」さえしっかりやっていれば、あとはチームの好きなようにやって構わないと思っています。
これは「自律性や自己組織化を高める」という意味では非常に有意義なやり方ではありますが、一方で「クラス全体の共通認識が欠ける」という問題点があります。その結果「自分たちがどこにいるのか謎」「いまさらそんな指摘されても困る」「プロトタイプが完成するまでユーザーテストやる予定はない」という感想も見られます。まあ、いずれも納得できる意見ですね……（ごめんね！）。
これまでは「Dance with ambiguity」という言葉で「不確実性の高い状況に慣れることが大切だ」と言い聞かせてきましたが、それだけだとあまりにも伝わらないなぁと思うようになりまして、即席ですが「EDPキャンバス」なるものを作りました（※私が翻訳している書籍『Running Lean』の「リーンキャンバス」の構造を参考にしました）。なお、各項目は授業のおおまかな流れを表しています。2017年に出版したEDPの本をまとめるときに、それとなく規定した流れです。
各項目について説明しておきましょう：
User Journey Map
いわゆるジャーニーマップです。「観察」や「ユーザー調査」をやってから、その結果をまとめるために使います。親和図法よりも臨場感を感じながら時系列でまとめるほうが便利です。
Old Solutions
ユーザーインタビューでは「最近◯◯をしたときの経験を教えてください」という鉄板の質問がありますが、そのときに使われてきた道具をまとめておきます。今後の競合製品の調査にも使えますし、「それって、既存の◯◯で解決できるんじゃない？」という指摘を回避するためにも使えます。「共感」のあとに少しサーベイしておいたほうがいいでしょう。
POVとHMW
収集したデータを「タテマエメソッド」にまとめ、さまざまな切り口で加工していきます（HMW）。詳しくは、EDPの本を読んでくださいw
Design Principles
EDPの本では「デザイン原則」として紹介していますが、アイデアの方向性や価値基準をまとめるものです。具体的なアイデアは、教員からダメ出しされたり、ユーザーテストで受け入れられなかったりするので、アイデアを何度でも生み出せる「メタな原則」のほうが、実は大事なのです。
User Experience
ソリューションがまだない段階で、ユーザー体験をデザインしていきます。ふつうの4コマ漫画で構いません。通常であれば、3コマ目にソリューションを登場させることになりますが、初回は空欄でも大丈夫です。少しずつ完成度を高めていきましょう。
Touch Point
マーケティングの用語だったり、ジャーニーマップで使われる用語だったりする「タッチポイント」は、ソリューションとユーザーが接する時期・場所・文脈を規定するものです。［User Experience］のところはマクロな視点で、［Touch Point］はもっとミクロな視点です。リーンスタートアップのMVPのように考えても構いません。また、ユーザーテストの対象者や場所を特定するための準備として使うこともできます。ツールとしては、エレベーターピッチなどバリュープロポジションを表すものになります。
Differentiator
リーンキャンバスでいうところの「圧倒的な優位性」です。ただ、EDPではビジネスの観点は対象外なので、一般的な「差別化要因」を意味しています。当然ながら新しいソリューションにも競合製品はあるわけで、それらとの違いが何なのかを明確にしておきましょう。自分たちが「強み」と思っていることが必ずしもユーザーから見た「強み」であるとは限りません。したがって、自分たちの想定ではなく、ユーザーテストで検証できた「優れた点」をここに書くことにします。ユーザーから「推薦の言葉」をもらえれば、強い説得材料になります。また、ここで得られた知見をもとに、［Design Principles］をアップデートしておきましょう。
New Solutions
これまでのやり取りを何度か繰り返したあとで、目に見えるソリューションを少しずつ構築していきます。ただ、これで終わりではなく、［User Experience］をアップデートすることが求められます。
これまでの説明を図にまとめておきましょう。EDPキャンバスにd.schoolのデザインプロセスと同じ色の矢印を追加してみました。
ユーザーリサーチのあとに［User Journey Map］をまとめます。サーベイが必要なら［Old Solutions］を経由して、特に不要なら［POV］と［HMW］に流れます。ここまでに「共感」「問題定義」「発想（の準備）」ができていることになります。
ここから「発想」で［Design Principles］を作っていきます。EDPの本では、「雑談」と「落書き」によるアイデア発想を推奨しました。
そこから［User Experience］をプロトタイプします。初回は1枚のチラシや4コマの漫画で構いません。少しずつ精度を高めていきます。［User Experience］で特に注目したい部分を［Touch Point］として抜き出し、その相手にユーザーテストを実施して、［Differentiator］を特定します。デザインプロセス「プロトタイプ」や「テスト」の段階になります。
ここから先は説明の繰り返しになりますが、得られた知見を［Design Principles］に戻したり、実際に［New Solutions］を構築したりして、「プロトタイプ」→「テスト」→「プロトタイプ」のループを繰り返していきます。
何度もやっていると［Design Principles］の情報量が変化していくと思います。ソリューションがうまくループにハマると、フィードバックも好意的なものとなり、だんだんと情報量が増加していきます。逆に低減しているようなら、思い切って前段階に戻り、仕切り直しをする必要があるでしょう。プロトタイプができているのに、いつまでも「POVは何なの？」と指摘されるチームがありますが、これはPOVの字面を更新しろというよりも、［Design Principles］が低減しているのでもっと明確化しろ（そのためにPOVの字面を更新する必要がある）という意味だと思います。
「EDPキャンバス」のPDF版をダウンロードできるようにしておきましたので、ご自由にお使いください。😊
