Bye Bye "ByVal". Hello "public static void Main". 〜転職してました〜

数ヶ月ぶりのエントリになってしまいました。すでに id:yujiorama さんに現職の社名を明かされてしまったのですが、今年の3/1からグロースエクスパートナーズ株式会社（以下GxP）で働いています。
今はVB.NETを離れ、C#でたのしく仕事をしています。

ここでは、転職の経緯ではなく、GxPで3ヶ月働いてみて感じたことを書いてみようかと思います。

SIerのあるべき姿とは

僕にとってのSIerのあるべき姿というのは、お客様のビジネスをITの面で支援する。支援するだけでなく、成長のための推進力を提供するというものであります。
そのために、できることをやるだけでなく、できることを増やし、より良い手段を提供していくことが大事だと思っています。
そう。僕は「SIerは、お客様のパートナーであるべき」だと思っているのです。「共に成長する間柄であるべき」だと思っているのです。
前職では、結局そうしたパートナーとしての立場をとることができませんでした。その一端は、自分の振る舞いにあったかもしれません。

GxPは、その社名の通り、お客様のパートナーとして、ITのプロとして、お客様と共に考え行動していってる会社だと日々感じております。実際、僕もあるプロジェクトでは、システムの改修に携わりながら業務内容を読み解き、あるべき姿をお客様と共に考えるようにしていました。

どこまでも成長していける

いわゆる二次受け、三次受けの仕事をしていると、上から降ってきた仕様通りに作ることが求められ、自分の判断というものはなかなか入れられないように思えます。
プライムの案件だとしても、時と場所によっては「社内標準」と呼ばれるプロセス通りに動くことが求められ、改善の行動を起こすことが難しい場所もあるでしょう。そうしたマインドがない場所だってあることでしょう。
そうした環境では、たとえ情報処理技術者試験の高度を取ろうが、いくらファシリテーションや思考ツールを学ぼうが、それらを活かせる場面というのは、かなり限定されてしまうように思うのです。
また、スキルというのは場数をこなすことで磨かれていくものだと思っています。それはプログラムを書くことから、飲み会の幹事まで、ありとあらゆるところに言えることだと思います。

GxPに移ってから感じたことは、自分が望めば、こうしたスキルをどこまでも伸ばしていける環境にあるということです。ただし、自発的に動くことと、動いた分の責任は求められます。
実際、ただ上からの指示に基いて動くような思考では、かなり苦しむことでしょう。

愉快な仲間たち

「エンジニアマインド」の系譜に連なる者として、やはり誰と働くかは重要なポイントとして挙げたいですね。どんなに優れたエンジニアと仕事をしていても、趣味嗜好がまったく合わないと、その職場で働くのは辛いものだと思います。
GxPには、コミュニティに参加していない方も大勢います。でも、なぜだか知らないけど、コミュニティ界隈の方々に負けず劣らず、濃ゆいキャラクターの人が大勢います。趣味や知識の範囲もそれぞれ違うのですが、それがうまい具合にオーバーラップしてて、ランチのときなど話していて楽しいですね。

厳しい面ももちろんある

GxPに入ってから求められていることの一つに、「きちんとした理由をもつ」ことがあります。アーキテクチャ選定だけでなく、個々の作業の見積りであったり、バグ修正でハマったりしたときなど、「なぜこれがベストだと思うのか」「なぜこれだけの時間がかかるのか」「何がわかっていて、何がわかっていないのか」「失敗したときにどうやってリカバリーするのか」といったことに対して、きちんとした理由を求められます。そのために、ちゃんと考えることが求められます。
ゆるふわなノリで社内システムを作ったり、「使ってみたいから」という理由だけで、特定の言語を使ったりするような自由はないですね。
この辺り、とても厳しいです。当たり前と言えば当たり前なのでしょう。実際、この三ヶ月で少しは鍛えられたように思えます。

この環境を求めていたんだよ！

転職する前は、コミュニティで見聞きする「楽しい開発現場」に憧れ、その理想と現実のギャップにずっと苛まれていたように思います。そのギャップの圧倒的な開きに絶望することもありました。
ですが、GxPに移ったことで、こうしたギャップはなくなりました。もちろん、バグに悩んだり、納期に追われたり、たくさんのお客様要望に応えなければいけなかったりする場面は往々にしてあります。
でも、それはきっとスタープレーヤー揃いのチームでも起き得ることでしょう。
大事なことは、自分の価値観に照らして、誇りと自信を持って仕事ができるか・できているか。これだけなのかもしれません。
それが人によってはソーシャルゲーム開発かもしれませんし、ECサイト運営かもしれません。僕のようにSIが性にあっていることもあるでしょう。
今回、転職活動をしていたなかで一番考えたことはここでした。たくさん悩んで、たくさん苦しんで、たくさん迷いました。そのなかで、コミュニティ活動を通して近い距離にあり、また、マインドが近かったGxPにお世話になることとなりました。

思えば、IT業界を目指すきっかけとなったのが東大坂村教授の著書。これまで読んだ技術書のなかで一番影響を受けた本の訳者が今野睦さん。コミュニティで最初に書いたマインドマップは和智右佳さんの講演。福井厚さん・小井土亨さん率いるVSUGのアーキテクトアカデミーで拝聴した榊原彰さん・平鍋健児さんの講演に感銘を受けたし、鈴木雄介さんの講演からはアーキテクチャの考え方の基礎を学んだように思えます。
他にも大勢の方から影響を受けました。その多くは”アーキテクト”と呼ばれる方々でありました。GxPに縁があったのも、ある意味”運命”だったのでしょう。

最後に

今回は、多くの人のお世話になりました。ときに迷惑をかけたりすることもありました。あまりの苦しさで吐露してしまった叫びに嫌悪された方もいたとも聞きました。
この場を借りて御礼とお詫びを申し上げます。
自ら望めば、どこまでも成長できる環境に移れたことを機会として、日々の仕事に精進して参ります。そのなかで得た学びも、いろいろな場面でお伝えできたらと思っています。
至らない点は多々ありますが、皆様、これからも引き続き宜しくお願い致します。

こんまり先生の「片付けの魔法」は凄かった。

あけましておめでとうございます。今年もよろしくお願いします。

さて、昨年12月頃Amazon Kindleのセール本でこんまり先生こと近藤麻理恵さんの「人生がときめく片付けの魔法」がラインナップされていました。

人生がときめく片づけの魔法

前々から「部屋を片付けたい」と思っていたところにセール扱いでたった400円で買えるとなれば衝動買いバンザイってことでポチったわけでございます。
それで、こんまり先生の教え（こんまりメソッド）に従って部屋の片付けをやりました。

こんまりメソッドのざっくり解説

こんまりメソッドは「モノに対するときめきセンサー」の精度を高めていきながら一気に完璧に片付けていくという手法です。
「ときめき」って何と聞かれると説明するのは難しいのですが、あえていえば「これは自分の生活に必要なものだ」という感覚でしょうか。

この「ときめきセンサー」を高めていくには「場所ごとに片付ける」のではなく「モノの種類ごとに片付けていく」のが大事だとしています。
その「モノの種類」は衣類=>書籍=>書類=>小物=>思い出物がいいとしています。この各種類のなかにはさらに分類があるようです。
これらの種類ごとに「ときめく」「ときめかない」を基準にして残すものと残さないものを分けていくのがこんまりメソッドの基本です。

また、こんまりメソッドのなかには「本は開かない」「服は縦置きできるように畳む」といったプラクティスも数多くあります。

こんまりメソッドを実践する

ということで、こんまりメソッドを実践しての部屋の片付けを開始しました。自分の場合は最初に分類できる場所を作るためのモノの移動から。これはこんまりメソッドではなく普段の自分の片付けをしました。
分類できる場所ができたらこんまりメソッドを実践していきます。まずは衣類から。クローゼットからすべての衣類を引っ張りだしてときめくもの・ときめかないものを分類。
ときめかないものはゴミ袋に納め、ときめくものをクローゼットに再度収納。続いて書籍、書類、小物、思い出物と行なっていきます。

中には10年以上前の高校時代に友人からもらった書簡なんてものもあったり。痛すぎたし消したい過去だったので破棄しました。
マンガや小説本・ビジネス書は「面白かったけどいまは読まないなぁー」という本はブックオフに行って新しい持ち主を探してもらうことにしました。
その中には未読本も。買った瞬間はときめいたけど、今は他に読みたい本がたくさんあるので「多分読む機会はこないなぁ」ということで去って頂くことにしました。

こんまりメソッドの実践結果

そんな感じで分類した結果、ゴミ袋7袋・ブックオフ行き書籍が500mlペットボトル48本が入っていたダンボール1箱分・廃棄雑誌類が先のダンボールの半分サイズで1.5箱分。
もう見ないやという某バラエティ番組のDVD-BOXも合わせてブックオフに持ち込んだら5000円を超える値がついてびっくりしました。

また、クローゼットに収容しれないほどあった衣服がクローゼットに収まるようになったり、本も全て収納棚に収まるようになりました。その他の小物も全部収納することができました。
ひょっとしたら僕らは、部屋の収納力というのを無意識化で知っており、こんまりメソッドを行うことで、その無意識に知っている部屋の収納力に合わせて分類を行なっているのかもしれません。

かかった時間は6畳弱の部屋を片付けるのに約10時間。ただし未着手の場所が数カ所あるので、完璧にやるには丸一日以上かかると思っていいでしょう。

こんまりメソッドをITエンジニア向けにアレンジする

さて、（いい意味で）意識高いITエンジニアの場合、ガジェットやアニメのDVD-BOX、技術書が部屋のなかで多くを占めているかと思います。
これらも基本は「ときめきセンサー」に基いての分類ができるかと思います。ただ、技術書に関してはちょっと違ったセンサーが必要になるかもしれません。
というのも技術書はこれからの学習やリファレンスとして使うことがほとんど。しかもモノによっては絶版になっていたりする場合もあります。（パターン指向リファクタリング入門とか）
僕個人としては、技術書に関しては「仕事で使う機会があるかないか」という感覚で分類していくといいのではないかなと思うのです。

例えば転職を経て扱う言語やミドルウェアが変わった場合、それ以前に扱っていた言語・ミドルウェアの技術書は必要になるのでしょうか。近い将来元の言語・フレームワークを扱う可能性があるのならば、残しておく価値はあると思いますが、一方で「もう戻らない」と決意しているのであれば電脳書房さんに引き取ってもらうといいかもしれません。
言語やミドルウェアの場合、新しいバージョンに合わせて新しい技術書が出るので手放すリスクは低いでしょう。仮に必要になったら最新バージョンの本を買えばいいでしょう。

一方、アーキテクチャや設計技法・開発プロセスといったものは10年くらいは価値が変わらないと思います。（事実、リファクタリングや達人プログラマーといった名著はAmazonマーケットプレイスでは値下がりしていない）
こうした本の内容は言語やフレームワーク側でどんどん吸収されていくでしょう。しかし、教養として知っておいた方がいいなんて場合もあるかもしれません。
自分の場合、この種類の本は未読でも大半を残すようにしました。

ガジェット類に関しては、新しいものがどんどん出てくる世の中なので「使わない」となれば売却していいかと思います。使わないのに保有し続けることで売却金額が下がっていく上に保有コストが高くつくからです。

アニメのDVD-BOXは思い入れのあるものであれば残しておいていいのではないでしょうか。一方で「見たくなったらTSUTAYAで借りたりネットで見ればいいや」という割り切りができれば、売却していいかと思います。（自分は龍馬伝のBD-BOXを残しました）

まとめ

というわけで、こんまりメソッドを実践したおかげで部屋がちらかり、足の踏み場がなくなるということはなくなりました（少なくとも1週間以上は継続）
また、今までモノが積み重なっていた机が執務スペースとして復活を遂げました。
まだもう少し整理したいと思っていたりするのですが（特にコード類がヤバイ）、こんまりメソッドを実践することで、自室で過ごす時間が気持よくなりました。

部屋がちらかってる・モノが多いと嘆いている方はこんまりメソッドを実践してみてはいかがでしょうか。（Kindle版でたった800円の投資で済みます）

ちなみに、本の文体は今どきのちょっと自信なさげなんだけど「私頑張る」的なちょっとテンション高めの妙齢の女性といった感じでした。人によっては萌えるかもしれません。（というかちょっと萌えた）

変態ライトニングトーカーが編み出したプレゼンメイキング手法

このエントリは、変態アドベントカレンダー2012の2日目です。一日目は@daiksyさんの「文字列の変態力を計ってみよう。」でした。
2010年末のDevLOVE HangerFlightの場でライトニングトークに初挑戦して以来、プレゼンというものにのめりこんでしまった私です。これまで数えきれないくらいのライトニングトークをやってきました。
今年の4月には、能の舞台でライトニングトークができると知って、わざわざ奈良まで出向きました。
また、誰かのまえで自分の考えを発表することに味をしめた結果、エンジニアライフでコラムを書きはじました。
結果、自分の考えを表に出すことが快感になっていた、ある種の変態となった自分ができあがりました。
その自分の考えをどうやって表に出すか。そのために使っていたプレゼンの作り方の変遷を、そして自分が編み出したプレゼンメイキングの手法を書いてみようと思います。

※要するに、今回の話自体は変態でもなんでもないのですが、プレゼンをやりまくっていた自分自身がある種の変態ということで、変態アドベントカレンダーの基準を満たそうとしました。よろしくおねがいします。

最初の手法 マインドマップ

プレゼン資料を作る上で最初に使っていたのは「マインドマップ」でした。
マインドマップは

描き方は、表現したい概念の中心となるキーワードやイメージを中央に置き、そこから放射状にキーワードやイメージを広げ、つなげていく。思考を整理し、発想を豊かにし、記憶力を高めるために、想像 (imagination) と連想 (association) を用いて思考を展開する。
(Wikipedia)

という手法です。
2010年末当時、自分は参加した勉強会のまとめをマインドマップで書いてこのブログで公開していたりしました。
そのため、マインドマップ自体は書き慣れており、プレゼンで何を話すか構造的に書き上げるのに一番使いやすいツールでした。
そんなわけで、2011年後半から2011年末くらいにかけてのライトニングトークの資料を作っていた時期は、マインドマップで資料のアウトラインを作っていき、それをスライドに落としこむようなやり方をしていました。

第二の手法 ふせん並び替え

ですが、マインドマップをメインで使っていたのは、2012年のはじめのころまででした。いつしか、マインドマップを書くためのペンやスケッチブックを持ち歩くことが億劫になり（荷物が多かったり、スケッチブックが大きかったせいで）、マインドマップを書く機会が減ってきました。
その代わりに自分のなかで台頭してきたのが、ふせんを使ってネタをまとめるやりかたでした。
この方法を知ったのはプレゼンテーションZENがきっかけでした。この本のなかで「プレゼンの話のアイデアを練るのにふせんを使ってどんどん書き出すといいよ」といったことが書いてあり、それを試してみたところハマったのです。

プレゼンテーションzen

それまでマインドマップを使って資料を作る際は、頭の中である程度の構想を練ってから書き出すようなやり方をしていました。
ですが、ふせんを使うことで、構想のねり方が少しざっくりになりました。
マインドマップ自体、発想法の要素を持っています。ですが、自分にとってはふせんを使ったほうがより自由に発想できる感触がありました。
そうして自由に思いついた要素を並び替えて、資料を作るようになりました。また、この方法を使って何本ものコラムも書き上げていました。
しかし、この方法は場所を取ります。ふせん自体ある程度の大きさがないと書くのが辛く、また十数枚のふせんを並べるので、ある程度の場所がないと使えませんでした。

編み出した手法 3の累乗で構造化する

そんななかで、資料作りに追い込まれる出来事がありました。それは、2012年10月に登壇した「勉強会初心者のための勉強会」の資料を作ろうとしていたときのことでした。このときは45分のセッション時間を頂いていたのですが、仕事などが忙しく、前日まで資料作りに着手できていませんでした。
構想自体は練っていたものの、書き出す場所がない。ただ、仕事中で移動する時間があって、手帳にネタを書ける程度の余裕はありました。
この時に使ったのが3の累乗で、ネタを構造化するやり方でした。
なぜ、3の累乗なのか。テレビ番組でもおなじみ池上彰さんの著書「わかりやすく＜伝える＞技術」のなかで、こう説明されています。

わかりやすく〈伝える〉技術 (講談社現代新書)

人は、たいてい三つまでなら耳を傾けて聞きます。それが、四つになると注意が拡散します。話し手も内容を把握しづらくなってしまいます。
人間がメモなしで話せるのは、たいていは三つのことまでです。聞き手のほうも、頭の中でとりあえず整理して覚えられるのは三つまで。不思議なもので「三つあります」と言われると安心するのです。

大きな三つのテーマについて30分ずつ話す。
その30分の大きなテーマを説明するために、それぞれ小見出しを三つ立て、10分づつ話していく。
すべてを三つに分けて整理していくと、聞き手にもわかりやすくなりますし、話をしやすくなります。

この三つまでというルールを覚えていた自分は、話したいテーマを3つ。そこで取り上げるトピックを各テーマごとに3つ。そのトピックを説明するのに使うエピソードや、訴えたいことを3つ。合計すると27個の話題になります。これをそれぞれ1分で説明。そのほかに自己紹介やまとめ。質疑応答で合計45分。という計画を立てたのです。
実際はこれらの話題に対して話すことを3つ。それぞれ20秒で収まるようにしました。
こうすることで、45分のセッションを無事成功させることができました。
そして、この手法の利点に気が付きました。

3の累乗でスケールしていくネタ作り

この方法は5分のLTから45分のセッション。もちろんコラムでもブログのエントリでも使うことができます。
5分のLTなら話したいテーマを一つ。そこでとりあげるトピックを3つ。そのなかで話すことを3つ。話すこと一つにつき30秒とすれば、合計で4分30秒。自己紹介も含めて5分で収まるようになります。
一つ30秒で刻めるので、しっかり時間ちょうどで終えることもできるでしょう。
45分のセッションなら先ほど挙げたとおりテーマを3つ。そのなかのトピック・エピソード・説明と3つづつ用意していくことで81の説明を各20秒〜30秒。自己紹介や質疑応答を含めれば45分に収まるボリュームとなります。
さらに長いセッションになれば、テーマ3つを束ねる大きなテーマを用意すればスケールさせることができます。
どんな時間のセッションであっても対応可能な方法が、この3の累乗でネタを作っていく方法なのです。

ネタ出しはマインドマップでもふせんでもノートでもOK

そして、この方法はあくまで構造化のルールです。実際にネタを作っていくのはマインドマップでもふせんでも、ノートの行を使っていくのでもいいのです。
ちなみに、このエントリのネタ出しはふせんを使ってやっています。マインドマップ・ふせん・3の累乗。それぞれの方法の利点を3つ出すことで、構造化させました。

LTのネタ作りや、こうしたアドベントカレンダーのネタ作り。直前になって考えるのは大変ですが、こうした思考の枠組みをつかうことで、そうした大変さを軽減することができます。
2012年末は昨年に比べてさらに多くの技術系アドベントカレンダーが行われています。そうした場でネタを書くのに苦しんでるそこのあなた。こうしたやり方でネタを作ってみてはいかがでしょうか？

ということで、僕のエントリはここまで。明日は@backpaper0さんです。僕みたいなガチエントリでなく、いたって変態なエントリを書いてくれることでしょう。楽しみにしております。

.NETでスキャナを扱うためのTWAINライブラリ

結論から言うと、TwainDotNetを使うのが一番幸せになれそうだなということなんですけどね。
twaindotnet - A TWAIN library for the .net platform. - Google Project Hosting

ネット上の日本語情報にあたってみたけれど・・・

今月に入ってから、仕事で.NETからスキャナを扱うことをしていました。
たぶんライブラリあるだろうなぁと調べてみたのですが、なかなか情報が少なく・・・。
有料のコンポーネントもいろいろあるようですが、オープンソースのライブラリで日本語情報としてあったのがこの２つ。助かりました。

C#でTWAINを操作してみる - ニヤリ TechSide
.netでTWAINスキャナから画像の取込(実践編) | .log

ということで、この2つの情報をもとに.NET TWAIN image scannerを使ってみたのです。
.NET TWAIN image scanner - CodeProject

このソースはだいぶ古く、.NET 1.1のころのもののようです。
ですが、.NET 4.0に普通にコンバートしてくれたのでしばらく使っていました。
それで分かったのですが、このライブラリ・・・というかラッパーは、結構使いづらいなということでした。
まずい点としては、

• リソースの解放を自力でやらなければいけない。
• メッセージポンプの実装が必要になるので、それなりの量のグルーコードを書かなければいけない。

の2つです。
特にリソースの解放に関しては、ポインタのない世界で生きてきた自分には苦しくて。。。

リソース解放の方法を調べていたら見つけたデキル奴

そんなわけで、うまいことリソース解放できる仕組みを作ろうと思ってグーグル先生にいろいろ聞いてみました。そこで見つけたのが、上記で紹介したTwainDotNetでした。
このライブラリは.NET TWAIN image scannerに対して、制御用のメソッドを数多く加えています。リソース制御もきっちりやってくれています。
そのおかげで、AccessViolationExceptionが発生しないようになりました。

また、TWAIN DriverのUI表示や画像の回転を指定する際にTWAINのソースをいじくる必要もありませんでした。

実際のところ、このライブラリ一つで十分実用に耐えうると感じています。
細かい使い方に関しては、TwainDotNetのサンプルプロジェクトを参照してください。
/ - twaindotnet - A TWAIN library for the .net platform. - Google Project Hosting

ITエンジニアの生き様を見よ！「ITコミュニティ秋祭り・リターンズ」の見どころを妄想紹介 全登壇者のスライド付

僕が企画で関わっている「ITコミュニティ秋祭り・リターンズ」というイベントが10/5にお台場の東京カルチャーカルチャーで開催されます。
ITコミュニティ秋祭り・リターンズ TOKYO CULTURE CULTURE：@nifty
今日はこのイベントの見どころについて、勝手に"妄想"してみたいと思います。

コミュニティに参加したら人生変わった

第一部のパネルディスカッション、前半は「コミュニティに参加したら人生変わった」と題してお届けします。
登壇者の一人、@kashew_nutsさんは、昨年のITコミュニティ夏祭りの参加者。そのITコミュニティ夏祭りに参加してから、Pythonの勉強会などに通うようになりました。彼はこの１年間で何を感じたのでしょうか。
その@kashew_nutsさんを支えいじくるのが、DevLOVEからは@papandaさん・@bash0c7さん。さらにRubyistの@sugamasaoさんに高専カンファレンスから@june29さん。
ITコミュニティ界のトップランナーである彼らもまた、コミュニティ初心者な時代がありました。そんな彼らはこれまで何に触れ、何を想い、ここまできたのでしょうか。コミュニティに関わり続けたエンジニア達の人生はどのようなものだったのでしょうか。そして、彼らはどこに向かおうとしているのでしょうか。

20111206 GLT vol.40 from Kashun Yoshida

moon and strategy from toshihiro ichitani

闇RubyKaigi from suga masao

Over The Rainbow from Jun OHWADA

発表したらさらに人生が変わった

パネルディスカッション、後半は「発表したら世界がもっと変わった」
GLT代表の@do_akiさんに、Yokohama.rb / アジャイルサムライ道場からは@joker1007さん、DevLOVEからは@quindim、エンジニアライフから@daiksyさん、そしてRubyistの@igaiga555さんが登壇。
昨年のITコミュニティ夏祭りでジョジョLTを披露していただいた@daiksyさんと、関東が誇るジョジョエバンジェリストの@joker1007さんがついに夢の競演を果たします。
そこに素晴らしきPHP LTをされる@do_akiさん、XP祭り2010でカポエイラの実演LTをされ、会場をわき上がらせた@quindimさん、そしてスタートアップRubyの出版まで果たした@igaiga555さんが加わります。
このパネルの登壇者の方々は、皆コミュニティでの発表を通して人生を切り開いてきた人たちです。そんな彼らのトークに、エンジニアとしての生き方のヒントが得られるのではないでしょうか。

JoJoに学ぶプログラマが知るべきたった一つのこと from Daisuke Kasuya

ゆるLTのススメ+α from joker1007

Php in ruby from do_aki

たのしい開発 スタートアップRuby

ITコミュニティオールスターと話せるよ

そうしたITコミュニティのオールスターが揃ったとでも言うべき第一部のパネルディスカッション。
そこに登壇する方々が客席に降りてきて参加者のみなさんと渾身するのが第2部 コミュニティお悩み相談室（野良バージョン）です。
日頃思っていることを語れるチャンスです。思いの丈を語り尽くしてください！

チケットはイープラスでお買い求めを！

この「ITコミュニティ秋祭り・リターンズ」は勉強会ではありません。お祭りです。ITエンジニアの生き様を肴にお酒を酌み交わすお祭りです。
なので入場にもちょっとばかしお金がかかってしまいます。

入場チケットは前売り1500円でイープラスにて販売。入場の際に別途500円の食券を購入いただきます。ライブハウスのドリンクチケットみたいなものですね。
ペアチケットは3000円で食券が2枚つくので、こちらはかなりお得になっております。同僚やコミュニティの仲間と一緒にお越しいただけるのであれば、ペアチケットをお求めいただくと幸せになれると思います。
該当公演なし

皆様のお越しを、心待ちにしております！

CyberAgent VS gloops な勉強会に行ってみた。

9/20に行われたレバレジーズさん主催の勉強会　
【Java・C#エンジニア必見！】CA×gloopsコアエンジニアによる合同技術勉強会！ Javaによるゲーム開発パッケージ化への取り組みとノウハウ ／月間150億PVを捌く想像を超えた安定性と適応力を持つC#の魅力 : ATND
に行ってきましたので、久々に勉強会レポートなるものを書いてみようと思います。
なぜ書くかというと、近いうちにがっつりレポートを書かなければいけないので、その練習という感じだったりします。
あと、サイバーエージェントさん・gloopsさんの仕事に興味を持っていたので、一度聞いておこうと思って行ってみました。

サイバーエージェントさん講演

Javaを用いてソーシャルゲームの開発をしている。これまでに15本ほどゲームを展開した。いまも新規で数本開発している。
そのソーシャルゲームも最近ではリッチなUIが求められたり、標準機能が増加している。また、コンプガチャが規制されたように、今後特定の機能が規制されることもあり得る。
そうした対応を個々に行うことが大変になってきたため、ソーシャルゲーム開発の基盤をパッケージすることになった。
講演者の山田元基さん [twitter: @ygenki] は、そのパッケージの開発を行っている。

パッケージ化したのはガチャやショップ・トレードといった、どのゲームにも共通して必要となる機能である。たとえばガチャのライブラリ化を行うことで簡単にガチャを導入できるようになった・規制にも対応しやすくなった・新しいガチャの種類を他のゲームに展開できるようになった。
また、各ゲームでの独自機能開発も行っている。その独自機能開発を行う際はパッケージの開発メンバが入って、ライブラリ化を前提に行うようになった。その結果として、独自開発したものを横展開できるようになった。

パッケージ化をすることで、開発スピードや品質の向上。ゲーム間の機能連携などを行えるようになった。特に開発スピードに関しては、開発前の仕様を決める部分などがごっそり無くなった。また、開発したゲームがヒットすると、開発者はそのゲームの運用にずっとかかわらなければいけなくなり、人が移動しにくくなるという弊害があるが、パッケージ化を行うことで、人が移動しやすくなり、新しいゲームを生み出しやすくなる土壌が出来た。

gloopsさん講演

gloopsはIIS, SQLServer, ASP.NET C#でソーシャルゲームの開発を行っている。主なタイトルは「大召還！マジゲート」など。
講演者の河合宜文さん [twitter: @neuecc] はLINQjsなどのライブラリの開発を個人で行ってもいる。

講演の内容はC#の進化の歴史である。2002年にC#が登場した後、2005年にジェネリクス、2008年にLINQやラムダ式といった関数型言語的な機能が追加される。2010年にDynamicが加わり一部動的言語のように扱えるようになった。そして2012年はASyncと呼ばれる非同期処理向けの言語機能が加わった。
C#は日々進化している。その進化の過程で加わった言語機能に、強力な補完機能、コンパイルエラーをリアルタイム検出、リファクタリング支援などを備えたIDE Visual Studioを合わせることで、スピードの速さが求められるソーシャルゲームの開発をC#で行えている。
例えばLINQを使うことで、どんなコレクションでも同じ構文で統一的に扱える。その機能のおかげで、memcachedを使ったキャッシュデータをそのままアプリ側のメモリ上で高速にJoinすることができている。実際のところ、SQLよりも強力であり、生産性が高い。
Dynamicがあることで、Javascriptを通して取得したデータを動的に扱えるようになっているし、ASyncがあることで、node.jsのようなコールバック地獄に陥ることなく、非同期処理が書けている。
開発コストについてはLinuxを使う場合よりも若干高くつく。しかしAWSなどでもWindows Serverのインスタンスを提供しているので、今後開発コストの差はどんどん縮まっていくだろう。
スタートアップがC#で開発するような場合、BizSparkというMicrosoftが提供する支援制度があるため、費用面も安く済む。
ソース管理はSubversionを使っている。今後はGitを検討中。どちらもIDEと連携するプラグインで優秀なものがある。
一方、ユニットテストなどはあまり書けておらず、今後の課題となっている。

サイバーエージェントからgloopsへの質問

C#以外の言語の採用・検討はあるのか。
現状は無い。他社でF#をバックグラウンドに採用している事例はあるが、ソーシャルゲームの場合、C#のほうが有利であると考えている。

C#を選んだ理由。
前身の会社がSNSをC#で作っており、その流れからC#を採用することとなった。

バージョンアップはどうしてる？
新しいバージョンを試して、問題なく移行できそうであればバージョンを上げている。
バージョンアップ自体はリスクが高いものの、言語そのものをMicrosoftがしっかり管理しているため、あまりリスク無くバージョンアップをすることができている。

gloopsからサイバーエージェントへの質問

他のJVM言語は使わないのか。
ソーシャルゲームはJavaでやることにしている。
他にはScalaのノウハウを貯めるために管理ツールの開発に使っている。

フレームワークはどうしているか。gloopsはASP.NET Web Formsでやっているが。
サイバーエージェントではStrutsやSpring, Seaserなどいろいろ使っている。フレームワークの選定は責任者が行っている。

感想

どちらの講演も「なるほど」という感じで聞いていました。
サイバーエージェントさんについては、「共通機能をライブラリ化することで、ゲームのコア部分にリソースを集中させられるな」と普通に思いました。いい戦略だなぁと思いますし、そうした共通機能のライブラリを作れてしまうのもすごいなぁと思いました。
gloopsさんについては、「こんなにもC#の機能は進化していたのか」と思いました。普段VB.NETでぐぬぬと思いながら開発をしている身としては、なかなか魅力的ではあります。
ただ、ASP.NET Web Formsではテストしずらいのは身を以て知っているので、そこがなんとかなると、もっと魅力が増すなぁと思いました。

JVM言語でクロージャ使って遊んでいた。

clojureじゃなくてclosureのはなし。

アジャイルサムライ読書会横浜道場の仲間と、隔週でゆるゆるとGroovyの勉強をしています。

プログラミングGROOVY

今日のお題の一つはこちらの本の3.6章 クロージャ

こういう書き方はなんとなくわかるんだけど・・・という感じでちょこっと調べてみたらC#でもクロージャが書けるようで（無知）
言語仕様から読み解くC# 3.0入門 （2/4）：CodeZine

で、このコードをGroovyで実装してみた。

このコードを書いてみて、なんとなくクロージャが何をやってるのか理解できて。
で、調子乗った結果、クロージャ使ってフィボナッチ数を計算するスクリプトをGroovyで書いてみた。

「ああ、あそこの変数の値をスコープ内に持ち込んで触ってるなぁー。」みたいなことがわかってきて。
この変数を、クロージャ内に仕込みたいなぁー。と思って、GroovyじゃなくてScalaで書いてみた。

なんだかんだでいろいろ書いてみたけど、どこまで理解できているかはあやしいところだったりします。

Scalaのクロージャに関しては、スケーラブルで関数型でオブジェクト指向なScala入門（4）：基本的なパターンマッチとScalaで重要な“関数” (3/3) - ＠ITを参考にしました。