void chachaki::Blog::main()

2013年02月


http://devlove.doorkeeper.jp/events/2775

f:id:cha-cha-ki:20130228102728j:image:w640

(会場のIIJさん、開催10分前の様子。ほぼ全席埋まりました)


(SQLはおろかをまともに触ったことがないクライアントサイドのエンジニアが)裏方として参加してきました。130名募集して110名くらいは居たので、久しぶりに大規模で、その中でダイアログをやる、といった形なのでそのお手伝いに。


和田さんの話をちゃんと聴くのは、2011年4月の縦サミ(そのレポート)以来だなーと思って、聴いていた。あの時の話も衝撃的だったのだけど、今回の話もSQLは自分から遠いにも関わらず、とても心に刺さる内容だった。アンチパターン名がスタンドっぽいのはいいなぁ。


懇親会で近くに座らせていただき、自分の肩書き(エクスペリエンスアーキテクト)の厨二病っぷりにちゃんと笑っていただいたり、とても楽しい時間でした。


裏方のみなさん&参加者のみなさん、会場提供のIIJさん、そしてオライリーのみなさんありがとうございました!

f:id:cha-cha-ki:20130228102729j:image:w640

(当日設置されたオライリー書籍販売ブース)

買った本

入門 モダンJavaScript(Oreillyの紹介サイト)

SQLのイベントでjavascript本を買うという荒業をやった結果、お仕事でガッツリ関わっていきそうな気配に。

入門 モダンJavaScript

入門 モダンJavaScript

http://hdifes.doorkeeper.jp/events/2611

私が所属するDevLOVEとhcdvalueの2つと、ゲーム業界の開発者団体のNPO法人IGDA日本の3団体合同のゲーム・開発・UXD情報交換会を開催した。裏方っぽい動きをしつつ、ダイアログの流れ補佐と懇親会での発表の1つ(人気なかった)をした。


今回は自分の知り合いにテストな方が居なかったので、2HOP先をお願いすることにした。DevLOVE代表として名古屋のうさみみ…kyon_mmさんに講演をお願いした。個人的にテストエンジニアという言葉が気になっていたのでオファーした形だった。結果的にふわふわしがちなお題に対して一本筋が通るようなお話をいただけたように思う。


hcdvalueからはポンデ…イトウさんと榎本さんにお願いした。イトウさんには、HCD(人間中心デザイン)の概要的なお話をいただいた。色々あるんですよね。参加者の方が「オズの魔法使い」に驚いていたので、こちらが当たり前だと思っていることでも業界が違うと当たり前ではない、という当たり前のことに気付いたりした。

榎本さんにはA/Bテストのスペシャリストとして、入門的な内容をお話いただいた。サクッとやってる感じがいいんですよねー。あーゆーこととうんうん唸って考えるのを往復するようなプロセスにしたい。


IGDA日本からは3名、motoko128kさん、南治さん、岡本さんに発表いただいた。motoko128kさんは異色で、最も感銘を受けた。まさか人にゲーム機を演じさせるとは。でも、ロケテストの観点は、HCDで言うと観察などの観点にも応用できる気がして、もっと情報交換すると面白いなーと思った。事前にIGDA日本代表の小野さんに伺っていた話によると、ゲームセンターが減ったり、クレーンゲームだらけになっていることによって、こういったロケテストのノウハウはロストテクノロジーになりつつあるとのことだった。こんなに面白く、タメになるノウハウがロストしてしまうのは、やっぱり残念だと思う。

南治さんの発表中、みんなトロトロトロトロうるさかった。みんないっしょにトロトロトロトロ呟いてた。PS Vitaの話だったのにトロだった。中身の話は、開発したものとユーザーとの行ったり来たりの、とてもいい話だった。トロはかわいかった。

岡本さんの発表は、非常にロジカルなソーシャルゲーム運営のお話だった。KPIを設定し、ゲームの構造を決めて、作って、それを修正して、運営していく。とても当たり前のことなんだけど、そのサイクルが早いせいか、突っ走ってるなーという印象があった。


ダイアログでは自分が担当して、緩い対話モードをつくっていった。いやーあんな人数ダイアログするのは初めてで、うまくいったか不安で、終わった後周りに感想を聞きまくってしまった。


会場を提供していただいた長久さんのコラボレーションパターンワークショップの手引きも面白かった。プレゼン資料に今後パワーポイントは使ってはいけないらしい。私はC++でプレゼンツールを作らねばならない…学習パターンのワークショップはやったことがあって、それはそれで面白かったので、実際にやったらもっと面白かったかなぁと思った。ちなみに、タイミングをみつけたのでコラボレーションパターンワークショップをやってみたら、それなりに効果はあった(と思う)


ビアバッシュではポスター・デモ展示をしつつの懇親会となった。UX白書はまったく人気がなかった!!!しまった!!!w うぉーるぼっとの勝さんに参加をお願いしたのだけど、みなさん満足してもらっただろうか…


一緒に事前準備したスタッフの方々、会場提供していただいた長久さん&国立情報研究所ありがとうございました。


以下、感想。

トロがかわいかったことを除けば、同じようなことをやっているはずなのにズレ続けていく認識をずっと感じたイベントだった。開発者とユーザーのズレ、企画者と開発者と設計者のズレ、組織間のズレ、理想と現実のズレ、老練と若手のズレ、業界間のズレ…挙げればキリがないほどのズレがあるように思う。それを受け入れるか拒絶するかは、本人次第なんだろうけど、それを受け入れる方法の一つが「テスト」なのだと思う。何かズレそうなところをテストする、そんなことを思いました。

とある方から勉強会に関する相談をしたい、と言われお酒飲みながらお話してきた。最初にいただくはずだった話からは、だいぶズレた話をしてしまったようで、申し訳ないやら。でもそれなりに満足いただいたようだった。


勉強会という「型」は一緒でも、企業主催とコミュニティ主催では目的が違う。企業主催はPR・広報、人材確保など企業(組織)とヒトを繋ぐこと、コミュニティではヒト同士の繋がりをもつこと、だと私個人は思っている。


企業主催の観点からでも大変なんだなーというショッキングな話を聞きつつ、学びとは何なのか、自分に問い直しながら眠りについた。


学び続けること。学び続ける仲間がいること。自分を過大評価せず、過小評価せず、受け入れること。

たぶんfacebook経由だったと思うのですが、表題のワークショップを見つけて参加することにしました。

http://www.anotherway.jp/archives/001309.html

講師は神奈川工科大学特任准教授の中村隆之さん。中村遊び応用研究所を3年前に立ち上げており、その前はナムコ(現バンダイナムコゲームス)にいて、「もじぴったん」のプロデューサーをされていた方です。

以下メモですが、キーワードだけでそんなに分からない気がしますが…


前半の講義部分のメモ

ゲームデザインとは
  • 日本語の「ゲーム」と英語の「game」の違い
    • ゲームと言っても(オリンピックゲーム、デジタルゲーム、マネーゲームetc…)
  • 日本語の「デザイン」と英語の「Design」の違い
    • (省略)

→ゲームを通じて「自然と楽しくなる仕組みをつくる」=デザイン

ゲームデザインは何故分かりにくいか
  • 先生がいない/教科書がない→体系化されにくい
    • 全く同じゲームを遊んでも楽しいと感じる人と感じ無い人がいる
    • 楽しいと感じても違う部分で楽しいと感じることがある
ゲームデザインをどう学ぶか
  • 実際に作って体験から学ぶ。
    • 独学で。何度も作って。真似して。→ハードルが高い/時間がかかる
  • 既に完成されたものを分析して学ぶ
    • 楽しいもの/楽しくないものそれぞれ分解/要素間の関係性の発見
    • 医学でいう解剖学に近い。(リバースエンジニアリング
    • 比較的短時間で繰り返せる

ルールベースのゲームデザインの背景
  • コンピュータゲーム以前。
    • 一人で遊べることは限られていた
    • ゲームは複数人で遊ぶことが前提(勝負・駆け引き)
  • コンピュータゲーム以後。
    • 一人でも楽しい面白いと感じられることが革新だった。
    • 勝負の楽しさ以外の楽しさ面白さが重視される 「ひとりで」

コンピュータゲームの基本は一人でも楽しいこと。複数人で楽しいのはあたりまえ。

楽しいってどういう事だろう
  • 意味:主に自分の「行動」を通して持続的に感じる「快さ」
  • 「快感」がキーワード
  • ゲームで得られる快感は様々
    • 「達成感」
    • 「成長感」
    • 「勝利の快感」
    • 「爽快感」
    • 「連続でできる快感」
    • 「敵を倒す快感」
    • 「集める快感」
    • 「リズムに乗る快感」
    • 「モノを壊す快感」
    • 「狙い撃ちする快感」
    • 「謎解きの快感」
    • 「その他」

味覚に塩味甘味苦味旨み辛味があるように、ゲームで得られる快感にも種類がある

特に着目しているのは「達成感」

=基本の調味料としての塩味的要素

  • 決められたゴールに到達する快感
    • ゴール
    • ミッション達成
    • ステージクリア
    • レベルクリア
    • エンディング
  • スタート→課題→ハードル→ゴール
    • 達成感を得るためにはある程度のストレスが必要
    • ゲーム内の集団目的(目標)の関係とストレス
  • 大目標 (ex.オールクリア/エンディング…姫を助ける
  • 中目標 (ex.ステージクリア/中ボスを倒す
  • 小目的 (ex.うまく障害物を避ける/敵を倒す
  • 手段  (ex.アクション(ダッシュ/ジャンプ/叩く…)
  • 操作 (ex.ボタン押す、タッチ、スワイプ…
  • 達成感を感じさせるためにストレスを入れる
    • 達成できないと辛いだけでは?
    • 失敗しても楽しいデザイン
  • 下手な人でも楽しさが持続するためには
    • 短い時間の中に快感が繰り返しあるとクリアできなくても楽しいと感じる
  • アーケードゲームがヒットするための条件
    • 遊ぶ前に楽しそう、面白そう、やってみたいと思わせる(100円を入れてやってみたい)
    • 遊びはじめて30秒で操作方法、ルール、遊び方がわかっているだけでなく、楽しいと感じている
    • 3分でゲームオーバーになる時にはもう100円入れたくなる(リピート)
    • 後ろで見ているだけで楽しめる(やってみたくなる)
    • 実は今のスマフォアプリに求められていることに近い

ワークショップの手順

  1. 短時間プレイで快感を感じるシーン
  2. オノマトペで表すと?
  3. 物理的操作
  4. 手段(直接操作してできること) ユーザーが行なう操作
  5. 手段(結果的に「起こる」こと) コントロールできないが起こること
  6. 小目的(ゲーム内でよいと評価される最小限の行為) だいたいスコアがある
  7. 中目標(ゲーム内で最初に達成クリアゴールする事) 1面クリア。テトリスのエンドレスモードのようにないものもある
  8. 大目標(ゲームの最終目的)

「最初のワンプレイが大事」

  • まとめ
    • 先生よりコーチ。インストラクション。
    • 失敗の重要性。
    • 夢中になる。

感想・考察

自分はUXのためのデザインをエンジニア側からアプローチしている、というスタンスで参加しました。ワークショップ自体とても面白かったです。

個人的には物理操作と手段を分けていること、手段の中でもActionとReactionを分けているところが、今まで意識してなかったので良かったです。今回はスマートフォンアプリが対象なので、大目標や中目標の重要性は薄く、物理操作や手段、小目的の重要性が大きく表れたように感じました。じゃぁドラクエではどうなんだろう、とか、似たようなスマフォアプリで面白い/面白くないものを比べる時に使えそう、とか色々思いました。

また、不快/ストレス要素を組み込んでいるのはいいなぁと思います。UXのためのデザインというか人間中心デザインのプロセスで考えていると、出自がユーザビリティであることもあり、意図的に不快/ストレス要素を入れるという考えは少ないような気がします。もちろん、みんな考えていると思うのですが。

私が所属する社外勉強会コミュニティのhcdvalueで翻訳・公開しているUX白書には、長期的UXという期間的な概念が提唱されており、その視点に立ったデザインが必要だ、といったことが言われています。このワークショップで言う「大目標」や「中目標」の見せ方、といったことになるのだと思います。その辺りは考えていきたいなーと思います。

また、ゲームセンターにおけるノウハウの詰まった「30秒」「3分」といった指標がグッと来ました。こちらは短期的な、一時的UXが支配的な場合に利いてくると思いますが。

全体的に、UXデザインやらワークショップデザインやらで言われていることと似ている部分があったりして、話を聞きながらとても楽しめました。どこかで素振りしつつ自分のものにしたいなーという感覚です。誰かやろうず。

http://devlove-sendai.doorkeeper.jp/events/2718

私の地元の宮城・仙台で、私の所属するコミュニティ「DevLOVE」の仙台版のコミュニティが立ち上がりました。当然のごとく立ち上げメンバーとなりましたので、ここに想いを記しておきたいと思います。…何か書いていたらネガティヴっぽくなりましたが、そんなに悲観的ではないです!(笑

私は大学卒業まで宮城にずっと居て、就職と同時に首都圏に来ました。当時、大学で触れたC言語のプログラミングが楽しくて、漠然とソフトウェアに携わる仕事につきたいと考え、最初は仙台のベンチャー企業に内定をいただきました。その会社は私が入る前にほぼ全社員を解雇するという事態になり(苦笑)、前職となる会社(首都圏)に再度内定をいただきました。地元志向が強かった私にとって、それはとてもとても辛いことでした。それが6年前になります。


それからずっとずっと、恩返しがしたかったのです。


そして、2011年3月。大きな地震がありました。


数ヶ月前に現職に転職をする際に、仙台も視野に入れて就職活動をしましたが、活動するうちに何だか違う気がして、現職に落ち着きました。今の自分のスキルで仙台に帰っても、復興の邪魔になるんじゃないか…その感触がずっと拭えず、自分への自信の無さがずっとつきまとい、自分のやりたい仕事をずっと問い、それは首都圏にしかないと、現職に決めました。


お金やボランティア以外で、何かお手伝いできないかなぁ…そんな時にDevLOVE仙台の話が立ち上がりました。


仙台は元々、商人の街です。初売りはとても豪華な景品が付きます。そこには「サービス」の精神があったように思います。でも、ソフトウェア開発は、少し元気がないように、遠く都内からは見えていました。受託というか、受身であることに慣れてしまったような…サービスから少し遠のいてしまった、そんな気配です。仙台人は大人しい、そんなこともよく聞いてました。


それでも、少しずつ、ソフトウェア開発のコミュニティが活発に活動しているのが見えてきて、それをもっと加速させてみたいなぁと思うようになりました。これが私のDevLOVE仙台への想いです。

私が学んだり体験したりしてきたことを、少しでも仙台に返せたらという想いで、DevLOVE仙台には継続的に関わっていきたいと思っています。

というわけで、よろしくお願いいたします。

http://devlove-sendai.doorkeeper.jp/events/2718

このページのトップヘ