2013年を振り返る

今年も残すところあと僅かとなりました。毎年恒例の振り返りエントリです。

■プログラマ定年
今年の9月に35歳になりました。
以前勤めていたSIerでは、30歳を過ぎたあたりから少しずつ仕事でコードを書く機会が減ってきており、顧客調整とかスケジュール管理などの仕事が多くを占めるようになっていました。その後そういった状況が嫌で今の会社に転職し、幸いなことに35歳を数ヶ月過ぎた今でも毎日Scalaコードを書き続けています。

将来的にいつまでこの状態が続くかはわかりません。僕も今の会社で職位が上がり、開発リーダーなど任されるような日が来るかもしれませんし、そうなるとやはり自分が直接コードを書く機会は減るでしょう。ただ、そうなった後でも、今のマインドを捨てず、あくまでも「プログラマ」としてそういったリーダー業に従事できるようになりたいです。

"SE"とか"PL"とか"PM"とかではなく、限界ぎりぎりまで自分は"プログラマ"を名乗って仕事をしていきたい、ということを考える良いきっかけになりました。

■訃報
今年は身の回りに訃報が多い１年でした。
自分に大きな影響を与えた著名人だったり、同級生だったり、コミュニティの人だったり。まだ皆さんが亡くなられてから日も浅いですし、自分の中できちんと整理もできていないのでここでは多くを書きませんが、本当にいろいろな事を考えました。

■コミュニティ活動など
去年に比べると、勉強会などの参加数はかなり減ったと思います。
今までは手当たり次第にいろいろ顔を出していたのですが、勉強会でHP/MPを回復する、というような「勉強会お花畑」な状態では無くなったので、自分がどのようにコミュニティに対して貢献するか、どのように自分のキャリアを積むか、ということに少し悩んでいました。

自分がスタッフやスピーカーなど、「中の人」として関わった勉強会をまとめます。

1月

・ TDDBC 大阪 for C#（Visual Studioハッカソン事前勉強会）
現場でのペアプロについてお話させていただきました。風邪を引いて翌日のハッカソンを欠席するなど、少し迷惑をかけてしまった記憶があります。

2月

・DevLOVE関西「勉強会勉強会」
勉強会について勉強する、というメタな勉強会です。
ビアバッシュでのQAコーナーのファシリテーターをしました。

3月

・Scalaカンファレンス
今年の社外活動の中で最も印象に残っているカンファレンスです。
最初、公募セッションに応募したものの落選し、その後いろいろあって会社がスポンサーになってくれたので、スポンサー枠で発表させていただきました。
こちらのエントリにも書きましたが、ものすごい熱気で、この時代にあの場所にいれた事をとても幸福に思います。

・ステーキ駆動勉強会(hoge駆動)
いつものhoge駆動でした。

4月

勉強会参加はなし。

5月

・第4回 関西ソーシャルゲーム勉強会
会社で、ソーシャルゲーム関係者を招いての交流会をやったのがきっかけでスピーカーとして呼んでいただきました。これをきっかけにスタッフとして第５回のお手伝いをすることになります。

6月

お世話になった某社の編集者さんが留学されるということで、送別会に行ったりしました。あとはプログラマーズナイトでLTをやったり。

7月

・IT英語勉強会 第1回
Scalaカンファレンスで英語のスライドを作ったことで少し自信がついて、参加してみました。生まれてはじめて、英語でLTをしました。ネイティブの人に、聴きやすい発音でしたよ、と言っていただけて嬉しかったです。また行きたい勉強会の１つなのですが、他の予定と被たりしてなかなか参加できずにいます。

・アジャイルラジオ 前編 後編
Webラジオに出演しました。めちゃくちゃ緊張して、何を喋ったのかあまり覚えていないです。だいたい雰囲気がわかったので、もう一回やりたいです。

・日経コンピュータ 奇跡のJava
ある日仕事をしていたら、本社の広報から自分のデスクに電話がかかってきました。普段広報から内線が来ることなどないので、SNSでNGな話題でも書いてしまって怒られるのかと身構えていたら、この記事の取材申し込みについての連絡でした。Scalaカンファレンスでの登壇がきっかけだったようです。
雑誌の取材を受けるのは当然人生初体験だったので、いい経験をさせてもらいました。

・夏のhoge駆動☆カレーの王子さまリターンズ
いつものhoge駆動でした。

8月

勉強会参加はなし。仕事がむちゃくちゃ忙しかった記憶があります。関西に遊びに来た@zer0_uさんとランチ食べたりしました。

9月

・デブサミ関西
憧れのデブサミに登壇することができました。自分戦略セッションが公募制で、自薦も可、とあったのでダメ元で申し込んでみました。たぶんムリだろうと思っていたのですが、なんと人気投票1位ということでびっくりしました。

10月

・高速ITコミュニティ秋祭り
初回から参加しており、今年で3回目の開催になります。
これまでは登壇者としての参加でしたが、今回はスタッフとしての参加です。といってもあまり大したお手伝いはできなかったのですが…。

こういう、「お酒と食事を楽しみながらのトークイベント」という形式は個人的に大好きで、関西でもこういう企画をやりたいなー、と常々思っています。来年あたり実現したいです。

・怖くないScala勉強会
Twitterでの会話をきっかけに、日経コンピュータさんの奇跡のJavaの記事とも絡めて開催したイベントです。
Scala関連の勉強会の盛り上がり方は本当に驚くばかりです。こういうコミュニティの盛り上がりを絶やさず、現場の普及も着実に拡げていきたいものです。

個人的には、持ち時間に対して大幅に早く発表が終わってしまう、という大失態をやらかしてしまい、反省点の多い勉強会でした。

11月

・第9回 RxTStudy
DVCSについて話してほしい、というご依頼をいただいたので、以前関Javaで話したgitの失敗事例の後日談をお話してきました。

・開発現場に伝えたい10のこと
達人出版会さんから出版されている電子書籍です。DevLOVE関西にゆかりのメンバー10人で書きました。5月のGWに執筆し、11月に出版という長期プロジェクトでした。

・第5回関西ソーシャルゲーム勉強会
主催という立場でやらせていただきました。会場提供やスピーカーへの呼びかけなどアマゾンデータサービスさんにものすごくお世話になりました。
こちらの勉強会も継続してお手伝いさせてもらおうと思っています。

12月

・合同勉強会 in 大都会岡山 -2013 Winter-
毎年恒例の岡山での勉強会。LTでは途中でマシンがフリーズしてしまい、「自己紹介を2回やる」というネタにあふれたLTでした。

・Far East Developer Review
DevLOVE Pubが冬コミで頒布する同人誌に寄稿させていただいてます。
これもずいぶん前に書いた文章なのですが、ようやく陽の目を見られました。

・忘年会駆動
いつものhoge駆動でした。

■まとめと来年の抱負

来年に向けて、デブサミの公募セッションに応募したのですが、落選しました。一度雅叙園で登壇してみたいので、機会があればまたチャレンジしたいです。

今年１年間、コミュニティ活動をしてきて、実に様々な人と関わりを持ちました。そのような中で、自分たちの開発が、決して他社に引けをとらない、という自信も持ちました。

僕が勤める会社は、まだまだネームバリューが高いとはいえません。全国的に名を売ろうと思えば、大ヒットのサービスをローンチするなど自分個人では難しい部分もあるでしょう。しかし、エンジニア界隈でバリューを上げる、ということなら、今までコミュニティに対してコミットメントしてきた自分もある程度貢献できるのではないかと思い始めました。

これまでは自分個人のバリューアップのみに焦点を絞っていろいろな活動をしてきましたが、2014年は自分と会社双方のバリューアップに貢献できるような動きをしていきたいなー、と思っています。

いろふさんとの思ひ出

いろふアドベントカレンダー 18日目です。昨日はみうみうの「いろふさん絵描き歌」じゃないヤツ、歌ってみた #irof_history でした。

技術的なネタの構想もあったのですが、こちらは動画を撮ったりいろいろ仕込が必要で、今日は自分の番だということをすっかり忘れていてついさっきまで先斗町の鉄板焼き屋でぼっち日本酒を嗜んでおり、気づいたら準備する時間が無くなってしまいました。元々のネタはhoge駆動で発表しようと思います。

と、いうことでいろふさんとの思い出話でも。

いろふさんと初めて出会ったのは、2011年4月のScala本読書会でした。

こうして振り返ると今や同僚となった塾長がいたり、後にほげメン（hoge駆動メンバー）と呼ばれる人達のほとんどが集まっていたり、僕自身当時の会社を辞めてScalaで仕事してたり、今の僕のある意味で原点みたいなところだなぁ、と思います。

いろいろ思うところあって勉強会に行き始めたところでもあり、Scalaに興味を持ち始めた初期の頃でもあり、当時の同僚だったs_kozakeさん以外は全員初対面でした。
（この次に参加した勉強会がイケメンと初めてお会いしたTwitter4j読書会だったと思う）

そんな中にいろふさんもいました。

この時にいろふさんとの接点はほとんど無かったと思うのですが、この読書会のすぐ後に僕がこんなイベントを企画しました。

第1回 業務前モクモク会

同僚のs_kozakeさんと、会社の近くの喫茶店で始業前に勉強してから会社行こう、という会で、もともと２人でやればいいや、と思っていたのですが、他に来れる人がいたら皆で集まって各自で勉強しましょう、ということでATNDをたてました。

そこにいろふさんが来てくれました。いろふさん自身も当時思うところあって、いろいろな場に積極的に顔を出そうとされていたところだったようです。今の「いろふ複数インスタンス」の最初期だったのでしょう。

そういったところで、お互い「勉強会にとりあえず手当たり次第に顔を出す」みたいな最初の時期に接点があって、僕はなんとなくいろふさんを近い存在として感じていました。

で、なんやかんやあって今に至るわけです。

なんやかんやの部分はまた気が向いたらまたどこかで。

DevLOVE Advent Calendar 2013 【29日目】「現場における正しさとは」

DevLOVE Advent Calendar 2013 の29日目です。

昨日は瀬宮新さんの「始まらなかったアジャイルを一人でもう一度始めようとした話」でした。

去年のDevLOVEアドベントカレンダーでは「仕事とプライベートがウェットってブラックなの？」でその年のDevLOVEブログで最も読まれた記事、に選ばれましたので、今年も頑張って書こうと思います。

■きっかけはある人の質問

先日、第9回RxTStudyで、チームにおけるgitの失敗事例と、その改善までのお話をさせていただきました。(そのときのスライド)

僕たちのチームでは、結成当初からgitを使ってソースコードのバージョン管理を行っています。導入当初はメンバー全員がほぼgitを扱うのが初めて、という状態で、幾度と無くトラブルにも見舞われました。

運用を安定化させるために、チームではいろいろな試みがなされました。様々なGUIツールを試したり、ブランチ戦略を検討したり。

そのような中で、最も効果が高かったのは、『入門Git』などを読んで「正しい知識を身につける」ということでした。

僕はRxTStudyでの講演を、「ツールを使いこなすには、まずは正しい知識をきちんと学ぼう」という結論で締めくくりました。

講演後、ある方から質問をいただきました。

「正しい知識、というキーワードがお話の中で何度も出てきましたが、正しさの定義とはどのようにお考えですか？」

なるほど。これは辛辣な質問です。

僕は「正しさの定義」はそれぞれのチームや現場によって異なると考えています。この時にいただいた質問でも、そのような主旨の事を回答しましたが、それをもう少し具体的に書いてみよう、というのがこのエントリのテーマです。

■現場における正しさの定義は「チームメンバーが合意すること」

「gitの使い方」というような場合における「正しさ」の定義は簡単です。そのツールの仕様が、正しさの前提だからです。

では、チームでコードレビューなどをする場合における「正しさ」はどうでしょう。「正しいソースコード」などと言われても実に曖昧で、正解などないような気がします。

僕はこういう曖昧なものに正解を求める必要があった場合、「チームメンバー全員が合意する」という事を軸に考えます。

コードレビューにおける「正しさ」は、最終的にチームメンバー全員が「それで良い」と判断すれば、それが「正しいコードである」とみなします。

ペアプログラミングでのプログラマ同士の議論、あるいはチーム全体でのレビュー。こういった、度重なる議論を経て、僕たちが書いたソースコードは最終的にプロダクトとして世に放たれます。ならばチーム全員の合意を「正しさ」の定義に据えるのが、最もわかりやすい考え方ではないでしょうか。

■「チームメンバーの合意」が間違っていることもある・・・

しかしこの考え方には危うさがあります。

ここである架空の現場を想像してみましょう。

彼らは仕様書をExcelで書いており、それを以下のように管理していました。

・認証システム設計書_20131208.xls
・最新版_認証システム設計書.xls
・最新版_認証システム設計書_bkup.xls

チーム全員が合意の上で、彼らはこのような管理をしているわけですが、これは本当に「正しい」と言えるでしょうか？

現場における正しさの定義には、「チームメンバーの合意」に、もう一つ付け加える必要がありそうです。

■正しさとは、「チームメンバーが合意」しており「困っていないこと」

メンバーが合意した方法や考え方であっても、チームとしてその運用が困難であったり、なにか問題がある場合、それは正しいとは言えないでしょう。

さきほどの設計書の例で言えば、メンバーの合意があっても、結局本当の最新版はどれか、という問題が生じてしまうのであれば、それは正しいとはいえません。

チームにおける「正しさ」とは、チームメンバーが合意しており、その運用において解決すべき問題が無い状態が望ましいです。

こういう正しさの定義は、チームの成熟度によって当然変化します。

今まで問題とされていなかったような事柄が、チームの成長にしたがって問題として顕在化することもあります。その場合はチームが成長して「正しさの定義」に変化があったということですから、その問題と向き合って新しい「正しさ」を見つければよいだけのことです。

僕たちは個人ではなく、チームで仕事をしています。
で、あるならば、その中で生じるいろいろな事柄はチームとして定義されるべきです。

僕からは以上になります。

明日は@shinyorkeさんです。

いろふインスタンスの最大数を探る。

いろふアドベントカレンダー3日目です。

昨日は@kawakawa さんのirofさんとAR（拡張現実）で遊んでみよう♪ でした。

ちなみに去年はこんなの書いてました。

さて。いろふさんと言えば、複数インスタンスですよね。昨日大阪の勉強会でご一緒したと思ったら、次の日は東京にいる、とかしょっちゅうで、いろふ複数インスタンス説が唱えられて久しいわけです。

と、いうことで、いろふインスタンスははたしていくつまで作ることができるのか、僕のMBP上のScalaのREPLで試してみましょう。ちなみにREPLはなんのチューニングもしていない、デフォルト状態です。

まずはいろふクラスを作りましょう。これが、すべてのインスタンスの元になります。

case class Irof(name:String, age:String, place: String)

型がすべてStringなのは、まぁ、ご愛嬌。

とりあえず、いくつかインスタンス作ってみましょう。

val irofs = List("osaka", "tokyo", "nagoya", "hokkaido").map(Irof("hirofumi nozaki", "unknown", _))

このくらいなら余裕です。
地名を指定するのも面倒なので、とりあえずこうして1000個くらい作ってみましょうか。

val irofs = (1 to 1000).map(p => Irof("hirofumi nozaki", "unknown", p.toString))

余裕です。

どうせなら、無限の世界に突入しちゃいましょう。いろふインスタンスに上限など設けてはいけません。

def xs(n: Int): Stream[Int] = n #:: xs(n + 1)
xs(1).map(p => Irof("hirofumi nozaki", "unknown", p.toString))

無限リストのmapですから、概念上、これでいろふインスタンスは無限に存在することになります。これでこそ僕らのいろふさんです。

ぼくも執筆に加わったDevLOVE本が出版されました

昨日、DevLOVE関西 -Decision- の開催に合わせて、「開発現場に伝えたい10のこと」という電子書籍が出版されました。

開発現場に伝えたい10のこと【電子書籍】

DevLOVE関西
達人出版会
発行日: 2013-11-16
対応フォーマット: PDF, EPUB

詳細を見る

ぼくも、「第二章 アジャイルな乙女ゲーム開発のおはなし」を執筆させていただきました。

今年のゴールデンウィークに数日かけて初稿を書いていましたから、ものすごい長期プロジェクトでした。

プロジェクト自体はBacklogで管理されていて、原稿はMardown形式で書き、gitで共有されていました。各担当者からのレビュー結果などがBacklogにチケット登録され、それを反映してgitにpushしてチケットをクローズする、というエンジニアにとって取っ付き易い形で作業を進められたので、楽しかったです。

前述のとおり、原稿を書いていたのは今年のゴールデンウィークの頃ですので、今とはチームの状況や仕事の進め方など変化している部分もありますが、チームのマインドはこれを書いていた頃と何も変わっていません。

皆さんの現場について考える小さなきっかけにでもなれば、嬉しいです。

このプロジェクトを立ちあげ、長期間牽引してくれた、@papandaさん、@yohhatuさん。達人出版会の高橋さん。執筆陣の皆さん。レビューに協力してくれた弊社技術ブログライターの皆さん。ステキな挿絵を提供してくれた@issps2009さん。本当にどうもありがとうございました。

デブサミ関西へのAction #kansumi

デブサミ関西 に参加してきた。


◆ラウンジスポンサー

デブサミといえば、開発者のお祭り。いろいろ都合があわなくて、これまで参加できておらず、今回が意外にも(?) 初参加である。

そんなデブサミが今年も関西で開催されると聞き、今年こそ、と意気込んでいた。
しかし実行委員の面子を見ると、知っている人ばかり（最近は関西の勉強会で知っている人がいないものの方が少ないけど)。そういうところへ、ただの一般参加者として行くのはなんだか勿体無いなーと思った。

自分もこれまで、関西のIT系勉強会やコミュニティに対していろんな貢献をしてきたし、その発展に少なからず寄与できていると自負している。だからこそ大きなお祭りであるデブサミに参加するからには、なんらかの形で手伝いたい、と思っていた。

するとラウンジスポンサーということで、参加者の電源つき休憩スペースを確保するためのスポンサーを募集しているということだったので、その場でクリックして申し込んだ。

これで心置きなくデブサミに遊びに行ける。

◆自分戦略

やはりデブサミでの登壇は勉強会クラスタにとっての憧れだ。
去年、東京のデブサミで「公募セッション」という枠があり、一般公募されていたので応募するかどうか悩んだ。
しかし当時、同じ時期にScalaカンファレンスの開催があって、そこに登壇する予定であったので、さすがにどちらか一本に絞るべき、と思って諦めた。

そんな折、デブサミ関西で今年も自分戦略セッションがあるという。去年、盟友の@irofさんが登壇してたやつだ。

これは一般からの投票の結果、上位者に登壇機会が与えられる。当初の実行委員選抜者の中に僕の名前は無かったのだが、自薦も可、ということで応募してみた。

すると、結果はなんと1位。 投票してくださった皆さん、本当にありがとうございました。

当日の資料はこちらになります。

デブサミ関西 自分戦略 2013 from Daisuke Kasuya

◆Action!

今年のデブサミ関西のテーマは「Action!」これは今回の自分の発表でも言いたかったことなのだが、僕の今回のデブサミに対する関わり方そのものが、僕のActionだ。

僕たちITエンジニアは、少し外の世界に目を向けるだけでいろんなActionの場が存在している。僕自身、エンジニアとしてのスキルはそれほど高いわけではないけれど、こうしてイベントなどで登壇したりできているのはActionの結果だ。

コミュニティとか、勉強会とか、イベントとか、そういうところに飛び込むことへのリスクはそれほどない。僕が今回、デブサミの自分戦略に自ら手を挙げて、投票の結果登壇できなかったとしても、別に失うものなんてなにも無い。事実、今回は半分くらい自分は選ばれないだろうと思いながら応募のクリックを押した。

今回のようにうまくチャンスを与えられた場合もあれば、逆にチャレンジしてみたけれどダメだった場合も星の数ほどある。でも僕は別にその失敗の結果何一つ失ってなどいない。

なので、みんなもっと物怖じせずにいろんなチャレンジをすればいいと思う。

◆プログラマ定年

こんなチャレンジを続けた結果、今日でプログラマ定年(35歳)になったわけだが、まだプログラマを続けることができている。
（ウィッシュリストをこっそり：  http://www.amazon.co.jp/gp/registry/wishlist/ref=wish_listhttp://www.amazon.co.jp/gp/registry/wishlist/ref=wish_list)

次はやっぱり雅叙園で登壇したいなー　(/ω・＼)ﾁﾗｯ

leapmotion sdkをsbtで動かしてみた

LeapMotionを購入して、いろいろ遊んでいる。

で、SDKを見ると、javaのSDKがあったので、せっかくだからScalaで実装して遊ぼうと思い、まずはSBTでLeapMotion SDKが動く環境を作ってみた。

まずはLeapMotionのDeveloperサイトでユーザ登録し、SDKをダウンロードする。

次にSBTプロジェクトを作成し、libディレクトリに"LeapJava.jar", "libLeap.dylib", "libLeapJava.dylib"を置く。

SDKにJava用のサンプルコードが入っているので、それをScalaで書きなおす（IntelliJ IDEAでコピペしたら勝手にScalaに変換してくれるw)。

ここまでは順調に行ったのだが、僕はここで詰まった。

lib配下に置いた "libLeap.dylib", "libLeapJava.dylib"はネイティブライブラリであるので、普通のjarファイルと違ってlibに置いただけではSBTでロードすることができない。

"-Djava.library.path"で明示的にlibディレクトリを指定する必要がある。

SBTでrunコマンドを実行すると、通常はSBTが動いているのと同じJVMで実行されるから、単純に考えるとSBTの起動時に"-Djava.library.path"オプションを指定してやればよさそうなのだが、これではうまく動かなかった。

なので他の方法を。

build.scalaにいくつかの設定を加えてやることで、runコマンドでの実行時に使用するJVMをSBTが動いているのとは別のものにすることができる。

Forking

そこでbuild.scalaに以下の設定を入れてみる。

fork := true

javaOptions ++= Seq(
   "-Djava.library.path=.:./lib"
)

これで実行してみたが、コンソールからの入力を受け付けてくれず、思った通りに動かない。fork run時に、標準入出力の設定をきちんと書いてやらないといけないようだ。

そこで次の設定を追加。

connectInput in run := true

これで動いた！！

ちなみにこれらの設定を入れたsbtプロジェクトのテンプレートをgithubに上げといた。

leapmotion-sbt

さて。やっとスタートラインに立ったので、なにを作ろうかなー？

デュシャンの「大ガラス」に出会った不思議な旅

この土日に東京に行っていた。

目的は土曜日の夜に、某オフ会に参加するためだ。

彼らとは２年ほど前からの付き合いで、年に1, 2度会うだけなのだが、会えば昔からの友人同士のように語り合える。この2年、いろいろなコミュニティに参加してきたが、ここが今の僕の原点で、人生で最初に参加した「コミュニティ」でもある。

彼らとは出会う前からオンライン上の付き合いがあったためか、初めて顔を合わせた時から、旧知の友人同士のような関係が築けていたような気がする。

彼らとの出会いで、僕はIT系コミュニティという存在を知り、はじめてのライトニングトークを経験し、多くの仲間と出会えた。

去年、僕が転職した当時、このコミュニティで知り合った友人の二人が京都にいた。僕も京都の会社に就職したので、これで彼らとしょっちゅう飲みに行けるぞ、と思っていたが、結局それが叶わないまま、二人とも時期は異なるものの、仕事の都合で東京に行ってしまった。このオフ会は彼らと久しぶりに再開した場でもあった。

オフ会の主旨自体は、コミュニティのメンバーだった一人と、諸事象によりしばらく会えなくなってしまうため、その前にみんなで会おう、という集まりだった。

なんだかみんな、遠くに行っちゃうなー。そんな事を思いながら、その夜はお酒を飲んだ。

翌日。ホテルを出て、このまままっすぐ帰ろうかと思ったのだが、なにげに道路に設置されていた周辺地図を見ると、近くに大橋ジャンクションがあるというので見学して帰ろうと思った。僕は洋の東西や規模の大小を問わず、珍しい「建築物」が好きなのだ。

ひとしきり大橋ジャンクションの威容を愛でたあと、帰りの時間は特に決めていなかったので、周囲を散歩してみようと思った。

特にあてもなく住宅街を歩いていると、なにやら緑の深い一帯が見える。公園でもあるのかと思いそちらに行ってみると、そこは公園ではなくて、東大だった（笑）

駒場キャンパスだ。

一人で日曜日に大学キャンパス内を歩いていて、不審者と思われたらやっかいなので、とっとと立ち去ろうと思ったが、そういえばここにはアレがあったんじゃないか？ とある記憶が頭をよぎった。

僕はマルセル・デュシャンが大好きで、死ぬまでに必ずフィラデルフィア美術館で彼の遺作を見ようと心に決めている。そんなデュシャンの代表作『花嫁は彼女の独身者達によって裸にされて、さえも』（通称大ガラス）の東京バージョンが、駒場の美術博物館に常設されていたはずだ。

いつか観た来たいと思っていたが、東大のキャンパスやその近くに来る用事などあるはずもなく、また、わざわざこのために来るというのもはばかられていたので、ずっと機会を伺っていたのだ。

キャンパス内を探すと、美術博物館はすぐに見つかった。中に入ると、展示ホールの中央にそれはあった。去年、マン・レイの写真展で、彼の「埃の培養」という作品越しに観た、ガラス板（埃の培養に写っているのはオリジナル版で東京バージョンではない）。
あの、作品を象徴するガラスのヒビが入っていない、フラットな表面。念願の「大ガラス 東京バージョン」だ。

これを観た瞬間、すごく不思議な気持ちになった。昨夜、なんとなくさびしい気持ちでお酒を飲んで、その翌日にまったくの偶然に、ここにたどり着いた。この作品が向こうから僕に近づいてきてくれたような、そんな感覚だった。

この土日は、なんだが不思議な旅だったが、来てよかったと思った。

関西ソーシャルゲーム勉強会は超熱い勉強会だった

第4回関西ソーシャルゲーム勉強会 で発表してきました。

先日、ソーシャルゲーム会社の交流会 に参加した折に登壇の依頼をいただいてお話をしてきたのですが、想像以上に熱い勉強会でした。

80名近い人が参加する、という大盛況ぶりで「関西にソーシャルゲーム関係者ってこんなにいるのか！？」と驚きました（そりゃいるだろうけどもw）

今回はDeNAの川上さんが登壇されるということも、楽しめたポイントでした。これまで、GREEさんとか、サイバーエージェントさんの人とは他の勉強会で交流する機会がありましたが、DeNAさんの中の人とお会いするのははじめてだったので。

僕はいつものごとく「乙女ゲーム」の話をしてきました。
以前、Scalaカンファレンスで発表した際に、「発表タイトルに"乙女ゲーム"と入っていたから期待してたのに、あまり乙女ゲーム成分がなかった」というフィードバックをいただきまして、その反省を踏まえて構成を考えました。

ご依頼があればどこにでも喋りに行きますので、オファーお待ちしておりますw


今回の勉強会では、広告戦略の話などで具体的な金額の話なども飛び出し、「えっ！ そこ言っちゃうの！？」というこれぞ関西のノリ、という濃い勉強会だったと思います。おそらくは「ソーシャルゲーム関係者の集まり」という会場のコンテキストだからこそ実現できた内容なのだろうと思います。Google相手に金額交渉で値切る、というのはすごい話でしたw

懇親会は、LTを交えながらビアバッシュ形式で行われました。
僕らが普段よく参加する勉強会は、エンジニアの集まりがほとんどなので、懇親会でも技術の話が多いです。しかし、今回はデザイナさんや営業さんなど「ソーシャルゲーム」に関わるいろんな職種、業種の方が集まっていました。そのため懇親会でも、開発会社さんやデータセンター事業者さんからの売り込みがあったり、すごく新鮮な感じでした。

普段、「ソーシャルゲーム」という枠組みの中で、各社が交流する機会というのがまだまだ少ないですから、こういう懇親会もいいなー、と思います。

ソーシャルプラットフォーム各社さんも関西に進出してきていますし、もっと業界を盛り上げていきたいです。

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」 に参加しました。

DevLOVE関西「SQLアンチパターン・レトロスペクティブ関西・リターン 」 に参加しました。

「SQLアンチパターン」の監訳者である和田さん親子を招いての勉強会です。



最初に、和田卓人さん の講演で25のパターンに関する説明を受け、その後グループディスカッションで自分たちの経験を25のパターンに当てはめて議論し、最後に26個目のパターンを見つけて名前をつける、という流れでした。

個人的には「SQLアンチパターン」に書かれてある内容は、ほとんどすべて見たことがあります。実際に自分がデータベース設計をするにあたって、やってしまったパターンもいくつもありました。

ただ、最近はソーシャルゲーム開発に携わっていることもあって、あまり設計時にガチガチにER図とにらめっこすることが無くなりました。DB側で制約をつけすぎると、柔軟性が損なわれるので、DBは最低限の「入れ物」と見なす事が多いからです。

また、ORMなどを使うのであまりアプリ側でSQLを直接書いたりしませんから、複雑なSQLクエリを書いて仕事をさせる、というよりは最低限のWhere句でデータの塊をとってきて、実装側で加工することが多いです。特にScalaのコレクションAPIはそれをしやすい機能だったりするので。

そのため、最近はここに書かれているアンチパターンは、特に意図せずとも遭遇する機会が減ったなー、という印象でした。

そういう話をしていたら、「RDBネイティブとNoSQLネイティブの世代間ギャップを最近感じる」という意見が出されたりして、興味深いディスカッションになりました。

最後に、いつも会場提供くださる楽天さん、ありがとうございます！
毎回おもしろい勉強会を開催してくださるDevLOVE関西スタッフの皆さん、ありがとうございます！

上司に怒られないExcel方眼紙の作り方

Excel方眼紙 Advent Calender 2日目です。

Excel方眼紙ドキュメントには、それ自身よりもやっかいな問題があります。

それはレビューです。
Excel方眼紙はその特性上、レビューにおいては、その設計内容よりも罫線のズレだとか、印刷がはみ出るとか、本質とまったく関係ないクソみたいな指摘に終始する傾向があります。

Excel方眼紙には、制作時点で気にかけておかないといけないことが山のようにあり、これらを怠ると徹夜で方眼紙の罫線を引き直す、という謎の作業に従事させられることになるわけです。

そういったことがないよう、いくつかの注意点をみていきましょう。

１． 印刷プレビューを信じるな。

Excelの印刷プレビューはエイプリルフールのインターネットのように信用ならないものです。印刷プレビューで綺麗に枠の中に文字が収まっていたとしても油断なりません。枠線ぎりぎりの文字は、必ずはみ出ます。枠に対して、文字は余裕をもって余白を開けるようにしましょう。
Excelはワープロソフトじゃないからね！

2.  改ページの罫線に注意

ちょうど罫線が改ページに差し掛かっている場合、注意が必要です。
改ページの上側のページでは、印刷時に綺麗に線が出力されていても、下側では線が出力されないことがあります。
こういうところは、レビューする上司もまっさきに目をつけるポイントですのできちんと確認しておきましょう。
そんなことよりロジックの妥当性を見ろよ！

3. お絵かきの図は、方眼紙の枠線にあわせる

Excelでシーケン図とか、クラス図を書く場合があります。
このような場合、シーケンス図の縦線や、クラス図の四角い箱の線が、方眼紙のマス目の線と完全に一致するように書かないと、たいていの上司に怒られるはめになります。

オートシェイプを選択し、ダブルクリック。描画ツールの書式タブの[配置]を選択し、[枠線にあわせる]にチェックを入れましょう。

これで、オートシェイプは方眼紙のマス目に沿って描画されるようになるはずです。

Excelは図形描画ツールじゃねーよksg!

これらの注意点を守って、みなさんも快適なドキュメントライフを送ってください。

さて、わたしはこれからwikiに仕様書を書かないといけないので、これにて失礼！

2012年度末をもって退職しました #hogedriven

この度、株式会社HOGEDRIVENを退職することになりました。

株式会社HOGEDRIVEN

この会社にはいろいろな思い出があります。
最初に携わったプロジェクトは、「焼肉小倉優子のサイトにあるゆうこりんのプロモーション動画を再生する」という案件でした。

@irofさん、@backpaper0さん、@kiy0takaさん、@tan_go238さんといったそうそうたる顔ぶれが集結していたプロジェクトでしたが、結局誰ひとりとして動画を再生することができず、デスマプロジェクトの深淵を垣間見たものでした。

その焼肉小倉優子西中島店も、今は閉店してしまったようです。

メンバー全員、楽しく仕事をしていたわけですが、いつからか「だいくしーは老害化した」という話題を社内で聞くようになりました。

僕がSIer時代に培ったExcel方眼紙マネジメントを推進しようとした結果ですが、誰も賛同してくれなかったのです。

@tan_go238さんはカレーばかり作っているし、@kiy0takaさんはなにかにつけてGroovyを推してくるし、@backpaper0さんはPCの壁紙を新婚旅行のイタリア写真にしてドヤ顔。@s_kozakeさんに至ってはある金曜日に「この土日はドラクエ三昧ですよ」と言って帰宅したまま、二度と出社してきません。

@Posauneさんの開発環境はMacのVMware FusionでIKVM使ってC# でTwitter4jを動かす、というわけのわからない始末。

そしていつの頃からか、楽しそうにテストを書いている@irofさんの腕に輝くグリーンバンドですら、僕にとって嫉妬の対象となってしまいました。

ある日、社長の@hogedrivenに会議室に呼び出され、こんな事を言われました。
「我が社も某社の海鮮丼のような目玉が欲しい。@tan_go238のカレーをその位置に据えようと思うがどうか」というので、「カレーはもう他社がすでにやっていますよ」と答えたところ、逆切れされるという事がありました。

ぼくはこれ以上、この会社で働くことはできそうにありません。

そんなわけでHOGEDRIVEを退職し、@kuchitama さんとフリューという会社で楽しく乙女ゲームを作っていますので、みなさん今後共よろしくお願いします。

今度のhoge駆動はなぜ再演なのか？

2013年最初のhoge駆動イベントの募集がはじまりました。

ステーキ駆動 - なるほど！ザ・春の再演スペシャル！ あのステキな発表をもう一度

今回は少しいつもと趣向が違って「再演スペシャル」です。基本的にこのイベントで登壇者が発表する内容は、以前にどこかの勉強会でやった再演に限定する、というルール。

つまり、みんなの自信作、鉄板ネタが持ち寄られるはずだから、全発表バカウケ間違いなし、まさに、スベらない勉強会！！

というのはまぁ、半分冗談なんですが、なぜ僕が今回再演イベント面白そうだなーと思ったのか、その理由をちょっと書こうと思います。

コミュニティ活動に熱心なITエンジニアはいろんなところで発表機会があります。しかし、たいていはどれも一発勝負です。まれに、懇親会で飛び込みLT大会なんかがはじまって過去のLTネタを引っ張りだしてやったりする場合はありますが、やはりそれもレアケース。

一発勝負というのは少しもったいないなーと思うのです。

僕は、去年１年間と、今年のScalaカンファレンスとで、『乙女ゲームを支える技術』という発表をあちこちの勉強会で披露しました。勉強会によって枠の時間が違ったり、play勉強会とscala勉強会では内容の比重をそれぞれ向けに少し倒したりとアレンジは毎回変えていますが、たぶん6, 7回くらい、同内容の発表をしました。

毎回新作を作ることもできますが、僕は意図的に去年１年かけて、同じ発表をし続けました。毎回、顔をあわせるような勉強会の常連さんからは、「もうそろそろ、だいくしーさんの新作見たいです」と言われたりもしましたし、そう言ってくださる方には申し訳ないのですが、これは自分なりのチャレンジだったのです。

去年一年間は、新しい会社に入社した直後だし、せっかくScalaとかplayとか、面白い技術を使って、乙女ゲームという面白いサービスを作っているのだから、それのブランディングをしたいと考えました。

ひとつの勉強会に50人が集まるとして、一発勝負だと僕の発表が届くのは50人です。それを５回続けると、250人にまで拡がります。もちろん、聞いてくださる人には重複している人もいらっしゃるでしょうから、単純に250人ではないでしょうが。しかし、発表者としては同じ発表の繰り返しであっても、それを聞くほとんどの人にとっては「最初で最後の1回」なわけです。その意識を持ち続けて同じ発表を繰り返すことも、なかなかしんどいチャレンジでした。

発表者的にも再演はいろいろなメリットがあります。同じ発表でも、その時々で、ウケるポイントとか、反応が全然違ったりします。
同じ発表を、それぞれ異なる雰囲気の勉強会で、クオリティのブレなく繰り返すというのは、物凄く難しいことで、この１年で場の空気を読みながら発表の間の取り方とか、話し方を変える、というスキルを身に付けることができました。

僕自身が「再演」でいろんな得がたい経験をしたので、みんなもプレゼン力を鍛えるためにやってみるといいよ、と思って企画した「再演スペシャル」。ぜひチャレンジしてみてください！！

Scalaカンファレンスで熱気を感じた話 #scalaconfjp

3/2 土曜日に開催された Scala Conference in Japan 2013 に参加してきた。

僕が勤めている会社が、本カンファレンスでスポンサーをさせていただいた事もあり、乙女ゲーム開発の事例紹介を発表する機会も貰った。

そこで感じたいくつかのことをまとめておきたいと思う。

■お祭り感がすごかった

今日のScalaConfですがSeasar全盛期の勢いを軽く超えてた感はあります。まぁ、これは単なる煽りなので本気にしなくていいですがね。 #scalaconfjp #scalajp
— かとじゅんさん (@j5ik2o) 2013年3月2日

Scala のイベントでこれほどまで盛り上がっている現実を目の当たりにして何というか感慨深いものがありました。関わったすべての方ありがとうございました。 #scalaconfjp
— Kazuhiro Seraさん (@seratch) 2013年3月2日

「10年くらい前のJavaの熱気」わかるわー。でも、かつてのJavaはベンダー手動・標準化って流れだったけど、Scalaの今はOSSが主体になってる点でかつてよりオープンだと思う #scalaconfjp
— 蒸発プログラマさん (@yuroyoro) 2013年3月2日

今回、このカンファレンスに参加した人みんなが感じたことだと思う。
懇親会の後、@mumoshuさん、@takashima0411さんとも自由が丘の焼き鳥屋で興奮冷めやらず、同じようなことを語り合っていた。
とにかく、お祭り感というか、熱気がすごかった。

これまで、Scala使いが抱いていた、こういうお祭りへの希求とか、フラストレーションとか、そういうのが一気に爆発した感じ。
僕は「10年前のJavaの熱気」とか「Seasar全盛期の勢い」とかは体感していないのだけれど、ソフトウェア開発者として、こういう熱気の渦中に混ざることができて、とても幸福で幸運だと思った。

■紛れもなく、その日の日本のScala界の中心はあそこだった

ブログとか、Twitterとか、雑誌記事とか書籍とか、おおよそScalaという言語を日本でウォッチしていて目にしてきた人たちが、ほぼ全員あそこにいた。

これまで、Scala勉強会とか、そういうものを開催して、50人くらいの人が集まることはあった。けれどそういうところで出会う人達というのは、「Scalaに興味がある」とか「Scalaをこれから学びたい」という人達だった。もちろん、そういう人に集まってもらう意図で開催していたりするし、そういう人達と出会ってコミュニケーションをとることはとても大切なことなのだけれど、実際にScalaを使って仕事をして、同じような悩みを乗り越えてきた人達があれほど集まる場はかつてなかった。

自分たちが悩んだり乗り越えたことを、みんなも同じように乗り越えてきていて、そういう情報とか、感覚とかをあれだけの人数とともに共有できたのは凄い経験だった。

特に、ドワンゴの@mtgtoさんの発表はPlay2+Scalaという自社と同じ構成で、共感できることがとても多かった。どうしてもお話したくて、懇親会の最後で少しだけ声をかけさせてもらい、テストの話とか、今自分たちが自社の開発で悩んでいることについて話を聞けたのはなによりの収穫だった。どうもありがとうございました。

■土佐さんの発表がすごかった。

個人的に今回のカンファレンスのベスト発表は、プレゼン力という意味ではJames Roperさんの超絶ライブコーディング( & IntelliJステマ)。そして内容は土佐さんの発表だった。

三菱UFJインフォメーションテクノロジー株式会社、というお固い銀行系のシステムでのScala事例。これはこのカンファレンスの規模と内容だからこそ実現できた発表だと思う。

プログラム言語が普及するためには、ぼく個人としては、やはりNTTデータさんとか、富士通さんとか、日立さんとか、そういう"ITベンダー"と呼ばれる会社が手がける開発での導入と、そのプロジェクトでの成功が必要だと思っている。

そしてそういう会社の案件で導入されるということは、銀行とか、商社とか自治体とか、そういうところをターゲットとしたシステムで利用されるということだ。

ぼくもScalaという言語を普及するために、去年からいろいろなところで自社の事例紹介を発表してきた。しかし、いくら乙女ゲームの開発事例を紹介したところで、実際に導入した後の人達には参考になっても、これから導入しようとする人々の後押しにはならないのだ。

「フリューさんの発表面白かった。やっぱりWebアプリの開発はある程度自由にやれるんですね。羨ましいなー」そういう感想を何度も頂いた。業務系の現場で、実際にScalaを導入してもらうためには、乙女ゲーの開発事例ではダメなんだ。

そんな中、土佐さんの発表はひとつの楔を打ち込んだ発表だったと思う。懇親会でも土佐さんは、「自分はそういう役回りだと自覚して今日の発表にのぞんだ」とおっしゃていた。本当に素晴らしかった。

■ぼくの発表のこと

ぼくも自社のスポンサー枠でのセッションで、事例紹介をしてきた。

Scala conf2013 from Daisuke Kasuya

「乙女ゲームを支える技術」のファイナルエディション。
Play勉強会とか、Scala勉強会、関数型言語勉強会など、あちこちでお話してきたこの内容も、今回のイベントで一巡した感があるので、最後にしようと思う。

毎回、お話を聞いてくださった人から嬉しいフィードバックをたくさん貰った。
懇親会である方から「だいくしーさん、もうそろそろいいのでは？」とのご意見ももらったけどw

次に発表機会をいただけたら、次は新作を用意しようと思う。

■最後に

他にも、会社の同僚であり、本カンファレンスの衝撃の個人スポンサー@mumoshuさんのLTとか、いろいろありすぎてすべてをここには書ききれないけれど、本当に素晴らしいカンファレンスだった。もし、次もあるなら必ず参加したい。

スタッフのみなさん、どうもありがとうございました！！

P.S.
ぼくはなぜ『scala逆引きレシピ』を持って行かなかったんだ。。。竹添さんにサインをいただくチャンスだったというのに。。。。。。

ドラクエ7のパズルが解けんのでコード書いた。

ドラクエのバロックタワーのパズル。
図に書いても全然解けん。

で、あやぴーさんもコード書いて遊んでたので、ぼくもコード書いて解くことにした。

	// コードを読みやすいように名前をつけとこう.
	val Up = 0
	val Right = 1
	val Down = 2
	val Left = 3
	type Direction = Int
	/*
	* 石像をあらわすcase class. 像の向きを状態として持つ.
	* また、一回の動作で向きが90度回転するという振る舞いも定義.
	* moveメソッドは動きをわかりやすくするためにあえてゴリッと書いてる.
	*/
	case class StoneStatue(var direction: Direction) {
	def move: Unit = {
	direction match {
	case Up => direction = Right
	case Right => direction = Down
	case Down => direction = Left
	case Left => direction = Up
	}
	}
	}
	// 4体の石像と、その状態の初期化メソッドを定義.
	val A = StoneStatue(Up)
	val B = StoneStatue(Up)
	val C = StoneStatue(Up)
	val D = StoneStatue(Up)
	def initializeStatues = {
	A.direction = Right
	B.direction = Left
	C.direction = Up
	D.direction = Up
	}
	// ボタンを押した時の動作を定義.
	def button0: Unit = {
	A.move; C.move; D.move
	}
	def button1: Unit = {
	A.move; B.move; D.move
	}
	def button2: Unit = {
	B.move; C.move; D.move
	}
	def button3: Unit = {
	A.move; B.move; C.move
	}
	type RunOrder = List[Int]
	// (0)から(3,3,3,3,3,3)までのすべての組み合わせのリストを作る.
	// ただし,組み合わせに使用できる数字は"0,1,2,3"の4種.
	// 我ながら無茶苦茶やなこのコードw
	val runOrders:List[RunOrder] = (0 to 333333).toList.map(_.toString.toList.filter(c => c == '0' || c == '1' || c == '2' || c == '3').map(_.getNumericValue)).filter(_ != Nil)
	/*
	* 実行指示のリストを受け取り、正解の像の向きの組み合わせを抽出する.
	* 実行指示の中に正解が無ければNone.
	*/
	def solve(runOrders: List[RunOrder]): Option[RunOrder] = {
	// 最終的に正解となる像の状態を定義.
	val answer = List(Down, Left, Up, Right)
	// 4体の像をリストとして表現.(answerとの比較用)
	val statues = List(A, B, C, D)
	runOrders.find{ xs =>
	initializeStatues
	xs.foreach { n =>
	n match {
	case 0 => button0
	case 1 => button1
	case 2 => button2
	case 3 => button3
	}
	}
	statues.map(_.direction) == answer
	}
	}
	println(solve(runOrders))

view raw dq7Baroque.scala hosted with ❤ by GitHub

組み合わせを作るところで力尽きで超適当になってるけどｗｗ

とりあえず解けた。
やっと先へ進める。

飯野賢治さんのこと

木曜日の朝。なんとなく胸がムカムカして、便の調子も良くないので午前半休を取って体調を整え、午後から出社しようと思った。

そうこうするうちに寒気がひどくなり、体温を計ると39度もある。いわゆるノロウィルスとやらにやられたらしい。

数えきれないほどトイレに行き、バランスを崩してトイレのドアノブに頭を強打するなど命の危険を感じながらの闘病。

ぼくが熱を出して寝こむ時には、なぜかきまって悲しい事件がおきる。

2001年にインフルエンザで寝込んだ。9月11日。布団の中からWTCが倒壊するのを見た。

東日本大震災のあった日。熱を出して会社を早退。最初、地面が揺れているのか、自分が熱にうなされてふらふらしているのか、しばらく理解できなかった。

いいかげん眠っているのにも疲れたので、iPhoneを寒気でガタガタと震える手でつかみ、Twitterを見た。

ぼくが熱を出して寝こむ時には、なぜかきまって悲しい事件がおきる。

飯野賢治さんが亡くなった。なんということだ。

ぼくはセガ・サターンに移植された「Dの食卓」から「エネミー・ゼロ」「リアルサウンド　風のリグレット」「Dの食卓２」をプレイし、そのどれもめちゃくちゃハマった。
賛否の激しいゲームなので、なかなかこれらに「ハマった！」と一緒に感動を共有できる人と出会わないのだが、ともかくハマった。

プレイステーションエキスポの事件とか、ちょうど僕自信が多感な時期だったこともあって、最高にクールで、飯野賢治という人にあっという間に惚れた。彼の著作は全部読んだ。

映画とか、音楽とか、デザインとか、そういう分野でぼくが「お、これかっこいいな」と感じる「感覚の物差し」の大部分は、この人の影響を受けている。
僕がグッとくるものの大半は、飯野賢治的な成分を有しているものだ。具体的にそれがどういうものであるかを言語化することはできないけれど。

彼のゲーム開発のエピソードで、「会社に泊まりこみで死にかけながら開発してる」という状況に憧れ、自分がIT業界に入る動機の数%くらいはそれへの憧れがあったりもした。今思えばただのデスマーチだし、絶対泊まり込みとか嫌だけど。

ふと、自分もゲームを開発する仕事をしていることに気づいた。

「遠回りしたけど、なんとなく飯野さんと同じ仕事してるなー」と勝手に思った。

これまでは、いろんな人から影響を受けたり、なにかに感動したりする人生を歩んできたわけだけど、ぼくに影響を与えてくれた人がこうして少しずついなくなる。
つまり、ぼくが今度は、誰かに影響を与えたり、感動してもらったりする人生にシフトしなければならないんだなー。そんな気がした。

心よりご冥福をお祈りします。

※写真は新宿ロフトプラスワンのイベントで撮ってもらったやつ

勉強会初体験とその後のことをさらしてみる

明日はエンジニアのお祭り、デブサミですねー。

たぶんその流れだと思うのですが、Twitterでこんなハッシュタグが流行ってました。

#初めて参加した技術系勉強会を晒す

僕の初めての勉強会参加は、2010年のOSC神戸ですね。

今でこそ、ソーシャルゲーム開発のプログラマとしていろいろ偉そうな事を言っていますが、当時の僕はバリバリのサラリーマンエンジニアでした。

2回の転職の末に中堅SIに入社しており、そこそこ安定していたので当時勤めていた会社に定年まで在籍するものだと信じていたし、毎月のように会社の偉い人とか上長とゴルフに行ったり、社内で出世してやるぜー、とか思ってました。

その反面、自分のキャリアがどんどんマネジメント的な色合いを帯び始め、「現場技術はオフショアでいけるんじゃね？」な流れに違和感も持っていたり、なんとなくモヤモヤする日々を送っていました。

SIという業界が、その頃からなんとなく閉塞感につつまれ、なんとかしないとな、という流れの中で、僕もいろいろな試みをしました。

OpenPNEを使って社内SNSを立ちあげたり、Redmineを導入してみたり。
なにかきっかけをつかもうと、思い付く限り新しいことをやってました。

そんな流れの中で、OSS界隈の情報収集をしよう、と出かけたのがOSC神戸だったかと思います。

いくつかのセッションに参加し、こんな世界があるんだ、と思いました。

どういう論理展開でそう思ったのか、はっきりと覚えてないですが、それまで、なんとなく「ひょっとしたら自分はこの会社で定年までいられないかもな」と思っていた気持ちと相まって、会社に依存するのではなく、エンジニアとして、どこに行っても通用するバリューがあれば、幸せになれるんじゃないかな、と思い始めました。

その後、7月に@ITの読者コラムニスト募集に応募して、エンジニアライフにコラムを書いたり、そのオフ会で初LTをしたり、社外活動の比重を増やして行きました。

少なくとも、勉強会という世界に出会わなければ自分の人生は今とはまったく違っていたのは確かです。

半分酔っ払って書いているので支離滅裂な文章になっているかもしれませんが、僕の勉強会初体験はこんな感じ。

勉強会勉強会の中の人やってきました。

DevLOVE関西 勉強会勉強会 のスタッフとして、開催のお手伝いをさせていただきました。

* まとめ：http://togetter.com/li/452510?page=1

元々、勉強会文化を拡げていきたいという思いもあるので、こういうメタな勉強会は何度か参加してきました。

* 勉強会初心者向け勉強会：http://daiksy.blogspot.jp/2012/02/study4bg.html
* ITコミュニティ祭り：http://daiksy.blogspot.jp/2011/09/it.html

勉強会の主催者は、みんな同じような悩みをもっています。

会場どうやって探すの？
スピーカーってどうやって呼ぶの？
ドタキャンで会場費が赤になるのコワイ  etc...

このパターンだと、スピーカーのコネはあるけど会場のあてがない人と、会場提供できるけどスピーカーのコネがない人が組めば問題はある程度解決するわけで、そういう情報共有とかしたいなー、というのを常々思っていました。

そこで、今回は皆さんのそういう疑問とか悩みを共有して解決しよう、というビアバッシュ形式のコーナーを設け、僕はそこでファシリテータを担当させていただきました。

うまく場をコントロールできたかわかりませんが、他のスタッフさんとか、参加者さんのフォローもいただき、なかなか盛り上がったのではないかと思います。

会場提供してくださった楽天さん。スタッフの皆さん、参加者の皆さん、どうもありがとうございました。

SIを卒業して1年経ったので振り返ってみる

2月1日で、転職してちょうど１年が経ちました。

受託開発なSIの世界から、コンシューマ向けの開発をする事業会社に転職して1年間過ごしてきたわけですが、正味のところどうだったのか、ちょっと振り返ってみたいと思います。

■転職理由はすべて叶えられたか？

僕が転職を決意したのは、以下の様な理由からでした。

・キャリアとか、収入とか、もろもろ含めた将来への不安

僕が転職を決意した頃のSIer界隈に漂う閉塞感は凄まじいものがありました。SIといってもいろいろな事業領域がありますから、あくまでも僕が携わる範囲の話ではありますが、ぶっちゃけ給料は下がりましたし、その影響で自動車を手放したりしました。
っていうか、いつまでリーマン・ショックががが、とか言ってるのかと。

・会社員ではなく、エンジニアでありたかった

SIの閉塞感、という話にも関連しますが、会社に依存する生き方では幸せになれないな、と思うようになりました。社外の勉強会やコミュニティに参加することで、その思いはより強くなりました。
フリーになる、とか起業する、という選択肢は自分には今のところないのですが、世の中が変化した際に、それに合わせて自分の立ち位置をフレキシブルに変えられる生き方をするのが、幸せになれるポイントかな、と思うようになりました。
そのためには、僕個人のバリューを高める必要があります。
自分がエンジニアとして高いレベルに成長するには、高いレベルのエンジニアたちが集まる場所で戦う必要がある、と思いました。
勉強会でレベルの高い人たちと関わって、刺激を受けるうちにそれをより強く確信しました。勉強会で刺激を受けているだけではダメだ。仕事という、一日のうち多くの時間を費やす場所で、こういう人たちと関わっていなければ、と。

・コンシューマを相手に仕事をしたくなった

これは完全に自分の趣味の問題なのですが、もっとマスの大きい仕事をしたいなと考えました。受託開発であっても、エンドユーザと直接やりとりをする仕事は楽しかったのですが、そのエンドユーザがもっと大勢いたらさらに楽しいのではないか、と思ったのです。
Twitterやブログなどで、多くの人から反応があった時の気持ちよさを仕事でも味わいたい、とも思いました。

⇒　今のところ、上記の希望はすべてかなっています。

乙女ゲーの開発に携わることで、今までとは比べものにならないほど大勢のユーザさんに自分の作ったゲームで遊んでもらっていますし、チームのメンバーはみんな高いレベルで仕事をしていますし、収入も増えました。

■ 勉強会やコミュニティ活動について

転職してからの1年間で、自分の価値観やライフスタイルに決して小さくない変化がいろいろありましたが、最も考え方が変化したのは、勉強会やコミュニティ活動についてです。

以前まで、僕にとって勉強会は映画館のようなものでした。
休みの日に出かけて、ファンタジーの世界に触れて、気分がよくなって現実に戻る、というそんな感じ。
自分もスクリーンの中に入りたくて、発表したり、記事を書いたりもするのですが、やはりそこは日常とは少し切り離された世界である、という感覚でした。

そうして活動を続けているうちに、いつしか懇親会などで「お会いしたいと思ってました」とか「おお！ 本物のだいくしーさんだ！」とか言ってもらえるようになりました。

去年の11月。DevLOVE関西で登壇する機会をいただき、自社の開発事例を発表しました。そのときにふと感じたことがあります。

2010年3月のOSC神戸。そこでいくつかのセッションを見た時、そこで登壇するエンジニアは雲の上の人でした。ああいうところで発表するエンジニアは、どんな人たちなんだろう。どんな世界が見えてるんだろう。
これが、僕が社外活動に参加しようと思った原点です。

DevLOVEという大きな勉強会で、50人の人の前で40分も喋っている。OSC神戸で自分が憧れたあっち側に、今まさに立ってるじゃないか。

去年１年、いろいろなことがありましたが、これは自分の中ですごく大きな出来事でした。

僕にとって「映画館」だった勉強会は、いつしか日常と地続きになっていたのです。

日常と地続きで社外活動をするためには、仕事においてもエンジニアとして充実していたほうが楽しいに決まっています。去年はいくつかの勉強会で、自社の事例紹介などもさせてもらいましたが、職場と、外の世界との地続き感は今後もこだわっていきたいと思っています。

■次の１年

この1年、Scalaとか、Playframeworkとか、アジャイルとか、とにかく未経験のことばかりでした。ようやく日常の業務もそつなくこなせるようになってきましたので、そろそろプラスアルファを考えたいな、と思っています。

一時は、勉強会参加を少し控えて、軸足を会社業務に大きく移そうかとも思ったのですが、そこはやはり両輪バランス良くやるほうがいいな、と考えを改めました。

個人的にはエンジニアとしての地力を鍛えつつ、社外でも何か去年の鹿駆動並に面白いことができたらなー、と思っています。

今年もよろしくお願いします。

他人のレベルが低いと思うのなら、自分の物差しのサイズをまずは疑え

どういう流れかよくわかってないのだけど、なにやらTwitterのタイムラインで大企業をdisってる感じのツイートを見かけたのだけど、これについて言いたいことがある。

IT業界で仕事をしていると、時々こういう場面によく出くわすんだよね。

「元請けベンダーが仕事してない」
「オレはITゼネコンで働いてるやつらより仕事できるはず」

その気持ちはすごくよく分かる。でもちょっと待って欲しい。
本当に君から見たその人達は、レベルが低い人なのか？

ひょっとしたら、自分の物差しが、その人のサイズを正確に測れるレベルに達してないだけなんじゃないか？

なぜ、そんな事を言うのかというと、僕自身が自分の物差しのサイズを強烈に意識した経験があるからだ。

僕は新卒で、社員20人ほどのITの会社で働いていた。仕事のほとんどは、特定派遣だ。
客先に常駐して、ITベンダーの指示に従ってシステム開発の末端に従事する仕事。

そこでは僕は「優秀な人」という評価を得ており、正直調子に乗っていた。

ITゼネコンと呼ばれる、大きな会社で働くSEよりも、自分はうまく仕事をやれる。だって現場では、高評価を得ているじゃないか。

そしてしばらくして、僕は転職することになる。ITゼネコンとまでは言わないまでも、社員500人ほどの中堅SIだ。

そこで働きはじめた当初、僕は自分のスキルがまったくここで仕事をするレベルで無いことを思い知る。

客先に常駐して、常駐先企業が受注した仕事のプログラムを組むことと、エンドユーザと相対して、自分たちで成果責任を負って開発を進める仕事では、必要なスキルや、やるべきことが大きく違う。

僕がかつて、「レベルが低い」と思っていた人たちは、僕の物差しで測れる範囲ではなく、もっと違う次元で戦っていたのだ。

立場が変われば観測される世界は異なるし、その世界のサイズを測るための物差しの種類も変わる。

自分の物差しで、あるサイズを測って、「この物体の幅は狭いなー」と思っても、実はその物体はとてつもなく縦方向に長い物体で、自分の物差しはその高さを測れないから最初から目に入らない。そういうことが世の中にはたくさんある。

大企業の人がレベル低いとか絶対に無いって。
大学入試とか、就職活動とか、そういう時点から勝ちを積み重ねた人たちなんだから。

そういう人を安易にdisってしまうと、自分の懐の狭さをさらけ出してしまうだけだと思うんだ。それはとっても恥ずかしいことなんだよ。

僕もたまにdisっちゃうことあるけどね。