デザイン思考ワークショップで富士ロック子さんをつくった@DevLOVE

最近、勉強中のデザイン思考について、昨日(2010/07/24)、DevLOVEでワークショップが開催されました。
ワークショップの講師は、棚橋弘季さんでした。
『ペルソナをつくってそれからどうするの?』や『デザイン思考の仕事術』の著者としても知られている方です。

最初に「デザイン思考とはなにか」という説明を棚橋さんから受けました。
デザイン思考によるプロダクトの作成においては、ペルソナとシナリオの2つ成果物が大きな役割を果たします。
ペルソナというのは、つくろうと思っているプロダクトや解決しようと思っている問題に関わる「仮想」の人物像です。
一方、シナリオというのは、「仮想」の人物がプロダクや問題の状況下においてどのような行動をとるか、を考えるものです。

今回のワークショップでは、旅行サイトの集客を増やすことを目的としたサイトリニューアルを想定し、ワークを行ないました。
大まか流れとして、まずは3人の実在の人物の調査結果から2人を選択し、1人のペルソナを考え、シナリオを抽出します。
情報の抽出と整理には、KJ法を使用します。
その後、KJ法によってペルソナとシナリオを活かしながら、理想となるサイトについてペーパープロトタイプを作成し、終了、というものです。
だいたい1チーム5から6人に分かれて作業を行ないました。KJ法は以下のように壁に大きめの用紙を張っておこないました。

その分析の結果、私たちのチームはいかのようなペルソナを作成しました。

富士ロック子さん
-ライブ好きでネット好き
-アイスクリーム作りが趣味
-ライブがゆくのが目的で旅行する
-時間があって興味がそそられたら観光名所もゆく
などいうペルソナを作ったのですが、この時点ですでに講師の棚橋さんからは「アドバイスできない。笑」と言われてしましまた。

というのは、3人から2人を選択した時点で、あまりにも共通項の少ない人物を選択したために、2人の人物像がうまく統合できなかったためです。
ちなみに、課題終了後には、このペルソナづくりは非常に重要で、ここの誤りはプロダクトでは取り戻せない、というお話がありました。
考えてみると、ペルソナを作成されると、このペルソナ(富士ロック子さん)へ向けて、プロダクトを作成するのですから、当たり前ですね。
ということで、私たちのチームは、この失敗ペルソナ、富士ロック子さんの呪縛から逃れることはできず、ちゃんとしたプロダクトを作ることができなくなってしました。
ただ、個人的には、KJ法を使用して富士ロック子さんを作成するくだりが一番、面白かったのですが。

ちなみに、本来のプロダクトを作成する際には、実在の人物の調査は5人程度、この調査結果をKJ法により分析すると、分析だけでも1日ちかくかかるらしいです。

その後は、抽出したシナリオからユーザー(富士ロック子さん)要求や要求を満たすためのコンテンツを考える作業に移りました。

ユーザーの要求については、作成したペルソナや抽出したシナリオからあまりにも離れすぎてしまうと、ごくごく一般的なプロダクトになってしまいます。
こうなるとペルソナやシナリオを作った意味はなくなってしまいます。
と同時に、あまりにペルソナにこだわり過ぎると、偏ったプロダクトが生まれそうな恐怖もあります。
実際に、私たちのチームは、そもそも富士ロック子さんが偏ったユーザー像だったために、プロダクトが偏ったものになりました。
良いペルソナやシナリオがないと、よいプロダクトを生むことができないのでしょう。

最後に、上記で抽出した要求から考えだされたコンテンツを元にペーパープロトタイプを作成しました。

ペーパープロトタイピングは楽しんでやることが重要ですね。
あんまり「絵ごころないしなぁ」とか考えてやってもプロトタイプが作られませんし、作ってゆくたびにうまくなってゆくはずです、きっと。

以上が、私たちのチームで作成したペルソナ、シナリオ、ペーパープロトタイプです。
これらの一連の作業は、思ったよりも疲れると同時に大変楽しいものでした。

と、これだけで終わってしまうのはなんので、ワークショップを通じて学んだことを以下にまとめます。

<エンタープライズでもペルソナを書く意義はある>
ペルソナやシナリオを作成する価値はどの程度あるのでしょうか。
iPodのようなクリエイティビティあふれる商品を生み出したい、と考えるのならいざしらず、エンタープライズなシステムを開発するうえでどれほど価値があるのでしょうか。
想像の段階ですが、価値の1つに教育のコストの低減が考えられます。

棚橋さんいわく、デザイン思考の目的の1つは、イノベーションを起こすこと、すなわち、新しい価値観や生活の様式をユーザーに提案することです。
デザイン、としていまappleなど注目を集めているのは、この点についてでしょう。

そして、もう1つの目的は、ユーザーの”?”、疑問をなくすことです。
たとえば、なにかの道具、アプリケーションを目の前にしたユーザーが「いったいどのように使えばよいのだろう?」という疑問をなくす、これは非常に大切な事です。
というのは、エンタープライズ向けのシステムを刷新すると、今まで使い慣れていたシステムを捨てなければならないからです。そして、新たなシステムを使用するためには、その使い方を覚えなければいけません。
システム屋の目線からは、そのほうが情報管理もシステムの構成もすっきりと使いやすいシステムを作ったつもりなのですが、それを使うユーザーからしてみると今まで使い慣れていたシステムが使いづらいものになってしまうのです。
そのために、ユーザーの側では教育期間をもうけてシステムの使用方法をユーザーが覚えなければならず、システム屋は(システム屋の)みんなが嫌いなドキュメント作業にとりかかり、それほど質の高くない操作マニュアルを作らなければいけません。

現状、こうした教育コストを減らす試みの1つは、「元のシステムと同じ画面」で作る、というものです。
たとえば、汎用機上に載っていたシステムを、マイグレーションする際には、使い慣れているように「TAB」と「ENTER」で移動し、マウスでのクリックは出来ないようにするのです。
たしかに、それも1つの手段ではありますが、たとえば今年、新入社員で入ってくる人にとっては、操作方法がほとんどわからないでしょう。

新入社員、にフォーカスをすると、既存の社員との相対的な数は少ないうえ、教育費もある程度、見込まれているので教育という観点からは痛手を感じることはないかもしれません。
とはいえ、今後はダイバーシティという価値観から、目が見えないなどのハンディを抱えた人やそもそも日本語を母国語としない人々が増えたり、一斉、定期的な新卒採用がなくなったりした場合は、スキルセットも経験もバラバラで、一括で教育を施すことが難しくなってゆくでしょう。
そうなると、システム屋が書いた分かりにくい日本語のマニュアルをポンっと渡して、「使い方を覚えておいて」などとは言えなくなります。現在でも、そのようにできない部分はやはり先輩社員や上司が、その目的と使い方を教えなければならないのです。

そうしたちょっと遠い未来においては、誰でも直感的に使用方法がわかるシステムは教育のコストを減らすためには有効なのではないでしょうか。

ただ、「誰でも」というのは、ちょっと曲者な言葉です。
受託開発のシステムにおいては、法律など各業界の標準に則る必要がありますし、各会社の業務に則る必要があります。
もちろん、業務についても業界における標準のようなものがあるのですが、標準を越えた独自の部分は存在するのです。
その独自の部分を取りこぼさないことが、ユーザーのシステムの使いやすさに、通じるのだと思います。
なぜなら、その点が他の人たちにはなにその人達が固有に抱える問題であり、共有している価値観であるからです。
そして、その問題を解決し、価値観に訴えることが、使いやすさに通じると思うからです。
そのため、やはり「誰でも」というよりは、ターゲットとする「誰か」に届ける必要があるのです。

たとえば、教育のコストを下げるため、直感的に使いやすいシステムを、考えても、

・PCをよく利用する人なのか、全く使用しない人なのか
・業務知識がある程度ある人なのか、ない人なのか
・席に座ったま使用するのか、工場や売り場などでたったまま使用するのか

など、システムを使用するユーザーの使用状況や知識レベルを理解する必要があります。
ペルソナやシナリオはこうしたユーザーの行動や性質を理解するために作成されるのです。

棚橋さんの言葉で感銘を受けたのは、

同じものでも使用状況によって価値が変わる

という言葉です。
そのために、ユーザーが一体どのような人たちで、どのような状況のおいて使用するのか、をインタビューなどのユーザーへの調査やKJ法による分析、そして、ペルソナとシナリオをづくりと通じて理解するのです。
そして、こうした理解の先に、システムのコンセプトが生まれます。
ワークショップでも、どのようなユーザーに向けて、どのようなシステムを作るのか、というコンセプトを、ペルソナとシナリオを描けたチームのペーパープロトタイプは、しっかりとしていました。
ちなみに、ペーパープロトタイプの良さは、「たくさんの質問、疑問が発生すること」だそうです。
そのようなペーパープロトタイプは、ワークショップでは1チームしかできてきていませんでした。

情報収集→KJ法による分析→ペルソナ・シナリオづくり→プロトタイプの作成→プロダクトの作成、という流れの中では、1つ1つの作業が重要になります。
そして、前段の失敗は、後段ではなかなか取り戻すことできません。そのためにも、早めの失敗が重要です。
ペーパープロトタイピングはまさに、失敗に早く気づくための方法の1つでしょう。
また、直接、触れられてはいませんでしたが、安上がりに失敗する、という視点も必要なのでしょう。
早めに失敗しても、その時に大金を失っていては、失敗を取り戻すことはできません。
紙を使う、というコンセプトが、安上がりに失敗する、failcheapという観点を含んでいるのだと思います。

また、デザイン思考において、固定的なプロセスはない、と棚橋さんはおっしゃっていました。
なんだか、アジャイル開発に通じるものがありそうです。
ということは、知ることは簡単でも実践は困難ということでしょう。
今回、ペルソナ作りに失敗したことは、難しさに触れることができた、良い経験なのだと思います。

ランキング参加中。気に入ったら一押しお願いします!
人気ブログランキングへ

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中


%d人のブロガーが「いいね」をつけました。