eVar7 Adobe Summit 2016報告会にいってきました。
このところずっとHCD(人間中心設計)のプロセスぐるぐるしていたため、マーケティング系の仕事はしていなく、Adobe系の解析ツールから離れて久しい状態でした。
ただ、今担当しているサービスでマーケティング系に類する仕事が自分の範疇に再び戻ってきそうな状況や、登壇者で話をききたいトークもあり。
「Adobeのマーケ系ツールのユーザーではないけどご容赦を・・・」とどきどきしながらAdobe Summit 2016報告会にいくことにきめました。
UXデザインの業務をはじめてはや5年。
自分自身も三十路超え、ついでに体重も肥え、文字通り『脂がのってきたかんじ』の状況ですが。
5年の中で、先輩方が体を壊したり、自分自身もあと数歩で体を壊すのでは？というところにいったことを、ふと@VoQn氏のツイートでおもいだしました。
(酔ってきたからいいかげんな事言う)「UIデザイナー」っていう「ロール」は充てちゃ駄目です。その子、全ロールの要求に頭がパンクするか、人材として潰れてしまうまでタスクが積まれて心療科通いになっちゃいます (続く
— ぼうくん (@VoQn) 2014年11月18日
※詳細 @transit_kix姉さんがまとめてくれている「酔ったぼうくん氏語る「ポジションに据える形での“UIデザイナー”というセクショニングの危険性」
「フルスタックデザイナーになろう！デザイナーもコードをかくのが当然」「デザイナーもUXデザインで上流工程へ」「webディレクター不要論」「いやディレクターこそUXデザインでグラフィックデザインできるように」とか、いろんな要望がデザインの現場でとびかう今。
その言葉の強さと、潜む怖さを感じ、じゃあデザインの現場にいる人間としてどうしていくのがいいのかなと思い、つらつら文章をかくことにしました。
【前編】グローバル化するサービスとオフショア開発環境の中で、webディレクターができること ～現場の悩み編～の続き。
「旅行ECとして機能必須要件すりあわせに時間や工数かけてるけど。もっとユーザー目線で考える時間や工数増やして、ユーザビリティ・売上あげたい、チームで事業貢献したい！webディレクターとして、今私はどうすればいいんだろう？」という問いに対して。
ベトナム出張でであった人々・出来事から得たヒントを書いていきます。
2016年年明けから、自分の仕事が大きく変わりました。
これまで対日本人への旅行ECサービス担当だったのが、外国人向けの旅行ECサービス担当となったのです。
また、関わるエンジニアや事業部のメンバーも日本人ではない人たちが増えました。
年明けから数か月、「グローバル化するサービスとオフショア開発環境の中で、webディレクターができることってなんなんだろう？」と模索をする中で、少しずつ見えてきたものがあったので記録にのこしておこうと思います。
まずは前編、グローバル化する開発環境とサービスの中でwebディレクターが悩んできたこと編。
webディレクターが人間中心設計（HCD)専門家認定制度うけてみた話という話をかいてその後。
3月末、無事に人間中心設計専門家に合格しました。
そののち5/8(日)の情報デザインフォーラムにでかけて『うああああ世界広いよー』となったのが現在、です。
webディレクターが人間中心設計を学び始めた理由、学んで専門家とったのちに『うあああああ』考えるに至った軌跡を記録しておこうと思います。
UX界隈の勉強をはじめたときは。
・なんか学術的なことやってそうな人たちで壁高そう
・資格？何をやっている人たちなんだ
・事業会社のドロドロの中で資格が活きるように思わない
と思っており、まさか自分がこの資格をとるとは思っていませんでした。
人間中心設計を学び始めたのは、「『定量』『定性』両方の軸がないと、サービスのデザインを考えられないわ」と痛感したからです。
もともと私はweb制作会社のディレクターで、「もっと上流から考えられるようになりたい！」と事業会社に転職したクチだったのですが。
ある程度定量的にログ解析ができるようにはなったものの、それでも旅行会社において『上流』を考えるためには、大きな壁があったように思います。
・ユーザーのインサイト、旅行業のお金の稼ぎ方を一番知っているとされるのが、旅行会社の旅行事業のメンバーであること
・オンライン旅行会社のデータは外接ものが中心で、そのデータやシステムに基づいたUIが求められること
旅行会社にはいってまずびっくりしたのは、ユーザーのニーズの細かさ、多様さでした。
1月にGWの商品を予約しようとする人はあたりまえだし、ヨーロッパに行く際「直行便に近い経由便」なるものがあること（超効率的な乗り継ぎできるFinairとか、アエロフロートとか）。燃油サーチャージの上下するタイミングで、「燃油代がお得」という視点で航空券を探すユーザーがいるということ。
web業界にいた身としては、その多様なニーズはとても興味深く、販促にかかわるたびにワクワクしっぱなしでした。
ただ、しばらくすると。
ユーザーのニーズをいつも旅行業の人にきいているという状態になっていました。
ユーザーのインサイトを見つけるという広告の本を読んだけど、なんかぴんとこないのです。
また、旅行業のお金の稼ぎ方も全くしらない状態でした。
旅行業は商習慣があり、事業を成立させるためのお金の流れも存在します。
ただ数をうればいいというものではなく、キックバックやコミッションを最大化するための施策もあります。
会社の事業が何に基づいて動いているのかが見えない中、デザインの文脈でのみ発言して、顰蹙をかうことも多々ありました。
サービスを運営するということは、デザインの美しさや保守性の文脈だけで語れる分野ではありませんでした。
求められたものをつくれば喜んでもらえる。
そう思っていたところ、29才くらいのとき、マーケティング畑の上司から厳しい言葉をいわれました。
「システムを理解しろ。理解してはじめて、どうすればいいのかエンジニアと一緒に話すことができる」
そうはいってもECサイトの設計経験もあったので相応の自信はあったのですが。
いざ開発現場にたってみると、システムとの打ち合わせで自分がいかに役にたたないかを痛感する日々でした。
オンライン旅行会社のデータは外接ものが中心で、その中でどう最適なUIをつくるのか？という議論が中心になります。
「こういうことをやりたい」といっても、「このデータはないから作る必要があるけど、本当にそれっているの？どうやるとそれってできる？」といわれると、言葉につまるのです。
本当にそれがいるのか？というのは自分の思い付きのアイディアでしかないし、ましてやそれがどうやってできるのかというプロセス一緒に話すには弱い。
「工数かかるよ」といわれると、自分の意見をひっこめてしまう日々が続きました。
デザインが事業を前に進める力になると思うからこそ。
自分のひとりよがりアイディアなんてどーでもよくって、定量的な数字・定性的な行動や感情を論拠としたものから発想したかった。
そして、「今、こういうデザインが必要なんです。工数かける価値があるんです。これが事業を前に進めるんです」って心の底から信じていいたかったのだと思います。
これは株式会社パエリアの山口隆広さんの定義が、webディレクターとしての現場ではものすごーーーーくしっくりきています。
リリースまで走り倒せないとダメな役割 is 専門家
HCD専門家に求められる実務的なスキルセットを抜き出すと下記のとおりです。・現状のユーザ課題を具体的に推測する
・調査計画を立てる
・定性、定量調査を行い、その結果を分析する
・その結果を受けて仮説からユーザを幾つかモデル化する
・モデル化したユーザに対してどのような機能、経験をさせるべきかを実現可能性を含め提案する
・提案した内容をもとにユーザーシナリオやコンセプトにまとめる
・まとめた内容をもとに企画提案を行い、要求仕様をまとめる
・必要に応じて情報設計を行い、デザインを作成する（自分で作らなくともグラフィックデザイナーをディレクションする能力でOK）
・作成した結果をもとにプロトタイピングを行い、ユーザ調査、仮説検証を行う（中略）
すなわち、開発現場に対し正論を振りかざす人というよりは、実際に開発現場でディレクター的な役割を持ち、一緒にサービスを作る人というのが役割となります。こう考えると、いわゆる開発現場のディレクターがやっていることに対しユーザ調査とフィードバックを加えたことが、HCD専門家に近いように思います。あれ、全然めんどくさい人じゃなかった。
開発現場に5年間立ち続けて、勉強会に通い、本を読んで、産業技術大学院大学人間中心設計履修証明プログラムに通って、ようやく『リリースまで走り倒せないとダメな役割』がこなせるようになってきたように思います。
中でも、『リリースまで走り倒せないとダメな役割』をするのに大事だなと痛烈に感じるようになったのが、ファシリテーション能力でした。
プロジェクトを継続してつづけていくには、旅行業のメンバー、エンジニア、デザイナー、ユーザー、国籍の違うメンバーと一緒にものづくりをしていくことが必要というのもあるのですが。
それ以上に、つくりつづけるプロセスそのものも、デザインしていく必要があると感じたのです。
この点、大きく影響をうけているのは、上平先生のブログ『子供と一緒にデザインする方法』からです。
・物理的に距離が近いというのは、協業において（あたりまえだけど）とても大きい。
・子供のアイデアはそのままつかえるわけではなく、そのイメージを具体化・精緻化するのはプロのデザイナーの仕事。大人にはない発想を取り入れるために計画的に巻き込んでいる。
・見せかけや口実つくりの市民参画、ワークショップではなく、そもそものところでたとえ子供であっても対等に対話し、尊重する社会理念がベースにある。先日、Rasmusは「我々は実際に使う彼らの気持ちを何も知らない、逆に教えてもらうという気持ちだよ」と言っていたな。この辺の民度（？）を決定づけているものとして、デンマークの社会民主主義の歴史は半端なく厚い。
・そして民主的とはいっても、決して多数決ではなく、折衷案でもなく、決めるところはピシッとプロが決めている。つまり役割分担がうまい。
子供と一緒にデザインする方法
Kamihira_log in Copenhagen
私レベルの情報設計できる人なんていくらでもいるし、グラフィックのデザインもできるかっていうとNOです。私自身、ものすごくかっこいいとか美的で評価されるデザインをつくりたいかっていうとNO。広告賞とかどうでもいい。
それより、継続的に使われるものをつくりたいし、プロジェクト立ち上げからリリース、評価して運用していくすべての流れにおいて、みんなで作る瞬間にわくわくしていたい。
そんなわくわくした前向きな場をたくさん作れるようになりたい。
そこに必要なものって、場をつくる力＝ファシリテーション能力でした。
上平先生の「デモクラティックデザインとその実験精神—もうひとつの北欧デザインから学んだこと—」の話をうかがいたくて、情報デザインフォーラムに参加してきました。
基調講演、パネルディスカッションを通じて、特におもしろかったのが、以下のトピック。
・デンマークで持続性あるけどリスクもあるサービスをだせる背景＝信頼がある。その信頼があるのは「そういう風に育てられたから」
・高度成長が過ぎ、成熟産業が時につぶれていく現在の社会。社会全体の目標が見失いがちな中、一人一人が社会へ関わり何を達成したいかを考えていく必要がある。そのとき、デザインという手法は皆の大きな力となる。
・多様性・不確実性・複雑性をうけいれてイノベーションへのプロセスをつくれる人が求められている。
この『多様性・不確実性・複雑性をうけいれてイノベーションへのプロセスをつくれる人』＝カオスパイロットでのチームリーダーとのこと。
たぶん私がなりたいのってこの立ち位置。
でも、ものすごーーーーーーーーーーーく、遠いよーーーーーーーーーーーーーーー。
今もってる現場だってまだまだ小さいもの。。
人間中心設計専門家とって、少しは先達の先生方の見ている世界を見れるかな？と思ったら。
とんでもない。世界は恐ろしいほど広かった。
たとえるなら、カイの冒険でフロア60まで到達したのち、スペシャルステージが表れていきなりわけわからん難易度になってるかんじ。
※画像は「アナタはGWは何をしていましたか！？僕は「カイの冒険」を攻略 ②」より引用。カイの冒険の鬼畜ぷりがわかる素晴らしいエントリーだと思います。
ここからが本番なんですよね。
人間中心設計専門家をとったのははじまりにすぎなくて。
今度は自分の今までの現場のみならず、いろいろな場でどんどん試していけということかなと。
人間中心設計を学び、人間中心設計専門家の資格をとるなかで、いろいろな先達にお会いすることができたのはとても幸せなことだと思います。
んまた、そこからすごく多くの素敵なチャレンジをしている人たちを紹介いただいているなと感じます。
めっちゃうちひしがれてるけど、小さくても、新たな場をどんどん作っていきたい。
情報デザインフォーラムから、これから成田にいきます。参加型デザインとなる社会って理想なんだけど、いち市民からみると遠すぎる道のりにみえて「自分じゃできないよー」と思ってしまう。うちひしがれる。でも、そこ一個ずつのぼるのが必要で、あとからみたら転換点だったみたいな場なきがする。
— azumi (@azumi0812) 2016年5月8日
今私はグローバル展開したサイトの担当をしているのですが。
お前どうこう言う前に、まず英語でコミュニケーションとれないとベトナム人エンジニアたちや、ユーザーと話せないだろ、『リリースまで走り倒せないとダメな役割』できないだろ、という状況。
切羽つまってるんですよ。あーあーあーお恥ずかしい。
まずは出張で明日からベトナムに渡航なので。
『多様性・不確実性・複雑性』をたくさん集めてくるところからはじめてみようと思います。
いかないと見えないものがある。
見えないものをみにいこう。
ようやく念願かなって。
東京大学大学院 安斎先生が企画されているワークショップ『dialogue to diagram：対話を図解する手法を学ぶ』に参加してきました。
ゲストは東海大学講師の富田先生。
今回参加したのは「学問の世界にいる人たちから見えるワークショップと、可視化の世界を見てみたかった」という理由からでした。
UXデザインの世界から入り、ワークショップデザインをするようになってから、『どんな問を場にだすと、みんんなと新しい世界にいけるんだろう？』『この場で何がおきているんだろう？』という問いを常に考えるようになりました。
しかし、『この場で何がおきているんだろう？』については瞬時につかむのが私は苦手。感覚的にまだ体に入り切ってないなーと考えています。
たとえるなら自転車で補助輪つけたりはずしたりして、ふらふら走ってる状態。走れるけど、危なっかしい。
こういう時に私は違う視点をあえてぶっこむのが好きです。
その道の先達について実務を見たり、研究や書籍を読み、自分の中に新たな問いを発生させるのです。
問いのもやもやを考え続けて、外化しつづけて、前に進むスタイル。
今回は学問の世界にいるお二人の話を伺って、そのワークショップの場に参加することで、自分をゆさぶってみようかなーと思ったのでした。
「カンファレンスでのグラフィックレコーディングの果たす役割ってなんだろう？」と昨年からずっともやもやしていました。
イベントでグラフィックレコーディングを描くと、喜ばれる。写真をとられる。
その場は盛り上がって、なんか嬉しい。
でも、そのあとってどうなるんだろう？
また、カンファレンス等で描く場所が増えれば増えるほど、「なんでグラフィックレコーディングなの？」「絵の議事録でしょ、それよりちゃんとした文章がほしいと自分は思う」という話をよくきくようになりました。
今回は、CIVIC TECH FORUM 2016のグラレコ隊として、イベントにかかわる中で「カンファレンスでのグラフィックレコーディングの果たす役割ってなんだろう？」について考え続けました。
「グラフィックレコーディングって、絵の議事録でしょ？」
「イベントで最近よくみるけど、結局写真とって終わりで、あまり意味なくない？」
グラフィックレコーディングを描いている話をすると、時々そんな質問をうけることがあります。
同時にグラフィックレコーダーからも「イベントで描いてその時は喜んでもらえたんだけど・・・結局かきっぱなしになっちゃってる気がする。」という声もきくこともあり。
グラフィックレコーディングが注目をあびればあびるほど、コミュニケーションのいち手段であるという側面が見えづらくなり、パフォーマンス面が目立つようにここ最近感じます。
グラフィックレコーディングは、コミュニケーションのためのいち手段。
グラフィックレコーダーは、『場』をつくる一員。
では、グラフィックレコーダーは、どんなコミュニケーションを目的に、どのように『場』をつくるといいんだろう？
そんな問いのもと。
ここ最近、依頼をうけた案件については、極力『場』をつくる一員として、企画や進行に提案を行うようにしています。
Code for Nagareyama IODD2016「SNSといじめを考えるワークショップ」にて、ひとついい形をうみだせたなーと思うので、事例紹介として記録にのこしておきたいと思います。
webディレクターやってはや10年。
サービス開発の現場に立ってUIとかUXとか考え続け、気付けば5年。
一つの区切りとして「なんかやったぞ」感をのこしたく、人間中心設計（HCD)専門家認定制度をうけてみました。
受験申込書をだしたあと、12/26～台湾に旅行⇒年末夫の実家にいき、そのまま年始まで帰宅しないという生活をしていました。
当然申請書類は一切手をつけず。
1/1に帰宅して、「年始だしやるか！」という謎の年始の勢いにかられる中。
このスライドみて脱力しました。
無理ですからぁってアンタ。
・・・そして書き始めて、「無理ですからぁ」をかみしめました。
人間中心設計（HCD)専門家の書類のうち、特にボリュームが多く大変なのが、B3『B-3 コンピタンス記述書（専門家資格受験者）』。
大量のexcelのセルをみて、まず愕然。
そして、上から順番にうめていくのですが。
『B1 プロジェクト企画能力』をかいて、さあ次は『B2. チーム運営能力』『B3. プロジェクト調整・推進能力』だ！と思って項目をみると。
・・・・あれ、B1で書いたことと同じことかいてない？
同じことが、Aの12個のHCD基本コンピタンスにもいえます。
「とりあえず何も考えず書こう、あとからいらん部分は消そう」と思い定め、かきたいことをあっちゃこっちゃに書き散らした結果。
私の年始の休みはすぐに終わり(たぶん8時間くらいは使った)、1案件（しかもユーザーテスト企画実施というだけの、一番軽いはずの案件）しかかけない状態となっていました。
どう考えても書きなおししないといけないクオリティ。
この状態で締め切り前一週間前だったら、絶対先のボリューム想定して絶望して出願諦めていたと思います。
ああ。これが「無理ですからぁ」なのね・・・・
年始に会社にいって、コンピタンスを印刷して眺めてると。
ふとどこに何をかくべきかが見えてきた瞬間がありました。
「ああ、これHCDの各サイクルの部分を集中して書けばいいのか。」
↑言葉でいうのは簡単だけど、感覚としては伝わりづらいので。
ここを今回言語化してみようと思いブログをかきました。
私はこのコンピタンス記述書を書く大変さを、「正しい料理方法を知った上で、家庭で毎日のごはんをつくれるようになったことを文章をかいて証明する」という風に感じています。
例えば、『だしをとる』という過程。
・だしが必要な理由：うまみのもとになるから。特にグルタミン酸イノシン酸を組み合わせると人間はうまみを感じやすい。過剰な油脂や糖に頼らなくてもおいしさを感じることができる。
・だしのとり方：冷たい水にこんぶをつけて、ふっとう直前になったらかつぶしをくわえて、そのあと濾して冷蔵庫で保管。
でーもーねー。
一般家庭で毎日毎日だしをとるって大変です。
そんなときに、『B-3 コンピタンス記述書』風にかくとこうなるのかなと思います。
・でも、おいしくて健康的なものを食べたい。夫の健康診断の結果も気になる。
・塩分をとりすぎないように、だしをしっかりとりたいと思う。
なぜその方法を選び、どのように企画設計したか？工夫したことは何か。
・うまみ成分をいれて、過剰な塩分をとりすぎないようコントロールすることが味噌汁の調理には求められる。
・だしはパルシステムの顆粒だしを利用することにした。パスシステムの顆粒だしは、化学調味料の強い味がせず、味わいがやさしく自然なだしの味に近しいため。また、ふりかけていれるだけのため、だしをとる時間を圧縮することができる。
・また、パルシステムの顆粒だしは1本で味噌汁4杯分つくれる仕様となっており、1回につき半分を使えばいいため、利用量がわかりやすい。塩分とりすぎを自然と防ぐことができる。
・水300mlに顆粒だしと、うすめの半月切りにした大根をいれて、大根に火が通るまで沸騰直前の状態で火を通した。大根に火がとおったら、油揚げを入れ、味噌をいれ、放置し他の炒め物料理を作成。この放置時間でさますことで、食材に味がしみることがねらいである。また、炒め物は先に作ると放置できず水分がでてくるので、煮物の工程を終えてから調理を実行することとする。
・炒め物料理を食卓にだした後、再び火を入れて味噌汁をあたためる。このとき、ふっとうすると味噌本来の風味がとんでしまうので、沸騰させないように気をつける。
・味噌汁をお椀にもる。このとき、大根の葉をきざんでのせる。彩りよく見えるようにするためと、栄養価をあげるためである。大根の葉は緑黄色野菜に分類され、βカロテンやビタミンを多く含んでいる。
どうでしょう？
「大根とあぶらあげの味噌汁をつくる」という味噌汁をつくるという行動すら、長くなるので書くのがすごく大変なのです。
また、背景情報は自分にとってあたりまえの情報で。
このあたりまえの状況を客観視して、手法をえらんでいくということ自体、けっこうやれてない部分なのかんとかんじました。
（例：お母さんがいつも顆粒出しいれてたから、私もなんとなく顆粒だしつかうもんだと思ってた状態）
トータルとしては、各コンピタンス、脳内でこんな変換をしてみると、直感的に理解できるのかなーと感じています。
B：毎日の台所をつかさどる力
・B1 今の家庭に必要な毎日のごはんを考える力
・B2 手伝いする家族をまきこむ力
・B3 現状の家庭状況にあわせて料理をする環境をつくる力
C:自分の家や親戚の家庭に料理プロセスを教えていく力
※料理プロセス⇒家族を見る・何が必要か考えて外化・献立つくって料理・評価する
・C1 どうすれば自分の家族や親せきの家に料理の一連プロセスを伝えていけるか考える力
・C2 自分の家族や親せきに、料理のプロセスを伝える力
・C3 自分の家族や親せきが料理のプロセスをできるようにそだてる力
・C4 自分の家族や親せきが料理のプロセスをできるようにそだつため、教える手法を考える力
L：ひとと一緒に料理をつくっていく時のテクニック
・L1 人と一緒に料理をしていく際、献立や料理をうまく文書で伝える力
・L2 人と一緒に料理をしていく際、献立や料理がすてきなおいしそうなものと感じられるようみせて伝える力
・L3 人と一緒に料理をしていくために、家族や親せきをうまくまきこんでいく力
大事なのは、
・自分のおかれた背景状況を客観的に理解すること
・その状況にあわせて、基本をしったうえで、適切な目的設定をし、適切なタイミングで、適切な効果を得られる手法をくみあわせること
・手法にたいしての評価を行い、次につなげること
だと思います。
知識を多くもった人とか、手法をたくさん知っているひとが専門家なのではなく。
この状況把握および適切な手をうちつづけられる人が、人間中心設計専門家なのかなと感じています。
この感覚を得た時『B-3 コンピタンス記述書』がとてもかきやすくなりました。
まあそれでも大変だったんですけどね・・・・。たぶん60時間くらいトータルでかけてると思います！
「UX学んだから、手法たくさんしってるんだよね、知識がたくさんあるんだよね」
産業技術大学院大学にいって、人間中心設計を学んだとき、会社でそういってくる人がいました。
違うんです。
知識量とか手法できる人じゃなく、現場で活かして事業を前にすすめてこその力なんですと。
私のもってる現場は、別にそうひろい台所ではないし、最先端のイケてる調理器具とか最先端の調理人がいるところではないと思います。
私自身、じゃあ最先端のスキルもった料理人かっていうと、絶対NO。
でも、ものをつくるときに、つくって誰かにみせて、こわして、またつくって…というプロセスはそれなりにまわせるようになったんじゃないかなあと思うのです。
まだまだ修行中ではあるけれど。
専門家とれるかとれないかはわかりませんが、書いたことでなんかすっきり、次へいける感がしてきました。
そんなことおもいつつ。
今日は夫も長期出張でおらず、自分ひとりのため、大鍋に牛肉1kg+筋肉いれて、大量の牛筋にこみをつくってしまいました。
しかも1品だけ。
大根人参つっこんでるけど、栄養かたよりまくりです。料理プロセス設計能力ゼロ。
すごいうまいんだけど、誰がたべるんだろうなあこれ。
2/13(土)Devlove関西さんからご招待いただき、大阪で『グラフィックレコーディング～構造化のコツ～』というワークショップを実施しました。
今回はグラフィックレコーディング3つのスキル「聴きとる」「表現する」「構造化する」の中でも、構造化に重点を置いたワークです。
私自身、会社でグラフィックレコーディングを用いるか？というと実はあまり使ってなく（アクティビティシナリオやストーリーボード考えるときに使うくらい？）、グラフィックレコーディングのスキルを活かして現場で動いている、という状態です。
特によく使ってるなと思うのが「構造化する」という部分。
会議の内容をリアルタイムで関係性を示し、それをもとに考え、進行するという「構造化」。
「構造化には、いったい何がコツとして必要なんだろう？」
そう考えたく、ワークショップを設計しました。
私自身、ワークショップをやって見えたこと、感想戦をやってようやく見えたこと、それぞれあったので記録に残しておこうと思います。
この記事は 家庭を支える技術 Advent Calendar 2015 – Adventar 12/20の記事です。
テーマは「不妊治療」。
自分一人の問題ではないこと、また知り合いが読むことも十分に想定されるので、書くことに抵抗がないわけではないですが。
自分の気持ちの整理の言語化に加え、少しずつ知見が高まってきたこと、あとこの問題に取り組んでることについては（ある程度までは）周囲に「えいやー！」と公開してしまったほうがラクだなあと思ったので、えいや！で書いてしまうことにしました。
この記事は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デザインが根付いてくるということではないでしょうか。
この記事はファシリテーター Advent Calendar 2015 6日目の記事です。
高柳さんからのお声掛けいただき、執筆することにしました。
お恥ずかしながら、体調不良により、1日おくれでの投稿です。
2015年は、ファシリテーションに向き合う年でした。
私がファシリテーションに出会ったのは2004年頃。
A SEED JAPANという環境NGOで会議の進め方研修として学んだのがきっかけでした。
会議を時間内に、目的どおり、実りある議論にするためのもの。
横道にそれないよう、うまく導くもの。
それが私にとってのファシリテーションだったのですが。
今年、その認識ががらっとかわりました。
『自分が導く』ではなく『参加者の思いが溢れだす』へ。
『ひとりで』ではなく『バディといっしょに』へ。
11月9日（月）、フェリス女学院大学『社会的起業』(春木良且教授)の授業で、グラフィックレコーディングのワークショップを実施してきました！
一緒にワークショップ設計＆授業をしたのは、グラフィックレコーディング勉強会メンバーのファシリテーター西田武史さん、グラフィックレコーダー増山和秀さん。
この『社会的起業』の授業は、PBL（Project-Based Learning 課題解決型学習）という形式をとっています。
大学外部の方から社会的な課題を共有いただき、社会的な課題を考えていく中で学びあうそう。
グループで社会的課題を考えるにあたり基本となるのが、思考する力、発散収束する力、異なる立場の人に伝える力です。
春木先生からご依頼いただき話を伺う中で。
「どうやったら、グラフィックレコーディングを通じて、情報を『見える化』するの大事さ・手法を学べるのか？学生みなさんが社会に対してアクションしていく一助になれるのか？」という問いをずっと考え続けました。
産業技術大学院大学、人間中心デザイン履修証明プログラムの復習レポ第10弾「発想ファシリテーション論」です。
去年発想ファシリテーション論の授業振り返りブログを書きましたが。
今年はブログに加え、グラフィックレデコーディングも描いています。
去年学んだ内容を、再解釈もぐもぐした結果。
全く別の味わいになってたことに気が付きました。
↓グラフィックレコーディングはこちら
詳細はこちら
11/7(土)11/8(日)、Code for Japan Summit 2015でグラフィックレコーディングやってきました！
全国のcode for xから関係者がサミットにあつまる中。
総勢16名のグラフィックレコーダーも、首都圏近辺、静岡、岐阜から集結しました！
産業技術大学院大学、人間中心デザイン履修証明プログラムの復習レポ第9弾「UX方法論」です。
わたくし2014年度で履修証明をしっかり修了しましたが。
2015年度授業にも卒業生としてお邪魔して、復習グラフィックレコーディングをしてきました。
（浅野先生、押しかけグラレコ受け入れてくださりありがとうございました！）
ノートの取り方が話題になっている。
勉強ができる人とできない人の、ノートの取り方における決定的な違いについて
多分勉強ができていた私は、具体的にどうやってノートを書いていたか
このあたり読んだ。で、思ったこと。
・勉強できる人＝ノートの情報編集をやってる人ではなかった気がする。
感覚値でしかないんだけど。偏差値60台までは美しくノートをとっている人は多かったけど、東大にいくレベルで偏差値70台以上の人はノートぽいものとってなくてもできていた。
ひとつの何かから一気に記憶する力、思考していく能力ともに相当高い『できる人』。
・『不倒城』の人は、まさに『できる人』のように思う。
こういう人はひとつの何かから一気に色々正しく思い出せるから、「明日の自分は今日の自分とつながっている」と信じられてるのではないか。
・逆に私は「明日の自分は全くの赤の他人。」
100言われるとと明日には99忘れる。内部記憶メモリが10年以上前のPC状態。
すがすがしいほどの残念ぷり。
だから何かを心から学びたいと思ったら、内部記憶メモリがない以上、明日の自分＝他人にむけたものを残しておく（外付けハードディスク）の存在が必須だったのだ。
明日の自分＝他人にむけたもの＝情報編集をしっかりやったものを残す。
それが私にとってのノートの存在。
最近、人生の目指す方向が、がらっと変わった。
「伝えるものづくり」じゃない、「溢れだすものづくり」へ。
生きることはつくることに他ならない。
「ああ、これからずっともっと創れるなあ」て気づけたのが、今はただただ有難いなと思う。
ディレクターやって10年。
昔はワイヤーフレーム作って煮詰まっていつまでたってもできない、という状況になっていたんだけど。
ようやくどうやったら自分がワイヤーフレームを書く時、どうやったら限られた時間内で品質をあげられるかが見えてきました。
これはあくまで自分だけの話なので恐縮ですが、限られた時間を自分がどう使えばワイヤーフレームの品質をあげられるのかをざーっと書きだしてみました。
他の人の工夫もぜひきいてみたいところです。