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 うぉーるぼっとの勝さんに参加をお願いしたのだけど、みなさん満足してもらっただろうか…

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

以下、感想。

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

たぶん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

上記イベントに17時50分まで参加した後に18時からのこちらのイベントに参加しました。我ながらアホですn(ry

内容は、メモがわりにつぶやいていたのをまとめていただきました。

つぶやきまとめ(うわー35ブクマover www)

やすゆきさん主催のイベントはスゴ本オフのLOVE編以来かなぁ…

以下簡単に感想などなどを。

実態に合わせて柔軟に変わっていた音楽周りの法律

レコード→カセットテープ→CD(→MD？)→インターネット配信などなど、受け取る媒体が変更になるにつれ、それに合わせて法律も進化していました。今はインターネット配信がまだ過程だと思いますが、著作権って思ったより柔軟だなぁというのが収穫としてありました。

レンタル界隈も、誰か突破した人がいて、なし崩し的に変わった部分もあり、あー今のwebサービスの空気に似てるなぁと感じました。

ユーザーが著作権関連法を知らないといけない時代

途中のつぶやきから引用すると「作って公開することも、違法なものもダウンロードするのも、不便だったことも、全部簡単になっている。そのため、自分の権利を知る必要が出てきている。」

何をするのも簡便になっている。なっているからこそ、ちょっとしたことが違法な行為になっていたりする。特に作って公開すること、作り手になることが簡単になっていることにも自覚的になるべきなんだなぁと感じました。Ustreamで…などなど。

ユーザーが自覚的になるために

話を聞いてて気になったのは、ユーザーがこういうことをやっちゃいけないということが緩くなってしまっているんだなぁと思ったり。例えば、放送で使われる音楽。ジングル？とかシンクロ？といったもので、昔も今も、楽曲（洋楽）の一部が華やかに使われています。でも、実際海外の放送ではそんなに使われないとのこと。昔の放送ほどフリーダムではないにしろ、現在でもバラエティのジングルでは多用されているとこのことでした。

そうすると、ユーザーにも無意識に「あ、聞いたことある」＝「使っていいんだ」ということになってしまうんじゃないかなぁという気がしました。

ユーザーがやるとNGだけど放送ではOK、みたいなのって、日本みたいなマス向けメディアが発達してた環境でOKだったのでしょうかね。ふと考えてしまいました。

Spotify

最後はやっぱりSpotify。ビジネスモデルもユーザー体験も、中身の技術も完成度が高い。デモ見ただけで、これでいいじゃん感、俺も欲しい欲しい感がすごかったです。

最後にJRCの荒川さんが公共ではない私企業にデータを預けていいのか、MySpaceの二の舞になってしまうのではないか、公共への働きかけが必要なのではないかということを述べていましたが、そのとおりで、音楽はもっと公の資産になっていいと思います。それは数十年先とかかもしれませんが。国立図書館みたいな、そういう役割のところがあってもいいですよね。

いやー、本当に勉強になりました。ありがとうございました。

DevLOVE裏方として、ストーリーテリングWSを開催しました！

UX Tokyoのお三方、本当にありがとうございました！！！！

以下簡単にまとめたいと思います。

今回の意図

今回は開発者向けということで、実際の現場での適用までを念頭に、ペーパープロトタイプ作成までをやることにしました。そのため集まったのは朝10時…10時からランチ含めて18時までの長丁場となってしまいました。（ちょっとキツかったですかねw

でも、デザインとしてのストーリーテリングからラピッドプロトタイプとしてのペーパープロトタイプまでできて、とても有意義だったなぁと思います。

自分は最近ちょっとコンセプトデザイン寄りの学びを進めていたところがあり、やはり実作業とつながるところ、そこまでを体験できたのがよかったなぁと感じました。

内容

内容については、ryu22eさんの記事が分かりやすいと思います。

ストーリーを集める→ストーリーを紡ぐ→ストーリーテリングまでは、今まで他所のWSでやっていたのですが、そこを一歩進めて、ストーリーテリングされたものの修正→ストーリーボード作成→ペーパープロト（ワイヤーフレーム）作成→エレベータピッチ作成までをやった感じです。盛りだくさんw

前半がだいぶ駆け足でしたが、後半は少し余裕ができてよかったなぁと思います。

エンジニアをやってると、なかなか説明する機会を意識できなくなるもんなので、自分の中で理解を棚卸する意味でも、説明するクセをつけたいなぁと思いました。

懇親会

VOYAGE GROUPの素敵な社内バーを引き続きお借りして、懇親会をやりました。結局、23時近くまで飲んでお話してました。HCDやら開発やら、ざっくばらんにお話できて、こちらもとても有意義でした。

UX Tokyoのみなさん、会場提供のVOYAGE GROUPこしばさん＆海江田さん、裏方スタッフのみなさん、本当にお疲れさまでした＆ありがとうございました！！！！

私が参加している2つのコミュニティ、「DevLOVE」と「hcdvalue」の共催という形でブレスト祭りを開催した。とてもとても学びの大きなイベントだったので、開催側の視点からブログ記事を残しておきたい。

内容のまとめはこちらを。

http://devloveblog.wordpress.com/2012/03/04/brest_festa/

開催のきっかけ

1月21日に、友人らと美術館巡りをした。その時のメンバーがたまたま「DevLOVE」と「hcdvalue」だったのだけれども、その感想戦の場で中華を食べながら冗談でDevLOVEとhcdvalueのどっちを取るんだ！的な話になった。

知ってる人は知っているのだけれど、私はこの2つのコミュニティの裏方・企画みたいなところにヒョイヒョイ顔を出していて、プライベートの時間のほとんどをコミュニティ活動に費やしていたりする。まぁ1つのコミュニティの裏方でも結構アレなので、2つのコミュニティをやってるのはとてもアレで、まぁ時間のマネジメントがグダグダになっているのは否めない。

そこで、この2つのコミュニティを結びつけるイベントを何かやりましょう、という話になった。吸収合併するぞと脅されたり、踏み絵を踏まされそうになったりした話は割愛する。

どう結びつけるか

そもそもDeveloperが集まるコミュニティの「DevLOVE」とDesignの中でもHCD(人間中心デザイン)に興味を持った人が集まるコミュニティの「hcdvalue」をどうつなげるか。これはこの1年の活動で色々考えていたこともあり、「アイデア発想」という形で繋げたいなぁと考えた。

DevLOVEもhcdvalueも「現場」というコンテキスト(文脈)をコンセプトに持つコミュニティだ。誰かのありがたい講演を聞いただけ、完全に設計されたWSを体験するだけでは、簡単に現場には持ち込めない。そこでもがくために、コミュニティで色々やっているように思う。それは失敗してもいい場としてのWSだったり、何か新しい手法を学び、それについてあれこれメンバーと議論することでもある。(議論する場はダイアログだったり飲み会の場だったりする)

現場でどう活かせるか、と考えた時に必要なもの、足りないものはたくさんある。たくさんあるんだけど、それは各人がアイデアを出して、一歩一歩解決していくしかないと思う。だから、アイデアを発想することが、「現場」への一番への還元になることだと思った。

ここで言うアイデアは多岐に渡る。プロジェクトの中のブレイクスルーだったり、現場改善のアイデアかもしれない。お客に提案する際のキーメッセージだったり、デザインの改善アイデアだったりするかもしれない。どんな小さな改善も、やっぱり「アイデア」なんだと思う。言い換えれば創造性とかになるんだけど、そういったアイデアを発想することが、DeveloperやDesignerをつなげる点として有効じゃないかと考えた。

石井力重さんをお呼びすること

そんな訳で、二つ返事で2つのコミュニティをつなげる役を買って出たのだけど、ちょっと考えて、講師を石井力重さんにお願いすることにした。石井さんとは、XB飲み会(クロスビー)でご一緒した後、宮城繋がり＆同大学卒繋がりということでtwitterやfacebookでコミュニケーションさせていただいていた。アイデア発想をベースに起業されており、アイデア発想のツールを開発したり、全国を跳び回って講師やWSファシリテーターとしてご活躍している方だ。

テーマを設定する

テーマは私の想いから事前打ち合わせでブレストし(ここも石井さんのテクニックを色々垣間見た)、「学びの効果を実感するには、どうしたらよいか？」という形にさせてもらった。これをテーマに、システムや手法など、色々とブレインストーミングしてもらう。

これはIT勉強会コミュニティの一つとして大きくなってきたDevLOVEと、社会人向け教育プログラムを基礎にコミュニティ化したhcdvalueで、共通の大きなテーマだと勝手に思っていたものだった。

DevLOVEは「野戦病院」というメタファを使っていた時期があった。現場での戦いに疲れたDeveloperがコミュニティで英気を養い、いつかまた現場へと帰っていく。でも、本当にコミュニティは今のままでいいのだろうかという不安が必ずつきまとっていたりする。運営で飲み会をしていると、「みんな本当に現場で役立っているんだろうか」という話が出ることが多くなっていた。「現場」のハブとして機能させたいのに、その循環がうまくいっているのか分からない。学びの場を提供しているものの、その効果が実感できない。そんな不安もあり、どうやったら学びの効果を実感できるのか、一度真剣に考えたかった。

hcdvalueはまだ発足1年の小さなコミュニティだ。外部向けの勉強会というのは開催しておらず、内部向けのワークショップを中心にやっている。ちょっと変わっているのは外部向けに学会発表をしていることかと思う。こういった活動は、その基礎になる産技大「人間中心デザイン」での学びが大きくて、しかもそこでの講師の方々がそれぞれセミナーやWSを開催していることが大きいかな、と思う。でも、本当にHCD(というプロセス)を現場に組み込むなら、学びの効果を実感してフィードバックし、その効果を他の人にも実感してもらうことが大事になるはず。だから真剣に考えたかった。

開催のふりかえり

とりあえずみえている範囲ではとても満足度が高くてホッとした。石井さんのファシリテーションと発想技法、その開設が素晴らしいことが大きいと思うのだけれども。では何が良かったのだろうか。

一つは「明日使える」ヒントがたくさんあったこと。これはDevLOVEのコンセプトに近いものがあって、遠い将来使えるコトじゃなく、明日の現場で使おうと思えば使えるヒントがたくさんあった。たくさんあり過ぎて取りこぼしてると思うのだけど、webにあがっている資料を読めば、きっともう一回拾えると思う。

二つ目。ブレストの技法がこんなに整えられているのか、といったものが単に把握できたこと。「創造工学」という分野には、とてもたくさんの知見があるんだなーと単純にびっくりした。IDEOとかで知ったつもりではいたけど、全然分かっていなかったなぁという感じ。とても心がホクホクしました。

三つ目。初対面でもちゃんとブレストができたこと。グループワークではアイスブレイク的に自己紹介、なんてのも多いのだけど、それを飛ばして、ブレストから入った。それでもちゃんとできたのは、参加者のモチベーションが高かったのか、石井さんのファシリテーションの妙なのかは分からないけど、とっても勉強になった。

四つ目。DevLOVEとhcdvalueが交流できたこと。裏テーマがDeveloperとDesignerのミートアップだったのだけれども、それがちゃんとできたかは不安。だけれども、懇親会でちゃんと混ざって会話が進んでいたりしたので、よかったなぁと思う。（まぁhcdvalueはちょっと固まりやすい傾向はあることが分かったけどw)

五つ目。「学び」について109個もアイデアが出たこと。これは単純にすごいなぁと思う。32人で3個以上のアイデアが出て、109個ですしおすし。「ハイライト法」ということで☆による評価はついているけれども、基本どのアイデアでも☆がついている状態で、それなりのアイデアが出ていたように思った。

今年はデブサミに行けなかった、行かなかった。そんな話をしようと思った。

DevLOVEとの出会い

ちょっと振り返ってみたい。まずはDevLOVEとの出会いから。

私はDevLOVEというコミュニティに参加していて、一昨年2010年の10月から裏方として参加している。DevLOVEとの出会いは、勉強会に狂ったように参加していた2010年3月、チームラボ主催のPM勉強会があって、そこでDevLOVEを始めた2人のうちの1人、竹本さんに出会い、DevLOVEの名刺をもらった時だと記憶している。その後、4月～8月くらいに、DevLOVEの様々なイベントに参加した。RIA勉強会、Android勉強会、Dluid(DevLove User Interface Design)…

その中でユーザインタフェースの魅力にハマり、産技大「人間中心デザイン」を受講するきっかけになった。産技大のプログラムを受講中、DevLOVEのようなコミュニティの中に入りたいと思い、裏方に志願した。

DevLOVEと出会うことがなければ、産技大の授業を受けることもなかったし、人間中心デザインを学ぼうとも思わなかったし、そこから派生した、hcdvalueという別のコミュニティもなかったか、別の形になっていただろう。

デブサミ2011

そんなDevLOVE裏方として、2011年2月、デブサミ2011に初めて参加した。

事前の打ち合わせで、特別な空間として認識していた場所は、やっぱり特別だった。2日目しか行けなかったけど、普段その人だけで1イベント立てられるような人がわんさかいた。その中でDevLOVEは1セッションを担当して、「未来のために帆を立てる」というセッションをした。その手伝いをする中で、とても大きな充実感を得ることができた。

震災後の世界

そのセッションのあと、忙しく仕事をこなしていたら、あの震災があった。

実家が宮城なのでとても心配したが、幸い被害が少ない地域で、色々悩んだあげく、東京で仕事を続けることにした。ITでできることなんて、ほとんどないんじゃないか、と悶々とする日々を過ごしていた。

僕らが日常だと思っていたのは、何だったのだろう。

変わらない世界

でも、とても大きな変化があったのに、私は今までと同じ仕事を淡々と続けていた。目の前の仕事をこなすことで精一杯だった。どこから変えていいか分からなくなっていた。

そして時は流れて、2012年2月。やっぱり仕事は忙しかった。とてもとても。

デブサミ2012

隙があれば2日目午後から参加しようと思ったが、全然ダメだった。

企画あれやこれやに参加していたものも、魂とビデオカメラを預けて、全部まかせた。

僕は、ちゃんと仕事をするという選択をしたのだった。

できれば、仲間と一緒にやりたかった。でも、今のようにあたふた仕事をするようなスタイルでは、やっぱりダメなのだ。お題目としての「効率化」は議題にあがるけれど、それを着実に実行しないといけないな、と仕事場でPCをたたきながら考えていた。