KNLog: 2011/07

2011/07/30

経験と言う名の授業

インターネットが普及していろーーーんな知識をweb 上から得る事が出来る。

これだけって思われるかもしれないけど、 [KNLog: ME310 を通じて自分なりのまとめ]の中に1年間学んできた事はほとんど書いた。。。と思う。

自分が頑張って得てきたものをこんなに簡単に公開してしまうのはもったいないとか、最先端な事を学んだのに秘密にしておきたい事とか正直若干あるけどでも公開したのはきっと今回のテーマで言いたい事が絡むのだと思う。

今の世の中何かを秘密に心に置いておいたとしても、頑張って調べればここに書いてある内容なんていくらでも手に入るだろうし何かを自分が思いついたとしても大抵の事はもう既にされている。

自分よりも頭のいい人だっているだろうし、文章書く事が上手い人もたくさん居るし、アクセスたくさん集める人もたくさん居るし、情報なんていくらでも転がっている。

そういった意味で情報の格差ってのはまー広がるって見方もあるけれども二極化してしまってる気がするんだ。そして二極化のうちのたくさん情報を得ている人が得る事の出来る情報量って、人と人との間にそこまで差は無いのではないかって思う。

今後インターネットを使わない人は居ないだろうし、そういった意味で情報は何でも転がっているような時代が来る。全ての人が同じ量の情報に、同じ確率でアクセス出来る可能性がある時代がくるんだ。
そしてその膨大な量の情報は google なのかどこなのかはわからないけどそれらの会社によって管理され、より精度よく誰も二届けられる。そしたら・・・今度は何が重要になってくるんだろう？

というか今そもそもこうやって自分が「知識の共有」として書いている事は将来どこかで価値となるのだろうか？

この間ENPC (Paris の大学) と Stanford でそれぞれ同じME310のプロジェクトをとっていた人と飯を食いにいった時に、今度は「経験」ってのが大事になるんだろうなって話になった。

確かになーーー。画面から「経験」を伝える事ってのはどうも出来ない。
たとえば自分が「ボールの蹴り方」をブログで丁寧に1時間くらいで読める長さに書いたとしても、それは実際にサッカーの練習を1時間した人の方がためになっているだろう。

って孔子の言葉好きなんだよな。自分で考えてるだけじゃだめ！でも本とか読んだり教わったりしてるだけでも自分で考えなかったらだめ！両方しなさい！って意味なはずなんだけれども（間違ってたらごめんなさい）更にそこに経験しなきゃだめ！って事を付け足したい。まー孔子の言った「学ぶ」の意味の中に経験の概念も入ってるのかもしれないけど今だからこそいっそう強調して、経験という言葉を入れこみたい。

モノを知っているって事にどれだけ価値があるだろう？あるかもしれないけどそれに価値の重きを置いたらそれこそコンピューターの方が価値が出てきてしまう。何が出来る、に価値があるって訳でもない。その人の得てきた経験、そしてそこから出てきた個人の「考え方」にこそ価値が出てくるのではないか？

なんか話は哲学的になってしまうかもしれない。誰もが自分なりの哲学を持っているけど、それはおそらく経験から来た哲学。それは唯一のモノだし、それを嫌う人も好む人も居るだろう。例えば哲学書を100冊読んで積み上げてきたその人の哲学と、恋愛でもサッカーでも旅でも仕事でも頑張って自分で考えて掴んだものがある人の哲学、どっちが親しみやすいかで言ったら個人的には後者。大抵の人がそうだと思う。

哲学ほど非生産的なものはないかもしれない。俺の知り合いは片思いほど非生産的なものはないと言っていたけれども。
そんなの仕事とかには関係ないよーってなるかもしれない。

でも個人的な考えでは・・・人間の周りにはどこまで言っても人間が居て、何をしていても最後には人の考え方がモノを言う。何をしていてもどこに居ても、自分の行う事には「プロセス」が存在し、そのプロセスに当てはめられる「公式」は年々多様化していく。
だったら公式を何かから覚えるよりも、自分の哲学から「自分なりの公式」を毎回導きだせる事が今後必要となってくるのではないか？？

彼女が出来るとこんなにいいんだぜーって誰かに言われるよりも、自分で体験した方が楽しいし分かりやすい。

デザインシンキングって何？って人に聞くよりも自分で体験した方が良い。

そこから導きだされる答えが人と同じとは限らない。でもそれを個人として大切に育てていく事、それを他人とぶつけ合って少しずつ変えていく事が人としての成長なのだと思う。

この記事もそう。形にしてしまう時点でおそらく他人にそこまでは伝わらない。同じような考えをもった人には伝わるかもしれないけども人の考えなんて100％伝える事は不可能だ。
それにこうやって考えている人は世の中にいくらでも居る。それを表現している人もいくらでも居る。だから「このブログも他の記事と同じようなこと言っているよ」って思う人もいると思う。ただそれでもいいんだ。この記事は誰かが言っていた事ではなく、自分の経験が導きだした、自分なりの答え。(とは言え友達との話の中からinspire されたのだけれどもw)この「答え」ってもっと丸く言えば自分なりの考え方。人と話してどんどんその形は変わっていくと思う。

でもこうやって何かの経験から何かを感じ取る、それに喜びを感じられるような生き方で居ようと思う。

そういった意味で「知識」や「スキル」以上に「経験」をくれたME310のプロジェクトには本当に感謝している。

経験を得る上で大事なのはおそらく「環境」。人生の中で自分ほど「環境」に恵まれている人は居ないんじゃないかってくらい自分は環境に恵まれていると思う。親もそうだし友達もそうだし学校もそうだし留学とかもそうだし。
今度は自分自身がそのような環境を作れる人として存在していきたいと思う。

なんだこの意思表明ブログw　すいません。

留学とか旅行とかに限らず、「環境の提供」ってvision を持った会社ってのも大成するかもなーなんて思ったり・・・

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/29

Think to build, build to think

Think to build, build to think.
特にbuild to thinkはME310@Paris の中ではキーワードみたくなっていた

「プロトタイプは疑問にこたえる為に作るもの」ってことは色んなところで書いていた。　(よい疑問を持てば、プロトタイプの形は見えてくる, モックアップとプロトタイプ, プロトタイプは状況に応じて時にラフに、時に詳細に, デザインは人のニーズを満たす物として然るべき, 社会的プロブレムと個人的プロブレム, プロトタイプの限界)

もちろん疑問って、考えていっても自分なりに考えれば答えが出てしまうもの。そうして考えて考えて、最終的にひとつのプロダクトを作るのもある意味よい事かもしれない。
もっと言えばプロジェクトを進めている時によく

「作るのに時間がかかるから考えてから作ろう」

ということを考える。
ただ・・・もっと身軽に行った方が良い時が多い。考えているときには思いつかないことが、プロトタイプを通じて見つかったりする。

だから「とりあえず作ってみよう！」ってのも大切。
よくわからんけどとりあえず作ってみよう！って手を動かす事で、それをテストさせる事で思いもしないものを得れたりもする。

たとえば下の写真は、フィードバックが水の使用量を減らせるかという疑問を持った際のプロトタイプ

まーよくわからないけど、とりあえず作ってみた。

ここで得られた知見にも、面白いものはあった。
たとえば

とか

とかなんとなく期待していない意見が得られた。もちろんカロリーに似せた覚えなんてないし、水の量もホントは水道をまねて作っただけだからそこは感じてほしくなかったってとこが正直なところだし・・・
でもそこから例えばカロリーを減らそうと頑張っている人には何が効果的なんだと調べることが出来たり、水の量に限りがあるように見せたりする事で使用量を減らさせる、などちょっと発展させる事が出来る。

さらにそゆのって人からの意見／人を観察して得られた知見であるので結構自信をもって進める事が出来るし、それもプロトタイプとして別にミスってもいいから、って感じで進めて行ける。またそこから何かを得られるかもしれない

虎穴に入らずんば虎児を得ず、ではないけどとりあえず作ってみる、それが案外色んなところに導いてくれたりもする。

もちろん毎回ではないけど。

ただそんな作ってたら時間ないよーとか思われるかもしれないけど、例えば先の画像のバケツのプロトタイプなんて1時間やそこらで作れる。それをテストするのだって一人５分程度しかかからない。それらで得られた知見について進めていく事が出来るのは大きい事だと思う。

あと微妙に思ったのが「作る事」＝プロトタイプではないという事。またプロトタイプでなかったら作っていけないなんてルールもない事。もしかしたら電車で５時間行ったところにあるようなものを使っている人を観察するよりも、同じようなものを作ってそれを使っている姿を観察する方が効率的かもしれない。そういった意味で作ったものは、モックアップではあると思うけどプロトタイプではない。ただ、「観察」も重要であるしもちろん時間の許す範囲でだけど、何がプロトタイプで何がプロトタイプでなくて、なんて考える前に、ちょっとこれどうなんだ！って思ったら作ってみるのが得策なのかも知れないデスネ

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

コミュニケーションにおけるFace to Face の強み、スカイプとの違い

ME310のプロジェクトでは、チームワークとチームマネジメントでも説明したように俺はFrance 4人、Finland 4人のチームの中の一人だった。

時差は1時間とあまり遠くないとはいえ、そんな頻繁にあえる訳でもない。
ただ進捗や今後の計画等はやはり情報交換していかなければひとつのチームとして進んでいく事は出来ない。

そこで役に立ったのがSkype だった。

今更説明なんていらないと思うけど、最近では色んな人がスカイプの恩恵を受けていると思う。

ただやっぱり・・・Face to Face で居る時とSkype で話しているとき、チームとしての進み具合は格段に違う。なにが違う要因となっているのかってことを深くまで突き詰めれば研究とかにまでなりそうなイメージ。

もちろんSkype でブレストする事も出来ないのは何となく直感的にも分かると思う。ホワイトボードに向かっていなかったり読み取れない状態でのブレストは若干きついものがある。

ただそれ以上に、ただ単に進捗を伝えるだけでもSkype の方が遅いしなぜか上手く伝わらない。

個人的に思った、ツールの強みと弱みのまとめの様な表が以下。

ほんっとに個人的な感想です。異論はいくらでもあると思います。もちろんgoogle doc とかtwitter とか他のtool もある訳で．．．
それからいくつかは組み合わせる事でさらに力を発揮します。例えばブログとfacebook. ブログアップしたぜって事をfacebookで伝える事にした場合に、もっと上手くコミュニケーションはとれたり。ブログは実際クライアント側とのコミュニケーションにも使ってた。

ただ個人的にはblog よりもwiki の方が良かったと思う。

face to face の中で個人的な話が○でスカイプが◎なのは、場所の問題。例えばプロジェクトの事じゃなくてもチームの中でうまくやっていってるかとかそういう話はむしろみんなが居ない方がやりやすい。French culture の中に一人飛び込んでいった俺を、finns はめっちゃ気にかけてくれたりしていた。そゆときにskype はパワフルというか・・・

進捗報告もブログが有効と書いたけど正直○と◎で迷ってた。ただたとえば画像とかを準備出来ればface to face の方がもちろん強い。ただ例えば英語でうまく伝えられない時とか逆に準備してブログ等でどうだったって紹介したりする事は結構うまく伝えられたりする。
もちろんインパクトは少なくなってしまう時とか思い入れがあればあるほどたくさん書いちゃう→読む気なくなっちゃうみたいな悪循環もたまにあるから気をつけなくちゃだめだけれども。

ただほとんどの場合でface to face が強い。これはどうしようもないのかなーーー。

昔Idea blog の方（KNIdea: Video chat for Distant Team Work）にこうやったら遠隔地でも上手く行けるんじゃないか！って感じのを書いたけれども、それでも分からないからなー

尻つぼみな記事になってしまったけど、Distant なチームとプロジェクトをやる際にコミュニケーションツールというのは上手く選ばないとかなりきついです。チームワークとチームマネジメントの記事も参考にしてください。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/27

インプットとアウトプット

日本人とフランス人、もしくは欧米の人全般かもしれないけどアウトプットの違いがとてつもない。

理系的に言うと
output = f(input) である事は誰もが納得してくれると思うんだけれども

fj(x) ・・・・japanese の関数
fe(x)・・・・europeanの関数
とするとおそらく
fe'(x) = 10fj'(x) くらいある。

きもいなこのたとえ・・・

健全な形に話を戻しますw

例えば話しの仕方。

話を盛ると言ったら言い過ぎだけれども、とにかく伝えるのが上手い人が多い。政治家向きかな。
ホントに少しの事でも大きくやったように話す事が出来る。

なんでこんなに上手いんだろうと思って聞いた事がある。特に文系出身の人に突出してその上手さはよく見られる。んで聞いてみた。
そしたら授業の一貫でSpeech があるらしい。
「AとBとC ってキーワードで10分間スピーチしなさい」
ってのを毎週？だか毎回の授業でだか分からないけどやるっぽい。
日本人的な感覚で言うとなんかムダだなーって思ったりするけどやっぱりプレゼンの時とか交渉の時とか、自分たちがこんなに大変な事をやったんだ、とか女の人を口説く時とか(?) かなり役に立っているのを見る。

Whereas 日本人はinput に重点を置く気もする。
関数f は社会に出てから見つけるという暗黙の了解、もしくはそこに関数があるかすら分からない。

例えば今回プロジェクトでArduino とか使って電子回路？的な電流とか電圧とかの計算をしまくってる人が居た。自分も物理のテストの紙の上に書いてあれば出来る自信はある。でもその機械を見て、ここがこれで・・・って実際に使う事は出来ない。それはfに代入するやり方を知らないから・・・ってことにしたら上手く説明つくかな・・・

東大からStanford に行った友達と話をした時もそんな事を行っていた。授業としては東大の方が難しい事をやってる。ただこっち（Stanford)はそれを社会で上手く使う方法を知っている、と。

それは自分も思う。「如何に社会に役立てるか」が勉強、もしくは工学の意義であるとしたらそれを教えないのは言語道断。。。。な気もする。

Franceの理系の大学では入ってすぐInternship を強要される。それも本当にいい仕組みだと思う。社会を知って、自分の学ぶ分野を明白にした上で勉強に従事する。
日本の社会はInput の社会。個人的には世界一だと思ってる。。。インドとかは分からないけど。。。

ただそれを関数に代入する発想すらない事が多い。自分たちの関数は紙の上にしか応用出来ない。

まーこっからだな！input が実は一番大変な作業だってことを本能的に知ってるんだと思う。だからそれを出来る日本人は強い！でもそれをoutput に変換しない事にはまさに宝の持ち腐れ。

という事でどーやってこれが使えるかってことを考えながら勉強していけたらなって思います :)

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/26

Catch me if you can, I am a Computer

最近ずっとME310のネタばかり書いていたのでちょっと変えてみる。

タイトルはパクリです。すいません

インターネットが世に広まってきて１５年以上。
昔インターネットが出てきた時の事は何となく覚えている。

その当時８歳前後だった私も、Windows 95 とかそこら編の名前を聞くと懐かしいと思える。
じぶんが初めて使ったパソコンは覚えてないけれども、自分の家でWindows me がを使った時の感動は鮮明に・・・と言いたいところだが、なんとなく、覚えている。

もちろんそれ以前にそんなハイテク機械など家にはなかった訳で。自分になじみのあるディスプレイはテレビのみであり、機械といったらスーパーファミコンであった。そんな私に、パソコンというのは明らかに異次元への入り口であった。

共感する人も居るかもしれない。
昔、パソコンは何が出来るの？と聞かれたらすぐさま「インターネット」と答えた
インターネットってなに？と聞かれたら、あの青いe のマークに輪っかのついたようなあのInternet Explorer のアイコンの事だと思っていた。
そしてそれは同時に、Yahoo から始まるものだと思い込んでいた。

というよりも
パソコン=インターネット= yahooのトップ画面
であると思っていたといっても過言ではない。たまにゲームも出来るくらいだ。ただそれも、インターネットのおまけくらいにしか思っていなかった。
IE のアップデートとかをしてしまった暁にブラウザを開いてもyahooのトップ画面が出てこなかった日には、それはもはやインターネットでなくなってしまったかと思うほどだ。

いつ頃からトップページとしてgoogle を使いだし、レポートとしてword を使い、計算にexcel を使いだしたのかはわからない。いつから、パソコンは「インターネット」でなく、「なんでもbox」になったのかは分からない。
ただこれは明らかな前進である。この一見単純なようで大きな前進はとてつもないvision の変化である。なぜか？

私の名前はKenji である。
私はMichael でもある。
そして Robert でもある。

とまぁなんとなく３つの名前を書いてみた。
何言ってんだこいつ？と思った人も多いだろう。
もちろん私の名前はKenji だけだ。ただ先に述べた大きな前進とは、私にこの３つの名前、もしくはそれ以上があると本当に信じ込む事と同じなのである。

どういうことか？
今我々はパソコンを通じて、もちろんインターネットを通じてで色んなものを経験している。いろいろな情報にアクセスし、いろいろな操作を行っている。
ただ考えてほしい。パソコンがなかった時代の事を。
家には何があっただろうか？

寝るための布団
遠隔地と通信するための電話
明かりをつけるための電気
紙を送るためのFax
風邪を送るための扇風機
室温を調節するためのエアコン
時間を見るための時計

これらすべてがひとつの目的のために、ひとつのものが存在している。
つまりひとつの目的に応じてハードもひとつ存在する事が当然であったのだ。

まるで人間の名前のように。

ただパソコンはどうか？

Facebook を使い、Twitter を使い、ブログを使い、google を使い、word, excel, illustrator, photoshop, power point, keynote, .... 数えきれないほどのアプリケーションをひとつのパソコンという中で用いている。

携帯電話でも電話をし、メールをし、ゲームをし、・・・さまざまな事をしている。

それは実はインターフェイスを語る上ではとんでもない進歩なのではないかと勝手に思っている。

パソコンをひとつのインターフェイスとして考えると、パソコンはまさに何でもインターフェイス。

さっきの例でいえば、誰もがなにを疑う事もなく私の名前をKenji でありMichael でありRobert であると信じ込み、状況に応じて名前を呼び分け使っているようなもの。なんか恐ろしい進歩だなーって勝手に思ってしまったと同時に、それを我々や現代の子供は当然のように受け入れている事にも人間としての進化を感じる。
ただ一方でまだパソコン＝インターネット＝Yahoo の様に思っている人も居るのではないかと思ってしまう。ひとつのハードに、ひとつのファンクション、のように

全てをひとつにつぎ込んできた時代から、どっちかというと今その逆の流れも出てきている。

例えば石井先生の提案するタンジブルの概念。

触れる情報、のようなイメージだけれどもこれは情報に触るためのファンクションを出来る限り直感的に、触れるものとして作っていこうというインターフェイス。

この方が「わかりやすい」とか「あつかいやすい」と思う事が多いのは動物としての本性として「1個のモノに1個の機能」の方が扱いやすいからか、「何でもインターフェイス」にしたが故に全てに対応する事が出来ていないからか分からないけど、今後もう少しまた「1個のモノに1個の機能」の方に流れが行くと思うんだよな。

俺ひとつの名前だけで十分だもん。

2011/07/25

ME310 におけるデザイナーの役割

デザイナーの位置づけ
エンジニアとデザイナー
複数のデザイナーの共演

の3本立てで行きます。

デザイナーの位置づけ
それぞれのチームの中に、最低一人はデザイナーがいた。
といっても
Web designer
Graphic designer
Industrial designer

とかいろんな種類のデザイナーが居るわけだけれども。
チーム構成で言えば他にはエンジニアが基本的には多くて、何人かはマネジメントとかファイナンスとかマーケティングとかを専門にしている人たちも居た。

チームによって"designer" の役割ってのは結構違うのが面白かった。
たとえば
アウトプットに力を添えてくれるデザイナー
コンセプトを上手くシェアしたりするためにvisualise するデザイナー
visual 化するときに力を発揮するデザイナー
シナリオなどを上手く考えていくデザイナー
デザイナーとしての視点からチームをまとめて進めていくデザイナー

上手く言えないけど、最後のデザイナーの種類ってのは今までデザイナーとしてイメージするデザイナーとは違った。 Design 的なプロジェクトを何度も経験したことがある人だったからかもしれないけどそういったDesigner としての視点とかDesigner としてのやり方的なものをチームに上手く浸透させていく感じ。

なんかそういう人を見ていると絵を描けなくても、3Dのモデルを作れなくても、デザイナーって言ってもいいんじゃないかなって正直おもった。
サッカーの監督、とかなイメージかもしれない。サッカーはもちろん知ってなきゃダメだけど、とてもいいプレーヤーがいい監督になるとは限らない。ただプレーヤーであれ監督であれ、くくりはサッカー人。デザイナーって言葉はサッカー人てきな言葉であって良いとおもった。プレーヤーではなく。監督も含むって意味で。

エンジニアとデザイナー
うちのチームではエンジニアとデザイナーで一度バトルがあったりした。使いやすさとかをエンジニアが考慮して、多少Designer が提案したものと違うwebsite の形をつくった。それを見たVisual にこだわっていたデザイナーは激怒。なぜそのレイアウトを変えてしまったのか、と。その人からすればその枠の1ミリ1ミリにこだわって作られたWebsite のvisual. それを少し移動したり違っていたりするのが耐えられなかったらしい。

へーーーーっておもった。そもそもバトルの焦点が違ったけど、こだわるところが全然ちがくて面白かった。エンジニアがファンクションにクレームを付けているのに対して、デザイナーはそれによるレイアウトの変更にクレーム。だから結局は丸く収まったんだけど、お互いに変なところこだわるなーっておもってたと思う。

個人的にもなんとなくデザイナーの考え方ってオモシロイと思った。
一番最初の遊びみたいなワークショップで自分がちょっとギークなソリューションを提案したときにちゃんとそれをシンプルに戻してくれたときがあってなんかはっとしたんだよなー。
こんな難しく考える必要ないのか、とか。
もちろんデザイナーによって趣向は様々。テクノロジー的な方向が好きな人もいれば、ディスプレイは極力置きたくないというひともいたり。
個人的に no display の方向性はかなり自分にあっていた。
Keep it simple がまさに自分の中でのスローガンみたくなっだんだ。

複数のデザイナーの共演
自分のチームの中にはデザイナーは一人だった。けどもしもう一人デザイナーが居るとしたらどうなっていたんだろうって思うことが結構あった。こいつらって共存できるのかなって…
一つコンセプトが決まったりしているときはできるとおもう。でも例えばコンセプトを最初に作るときとか。どうするんだろうっておもってた。

んでいろいろ経験のありそうなDesigner に聞いてみたんだ。そしたら会社の中にDesigner はもちろん複数いるけど、共存というよりは競争だって言ってた。Competition みたいなものをして、勝った人に従う、的な。

たしかになー。。。難しそうとおもった

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/22

プロジェクトの種類

ME310の中にはおそらく40以上のプロジェクトがあった。

なんとなくそれらのプロジェクトって形にして、タイプ１、タイプ２とかそゆ風に出来るんじゃないか、そしたらタイプ1に対してはこういうアプローチが効果的、とか言えるんじゃないかって思ってプロジェクトの種類分け見たいのが出来たらいいなって思った。

本当に頑張ってやったら論文かけそうな内容なきもする。

そして自分が今やってるのは本当に直感的で頭の中で少し考えただけのものなのであまり当てにしないでください。

ただなんか意見があったら貰えたら幸いです。

ただなんかタイプ見たいのを考えてたらプロジェクトってのがどんな構成で成り立ってるのかを考える事になってしまった。下の二つはなんとなくの候補。
穴みたいなとこを通ってgoal に向かう感じ。
一つ目はプロブレムとかニーズとかを発見して、それを人のニーズにかなうように道筋を立てて、さらに制約的な部分の穴も通ってgoal に向かう。ここで分かるように赤線はどんな穴を通ってもいいし、どう曲がってもいいからある意味ソリューションは無限。丸くしたのは、初め何となくゴールと違う方向向いてても案外面白いpath になったりするって意味を込めてあんな感じにしておいた

もう一つはrequirement って事でなんとなくまとめておいた。

ただなんか違うんだけどなー。まーでもなんとなくmake sense.

candidate1

candidate2

ここでgoal は目指すべきもの
constrains:使うべきmaterialとか budget, term, company とかによって制約される
requirements とかproblems とかneeds とかは、トピックによって決められるイメージ

なんか違うかなー。
もう少しいいもの思いついたらアップします。現在はこんな感じが限界。

ただ、双方に共通して言える事が、スタート地点から一直線でゴールが見えているとそこに気を取られがちでほかの道が見えなくなってしまう事がある。

一直線で行くと下の絵みたいになるって言われた

こんなヒドい絵ではないけどw

ただ横にはいろいろ道があって直線的に行ってしまってはいき止まる可能性が出てきてしまうってこと・・・らしい

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/20

ME310を通じて　謝辞

一応。。。書いておこうかな。
ME310を終えておもったことのまとめの記事を書き終えてから書くつもりだったけれどもいつ終わるか分からないので今のうちに

いろーーーんな事を得れた一年だった。まずは、親にありがとうと言いたい。金銭的な面でもいろいろ支えてもらったし、いろんなところでサポートしてもらった。おそらく人生の中の１大事である311の時に近くに居られなくてすいません。ただかけがえのない経験を出来ました。本当にありがとうございます。

次に・・・Sushi かな。彼はアメリカ育ちの日本人。自分にME310の話を持ってきてくれた。Design thinking の事から英語とか文化とかいろんなモノを学んだ。デザインに於いてSushi イズムが日本人やパリ d.school には浸透していると思う。本当にSushiの下で学べて良かった。ありがとうございます。

それから・・・梅室先生。東工大の教授です。このような場所に行くことを快く受け入れて下さり、またサポートしていただきありがとうございます。

と日本に居る留学生の方々。フランスから来た方々にたくさんお世話になった。ありがとう

あとは日本人留学生達。寮生活は楽しかったしみんなといた事は刺激的だった。またみんなで語ろう。つっても3/4は東工大でしょっちゅう会うけれども

ふーーあとは日本語で書いても意味ない人ばかり。
パリのT-team　みんな温かい人達でプロジェクトが成功したのはみなさんのおかげです。

あとはパリの人達とチームメンバーか。フランス人で一人日本語を勉強してるって言ってたからそのうち読めるようになるのかな？ｗ　フィンランドのチームメイトも、フランスのチームメイトもみんな最高だった。たまにストレスは溜めたけど、というかかなりストレスは溜めたけど、あのチームでよかった。めっちゃ楽しかった。もっかいなんかやりたいね :)

フィンランドの人とかもありがとう。みんなに気に入られて楽しかったよ。
パリに居なかったMEの日本人メンバーの人もありがとう。女性には理由ないけどなんとなく謝っておきます。すいません。

パリで会った人も、スタンフォードであった人も、もちろんそれはプロジェクト以外のメンバーも含めてなんかいい人に恵まれたなーーー。

いろんな人に支えられて、なにもわからずあたふたしてた毎日。
いつのまにか俺もそこに慣れてって、ちょっとはしっかりしたのかな。

成長したかはわからない。

ただ周りに成長したなって思われるように今後も頑張っていきたいです。
社会人になるまでもーちょい子供で居ます。ありがとうみなさん。

2011/07/19

チームワークとチームマネジメント

今回のお話はチームワークとチームマネジメント

ME310のプロジェクトは、全てがチームワークだった。
なんというか…学生のうちにこんなにずっと同じチームで過ごすこと、ましてやいろんな文化が合わさった中で過ごすことができたのは本当にいい経験だったと思う。
もちろんDesign thinking について学んだりもしたし、知識も増えたし「問題解決」に対するアプローチの仕方のバリエーションも増えた。
ただ、何をするに当たっても人とうまくやっていけなかったら何も出来ない。

どんなふうにこの記事をまとめようか迷ったけど、今回は箇条書きとその説明で行こうと思う

リーダーを作る強みと弱み
メンバー内でのコンフリクト
結果の共有
場所を変える
メンバーとの時間
物理的に離れたチームのチームマネジメント
分業
役に立ったツール

リーダーを作る強みと弱み
そもそもリーダーって定義が曖昧なのだけれども。。。「意思決定をする人」、「責任を負う人」、「チームのスケジュール管理などをする人」とでも勝手に定義しておきます。
この理由は・・・なんとなく自分の考えるリーダーというのがこゆ人だったから

自分たちがプロジェクトを進める際、リーダーはつくらなかった。理由は意見が偏ることを恐れたり、メンバー全ての人のプロジェクトにコミットする量が変わるのが嫌だったから。
そもそもリーダーはどのような人がなるべきかってこの間話しをした。そしたらその中に「トピックについて一番良く知っている人」という意見が出た。まー・・・賛成。
ただ今回進める上では誰もが同じ土台に立っていたし、敢えてリーダーはつくらなかった。

案外それでもうまくいく。もちろんリーダー気質の人とかはいるから少しその人が強くなったりもするけど、「権力者」みたいなのは居なかった。だからこそみんな自由に意見を言えたりプロジェクトはいろんな方向に発散できた。

そもそもリーダーをもつ理由はなんだったのだろう？
それはおそらく時間と責任。リーダーが居たほうがいろいろ長引かなくて済むし、タスクをassign するのが簡単。チームはより効率的に動くことが出来る。
上手くいかなかったらリーダーが責任を取るし、会社などではこの形がおそらく望ましい。
ただ今回は学生プロジェクト。それから、クリエイティブなプロジェクト。いろんな分野の、いろんな文化の人が集まっていた。そんな中でもしリーダーを決めてしまったら結構いろいろ偏ってしまったりしたと思う。比較は出来ないけど、そんな気がしてる。

でも例えば日替わりでリーダーのような人を作ったり、そゆのも面白い。ブレストの際に司会者を毎回変えたりした。そゆのは面白い試みだと思う

メンバー内でのコンフリクト
もしくはまぁ・・・意見の不一致とでも言うかな。そゆのはいつでも起きる。
最初の２ヶ月くらい自身も自分のあまり賛成できない意見に従事してた。
どういうふうにすればメンバーがハッピーになるのかはわからない。ただ今いえるのは打うちのチームには色ーーーんな意見の不一致があったけれども、最終的にはみんなハッピーになった。
自分はなんでその意見に反対かをずっと考えて、次にどういう方向に踏み出すべきかも考えておいた。そして少しその方向性に行き詰まったときにタイミングを見計らってみんなで話そう、という形にした。できるだけみんなが共感できるように話を進める努力をしたり、なんでこれがダメだと思うかを言ったり。
ただこれって時間とかすごいかかってしまうし難しいよなーなんて思ったり。
IDEOのことを少し知っている人に聞いたら、意見が不一致になった場合は「この週はこいつに従う」「この週はこいつ」のようにやっているところもあると言っていた。
これも面白いけど最終的にどう収束するのかはわからない。

ただ誰かしらがいいと思う方向性には「いいもの」ってのが絶対ある。このIDEO のやり方のいいところはその方向に一回みんなで進むことで一人の思っている「いいもの」をみんなで共感できるところだと思う。

多数決だと不幸になる人は最大半分いるからな。。難しい・・・

結果の共有
プロトタイプをテストした結果とか、ユーザーリサーチをした結果とか、ブレストをした結果とかそういうのをシェアするのは案外むずかしい。
例えばブレストをしていたとしよう。４人チームでそのうちの２人がブレストを頑張っていたとしよう。そして良いアイディアでたーーーーって感動することもあるとおもう。
さぁ、次の日それを残りのメンバーに伝えようってなったときに、案外その感動は伝わってなかったりする。その人からすればそれは他人の意見であり、自分なりに消化しない限り他人の意見に対していいなどとあまり言えたものでないからである。うまく伝えるために絵などを用いてもいいし、どのように順序立てて話すかを考えたり、案外結構な努力が必要だったりする。

だからこそ出来るものは出来る限りみんなで進めたほうがいい。特にリーダーとかが居ない場合は。居るときは「こうなったから」的なことを言えば済むのかもしれない。けどみんなが納得して１つのチームとして進む際にはみんなが出来る限り納得して進むことが望ましい。

場所を変える
ブレスト用の部屋とか、何かを作るときの部屋、試すときの部屋、とかいろんな用途に合わせて場所があると・・・良い・・・・
ずっと同じ部屋だと飽きてしまう

メンバーとの時間
案外メンバーの中に一人忙しい人が居たときのほうがチームがまとまったりする。それは他のチームを見てておもった。うちのチームはほぼずっと一緒だったからメリハリがなかった。いつ何を始めるのかも分からなかったり、隣にいても横が何をしているのか分からない時があった。
そんな時のために（単純だけど）朝集まって、今日は何をしようか、というふうに話しあって最後にそれをシェアするのは本当に大事。

物理的に離れたチームのチームマネジメント
ちょっと図の構成が酷いのは気にしないでください。ME310内での自分のプロジェクトは、フランスでのチームとフィンランドのチームが共同で協力してやりました。下の図みたいなイメージ。

図フランスのチームとフィンランドのチーム

こう言ったときに、もちろん意思伝達ってのが鍵になってくる。今何をやっているとか何を考えている、とか。何をやるのかとかもお互いに分かっていないと自分の知らないところでどんどん違う方向に進んでいってしまう。自分たちがやったことは週明けと週末に必ずスカイプで進捗報告をすること、また何かあったらスカイプで会議をする。それからそれだけでは足りないから週に２回くらいは何をやったかをブログという形で自分たちしか見られないようなブログにアップロードする。アップしたらfacebookのグループでリンクを張って知らせる。というような事をやった。
google doc などももちろん用いて。

分業
上の話も絡んでくるのだが、チームで働く上で分業しなくてはならないことが多々ある。
最初の方に起きてしまった失敗から話を進めよう。

２つ、やることがあった。それを分業するのに一番手っ取り早い方法は何か？もちろんフランスではこれやって、フィンランドではこれやって・・・ってのが一番やりやすそう。
というわけでそうした。

でも・・・・それが案外あとあと尾を引くことに。お互い分業だから、コミュニケーションをそんなに取る必要がない。だからどんどんまるで２つのチームのように２つのことが進んでいく。結局それをまとめるために相当な労力を使ってしまうのだ。
そんな反省を踏まえて、その後何か複数のタスクが出てきた場合は下図のようにチームを分けた

遠隔地でとの分業

もちろんphysical なものはこうは出来ない。でもたいてい分業をやる際って何かしら近くに居なくても出来ることがある。thanks to the technology.

役立ったツール

google doc
google calender
google group (mailing list)
dropbox
twitter
facebook
wordpress
skype

くらいかなーー。あとなんかあった気もするけどここらへんがコアでした。mind map を複数人数でいじれるヤツとかもつかったけどあんま頻繁には使わなかったかな・・・

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/17

人間工学を知るためのキーワード　

エイ（木へんに世）出版社さんの出した
Real Design (リアル・デザイン) 2010年 09月号 [雑誌]

で人間工学とデザイン、という特集をしていた。
その中にあった
「人間工学を知るための７つのキーワード」というものがとてもよくまとめられていると思うので~~パクらせて~~引用させていただきます。

エルゴノミクス; カラダについての人間工学がルーツ

当初は人間の身体的な特性に会わせた製品や環境図栗についての研究の事をさしていたが、今では認知的特性への対応も含めたいわゆる人間工学全般をさす言葉として用いられるようになっている。

ヒューマンファクター; 認知的特性から考えた人間工学

エルゴノミクスとほぼ同じだが、ルーツ的に心理学的なアプローチをする研究と言うイメージが強く、あえてその意味でのエルゴノミクスと名前を使い分ける研究者も居る

ユニバーサルデザイン; 多くの人が使えるもののデザイン理念

どんな人でも公平に使える事
使う上で自由度が高い事
使い方がすぐに理解出来る事
必要な情報が理解出来る事
うっかりミスや危険に繋がりにくく、安全である事
カラダへの負担が少なく、小さな力でも使える事
体格等に関わらず使いやすい大きさと空間を確保出来る事

アクセシビリティ; モノや建物、サービスへのアクセスしやすさ

ユーザビリティ; 製品の使いやすさの度合いを表す言葉

ヒューマンマシンインターフェイスやユーザインターフェースの評価において重要な基準

ヒューマンマシンインターフェイス; 車等の機械との間の入出力手段

ユーザインターフェースが主にPC関連、それと対比して例えば車のダッシュボードのようなもの

ユーザインターフェース; 主にPC関連機器との間の入出力手段

人間と機械との間で情報をやり取りするための接面の事

エルゴノミクスやヒューマンファクターについては厳密にどこから来たかは知らなかった。カラダ的なものがルーツ、とかそゆのは聞いてはいたけどきちんと文章としてまとめたものを初めて見たので助かった。
ユニバーサルデザインとかについてはおじいちゃんとかも使えるような、誰にでも使ってもらえるもの、くらいにしか考えていなかったので７つの定義のようなものがあって驚いた。。。うーーん。一応こういう分野に居るのに全然知らないんだな俺・・・
万人に分かるように書いてあってシンプルなはずなのに新しい情報がたくさん入ってくる

ちなみにユーザビリティに関してはwikipedia などに詳しく載っている

二つの定義がある事は分かっていたけれども、おそらくニールセンの定義の方がよく使われているのでは？というのが率直な感想。ちょと論文読んでおきます。

あとは人で言うとノーマンとかが自分の研究室にはというかこの分野には欠かせない人な気がするな。
アフォーダンスの概念とかもたまに出てくる。
近いうち自分の中で「人間工学とは何か」と「自分はどの分野の専門家か」という質問には答えられるようにしておこう

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/15

語学レベルと人の説得

ME310のプロジェクトを通じて、日本人とプライベートで話すとき以外はずっと英語で話していた。
パリでのプロジェクトだったにもかかわらずフランス語を身につけられなかった事は若干恥ずかしい事なのですが・・・許してくださいw

そんな中で感じた事。語学力の話。

「人に何かを伝える事が出来る、会話が出来る」という事と「人を説得する事が出来る」ということは全くの別物だった。自分の考えはこうだ！的な事は考えていてもそれをストレートに伝える事しか出来ない。少しそれを比喩したり寄り道をして人の興味を引いてそれを人に納得させる、もしくは説得する、このことが恐ろしく難しく感じた。

日本語で言うなら今書いた文章、そしてこれから書く文章をただ「英語で人を説得するのは難しい」という一言だけで伝えてしまうようなイメージ。
これに人を納得させる力等ある訳がない。

ただ逆に流暢な人はやはり人をまとめる事であったり人を聞く姿勢にさせる事が出来る。自分としては本当にそれがうらやましかった。

初めにパリに行った時は（今どうなっているかは分からないけど）正直説得なんて全然出来なかった。でもだからこそ自分なりにいろいろ工夫した

以下に自分なりに工夫した事等を書いておきます

自分の意見があってそれを言いたいとき、自分は以下の事をした

「話の道筋をあらかじめ考えておく」
「画像等visual の題材を用意しておく」
「既存のものをたとえにして説明する」
「似たような話が出た時にここぞといく」

もちろん・・・普通の事。ただ少しでもそれを考えておくと人に話した時に伝わり方がかなり違う。特に画像等を持っていった場合は理解が全然違うし興味を引く事も出来る。もちろんやり過ぎはないようにした。一人だけ頑張ってると向こうからしたら居心地が悪いと思ったし・・・
最後の「似たような話が出た時にここぞといく」ってのも結構効果はあった。当然コミュニケーションなわけだからいきなりぶっ飛んだ話をしても聞く事すらしていないときすらあるイメージなのだ。もちろんその似ているアイディアを出した人が自分のアイディアにくっつきすぎてしまうというデメリットはあるけれども・・・そこさえ上手くクリアすればとても「聞く準備の出来た状態」の相手に話す事が出来る

語学以外でカバー出来る事はフルに活用した。そのくらいしなくてはあの頑固な（笑）人たちは説得する事は出来なかったので・・・難しかったなーー

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/13

問題とニーズの階層

今までME310を通して感じた事のまとめの記事の中でいくつか問題点やニーズについて、「掘り下げる」という表現を使ってきた。例えば以下の二つを見てほしい

プロトタイプの限界　より引用

個人的プロブレムと会社側プロブレムより引用

これら全て問題点を多少深く掘り下げている、という感覚。
フィールドリサーチ（ユーザーインタビューやリサーチなど）をした際にたくさん問題というのは見つかる。例えばチームであったらそれらを言い合って、どこにどのような問題があるかをもう出ない！というくらい挙げていく。するとそれらはいくつかのカテゴリに分ける事が出来る。そのまとめあげたものも問題なのである。そしてまとめられた要素からすればそのカテゴリは1階層上の問題。

また「なぜそれが問題となりうるのか」という事を議論する事も役に立つ事が多い。よく研究等でもそれを「なぜ」やりたいのかを何回も問えと言われる。そうする事でより本質に近づく事が出来るからだ。なぜそれがユーザーにとって問題なのか？それを考える事でそれもまた本質に近づく事が出来、より「掘り下げた」問題となりうる

人のニーズに対しても同じ。それぞれの問題とユーザーのニーズというのは密接な関係にあって、それぞれの問題に対してユーザーのニーズを発見出来ると思う。それらを「なぜ」と問い続ける事によってそのニーズの根本にある人のもっと大きい枠でのニーズというものを理解する事が出来る。

言っている事は単純だけれども、正直これが出来ない事が多い。そのニーズがどの程度特殊な状況であるか、人々に共通であるか、それらを上手く並び替える事でうまく人のニーズというのを整理する事が出来る。そして整理した上でプロジェクトを進める事でプロトタイプの限界や社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜で紹介したような「間違い」や「勘違い」の様なものはおこりにくくなるのである。

ニーズを整理出来たら、今度はどこから着手するかは自分たち次第。小さいニーズを狙ってもいいし、大きなニーズからまた少し派生させて新たなニーズを予測しても良い。
そうする事によって次の手順は踏みやすくなるし、花形であるソリューションを出す際の可能性は大きく広がっていくはずである

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/11

個人的プロブレムと会社側プロブレム

以前
社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜

という記事を書いた。
これはプロジェクトを進める段階で発見される「プロブレム」には２種類あって、それは

「社会的プロブレム」: 社会や環境のつくり上げた問題。地球温暖化などがその一例
「個人的プロブレム」: 個人が不便に感じる問題点、朝起きるのが辛い、などがその一例

に分けることが出来、ユーザーのニーズはこの「個人的プロブレム」に潜んでいるという物である。

ただもう一つ、プロジェクトを考える上で大事なプロブレムがあることに先日気がついた
「会社側プロブレム」である。
それは何か？
一種の「会社の要望」の様な物。

例えばそのプロジェクトが会社から持ち出されたものであれば、会社的にこうしたい、こうであると嬉しい、というものはあるはず。考え方としては社会的プロブレム、と多少かぶる部分もあるかもしれないけど敢えて切り離して考えたほうが分かりやすいと思った。

例えば・・・レストランの顧客のエクスペリエンスを改善しよう、となったとする。
そこで問題を頑張って探す。
その際に例えば
「長蛇の列が出来る」
「ご飯にありつくまでに時間がかかる」
「込んでいる」
というところを問題点として発見したとしよう。

そして例えば長蛇の列が出来てしまう、という所に焦点を当てたとする。
なんでそれが問題？と考えたりした際に、ユーザーを観察して得た問題であるにも関わらずそれが
「長蛇の列が出来るとそれを見てお客様が来なくなり、店側は利益を損ねてしまう」
という様な論点に移ってしまうのはありがちな経過である。

もちろんこれも、「プロブレム」であり間違いだとは言わない。
ただこの極端な例でおそらく気付かれた通り「店側の利益」など客にとってはしったこっちゃない。正解はないけど、自分であればもう少しこれを「個人的プロブレム」まで掘り下げることに魅力を感じる
「長蛇の列」が出来る「原因」はなにか、それがどうエクスペリエンスに影響を与えているか？
そもそもなぜ「長蛇の列」が出来るとユーザーのエクスペリエンスは下がるのか？列をなくす事を考える事でなくその困っている事を解消すれば良いのではないか？逆にラーメン屋でまっているとわくわくする事があるのはなぜか・・・など・・・

世の中に出ている商品には、会社が「会社側プロブレム」のみを考えて商品を作ってしまう事が多い。「これが売れればうちの会社は・・・」の様に・・・

この記事ではgoogle+ がそうである、というような事も書いてある。
他の例では、「広告を見るためのアプリ」などもそうである。バス停とかに、暇だったらこれダウンロードしたらいろんな広告見れるよ、的な広告があるらしい。。。そりゃ・・・広告見てくれたらうれしいけど、それをダウンロードして使う人って居る？的な感じになってしまうだろう。

どんな種類のプロジェクトであれ、議論を始めるきっかけとなる足場を探す事は必要であり、これ無しにプロジェクトは進められない。そしてどんな種類の「プロブレム」も足場にはなりうる。ただそこから深く考えていこうというときにその問題をどうとらえるか、それを如何にユーザー側から見た「個人的プロブレム」に落とし込めるか、それがデザインプロジェクトにとっては鍵になってくるのである。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/10

プロトタイプの限界

以前 [社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜]
の中でも少し触れた話なのだが、今回は「プロトタイプの限界」についての議論を進めていく

そもそもプロトタイプとは？って人のは…さっきの記事の中か、
プロトタイプは状況に応じて時にラフに、時に詳細に
という記事を読んでいただくことをおすすめします。

一応簡単に書くと

ということになります。

そんなプロトタイプにも限界があるというのが個人の考え。
ではどういうところに限界があるのか？それは前回の記事でも触れたような話。前回はこんなふうに書いていた。

つまりそれはどういう事か？
プロジェクトが例えば、「飲み会のエクスペリエンス向上」というお題であったとする。
そして問題点として「お酒をあまり飲まない人が居る」という問題を発見したとする。

それを解決するためにお酒を人に飲ます事のできるソリューションというのを例えばいくつか思いつく、それはアプリケーションなどであったりツールであったり、もしかしたらメニューの構成であったりメンバーであったり席順であったり・・・

そんななかでプロトタイプを作成してテストする。
例えばプロトタイプでお酒を飲ますためのアプリケーションなどを考えたとしよう。そしてそこで「どのインターフェイスがもっとも人を飲む気にさせるか」的な疑問を持ったとする。
そのプロトタイプを通じてどのようなことが分かるだろうか？それはせいぜいどのような要素が飲む気にさせるか程度であり、そもそもそこに疑問を持ったことは正しかったのか？というような一歩引いた意見は出てこなくなってしまうのだ。

もちろんそれは、プロトタイプの失敗という形でみえてくるかもしれない。プロトタイプってのは失敗してなんぼのものであり、それを恐れてプロジェクトは進められない。ただもしも、もっと早くから失敗してしまうかもと見えていれば、というふうに思ったりもする。
まー失敗の定義も難しく何が失敗であるかなど誰にも言えないのだが・・・

失敗の定義がわからない以上、この話を進めるのもナンセンスかもしれない。ただもしよければもう少しお付き合いいただきたい。

自分だったら今回発見した「お酒を飲まない人が居る」という問題について進めることはしない。なんとなく。ではどうするか？
たとえばここで設定した問題を、もう少し深く掘り下げていく。もしかしたらもう少し良い疑問を持てるのかもしれないという期待を込めて。

1. 「お酒を飲まない人が居る」
↓
じゃぁそれはなぜ問題なのか？
↓
それが例えば 2. 「会話に対して同じようなテンションで盛り上がれないから」だとする
↓
じゃぁなぜそれも問題なのか？
↓
3. 「みんなで盛り上がりたいから」
↓
・・・・

という様に問題というのは基本的にはどんどん深くまで掘り下げることが出来る。ただ掘り下げれば掘り下げるだけ抽象的になってしまうこともあるので注意なのだが、例えば途中の2. の段階で
「じゃぁどうやったら盛り上がれる？」「あまり盛り上がらない、と言われている人が盛り上がるのはどんな時？」「話したくないの？話したいけど話せないの？」「話したいのに話せない、という人は何を考えている？」
などともう少し派生した問題点、もしくはニーズに行き着くことが出来るのも事実。

もしくは1. の段階で「なぜ飲めないのか？」を考えることで
↓
「お酒嫌い」「みんなと飲みたいお酒の種類が違って頼みづらい」

などどの階層にもある

ちなみに最初に設定した問題「お酒を飲まない人が居る」ってのはある意味「個人的プロブレム」ではなく「社会的プロブレム」（こんな場合は環境的プロブレムとでも言うべきなのだろうか？） ( [社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜] 参照) であり敢えてへんな問題点を設定したのだが・・・
ただここで後述した問題点、それらはもう少しユーザーに近いニーズなのではないかと自分は考える。見つけた問題点に自信を持つ。そしてそこから「どのように〜」といった疑問をプロトタイプで解決していくことが個人的に考える「良い流れ」だと思う

まとめると、プロトタイプってのは設定した疑問の外側、もしくはそれよりも上層の問題（問題とニーズの階層参照）にはたいてい出得ないものであるのだ。
Build to Think, Think to Build の章で書いたように、もちろんプロトタイプを作ることで、想定した以上のフィードバックに出会うことはある。ただそれでもそれはたいてい設定した疑問よりも上層の問題を解決、発見するには至らない。
これははじめのプロブレムを見つける段階、ニードを見つける段階が如何に大事かを裏付ける事実だと捉えて欲しい。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

モックアップとプロトタイプ

昔ここでも記事を書いたけど、今回はもうちょっと体裁を整えて丁寧に書きます笑

モックアップとプロトタイプはどう違うのだろう？
以前プロトタイプは状況に応じて時にラフに、時に詳細に、でも書いたように
プロトタイプを作る目的は
[to answer the question]、「疑問に答える事」
である。

だから何かしら疑問を持った際にその疑問のみに答えられるような必要最低限のプロトタイプを用意すれば、それは「良いプロトタイプ」なのである。

今この記事を書いていて思ったのだが、「モックアップ」について自分自身で意見を述べられるほど頭の中に入っていなかったので多少引用させていただきます。

一応頭にこのようなものがモックアップ、とはあるのですが多少の誤解があるかもしれません。「モックアップとプロトタイプ」について自分なりの考えを述べていきます。

ある意味モックアップもプロトタイプの一つになりうると思う。ただ必ずしもそうとは言えない。

たとえば新しい傘を作るっていうプロジェクトがあったとして。
そのコンセプトを「相合い傘しやすいように傘作ろう」ってなったとする
（ちなみにこれは僕が友達と東工大の授業のプロダクトデザインという授業でセットした題）

その新しい傘ってのは、いろーーんな要因を含んでいる。
サイズであったり、形であったり、重さであったり、色であったり、音であったり。

プロトタイプってのはたとえば
「サイズはどのサイズがベストなの？」
「どんな形がふさわしい？」
「どんな重さまでが許容範囲？」
とかとかそういった疑問を解くために作られるべき。

一方モックアップは、ある程度イメージ出来るファイナルプロダクトの形を作ってみる感じ。ここで言うとこれら全部の要因を含むもの。たとえばそれでもテスト出来るよーっていって、いくつかのモックアップを作ってテストするとする。ある意味それもプロトタイプなのかもしれないけど、多分そのプロトタイプで重要なインサイト（洞察）を期待する事は出来ない。なぜならそこでの疑問は「どのモックアップが一番いい？」というような抽象的であまり良くない疑問であり、（正しい疑問を持てば正しいプロトタイプは見えてくる参照）あまりに詳細に作られているが故に、フィードバック自体も詳細になりすぎて自分の本当に試したい事に対する意見を貰えなくなってしまうのだ（プロトタイプは状況に応じて時にラフに、時に詳細に参照）
さらにモックアップは時間がかかる。そしてコストもかかる。そのモックアップが受け入れられなかった場合にショックはなかなか大きく、その失敗はにわかには受け入れがたい・・・と思う。

ただモックアップが悪いと言っている訳ではない。モックアップを作る事でユーザーはたとえばその商品なり経験をより鮮明にイメージする事が出来る。それを使ってたとえばインタビューをする、物理的な大きさ等の確認をする、詳細部分を確認する、プレゼンする、などそれによってしか出来ない事もたくさんあるのだ。モックアップとはもう少しあとのフェーズに出てくるべきものの様に思われる。

注意すべきところはデザインプロセスの中で多くの場合に「曖昧さ」と戦う時期がある。そんな場合にタンジブルな自分の考えに近いモックアップを自分の横においておく事は精神衛生上落ち着けることが多い。一刻もはやくファイナルプロダクトを見たいし、そもそも作れるのか不安だし、おもしろいアイディアだから早く具現化したいし、みたいなどっちかというとプロトタイプ作りたい欲よりもモックアップ作りたい欲のほうがプロセスに居る間は強いのだ。

ただそこをぐっとこらえて、正しい疑問をもち、正しいプロトタイプを作る事。それが重要だと思う訳なのですよ。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

よい疑問を持てば、プロトタイプの形は見えてくる

タイトルが・・・もっとも伝えたい事です笑

この言葉は師（？）である Sushi Suzuki さんのツイッターから引用、着色したものです。昔のつぶやきだったので一字一句合っているかは分かりませんが、こんな感じの事を言っていたと思います

正直・・・正しいかは分からない。
けど何となくそうと信じてやってきた言葉。

何が「よい疑問」なのかも分からないしそれらが全て「プロトタイプ」を通じて検証出来るとは限らない。

ただ「プロトタイプなにつくりゃいいんだーーーー」ってなる人はたくさんいると思う。
そんな時に、一度「疑問」に疑問を持つ事はとても大事。

プロトタイプは以前にも色んな記事で言ったように、「疑問に答えるために作るもの」であり、その形は必ずしもファイナルプロダクトと似ているとは限らない。むしろ似ていない方がよいフィードバックやインサイトを得る事が出来る事もある。
（プロトタイプは状況に応じて時にラフに、時に詳細に, プロトタイプの限界参照）

たとえば下はディスプレイの傾き加減や高さを決める際のプロトタイプ

紙に This is a display って書いてそれに棒をつけただけのプロトタイプ。（もちろん何かしらにそゆのが載ってる本とかありそうだからやる必要なかったのかもしれないけど）タッチスクリーンがどこに固定されているのが一番使いやすいかを聞いたもの。ここでの質問はシンプルで、おそらくこれは作るのに一番悩まなかったうちの一つのプロトタイプ。
まぁ誰でも思いつくようなものだけど、たとえばこれでプロダクト全部を作る必要もなければ形ですら作る必要もない。聞きたいのはディスプレイの高さと傾きなのだから、それが試せるプロトタイプを作れば良い。

あまり疑問を持たずにプロトタイプを作った事もあった。それはやはりファイナルプロダクトを意識してしまって、全てのファンクションを盛り込んだ。作ったあとに、あれ？何聞きたいんだっけ？ってなったりした。。。問題も疑問も、そこに視点をおいて初めて見えるものであり、とりあえず進めているだけでは見つかるものでもない。そして「なにすりゃいいんだーーー」ってどうせなる。そういう時はプロトタイプをどうしようでなく、疑問をどうしようと考えることを勧める。それがプロトタイプを作る一歩目だからだ。

ユーザーの問題を見つけてそれを解く時にじゃあこうだったらどうなるんだ？っていう疑問。それがまず一歩目。
そしてその「こうだったら」という度合いや抽象度が2歩目かな。
例えば「かっこいいものって何？」ってのも「疑問」だ。ただこれに答えるためのプロトタイプは自分には思いつかない。そこでなぜ？を問いつめる。なんでまずそのプロジェクトの中でかっこいいものが必要なのか？ユーザーはそこで何を求めているのか？それが例えば人に見せびらかしたい、であれば人にクールに使っている姿を見せびらかすために何か出来ないか？あーだこーだ、じゃぁこれってどうかな？とかのようにもう少し具体的な「よい」質問を持つ事が出来れば、プロトタイプってのは自然に作れる・・・・気がする・・・
具体的な事が「よい」ことであるとは限らない。ただ少なくとも聞いている本人でさえ何を聞いているのか分からないような質問は絶対にさけるべきだと思う。

「形にする」っていう段階でかなり前進する。ただそれはプロトタイプの限界の章でも述べたように多少危険でもある。（何が危険かはプロトタイプの限界読んでください。。。）良い疑問やよい問題意識を持つ事はプロトタイプを作る上でも、プロジェクトを進める上でも重要になってくるのだ。

正直この記事は実体験に基づいている訳でなく、このように思って進めてきた、という心意気のようなものなので物足りなかったかもしれません。申し訳ないです。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/09

ユーザーインタビューとその限界

ユーザーインタビュー・・・ME310の中でそれらは何に使われていたか？
それは時にユーザーについて学ぶ事であり、それは時にペルソナを作るための過程であったり、様々な用途に使われユーザーを理解するのにとても役に立つ。
まーとにかく、ユーザーにインタビューすることは何らかのプロジェクトをデザイン的なアプローチのもと進めていくには必要不可欠だと思うんですよ。
これと微妙に似て非なるものが「アンケート」これについてはどっかで書こうかな・・・って感じです。ただたいしたトピックにはならないです。用はexplore な感じがインタビュー。analyze な感じがアンケート。自分から新しいトピックを作り出すためにアンケートは用いられないし、「何割の人がこういっているからこれはだめだ」という考え方はあまりにデザインとかけ離れていると自分はとらえる

そんなインタビューも私の考えからすれば限界があるのですよ。
僕らのチームの行ったインタビューにはいくつか種類があった
1. ノーマルユーザーインタビュー
2. エキスパートインタビュー
3. エクストリームユーザーインタビュー

結構聞かれる事があったのでそれぞれの言葉の説明

具体的な例を示すと・・・たとえばトピックが空港だとして
ノーマルユーザーは自分とか他のごくふつーーーーーに空港使う人
エキスパートは空港で働いている人とか、空港立てた人とか、航空を専門に勉強している人とか
エクストリームユーザーはたとえば月に５０回くらい空港を使う人であったり、空港なんてぜっっっったいに使いたくないと考える人であったり、飛行機の種類とか全部言えるような人だったり、何十カ国も飛行機で旅しているような人であったり

それらのインタビューで得られるものはもちろん違う。
1 のノーマルユーザーへのインタビューは、そのトピックに対してどのような考えをもってどのような態度をとっているか、について聞く。ある程度クラスター化（グループ化）出来るくらいたくさんの人に聞くのが望ましい。またそのトピックに対する問題点等を発見出来る

2. のエキスパートインタビューは例えばどのようなところでどんなテクノロジーがあるか、やそこにどのような問題があるか、今何が行われていて何が行われていないのか、それらを把握するのにはもってこい。また専門家ならではの視点から様々な知見を得る事が出来る。

3. のエクストリームユーザーは専門家とはまた違う、またノーマルユーザーからは得る事の出来ない、もしくはノーマルユーザーの気付かない問題点を発見するのに役に立つ。自分の知らない知識とかエキスパートとはまた違う視点を持っていることが多い

これら全てのユーザーインタビューはそれぞれ等しく価値がある。
ただ強いて言うなら、インタビューは現状を理解する上でもっとも役に立つもの。
ここから問題点を発見するのは案外難しい。

とくにノーマルユーザーから聞いた話から問題が見つかっただけで喜んでいてはもーだめなのである。インタビューで聞ける内容は、個人が頭で意識している内容のみであるからだ。（もちろんインタビューを上手く行えばそれを引き出す事も出来るのかもしれないが自分には出来なかった）

問題ってのはいろいろある。その中で個人が、特にノーマルユーザーが把握している内容等価値はほぼないに等しいと言っても良い。ここでの価値とは経済的な価値である。もちろんプロジェクトを進めるにあたってそれらの問題を頭に入れておく事は非常に重要。ただそのくらいの表面をなぞっただけの問題点など誰もが気付いている事なのだ。

エキスパートとのインタビューは個人的な見解では「社会的プロブレム」（社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜参照）やその分野の会社の抱える問題点を発見するのには役に立つがエキスパートはあくまでエキスパートであり、ユーザーではない事に注意しなくてはならない。そこからユーザー起因の問題を発見する事は若干難しい

上の2点とは違い、個人的にはエクストリームユーザーへのインタビューはおもしろい問題を発見するためには非常に役に立つと思う。たくさん使うからこそわかる問題、いろいろ知っているからこそ分かる問題、まったく使わないから感じている恐怖などノーマルユーザーの気付かない、つまり世の中の９０％の人は気付いていないような問題点をかれらは頭で知っているのだ。
ただそれでもやはり頭で意識している内容のみしか聞き出す事が出来ないので自分でも気付いていないような問題、インサイトは得る事は難しくなっていることが多い。

と、ちょっと強めにいってしまったのだが、プロジェクトの進め方はもちろんいろいろある。ある程度明白な問題をすばらしいソリューションを用いて解く、これもイノベーティブになる可能性はある。そして誰もが見つけられなかった問題を解く、これもイノベーティブにはなりうる。ただもしも後者の形でプロジェクトを進めたいのであれば、ユーザーインタビューよりも個人的にはインタビューに加えて、「観察」を行うべきだと思う。

観察の仕方はそれぞれ。ビデオをとって人を観察しても良い。自分自身がユーザーになってみるのも良い。写真をとってその写真をみてあれこれ言い合うのも良い。共通なのは要は、現場に行けという事。
たとえば下の写真は自分が旅行しているときに見つけたブロブレム。おそらくインタビューからではえる事が出来ないものである。

問題？って感じかもしれないけど８割がたの子連れの家族はこのように家族を引いている。まぁいいけどさ、この空港の荷物運ぶやつをデザインするのもある意味チャレンジであり面白そうだと個人的には思っている。（ちなみにアイディアブログの方にその問題をとくアイディアを出しました）

最後までおつきあいありがとうございます、といいたい所なのですがもう一言付け加えておきます。
「有言実行」という言葉がいつしかかっこ良く見えてしまうほど、いった事を実行するのは難しい。たとえばリサイクルについて人にインタビューしたとする。そしたらその人は100点満点の答えを出すだろう。ただ実際は？と聞かれたらそれを実行している人は滅多にいない。車を運転しているときに自分が一番不安なシチュエーションは？と聞いたときに携帯を打ちながら運転している時、とは誰も答えないと思う。事故の何割かはそれが起因しているにも関わらず。むしろそのくらい運転に慣れた人ならどこにも不安はないと答えるのが普通なのだ。

インタビューはもちろん強力なツールである。しかしよりよいインサイトを得るためにはインタビューだけでは物足りない。観察とインタビューとを混ぜてこそ、良い物が生まれると私は考える。

2011/07/08

ブレーンストーミングについて

ブレーンストーミングについて。ブレインストーミングの方がいいのかな？

この記事では個人的にブレストを左右する３つのトピックについて書いていきたいと思います。もちろんブレストを左右するものはブレストのお題であることも分かるのですがそこには触れず。今は書いてはいないのですが「プロジェクトの種類」って記事でもしかしたら触れるかもしれません（08/July/2011）

以下が書く内容

1. メソッド
2. ツール
3. ナショナリティと言語

1. メソッド
KNLog: イノベーション：ブレインストーミングの一例の中で書いた話と完全に重複するのですがきちんとした形で記事を残したかったので書いておきます。

まず最初に始めるときに、何となくだけど2種類に分かれる気がする。

「３分間最初自分自身で考えて、それらをどんどんシェアしていこう」
「とりあえず思いつくがままに発言していこう」

個人的には後者が好きかな。何となく最初に考える方では自分のアイディアにスティックしてしまう可能性が高いので。後者の方がお互いにお互いの意見を取り入れて上手くミックス出来るイメージがある。ただそれもメンバー次第だしどっちがいいとは言えない。例えばおしゃべりすぎる人とおとなしすぎる人がいる場合、何となくだけど最初に考える時間をとった方がいい気もする。とりあえず適当にアイディアを出すのが好きな人が多いときとかは思いつくまま発言がいいと思う。それは本当にどっちがいいとかは言えない。

始めて少し経ってから、ブレストをしている最中に話が詰まってしまう事はよくある。そんなときにある程度役に立つ方法を紹介

まず一つ目は、逆の事を考えるという発想。たとえば
「電車でのエクスペリエンスを快適にするには？」とかが課題だとして

椅子を快適にするとか時間を短くするとか・・・いくつか普通に出てくる。ただ何となく悪い例のせいもあるかもしれないけど、うまく掴みづらい感がないだろうか？

そしたら逆にめっちゃ不快にする方法とか不便にする方法を考える

乗り換えの案内がない、臭い、トイレが無い、どこに行くかが分からない、急行とかばっかり、切符が買いにくい、ドアが空かない、電車に乗るときに落ちそうになる、めっちゃ混んでる、出入りが不便、すぐドアが閉まる、バスとかとの乗り継ぎが悪い、家から遠い、山の上にある、川の中にある、階段が多い、うるさい、自分がどこにいるか分からない、とか何となくこっちの方がたくさん出てくる気がする。
もちろんこれら全てが有用であるとは限らない。ただこれらを逆に「なくそう」とか「どうやったら改善する事が出来るか」を考える事で通常の道を通ったときには思いつかないアイディアが出てきたりする・・・はず笑

もう一つは何かと適当に繋げる、というもの。
これはビジコンとかやってる人には有名なのかな？
たとえばさっきの例で言うと、「電車を快適にする」それと例えば「携帯電話」を一緒に考えようとか「イルミネーション」を考えようとか「東京タワー」を考えようとか「プール」を考えようとか、「香水」を考えようとか適当に何でもいいので何にも関係なさそうなものをお題に出してやってみる。
ちなみに一度ビールを飲みながらbeer storming を繋げる方法を用いてやった事があるのですが結局アイディアの８割は下ねたかアルコールの話になってしまいましたw

たとえば「携帯電話」だったら乗り換え案内的なものからgps, 眠ってても自分の駅で勝手に起こしてくれる機能とか、なんか一人で考えてもたくさん出てくる
「イルミネーション」道案内ライトでしよーぜーとか・・・
「東京タワー」これは難しいかもだけどランドマークを色んなところに作って待ち合わせを楽にしようとかかなー？まーでも考えればいろいろ出てくるはず
「プール」・・・・水・・・シャワールーム付けとくとか？分からんw
「香水」電車いいにおいにしようプロジェクト・・・(結局汗とまみれて臭くなりそうだな・・・って自分でいってても思ってしまうのですがブレストは基本なんでもあり。自分自身の意見も批判しなくていい・・・はずw)

あともう一つはフレームワークを用いるというもの。
どんなフレームワークがあるかな、とちょっと自分のパソコン探したけどあまり見つからなかったので見つかったらまた載せておきます。
ちょっと適当に書いてしまうので有用かは分からないけど、そのトピックをフレームワークに当てはめて考える事でより深いブレストが出来ることもある
たとえば「問題点」て何だろう
その問題がなぜ問題なのかwhy を５回聞いてみよう
それに対してそれを解く「解法」てどんなものがあるだろう
とか
このトピックのお題って何なんだろう。それのもっと深くに眠っている真相を探ろう、どういう意味でとらえる事が出来るか、どのような側面を持っているかとか
どんなユーザーをターゲットにとしているか、とか
そんなフレームワークを用いる事で円滑にブレストが出来る事もある。

2. ツール
上でいったフレームワークもある意味ツールの一部なのかもしれないけどもっとphysical なツールについて
ポストイットとかホワイトボードとか。
個人的にはペーパーボードって言うのかな。。。でっかい紙がボードにあるようなのが好き。めくってもめくっても紙、みたいな。保存も出来るし消えないし。
ただ今回はポストイットについてその有用性と危険性について述べたいと思う。

ポストイットのメリットはおそらく可動性？とでも言うのかな。意見をクラスター化するのがとても楽。このアイディアはこういう事だなとか、ブレスト以外のプロブレムファインディングのときとかまさにそうだけど、要約するのがとても楽。
デメリットというか危険性については、個人作業の集約になってしまいがちな事。ブレストの一番の売りはdiscussion をdevelop して個人からは生まれないようなアイディアを出していく事。たとえば思いついた事をとりあえず書き出して、あとでホワイトボードにはろうってなってしまうと、アイディアが出来たバックグラウンドも分からなければ興味すらなくなる事もある。そいった意味で上手くコミュニケーションをとりながら、決して個人作業にならないようにポストイットを使っていかないとだめだと思う。ちゃんと自分で何を考えてるのか発言して、こういうアイディアっていってそれについて話し合ったあとにその要約なりタイトルなりをポストイットにかいて形として保存する。そんな感じで上手く使ってかないと難しい><

3. ナショナリティと言語
おそらく日本語でこのように書いてあるブレストの話で世界的な文化的な違いを考慮した記事ってのは少ないんじゃないかと思う。まーそーいった意味でいい記事になる可能性も秘めてたんだけどなー・・・いかんせん文章書くの苦手だからなぁ・・・

正直フランスでの生活で文化の違いはあからさまに感じた。ただそれを「文化の違いだからしょうがない」って形で終わらせてしまうのはもったいない話。理解しようと努力もしたし理解させようとも努力した。最終的にナショナリティてよりはパーソナリティって考えられるようになったのは小さい変化だけど個人的には大きな変化。ただ最後に気付いたのは自分が相手を理解するよりも先に、向こうは俺を理解していた。それはうれしかったけど同時にそれに気付けてなかった自分が恥ずかしくなったりした。

フランスでブレストをする際にいくつかのタイプがあったと思う。もちろん日本的な、いわゆる日本人が考えられるようなブレストをしてくれる人もいたりした。それは当然なのかな。だけど、自分が見た中では２種類の日本ではあまり見ない特徴のあった。

一つ目は、自分の意見にやたら自信持っている人がいる事。こう言うと日本にもいるじゃーんてなるんだけどな・・・伝えるのが難しい。ただ向こうの人は本当に自分の意見に自信を持っている。そしてある意味「自身」も持っている。なんて言うかな。やっぱカラーがあるんだ。そして人によっては気に入らないアイディアにはためらいなくケチつける。それがブレストで掟破りであってもw　それは辛かったな。「それ日本だったらいけるかもだけどフランスではむりだよ」みたいなこと言われたのは本当に辛かった。自分の意見に自信を持っていて、これで行きたいって思うと止まらないんだ。これがいい！みたいな。日本でこんなに主張される事はないから若干引いてしまったりする。んでそれに決まって進んでいったりする。ただagreeable が無い訳ではない。なんというか文句は言うけどもちろん周りの事を考えてくれたりもする。ただやはり自身のアイディアに自信を持っていて、それは本当に日本の姿勢とは違った。
日本の友達から、どっかの会社では期間を決めて、誰のアイディアに進むかを決めたりもする、という話を聞いた。誰も意見を曲げないからこの期間は誰々に従う、この期間は誰々に従う、的な。ある意味柔軟というかなんと言うか・・・

もう一つは、議論を積み上げない事
自分が理系の大学から来てるかもしれないけど、フランスでのブレストはとにかく話が飛びやすく感じる。というか議論をすると穴があるような気がして気持ち悪くなる事がある。ブレストだからそれは良かったりもするんだけど、ただ、え？それは次のフェーズでしょっていう議論までそこから発展してしまう事がある。日本人がゆっくり積み上げていって体積のある議論であるのに対して、もうちょっと直線的なイメージかな。
正直自分がよくブレストした人たちはコンピュータ大好き人間でそこまで議論が弾んだりはしなかったけど、他の日本人の話を聞いたり周りを見ているとしていると本当にこんな感じ。

うまく説明出来ないな。ただ明らかに違う。これは慣れるのに本当に苦労した。冗談とかもうまく掴めなかったりしたし大変だった。
あとはやたら集中力のない人がいたりとか、議論の外側の人が話を遮るのに躊躇しないことが多いとか、そゆのは結構ある。

あと苦労したのは言語かな
向こうでは英語を話してた。コミュニケーションは普通にとれる。自分の思っている事もしっかりと伝えられる。ただ自分の伝えたいものってのがどっかにあって、それを湾曲的に？比喩的にとか直線以外の方法で伝える事が出来ないから説得するのにすごい苦労した。上手く伝えるために絵を描いたりとかいろいろ話の道筋を準備したりとかしたのはいい思い出。

あとはなんか他にもいろいろ工夫した事もあったんだけどなぁ
繰り返しなんかを言うとか司会者を日によって変えるとか上手く人に振るとか細かいところだけどやっぱりメンバーによって工夫していかなきゃ行けない。ブレストってのはただの手段でしかないからな。目的を達成するためにその形は変えていくべき

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

プロトタイプは状況に応じて時にラフに、時に詳細に

プロトタイプってのは、まぁそれはテストをするために用いられる題材を呼ぶ訳ですけれども・・・ME310の中では、
「to answer the question」

という認識で統一していた。(a か the かは正直定かではないw)
プロトタイプの目的ってのは、プロダクトに似てるものを作る事ではない。
何かの疑問を解決するために作るものなんだ。

ちなみに下の画像は昔ペーパーバイクプロジェクト（紙素材だけで人が乗れて人が押せる／引ける乗り物を作ってゲームして遊ぶプロジェクト）を行ったときに作ったプロトタイプ

ここでの疑問は「このタイヤほんとに人を支えるだけ強いの？」
でした。ショッピングカートの下にタイヤつけて、その中に人入れて押したりするだけのプロトタイプ。まー単純だけどプロトタイプとしてペーパーバイク全てを作る必要はないしテストしたい部分だけを作ればいい

このプロトタイプだと「人」のテストが出来ていないのでちょっと説明しづらいけど、こゆプロトタイプって「対人」の時にもっと強くなると思う

次の写真は分かりにくいけど、これはユーザーに水の使用量を見せる事で、ユーザーに出来るだけ水の使用量を抑えさせる試み。横にボードで1l, 2l, とか使った量が簡単に分かるようになってる。

ここでの疑問は「フィードバックってエコ活動する上で役に立つの？」というもの。

log(shogo807) でも紹介されてたIDEO がデスク周りにあるものだけで作った医療器具のプロトタイプをご紹介
記事の中にはこう書かれている

画像はIDEOを超えよう(1)というブログからはらせていただきました

ここでのプロトタイプは上で書いたのと若干違うかもしれないけど、クライアントと話をしている際に、「今望んでるものってこういう感じ？」といって洗濯バサミやらなにやらを用いてこれを作ったと聞いた。これも「疑問」ではある。こゆプロトタイプをたくさん作ってどれの、どのような面が気に入ったか？と聞く事は確かなプロトタイプ

「プロトタイプの限界」って章ではプロトタイプを行う際の問題点を出すつもりだけど今回は正しいプロトタイプの作り方。

どっかの研究で、そのプロトタイプが綿密に作られていれば作られているほど、ユーザーからのフィードバックもよりdetail になるという結果が得られた・・・って誰かがいっていた気がする・・・

でもそれは確かに自分たちでやっていても思った。たとえばこのバケツでの汚いプロトタイプのときには、ある程度自分たちの疑問に沿ったフィードバックを貰えた。もちろん水が限られているのが分かるからさらに焦った、とかいう unexpected なフィードバックもあったりしたけどそれもなにげにヒントになったりはする (これについては build to think, think to build で話す)
ただこれを、例えばArduino とか iPad とかを使ってかなり綺麗に、ほんとうに最終プロダクトみたいな形で提示したときにはユーザーのフィードバックは「かっこいい」とかに始まり「ここのインターフェイスが分かりづらい」とか「これどういう意味」とか、焦点がどんどん詳細な部分になり、自分が持っていた疑問とは違った分野のフィードバックが主体になってしまう事があったのだ。もっといえば「ケチつけるのが申し訳ない」とまで思わせてしまうような自己主張の強い、もしくは完成度の高いプロトタイプになってしまうと、もはや何のためにプロトタイプをしているのか分からなくなってしまう。

だからこそプロトタイプを作るときにはまず始めに「疑問」を持つ事から初めて、それの疑問に答えるためにはどのような形のプロトタイプが必要か、という事を考えなくてはならない。タイムマネジメントの事も考えれば更にムダはいっさい省いて、as fast as possible で作ることが望ましい。ただそれを考えなくても、疑問と関係のないfunction や見た目の美しさなど考慮することは「しない方がいい」のではなく「してはいけない」のだ

５分で作れるプロトタイプは５分でテストしろとも言われた。
そしてたくさんいろーんなタイプのプロトタイプをし続けて様々なインサイトを得る。インサイトをゲット出来ればファイナルプロダクトも自ずと見えてくる・・・はず

ファイナルプロダクトのイメージをクリアにもてば持つほど、人はモックアップを作りたがる。ただ正直に言わせてもらえば、モックアップは疑問を解決するためにはあまり役に立たないと思う。ただ作ったって自己満で終わる。

もちろん最終的にdetailをつめるときはある程度ファイナルプロダクトに近いものは必要。そこでdetailを考える事もかなり大事。ただcritical な部分では、モックアップは必要なかったりもする。
他の事に時間をたくさんかけるために、プロトタイプは極力シンプルに。
もちろん何をテストするかによるのは言うまでもないだろうけど。

もう一つシンプルにする理由もある。頑張って作ったプロトタイプってのは失敗を認めたくなくなる。失敗したら重要な要因だけ頭に入れてバイバイって言えるくらいのプロトタイプが、個人的には望ましいと思うんだ。

ただ正しいプロトタイプの作り方、ってさっき大きく書いてしまったけどそれは間違い。もちろんプロトタイプに正解なんてないし、１つの疑問に対して１００個くらいおそらくプロトタイプの仕方なんて出てくる。。。。（かも知れない）
でもプロトタイプはあくまでプロトタイプ。それによって何か意見を貰わないと。もしくは何かを発見しなくては意味がないのだから「文句無しのもん作ってユーザーとか上司に文句言わせないようにしよう」って下心がちょっとあったら、その心は見直されるべし。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

2011/07/07

ペルソナの必要性、意義と強み

ME310 のデザインシンキングのプロジェクトに参加して「ペルソナ」ってのがまーある程度よく出てきたのでそれに対する考えをまとめたい。

「デザイン」をやるにあたってペルソナってのは大事だ

ってよくいわれるっぽい。

web設計なんかでもいわれているはずだ。

ただ正直、プロジェクトが終わった今でも、ペルソナ？ってなってしまう感は否めない。
少なくとも今、何も調べていない段階で自分がいえるペルソナの強みは３つ

ユーザーの把握
シナリオのリアリティ。
情報伝達性

1. ユーザーの把握
自分たちがペルソナを作ったのはユーザーをリサーチした結果ペルソナ作らなきゃいけないっぽいからその結果使って作っとくかってなった。ただ逆に、ペルソナを作ろうってなっても同じような事をしていたと思う。観察、インタビュー、テスト、アンケートなどなど
自分の今行う分野にどのような人がいて、何かしらトピックに対してどのような態度を持っているのか、どのような事をいままでしてきたか、などを聞いていく。これによっていくつかのユーザーのパターンが出来上がるはず。
それらを上手くまとめあげたものがペルソナ。
だからユーザーリサーチとかが身に付いてない人に、ペルソナは大事なんだ！だからやれーって言えば、嫌がおうにもユーザーリサーチとかはするようになるのかもしれないとは思う。
ただこの時点でも写真まで使う必要はないのでは？とは思ってしまうかもしれないけど・・・

2. シナリオのリアリティ
何か新しいものを作ったときに、それは３行以内くらいに説明出来る事が望ましい。とはよく言われる。ただ詳細に説明したい時、特にドキュメントやプレゼンテーションのdetailの部分ではそうはいかない。
そんなときに力を発揮するのもペルソナだと思う。
こういうユーザーの場合はこういう事が出来て・・・こういうユーザーの場合はこれが・・・とかポストイットとかに書きだすだけでも出来なくはない。
けどユーザーがその新しいものとどう関わるかやそれにより何がどう便利になるかとかは、ペルソナとシナリオを考える事でもっと上手く説明は出来るし、詳細まで考える事が出来る。またそれぞれのシナリオを考えたときに何となく上手くいかなそうな部分とか矛盾する部分とかそういうのも出てくる。そこからまた上手くいかない部分を修正する事が出来たりもすると思うし、detail までつめる事が出来る。まーここまでいくとペルソナの話でなくシナリオの話になってしまうのだけれども、シナリオは個人的な意見としてはペルソナ無しには出来ない。

3.情報の伝達性
誰かに伝える時、もしくは同じチームメンバーと何かをシェアする時、ペルソナがいなかったら誰がユーザーかも分からず、ある程度分かっているにしても完全に同じマインドセットになる事は難しいと思う。自分で何かを開発したり考えたりするとき、一番分かりやすいユーザーは自分自身。ただそれは他のチームメンバーにとってもそうなはず。それを上手くシェアするためにもペルソナは必要。またシナリオを詳細に伝えるためにも、ペルソナもきちんとしておいた方がよい。そしてペルソナをきちんとした上でシナリオをチーム全体が共有する事でチームとして同じビジョンを持つ事が出来る。

ただ・・・デザインをsympathy と言う人もいた。
確かにそれを哲学として持っている人からすれば、ポストイットに書かれている情報の山よりもそれをまとめあげ、【人】として見る事の出来るペルソナの方がsympathy は上手く出来ると思う。細かいところだけど、ペルソナの強みはそんなところにもある気がする。常に「人の顔」を見ながら商品を作る。顔色でなくねw

そんなところが自分的に把握しているペルソナの強み・・・かな
たしかに重要そうな内容だけども、たとえば自分に時間がないときにこれをやるかと言われたら微妙かもしれない。

web制作に置けるペルソナの重要性などは
Togetter - 「web制作におけるペルソナの必要性」

ペルソナの必要性を開発者視点で説明してみる - ウェブユーザビリティ.JP

こゆとこに書いてあった。
webだと多少は違うのかもしれないけど、多くは同じかな。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

広告というお邪魔虫｜おもしろデザイン

こんな事書いて大丈夫なのかな
就職に影響ありませんように

ヘルシンキに行ったときに、バス停に広告があった。
まー普通の話

別のバス停には広告がなかった。
その理由は、みんなが１ユーロだか2ユーロだか払ったから。

お金を払って、広告をなくしたらしい。
そして広告の代わりにデザイナーだかなんだかの絵とかそゆのを載せたりした

まーシンプルなアイディアだけど
なんか好きだ。

インターネットとかだと有料会員、とかになるのかもしれないけどそゆの普及させても面白いかもなー

０円と１円の違いも０円と１０円の違いもあんまり変わらないように、
０か１かはデカイ。
けどそれでも払う人はいたりする。

なにやらスカイプとかにも広告が出てくるとかなんとか。
１００円くらいなら払うから広告なくしてほしいな

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

社会的プロブレムと個人的プロブレム〜デザインは人のニーズを満たして然るべき〜

〜デザインは「プロブレム」を解いて然るべき〜

というタイトルとは違うんです。

今回の話は、「プロブレムとは何か」

ME310のプロジェクトで、自身のプロジェクトは新しい水／ゴミ処理に関するサービスを作り出す事。
さらにそのサービスはグリーンでなければならない、というプロジェクトブリーフを貰った
（ちなみにME310のプロジェクトに興味がある人用に書いておきますがプロジェクトの形は様々です。自分のは多少ビジネスより、他にもコンセプトを作るもの、技術を応用するものなど様々な形のプロジェクトがあります）
プロジェクトを進めていく段階で「プロブレムファインディング」を行った。
ユーザーを観察することで、もしくはユーザーにインタビューをする事でそのトピックに対して人がどのようなアプローチを持っているかを考えるためのもの。
そのプロブレムがいずれ「ニーズ」に変わるための重要な位置づけになるのは言うまでもない。

そこで見つかった問題の一つに
「フィードバック」ってのがあった。
フィードバックがないから、エコ活動が無力に感じる、だからやらない。
「じゃぁフィードバックがあったら人はもっとエコ活動出来るんじゃないか？」
ってのはおそらくエコ活動系のプロジェクトに取り組む人なら誰もが思いつくような話だと思う。
ただ・・・ちょっとそこで疑問に思う。
たしかに、フィードバックを貰えば、人はグリーンに活動する事が出来ていた。それはプロトタイプ等で実証した。（多分探せば研究でもあるはず）
ただそのフィードバックにお金を払う人はどのくらいいるんだろう？？
もっといえば、それをユーザーにとってvaluable であるといってよいのだろうか？？

そこにフィードバックがあれば、人に目的の行動を行わせる事が出来る。ただ、そのフィードバック自体がユーザーの望むものかと言われればそうでもない。

それではなぜ、プロブレムを発見したのにニーズを上手くつかみきれない、そのような「勘違い」が起きてしまったのか？

確かにこのアプローチは「プロブレム」を解いていて、それを解決するためのある意味でデザイン的なアプローチである。
ただここで議論したプロブレムってのは、「人々がグリーンな活動をしていない」という問題。その問題をどのように解くのか？？？

その解はもちろん様々。ただ個人的な見解を言わせてもらえば、そこに問題意識を置く事時点でこれはもはやユーザーセンターのデザインではないのだ。

なぜならその「プロブレム」はユーザーのプロブレムではないからである

それは社会の作り上げた、勝手に言葉を作ってしまえば「社会的プロブレム」。
もちろん責任感の強い人は社会全体の作り上げた問題を解くために努力はする。そこにニーズがあるのもまぎれもない事実である。ただこれと（個人的に）対比させる事の出来るもう一つのプロブレムである「個人的プロブレム」と比べれば、そこに対するニーズの大きさは比べようもないほど違うのだ。

では「個人的プロブレム」とは何か？
それは例えば「お湯が最初でなくて冷たい」とか「ゴミが臭い」とか「ゴミ出し面倒」とかもっと言えば「パスタ作るのに時間がかかる」とか「起きるのがめんどくさい」とかそういった、個人それぞれがいやがるものや苦に思うもの。
デザインてのは「個人的プロブレム」を解いてしかるべきなのである。
個人的プロブレムにはユーザーの「ニーズ」が必ず存在する。
そしてそこにはそれを解くための「ソリューション」もいくらでも存在する。
そのニーズを満たしてこそ、個人的には「デザイン」

そのソリューションの一つとして、「社会的プロブレム」も解いちゃえ、というアプローチが個人的にはとても魅力的なアプローチ。
もちろん答えなんてないし他にもたくさんアプローチはあるけど、個人的なプロブレムを、社会的なプロブレムを解きつつ解決していくって道が個人的にはすきでそんな事ばっか考えてた。

例えばシャワーを浴びるときに最初の１分くらいは水が冷たい。
それをたとえばだけど目覚ましと連携させて起きた瞬間にお湯を最初の一滴からだせるような準備をしておく。（欧米の人は朝シャワーなので・・・）
そしたら最初のシャワーで冷てっってなることがない（個人的プロブレム解決）
そしたら少なくとも１分は長く寝れる（個人的プロブレム少し解決？？w）
そして毎日水の量も１分分は減る（社会的プロブレム解決）
さらにたとえばシャワーを浴びているときにコーヒーの準備でもいいしバスの時間を出すでもいいし、なんかいろいろ手伝える事したり出来たら・・・とか
ちなみに１分水の量が減ったらかなり水の使用量は減るけど、その分電気代とかかかってしまいそうだよな・・・改善が必要な案だけど、なんとなくそんな感じのアプローチ

他にも例えばパスタを短い時間で作れる機械を発明しようってなれば、個人的プロブレムは解決、んで社会的プロブレムも熱的な観点で見ればエコだったりする。

よくわからないけど、個人的にvaluable なデザインってののメインなフォーカスは「個人的プロブレム」に当てていないといけない気がする。

プロトタイプの限界の章にあるように、プロトタイプは形にしたものを改善する、もしくは評価するのはとてもいい。ただそれ自体が本当にいいものかどうかってのは測れない・・・かもしれない。

読んでいただきありがとうございます^^
コメント、もしくは評価ボタンを押していただけると幸いです。
↓↓↓↓↓

登録: 投稿 (Atom)

ヘッダー

2011/07/30

2011/07/29

2011/07/27

2011/07/26

2011/07/25

2011/07/22

2011/07/20

2011/07/19

2011/07/17

定義

ISO 9241-11

ニールセン

違い

2011/07/15

2011/07/13

2011/07/11

2011/07/10

2011/07/09

2011/07/08

2011/07/07