主要な6つのプログラミング言語について、とくに説明もなく紹介
プログラミング言語を紹介する
世の中には、いろいろなプログラミング言語があり、どれを選べばいいか分からない! って人達が結構います。なので、その人達のために、僕がよく使っている良く使われているメジャーな言語を紹介します。以下のプログラミング言語を学ぶのが普通のプログラマーだと思います。
あ、説明はしないです。適当にリンクだけ張るからサイト見てね。あ、Shenだけ説明しようかな。 気がむいたら、ちゃんと新しく記事を書く。
Pony
Nim
index - Nim Programming Language
Nemerle
About - Nemerle programming language official site
J
Haxe
Shen
Home | Learn Shen | OS Kernel Do
Shenは神です。
SPAである価値
以前、少し前だが、以下のブログを読んで、SPAであるべき価値について考えたことを述べる。
そもそもSPAとは?
この議論をする前に、そもそもSPAとは何だろうか?という点について整理しておこう。僕は2つの点で特徴があると思っていて、
- フロントエンドGUIであること
- Webアプリケーションであること
この2点かなと思う、簡単にまとめると、
フロントエンドGUIであること
まずは、「フロントエンドGUI」というのはどういうことかと言えば、サーバーサイドレンダリングとは対照に、jsによるDOM操作によって、UIを切り替えて行って構成するGUIを指す。
Webアプリケーションであること
GUIではあるのだが、それは、Webアプリケーションでもある。サーバーからAjaxやwebsocketなどによって、サーバとデータのやりとりをする。
ここいらの話は、思う所が結構あって、たとえば、webの技術と、GUIの技術が交わっていることによって、コミュニケーションがおかしくなったりとか、そういうことがある感じがしたりしているとか。まぁ、これは話が外れる。さて、SPA の価値について考えてみよう。
SPAの価値
先程のエントリから、幾つか、抜粋、引用する。
まずこれ。正直そんなにたくさん動的にがりがり書き換えているページをあんまり見ない気がするんですよね。その上正直そういうウェブページ、あったとしても大体使いづらいです。 世の中のページが全部FBならいいのかもしれませんが、具体的にはどんなところで使ってるんでしょう。業務ページとかですか？あと、なぜSPAにしなければいけないのかもよくわからないです。画面遷移するのだめなの？という感じで。 (http://anond.hatelabo.jp/20160521163144 より引用)
この点について、mizchiさんも、いくつかアンサーを出していたが、この点を僕なりにまとめたいと思う。(これが、本ブログの趣旨である。)
まず結論から言えば、「ちゃんとしたwebアプリケーションのUIを考えたら、SPAにならざるを得ないということが多い」ということである。順番に言って行こう。
SPAと「使いにくさ」
SPAと「使いにくさ」は関係がない。
まず、言いたいことは,SPAであることと「使いにくさ」は関係がないということである。一般に使いにくい、UIの原因は、「そもそも操作が複雑であること」と「UI設計が糞」であるかどちらかである。
そもそも操作が複雑であること、これが挙げられると思う。つまりアプリケーションが本質的に難しいのだ。toBのアプリケーションやら、ギョームのアプリケーションでは、仕方無い面があるとは思う。特殊なパターンに対応しないといかん場合が多いからね。一方、一般の人達が使うのを想定するtoCで、本質的に難しいアプリケーションを作る奴は、大抵、UXとかビジネスとサービスの根本から考えなおせクソ野郎である。
UI設計が糞というのは結構多いと思う。というのも、根本的にUIを設計ができるデザイナ、エンジニアがいないってのが問題としてあると思う。たぶん、UIの設計をやる人達は、Webデザイナだとかが多いのだが、Webページを作るデザインと、GUIを作るデザインは異なるのであり、おそらくだが、GUIのインタラクションについて考えられてないとか、そもそもユーザを定義して、ちゃんとUIを設計できるってスキルが無い人達が多いと思う。SPAの自由さを活かして、よりよいユーザのためのUIデザインができるデザイナはなかなかいないのである。
多くのSPAの場合、SPAのその表現の自由さの影響で、糞UIが生まれてくることも多い。自由すぎるのだSPAは。その結果、その自由さによって、良いUIであろうが糞UIであろうが、自由にUIを作ることができるのであり、その結果、UIデザイン、さらには、フロントエンドの技術的な設計まで複雑さをもたらしているということである。ゲームのインターフェースが素晴しいとか、ゲームの体験がすばらしいからといって、マイクロインタラクションやら、アニメーションを一杯入れて、独自の世界観を作り出し、結果糞が生まれてくる、など良く聞く気がする。
SPAが「使いやすくなる」こともある
一方で、SPAは使いやすくなることがある。一つの「使いやすさ」の指標として「ユーザのタスク時間」を考える時があるが、SPAを使う事によって、タスク時間を短くすることがある。というのも、サーバーサイドレンダリングで、一々ネットワーク越しに、通信して、Webアプリケーションを使うというのは、「遅い」のであり、SPAにすることによって、解決することがある。つまり、SPAにすることによって、ユーザとコンピュータの応答を素早くする効果がある。
もちろん、「タスクの時間」は、他の事、たとえば、画面のレイアウトだとか、ページの情報の設計だとか、その他にも影響するのだが、ユーザとコンピュータの応答を素早くするは一つの方法としてあるだろう。つまり、有効なことではないが、ある程度SPAにすることによって改善することもある。また、ページ遷移履歴の管理をスッキリさせることによって、無駄な戻るとか、進むを無くしたりして、「使いやすく」なるということも考えられる。
つまり、SPAは自由な表現とさっき言ったのだが、もちろん、ちゃんとユーザ調査、定義をして、UI設計をすることによって、より「使いやすい」ものを提供することができるようになるということもある。
ちゃんとした、まともなwebGUIを作るためのSPA
結局のところ、まともなwebのGUIを作るために、SPAであるべき(ことが多い)ということです。SPAは種々の、UIデザインの問題や、フロントエンドのGUIの技術的な設計が、難しくなることが多いが、一方で、使いやすい、よりまともな、GUIを提供できるというのが、SPAである価値であると思う。ユーザにとって需要が無いということであるのではなくて、それこそ、ユーザが気づかない潜在的なニーズに答えるというのができる可能性があるということである。
追記、誤字、脱字について
当エントリじゃなくても僕のブログは基本的に僕の考えや行動の記録でありメモであり、推敲やら見直しやらは基本的にしないで公開している。ただし、指摘があったら修正する。あとときどきたまに直したりする。「誤字が多い」とか愚痴をコメントで言うぐらいだったら、指摘した方が建設的ですよ。
自分が書いた文章なので、自分が読みやすいというのは当たり前で、人が読みにくいなんてこと結構あることを分かって頂きたい。人に読ませる文章であれば、他の数名にレビューして貰ったりするのだが、こういうブログではその負担はキツい。だから、悪いというのをただ言うのではなく、どこが悪いのか、そしてどう直すべきかというのを指摘すると、それは直すのでそのような指摘を頂けると助かるのである。
追記2
id:nurehaさんの指摘頂き、ありがとうございます。やっぱり、こういう誤字や脱字は書いた本人は全然気づかないものです。
英語とプログラミング
あと、もう一本、エントリすることにする。
まぁ、この記事についてだが....
ちょっと、ツッコミながら、僕も言いたいことがあるので言うていく。
英語の学習時間を考えてない。
、やはり「英語を先に学んでからプログラミングを勉強した方が、圧倒的にプログラミングの学習効率が高い」という結論に至りました。
「プログラミングを学んでから英語を学習するよりも、英語を覚えてからプログラミングの勉強をした方が圧倒的に学習効率が良い」というが、このエントリ、全く英語の学習時間を考えてないように思える。
そもそも、その文系大学生ってTOEIC940点になるまで、どのぐらい勉強したの? という感じで、そもそも、英語を勉強していた方が、学習が早いからって、「英語を勉強していた方が学習効率が高い」とはいえんやろというか。それを言うのであれば、英語できない+プログラミングできないで、「英語->プログラミングの順番に覚える」と「プログラミング->英語の順番に覚える」ということをやるべき。
というか、英語覚えながらプログラミングやるやろ普通は。
英語関係なしに、「デキルやつがプログラミングやっただけ」
正直に言うと、思った以上に成長が早くないというか、「ふつうに、デキルやつがプログラミング覚えたらこうなるわな。」という感じである。
ぶっちゃけ、いやまぁ、悪いけど、この記事に出てくる文系大学生、僕からすれば...そんなにプログラミング覚えるの早くない気もする。ここについてはあんまり言わんで置こう。
それに、英語ができればプログラミングの学習効率が高いというけど、プログラミングとか技術ぜんぜんできねぇアメリカ人とかもいるし。おすし。
英語よりコード見りゃわかる。
とはいえば、「英語ができた方が良い」というのが確かである。しかし、僕としては「ドキュメントが英語ばかり」で困ることが実は僕はあまりない。
僕の英語力っていうたら、英語は読めるけど、読むスピードは結構遅い方だとは思う。しかし、英語が読むのが遲くても分からなくても、そのにコードが書いてある限り、分かる。理解できるのだ。
正直、英語ドキュメントよりもコードを読む。ひらすらに。というか「英語ですらドキュメントが無い」なんてことざらにあるし、そのときは、ひたすらコード読めば分かるのである。
More Source Code than English!
あと、英語のコメントが長すぎるソースコードは大嫌いですね。
とはいえ、英語はできた方が良い
しかし、とはいえ、英語はできた方が良いとは思いますけどね。
最近のフロントエンドへの違和感
そういえば今日これらを読んでて
その中で
Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており...
はぁ? 「海外では当たり前()なんですねw 海外ってどこですか? タンザニア? パフアニューギニア? 」などみたいなリアクションを取りつつ、んで、まぁ、フロントエンドに関して、書きたかったことがあって、丁度良いので書いてみる。
というのも、フロントエンドが「凄く変化が早い」「ついていくのに大変」「新しい!!すごい」「これからは○○フレームワーク」だとかそんないろいろな意見が見られて、なんというか違和感を感じてるので今回はそれについて書く。
フロントエンドは変化が早い?
まずこれ。僕は普通に違和感を感じている。確かに、jsフレームワークやライブラリとしたら、jQueryから、Backbone、Knockout、Angular、Ember、Vue、React、Riotや、CSSではOOCSSとかBEMとかSMACSSとか、みたいなCSS設計、ツールとかだとnpmやYeoman、grunt, gulp, bower, browserify, webpackなどいろいろなものが出てきた。本当に一杯出てきた。
しかし、考えてみると、こういったツールが出てくることは「変化が早い」というものだろうか?
一体何が変化してるのだろうか? 「流行」? 「当たり前」? 僕には、「フロントエンド流行がすごく早く変化している」という論調が多い気がする。
どうして流行りに乗らないといけないの?
僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールやフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか?
フロントエンドの「最新の」フレームワークに採用したり、置き換えたりすることで、誰が喜ぶのだろうか? 同じアプリケーションでフレームワークを起き変えたって、ユーザは喜ばないだろう。だって、置き変えるだけなら、機能は変わらないのだから。フレームワークが「最新の」ものになっても、サービスが変わらなければユーザにとって意味は無い。
開発が喜ぶのだろうか? それはどうして? 設計が良くなる? 本当だろうか? ただ、あなたたちが流行り好きなだけじゃないのか?と勘ぐりたくなる。
そもそも、それ流行ってる?
たまによくある違和感としては、そもそも、「流行ってる」という出所がわりと、限定的であるということである。非常にコミュニティが狭くて、そのコミュニティに属していなかったら、「流行ってる、流行ってる」というのに説得力がないときが結構ある。
流行じゃないツールは「終わってる」のだろうか?
じゃあ、視点を変えてみよう。流行じゃないツールは「終わってる」のだろうか? そんなことは無いだろう。だって、jQueryだっていろんなところで使われているだろうし、Backbone.jsで書かれてたり、他のフレームワークやライブラリが、採用されているサービスは沢山あるだろう。そのサービスはすべて、「流行のフレームワーク」じゃないと、技術的に終わってる?今すぐ、「流行の」フレームワークに書きかえるべきだろうか?
そのフレームワークを使わないとあなたの欲しいものが作れないの?
SPAを作るみたいなとき、「React + Redux」が最近の流行みたいだから使ってみよう、みたいな感じフレームワークを選択するみたいだが、ちょっとまって欲しい。そのwebサービスは本当に「React + Redux」じゃないとダメなの? 過去に培ってきたフレームワークなどの知識でも、それはできないの? できるとしたら、それを選択する理由は何?
フロントエンドは抽象化できるほどなのだろうか?
フロントエンドと一言で言っても、いろいろあるだろう。 アプリケーションによって、フォームが一杯あってしかもそれが同期するUIかもしれないし、アニメーションがたくさんあるゲームのようなGUIだったり、画面がどんどん遷移してしまうGUIだったりするかもしれないし、画面にグラフを一杯つなげるみたいなUIかもしれないし、タッチパネルのジェスチャーをどんどんやらないといけないものかもしれない。
それらを全部まとめて、抽象化して、「フロントエンドGUI」の技術として標準化できるものだろうか? どのフロントエンドアプリケーションとして「当たり前」な技術になるほど、抽象化して語れるのだろうか?
というか、「新しい技術」を出てきても、問題が解決しないというか、問題領域が違って「そこじゃねぇだろ!」「そこ解決しなきゃ意味ねぇだろ」と思うときがけっこうあったりするのだ。
そもそも、新しくない。変化してない。
そもそも新しくなくて、変化してないなとか、思う時があって、「新しい」といって出てきた技術が実は全然あたらしくない。いや、これ昔からあったから! みたいな気分になることがある。もちろん、その時は、ちゃんと比較して調べるとかするが、それにしても騒ぎすぎな感になるときがある。
そもそも、フロントエンド開発は大変であって、やり辛いところは、どれを使っても一緒だ みたいなところはあるとは思うが、もし、そういった辛みが、なくなれば新しいんだろうなとか思ったり。
以上が僕の違和感の概観である。
最後に
こうすると、僕が「最新の」フレームワーク嫌いな人に思われるかもしれないが、そいういうことでは無い。ただ、少なくとも「これをつかうのが当たり前」とか、そういうったのが嫌いなのは確かであって、つまるところ、よりよく技術選択をして、開発したいだけである。
追記
ただ、新しいフレームワークが出てきたら勉強するというか、調べておくことはやっておくべきではあると思う。ドキュメント読んだり、サンプル読んだり、ちょっと動かしてみたりね。(僕にはフレームワークを「勉強」っていう感覚が無い。)
追記2
ちなみに、どうでもいいけど、僕もSPAを作っている人間なのですよ。
「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さんの「コーヒー」のやりとりであった。コーヒーとてもおいしかった。
