「ES5でOptionを作った」らへんに対する感想
いやまぁ、ツイッターでつぶやいて終りの内容なんだけど、きまぐれでブログに書く。
この記事と読んでて、その関連で、
とか読んでて、思わずツッコミたくなる感があるので、感想を書いておく。
「ES5でOptionを作った」に対する感想
Optionは静的型チェックで意味がある。
まず、TypeScriptなら良いのだが、Optionとかのありがたみって、コンパイラでnullチェックしてくれるとか、そういったところにあるんじゃないかなと思う。つまり、Optionによって、失敗だとか、なにもないだとかが、あるかもしれない値を静的にコンパイルして実行しなくても、静的に型エラーとして検出されるとかそういう意味でな。
そもそも、null(なにもない値)と値が同じ型であるのが問題なのだ。例えばSwiftでは、String型にnilを代入しようとするならコンパイルエラーになることによって、値が無い変数をある程度、"type safety"に扱うことができる。
TypeScriptなら利用する意味はあるような気がする。コンパイルで検知できるかもしれない。しかし、"type safety"ではない動的言語として、Optionが必要かっていうと疑問だ。
「ES6のDestructuring assignmentで解決する」に対する感想
そもそもどちらもCommon Lispにある。
これは、ツッコミというか、ただ僕がLisperなので言いたいだけなのだが、
そもそも、Destructuringもmultiple valueも、Common Lispにある。 Common Lispでは、多値も分配束縛も存在する。
;; 分配束縛 (destructuring-bind (x y z) '(1 2 3) (+ x y z)) ;; => 6 ;; 多値を返す関数 (defun ret-mul-value () (values 1 2 3)) ;; 多値を束縛する。 (multiple-value-bind (x y z) (ret-mul-value) (+ x y z)) ;; => 6
そして、わりと、Common Lispではたとえば、gethashなんかの関数では、多値で、成功失敗を表現したりする。
むしろ、イケテナイ気もがする
golangのmultiple valuesが「よくできてるなぁ」という感想を持ったらしいが、むしろ個人的には、かなり微妙だと思ったところである。
むしろ、多値を利用して、成功失敗を表現するのは、なんか個人的にはイケテナイ感じもする。なぜなら、毎回多値のどちらが、成功や失敗を表現するして、どちらかが、成功した時の値になるかなんて、やっぱり書く人に依存するからだ。
UX Fukuoka 研究会9回目 -なんのためにUXコミュニティやるんだっけ?ー
UX Fukuoka 研究会のレポートを行なう。久しぶりにだ。最近しばらく書いていなかったので、書こうと思う。
UX Fukuoka 研究会9回目
前回では、UX ファーストステップからの得られた、情報を元に、ラダリングを行ない、参加者が実際にどんな人がいるのか?について話しあった。基本的には、「基礎が理解したい」「UXを仕事で導入したい」「UXの流行を知りたい」などがあった。
今回はそれから、UX Fukuokaの現状の把握をし、そしてどうしたいか?を考えるために、ビジネスモデルキャンバスを行なった。
さてさて、今回の会場はRubyコンテンツセンターだった。そこで、最近話題の「IA/UXプラクティス モバイル情報アーキテクチャとUXデザイン」の本について話したり、UX DAYS TOKYOの話をちらっとした。
さて、最初に、今回は村上さんからの提案で、「なんのためにビジネスモデルキャンバスをやるのか?」ということを議論した。 「現状の把握をして、それからUX Fukuokaとしてどうするべきか?を考えるのと、1年前にやったビジネスモデルキャンバスとの比較をしたい」みたいな話をした。
そしてビジネスモデルキャンバスを作成した。現状のUX Fukuokaの分析をした。
途中、ヨシカワさんが入ってきた。それで、1年前とビジネスモデルと比較して、できていることできていないことを確認した。「ああそういえば、これやりたかったw」みたいなのがあった。
それで結局、「UX Fukuokaとして我々は何をしたいか?」みたいな話になって、 「UXの初心者のニーズに合わせてしまうと、セミナーモデルになってしまう。しかし、それはやりたくない。大変だから」みたいな話したりして、UX Fukuokaのコミュニティとして何がどうあるべきか?など、議論した。
最終的にこうなった。
つまり、どういうことかといえば、たとえば経営層やエグゼクティブなどの人達は、盛り上がって無いときは反応しないけど、なんか盛り上がっている時などは、「ねぇこれどうなの?」と聞いて来たりとか、そういうUXが受け入れやすい土壌ができれば、自分達がもっと取り入れやすくなったり、仕事しやすくなったりすれば良いなと思っている。
逆に、UXに関して、なにか変な思い込みをしてしまうと、逆に仕事の障害になるのでそこらへん、上手く啓発していくべきだ。というか。
今回は、参加者の方が何かスッキリしたようなので、良いと思った。
とりあえず、思うところ
結局のところおそらく僕達は、「よりよく仕事がしたい」というだけなのだと思う。
UXデザインを行なうことはユーザを中心にしてはいるが、いろいろなことを組織でコンセンサスを取らないといけない。いろんなことが関わってくる。「デザイナー」だけでなく、「エンジニア」や「経営者」の理解が得られないと、よりよいUXデザインはできないと僕は思っている。
むしろ、組織全体で、「デザイン」について深く考えないといけないと思う。デザインをすることは、デザイナーだけのものではない。むしろ、デザインの責任はチーム全体にあるような気がする。
如何にして、UXについて関心を持ってもらい、組織を巻き込み、うまく自分の仕事をよりよくやっていけるか。それだけである。
んで、ぼんやりいろいろかんがえてると、今後のUX Fukuokaの活動としての僕の理解は
- UXに関して、変な誤解なく正しく学んで欲しい -> UX勉強会、 UX読書会など
- UXの業務の事例などを共有して互いに、参考にする。 -> UX研究会
みたいになればいいのかなぁとかぼんやり思っている。
最後に
最後に、あとUX DAYS TOKYOに言ってきた報告をした。
UX DAYS TOKYOに行って、Coffeeとか飲んで来た話。
一昨日、3/18に開催された、UX DAYS TOKYOに行っきた。そのレポートとして書く。UX DAYS TOKYO自体は3/18-3/20まであるのだが、僕の1日目のカンファレンスだけ行ってきた。ワークショップも行きたかったのだが...。次は、ワークショップも行きたい。
注意
当然のことだと思いますが、UX DAYS TOKYOの内容については、僕個人の解釈であり、内容を完全に、正確に理解しているわけではありません。 僕なりの理解の仕方で、記事を書いているのであり、登壇者、主催者側の意見ではありません。
3/17日にカップメンをホテルで食べる。3/18日、ビルの入口で迷う
3/17日、starflyerで東京に行った。22:30分くらいの深夜に羽田に付いたので、東京にいる知人と飲みたかったのだが、時間が合わず。一人、ホテルに直行した。日本橋近くのホテルだ。
東京の不思議なダンジョンである、地下鉄でいろいろ迷い、最終的にホテルに近くについたのは23:50分くらいで、そのあたりの店が大抵締まってたので、ホテルで、カップ麺を食べた。
さて、3/18日は、8:00くらいにおきた。ホテルで朝食を取り、時間があったので、軽くプログラミングして、会場に行った。
会場のビルに到着したとき、3階が会場だったのだが、僕はビルの入口を間違えて、4階より上にしか行かないエレベータのエントランスに間違って入ってしまい、ちょっと迷った。ホテルをぐるとまわって、3階に行くエスカレータを発見。会場に到着する。
会場についてから
会場の受付についた。
会場の中に入ると、もうすでに前の方はいっぱいいて、僕は後ろの方に座った。
会場の通路では、コーヒーがあったりした。
直火焙煎である。
壁には、#uxdt2016とのハッシュタグが貼り出されていたが、最初ハッシュタグを「#uxat2016」と見間違えた。
UX DAYS TOKYO カンファレンスはじまり
そうこうしているうちにUX DAYS TOKYOのあいさつが始まった。
同時通訳用の機械を貰っていた。僕は片耳聞きながら、英語の単語も取りつつ聞いていった。
英語もっと勉強せんとなぁ... そして、最初のセッションのJesse James Garrettさんのセッションが始まった。
16年のUXワークから学ぶ16のレッスン : Jesse James Garrett
まず、内容としては、16年のUXの経験から得られた16の気付きについて、紹介解説していく内容であった。
16のポイントすべてメモはしているのだが全てに関して、コンテンツをそのまま全部、紹介するのもなんか良くない気もするので、一部だけ紹介しながら、どのように聞いていたか?や、どのように感じたか?を中心に感想を書こうと思う。
最初は、16年前のUXのキャリアを始める経緯について話していた。最初は、デザインの学校に行ってなかったそうで、最初はwebサイトの編集者(editor)で、デザイナーと関わりを持つうちに、デザインに重要性を感じたらしい。そしてIAを学んで行った。
2001年は、(おそらく.comバブル崩壊)で大変な時期で、その時期に、Adactive Path社を設立したそうだ。
とすれば、今は福岡ではUXの理解がまだ行ってないように思えるのに、16年前とすると全然UXやIAについて認識がされてない状況に違いないと思う。なので、「どのように自分の仕事やUXについて説明していったか?」ということを念頭にセッションを聞いて行きました。
そして、その16のポイントについて紹介されて行ったのだが、その一つ一つが含蓄があり、すごく良かった。その中で特にすごく良いなと思ったものを3つばかし上げる。ひとつは
Go farther than you think you should
である。「やるべきことより、一歩すすめ」である。仕事に慣れてくると、自分の成すべき役割を決めつけてしまいそれしかやらなくなってしまうのだが、そうじゃなくて、もっとやるべきということである。自分がやるべき範囲を超えて、仕事をするということである。
思えば、僕はエンジニアなのだが、こういうマインドに近いものは持っていたように思える。プログラマとして言われた仕様だけを実装して納得すれば仕事はできる。しかし、「なぜその仕様が出てきたのか?」「なぜ、僕はこの機能を設計し実装しなければならないのか?」ということを考えて、それがUXを勉強する理由の一つとなり勉強し始めたのだ。
実際に、やるべき範囲をこえて仕事するのは難しい。そして勇気がいる。そういうことに意識できるようになった。これだけでも良かったように思える。
Changing a design is easy Changing minds is hard
ほんとうにこれ。なんというか、偏見や思い込み、決め付けを変えるのは難しい。本当に思うことだ。 だから、人々の考えとの戦いは覚悟を持って根気を持ってやるか、それか諦めるしか無いだ。
We are all in this together
これは、どういうことかと言うと、意外と皆同じ問題を一緒にやっているということだ。 日本、福岡に住んで「アメリカほど、東京ほど、進んでない」と言うし、僕も思うのだ。確かに情報がやってくるのが遅いし、手法や技術が古いということはあるだろう。しかし、そこにある本質的な問題は実は世界共通しているということなのかもしれない。
新しい手法や方法論は、進んでいても、それは問題を解くためにやりかたが新しいか古いかの違いであり、それは直面している問題を問いているだけなのだ。もしかしたら自分達の方法で解いてしまっていたりするかもしれない。
同じ問題を問いてるのだ。だから、コミュニティを作って、解決できるかもしれない。
このセッションは、いろんなことに気づきがあり良いセッションだった。
混乱をどのように整理するか？ : Abby Covert
IA色が強いセッションだった。てか、今年のUX DAYS TOKYO、IA色が強いらしい。あとで東京の人に聞くと、「まぁ、知ってる知ってる」みたいな感じらしい。いや、やっぱ、東京進んでるわー。
僕自信、あんまりIAについては勉強できていない部分はあった。しかし、実は知らずと近いこと考えてやってるんじゃないか?みたいな感じのセッションだった。なので、このセッションもものすごく参考になった。
内容に関して、まず、ざっくり言うと「ユーザ中心にやり、言葉を考え、時には図解し、しっかりコミュニーケーションを取り、合意を得る。」というものであった。
最初に、「人々は混乱状態が大きいものだと認識していない。しかし、現実にはたくさんの問題がおきていて、混乱がたくさんある。混乱を整理して....」という感じで始まった。そして、「情報」を扱うのは難しいというのである。「情報」は物理的でなくて、人によって文脈が違っても解釈が違う場合がある。そして、人々は事実を推測してする。人は「事実」には意味が無く、情報を知覚して、リアリティを得るのである。
たとえば、「夜中にビルの電気がついている」という場合を考えると、人に寄っては「残業おつかれ」みたいな人もいれば、「電気消し忘れたのかな?」と思う人もいるかもしれない。「電気が付いている」という文脈が同じなのに、違う考えを持つのだ。そして、同時に「そのビルには昼間だれか居たのだ」というのを推測する。確認したわけでもないのに。という感じなのかな? と思いながら聞いていた。
そして、IAは「情報を「ユーザがしてくれるように」作り上げる」そうだ。そして、どうすれば良いのか?ということについて、3つのことを紹介して解説してくれた。
1つは言葉である。組織では実は、同じ表現なのに違う沢山の言葉で表わされてしまい、その結果、相手に違うものだと思われてしまい、仕事のコミュニケーションに混乱をもたらすのだ。だから、「言いたいことを伝える共通のこと」を共通認識を作っていくべきであるというのだ。
そこで、「Controlled vocabulary」というやり方を紹介されていて、結構近いことをやっているなとか思いながら聞いた。
2つめは「正しいやり方」はないというのである。だから、合意できるようにやっていくのである。
なるほど、「チーム」であれ「ユーザ」であれ合意形成しながらやっていくべきで、合意が取れないと物事が進まなくなる。だから、合意ができるように、やっていくべきだというのか。それは、合意を取るのに「正しい方法」やパターンがなんて無いということでもあるんだろうなぁとか思いながら聞いた。
3つめは図が重要であるということだ。図を使って、ワイヤーフレームでは無く、問題そのものの図をつくれというのだ。 視覚化は大事なんだろうなと思う。とにかくプロッキーを持って、図を作って、情報を整理しろってことだと思った。
そして、最後に「情報アーキテクトは専門家のものではない、みんなのものだ」ということだ。
最後に質問タイムとなった。何名か質問していて、僕も質問させていただいた。すごく良かった。
昼食、Abbyさん会話
そのあと、昼食を取った。
そうそう、その間では、スポンサーのコマーシャルがあった。
そのあと、たまたまAbbyさんが居たので会話した。僕の実際に考えている問題があって、それを彼女に質問してみた。すごくヒントになるものが掴めたし、本当に良かった。
いろいろ会話したのだが、印象に残ったものがある。僕は、「どうすれば上司やエグゼクティブを自分の仕事に巻き込めるのか? ユーザを一緒に見てくれるようにできるのか? 」 と聞いた。そうすると帰ってきた答えが コーヒーカップを指さして「 Coffee 」と言っていた。すごく印象に残った。
「社会性」がもっと僕には必要なのだ。考えてみれば当たり前のことだが、意外とできていないのだ。 自分の仕事で一杯一杯で実は当たり前のようにやらないといけないのが、できないのだ。UXをやるとよくそんなことにずっと気づかされる。
商品のストーリーボード化 : Kevin Cheng
昼食、そのあとのセッションはkevin Chengのストーリーボードの話だった。
ストーリーボード = マンガである。マンガを道具としてビジネスで活用するススメという感じの内容だった。
マンガ(comic)は、文字、文章では分かりにくいところを分かりやすくする、表現である。文章では分からないことをマンガで表現していくと、よく分かるようになると。
そうそう、アメリカではマンガというのはこども向けで、大人は読まれてない。日本では大人も読むものだ。そこまでマンガが普及している日本の状況が好きだ。みたいなことも言っていた。アメリカではこども向けだから、「ビジネスとして使うなんて!」 みたいな感じになることが多いとも。日本でもわりと「ビジネスとして使うなんて!」みないなのは多いんじゃねぇかね? とは思いながら聞いていた。
マンガというのは、なぜ良いのか? その4つの点について話していた。一つは「コミュニケーション」である。絵を使った表現は原始的なもので、文化を超えて伝えることができる強力なものだ。人間であればだれでも絵を使って伝えることができる。確かにとか思いながら、しかし、「バックグラウンドを超える」となると些か疑問に思えるのだが、まぁ、そうだろうなと思った。
2つめに、「イメージしやすい」ということだ。シンプル書くこともできるし、詳細に書くこともできる。だから、詳細にバックグラウンドを共有することもできるし、キャラクターに自分を当てはめて想像することもできる。僕は聞きながら、そんな感じの解釈かなぁとか思って聞いた。
3つめに、「表現ができる」ということだ。文字では「すいません」とか「ありがとうございます」と書けば、それは謝罪や感謝を表わす。しかし、そこに、表情を描くと、例えば「すいません」というのを怒っている顔をしているのであれば、それは謝罪しているがどこか納得していないだろう、みたいなそういうことが伝えられるみたいな感じのようかなと思って聞いた。
4つめに、「動き」が分かるということだ。時の流れや、動作などを伝えやすいということだ。なるほどと思った。これは文字で描くのは難しい。もし、たとえば体操やダンスなどを文字で解説されたら、分からないだろう。
そんな感じにマンガ表現の利点を上げて、マンガを上手く活用しようと良い、その次に、どのように描くか?みたいな説明があった。なるほどと思いながら聞いていたのだが、しかし日本の場合もっと上手くできるんじゃないか?とか思いながら聞いていた。
質問タイムがあったのでまた質問した。「ビジネスにおいてプレゼンテーション以外の場面でマンガを、どんなところで活用できるか?」そんな質問をした。ある程度「こんなところで使えるだろうな」とか考えていたので、ある意味、確認という感じだった。
このセッションの休みの間に、おやつがあったのでおいしく頂いた。
5日間でプロトタイプと試作品を設計する方法 : Daniel Burka
次に、いろいろホット(?)な「デザインスプリント」の話である。
最初に、イギリスでは「デザイン」というのがビジネスの経営者に重視されているという話をしていた。ただ、その「デザイン」というのは、あくまで、ロゴとか絵だったりのグラフィカルな表面的な理解をされていて、それを重要だと考えられているとも話していた。文化の違いを感じつつ、なるほど、おそらくヨーロッパではデザインの地位や発言権が高いのだなとか思いながら話を聞いていた。
それで、Danielさんは、経営者などに、もっと、デザインというのは事業の根幹に関わるところであり、もっと決定権がある人達にもデザインに関わるべきだみたいなことを話されていた。
その次に、デザインスプリントの方に話がなっていった。最初にアジャイルの作り方とその欠点を話されていた。
アジャイルプロセスは基本的に、仮説を建てて、早く開発し、市場投入、検証であると話されており、その上でアジャイルプロセスの欠点は、
- 仮説を抱えないといけないこと
- 開発には時間がやっぱりかかる
- サービスを投入してしまうと、サービスが辞めづらくなる。
- 統計値を取るのだと改善がやはり難しい
ということを上げていた。僕が普段アジャイルについて考えていたことを一緒であった。僕の意見をもう一つ言うならば、開発のフレームワークにサービスが依存することも大きい欠点が個人的な意見としてあった。
デザインスプリントはだから、まず「開発(build)しない」というのが重要であるという。なるほど。
さて、デザインスプリントは聞いてみると
- 「時間を決めてしまう」
- 「重要なメンバーに参加できるようにする。そして参加してもらう。」
- 「早期にユーザリサーチをし、仮説を検証する」
というところが重要な点だと思った。
僕は、この中で一番困難なのは「重要なメンバーに参加してもらうようにする」ということだろうと思う。なぜなら、「重要なメンバー」というのは大抵経営であったり、根幹の技術が分かる人だったり、組織の中でかなり重要な仕事をやっている人だろう。とすれば、他に仕事がたくさんあり、やるべきことが沢山あり、その中で、たとえば5日間、仕事を離れてしまわないとやれないのだ。とすれば、それなりに説得、理解 されないと難しいだろう。
さて、このセッションも質問タイムがあったので、遠慮なく質問した。「デザインスプリントをやるとすれば、どのタイミングで開発すれば良いか?」みたいな感じの質問をした。
SFにおける「弱いAI：ANI」と新しい試み : Chris Noessel
最後にChrisさんの、セッションだ。
SFとNarrow AIについての話であり、技術者としては非常に興味がある話だった。
最初は、バスケットボールのメンタルモデルについて話ていて、その次に、AIについての説明がった。
AIには、3つの種類があり、General AIとSuper AIとNarrow AIについてだ。今回の話は、Narrow AIの話であり、これは「ドメインを限定されたAI」であり、そのドメイン以外では使えないAIのことだ。僕は、ルンバみたいな話かなとか思いながら聞いていた。
それで、SFにおけるNarrow AIの表現を紹介し、Narrow AIについて説明していった。最初はRoll-Oh Robot という1940年の映画から始まった。 そこで、LISPやAIで有名な、John McCarthyの発言、「AIが機能したとき、認識されない」を紹介しつつ、Narrow AIについて説明が始まった。
そして、いろいろな映画を紹介しつつ、AIについて紹介して行った。
その中で、SF映画についての、AIについてはいろいろと研究しているが、日本におけるアニメについてはまだまだ疎くて、いろいろNarrow AIだと思ったら紹介してほしいみたいなことを言っていた。僕もあまり、SFのアニメを見るわけじゃないが、なるほど、ちょっと確認してみようとおもった。
Chrisさんのセッションも質問があったが、いろいろな人が質問していたので、あとで個人的にChrisさんに、質問した。「ただの機械やツール と, Narrow AIは何が違うのか?」ということを聞いた。「学術的な定義は実は無いのだが、一つの見方として、Super AIやGeneral AIの発展の途中にあるものが、Narrow AIという見方もできる」そんなことも話していた。難しい。
全体への質問、まとめ、クロージング
最後に、登壇者全員が前に出て、質問タイムが始まった。「日本独自の問題が何か? どうすれば良いか?」などの質問からいろいろ。聞きながら、上手く組織にコミュニケーションを取り納得してもらい、実践していくべきか、いろいろなヒントを貰えた。
アフターパーティ、2次会
カンファレンスの後、時間を置いて、アフターパーティがあった。参加者や、登壇者といろいろな話をした。どのセッションが良かったのか、最近どんなことをしているのか? どのような課題を持っているのか? どう解決したか? みたいなことを、雑談やくだらないことを言いながら、話した。
僕は特に予定もなかったので最後までいて、最後まで居た人と一緒に2次会に行った。どうでも良いけど、東京の人、さっさと帰りすぎるような気がする。
アフターパーティも2次会も、「明日のワークショップに参加しないのか?」と聞かれた。僕も行きたかった。しかし行けないのである。そして、そこで、東京の参加者に「ワークショップに行く重要性、意味、カンファレンスだけではダメで、そこでやっぱり分かることもある」みたいなのを聞かされる度、「重要性も分かるし、実際に僕も行きたい...、けど仕方ないんですよ」みたいなことを話した。
今回、チケットは5万円ぐらいするのだが、5万円支払って、来ない人が結構いたそうだ。ぼくは凄く重要なイベントだと思うのだが、「行けといわれて、やっぱり他の会議が入って....」みたいな感じらしい。「会社の金」なのだ。そして、自分から行くのと、行かされるのでは全然学びの態度が違うという、当たり前なことを感じた。
このあと、ちょっと東京を楽しんで、ホテルに戻った。
3/19日、福岡に戻る
大迷宮、東京の地下鉄で迷いながら、羽田空港に付き、福岡にもどった。
羽田空港では飛行機の便が遅れているらしいので、とりあえず、散策した。
最後に。
今回のUX DAYS TOKYOで、一番印象に残ったのが、Abbyさんの「コーヒー」のやりとりであった。コーヒーとてもおいしかった。
UX ファーストステップ@福岡をやった話
さて
をやってきました。
カード化
まずは、参加者同士ペアになってで、インタビューを2つやらせてみました。
一つ目は、「あなたの好きな○○は何ですか?」と聞き、そして「○○がなぜ好きか?」を「なぜ」を使わずにインタビューしてみるということをやりました。なかなか、みんな考えてインタビューしていました。
二つ目は、「あなたのUXの関心や悩み」について、インタビューして、それを付箋に書いて行きました。結構たくさん出てきて良かったように思います。自分で悩みを見つけるより、相手に悩みを聞いてもらう方が出るのかなぁ。
グルーピング
みんなでグルーピングしました。
結構出てるなぁ。
ディスカッション
グルーピングした内容をまたディスカッションしました。
今度はUX Fukuoka メンバーも入りつつ、ディスカッションしました。
なかなか、みんな同じ悩みを抱えているものだなぁと思いました。
全体共有
平野さんや坂田さんがハングアウトで参加してチーム毎に議論内容を全体で共有しました。
始めての試みで、いろいろと不手際があったなと思います。もっと気軽に話せる場にしたいですね。
ちなみに使用機材は、logicoolのwebカメラと、YAMAHAの会議用マイクスピーカーを使いました。
平野さん坂田さんを入れてディスカッション
全体ディスカッションをしようと思いましたが、ちょっと、議論が止まってしまったので、一旦、グループディスカッションをさせました。
全体だと議論しにくいようなので、坂田さんと平野さんの別のハングアウトを用意して、グループ毎にハングアウト会議をする形でディスカッションしました。
終了
さて、時間がそろそろ終わりに近づき、ハングアウトをまた全体のテレビに戻して、クロージングしました。最後に、平野さん、坂田さん、そして、実はこっそり観察されていたUX Kansaiの徳見さんにコメントを頂き、閉会しました。
次回(宣伝)
UX Fukuokaでは読書会や研究会をやっています。
次の読書会の書籍は、「ひとりから始めるユーザエクスペリエンス」です。第一回目です。
です。これもハングアウトで繋いで開催しますので、是非ご参加ください。
UX Fukuoka ハングアウト8分読書会を22回やっているのでまとめ
さてさて、そろそろUX Fukuokaの活動で、UX Fukuoka ハングアウト8分間読書会をやっているので、その活動についての紹介とこれまでのまとめをやっておこうと思う。もう22回目をやってしまった。
UX Fukuoka ハングアウト8分読書会とは
さてまずは、ハングアウト8分間読書会とはどういうことをやっているかを紹介しようと思う。
もともと、8分間読書会(http://www.aokiworks.net/diary131120.html) ものがあり、それをモデルにやっている。しかし、元に記事のように厳密にやってるわけではなく、もっとライトにもっとゆるくやっている。どちらかといえば、「読書」の時間よりも、「議論や雑談」の方が多い読書会である。
大体に人数としては、4~7名ぐらいでやっていて、やる前に、connpassのメッセージやfbで連絡を取り、ハングアウトurlを共有して、googleハングアウトによるビデオ会議で、読書会をしている。現在は隔週、つまり2週間に1回、木曜日の22:00~23:00の1時間でやっている。
さて、どのようにやっているか?といえば、まず「8分間読書」する。時間は8分間である。本は指定の本を読むのだが、特定の箇所をみんなで読むのでは無く、好きな場所、自分な気になっているような場所を読む。なんでそれをするか?といえば、最初から指定の箇所をみんなで一緒に読んだりすると、読むスピードの違いや、読み方の違い、流し読みしたり熟読したり、全体を読んで詳細を読んだり、最初から読んだり、途中から読んだり、いろんな読み方をする人が居るので好きの読んでほしいからだ。また、既にちょっと読んでる人などは、その途中から読んだり読み直したりして、より新しい発見をしてほしいし、読むのが遅い人や始めて読む人は、スピードについていけないとかが無いようにしたいのもある。
さて、8分間読んだら、Google ドキュメントを共有しみんなでまとめる。このときに、読んだところを整理する。「外化」の作業としてやってる。なんだかんだ、読んだ痕跡が残るというメリットもある。特に記述の形式に指定は無いが、言語のやりかた次第では、記述の形式を変えてやってみるとかしようかなと考えている。僕はわりと、このドキュメントを読み返したりするのだが、参加してない人にとっては読みにくいかもしれないので、読み易くしかし、書き易くするやりかたが無いか考えている。
そして、終ったら「語る」のである。先のブログとのやり方の違いはここにあって、僕達は別に8分間と指定していない。ここで、日常の事例や、愚痴などを共有したりして、雑談を楽しんでいる。わりと、この時間が楽しい。本の内容の理解もあるが、それ以上に、業務でどのように活かせるか?みたいな雑談を良くしている。
さて、具体的にどんな感じかは、22回目は読書会を録音してみたので、Youtubeにアップしています。
22回目までの振り返り
さて22回目までの振り返りをしようと思う。
ゼロ回目 ~ 7回目 : エクスペリエンスビジョン
最初から、8分間読書会をやっていたわけじゃなくて、ゼロ回~3回目まで、実は8分間読書回をやっていなくて、ただの「読書会」をやっていた。このときは、事前に読まずに「その場で読む」ということをやっていた。「その場で読む」という理由は、やっぱり時間を作って読んだり、「ここ前もって読もうね~」とやっても、そういう習慣を作るのは難しいだろうと思ったからだ。
なので、その場で読んで分かったこと、分からなかったことなどを、「その場」で読んで、議論するやり方だったと思う。そのうち、読む人のペースに差が出てきたので、ヨシカワさんが、8分間読書会というものがあるよ、というのでやってみたら、上手くハマッたので、それをやり始めた。
エクスペリエンスビジョンは、HCDとビジネスの話や、構造化シナリオや、その実践事例などが書かれていて、いろいろと参考になって、面白い内容であった。そのとき、インタビュー研究会でも、シナリオなどもやっていたので、参考になっていた気がする。
それで7回ぐらいまで読んだら、なんだかんだ、みんな、その本の内容が大体把握できていた。最初は週1ぐらいのペースでやっていたので、大体2ヶ月ぐらい。2ヶ月もあれば、みんな大体、暇な時間見つけて読んでしまっていた。意識高い。
なので、次の書籍何を読むか議論し、そこころ丁度、「ユーザーインタビューの教科書」が出版されていたので、それを読むことにした。
8回目 つなぎの回
8回目の回になるとまだ、参加者全員が書籍をそろえてなかったので、繋ぎの回として、黒須教授のユーザ工学講義(http://u-site.jp/lecture/ ) の記事を読もうという話になった。わりと、みんなの関心が分かって面白かった。
また、今度やってみようかな?
9回目 ~ 11回目まで : ユーザーインタビューの教科書
9~11回目まで、ユーザインタビューの教科書をやった。わりと良い本で面白かった。ただ、読みやすかったので、3回目で、みんな読み終えていた。
わりと、インタビュー研究会のテーマと被っているところもあって、めちゃくちゃ参考になった。
11回目、12回目 : つなぎの回、 u-siteと読書紹介回
次の書籍が届くまでの間、つなぎの回として、u-siteと読書紹介回をやっていた。
読書紹介回がおもしろくて、僕とヨシカワさんが、沢山読んでるのだが、「どうして、沢山読めているのか?」みたいなところが共有できた回だと思う。
んで、ここらへんから、ちょっとUX Fukuokaの読書会も、ちゃんと読書計画みたいなものを立てようということになったので、とりあえず計画を立てていた。
14回 ~ 16回目 ： 情報デザインのワークショップ
UX Fukuokaも初心者向けの勉強会を開催とかもあるので、情報デザインのワークショップを読もうということになった記憶がある。これも良い本で、わりかしみんな、暇なときに読んでいたようで、3回で終わった。予想では4-6回ぐらいやるかなーと思ったのだが、案外早く終った。
17回目 ~ 22回目 : HCDの基礎
今読んでいる本であるが、なかなか内容が濃くまた、年末も挟んでいるので、ちょと回数が多い。6回もやってるのか。なかなか、使っている言葉が難しく、アカデミックな感じの内容であり、また、「深く書かれているようで書かれていない」という感じなので、参考文献にあたりながら読んでいた記憶がある。
読書会やってみて。
運営が楽だった
かなり回数をやってきたが、わりかし、UX系のイベントは、ちょっとヘヴィーなものが多く、運営も参加者も疲れるものが多い印象があるのだが、この読書会は運営が楽である。時間を決めて、イベント立てて、ハングアウト繋いでおくだけである。時間も1時間程度と短かく、わりかし、気軽に参加できてるんじゃないかなと思う。
読書以外の雑談ができる場であった
読書以外の雑談ってわりと、そこでいろいろと相談などができて、とっても良い感じの時間だったように思える。
参加者の誘いにくさ
だた、一方で、参加者が誘いにくいと思った。この読書回は、ある程度知り合い同士で繋がっている。そこに、全然知らない人や、あんまり関係の深くない人は参加しにくい読書回のように思える。
少人数であるからこそ、みんなの予定に合わせて日程を管理できたし、意見を纏められた。それは良いことだと思う。しかし、参加者ほぼメンバーがUX Fukuoka研究会のメンバーであった。
今後
今後、こういった、記事やハングアウト読書会の録音を公開するなどして、もっとUX Fukuokaが参加しやすくなれば良いのかなとぼんやりと思っています。
「考え方」を教えるのは難しい
一回途中まで書いてた記事がネットワークエラーによって消えてしまって、イライラしながら書いてる。はてなブログから別のブログに移り時かもしれない。
まぁ、ぼんやり寝ながら考えたことを、大雑把に書いてるので、意味不明かもしれん。
「考え方」を教えることは難しい
それはそうと、最近、なにかを教えたり共有する事が多くなってきていて、その度思うのは「考え方」をどうやったら、共有できるか?ということを毎回思う。
「考え方」というのは、ある「やり方」があるときに、「何のために」「何でそんなことをするのか?」「どういう目的があるのか?」「何故それをするのか?」などのというようなもので、本当に大事なもの、本質的なものだ。それはとても教える、伝えるというか、共有するというのがかなり難しいなと感じる。一方、「やり方」というのは、「手順」とか「手法」とか「技術」のようなもので、「どうすればできるか?」みたいなものだ。
「やり方」を教えるのは、比較的楽だ。「やり方」というのは、その手順にそって注意すべきことをするだけで、分かってしまうし、できてしまう。なので、多くの場合は「やり方」を教えてしまう。しかし、「やり方」というのは、現実はもっと複雑で、いろいろ要素が絡んでくるので、それをそのまま当てはめて、解決できるようなものは、あまり無いのだ。
そのまま解決できないので、別の「やり方」を探して覚えようとする。いや、それも大事なことではあるのだが、引き出しを増やして、適切な問題に対処できるようになるのは大事なのだが、そうするのいろいろなやり方に振り回されて、本質的なことに気づかないで、なにもできなくなってしまうかもしれない。
だから、「考え方」は大事なのだ。「考え方」が分かるとそれは自分のものになる。自分の物になれば、それからどうすれば良いか?が分かるのだ。
しかし、「考え方」を教えたり共有するのは難しい。自分の言葉で伝えることはできるが、それを相手の言葉で理解させるのるのは難しい。なぜなら、抽象的だし、やってみて「深く考える」ことをしないと分からないからだ。また、教えることがなかなかできないので、その結果、苦しみがある。
「早く回そう!!」と「どうやって早く回すか?」「なぜ早く回すか?」
一つ、事例がある。以前、デザインプロセスとして「早く回して、短期開発を繰り返して、ユーザの評価して、リスクを小さくやろう」としたチームがあった。そのチームはそのようなプロセスやツールを取り入れようとした。皆が、プロダクトをより良いものを作ろうとしていた。
しかし、彼らは失敗したのだ。なぜなら、「ただ、早く回そう」というスローガンがあるだけど、「どうやって早く回すか?」を考えてなかったからだ。また、「なぜ早く回すのか」も考えてなかった。
彼らは、「より最高なものにしよう!」「より最高なプロダクトを目指そう!」として、ありとあらゆる仮説を立てるのが好きだった。たとえば「この、ボタンは左であるべきか? 右であるべきか?中央であるべきか?」 などに対して、「右利きの人が多いので右の方が良いだろう」「いやいや、左から目が動くので左にあるべきだ」「いろんなリスクを考えると中央だろう」「けど多数派は右利きだ」などの議論を永遠とやっていた。
なんで、こんな議論をするか? 「最初から、最高の物をつくろう」としたからだ。「早く回そう」というのは、基本的には、最初は「悩まないで作る」ということだ。「悩むよりも、決めること、やってしまうこと」が大事になってくる。最初から、最高のものを作ろうとすればいろんなことを考慮して「悩ん」でしまい、結果早く回せなくなるのだ。そして、その「悩み」は解決することが無い。だって、どの回答も全部根拠の無い推測でしか無いからだ。
また、「良いもの」というのは誰にとって「良いもの」だろうか? 実はそれも大事なことであった。彼らは、それを「良いもの」を「彼ら自身にとって」にしてしまっているのだ。それもまたまずいことだ。本当に「良い」かどうか判断するなんて「ユーザ」でしか無い。だから、彼らの悩みはユーザと当たるしか解決する方法が無い。だから、「ユーザと当たる」ために「早く回す」のだ。
「考え方」の共有
何も知らない、「やり方」すら、分かってない人達に対して、「考え方」を教えるのは難しい。先程言ったように、言葉で伝えるのは簡単だ。しかし、多くの場合、「相手の言葉」で理解しないと意味が無いのだ。自分の言葉で伝えても、おそらく表面的な理解、さきのような「スローガン」としての理解になったり、相手は深く納得しないだろう。
では、どうやって「考え方」を伝えるべきだろうか? それは、「失敗させること」から学べるというのが一つあるように思える。先のチームでは、その失敗から、「考え方」を知るキッカケになるように思える。失敗や挫折というのは、本質を知るための一つの手段なのだ。
ただし、「失敗」しようとしなければ、たぶんそれは素質が無いのだ。諦めるしか無いかもしれないと、わりと最近思ってしまっている自分がいる。
教えるのは難しい。
プログラミングからUXまで、僕がこれまで、読んできた書籍をピックアップする
さて、僕のキャリアとしてはプログラミングから始まり、CTOを得て、UXデザイナになったわけだが、そこで読んできた書籍をなんとなく紹介しておこうと思う。 なんとなく振りかえりである。
プログラミング
やっぱり、いちばん読んだ本としてはこれらが一番多い。
lisp系
Lispの入門をするなら、この一冊をまずお勧めする。非常に読みやすいと思うし、Lispエイリアンが可愛くなる。Clojureだろうが、Schemeだろうが、Common Lispをやろうが、「Lisp」のなにがしを始めようとするならば、とりあえずこの一冊をおすすめしたい。
Common LispのCLOSを勉強するために、購入した書籍である。MOPについていろいろと知れて面白かった。
最近出ている本、実はまだ全部は読み切れてないが、おもしろい。
Lispと言えばマクロだろう。マクロについて楽しめる書籍である。
まぁ、Lisperでなくても,SICPは読んでるという人は多いのかもしれない。SICPは第4章と第5章が一番おもしろい。なので、1~3章までは案外読み飛してもいいかもしれない。
なんだかんだ、問題集代わりに使っていた。
Lisp以外の関数型言語系
Haskellの入門ならこれかなと。すごいH冗長すぎるかも。しかし、モナドについては分かりやすいかなー。ふつけるは、すごいHが合わなかったら読んでみることをおすすめする。
批判が多い感じがしますが、僕としては、モナド変換史など、ちょっと、すごいH本を読んだ後に読む本としては良かった。
すごい薄いんだけど、読むのにかなり時間がかかる本。てか、未だに、全部読み切れてない。6割ぐらい。どの本でもそうだけど、わりと、全部理解しようとせず、ポイントだけ掴んで読み飛して、あとでじっくり手順通りに理解するぐらいが丁度良いかもしれない。
読んで凄い面白かった本。これで並列や並行処理について詳しく知れた。
Haskellばかりじゃなくて、とりあえず、OCamlもやってるんだけど、OCaml入門ならこれかなと思いまつ。
OCaml入門だけだと物足りないので、ついでに読んだ本。
とりあえず、目を通した程度なんだけど、わりと良い内容だった。
だいたい、これより上にある書籍読んでれば十分だけど、Scalaで関数型プログラミングやろうとするならこれ。正直読んでて、「Haskellやれ」と思った本であった。
Erlangはとりあえず、この本で十分だった。あとは、Riakのソースコードでも読んでれば良いんでね?
プログラマとして基礎な感じの書籍
ガウディ本。これ僕としては一番おもしろかった。「並行並列H本」を読む前に読んでおくと、良いかもしれない。
正規表現勉強したいの? ぜひこれをww みたいな感じ。
コンピュータサイエンス系学部の人間じゃない人からすると、いろいろと勉強できて良かった。オートマトンから、チューリング完全だとかいろいろ。
きしださん曰く、「オブジェクト指向してないオブジェクト指向本」。いや、ほんとうにこれ面白い本だった。
分厚い書籍が続きます(笑)。トランザクションやら分散システムなど、いろいろ勉強できる。
型について勉強するならこれ。
アルゴリズム系の本はこれしか読んだことが無い(笑)。
プログラミング以外のエンジニアリングっぽい系の本
上記書籍はだいたい読んでるんだけど、今度また紹介する。
以外と読んで無い人が多いのではないだろうか?
スタートアップ系
さて、スタートアップするあたりで、いろいろ読んだのでピックアップ
さて、みんなわりかし、ランニングリーンばかり読んでて、青い方の本を読んでない人が多い気がする。リーンスタートアップのポリシー的な部分はやっぱり、青い本を読むべきだ。
かなり古い本だが、すごく良い本だと思う。
基本なんだけど、以外と読まれてない感じがする。
「創造することとは何か?」みたいな一つの意見が書いてあるっぽい。(ナナメ読み程度よく読んでない。)
ちょっと内容としては、薄い感じがするが、全然知らん人なら読んでおくべきじゃないか?
内容が薄い分、まぁ、なんというか、あたりまえ、的なことが書かれている。
正直、スタートアップを上記書籍を読みながら、さっさと創業して失敗してください。というか、上手く失敗してください。としか言いようが無い。
UX系
さて、UXを勉強するにあたって読んだ本である。
情報デザイン系
最初は分からないが、UXを実践してくにつれて、内容が良く分かってくる書籍。エクスペリエンスビジョンはビジネスにかなり近い内容で、ある意味一番読みやすいかもしれない。
HCD系
人間中心設計について、かなり基本的だが、アカデミックなところが書かれている。もちろん、深くでなく、概観的であり、より理解するならば、それなりの論文や書籍を読むべき。
サービスデザイン
サービスデザインの考え方や、手法について。
ビジネスモデルジェネレーション系
ビジネスモデルキャンバス(リーンキャンバス)などはとりあえず実践するしか無いが、考え方が重要である。顧客欲求から、価値提案することが大事である。
デザイン思考系
手法系
エスノグラフィ
暴走族に関するエスノグラフィ。面白かった。
老人デザインのために、自ら老婆になって、老人調査した本。面白かった。
行動観察
今読んでる本。すごく面白い。ただ、実践することが大事。
インタビュー
インタビューに関連。インタビューも実践するべき。
質的研究
すごく、良かった。てか、思った以上に安い。
その他
その他UX系で、面白い本をピックアップ
ペルソナについて書かれている本。厚い本だが、すごく読みやすくて面白い本。
情報設計の本。すぐ読める。
ソフトウェアに関しての要求工学はわりと関連している。
すごく良い。ひとりでUX勉強することについての、つらみを軽減してくれるかも。
シナリオについての本、むずかしい。
すごく面白い、心理学的視野が広がる感じ。
とりあえず、読んどけ。
まとめ
とりあえず、適当に列挙しているだけだが、まだまだ、いろいろあるので、今後、詳しく紹介して行きたい。
