HCD-Net Forum 2015に行ってきた話。~~ 1日目 ~~
に行った話をしよう。
HCD-Net Forum 2015に行ってきた話。
僕が、HCD-Netに行こうと思ったのが、HCD-Netがある週の、火曜日の事であった。UX Fukuokaで読書回を最近やっているのであるが、その時、HCD Netの話題になったので、サイトを見て行きたくなった。それで、なぜか「行きます!」と宣言したので、その当日の深夜に、東京行きのLCCのチケットを予約してしまった。
当日の午前、スカイマークの、11時50分、羽田着の便に乗り、東京へ到着。そのまま、地下鉄に乗り、泉岳寺の駅に降りる。前日に会場が「東海大学高輪キャンパス」という場所だったので、東海大学のHPを調べて、「泉岳寺(せんがくじ)」を知った。
しかし、東京の地下鉄はヤバい。
んで、そこから、高輪(たかなわ)キャンパスまで、歩き。道中で、お寺や、階段があったりした。
んで、なんか丘?なのか山?があるのが分からんが、とりあえず坂を登って、東海大学へ。
いや、こっちじゃなかった。こっち。
んで、到着ー。
キター!!!!!
ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!
若干時間に余裕があったので、書籍展示を見る。お馴染の書籍たち。
あと、HCDの本。
あと、こんな感じ。
だいたい持ってた。持ってないのもあるけど。CMである。
基調講演
さて、基調講演である。
黒須先生「HCD-Netのこれまでとこれから」
まずは、黒須先生。「HCD-Netのこれまでとこれから」。なかなか、HCD-Netについてのお話し。ほぇーってなった。あと、最後の方で、「いろんな領域がある。だけど、ユーザ視点を忘れるな。ビジネス視点は重要だが、売上重視に走るな。都合の良いユーザ像を作るな。長期的UXを考えろ。」という感じのことを言うてた感じ。ほぇー。
森川 亮氏( (株)LINE元代表。 今は、(株)C-Channelの代表)
講演があって、途中、会場とのディスカッションがあった。当時のtw/fbの分析から、LINEの創業の経緯やらの話があった。そんで、LINEのマネジメント。ユーザの事より、その組織内部のお話な感じ。日本は、「計画」を変えることに倫理的な抵抗があるとか、野球型組織とサッカー型組織やら、そういうお話。あと、C-Channelの話。縦長と横長のディスプレイの話は面白かった。
「お客さんに求められるプロダクトを作れなくなったら死ぬので、ユーザの事を考えようよ。」
と言う感じのこと言ってたので、なかなか印象に残った。
基調パネルディスカッション1 : 「これからのHCD/UX、デザインとイノベーション」
なんか、時間が無かったので、ディスカッションは無かったのだが、面白かった。
隈元障次氏( (株)Side4D 代表) 「情報の視覚化デザイン」
データビジュアライゼーションの会社。すげぇー。会場の人が写真取りまくってた。サッカーの情報の視覚化や、野球選手の情報の視覚化がやっぱり印象的。すげぇー。キラキラしてう。「一般人の人が革新的だと感じる」とかそんなこと言ってたような。とにかく、最後の方、良く分からないこと言ってたような。(うる覚え。)
渡邊 恵太氏 ( 明治大学総合数理学部 専任講師 ) 「融けるデザイン」
インターフェースのお話し。マウスカーソルがどうして、「自分で動かしている」と感じるのか?から、自己帰属感の説明。それから、IoTで、インターネットのインターフェースを作る話し。なかなか、面白かった。「インターネットって不便じゃね?」みたいなこと言うてたのが、面白かった。
基調パネルディスカッション2 「これからのHCD/UX: サービスとイノベーション」
若干、ハイレベルな感じがした。
持丸正明氏 (産業技術創業研究所サービス工学研究センター センター長)「 ISO国際標準 : Human Centered Organisation 」
Human Centered Organisationの話。EQUID(Ergonomic Quality in Design)の話。Ergonomicのことは良く分からん。ただ、Humanが、Userだけで無いってことが分かった。すげぇ概念が広がった感。HCDの領域跨がり過ぎてるだろ。あと、スライド英語が多かった。
武山正直 氏 (慶應義塾大学経済学部教授) 「サービスデザインのこれから」
サービスデザインのこれからの話。プロダクトの概念が変わって来ているとか。グッズ(有形)からサービス(無形)の変化。体験価値で差別化しろとか。あと、サービスエンタグルメントの論文が面白いらしい。こんど読む。IoTでサービスデザインやると、サービス同士の連携を考えるということらしい。IoTバズってる。
竹部陽司 氏 ( (株)リクルートテクノロジーの人 )「UXDの職能要件、とキャリアパス」
リクルートテクノロジーのUXDについてと、そのUXDの人材についての話。UXDって一杯あるけど、全部できる奴はいない ー> なので、ちゃんと、キャリアを考えて、職種を決めつけるのでは無く、職能を選択して、変化に対応しよう!。みたいな話。すごい進んでるなーって感じがした。
ディスカッション
ファリリテーターは、長谷川敦氏。いろいろと面白かった。HCDを組織に適用するとき2つの解釈があって、HCDができる組織になることと、内部の人間にHCDをする事があるようなんだな。
あと、写真が気になりまくった。
懇親会
懇親会があった。浅野先生から、「福岡でやってきた事一辺に学べたでしょう?」とか言われた。その通りだと思った。なんか、スッキリした感じ。UX Tokyoの人や、日立の人、ソニーの人、DMMの人とか、HCDを組織に導入して行こうとする会社の話とか聞けて良かった。みんな苦労してるなぁ。
地震
その日は、とりあえず、上野のカプセルホテルを予約してたのだが、地震で新橋のカプセルホテルに泊まった。
地震で、品川のホームに居た。電車動かないので、一端改札を出ようとしたけど、めっちょ並んでう。
とりあえず、立ち食い蕎麦でも食べて、時間を潰した。
店員のおっちゃんが、地震に気づいてなかた。図太い。「地震があったの? はぁ、ダシが揺れてると思ったけど。」
なんだかんだ、上野まで、行く電車に乗って、なんとか新橋まで行ったのだが、満員電車に負けて、新橋のカプセルホテルへ。満員電車、嫌い。
なんか、いろんな意味で疲れたので、その日は結構眠れた。
-> 2日目に続く。
UX Fukuoka インタビュー研究会 Vol.14
ひさしぶりにやった。
今回はGroovenautsのコミュニティスペースをお借りしてやりました。
UX Fukuoka インタビュー研究会 Vol.14
今日は、メンバーとしては、主要メンバー3名、良く来る見学者1名でやりました。途中から、参加メンバー1名増えました。
最初に前回のまとめ、と今回やることを書いた。
とりあえず、今日、ホワイトボードが嫌いになった。とりあえず、字がきたないのはホワイトボードのせいです。プロッキーでホワイトボードに文字を書いたりしてしまったりとか起るのは、ホワイトボードのせいです。
さて、今日は、前回、だいぶ前にやったのを見ながら、画面遷移を作成していきました。とりあえず、前回のUXフローがみんなバラバラに書いたので、それを統合しながら、画面を整理していきました。
まず、バラバラのシナリオでやっていたので、重複があったり、足りないところがあったりして、纏めたり、足したりしたりしました。
ある程度、まとまって来たところで、途中参加のメンバーがやってきて、とりあえず、簡易的にウォークスルー的な、評価をしてもらった。
そうすると、いろいろ知らないうちに、途中のシナリオで、変に機能を追加したりしていたりするがあったりすることに気づいた。ベテランとかによくあるらしいのですが、変に気を使ってはいけないんだなと思いました。
また、自然とやってしまうところもあるので、レビューや振り替えり、知らない人を入れたりというのは大事だなと思いました。
次回
次回は、ストーリボードと完成させるところまでが目標かな。
そろそろ、区切りまで近づいた!!!
「にも通じる」「同様の事が言える」とじゃなくて、違いを探そう
さて、今日も頭で考えたことを外に出していく。
つらつら書いていく。
「にも通じる」「同様の事が言える」とじゃなくて、違いを探そう
自分の事を話したいだけじゃないか?
いろんな人が、いろんな事を言っていて、僕も何か言いたいこと、聞きたいことを書いたり、読んだりしているのだが、以前から、「それって、○○でも同じ事が言えてー」っていう発言は良く目にする。
実際、まぁ、そういう情報を提供してくれるのは良いし、すごく有用で、参考になる事例もあるんだが、ほとんどの場合つかえない事がたくさんある。
しかし、ほとんどの場合、どーでも良くて、「そうか。」ってなる。なぜなら、「○○にも同様の事が言えて~」という発言は経験上、自分の事を話したいだけだったりする事が多い。その場合、たいてい、本当にどうでも良い。
状況がまるで違う
また、「○○にも通じる」と言ったとき、その通じる状況が全く異なってて、問題の本質の根本が全然違うことが良くあるのだ。その場合、話題を最初に出した人の言いたいことが伝わらない事が多い。そして、消化不良になるのだ。
それは、そもそもだから文脈が把握できてないのだし、しっかり「聞け」って言うことだが、人は文脈に引っぱられてしまうので、仕方ない面はあるのかもしれない。
「違い」を探す
さて、どうすれば言いか? とすれば、「違い」を探すことだ。何かといえば、「似ている」という状況の背景には、必ず、「異なった常識」が存在するからだ。その事なった常識が、その人の社会システムを知ることになる。そこで、新しい考えが生まれるかもしれない。
Future Sync Vol.5の参加したことに対する感想やら
2015年5月16日、FutureSyncという、福岡のイベントがあり、参加してきた。
毎年開催され、僕はVol.3から参加しました。Vol.4の頃は、福岡の若手勉強会主催者のディスカッションに登壇した。今年が、最後のイベントだということだ。たぶん、運営メンバーの気が変わるとか、アンコールとかあるかもしれないが、今年で最後だ。
今回は、若干ブログを書くまでにタイムラグがあった。毎回は、直ぐに書くのだが、今回は、単純に、自分なりにメモやらが多かったので、それを整理するのに時間が掛った。
「外化」とは、頭の中を外に出すことだ。今回もそれをやっていくかもしれない。
Future Sync Vol.5の参加したことに対する感想やら
僕が参加セッション
さて、今回僕が参加したセッションは以下の5つである。
- 複雑に絡み合ったユーザーの思いを「ともにデザイン」するインクルーシブデザイン by 平井康之 *「体験」をスケッチする by 金箱淳一
- UXのデザインはどうすれば上手くなるのか by UX Fukuoka 吉川伸彦
- ひとつのレースが「宇宙に挑戦する者はいないか」と言った。 by HAKUTO
- 議論の可視化が生み出す効果 by Tokyo Graphic Recorder 清水淳子
なんだかんだ、エンジニアなのにデザイン関係が多い。特に意識がしていなかったのだが、おもしろそうなものを選んだら、こうなった。
インクルーシブデザインと、デザイン思考
平井先生の話を聞いてて、最近なんだかんだ実践していることと近いんじゃないかと思った。これを詳しく読まないといかんなーとか思った。
あと、老人介護の「ライフマップ」を作る話は面白かった。「ケアプラン」じゃなくて、これまでの人生の生まれてから、死ぬまでの道筋というか、そういうもんを書く。「いつ死にたいですか?」って聞くらしい。
「体験」をスケッチする
楽器インターフェースの「体験」を、どのように設計するか?という話だった。もともと、僕も音の関係のことをやっていたので、凄い親近感というか近いものを感じた。
さて、話の中で、「Interactive Sketch」という手法などを紹介されていた。今度やろうと思った。
この人の話は、アートの範疇ではあるが、デザインに近い側面を持っていてとても面白いなと思った。
UXをなんとかする話、吉川さん。
UX Fukuokaで、大変、お世話になってます。もっと僕もUXを血肉にするためがんばって行きたいなと思います。
HAKUTO
ローバ良いよねー。
さて、民間による宇宙開発。凄い。けれども、「民間」ってのが面白くて、結構実は「宇宙」という課題が、僕等の身近にあると気づかされた。
宇宙開発のために、もしかしたら、僕達の技術も、一見なにも関係ない技術でも、貢献できる可能性があるかもしれない。そして、宇宙の技術が、実は僕等の身近な存在かもしれないと思うとワクワクする。
グラフィックレコーディング
今回これが、僕の中で一番印象に残った。僕は絵が苦手なのだかが、なんだか上手く絵にすることができるかもしれないと思った。
なんというか、僕もテキストのみの情報というのが嫌になってきたので、いろいろなものを図にしたくなる衝動に駆られて、グラフィカルプログラミング言語まで作ったりしたものだが、共感するものが多いにあった。
テキストの理解を促すのみだけでなく、グラフィティカルなものがより新しい発見ができるような仕組みを考えて行きたいと思った。
今の日常からつながって行く「未来感」。
改めて、今回のFuture Syncのことを考えるて、たぶん得たものと言えば「未来感」である。僕等は、「未来感」というもをどこか、遠くの存在として、憧れの存在として追いかけるものだと思っていないだろうか? 実はそれは違ってて、「未来感」というものはどこか日常を観察して発見するものだと思った。
「未来」というのは、どこか突飛なものでは無く、実は「日常」を観察してみて、気づき、そこで、ほんの少しの行動することなんだと思う。イノベーションとか、パラダイムシフトというものは、実は僕等が生活している中を振り替えてみると、発見できるものかもしれない。
生活を少しずつ変えることによって、周りとは違う「未来感」を体験できるのかもしれない。そう思ったFuture Syncであった。
最後に、Future Syncみなさんお疲れさまでした。
「子供にでもできる」ではなく、「子供にしかできない」ということ
僕が以前、前職で、グラフィカル言語、Flowerを作ったときも思ってたことを書く
「子供にでもできる」
「子供にでもできる」。この言葉、僕がFlowerを作った時、凄くなんかもやもやして、イライラした感情を抱いた。その時は、「子供にでもできる」という事が、おそらく「大人の僕には関係のない」という感情が僕の視点から見え隠れしているからだ、思ったからだ。
だが、最近考え直してみると、そういうことでは無い気がしている。むしろ、「子供にでもできる」というのは、UIやプロダクトのデザインにとってなんの褒め言葉では無いということだ。また、「子供にでもできる」というのは、実はかなり評価が甘く馬鹿にしているという気分も実はしている。
「○○にもできる」
さて、ではなぜ、僕がイライラした感情を抱いたかといえば、そもそも「何々にもできる」という言葉自体がそもそも嫌いだからだ。「そんなの小学生でもできる」「そんなの幼稚園生にでもできる」「君はダメだな、そんなこと女にでもできる」というニュアンスに非常に近い。これは、非常に差別的な見解を持っていると思う。これらの言葉は、非常に僕は不快な言葉だ。
まぁ、僕が変に敏感なだけかもしれないが、ただ、「子供にでもできる」という言葉がまず嫌いというわけだ。
「子供でもできるUI」
次に、「子供にもできる」UIというのは全く持って、褒めてないのだ。UIを設計するときに、「子供が使う」にデザインされたUIというのであれば、そりゃそうだろう。寧ろ当然そうあるべきだ。 しかし、「子供が使う」事を想定していないデザインであれば話が違う。なぜなら、「子供が使えるUI」であるからと言って、「使いやすいUI」とは無関係だからだ。
子供と大人というのは全く違う。何が違うか? 「経験」だ。特に、大人というのは、ガラケーを使い、GUIのコンピュータを使い、キーボードを使い、ipadを使い、iPhone使って生活している。つまり、従来のUIに対して慣れているのだ。一方、子供はそうでは無い。奴等は、キーボートというのを知らないのかもしれないし、マウスというのを知らないのかもしれない。
だから、そもそも、UIに対する蓄積が全く違うのだ。とすれば、「(大人が)使いやすいUI」というのも全く代わってくる。なぜなら、既に学習したUIに似せる方が使いやすいUIになるのだ。大人は、「ああ、なるほど、たぶんここらへんに、こういうボタンがあるのだな!」と思って、UIを操作する。
それに対して、子供がそんな蓄積が無い。では、どうするか? 簡単だ、「自分達の拙い体験」で「こういう体験と、似たような動きをするだろう?」と思って行動するのだ。だから、我々が使いやすいと思うUIでも、もしかしたら、子供にとって使いにくいUIになる事は十分にありえるのだ。
「子供に使いやすいUI」を目指すのであれば、徹底的に小学生のコンテキストを調査しなければならないだろう。「子供に使いやすいUI」というのは、結局のところ「使いやすいUI」であるということにはならないのだ。
とはいえ、「子供にでも理解できそうな」とも解釈すればまだ良いのかもしれないがな...
「子供にしかできない」
さて、「子供にでもできる」ということについて考えていると、ふと、思う事があった。それは、「子供にしかできない」と考えるべきだろうということだ。
子供と大人では経験が違う。知識が違う。体格が違う。文化が違う。だから、そもそも、全く異る存在であり、全く想像付かない人間なのだ。だから、「子供にでもできる」という考えはかなりおかしい。違う存在だからこそ、子供にしかできない可能性があるのだ。
「子供にでもできる」と言ったとき、何か可能性を狭めてないだろうか?。考えを変えるべきなのだ。「子供にしかできない」と考えてみると、子供というのは、如何に思いも寄らない存在であるということを思うのだ。
子供が「想像力豊か」とか「発想力がある」とか言うのは、おそらく違う。そうでは無くて、単に「人間が違う」だけなのだ。だから、 自分とは違う発想ができるだけなのだ。
まぁ、ここまで書いておいて、言うのもって感じなのだが。僕は子供が嫌いだ。
UX Fukuoka インタビュー研究会 Vol.13 レポート
さて、前回書くのを忘れていた。まぁ、そういう時もある。 とりあえず、今日も凄く簡単に書く。
前回
前回は、アクティビティシナリオから、インタラクションシナリオを作成した。作成したあと、みんなで見直しをした。
今回
今回は、インタラクションシナリオ等を元に、UXフローや、簡易ストーリーボードを作成した。
今日は、Rubyコンテンツセンターに早めに付いた。開始は、19時30分~だが、19時20分には付いた。 そういえば、今日ははじめて、一番最初に着いたのかもしれない。僕は遅く来る方だ。
3名+見学者という人数。いつもはあと、2名いたのだが、忙しかったりとか。まぁ、仕方が無いってことはあるよね。
さて、そんなこんな、インタラクティブシナリオから、まず、簡易ストーリーボードを作る。以前、の浅野先生のUX、サービスデザインWS、「ペーパープロトタイピングの会」を思い出しながら。あ、その時、そういれば、資料を紛失していたのを思い出したので、コピーを頂けないか相談した。
さて、実は、この会が実は一番、曖昧な会だった。たぶん、あの時の会が一番、いろいろやっていた記憶がある。なので、なんとか思い出す。
思い出しながら書いていると、文章が若干箇条書き状態に。指摘されて若干追加した。
「ラフと雑は違う」とか、いろいろ思い出す。同時に、いろいろ抜けているところがあった。もう一度UXフローやら、ストーリーボードを復習しないと。今度、書籍とか資料とか探そう。
そんなこんなで、UXフローと、簡易ストーリーボードができた。
次回
次回は、画面遷移やらをやると思う。
fukuoka.goのソースコードリーディング会を企画した話。
外化するのは大事なことだ。外化とは、頭の中にあることを、外に出すことだ。よく、「考えている」と行って、外化しない人がいるが、それは、「考えてない」事に等しい。なので、積極的にブログなどで、「外化」することが大事だ。
なので、今回もまた、「外化」をしたい。なにかといえば、fukuoka.goのソースコードリーディングをやった話を、ブログに書くというだけである。事実を述べるのでは無く考えたことを記述していきたい。
fukuoka.goのソースコードリーディング会を企画した話。
目的
そもそも、人は何かの目標を持って行動するものだという前提が僕にはある。行動をするのは目的があるからだ。たぶん「動機」と言うのだろう。一見目的が無いように見えても、無意識や無自覚であるだけである。
さて、では今回fukuoka.goのソースコードリーディングをやった目的なのだが。いろいろあるとは思うが、主に一つに、
「参加者がある程度主体性を持てるような、勉強会を開きたい」
ということである。そしてそれは、
「一緒に勉強するメンバーを増やしたい。」
という本質的な欲求があるように思う。
勉強会の発端
さて、勉強会を振り変えると、発端は僕がなんとなくgoの勉強をしたいと思ったということなのかなと思う。そして、つぶやき、twitterで
勝手に「勉強会」というキーワードを手が入力してしまった。そんで、fukuoka.goの主催を検索して、
とまぁ、という感じで、勉強会が企画スタートしますた。
リーディング会になったわけ
そんで、まぁ企画を考えていたのですが、普通の登壇者と聴衆という形でのセミナー形式は、ありきたりすぎて飽きたのと結局勉強しているのが、登壇者で、登壇者とか主催の負担がデカいので、むしろ「参加者が積極性を持って、学習できる」というのをテーマにして考えいた。
そして、「もくもく会」や「ハッカソン」をやっても良いのかなと思ってたのだが、「もくもく会」は基本的に個人プレーになりがちで、また、「ハッカソン」となると、みんなの負担がでかくなる。なので、「個人じゃなくて、チームで」、「負担を減らす」というのもキーワードにして考えた。
そんなこんな考えていたら、プログラマーって個人の作業が多いなと思っりして、ふと思えば、ソースコード書く時は、みんな黙ってやるなー。そんで、考えてみれば、チームで作業するのって、たとえば、レビューみたいなことだよねとか。
そんで、まぁ、「レビュー会」みたいなのをしたら良いのでは?と思いった。誰かが書いて、別の誰かがレビューする。しかし、それでは、書き手の負担がでかいし、そもそも、それをやるにの勉強会時間が短かすぎる。
そして、だったら、「既に書かれているものをレビューしたら良いじゃん」となり、そして、じゃあそれは、レビューというより「ソースコードリーディングじゃん」となって「ソースコードリーディング」を企画した。
勉強会でやったこと
さて、実際になにをやったのかといえば、「3~4名のチームでのソースコードリーディング会」ですね。そして、今回は読む題材を提供し、読んでもらって、分かったこと、分からなかったことを聞き出す。
「さあ、読め」と言うだけじゃ、何をすれば良いか分からなので、読むべきポイントを整理したりとか、そいういうことをスライドにまとめたりした。そして、それを説明して、各チームでソースコードリーディングをしてもらった。
そして、最後に、各チームで、全体で発表をさせた。
そこいらは、fukuoka.goの主催のブログ
とかが詳しく書いてあると思う。
勉強会のふりかえり
さて、ふりかえりとして、まず良い点を上げるとすれば、
読むプロダクトのサイズが丁度良かった。
ということである。これは、当初、僕はもう少し大きいプロダクトにしようかと思ったり、また、各チームで自由に決めてもらおうとか考えていたのだが、時間的に考えてみれば、読む時間は35分で読めるものを、と考えると、サイズが少し小さい方が良いだろうということを直前となって決めた。これが案外良かったように思える。
ソースコードサイズがでかすぎると、把握できないし、小さすぎると、みんなが飽きてしまうと思う。実際に、各チーム、ある程度読めた感じであった。
さて、懸念事項を上げるとすれば、
チームを越えた総括的な、全体協議ができなかった
これは、僕が上手くそういう方向性に持って行けなかったとは思う。なので、次回からはここらへんをもうすこし活発にしたいとは思った。具体的には、各チームで意見が異なるような施策を考えるべきではあると思う。
最後に
さて、これから、どうするかって言えば、もうすこし、リーディング会を重ねて、いろいろ試したいとは思っている。また、fukuoka.goだけでなく、福岡Emacsを企画したり、Erlang勉強会や、関数型勉強会を復活させたいとは思っている。
また、プログラミングだけでなく、UXの会の方もやっていくので、みなさんよろしくおねがいします。
