UX Fukuoka 研究会9回目 -なんのためにUXコミュニティやるんだっけ?ー

ux-fukuoka.connpass.com

UX Fukuoka 研究会のレポートを行なう。久しぶりにだ。最近しばらく書いていなかったので、書こうと思う。

UX Fukuoka 研究会9回目

前回では、UX ファーストステップからの得られた、情報を元に、ラダリングを行ない、参加者が実際にどんな人がいるのか?について話しあった。基本的には、「基礎が理解したい」「UXを仕事で導入したい」「UXの流行を知りたい」などがあった。

今回はそれから、UX Fukuokaの現状の把握をし、そしてどうしたいか?を考えるために、ビジネスモデルキャンバスを行なった。

さてさて、今回の会場はRubyコンテンツセンターだった。そこで、最近話題の「IA/UXプラクティス モバイル情報アーキテクチャとUXデザイン」の本について話したり、UX DAYS TOKYOの話をちらっとした。

さて、最初に、今回は村上さんからの提案で、「なんのためにビジネスモデルキャンバスをやるのか?」ということを議論した。 「現状の把握をして、それからUX Fukuokaとしてどうするべきか?を考えるのと、1年前にやったビジネスモデルキャンバスとの比較をしたい」みたいな話をした。

そしてビジネスモデルキャンバスを作成した。現状のUX Fukuokaの分析をした。

f:id:Nobkz:20160325220408j:plain

途中、ヨシカワさんが入ってきた。それで、1年前とビジネスモデルと比較して、できていることできていないことを確認した。「ああそういえば、これやりたかったw」みたいなのがあった。

それで結局、「UX Fukuokaとして我々は何をしたいか?」みたいな話になって、 「UXの初心者のニーズに合わせてしまうと、セミナーモデルになってしまう。しかし、それはやりたくない。大変だから」みたいな話したりして、UX Fukuokaのコミュニティとして何がどうあるべきか?など、議論した。

f:id:Nobkz:20160325220005j:plain

最終的にこうなった。

つまり、どういうことかといえば、たとえば経営層やエグゼクティブなどの人達は、盛り上がって無いときは反応しないけど、なんか盛り上がっている時などは、「ねぇこれどうなの?」と聞いて来たりとか、そういう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日目のカンファレンスだけ行ってきた。ワークショップも行きたかったのだが...。次は、ワークショップも行きたい。

2016.uxdaystokyo.com

注意

当然のことだと思いますが、UX DAYS TOKYOの内容については、僕個人の解釈であり、内容を完全に、正確に理解しているわけではありません。 僕なりの理解の仕方で、記事を書いているのであり、登壇者、主催者側の意見ではありません。

3/17日にカップメンをホテルで食べる。3/18日、ビルの入口で迷う

3/17日、starflyerで東京に行った。22:30分くらいの深夜に羽田に付いたので、東京にいる知人と飲みたかったのだが、時間が合わず。一人、ホテルに直行した。日本橋近くのホテルだ。

東京の不思議なダンジョンである、地下鉄でいろいろ迷い、最終的にホテルに近くについたのは23:50分くらいで、そのあたりの店が大抵締まってたので、ホテルで、カップ麺を食べた。

さて、3/18日は、8:00くらいにおきた。ホテルで朝食を取り、時間があったので、軽くプログラミングして、会場に行った。

会場のビルに到着したとき、3階が会場だったのだが、僕はビルの入口を間違えて、4階より上にしか行かないエレベータのエントランスに間違って入ってしまい、ちょっと迷った。ホテルをぐるとまわって、3階に行くエスカレータを発見。会場に到着する。

会場についてから

会場の受付についた。

f:id:Nobkz:20160318102324j:plain

会場の中に入ると、もうすでに前の方はいっぱいいて、僕は後ろの方に座った。

f:id:Nobkz:20160318102906j:plain

会場の通路では、コーヒーがあったりした。

f:id:Nobkz:20160318113539j:plain

直火焙煎である。

f:id:Nobkz:20160318113600j:plain

壁には、#uxdt2016とのハッシュタグが貼り出されていたが、最初ハッシュタグを「#uxat2016」と見間違えた。

f:id:Nobkz:20160318113219j:plain

UX DAYS TOKYO カンファレンスはじまり

そうこうしているうちにUX DAYS TOKYOのあいさつが始まった。

f:id:Nobkz:20160318103308j:plain

同時通訳用の機械を貰っていた。僕は片耳聞きながら、英語の単語も取りつつ聞いていった。

f:id:Nobkz:20160318130420j:plain

英語もっと勉強せんとなぁ... そして、最初のセッションのJesse James Garrettさんのセッションが始まった。

16年のUXワークから学ぶ16のレッスン : Jesse James Garrett

スピーカー|UX Days Tokyo 2016

まず、内容としては、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

スピーカー|UX Days Tokyo 2016

IA色が強いセッションだった。てか、今年のUX DAYS TOKYO、IA色が強いらしい。あとで東京の人に聞くと、「まぁ、知ってる知ってる」みたいな感じらしい。いや、やっぱ、東京進んでるわー。

僕自信、あんまりIAについては勉強できていない部分はあった。しかし、実は知らずと近いこと考えてやってるんじゃないか?みたいな感じのセッションだった。なので、このセッションもものすごく参考になった。

内容に関して、まず、ざっくり言うと「ユーザ中心にやり、言葉を考え、時には図解し、しっかりコミュニーケーションを取り、合意を得る。」というものであった。

最初に、「人々は混乱状態が大きいものだと認識していない。しかし、現実にはたくさんの問題がおきていて、混乱がたくさんある。混乱を整理して....」という感じで始まった。そして、「情報」を扱うのは難しいというのである。「情報」は物理的でなくて、人によって文脈が違っても解釈が違う場合がある。そして、人々は事実を推測してする。人は「事実」には意味が無く、情報を知覚して、リアリティを得るのである。

たとえば、「夜中にビルの電気がついている」という場合を考えると、人に寄っては「残業おつかれ」みたいな人もいれば、「電気消し忘れたのかな?」と思う人もいるかもしれない。「電気が付いている」という文脈が同じなのに、違う考えを持つのだ。そして、同時に「そのビルには昼間だれか居たのだ」というのを推測する。確認したわけでもないのに。という感じなのかな? と思いながら聞いていた。

そして、IAは「情報を「ユーザがしてくれるように」作り上げる」そうだ。そして、どうすれば良いのか?ということについて、3つのことを紹介して解説してくれた。

1つは言葉である。組織では実は、同じ表現なのに違う沢山の言葉で表わされてしまい、その結果、相手に違うものだと思われてしまい、仕事のコミュニケーションに混乱をもたらすのだ。だから、「言いたいことを伝える共通のこと」を共通認識を作っていくべきであるというのだ。

そこで、「Controlled vocabulary」というやり方を紹介されていて、結構近いことをやっているなとか思いながら聞いた。

2つめは「正しいやり方」はないというのである。だから、合意できるようにやっていくのである。

なるほど、「チーム」であれ「ユーザ」であれ合意形成しながらやっていくべきで、合意が取れないと物事が進まなくなる。だから、合意ができるように、やっていくべきだというのか。それは、合意を取るのに「正しい方法」やパターンがなんて無いということでもあるんだろうなぁとか思いながら聞いた。

3つめは図が重要であるということだ。図を使って、ワイヤーフレームでは無く、問題そのものの図をつくれというのだ。 視覚化は大事なんだろうなと思う。とにかくプロッキーを持って、図を作って、情報を整理しろってことだと思った。

そして、最後に「情報アーキテクトは専門家のものではない、みんなのものだ」ということだ。

最後に質問タイムとなった。何名か質問していて、僕も質問させていただいた。すごく良かった。

昼食、Abbyさん会話

そのあと、昼食を取った。

f:id:Nobkz:20160318124029j:plain

そうそう、その間では、スポンサーのコマーシャルがあった。

f:id:Nobkz:20160318124837j:plain

そのあと、たまたまAbbyさんが居たので会話した。僕の実際に考えている問題があって、それを彼女に質問してみた。すごくヒントになるものが掴めたし、本当に良かった。

いろいろ会話したのだが、印象に残ったものがある。僕は、「どうすれば上司やエグゼクティブを自分の仕事に巻き込めるのか? ユーザを一緒に見てくれるようにできるのか? 」 と聞いた。そうすると帰ってきた答えが コーヒーカップを指さして「 Coffee 」と言っていた。すごく印象に残った。

「社会性」がもっと僕には必要なのだ。考えてみれば当たり前のことだが、意外とできていないのだ。 自分の仕事で一杯一杯で実は当たり前のようにやらないといけないのが、できないのだ。UXをやるとよくそんなことにずっと気づかされる。

商品のストーリーボード化 : Kevin Cheng

スピーカー|UX Days Tokyo 2016

昼食、そのあとのセッションはkevin Chengのストーリーボードの話だった。

ストーリーボード = マンガである。マンガを道具としてビジネスで活用するススメという感じの内容だった。

マンガ(comic)は、文字、文章では分かりにくいところを分かりやすくする、表現である。文章では分からないことをマンガで表現していくと、よく分かるようになると。

そうそう、アメリカではマンガというのはこども向けで、大人は読まれてない。日本では大人も読むものだ。そこまでマンガが普及している日本の状況が好きだ。みたいなことも言っていた。アメリカではこども向けだから、「ビジネスとして使うなんて!」 みたいな感じになることが多いとも。日本でもわりと「ビジネスとして使うなんて!」みないなのは多いんじゃねぇかね? とは思いながら聞いていた。

マンガというのは、なぜ良いのか? その4つの点について話していた。一つは「コミュニケーション」である。絵を使った表現は原始的なもので、文化を超えて伝えることができる強力なものだ。人間であればだれでも絵を使って伝えることができる。確かにとか思いながら、しかし、「バックグラウンドを超える」となると些か疑問に思えるのだが、まぁ、そうだろうなと思った。

2つめに、「イメージしやすい」ということだ。シンプル書くこともできるし、詳細に書くこともできる。だから、詳細にバックグラウンドを共有することもできるし、キャラクターに自分を当てはめて想像することもできる。僕は聞きながら、そんな感じの解釈かなぁとか思って聞いた。

3つめに、「表現ができる」ということだ。文字では「すいません」とか「ありがとうございます」と書けば、それは謝罪や感謝を表わす。しかし、そこに、表情を描くと、例えば「すいません」というのを怒っている顔をしているのであれば、それは謝罪しているがどこか納得していないだろう、みたいなそういうことが伝えられるみたいな感じのようかなと思って聞いた。

4つめに、「動き」が分かるということだ。時の流れや、動作などを伝えやすいということだ。なるほどと思った。これは文字で描くのは難しい。もし、たとえば体操やダンスなどを文字で解説されたら、分からないだろう。

そんな感じにマンガ表現の利点を上げて、マンガを上手く活用しようと良い、その次に、どのように描くか?みたいな説明があった。なるほどと思いながら聞いていたのだが、しかし日本の場合もっと上手くできるんじゃないか?とか思いながら聞いていた。

質問タイムがあったのでまた質問した。「ビジネスにおいてプレゼンテーション以外の場面でマンガを、どんなところで活用できるか?」そんな質問をした。ある程度「こんなところで使えるだろうな」とか考えていたので、ある意味、確認という感じだった。

このセッションの休みの間に、おやつがあったのでおいしく頂いた。

f:id:Nobkz:20160318142738j:plain

5日間でプロトタイプと試作品を設計する方法 : Daniel Burka

スピーカー|UX Days Tokyo 2016

次に、いろいろホット(?)な「デザインスプリント」の話である。

最初に、イギリスでは「デザイン」というのがビジネスの経営者に重視されているという話をしていた。ただ、その「デザイン」というのは、あくまで、ロゴとか絵だったりのグラフィカルな表面的な理解をされていて、それを重要だと考えられているとも話していた。文化の違いを感じつつ、なるほど、おそらくヨーロッパではデザインの地位や発言権が高いのだなとか思いながら話を聞いていた。

それで、Danielさんは、経営者などに、もっと、デザインというのは事業の根幹に関わるところであり、もっと決定権がある人達にもデザインに関わるべきだみたいなことを話されていた。

その次に、デザインスプリントの方に話がなっていった。最初にアジャイルの作り方とその欠点を話されていた。

アジャイルプロセスは基本的に、仮説を建てて、早く開発し、市場投入、検証であると話されており、その上でアジャイルプロセスの欠点は、

  • 仮説を抱えないといけないこと
  • 開発には時間がやっぱりかかる
  • サービスを投入してしまうと、サービスが辞めづらくなる。
  • 統計値を取るのだと改善がやはり難しい

ということを上げていた。僕が普段アジャイルについて考えていたことを一緒であった。僕の意見をもう一つ言うならば、開発のフレームワークにサービスが依存することも大きい欠点が個人的な意見としてあった。

デザインスプリントはだから、まず「開発(build)しない」というのが重要であるという。なるほど。

さて、デザインスプリントは聞いてみると

  • 「時間を決めてしまう」
  • 「重要なメンバーに参加できるようにする。そして参加してもらう。」
  • 「早期にユーザリサーチをし、仮説を検証する」

というところが重要な点だと思った。

僕は、この中で一番困難なのは「重要なメンバーに参加してもらうようにする」ということだろうと思う。なぜなら、「重要なメンバー」というのは大抵経営であったり、根幹の技術が分かる人だったり、組織の中でかなり重要な仕事をやっている人だろう。とすれば、他に仕事がたくさんあり、やるべきことが沢山あり、その中で、たとえば5日間、仕事を離れてしまわないとやれないのだ。とすれば、それなりに説得、理解 されないと難しいだろう。

さて、このセッションも質問タイムがあったので、遠慮なく質問した。「デザインスプリントをやるとすれば、どのタイミングで開発すれば良いか?」みたいな感じの質問をした。

SFにおける「弱いAI:ANI」と新しい試み : Chris Noessel

スピーカー|UX Days Tokyo 2016

最後に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日、福岡に戻る

大迷宮、東京の地下鉄で迷いながら、羽田空港に付き、福岡にもどった。

羽田空港では飛行機の便が遅れているらしいので、とりあえず、散策した。

f:id:Nobkz:20160319113701j:plain

最後に。

今回のUX DAYS TOKYOで、一番印象に残ったのが、Abbyさんの「コーヒー」のやりとりであった。コーヒーとてもおいしかった。

UX ファーストステップ@福岡をやった話

さて

ux-fukuoka.connpass.com

をやってきました。

カード化

まずは、参加者同士ペアになってで、インタビューを2つやらせてみました。

一つ目は、「あなたの好きな○○は何ですか?」と聞き、そして「○○がなぜ好きか?」を「なぜ」を使わずにインタビューしてみるということをやりました。なかなか、みんな考えてインタビューしていました。

二つ目は、「あなたのUXの関心や悩み」について、インタビューして、それを付箋に書いて行きました。結構たくさん出てきて良かったように思います。自分で悩みを見つけるより、相手に悩みを聞いてもらう方が出るのかなぁ。

f:id:Nobkz:20160223195642j:plain

グルーピング

みんなでグルーピングしました。

f:id:Nobkz:20160223201541j:plain

f:id:Nobkz:20160223202144j:plain

結構出てるなぁ。

ディスカッション

グルーピングした内容をまたディスカッションしました。

今度はUX Fukuoka メンバーも入りつつ、ディスカッションしました。

f:id:Nobkz:20160223203547j:plain

なかなか、みんな同じ悩みを抱えているものだなぁと思いました。

全体共有

平野さんや坂田さんがハングアウトで参加してチーム毎に議論内容を全体で共有しました。

f:id:Nobkz:20160223205759j:plain

f:id:Nobkz:20160223210310j:plain

始めての試みで、いろいろと不手際があったなと思います。もっと気軽に話せる場にしたいですね。

ちなみに使用機材は、logicoolwebカメラと、YAMAHAの会議用マイクスピーカーを使いました。

平野さん坂田さんを入れてディスカッション

全体ディスカッションをしようと思いましたが、ちょっと、議論が止まってしまったので、一旦、グループディスカッションをさせました。

全体だと議論しにくいようなので、坂田さんと平野さんの別のハングアウトを用意して、グループ毎にハングアウト会議をする形でディスカッションしました。

f:id:Nobkz:20160223211750j:plain

f:id:Nobkz:20160223213523j:plain

終了

さて、時間がそろそろ終わりに近づき、ハングアウトをまた全体のテレビに戻して、クロージングしました。最後に、平野さん、坂田さん、そして、実はこっそり観察されていたUX Kansaiの徳見さんにコメントを頂き、閉会しました。

f:id:Nobkz:20160223215651j:plain

f:id:Nobkz:20160223215704j:plain

f:id:Nobkz:20160223215822j:plain

次回(宣伝)

UX Fukuokaでは読書会や研究会をやっています。

次の読書会の書籍は、「ひとりから始めるユーザエクスペリエンス」です。第一回目です。

です。これもハングアウトで繋いで開催しますので、是非ご参加ください。

ux-fukuoka.connpass.com

UX Fukuoka ハングアウト8分読書会を22回やっているのでまとめ

さてさて、そろそろUX Fukuokaの活動で、UX Fukuoka ハングアウト8分間読書会をやっているので、その活動についての紹介とこれまでのまとめをやっておこうと思う。もう22回目をやってしまった。

ux-fukuoka.connpass.com

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勉強することについての、つらみを軽減してくれるかも。

シナリオについての本、むずかしい。

すごく面白い、心理学的視野が広がる感じ。

とりあえず、読んどけ。

まとめ

とりあえず、適当に列挙しているだけだが、まだまだ、いろいろあるので、今後、詳しく紹介して行きたい。

Splatoonはオワコン

nobkzです。

これは、2015年、Splatoon Advent Calendar

Splatoon Advent Calendar 2015 - Adventar

の記事である。

あるゲームがクソかどうかは一概には言えないのだが、個人的にSplatoonはクソで、オワコンでダメコンテンツになりつつあるので、いろいろ思いを書いておく。また、そのオワコン化していることについて、次に取るべきアドバイス的なことを助言というかじゃあどうするか?みたいなことについて、僕としての意見を述べておく。

この記事は、大体は僕の主観的なSplatoonに対する評価であり、おそらく同意できるとかできないとか、共感できるできないとかは人によってそれぞれだろう。なので、僕はSplatoonに対する意見の同意や共感を求めているわけでは無い。ただ、僕が愚痴を書いているだけである。

ただ、僕としてはSplatoonに対する飽きや、オンラインゲームとしてのシステムとしてのマズさ、僕の個人的な限界点などを感じている。たぶんそれのいくつかは、誰かが感じているような気がするし、また、分からなくても何時か感じることかもしれない。僕としては、それらの思いを感じたときに、「だから、僕はこうするんだ。」という点について述べていきたい。

ただ、誰にだって、そのゲームがオワコンになることがある。ということが言いたい。そしてその時にどうするか?、何を期待するか?である。

Splatoonがクソになりつつある。

さて、Splatoonが個人的にはクソになりつつあるのだが、その辺書いて行こうと思う。

Splatoonに対する飽き

新しい刺激のなさ

正直、僕はSplatoonに飽きかけている。これは、Splatoonが良い悪いとかでは無く、単に僕が飽きて来たのだ。毎日、毎日、に明け暮れ夢中になったSplatoonなのだが、ふといつのまにか、新しい刺激が全く無くなったのだ。毎回、毎回、同じパターンが見て、同じパターンで勝ち、同じパターンで負けるのだ。

とすれば、遊び方を変える。たとえば、ブキを持ち変えたり、イカナカマみたいなので、タッグまたはプラベに行ったり、レギュラーで遊んだりする。そうすることによって、また、違った「遊び」になり、楽しめたりする。

しかし、最近、その「新しい遊び方」が見つからなくなったし、そもそも、「新しい遊び方」を見つける気が起らないし、「遊び尽くした」という感じが出てきている。そう思えるようになってきたのである。もう、そこまでになってしまうと、新しいゲームを勝ったり、またもっと別の事に自分の時間を作った方が良い。

そもそも、考えて見れば、Splatoonで、自分の時間を使い過ぎた。Splatoonは僕だけでなく、より多くの人の有意義な時間を奪って来た、その意味で、Splaotoonはもしかしたらオワコンになるべきなのかもしれない、と思うのである。

もっと、別のゲームができるかもしれないし、もしかしたら運動もできるかもしれない、別の勉強をしてたかもしれない、もっと自分のossのプロダクトに集中できるかもしれない。もうSplatoonに遊び飽きたら、Splatoonは辞めてしまった方が良いかもしれない。

強くなる実感が無くなる、強くなれなくなる

遊びは、上手くなって行く過程を楽しむ、上手くなることに夢中になる、というのがあるかもしれない。「新しい遊び方」以外にも、「強くなる実感」が最近無くなってきたのである。なんでも、だんだんとできるようになる様は楽しい。ピアノで例えるであれば、「ピアノを弾くこと」だけが、楽しいのでは無く「ピアノを弾けるようになる感覚」が楽しいのである。

Splatoonをやって行くと、最初は、いろいろな操作を覚え、カメラの切り変えが上手くできるようになったり、移動が上手くなったり、aimが上達したり、立ち回りを覚えたり、戦況やルールなどを覚えたりとか、そういった、「上達」があってゲームの中で習熟することの楽しみがあるだろう。

僕は、その「習熟」に、限界を感じているのだ。むしろ、つらみを感じ始めている。ヘタレである。まだ僕はS+のカンストはしていない。しかし、正直、S+でカンストすることの「努力」をしたくなくなってきたのである。たかが、ゲームである。S+に上がるぐらいの「つまらない努力」をするぐらいなら、僕はLispを書きたくなる。

その意味でも、Splatoonはオワコン化している。Splatoonをプレイするのが楽しいのでは無い。「Splatoonのゲームが上手くなる」ことがやはり楽しいのだ。もしかしたら、Splatoonでひたすら塗るのが楽しい人もいるかもしれない。そういう人はたとえ、自己の限界を感じたとしても、ずっと楽しいSplatoonができるかもしれない。しかし、たぶん多くの人は、「限界を感じる」のは楽しくなくなるとかだったり、そうでなくても「以前よりかは夢中になれない」ということを感じるかもしれない。

だんだんとフェードアウトするんだろう。大して、上手くなくなり、毎日プレイしたのが、1週間に間が開くようになり、とすると、腕が鈍るので戻そうとしてちょっとやるが、直ぐ元に戻るので、またやらなくなる。そのうち、やらない期間が1ヶ月になる。3ヶ月になる。そのぐらいまで行くと、もうSplatoonは引退だろう。

システムとしてのマズさ

さて、システムとしてのまずさ、というか、僕は特にプレイしてやっぱり酷いな、と思うのがラグである。まずは、そもそもプレイしてて、システムというかそもそもネットワークゲームとして、非常にラグが多いと思う。というか、最近多くなってきたんじゃないだろうか? 僕だけだろうか?

任天堂などの、据え起き器でゲームを作ってきた企業なので、そもそもネットワーク周りに弱いと思う。特に海外勢とマッチングするのはちょっと辞めてほしいと思う。また、Wii U自体の無線の通信自体が不安定だ。家庭内のWiFi環境がいくら良くたって、Wii Uの無線は不安定であり、有線が必要になってくるのも糞過ぎるんじゃないか?と思う。

まぁ、けれども、しっかり、待ってアップデートをまつなど対策が取れれば良い。しかし、このまま、この状態が放置されてしまうと、最早オワコンである。

ゲームバランス

Splatoonゲームバランスとして、ブキ調整が何回か行なわれいるが、やっぱり調整が難しいのだろうか、強いブキ、弱いブキが出てきてしまう。その点について、いろいろと述べるとしよう。まずは、僕が一番おかしいなと思う、ところだけ述べておく。

クイックボム

まず、僕がちょっとこれはおかしいな?と思うところが、リッターのクイボである。ちょっと性能が良すぎる。とりあえず、あのノックバックだったり、手軽さだったり、結構いろいろな場面で使えるし、強すぎる。

射程が短いブキを使っていると、たとえば、ボールドなんかでリッターを1vs1すると、距離が長いと射程が負ける。だから、短距離しか無いのだが、ボールドなんかだと相手に接触するぐらい近づかないと倒せないので、近づくと、クイボの連発で負ける。至近距離でのクイボは避けようが無い。だから、絶対に気づかれないように裏取りして、倒すしか無いのだが、上手い人であればあるほど、相手に気づかれずに裏取りをするというのは非常に難しい。音で気づかれる。

個人的には正直、裏取りされたとか至近距離で近づかれたら、素直に倒されて欲しいのである。なぜなら、裏取りや、至近距離まで近づくリスクや苦労を考えると、今の状況はちょっとおかしいのではないだろうか?

これが一つの例ではあるが、ほかにも96ガロンとか、いろいろと強いブキがあって、ちょっと

つまらなくなってしまうことが問題

こう言うと、「もっとキミが強くなれば良いじゃん」とか「強いブキに持ちかえれば良いじゃん」と言われる。また、最初から強いブキ使って居る人を責めているつもりでも無いのだが、使用者から「愛着を持って使っているので僕は悪くない」という的外れなクソリプが来たりする(意見自体は間違ってはいないが、そもそも君を責めてない)。

問題なのが、そもそも理不尽に強いブキの存在によって、ゲームがつまらなくなる、ということにあると考える。理不尽に強いブキの存在によって、弱いブキの使用者がどのような立ち回りをしても、どのような努力をしても、勝てなくなり、ゲームとして崩壊してしまうことにある。ここで、注意したいのが、「強いブキ」が問題では無く「理不尽に強すぎて、どのような状況でも優位性が確保できるブキ」であり、その結果の「不公平感」である。

たとえば、上記のクイックボムのような問題は、何が問題かと言うと、非常にストレスが貯まるのである。近距離でメインでもし倒されたとするならば、「うおお、相手強い!」だったりとか、「ああ、僕が弱かった」と納得できるのだが、クイボでキルされると、「は?」となる。おそらくリッターというのは「遠距離に強いブキ」であり「近距離に弱いブキ」であるべきだと思うのだが、クイボの存在によって近距離でも対応できること自体が、公平さが無い。だから、ボールド使いがストレスが貯まる(笑)。

また、 弱いブキであれ、強いブキであれ、その武器に愛着を持つ人達がいて、そのような人達に大して「ブキを持ちかえろ」というのはどうだろうか? また、「持ちかえなければ、負け続ける」しか他が無いのだろうか? そのブキの使う「楽しさ」を捨てろと言うのだろうか?

強いブキしか存在しない世界

こうした、ブキ調整ができてないゲームの最終的な到達が、「強いブキしか存在しない世界」である。それは、一つのブキで、似たような立ち回りをして、そのスキルの競い合いでしか、「勝負」が成立しなくなるということである。勝負の多様性が無くなるということである。これはつまらない。少なくとも僕にとってはつまらない。

現に以前のS+がそのような感じだったらしい。僕自身は、修正以前にS+になったことが無く、S+の状況がかなりブキが偏っていた状況であったらしいを聞いていて、修正後はちょっとブキに多様性が増えたと聞いている。それは良いことだとは思う。

ただ、まだまだ、ブキの調整は必要だとは思うし、僕自身もボールドでS+に行けたので良かったがS+カンストがちょっと絶望的であるように思える。

やはり、自分の好きなブキで、楽しくありたい。ただ、もし、ブキのバランスが今後良くならないのであれば、Splatoonがオワコンである。

竹が救世主

どうでも良いが、竹はすばらしいブキなので、僕は乗り変えた。竹たのしい。

マッチング

また、Splatoonでオワコンなのが、そのマッチングシステムである。

マッチングとは本来、プレイヤースキルが近い人同士で、実力が拮抗した状態で、「良い勝負」をするためのシステムであるはずである。しかし、編成事故等が起きる状況はSplatoonオワコンである。

あと、途中で誰かが落ちて、それでもゲームを継続するのは如何なものか? そのまま負けて、ウデマエ落ちるとかな。最悪である。できればノーカンにしてもらいたいところではある。

(マッチングについてもいろいろあるが、記事を書くのが疲れてきた....)

ウデマエ

さて、レーティングとしてSplatoonにはウデマエがあるが、そのウデマエシステムがおかしい。

まず、Splatoonというのはブキ毎やガチホコやガチエリアなどのルール、ステージの違い、タッグかそうで無いかの違いによって「巧さ」が異なると思う。しかし、「ウデマエ」というのは、ブキの違いも無い、ルールの違いも無い状態で、上下する指標であり、たとえば、ガチエリアでS+波に上手くとも、ガチホコでBクラス並に下手ってのもいるはずである。そうした時にそれが、マッチングに関係してきて、「あれコイツS+なのに弱い」って状況が起き得る。

そこで、あるルールで、ある他のブキを使い勝ち続けてS+になり、他のルールでは非常に足をひっぱる人が出てきて、その人がそのキャラで他のルールや他のブキが使えなくなってしまう。オワコンである。そうすると、サブアカウントを作らないといけないのだが、オンラインゲームで、サブアカウントの大量発生は好ましいことでは無い。オワコンである。

塗ることも重視してくれよ!

いやまぁ、これはホントに超個人的な不満であるのだが、最近、キル至上主義が多くて、「イカに塗るか?」みたいなのが欠けているなぁと思う人が多い。僕としては「塗るためにキルをする」のであるが、一部は「キルをするために塗る」であって、まぁそれはそれなんだが。

問題は、たぶんK/D比で、K/D比が低いと戦犯扱いされる雰囲気である。いや、正直、味方で、死にまくっているけど、戦績に貢献している人もいるし、そういう行動も重視してほしいなぁと思うところである。

とりあえず、ガチマッチで戦績に塗りが出てこないSplatoonはオワコンである。

ウニ

死ね。僕はガチャをやりたいためにSplatoonをやりたいわけでは無い!!!

ゲームはいつまでもつづかない。

オワコン言い続けたが、そもそも、ゲームというのは何時か終わる。 それは、ゲームが続いたとしても、サービスが継続していたとしても、そのゲームのオワコン感は誰にでもやってくる。

Splatoonはオンラインゲームだ。その意味で、ユーザがいなくなれば、サービスは終了するだろう。いや、そうで無くても、君達自身のSplatoonとの終わりはやってくる。

だた、終わりは悪いことでは無い。あるコンテンツがオワコンになるのは悪いことでは無いのだ。むしろ、終わらない自体が悪かもしれない。Splatoonがもし終わらないのであれば、もしかしたら、君の時間が全てSplatoonになるのだ。それは、非常にもったいない。その時間でできた可能性が全てなくなるのはもったいない。

もし、Splatoonにストレスを感じ始め、毎日やってもやっても、イライラしていくだけならば、終りのタイミングかもしれない。その時は思い切って辞めてみよう。

終わりは、次のはじまりでもあるのだ。さて次は何をしようか?

Splatoonの次は何か?

さて、「次」になにがあるのだろう?

もしかしたら、新しいゲームかもしれない、新しい遊びかもしれない。新しい学びかもしれない。それが何れにせよ、あなたにとって有意義な時間となれば幸いだ。

SplatoonをWii Uを購入したのであれば新しいゲームソフトを買っても良いかもしれない。それか、Wii Uを売ってしまって、その資金から、別のことをしても良いかもしれない。ボドゲを購入して、イカナカマで知り会った、つながりで遊んでも良いかもしれない。ゲーム自体を辞めてプログラミングに集中しても良いかもしれない。

さいごに

たかが、Splatoonである。Splatoonに無駄な時間を費やすのであれば、いっそのこと辞めて他のことをしてみよう。

いや、まぁ、続けても良いけどね! (僕もまだ若干続けてるし。)

そして、Splatoon Advent Calendarの終わりもやってくるのである。それでは良いお年を。

追記

ちなみに、僕はまだ竹がたのしいのでまだ続けるデシ。前よりプレイ時間は減ったがな。