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ですから、概念上、これでいろふインスタンスは無限に存在することになります。これでこそ僕らのいろふさんです。