webディレクターの阿呆な研究

カンファレンスでグラフィックレコーディングが果たす役割、何だろう? ~CIVIC TECH FORUM 2016のグラレコ隊から考える~

img_160327evy「カンファレンスでのグラフィックレコーディングの果たす役割ってなんだろう?」と昨年からずっともやもやしていました。

イベントでグラフィックレコーディングを描くと、喜ばれる。写真をとられる。
その場は盛り上がって、なんか嬉しい。
でも、そのあとってどうなるんだろう?

また、カンファレンス等で描く場所が増えれば増えるほど、「なんでグラフィックレコーディングなの?」「絵の議事録でしょ、それよりちゃんとした文章がほしいと自分は思う」という話をよくきくようになりました。

今回は、CIVIC TECH FORUM 2016のグラレコ隊として、イベントにかかわる中で「カンファレンスでのグラフィックレコーディングの果たす役割ってなんだろう?」について考え続けました。

詳細はこちら

対話の場を、グラフィックレコーディングで深める ~Code for Nagareyama IODD2016の事例~

160315_img「グラフィックレコーディングって、絵の議事録でしょ?」
「イベントで最近よくみるけど、結局写真とって終わりで、あまり意味なくない?」
グラフィックレコーディングを描いている話をすると、時々そんな質問をうけることがあります。

同時にグラフィックレコーダーからも「イベントで描いてその時は喜んでもらえたんだけど・・・結局かきっぱなしになっちゃってる気がする。」という声もきくこともあり。
グラフィックレコーディングが注目をあびればあびるほど、コミュニケーションのいち手段であるという側面が見えづらくなり、パフォーマンス面が目立つようにここ最近感じます。

グラフィックレコーディングは、コミュニケーションのためのいち手段。
グラフィックレコーダーは、『場』をつくる一員。
では、グラフィックレコーダーは、どんなコミュニケーションを目的に、どのように『場』をつくるといいんだろう?

そんな問いのもと。
ここ最近、依頼をうけた案件については、極力『場』をつくる一員として、企画や進行に提案を行うようにしています。
Code for Nagareyama IODD2016「SNSといじめを考えるワークショップ」にて、ひとついい形をうみだせたなーと思うので、事例紹介として記録にのこしておきたいと思います。

詳細はこちら

webディレクターが人間中心設計(HCD)専門家認定制度うけてみた話

img_160223webディレクターやってはや10年。
サービス開発の現場に立ってUIとかUXとか考え続け、気付けば5年。
一つの区切りとして「なんかやったぞ」感をのこしたく、人間中心設計(HCD)専門家認定制度をうけてみました。

12月は受験申し込みだけした

受験申込書をだしたあと、12/26~台湾に旅行⇒年末夫の実家にいき、そのまま年始まで帰宅しないという生活をしていました。
当然申請書類は一切手をつけず。
1/1に帰宅して、「年始だしやるか!」という謎の年始の勢いにかられる中。
このスライドみて脱力しました。

img_160223_2

無理ですからぁってアンタ。

・・・そして書き始めて、「無理ですからぁ」をかみしめました。

私のやった案件、どこにかけばいいの問題

人間中心設計(HCD)専門家の書類のうち、特にボリュームが多く大変なのが、B3『B-3 コンピタンス記述書(専門家資格受験者)』。
大量のexcelのセルをみて、まず愕然。

そして、上から順番にうめていくのですが。
『B1 プロジェクト企画能力』をかいて、さあ次は『B2. チーム運営能力』『B3. プロジェクト調整・推進能力』だ!と思って項目をみると。
・・・・あれ、B1で書いたことと同じことかいてない?
同じことが、Aの12個のHCD基本コンピタンスにもいえます。

「とりあえず何も考えず書こう、あとからいらん部分は消そう」と思い定め、かきたいことをあっちゃこっちゃに書き散らした結果。
私の年始の休みはすぐに終わり(たぶん8時間くらいは使った)、1案件(しかもユーザーテスト企画実施というだけの、一番軽いはずの案件)しかかけない状態となっていました。
どう考えても書きなおししないといけないクオリティ。
この状態で締め切り前一週間前だったら、絶対先のボリューム想定して絶望して出願諦めていたと思います。
ああ。これが「無理ですからぁ」なのね・・・・

年始に会社にいって、コンピタンスを印刷して眺めてると。
ふとどこに何をかくべきかが見えてきた瞬間がありました。
「ああ、これHCDの各サイクルの部分を集中して書けばいいのか。」
↑言葉でいうのは簡単だけど、感覚としては伝わりづらいので。
ここを今回言語化してみようと思いブログをかきました。

『B-3 コンピタンス記述書』=家庭料理の状況・課題をこまかく書いてくかんじ。

私はこのコンピタンス記述書を書く大変さを、「正しい料理方法を知った上で、家庭で毎日のごはんをつくれるようになったことを文章をかいて証明する」という風に感じています。

例えば、『だしをとる』という過程。
・だしが必要な理由:うまみのもとになるから。特にグルタミン酸イノシン酸を組み合わせると人間はうまみを感じやすい。過剰な油脂や糖に頼らなくてもおいしさを感じることができる。
・だしのとり方:冷たい水にこんぶをつけて、ふっとう直前になったらかつぶしをくわえて、そのあと濾して冷蔵庫で保管。

でーもーねー。
一般家庭で毎日毎日だしをとるって大変です。
そんなときに、『B-3 コンピタンス記述書』風にかくとこうなるのかなと思います。

課題/目的の明示
・私は共働きで、毎日帰宅が夜遅めで、しかも体力ない。深夜に食べると太るので、できるだけすぐごはんをつくりたいと思っている。

・でも、おいしくて健康的なものを食べたい。夫の健康診断の結果も気になる。

・塩分をとりすぎないように、だしをしっかりとりたいと思う。

なぜその方法を選び、どのように企画設計したか?工夫したことは何か。
・うまみ成分をいれて、過剰な塩分をとりすぎないようコントロールすることが味噌汁の調理には求められる。

・だしはパルシステムの顆粒だしを利用することにした。パスシステムの顆粒だしは、化学調味料の強い味がせず、味わいがやさしく自然なだしの味に近しいため。また、ふりかけていれるだけのため、だしをとる時間を圧縮することができる。

・また、パルシステムの顆粒だしは1本で味噌汁4杯分つくれる仕様となっており、1回につき半分を使えばいいため、利用量がわかりやすい。塩分とりすぎを自然と防ぐことができる。

・水300mlに顆粒だしと、うすめの半月切りにした大根をいれて、大根に火が通るまで沸騰直前の状態で火を通した。大根に火がとおったら、油揚げを入れ、味噌をいれ、放置し他の炒め物料理を作成。この放置時間でさますことで、食材に味がしみることがねらいである。また、炒め物は先に作ると放置できず水分がでてくるので、煮物の工程を終えてから調理を実行することとする。

・炒め物料理を食卓にだした後、再び火を入れて味噌汁をあたためる。このとき、ふっとうすると味噌本来の風味がとんでしまうので、沸騰させないように気をつける。

・味噌汁をお椀にもる。このとき、大根の葉をきざんでのせる。彩りよく見えるようにするためと、栄養価をあげるためである。大根の葉は緑黄色野菜に分類され、βカロテンやビタミンを多く含んでいる。

どうでしょう?
「大根とあぶらあげの味噌汁をつくる」という味噌汁をつくるという行動すら、長くなるので書くのがすごく大変なのです。
また、背景情報は自分にとってあたりまえの情報で。
このあたりまえの状況を客観視して、手法をえらんでいくということ自体、けっこうやれてない部分なのかんとかんじました。
(例:お母さんがいつも顆粒出しいれてたから、私もなんとなく顆粒だしつかうもんだと思ってた状態)

トータルとしては、各コンピタンス、脳内でこんな変換をしてみると、直感的に理解できるのかなーと感じています。

A:料理の基本力
※料理プロセス⇒家族を見る・何が必要か考えて外化・献立つくって料理・評価する のもとになる力
【家族を見る】
・A1 食べる家族について調べる時、どう調べるか考える能力
・A2 食べる家族の行動や好みを調べる能力
・A3 調べた内容を分析する能力
・A4 調べた内容を見える化する能力
【何が必要か考えて外化】
・A5 食べた家族がどう幸せになるといいか考える能力
・A6 家族がどんな献立や栄養を食卓に求めているか検討する能力
・A7 長期的に家族が健康でいるために栄養を考え、毎日どうやれば持続可能に食卓をまわせるか考える能力
【献立つくって料理】
・A8 栄養を考える能力
・A9 料理をつくる能力
・A10 献立をつくる能力
【評価する】
・A11 下味つけた段階で調整していく能力
・A12 家族に味見してもらい、その結果をうけて改善しおいしい料理につなげる能力
・A13 するどい舌で味見する能力

B:毎日の台所をつかさどる力
・B1 今の家庭に必要な毎日のごはんを考える力
・B2 手伝いする家族をまきこむ力
・B3 現状の家庭状況にあわせて料理をする環境をつくる力

C:自分の家や親戚の家庭に料理プロセスを教えていく力
※料理プロセス⇒家族を見る・何が必要か考えて外化・献立つくって料理・評価する
・C1 どうすれば自分の家族や親せきの家に料理の一連プロセスを伝えていけるか考える力
・C2 自分の家族や親せきに、料理のプロセスを伝える力
・C3 自分の家族や親せきが料理のプロセスをできるようにそだてる力
・C4 自分の家族や親せきが料理のプロセスをできるようにそだつため、教える手法を考える力

L:ひとと一緒に料理をつくっていく時のテクニック
・L1 人と一緒に料理をしていく際、献立や料理をうまく文書で伝える力
・L2 人と一緒に料理をしていく際、献立や料理がすてきなおいしそうなものと感じられるようみせて伝える力
・L3 人と一緒に料理をしていくために、家族や親せきをうまくまきこんでいく力

大事なのは、
・自分のおかれた背景状況を客観的に理解すること
・その状況にあわせて、基本をしったうえで、適切な目的設定をし、適切なタイミングで、適切な効果を得られる手法をくみあわせること
・手法にたいしての評価を行い、次につなげること
だと思います。

知識を多くもった人とか、手法をたくさん知っているひとが専門家なのではなく。
この状況把握および適切な手をうちつづけられる人が、人間中心設計専門家なのかなと感じています。

この感覚を得た時『B-3 コンピタンス記述書』がとてもかきやすくなりました。
まあそれでも大変だったんですけどね・・・・。たぶん60時間くらいトータルでかけてると思います!

人間中心設計で大事なこと

「UX学んだから、手法たくさんしってるんだよね、知識がたくさんあるんだよね」
産業技術大学院大学にいって、人間中心設計を学んだとき、会社でそういってくる人がいました。

違うんです。
知識量とか手法できる人じゃなく、現場で活かして事業を前にすすめてこその力なんですと。

私のもってる現場は、別にそうひろい台所ではないし、最先端のイケてる調理器具とか最先端の調理人がいるところではないと思います。
私自身、じゃあ最先端のスキルもった料理人かっていうと、絶対NO。

でも、ものをつくるときに、つくって誰かにみせて、こわして、またつくって…というプロセスはそれなりにまわせるようになったんじゃないかなあと思うのです。
まだまだ修行中ではあるけれど。
専門家とれるかとれないかはわかりませんが、書いたことでなんかすっきり、次へいける感がしてきました。

そんなことおもいつつ。
今日は夫も長期出張でおらず、自分ひとりのため、大鍋に牛肉1kg+筋肉いれて、大量の牛筋にこみをつくってしまいました。
しかも1品だけ。
大根人参つっこんでるけど、栄養かたよりまくりです。料理プロセス設計能力ゼロ。
すごいうまいんだけど、誰がたべるんだろうなあこれ。

『現場を前に進める』グラフィックレコーディングの活用と対話の必要性

img_16021252/13(土)Devlove関西さんからご招待いただき、大阪で『グラフィックレコーディング~構造化のコツ~』というワークショップを実施しました。
今回はグラフィックレコーディング3つのスキル「聴きとる」「表現する」「構造化する」の中でも、構造化に重点を置いたワークです。

私自身、会社でグラフィックレコーディングを用いるか?というと実はあまり使ってなく(アクティビティシナリオやストーリーボード考えるときに使うくらい?)、グラフィックレコーディングのスキルを活かして現場で動いている、という状態です。
特によく使ってるなと思うのが「構造化する」という部分。

会議の内容をリアルタイムで関係性を示し、それをもとに考え、進行するという「構造化」。
「構造化には、いったい何がコツとして必要なんだろう?」
そう考えたく、ワークショップを設計しました。

私自身、ワークショップをやって見えたこと、感想戦をやってようやく見えたこと、それぞれあったので記録に残しておこうと思います。

詳細はこちら

web業界共働き夫婦の不妊治療、仕事、夫婦関係

img_151202001jpgこの記事は 家庭を支える技術 Advent Calendar 2015 – Adventar 12/20の記事です。
テーマは「不妊治療」。
自分一人の問題ではないこと、また知り合いが読むことも十分に想定されるので、書くことに抵抗がないわけではないですが。

自分の気持ちの整理の言語化に加え、少しずつ知見が高まってきたこと、あとこの問題に取り組んでることについては(ある程度までは)周囲に「えいやー!」と公開してしまったほうがラクだなあと思ったので、えいや!で書いてしまうことにしました。

詳細はこちら

そうだ、ユーザーテストのユーザーテストをしよう!『ホリエ式』について

151209この記事はUX Tokyo Advent Calendar 2015の9日目の記事です。
ここ数年の上司・仲間との活動が実って、社内ではユーザーを見ることでの設計の大事さが少しずつ根付いてきてはいるものの。
まだまだ属人的な部分や、やれてないなあというところもたくさんあるのが現状です。

特に最近「うおおどうしよう!」と思ったのが、ユーザー調査のまきこみ方。
社内でとあるサービスのユーザー調査(ユーザーインタビューとユーザーテスト)をすることになったのですが。
「今回、ユーザー調査が初めて!」というメンバーが大半でした。

その中で自分がどういう関わり方をすると、プロジェクトに活かせるデータをとることができるんだろう?
それぞれのプロジェクトにもちかえって活かすことができるんだろう?
初めてのメンバーでも興味をもって楽しく関われることができるんだろう?
色々悩んでた時に、ユーザーテストのユーザーテスト兼勉強会の場として同僚が提案してくれた方法がすごく楽しかったのでブログにのこしておこうと思います。
名付けて『ホリエ式』(ホリエさんが提案したので。安直w)

ユーザーテストのユーザーテスト兼勉強会『ホリエ式』について

事前準備

・ユーザーテスト用の記録用紙(行動・思考発話を記録できるフォーマット)を用意
フォーマットは 【マンガ】成果を出す!手作りユーザーテストのすすめ に記載した内容

・ユーザーテストのタスク設計は本番と同じものを自分(経験者)がやっておく

・ユーザーテスト開始時のトークスクリプト、OK会話集、NG会話集をつくっておく
ユーザビリティエンジニアリング(第2版) ―ユーザエクスペリエンスのための調査、設計、評価手法―をコピーして渡す。

『ホリエ式』スパルタ塾

・1限目 15分「15分でわかるユーザーテスト」
実際のユーザーテスト短縮版。解説なしとりあえず見ろ精神。
進行役は私、被験者は参加者の中から任意、記録者はホリエ氏(=ユーザーテスト経験者)

・2限目 15分「15分でわかるユーザーテスト解説」
実際にとった記録を見ながら・おさらいしながら何をしていたか説明。

・3限目 60分
「スパルタ実践。30分で実際にユーザーテストやってみよう」
1班A:進行 B:記録 C:被験者
2班DEF3人:ギャラリーは良い点改善点を1班に伝える

2班D:進行 E:記録 F:被験者
1班ABC3人:ギャラリーは良い点改善点を2班に伝える

総括

事前準備の意図

・自社では、ユーザーテストの記録フォーマットを統一するために、行動・思考発話を記録できるフォーマットを用意しています。
書く人が自ずと行動と思考発話を切り分け、集中してかきとれるようになっているので、毎回重宝しています。

・ユーザーテストのタスク設計は、正直初めてのメンバーには重い荷だなと感じています。
今回は3プロジェクトで利用する目的があったのでプロジェクトメンバーに「このデータとれたらどう使いたい?」と事前ヒアリング⇒タスク設計⇒調査目的の明示を私のほうでやってしまいました。
設計こそ肝なれど。初チャレンジの人には、まずは『ユーザーテストってどんなん?』を体で覚えて、その大事さとかおもしろさを知るほうが次につながるのかなーと最近は思っています。

・トーク集用意するのも、質のよいデータをあつめやすくするため。
本当は「なぜその質問がいいか?」等質問方法について座してみっちり学ぶのがベストとは思うのだけど。現場だとその時間がないので先人の姿をみて学べ方式です。
ただ、さすがに誘導尋問とか、なぜなぜ攻撃、自分の仮説検証に走り出すような「こういう質問はNGだよ」例はつくり、共有しました。

『ホリエ式』のねらいと実際にやってみた感触

・とりあえず目の前で見てみる。
ユーザーテストがなんぞやという説明をするよりも、目の前でやってみせたほうが「それがなんなのか」は伝わるなと感じました。

・みたものの解説
実際にやったユーザーテストをねたに、基本的な流れ(イントロの説明、ユーザーがさわっているときに観察してみているところ(行動や思考発話)、ユーザーから質問をうけたときの返し方)のネタバレをします。
自社では、必ず進行の人と一緒に記録者をユーザーテストにはつけています。
進行の人のやったことのねらい、そこを記録がどうかきとっていったのかというのを対にして見せていくことで、それぞれの役割がだんだん見えてくるようになります。

・スパルタ実践
あとはもう実践。あんちょこみながらでいいので、ユーザーテストを実践してもらいます。
ポイントとしては、ギャラリーが実際に見ながら、実施した人たちの「よかった点」「改善点」を考えて伝えるというところ。
人の進め方を能動的にみられるようになるし、「おお、これはいいな!」と思った点を場に共有していくことで皆がそのいいところをとりいれてみたくなるのです。
また、改善点についても、自分一人では気付けない部分につっこんでもらえるので、「本番はこれを気をつけよう」とチャンレジしてみる気持ちになるみたいです。
ここからどんどん場があったまっていくのを感じました。

・総括
実際にやってみて、じゃあユーザーテスト本番ではどんなことをしたい?を雑談。
「フォーマットはこの欄がほしい!」「ユーザーの背景をきく質問をもっとしてみようと思った、ユーザーインタビューもしっかりきこうと思う」「このタスクって実は○○じゃない?」と、本番にむけてすごく意見がでてくるのです。
今まで一方的めな座学でユーザーテスト勉強会やってきたときより、皆が本番を楽しみにしている感。
はじめての熱量だったので、すごくわくわくしてしまいましたw

———-

ユーザーテストというと、なんか専門的・体系的な知識、機材の使い方を知ることが必要なのかな・・・と最初は尻ごみしてしてしまう部分があるなと感じています。
自分がユーザーさんの前で失敗したら、せっかくきてくれたユーザーさんにも申し訳ないし、プロジェクトにとっても残念な結果になってしまう・・・少なくとも、ユーザーテストをはじめた頃、私はそんなどきどき感でいっぱいでした。
だけど、その一歩を恐怖ばかり考えて踏み出さないのはもったいないなと思うのです。

もちろん、ユーザーを見るという行為はやればやるほど、専門知識や体系的な知識、経験や共感する力が必要だと痛感します。
でも、まず最初は。
ユーザーをみてみることで、「気づいてなかったいろんなものが見える!」というおもしろさに一番にであってほしいなあと私は思うのです。
『ホリエ式』の価値は、この出会いをひきよせる大きな力になるなーと感じています。

「気づいてなかったいろんなものが見える!」というおもしろさは、新たな発想に繋がるし、チームでの推進力をもうみだす。
まだその発想部分や、推進力となれる部分を、自分が組織で拡げてきっているかと言うと答えはNO(苦笑)。
一気に拡がる気はまだまだしていません。
少しずつ、少しずつ、組織でゆっくり育てていければいいのかも。
『ホリエ式』がうみだされたように、きっといろんなやり方が、みんなの中からでてくる日がくると思うのです。

それが組織の中で、UXデザインが根付いてくるということではないでしょうか。

ファシリテーションする中で感じた弱さと、新しい風景をみるために動いたこと #fsAD

img_151207この記事はファシリテーター Advent Calendar 2015 6日目の記事です。
高柳さんからのお声掛けいただき、執筆することにしました。
お恥ずかしながら、体調不良により、1日おくれでの投稿です。

2015年は、ファシリテーションに向き合う年でした。
私がファシリテーションに出会ったのは2004年頃。
A SEED JAPANという環境NGOで会議の進め方研修として学んだのがきっかけでした。
会議を時間内に、目的どおり、実りある議論にするためのもの。
横道にそれないよう、うまく導くもの。
それが私にとってのファシリテーションだったのですが。
今年、その認識ががらっとかわりました。

『自分が導く』ではなく『参加者の思いが溢れだす』へ。
『ひとりで』ではなく『バディといっしょに』へ。

詳細はこちら

フェリス女学院大学『社会的起業』(春木良且教授)の授業でグラフィックレコーディングのワークショップをしてきました

img_1123_s11月9日(月)、フェリス女学院大学『社会的起業』(春木良且教授)の授業で、グラフィックレコーディングのワークショップを実施してきました!
一緒にワークショップ設計&授業をしたのは、グラフィックレコーディング勉強会メンバーのファシリテーター西田武史さん、グラフィックレコーダー増山和秀さん。

この『社会的起業』の授業は、PBL(Project-Based Learning 課題解決型学習)という形式をとっています。
大学外部の方から社会的な課題を共有いただき、社会的な課題を考えていく中で学びあうそう。
グループで社会的課題を考えるにあたり基本となるのが、思考する力、発散収束する力、異なる立場の人に伝える力です。

春木先生からご依頼いただき話を伺う中で。
「どうやったら、グラフィックレコーディングを通じて、情報を『見える化』するの大事さ・手法を学べるのか?学生みなさんが社会に対してアクションしていく一助になれるのか?」という問いをずっと考え続けました。

詳細はこちら

発想ファシリテーション論(2015)-産業技術大学院大学 「人間中心デザイン」

img_151114産業技術大学院大学、人間中心デザイン履修証明プログラムの復習レポ第10弾「発想ファシリテーション論」です。
去年発想ファシリテーション論の授業振り返りブログを書きましたが。
今年はブログに加え、グラフィックレデコーディングも描いています。
去年学んだ内容を、再解釈もぐもぐした結果。
全く別の味わいになってたことに気が付きました。

↓グラフィックレコーディングはこちら
151114_grec
詳細はこちら

Code for Japan Summit 2015でグラフィックレコーディングやってきました #‎cfjsummit‬

img_15111211/7(土)11/8(日)、Code for Japan Summit 2015でグラフィックレコーディングやってきました!
全国のcode for xから関係者がサミットにあつまる中。
総勢16名のグラフィックレコーダーも、首都圏近辺、静岡、岐阜から集結しました!

詳細はこちら

UX方法論-産業技術大学院大学 「人間中心デザイン」

img_15110101_s産業技術大学院大学、人間中心デザイン履修証明プログラムの復習レポ第9弾「UX方法論」です。
わたくし2014年度で履修証明をしっかり修了しましたが。
2015年度授業にも卒業生としてお邪魔して、復習グラフィックレコーディングをしてきました。
(浅野先生、押しかけグラレコ受け入れてくださりありがとうございました!)

詳細はこちら

勉強できない自分が、勉強できるできない超えて、とにかく学びたい時のノートの書き方

imgm_151028ノートの取り方が話題になっている。
勉強ができる人とできない人の、ノートの取り方における決定的な違いについて
多分勉強ができていた私は、具体的にどうやってノートを書いていたか
このあたり読んだ。で、思ったこと。

勉強できる人=ノートの情報編集をやってる人ではなかった気がする。
感覚値でしかないんだけど。偏差値60台までは美しくノートをとっている人は多かったけど、東大にいくレベルで偏差値70台以上の人はノートぽいものとってなくてもできていた。
ひとつの何かから一気に記憶する力、思考していく能力ともに相当高い『できる人』。

『不倒城』の人は、まさに『できる人』のように思う。
こういう人はひとつの何かから一気に色々正しく思い出せるから、「明日の自分は今日の自分とつながっている」と信じられてるのではないか。

・逆に私は「明日の自分は全くの赤の他人。」
100言われるとと明日には99忘れる。内部記憶メモリが10年以上前のPC状態。
すがすがしいほどの残念ぷり。
だから何かを心から学びたいと思ったら、内部記憶メモリがない以上、明日の自分=他人にむけたものを残しておく(外付けハードディスク)の存在が必須だったのだ。
明日の自分=他人にむけたもの=情報編集をしっかりやったものを残す。
それが私にとってのノートの存在。

詳細はこちら

「伝えるものづくり」じゃない、「溢れだすものづくり」へ

img_151022最近、人生の目指す方向が、がらっと変わった。
「伝えるものづくり」じゃない、「溢れだすものづくり」へ。

生きることはつくることに他ならない。
「ああ、これからずっともっと創れるなあ」て気づけたのが、今はただただ有難いなと思う。

詳細はこちら

webディレクターがワイヤーフレームを限られた時間内に書くための工夫

150908ディレクターやって10年。
昔はワイヤーフレーム作って煮詰まっていつまでたってもできない、という状況になっていたんだけど。
ようやくどうやったら自分がワイヤーフレームを書く時、どうやったら限られた時間内で品質をあげられるかが見えてきました。

これはあくまで自分だけの話なので恐縮ですが、限られた時間を自分がどう使えばワイヤーフレームの品質をあげられるのかをざーっと書きだしてみました。
他の人の工夫もぜひきいてみたいところです。

詳細はこちら

UXデザインのための観察リサーチ入門 ~ユーザーテスト、ユーザーリサーチの基礎力を体験して学ぶ~を開催しました

img_150906産業技術大学院大学人間中心デザイン同期のメンバーを中心に、「みる研究所」という組織を立ち上げまして。
第一回のイベント『UXデザインのための観察リサーチ入門 ~ユーザーテスト、ユーザーリサーチの基礎力を体験して学ぶ~』を開催しました。
「みる」(今回は観察(オブザベーション))することの必要性、そしてワークショップで得たかった学びについて、色々考えさせられたイベントでした。
今回はそのあたり、つらつら書いていきたいと思います。

みる研究所ツイッター
みる研究所FBページ
・webサイトは作成中

「みる研究所」について

UXデザインを学び、実務をやっていく中で痛感したのは、『一人でやることの限界』でした。
自分とは違う多様なステークホルダーと一緒に、自分とは違う多様なユーザーのためにデザインをする。
そんなものづくりの過程において、どんなに学んだとしても、自分の力の及ぼせる範囲は限界がある、と痛感しました。
同時に、誰かの意見から想定してない世界が開けるのを何度も何度も感じました。

ずっとこうやって、ものづくりをしていきたいなあ。

そう思ってた矢先、代表の津崎さんの「産技大のメンバーとこれからもつながっていたいーーー!!」言葉に思いっきり引きこまれて。
組織を超えてUXデザインを学び、実践する場として「みる研究所」を立ち上げるに至りました。

詳細はこちら

消化しきれない自己嫌悪、どうすれば消化できるか?

img_15090210代の頃失恋したときは、数歩歩くたびに涙がでてきたし、言葉を発しようとするだけで嗚咽が出てきた。
ぐるぐる考えれば考えるほど、どうにもならなくて。
電車にも乗る気になれず、泣きながら歩きつづけた結果、セーラー服とローファーで多摩丘陵を山越えしてしまった。

私は何か考えたくなると、とことんぼーっとして歩いてしまう癖がある。
三十路超えててこんなこと言うの恥ずかしいのだけど。
ここ2週間くらい、自己嫌悪の真っただ中にいたので、やっぱり都心をぼーーっと歩いてしまった。
恵比寿から世田谷。中目黒から世田谷。下高井戸から世田谷。
多摩丘陵の山越えに比べれば存外近かったように思う。
さすがにもう、数歩で涙なんかでてこないし、言葉を発してもすぐ嗚咽なんてでてこないけど。
家族とか、気を許した友達の前にいくと、ふと消化できなかった自己嫌悪と涙が出てきそうになって困ってしまった。

詳細はこちら

webディレクターが上流工程を進行するときに必要な5つの力(=生態系の中で生きていく力)

img_150803デザインのディレクションをやっていると、「なんでこの組織って、こんなやり方・考え方にとどまっているんだろう?もっとこうした方がいいのに。もっともっと変えたい!」と思うことが本当にたくさんある。
クライアントワークしかり、自社サービスしかり。

自分ならもっとうまく自社サービスのデザイン考えられる、と思って受託から自社サービスに転職してはや6年半。
「自分ならもっとうまく!」はとんでもない思いあがりだった。
やっぱりまだまだだなあー、もっともっと知らなきゃいけない、考えなきゃいけない部分があるっていう事実に直面している。
UX戦略フォーラムピーターモービル氏が「生態系」と話をしていた部分。
自分たちのサービスデザインにおける生態系において、問いはたくさんある。

どんなユーザーか。
そのユーザーは何を大事にしているのか。
サービスを担うステークホルダーがどのくらいいるか。
そのステークホルダーはどこにいて、何を大事にしているのか。
自分たちは何が強いのか。何が弱いのか。連鎖関係のどこにいて、どこにむかっているのか。

一つ一つの問いをひもといては、新たな情報設計と、情報設計のプロセスをデザインしていくのが私の仕事になってる。

変容する『進行管理』の意味合い

ディレクターとして1~4年目くらいまでも、もちろん情報設計はやっていた。
ただし、依頼された案件を見やすくわかりやすく整理するという情報設計。
進行管理は、エクセルでスケジュールをひいて、それを守って納期どおり進めていくというのが中心。

ただ、ここ数年その進行管理がかわってきたように思う。
そもそも『何を作るのか?なぜ作るのか?誰につくるのか?』自体をクリアにしていくことが求められてきたのだ。
いわゆる上流工程の進行管理も含まれてきたんだと思う。(下流工程もやるけどね)

この上流工程の進行管理にかかせない力が5つあるなーと最近は思う。

  1. 越境して、相手の思いや考えをひきだす力
  2. 皆の考えを可視化する力
  3. 考えを可視化したものを、現実のデザインに具現化する力
  4. 可視化したものを評価し伝える力
  5. 続ける力

『越境して、相手の思いや考えをひきだす力』『皆の考えを可視化する力』

このあたりは、IA CAMPでの三澤直加さんのプレゼンがすごくいいなーと思ってる。

役割を超えた人と人が、交わり考えるために、IAに必要なことは?
「相手の立場になってきく」「考えを可視化する」
その人ならではの情報を そのままの想いと共に抜き出し “それが伝わるように編集する”
⇒次のアクションを生むIAへ
「顧客から引き出す技術」–インタビューとグラフィックファシリテーションの共通点 by 三澤 直加 – presentation from IA CAMP 2015

自分一人でのアイディエーションなんて、所詮限界がある。
いつも予定調和になるのだ。一人だとはやいけど、たいして遠くにはいけっこない。
ユーザー、ステークホルダー、いろんな立場の人の気持ちがみんなわかるわけでもない。
だから越境して、相手の立場を理解し、思いや声をひきだすのがデザインの第一歩になるんじゃないかなと思ってる。

そして、思いや声、考えといった見えないものを見える化していく。
この「見える化」の段階でディレクターとして一番大事なのは、自分の意見をその中でひからせるスキルではない。
よいアイディアを多くのメンバーからひきだし、その見える化自体をつかさどることだ。

『考えを可視化したものを、現実のデザインに具現化する力』

次に求められるのは『考えを可視化したものを、現実のデザインに具現化する力』。
これがないと、絵に書いた餅ビジョンを掲げる人にしかならないので。。
具現化したと認めてもらうには、最低でも情報設計(IA)の技術が必要なんだろうなーと思ってる。

・子供のアイデアはそのままつかえるわけではなく、そのイメージを具体化・精緻化するのはプロのデザイナーの仕事。大人にはない発想を取り入れるために計画的に巻き込んでいる。
子供と一緒にデザインする方法 Kamihira_log in Copenhagen

この具体化・精緻化するための理想はフルスタックデザイナー。
情報設計もグラフィックデザインもマークアップもエンジニアリングもなんでもござれ状態になると無敵かと。

任せられる部分は人にまかせるのもありだけど。
任せる部分が多い=ある種の信頼とコミュニケーションにかける力、プロがいる前提が必要にはなるので、制約がでてくるのも事実だというのは肝に銘じるべきだと思う。
自分の技術とコミュニケーション能力と信頼貯金から判断して、何のスキルを磨いていくべきか、活躍できる場はどんなところか考えるといいのかもしれない。

『可視化したものを評価し伝える力』

実際にデザインができたら。実際に評価する力が求められる。
ここって評価する具体的な知識とか手法以上に、自分のデザインを壊す勇気が一番大事なんじゃないかとも思うのだ。
言いかえると、自分がベストだと思った案がベストじゃない、もっといいものがあるから壊して作りなおそうと評価できる勇気。

もうひとつ。「生きてるよ~成果でてるよ~」と数字で伝えていく力がもとめられると思う。
評価としてログ解析等ビジネスにいきる評価を行い、データをビジュアライズして、組織に伝えていく力だ。
この力は信頼貯金=生態系の中で他者からみた生命力を徐々に増やしていく行為に他ならない。

『続ける力』

そして最後に。
続ける、というのが一番必要なパワーなんじゃないかと思うのだ。
成果なんてそうすぐでやしないし、大きい変化を生態系に一気にもたらすことなんてできない。
1匹、また1匹というように、小さいひなを育てていく力が必要だ。

一つの生態系に変化をもたらすことがどれだけ大変かは、NHKスペシャルの「小笠原の海にはばたけ ~アホウドリ移住計画~」を見てると実感する。

そんな絶滅の危機に瀕したアホウドリを人の手で復活させようという計画が、8年の歳月を経て、今年、ついに成功のゴールにたどり着いた。「アホウドリ移住プロジェクト」。
主な繁殖地、伊豆諸島の鳥島が噴火の危険があるため、350キロも離れた小笠原諸島の無人島に、安全な繁殖地を新たに作ろうという壮大な計画だ。
まずは生まれたばかりのヒナを小笠原に移し、人の手で育てて巣立たせる。ヒナは成長後、育った場所に帰って繁殖する習性があるので、新天地で結婚と二世誕生までこぎつければ、あとはアホウドリ自らの力で継続的に繁殖できるようになるはず、という計画だ。
前例のない試みのため、ヒナのエサやりひとつにも苦労の連続。研究者たちは様々な困難にぶつかりながら手さぐりで試行錯誤を続け、今年ようやく、人工飼育したアホウドリが2世を誕生させたことが確認された。
小笠原の海にはばたけ ~アホウドリ移住計画~

アホウドリの移住。
ただ移住するだけなら、かたっぱしからアホウドリをつかまえて、別の島へうつせばいだけだけど。
アホウドリは生まれた島に帰ってくる習性をもつので、ある一時期だけ島にいる鳥をうつしても、またすぐにアホウドリは島へかえってきてしまうため、何も問題は解決しない。
ひなを別の島へ引っ越しさせて、その島でひなをそだてて、数年後うまれた島へかえってくることをまち、またそこで新たなひながうまれ育つのをまつ・・・という長期的な計画が必要となる。

その長さ、8年。
ただただ頭が下がる思いだ。

本当に生態系を変えたい、て思うなら。
長期戦は覚悟しなければいけないし、まずはじめるのは小さいところからだ。
webデザインの現場なら私はだんぜんユーザーテストから開始をおすすめ!
成功したら生存を伝え続けるし、失敗しても「失敗したけどこんな学びがあったから次にこういかせるぞ」と次へいかす。

この明日を作る小さいくりかえしこそが、生態系に新たな影響を及ぼしていくんだと思う。

—–

正直、自分が生きていくために生態系を変えるのって割にあわないかもしれない。
どうやっても変わらない、変わろうとしない生態系だってあるだろうし。
だとしたら生きやすい生態系に移動する=転職するっていうのも十分ありなんじゃないかなとも思う。

どんな組織が変化を受け入れず滅びゆく生態系となってしまうのか、をもう少し深掘りたいので。
終戦70年目だし、8月なので次は『失敗の本質―日本軍の組織論的研究 (中公文庫)』読んでみる予定。

私は今の自分がいる生態系=会社がなんだかんだいって好きなんだと思う。
信頼できるバディ的な同僚がいること、尊敬できるエンジニアがいること、挑戦させてもらえる環境を上司にたくさんつくってもらってこられたこと。
今同じ生態系にいるメンバーも、これから生態系に移動してくるメンバーにも、住みやすい世界にしたいなと思う。

※補足 アホウドリの写真は以下より引用。鳥さんかわいい。
http://free-photos.gatag.net/2014/09/21/140000.html
著作者:JJ Harrison

裸になって、助けて、助けられての繰り返し

img_150726「バディを信頼しているか?」

先日、Devlove関西でのグラフィックレコーディングワークショップが終わった後の恒例・感想戦。
Devlove中村さんと、一緒にワークショップを進めてた増山さん、アドバイザー三澤さんとそんな話になった。

バディという言葉は、映画『海猿』できいたことがある人もいると思う。
時に死と隣り合わせという職務上、潜水士が二人一組で常に行動しあうパートナーという意味。

詳細はこちら

「グラフィックレコーディングをやってみよう!ワークショップ」レポートと、グラレコ勉強会の即興性

img_cap_1506206月20日に、リクルートホールディングス本社にて、「グラフィックレコーディングをやってみよう!ワークショップ」を開催しました。

応募開始から1日で満席、キャンセル待ちが続くという大盛況ぶり。
増席したい気持ちは山々だったのですが。
ワークショップの内容上、参加者の方にケアが必要なため増席は厳しく・・・・。
「また開催しよう!」とグラフィックレコーディング勉強会スタッフ一同考え企画をはじめているので、またぜひご期待いただければと思います。

そんなわけで当日のレポート。
詳細はこちら

デザインの現場でUXデザインやるなら、まずユーザーテスト(=「評価する」)からはじめるといい理由

img_150626「UXデザインを会社のデザインの現場でやるにはどうすればいい?」
私自身、そんな疑問になんどもぶちあたりし、何度も何度も仲間と話し合ってきたこの問い。

『「調べる→企画する→解決策作成→評価する」って進めると失敗しやすくて。
「評価する→ 解決策作成&評価する → 企画する&解決策作成&評価する → 調べる&企画する&解決策作成&評価する」というような、人間中心設計のサイクル逆回転からスタートしていくのがいい!というのがよくいわれる答えだ。

img_hcdpimg

私はもともと「評価する(ユーザーテスト)」から全てをはじめて、意図せず逆回転を社内でまわしていったクチなのだけど。
最近自分の案件で「調べる→企画する→解決策作成→評価する」という順当な流れをやってみたところ、いろんな壁にあたるなーと感じることが多かった。
面白かったのは、逆回転からはじめた人ほど、順当な回転をまわすのがはやかったことだ。
「評価する」プロセスから逆回転をしていくのがなぜ大事か?というの、あらためて考えるきっかけになった。

「評価する」プロセスからはじめるといい理由

理由は以下。

  • 現場のUIデザインのプロセスにいれやすい
  • ユーザーテストからのユーザビリティの改善は、合意形成しやすいし&数字で効果を語りやすい
  • UXデザインに超大事な、観察する態度が身につく

現場のUIデザインのプロセスにいれやすい

既にリリースしているサービスに対して、さらにチューニングをしていくのはよくある話だ。
そのチューニングにあわせて、5人程度の(比較的ユーザー像に近い人をさそって)ざっとテストして課題を洗い出すというのは現場としてすごくやりやすい。
お金も時間もさほどかからないから。

えてしてUXデザインのプロセスで問題になるのがお金と時間だ。
調査にはお金も時間もかかる。現場で効果がみえるかどうかわからないところに「お金をください」というのは決済おりづらいし、ましてやプロジェクトにおいて十分な時間をさいてもらえることなんてなかなかない。

あるとしたら、UXデザインに相当な価値をおいている組織か、相当な社内信頼貯金を持っている人がいったときのみ。
まあえてしてそんな環境にはないので、現場でまずやれることとして、ユーザーテストって工数的に現実的なのかなーと思うのだ。
「自分たちでも現場でまずやってみようと思える」というのは、着手するのにすごく大事な要素だ。

ユーザーテストからのユーザビリティの改善は、合意形成しやすいし&数字で効果を語りやすい

そして二個目。
ユーザーテストに基づいたユーザビリティの改善は、チームの間でも施策立案しやすいし、改善した場合の期待効果も見えやすいと思う。

チームのメンバーがユーザーが実際に利用している状況を見ることで「こんな使われ方をしてるなんて!」という衝撃を受けることができる。
自分中心デザインでUIデザインを考えていた人であればあるほど、その衝撃はでかいんだけども。
「自分の考えたイケてるデザイン」に固執するのではなく、ユーザーの行動見ないとやばい、ということが肌で感じられるのだ。
百聞は一見にしかず。

また、ユーザーテストででてきた問題を効果・効率・満足度×発生頻度での課題整理し、ビジネス的なインパクト度合いや実現難易度で整理したら、やるべきことの優先順位はクリアに見えてくる。
その優先順位で実装すると、KPIの数字も上がることが非常に多い。
あてずっぽうでやるより上がる確率がぐっとあがるのだ。

こうして数字で成果を語ると、「UXデザイン(の一部のユーザーテスト)って効果あるんだね」「ユーザーを見ることって大事なんだね」というチーム内の空気が生まれる。
この効能感こそ、チームを動かす原動力になる。

UXデザインに超大事な、観察する態度が身につく

そして三個目。
ユーザーテストが産む効能として、もうひとつチームを動かす原動力になるのがあって。
それはユーザーを観察する態度だ。

ユーザーテストをしていると、観察者はユーザーの一挙一動、思考発話をつぶさに観察するようになる。
ユーザーがとった行動に対して、「なんでこのユーザーは、こんなことをしたんだろう?」「なんでこのユーザーは、ここでこんんなことを思ったんだろう?」という問いを抱くようになるのだ。
そして、そのなぜなぜを繰り返し、その粒度はどんどん細かくなる。

例えば、自分の会社の場合。
「ユーザーは、このホテルがいいと思って選んだ」という行動があったとする。

Q:このホテルをなぜいいと思ったか?
A:駅から近くて、部屋もきれいなのでコストパフォーマンスがいいと思った。
Q:『駅から近い』ってユーザーにとってどんなことを指す?『部屋がきれい』ってユーザーにとってどんなことを指す?
A:駅から近い=スーツケースをもって徒歩で移動できる範囲。つまり、坂道や人が多すぎる繁華街、治安が良くないところ、スーツケースをひけない石畳の道は、駅から近くてもちょっと選ぶのに気が引ける。部屋がきれいは、水回りとベッドに注目している。
Q:『水回りとベッドに注目』する理由は?
A:基本ショッピングやライブに出かけるしそっちにお金を使うので、ホテルはお風呂に入って寝る場所という位置づけ。カビが生えてないとかお湯がでるとか、最低限清潔に利用できればいい。ホテルにかける価格的な優先順位は低く、部屋が狭いとか、窓からの景色がシティービューなのは問題ない。
Q:『最低限清潔』を何でジャッジするか?
A:ホテルの部屋の写真。水まわりの写真は必ず確認する。
Q:なぜ写真がいいのか?
A:設備の有無のテキストだけだと、水回りのきれいさは絶対にわからない。
過去に安い宿で水回りが汚く、シャワーカーテンにカビがはえてたホテルにとまったことがあり、そんなホテルにはもう泊まりたくないという気持ちが強い。

「ホテルをいいと思う」という裏には、ユーザーの過去の経験が学びがたくさん詰まっている。
たいてい、皆一個目の質問「このホテルをなぜいいと思ったか?」はきけるんだけど。
「駅から近くて、部屋もきれいなのでコストパフォーマンスがいい」を掘れる人は少ないと思う。
多くの人は、駅から近い・部屋がきれいで思考停止してしまう。
その結果、駅から近い=近ければ近いほどいい?とか、部屋がきれい=ゴージャスな設備?とかかってなイメージをふくらませてしまうのだ。

ユーザーは「駅から近い」ホテルを選ぶのに、駅からのメートルを測らない。
地図上で駅とホテルの位置をざっと見た後、ホテルの住所や駅名、近くのショッピングセンター名で検索して、写真や文章を読み込み、その周辺の何かの情報を仕入れようとするのだ。
ユーザーテストでモデレーターをやってみると、こうしたユーザーの連続した行動をたくさん目にすることができる。
だから、ユーザーにとっての「駅から近い」が、具体的な距離ではないことに自ずと気がつける。

ユーザーテストは、利用中である一時的UXのさらにほんの一部のみ見る行為だ。
その一部のみでも相当深く、ユーザーの過去の経験に紐づいているというのを知ることで、「ユーザーの行動と思考は、自分の推測を超える」ということ、そして観察の重要さを身をもって学ぶことができるのだと思う。

———————–

この観察の力を持っている人が構造化シナリオ法でのアクティビティシナリオ(「もの」ではなく「コト」のシナリオ)を書くと。
最初はとまどっていたとしても、すごくチームメンバーの共感をよぶシナリオをかけるんだなーと最近気がついた。
その共感を呼びおこすものは、ストーリーの核をなす具体性の連続だ。
この具体性の連続からユーザーのコトにつなげて発見していける力をもつ人って、サービスをつくっていくのに強い力となるんじゃないかなと思う。

ちなみに、受託系デザイン制作会社の人と話すと、「プラグマティックペルソナ死んだ話」をすごくよくきく。
受託だとプラグマティックペルソナ立てる→ジャーニーマップを書く→シナリオ書く、って、クライアントとの合意形成のためという側面が非常に強いから。

プラグマティックペルソナは声が強い人にひっぱられやすいし、ジャーニーマップはご都合主義になりやすい。
シナリオは共感重視というより、「ユーザーがこの流れでこのモノに触るのがあるべき姿です」という、機能と機能を無理やりつなぐ何かにしかならない。

結果、ペルソナとシナリオが何も制作物に投影されない「ペルソナ作ってそれからどうするの?」状態に本当によくなるのだ。
私も受託制作会社で経験済み。
プラグマティックペルソナだって、ユーザーに近づけるよう育てていけばいいんだけど。継続して関わらないとプラグマティックペルソナを育てていくのって難しいのかな~と思う。

なにはともあれ。
UXデザインのプロセスぐるぐるがまわりはじめたとはいえ、ユーザーテストは継続して、チームでやっていく必要があるなと痛感。
特にUXデザインを学び始めた人の入り口としても、ユーザーテストはすごくいいきっかけになると思う。

Return Top