CSS Nite in Kobe, vol.48「ウェブサイトの課題発見とアイデア創出の方法を学ぶワークショップ」に参加してきました

先日開催されたCSS Nite in Kobe, vol.48「ウェブサイトの課題発見とアイデア創出の方法を学ぶワークショップ」に参加してきました。

今回の登壇者

今回の登壇者は株式会社まぼろしの益子 貴寛(ましこ たかひろ)さんと松田 直樹(まつだ なおき)さんのお二人です。

今まで何度もCSS Niteで登壇されていて、去年もウェブサイトのカイゼンをテーマにCSS Nite in Kobeで登壇していただきました。

そんなお二人に、ビジネスフレームワークやデザインフレームワークの活用方法や、ウェブサイトの課題を見つけるための「イシューマップ」という手法を、ワークショップを通して学びました。

フレームワークの使い所

まず、フレームワークは「いいとこどり」で使えばOKと仰っていたのが、印象的でした。

たしかに、フレームワークはあくまでも何を考えればいいのかある程度用意してくれているものなので、フレームワーク自体よりも、それを使って戦略を立てる方が大切ですよね。

また、現在存在しているフレームワークは「ビジネスフレームワーク」と「デザインフレームワーク」の2種類に分けられていて、それぞれ影響する成果物が変わってきます。

そしてフレームワークを選ぶときの4つのポイントが紹介されていました。

1. 目的に合っている
2. わかりやすい
3. 比較できる
4. 共有できる

ビジネスフレームワーク

• 3C
  • AB3Cという手法も考案されているそうです
• SWOT(スワット)
• 4P/4C
• ベンチマーキング
• ポジショニングマップ
• STP
• PDCAサイクル
• KPIツリー

企画提案書にフレームワークを載せるときは、「ベンチマーキング」などで文字やデータを見る必要がある論理的なものと、「ポジショニングマップ」などの見て間隔で理解できるものの2つを用意していくと、良いそうです。

デザインフレームワーク

• UXハニカム
  • レーダーチャートにすると視覚化できて良い
• ペルソナ
• カスタマージャーニーマップ（CJM）
  • AISASの法則にもとづいて作る
  • 具体的なアクションは後ろから2〜3番目にする
• デプスインタビュー（インデプスインタビュー）
• イメージボード（ムードボード）
• ストーリーボード
  • カスタマージャーニーマップの視覚化に有効的

デザインフレームワークだと制作者に馴染みがあるものが多いですね。

個人的には、UXハニカムをレーダーチャートにするのが衝撃的でした。
「価値の創出」は他の合計のようなものなので、それ以外の6つの項目を数値化してレーダーチャートにします。

なにが足りていないのかひと目で分かるようになりますし、クライアントとの合意も取りやすいですよね。

イシューマップ

そもそもイシューマップの「イシュー」の今回の定義は下記2つのどちらかでした。

1. 2つ以上の集団感で決着の付いていない問題
2. 根本に関わる、もしくは白黒がはっきりしていない問題

漠然とした課題の中から、これらのイシューを抽出してマッピングするのがイシューマッピングです。

そして、イシューにも「良いイシュー」があり、ポイントが説明されました。

1. 本質的な選択肢である
2. 深い仮説がある（前提の考察）
3. 答えを出せる（答えが出せないものは考える必要はない）

イシューの抽出

まずはマッピングするためのイシューを抽出するワークショップを行いました。
お題は「多くのウェブ制作は、スケジュール後半が押してしまう問題」についてです。

このお題に対してのイシューを大量に出し、出したイシューに対してさらに分解したり、細かくできそうであれば更に出していきます。

マインドマップに少し近いかもしれませんね。

イシューの整理（マッピング）

出てきたイシューを、今度は縦横2つの軸で整理（マッピング）します。

今回の場合は縦の軸が「外的要因と内的要因」で、横の軸は「時間（制作の前半、後半）」で、出てきたイシューがどの辺りにあるのか整理します。

この軸に関しては、お題によって変える必要があり、何を軸にするかによって結果も大きく変わってきそうです。
例えば、今回の場合は「外的要因と内的要因」の他にも「論理的と感情的」みたいな視点で出てきたイシューを分類しても面白かったかもしれません。

解決策の作成

できあがったイシューマッピングを見て、解決案を作成します。

問題の時期や、要因が整理されて見やすくなっているので、「それをあらかじめ阻止するためにはどうすればよいか？」という発想で解決策を考えてきました。

あとはできあがった解決策が抽象的だと、そのあとに実践しにくくなってしまいます。
ただ、この部分に関してはどうしても抽象的になってしまう気がするので、解決策を作成したあとに、どうやって実践していくか「落とし込む工程」というのが必要になるかもしれません。