2013年12月29日日曜日

くりかえしくりかえしの振り返り



空港が好きで、空港に来ると文章を書きたくなります。今夕方で、夕陽がとても綺麗です。さっきまで昼の空だったのがどんどん太陽が地平線に近づいていって、徐々に空の橙色の部分が濃くなっていきます。青かった山の色が光の加減で暗いシルエットになって、周りの雲は太陽に近ければ近いほど赤くなります。やがて雲も黒いシルエットになって、気がつけば夕方の空模様です。目の前に止まっている飛行機も徐々にシルエットがくっきりしていて、正面には羽田空港国際線ターミナルのビルが見えます。もうほとんど空の青い部分は暗くなっていて、山際の橙が極深くなっているところと良い按配のグラデーションをいつの間にか描いています。あ、ちょうど明るい星が一つだけ見えるようになりました。

そんな様子を見ながら、今年の振り返りをしています。普段PCの画面しか観ませんから、なんともこうやって目の前で動画を見ているような不思議な気分になります。

人に何かを伝えることは、人に何かを感じさせること。そういう相手に伝わった感覚というのを如何に失わずにいられるかというのが今年の命題の一つでした。

ソフトウェアエンジニアとしても、ギターを弾くときも写真を撮るときも文章を書くときも。一緒に働くメンバーにもホールに聴きに来てくれるお客様にも。自分に其の時間を割いてくれていることに、こころばかりのお返しをするということ。

毎日くりかえしくりかえし同じことをしているのではなく、相手に何かを伝えるときにくりかえしくりかえし試行錯誤すること。毎日同じ日をくりかえすのではなくて、試行錯誤をくりかえすこと。一日一日の一歩一歩を試行錯誤すること。

振り返ってできなかったことは、自分が客席にいって、受ける側になって、感じること。絵を観たり、ホールで音楽を聴いたり、ミドルウェアに感謝してみたり、写真をみて感動したりすること。綺麗なものだけを好んだり、刺激のあるもの、理知的で合理的で功利的なものだけを好むでもなく、常に素になるということ。力を抜いて自然に全て受け入れるようにして聴く観る感じるというのができると、それは多くのことがまた味わい深く興味に沁みるようになるのでしょう。

年々歳を重ねるということが身近になってきていますが、来年も又いろいろ感じて呼吸をして、また新しいものづくりや表現すること、伝えることに活かしたいと思います。今年もみなさまお世話になりました。良いお年をお迎えください。

2013年10月28日月曜日

リベルテ、第10回定期演奏会を開催します!

今年もリベルテの演奏会を催します!みなさまお誘い合わせの上、是非いらっしゃってください!
第10回定期演奏会
2013.12.8(日) 昼公演
第一生命ホール(都営地下鉄大江戸線 勝どき駅)
全席自由席
客演指揮:鷹羽弘晃 
アンドニオ ヴィヴァルディ
《和声と創意への試み》作品8より「四季」
*マンドリン独奏:望月豪(第5回大阪国際マンドリンコンクール第1位) 
壺井一歩
マンドリンの為のソネット 第6番(委嘱初演)
権代敦彦
(委嘱初演)
リベルテにとって「四季」を取り上げるのは2回目になります。今回は記念すべき10回目ということで、リベルテにとってなにかもう一度取り上げたい曲が無いかと相談していたところ、この四季があがってきました。2007年に販売を開始したCDにも取り上げられています。

私個人としては前回四季を演奏した時にはリベルテには参加しておらず、今回が初めての演奏になります。当時は客席で演奏を聴いていました。なので今回こうして演奏者として参加できることを嬉しく思っています。前回は指揮者なしのアンサンブルで演奏したとのことでしたが、今回は鷹羽先生の指揮のもと音楽を作っています。本番どのような仕上がりになるか、いまから楽しみです。

また今回は2作品初演をさせて頂く予定です。壺井一歩さんの「マンドリンの為のソネット 第6番」は前回演奏させていただいた「マンドリンの為のソネット 第5番」の連番作品になります。リベルテとしても私個人としても壺井さんの作品を数多く弾かせていただいており、今回の演奏会でもまた新たな曲を弾けることを楽しみにしております。

今回の演奏会の終曲では権代敦彦さんの作品を初演させていただきます。権大さんの作品を演奏するのはリベルテとしては初めてのことで、メンバー一同どんな本番になるのか楽しみにしています。先日スコアをみて初めて音を出し、これから徐々に音作りをしていく予定です。是非会場で聴いていただきたいです。

2013年10月5日土曜日

今年もライブコーディングの会でライブコーディングしました

先週の木曜日、ライブコーディングの会でライブコーディングをしました。


去年もやっていて、「今年はないだろうなー」と思っていたら依頼されて取り組んだ次第です。前回はこんな感じでした。

ライブコーディングの会でライブコーディングしました | Source 

今回もサポーターズのイベントの一貫として開催されました。大体60人ほど学生エンジニアの方々が集まられていたようです。多い。最初はAJITOでやる予定だったのですが、AJITOには30~40人ほどしか入れないので、パンゲアという広い部屋でやることになりました。環境は上の写真のような感じでPCの画面を映すプロジェクタと、手元の操作を映すプロジェクタの2つを使っています。

内容としてはこれ https://gist.github.com/suzuken/6840858 です。手元ではtestrunnerを使って自動テストしながら、TravisCI使ってCIするという環境です。題材は時間を変換する簡単なAPIのようなものを考えてみました。時間はプレゼン20分 + コーディング30分 * 2ほどという設計でした。

まぁ、しかしイベントにトラブルはつきものというか。イベント前にGitHubがDDoSダウン。
まぁとはいえ手元にローカルリポジトリもあるのでひとまず続行。お題の上司役を @brtriver さんにお願いしつつ、寸劇しながら進めました。

比較的シンプルなお題ながらもphpの日付文字列の書式を間違えて焦ったり、いろいろありました。お題を進めていくとしっかり前のお題でつくったテストがコケていたり、それを解消して進めていくという様子を見せることが出来ました。piece/stagehand-testrunner さまさまです。

その他質問には会場でも答えつつ、Twitterで質問されたものを返したりしていました。やはり去年と同様環境は気になるようで、vimの設定だったり、gitのaliasの設定を聞かれたりしました。

それと、会場では説明はしなかったのですが、composer つかってPHPUnitのインストールしたり、make installで環境を誰でも作れるようにしたり、PSR-0にしたがって構成を作ったりしていたのでした。というようなことはだいたい以下にまとまっています。
また、 @makoga さんと @mugeso さんからもおすすめが。
最初に質問した感じだとPHP使っている人は3割くらいのようでしたが、内容もシンプルだったのでそれなりに色々と感じてもらえたようでほっとしました…。今年はコーディング後もいろいろ質問で盛り上がり、楽しい時間となりました。あと、Kinesisを布教しました。

まとめ

2013年8月12日月曜日

エスプリマンドリンオーケストラ第一回演奏会終了しました


連日35度を超える猛暑のなか、8月11日に演奏会を行いました。第1回演奏会ということもあって初対面のメンバーも多く集まった団体となりましたが、無事本番を終えることが出来て今はほっとしています。また、ご来場いただいた皆様、どうもありがとうございました。せっかくなので、本番の録音を聴きつつ、半年に及んだ活動を振り返りたいと思います。

今回の演奏会は曲に恵まれました。「弦楽のための三楽章」を始曲として選びました。アンサンブルとしての息遣いもさることながら、メロディーの多様さ、リズムの力強さや音形を楽しむことが出来ました。みんな比較的すぐに曲に馴染んで弾くことができており、早い段階でアンサンブルを作っていくことに注力しました。この曲を最初に合わせた時には、メンバーに恵まれたアンサンブルになったなあと感じました。

桑原さんに作曲していただいた「みづかげ三章」は思い出深い曲となりました。最初スコアを見た時には、この曲がどんな世界を作っていくかを描くことは難しいものでした。Eの音を中心に揺らぎと空間を点でつなげていく譜面を見ていて、これはなかなかアンサンブルが大変だろうという印象を受けました。桑原さんによるプログラムノートにも書かれていますが(ぜひ読んでみてください)、非常に細かくパートがわけられていました。オケとしてなんとかアンサンブルができたと実感が湧いてきたのは本番の一週間前でした。団員と話していてもみんな苦労していた様子で、必死に譜面を追っていました。僕自身もソロで入るところが多く、集中力を常に高い状態に保つことが強いられました。よく練習後に桑原さんに聴いた、マンドリンオーケストラに今までになかったものを創りあげようとするプロセスはとても興味深いものでした。新しいものを創造することの負担と、そのためのエネルギーというのは大変なものなのだと感じたのでした。音楽は聴くべき場所があって、その場所で聴くべきだと私も思うようになりました。曲に関して文章で表現できるわけもなく、ただただ今回の演奏がティアラこうとうで、あるべき音楽として客席に届いたことを切に願うばかりです。今こうして録音を聴いていると、空間が捻じ曲げられ、重力が違う方向に傾いていってどこか遠くに吸い寄せられて行ってしまうような、そんな時間のうねりがたくさん発生しています。演奏者でなければ客席で聴いてみたかったものです。

終曲のシェヘラザードではいくつもの挑戦がありました。今回はマンドリンオーケストラでは珍しく金管楽器も取り入れて、管パートは原曲に近い形での編成での演奏となりました。このスケールの大きな曲をこうして弾くことができるというのは嬉しいことです。もうこれについては碇山さんの指揮が頼りでした。大学の頃はよく管と演奏する機会もありましたが、一度大きな編成から離れると耳を大きく開かなければなりません。シェヘラザードには、みづかげ三章とはまた違う、言うなれば物理的なうねりの、波の表現が常にあります。マンドリンで波の流れをつくるのはなかなか癖がついてしまって難しいものです。また、管の旋律についてマンドロンチェロで波を表現する部分などは、うねりの大きさやスピードを、響きの中でうまく噛み合わさなければなりません。これは曲を選んだ時から難しいところだろうと感じていました。また3楽章のように3拍子系に滑らかな歌いまわしを求められるような楽章では、通常のオーケストラとは違う合わせ方が必要でした。各パートのソリストは曲のなかで技巧的にも難しいものを求められるところが多々あります。コンミスのソロは練習を演奏を含め、本番が最も良いものでした。彼女が今の限界まで挑戦した、渾身のソロだったと思います。

個人的にはソロについてもいくつかの課題を感じています。一つのソロについてももっと音の響かせ方を学ばなければなりませんでした。また、旋律の中にあるいくつものエッセンスを感じさせながら、バランスよくあくまでも一つの旋律として聴かせる必要がありました。大きな曲ですし、楽章の中の旋律に明確なストーリーがあります。これを引き継ぐだけではなくて、世界観を作る必要がありました。レッスンでよく尾尻さんに指摘される、譜面の中にある音の読み取りについて無意識にに行うようになりました。あとは結果としての音として、音楽を作るというところに演奏者としてどこまで妥協せずにできるか。また、それを如何に毎回のテイクで表現するか。集中力を保つか。そういう部分がやはりプロの奏者と比べて雲泥の差がある…。そんなことをより強く感じました。


こうして終わってみると、演奏会というのは本当にあっという間でした。2月から始まった練習ですが、2次関数のように密度が濃くなって行きました。思えば、パートトップを引き受けたのは、まだ去年の冬のことでした。7月の合宿からようやく色々なものが見えてきたのかもしれません。リベルテともプレソとも違うアンサンブルとしての音楽が、結果として確かに残りました。指揮をしていただいた碇山さんや曲を提供していただいた桑原さんから、音楽について様々なことを学び、感じ取ることが出来ました。ギターパートのメンバーは難しい曲に向き合いながらも、なんとか本番まで頑張ってくれました。第一回の演奏会という大変な運営を頑張ったメンバーにはとても感謝しています。そしてご来場してくださった皆様、改めてどうもありがとうございました。また一つ、良い思い出ができました。

2013年7月16日火曜日

深く集中して模索しているときじゃないと、出てこないものもある

実は3回目のニューハイツ

3連休は合宿に行ってきました。新宿から高速バスで、一路河口湖へ。東京よりは少し湿度が低く、さらっとした空気でした。ギターを抱えて河口湖に行くのは大学の時以来です。2泊3日で泊まりに行くというのも久々で、日中は合奏をし、夜は音楽の話をしながらお酒を飲みました。普段はなかなかまとまった時間がとれず、団員と話し時間もろくにとれてなかったので、とてもよい機会となりました。やはり合宿は良いものです。

初日の練習はあまり音が鳴らず、少し不安になりました。指揮の碇山さんと「移動日だからみんな疲れているのかもしれないですね」という話をしつつ、シェヘラザードを弾きました。前の練習から時間が空いてしまうと、なかなか音楽に慣れていくのに時間がかかるものなのかもしれません。僕も先月仕事でパツパツだったこともあり、久々の合奏となりました。

2日目からは作曲家の桑原ゆうさんにも指導していただきました。今回委嘱させていただいた「みずかげ3章」の練習のためです。練習の中では曲の中の素材を、アンサンブルで実際に音を鳴らしながら確かめていきました。水の落ちる音や、曲の中に脈々と流れるものを1つ1つ確認していくことは、改めて曲について考えるよい時間となりました。音程ではなく、響きのイメージが先にあるということは演奏者にとっては弾くことのパラダイムを変えなければなりません。

ギターもマンドリンも撥弦楽器ですから、音の出るタイミングは指やピックから弦をリリースするときに決まります。それに加えて弦に指をセットするときの深さや角度、指の触れ方との関係で出てくる音が変わります。これを意識しないと、あまりに音が軽くなってしまったり、意識の浅い音になってしまいます。曲の中で繊細な音階を弾くときにはこれを特に大切にしなければなりません。マンドリンは特に、弦を叩くように弾くのではなく、置くように弾くことが求められます。慣習のなかにない気づきのある、良い練習となりました。

練習後の夜の懇親会でも普段聴けない話を色々と聴くことができました。はっとしたのは、桑原さんの仰っていた「消費される音楽は違うと思う」ということです。普段だらだらとイヤホンから音楽を聴くということで、僕は音楽を消費してしまっていたのだなと思ったのです。今までそういう感覚になったことはなかったし、新鮮でした。音楽を聴くというのはそれだけで大変なことです。目に見えないものを想像して、どういう構造なのか、どういう意図で作られているのかを考えながら、感じながら聴かなければなりません。

毎年嬉しいことに委嘱作品に触れる機会があり、こうして実際に話ができるということを嬉しく思います。クラシックの演奏会の場合、もう既に話すことの出来ない作曲家の方の曲を取り上げる機会が多いものです。曲を作った経緯やイメージ・音楽に向かう姿勢などなどを聞くことができるだけで、演奏する際に楽譜の先にある何かを考えずにはいられなくなります。深い集中の中から曲が生まれてきた過程を、追体験するように演奏しなければなりません。これは今の音楽を作っていくことの、一つの醍醐味なのだと思います。

本番は8月11日です。場所はティアラこうとう大ホール、開演は14:30です。

http://espritmo.web.fc2.com/index.html

2013年7月2日火曜日

学びの多かった6月の振り返り

All melody is expression of grief. by Kenta Suzuki (KentaSuzuki)) on 500px.com

忙しい時には学びが多いものです。しかし、忙しい時にはなかなか振り返る時間が持てないものです。一山超えて一息ついているこのタイミングにしっかりと振り返りをしてみます。

6月はとても学びの多い月となりました。タスクとしては、大きく1つ、DMPのリリースを担当することでした。これは内部的プロダクトではありますが、既存のDMPに手を入れつつ、ユーザ分析基盤を新しく設計し、実装し、カットオーバーする機会を得ました。

僕は惰性なエンジニアですから、普段の仕事というのは極力面倒なことを少なくする方向に常に意識が向いています。ですが、時間に余裕がなくなるとどんどん仕事の質が落ちていって、ひどく将来性のないコードをたくさん書いてしまいました。余裕がなくなると、勉強の時間も削られていって、コードの質が上がらない時間を過ごしてしまうことになりました。これは負のスパイラルで、「こういうパラダイムがあるとわかっているのに、そこに触る時間もなく目の前のものをなんとかするしか無い」という判断を積み重ねていくと、その先にはあまり良くないコードや設計が残ってしまいそうになります。本当にプロダクト開発というのはなまものなのだなと思うのです。

4-6月で進めていたプロジェクトでした。4,5月のマイルストーンを着々とこなし、余裕のあるペースで進めることができていました。しかし、6月の中盤以降は毎日ひどく遅くまで残らざるを得ない状況となってしまいました。最も酷かった日は午前9時半に出社して、一歩もオフィスから出ずに、誰とも会話をほとんど交わすこともなく、午前2時までコードを書いていました。出演する予定だった演奏会もキャンセルして、ひたすら設計してはコードを書いていました。こうなってしまった理由はシンプルで、4,5月に「作るべきもの」として認識していたものと、6月中盤に「作るべきもの」であったものが、量・質ともに乖離があったからです。これはもう、社内の当事者間でのコミュニケーション不足としか言えませんでした。僕として出すべき情報を先方にも出せていなかったですし、先方の希望をしっかりと聞くこともできませんでした。「ひとまずこれくらいのものを作っておけばよいのだろう」と考えていた甘えが僕に有りました。しかし、実際はそうではなかったのです。

6月中盤以降、実際に先方の要求を把握し、さあ全くもって要件を満たせていないということを知ってからは戦争のような毎日でした。集中をなんとか持続し続けて、長い長い2週間を、多少無理しながら終えました。機能を追加・拡充し、インフラを整備し、ミドルウェアを調整し、デプロイし続けました。これ自体やっていることはいつもと変わらないことですが、驚くほど短期間でやらなければならなくなってしまいました。

そういうプロジェクト佳境では、多くの同僚に助けてもらいました。インフラのメンバーには無理を言ってかなり優先して、スピーディーに環境を作ってもらいました。また、同じくリリースを控えていて、僕よりミッションクリティカルなシステムのローンチを控えているチームのメンバーに負荷テストや設計を手伝ってもらいました。運用ポリシーで悩んだ時には社内の専門チームにすぐに相談して、設計方針をブラッシュアップすることが出来ました。もういろんな人にお世話になり、迷惑をかけてしまった2週間となりました。入社以来最も過酷で、最も色々な人に迷惑をかけ、そして感謝をする2週間となりました。僕がもっとこういう設計をできていたなら、もっとプロダクトを取り巻く環境について知っていたなら、もっと事前にいろんなメンバーを巻き込んで早め早めに進めることができていたなら…。そう思わずにいられませんでした。

最終的には機能要件を満たし、なんとかリリースすることが出来ました。まだまだ求められているものには程遠く、やっとスタートできたというところではあります。何より、DMPというプロダクトの性質上、徐々に効率を高め、成果を上げて行かなければならないのです。やっと正常にサイクルを回せる環境が整っただけなのです。こうして少し落ち着きを取り戻しつつある今、自分が2,3週間前にできていれば超えられていたであろうところを学ぶ時間を得ることが出来ました。

そんな6月でした。

2013年5月17日金曜日

第一回渋谷アドテク勉強会で発表して来ました

今日はmixiさんで第一回渋谷アドテク勉強会が開催されました。 @rindai87 さんに発表の依頼をいただき、最近のアドテクノロジーの概論とDMPについてcosmiの例をおりまぜながら話しをさせて頂きました。

 


第1回渋谷アドテク勉強会 - 渋谷アドテク勉強会
http://adtech-shibuya.doorkeeper.jp/events/3869

初回、かつトップバッターということで何を話そうかと考えたのですが、やはりディスプレイ広告周りの近況、及び、DMPについて話をするのが良いだろうと思い、スライドを作りました。
「こういう狙いでこの機能を作って、それを実現されるためにこんな技術を使っている」そんなちょっとディープだけど技術より過ぎないお話をしていただこうと思っています。
営業の方やエンジニア、かつアドテク周りではないエンジニアの方もいらっしゃるということで、さあなかなか発表内容を決めるのが難しかったのです。終わった後に懇親会で感想をみなさまに伺った感じ、比較的好感触だったのでひと安心しているところです…。

僕の質問の後にDMPのプライバシー周りやリスクについて質問もありました。やはりDMPというプロダクトにおいては適切にユーザデータを処理するということが大前提にあります。また、先日のrefererによってid(≒ username)が判別可能なのではないか云々といったような議論についても、メディア側で対処できなければ「完全に技術的に不可能である」ということを言い切ることはできないのではないか、と僕個人としては思っています。なのでそういったところがプライバシーポリシーなどによる制限やいわゆる業界の共通見解的に「それは駄目」「やってはいけない」というもので排除するしか現実的に方法が無いというのが現状だと思います。ですが、アドテクノロジー領域のエンジニアとしてはそこに対する信頼を築きつつ、制度としてもユーザを守り、健全な環境を作るということが大切であると心底感じています。

また、アドテクノロジー領域のエンジニアと話す機会というのは実は私自身もあまりなかったので、今回の場はとても充実したものでした。意外とみんな同じような問題や運用に悩んでいたりするということが懇親会でわかりました…w 是非もっと色々お話して学ばさせていただきながら、アドテクの分野のエンジニアリングを進化させていければ、と思います。

運営していだたいたmixiの皆様、会場提供及び運営、どうもありがとうございました。

2013年4月30日火曜日

「プレ素」第8回目の音楽会に出演しました

2週間前になってしまいましたが、プレクトラムソサイエティーの第8回目の演奏会に出演しました。今回僕は3年ぶりの出演となりましたが、充実した合奏をすることが出来、幸せな時間を過ごすことができました。動画が上がって来ましたので、貼っておきたいと思います。

1部

ローラ序曲 イァサント・ラヴィトラーノ
Overture Lola Hyacinthe Lavitrano

抒情小曲集 小穴雄一編曲
エドヴァルド・グリーグ Lyriske stykker Edvard Hagerup Grieg arr. by Y.Oana
1. Arietta「アリエッタ」
2. Walzer「ワルツ」
3. Gangar「農民の行進
 4. Hochzeitstag auf Troldhaugen「トロルハウゲンの婚礼の日」

交響曲「ジェノヴァ市に捧ぐ」 ウーゴ・ボッタキアリ
Alla Città di Genova Sinfonia in quattro tempi Ugo Bottacchiari

2部

ディベルティメント イヴァン・シェコフ 桜井至誠編曲
Divertimento Iwan Shekov arr. by M.Sakurai
 1. Allegro rhythmico
 2. Menuetto capriccioso
 3. Canzonetta
 4.Tarantella 主題と変奏 ジュゼッペ・シルレン・ミラネージ
Tema con Variazioni Giuseppe Sirlen Milanesi

セントポール組曲 グスターヴ・ホルスト 小穴雄一編曲
St Paul's Suite Gustav Holst arr. by Y.Oana 
1. Jig「ジグ」( アイルランドの民族的な踊り) 
2. Ostinato「オスティナート」( 反復の音楽)
 3. Intermezzo「間奏曲」
 4. Finale (The Dargason)「終曲」

Encore

リバーダンス

2013年4月26日金曜日

最近の仕事の仕方と、僕が受けている恩恵と、ちょっと良い文化の話

4月から新卒2年目になりました。心機一転、4月の間は色んな面から働き方やエンジニアリングを振り返っていました。業務的にも僕が判断したり自分で設計する部分が広くなってきたので、その辺りについてのやり方も変わって来ました。

事、4月に入ってからは設計の時間が増えました。どうもコードを書き始めるための十分な材料が揃っていなかったので、ひたすら外部環境について調べてみたり、既存のシステムよりも上手く楽にやる方法というのを探ることに頭を使っています。既存のシステムや同じ事業部で書かれているコードを読みながら、「あー、この部分の設計はさすがだなー」とか、「ここの部分はみんな一回壁に当たるところだよなー」とか言いながら大量のコードに目を通しつつ、あとは頭のなかで熟成させます。そうすると寝る前や帰り道、もしくは朝起きて朝食を作っている時なども色んなことを思いつきやすいらしく、ぱっと良い実装のアイデアや綺麗で手間のかからない設計が生まれてきます。そういう「なんとなく仕事してるようなしてないような、でも、してる」ような時間というのが相対的に増えたのが、4月のハイライトだったように思います。

最近は広告のデータ周りのことをやっていて、随分と仕事の幅も広がったなぁと感じています。web広告というのは一見複雑なように見えます。私がやっているのはDMPというデータを集めてそれを活かす、ということに特化したところです。データを見るときには仮説を立てて徐々に徐々に深堀りしていきます。しかし、深堀りしすぎてもいけなくて、もう少し広い目に戻らなければならない時もあります。なんだか大学院生のときに教授から「鳥の眼と虫の眼や」と言われていたことが僕の中では身にしみていて、分析しているときは毎日がその繰り返しです。この繰り返しの効率というのが徐々に上がってくるのでまた楽しいものです。同じトピックについて一つの視点、例えばこの行動をしているユーザは一体全体どのような経路からやってきているのだろう、というような大テーマについて深掘って行くとどんどんユーザのその時の行動動機が頭のなかに描けてきます。一人のユーザのことを考えすぎても大きな結果につながる因子が出てくることは少ないですが、何かその時々のユーザの頭のなかについて想像することで、あるときとても豊かな事実にたどり着きます。そうやって、デジタルな世界からとても人間らしい何かに近づいていく過程というのは、とても魅力的です。

分析といえば最近は論文を読む会を社内ではじめました。広告技術関連論文をそれとなく読み合わせる会です。輪講です。これは至って研究室のスタイルに近いもので、毎週1本論文及び発表者を決めて、60分発表30分議論といった形でも催しています。やっていて面白いのは、大学院にいたときは実データに乏しく「実際に役に立つ感じ」というのが得がたいものでしたが、今は僕達の手元にデータが有るという点が生み出す学習効果です。論文を読みながら、「僕達ならこれをどのように利用できるだろう」「このモデルは私たちの実感と直感的には合わないがなぜだろう」「自分たちが見えていなかった外因性をこの人達はすごく気にしている」「立派な数式に落としこんでも結果は極めて単純だよね」等など、実際に現場でデータを扱っているからこそ見える視点というのがあります。僕のやっているような仕事を抽象化して学術論文にするというのはすごくハードルの高いと感じていますが、こうして同業者で研究を外に出すことができている企業というのはこれまた素晴らしいなぁと感じます。やはり実学の分野において学術との距離感というのはあるなぁと感じていて、これをお互いに歩み寄っていくことによってまた新しい発見が増えていくものだと思います。その試みのためのフィールドとして、web広告というのは魅力的な分野の一つです。

そういうところを行き来しながらプロダクションのコードを書いていると、やはりあまり時間というのは残らず、如何に必要最低限で価値を出すか、というところに僕自身の価値観が寄ってきています。これは健全であると思っていて、GNUツールの数々がそうであるように、最小のコードで筋の良い仕事を可能にするというのはエンジニアの美徳だと思うし、文化の成す技だなぁと思うのです。

$ cat some_log_files | using_some_mapper | sort_by_some_keys | and_aggregate_it > output_to_file

データをつかって仕事をするというのは面倒なことも多いですが、如何に綺麗に物事を当てはめて、それを適当に加工して、纏めあげて、つかいやすい形で手元に戻せた時点で8割の仕事が終わっています。それは分散環境下であれ、このPC上であれ、どこでも変わらないことです。などという当たり前のことを可能にしてくれているのは、やはり小さいツールが上手くお互いに仕事をこなしているからに他なりません。大抵仕事が失敗する場合というのはこれが一つの大きな仕事になっているときです。

$ using_some_mapper_and_sort_by_some_keys_and_aggregate_it_and_output_to_file some_log_files

この仕事だけにしかこの長い命令は使えないかもしれません。後から見た人が一体全体中で何をしようとしているのかを把握するのも大変です。あと、途中の処理の順番を間違えたりしていたら、それを修正するのも何やら大変そうです。どうも、はじめは何か大層立派なものを作ろうとしてしまうわけですが、僕のように一度に多くのことを考えられない人というのはこういうものを作ってしまう上手くいきません。小さいものを作って、つなげたほうが楽です。でもこれって、書くものの数はとても少ない割に、如何にこれらを小さくまともに素なものにするか、ということを考えるほうが大変です。

GrowthForecastはそういう点において素晴らしいです。このツールが素晴らしいのは、データを一旦継続して格納することを決めてしまえば、httpプロトコルでしゃべっているだけでデータを視覚化できることです。でも、意外とツールとしては面倒なことをやっています。データを貯める場所を作り、httpで喋れるようにし、グラフを書きださなければなりません。「そんな面倒ならGNU plot使えばいいじゃない」と思うかもしれませんが、継続してデータを貯めていくということは意外と面倒なのです。ところが、cartonを使って環境をつくり、あっという間にデータを溜め始めることができます。これは小さなツールを組み合わせて上手くツールを小さく使いまわしやすくした好例であると思いますし、こういったソフトウェアが公開されているというのは素晴らしいことです。社内でも徐々に広がりを見せつつあります。その様を見て、やはり設計の良いツールというのはドメインを変えても上手くフィットしていくのだな、と思います。僕もそういう筋の良い設計をできるようになっていきたいです。

こうして、もう4月も終わってしまいそうな時分ながら、改めて仕事を振り返ってみると、たくさんの先人の知恵を借りながら目の前にある課題に向かう時間がほとんどでした。sicpを読んだり、統計の本を読んだり、#ajitingしたりしながら、やはり僕は良い設計というものにこだわっていたい、と思うのでした。

2013年2月27日水曜日

2013/02/26 のajito in

昨日AJITOでビール飲んだらいいんですよって書いちゃったので有言実行してきましたよ。ということで気が向いた時にAJITOで話したことを自分用にメモ書きするシリーズ。名付けて今日のajito in。メモ順は時系列ではなく順不同。かつざっくり書いてる。


  • `make bench`でabしてgnuplotに渡して視覚化しちゃうの便利
    • 個人的にR使うけどgnuplot叩くことあまりない
      • Rだとtrellisオブジェクトというかインタフェースが良いのでそっちのほうをよく使います
    • やはり何よりmakeというインタフェースが素晴らしい
  • make cleanとかmake testとかの共通理解があるからやっぱりいいよね
  • でもrakeもいい
    • なんで?
      • アプリケーションと結びついてるからバッチ処理とかシームレスにできて嬉しい
    • とはいえrakeにする必要ないものをrake使うのはなんか違うしそこは止めましょう
    • 個人的にはmakeでrakeをwrapしてしまったら、なんて思うんですがどうなんでしょう。
  • rubyだとthorなんてのもある
    • wycats/thor · GitHub https://github.com/wycats/thor
    • 引数渡しやすいmake的な感じ
    • pythonだとfabricも近いインタフェースだけどthorのほうがユーティリティっぽい印象
  • やっぱgitって想像以上に開発スムーズにするしpull requestいいよね
    • rebaseも素敵
    • 10年後とかって別のバージョン管理システムあったりする?
      • なんかやっぱり進化してそう
      • RCS -> CVS -> subversion -> git / mercurial的な
    • ちなみに私はRCSを初めて知った
      • Revision Control System - Wikipedia http://ja.wikipedia.org/wiki/Revision_Control_System


今日はユーティリティーとか管理系の話が多かったかも。

2013年2月25日月曜日

だらだらと今のエンジニアリングの環境と所感について綴ってみる

ちょうど今、CCFBという社内フィードバックを行う時期でした。社員がお互いに評価しあったり、自分自身を評価する制度です。そんなこんなで半期のエンジニアリングについて振り返っていたので、せっかくなのでこちらにもメモにして残しておこうと思います。

基本的に私は社内のあるプロジェクトに携わっていて、中長期でプロダクトの開発をしています。社内にはいくつかの事業部が有り、それぞれにエンジニアが在籍していて各々に開発を行なっています。システムの基盤だけは別で、中央集権的に管理されています。おそらくはよくある形式ではないかと思います。

Githubが活発になった

ちょうど昨年から github.com によるプライベートリポジトリによる運用を始めた部署が増え始めました。gitの素晴らしい世界を語りだすと大きく本質から外れますのでとりあえずそこはビールを飲みながら語るとして、兎にも角にもgithubに載ったおかげでコードをレビューしたり他のプロジェクトの活動を追いやすくなりました。私などは息抜きに他のプロダクトのコードを見たり、たまにコードにコメントしたり、たまに各言語の深手の会の方々から突っ込みを受けたりしてします。これはなんというかエンジニアリングにおける血流のようなもので、脈々と流れるgithubのフィードを眺めながらプロダクト開発のスピードを感じたり、Jenkinsは私より働いてるなーと思ったり、Pull Request出したのに取り込んでもらえないからリマインドを送ってみたりと、まぁ楽しく開発しています。そんな中でもやはりWebの会社ですから同じようなコードを実は書いていた、なんてことも発見されやすくなって「じゃあ共通化しちゃえばいいんじゃね?」という気軽な提案が社内グループウェアやIRCで交わされ、気がつけばリポジトリが出来て…なんていう光景を目にするようになりました。

あら、何かGithub素晴らしいというようなことをただ書いただけになってしまっていますね。でも本当にこの開発スタイルは良いところが多いのです。あんまりメインで関わっているプロジェクトではないけど一部分連携していてちょっと口出したい、というときにも気軽にissueにコメントしてあれこれ確認したりコードを参照してあれこれ言えるわけですから、本当に便利になったものだなぁと思います。最近ではcommitコメントで大喜利が行われる程に盛り上がっております。

そういう観点で言うと、DIというか、私自身の設計の筋も少しずつ変化してきたように思います。「これ使い回せたらいいなー」から、「まぁこの抽象度は必要そうで、実際にあのへんのプロジェクトとかであとから使えそう」とか、極端に言えばデータ処理なんて全部ストリーム処理とみなしてしまえばHadoop Streamingでのローカルのサーバでも適宜動くような幸せなモノが作れそうだとか、よくそんなことを考えたりしています。

書くコードの量が減った。しかし生み出したものは増えた。

上記の話と関連している点でもありますが、書くコードの量は減りました。でも不思議と生み出すものの価値は大きくなっていて、スピードも上がりました。これは私個人の話です。今のプロジェクトでは「コードをなるべく書かないようしましょう」方針を採用いるのですが、私の中でもこれをより実践できてきたのではないかなぁという手応えを得ています。たとえばSparse Matrixの計算効率調整するの 面倒 手間だからとりあえずMahoutつかって入れましょうとか、細かい設定ファイル配布するくらいならサーバ設定に持たせちゃいましょうとか、プロトタイピングはなるべくHiveでやっちゃいましょうとか、細かい話です。そして作ってから計測する仕組みをいれる。今の事業フェーズで優先されるのは素晴らしいソフトウェアを書くことではなくて価値を出すシステムだったりするので、計測しやすく、効果を目に見えやすい形で示すことが大事。作りすぎず、考えすぎず、でも抑えるところはきっちり抑えてまずはリリースする。そういうことが習慣になっています。これは前々から私のスタンスでもありますが、継続して実践できているのは良いことだと思っています。

そういえば各プロダクトコードは短くなりましたが、テストコードが長くなってしまうのが最近の悩みだったりします。私はもう少し良いテストについて学ばなければなりません。まだ自分の中にベストだと言い切れるテストの方法が構築されていません。

やることが散らばった。質のことを考える時間が減った。

これは良くない話。比較的多岐にわたる分野のことに手を付けてしまったなぁという反省があります。去年の9月に書いた記事でも色々やったようなことを書いてあるのですが、今もやはりあまり変わりありません。JenkinsやらHiveやらAWSの特性を生かしたデプロイ、それらに加えてmongo周りの調整、R、機械学習周りのことをやったと書いています。この当時私の中で個人的に仕込んでいた統計周りの知識やら機械学習周りのことは今事業にも活かすことができていますから、今振り返るととても良いことでした。

ただ、特に今年に入ってから事業を加速させていくために質よりもスピードを重視しなければならない時間帯が増えました。それ自体は悪いことではないのですが、スピードを保ちながら質を担保したソフトウェアを書くということはいつも難しいことですから、当然負債は溜まっていくわけです。負債の匂いを感じることはできているので都度修正していきますが、同じソフトウェアの実装に集中している時間が短いため、あまり成果が大きく出ないという悩みがありました。例えば朝はJenkinsの運用周りとmongoのパフォーマンス調査をして、昼食後の開いた時間にphpでapi周りの仮実装をして、その後にHiveクエリを書いて分析を回しておきながら、夜はMahoutの挙動と運用について調査と実験をする…といったようなことが日常的に起きています。これは望んでやっているので良いのですが、質の高いソフトウェアを書くという点ではあまり良くないのかもしれない、と最近は思うのです。幸い少しずつチームが大きくなるに連れてタスクが別れてきていますから、私はよりデータ周りのことを見ていく時間が増えるかもしれません。とはいえプロダクトの成長を支え、判断をし、適切に、かつ、有効にデータは使わなければなりませんから、やはりプロダクトがどういう方向に進むべきかを知るという意味では今後もしっかりとプロダクトに軸足をおいて取り組んでいくということに変わりはありません。

そしてもう一つの良くないと思っていることは、こういったスピードを出して色々試して形にしてビジネスとして一緒に取り組んでいるチームの皆さんに、プロダクトの質を上げていくことの重要性を伝えきれていないなぁと思うことです。継続的デリバリーが如何に大事か、整然として誰が見てもストーリーの伝わりやすいコードとそうでないコードで機能を追加するの大変さが如何に違うか、チームで開発しやすい環境を作ることがどれだけ将来的にプラスに作用するか、数字を追いやすくプロダクト開発に活かせるようにしていく体制を作ることが如何に大事か、効果を繰り返し検証して調整していくことが如何に大事か…。エンジニアの方々に伝わりやすいことでも、チームに伝えるのにはそれ相応にわかりやすく、費用対効果を伝えるようにしなければならない。これにやはり苦労している部分はあるなぁと最近は思います。比較的よくコミュニケーションを取って一緒に勧められている部分もあれば、「まだそこの部分はリリースしてほしくないんです…。まだデータをとって検証する環境をつくれていないんです…。」というようなところでも気がつけばリリース優先になってしまったりするので、そのあたりは今後どうにかせねば…と思っています。もちろんバランスは必要ですが、総じてアグレッシブだなぁと思うことは多いです。

そういう面で、仕込んできた芽はでてきたけれど、今は芽に葉っぱが生えたような状態のものを、より太陽をたくさん浴びさせて伸ばしていくか、というようなところが今のプロダクト開発における今後の私の最大の関心であるようです。

やっぱりAJITOはすごい

上記のような話をAJITOでし始めるとたくさんの発見があるので、もっと社内の人はAJITOで一緒にビール飲みましょう。

まとめ

* Githubはやはり良い。
* コードあまり書かない方針は続ける。
* 今後も継続して色々ミドルウェア触るけど、自分の中で線引しっかりして、チームメンバーにもっと共有する。
* AJITOでビール飲みましょう。

2013年1月18日金曜日

学生エンジニアの就職について考える

考える、と言いながら今日後輩と飲んでいて思っていたことを書く次第です。

学部生エンジニアなり修士過程の大学院生エンジニアなり、多くの人は学卒として起業に就職することになります。もちろん博士課程に行くとか、起業するとか色々な選択肢があるわけですが、多くの人は新卒として入社するわけです。僕もその中の一人です。そんな中、今日大学の後輩と飲みながら色んな話をする機会があって、一昨年の今頃は何をしていたかなあなどということを思い返していました。積もる話になります。

僕自身は、就活中に事業を一緒にたちあげてみたり、内定者でありながら色々取り組んだり、研究をしたり、一昨年から昨年にかけていろんなことをしてました。基本的にはWebが好きだったので、何をしていてもそれに関連した物事をやっていました。今でもそこは変わらずに、仕事をしています。今はWebエンジニアと言うよりはWebのデータの分析のようなことをしている時間が多いです。いわゆるフロントのアプリを書く時間は減りました。その時々興味が変わることしばしばですが、分析よりのことというのは長期的に取り組んでいきたいので、今は長い目で見て足固めをしているという認識でいます。

さて、そうこうしていたわけですが、実際に就職するとなると悩むわけです。それはもう、とても悩みました。エンジニアというのは(そして特にWebエンジニアというのは)、多くの人が考えているように成長の方向性が多種多様ですし、ビジネスにも近いような印象がありますし、スピーディーかもしれないし、イメージとしては色いろあるのではないかと思います。僕も自分でWebアプリケーションを前々から作っていたわけですが、どうもよくわからない。プロのエンジニアというのは一体どういう人達で、どんな仕事を普段していて、かつ、そういう人たちのように働くには自分は何が足りないのだろう、とか。プロ。そう、プロのエンジニアというのがよくわからなかったわけです。それは、お金を稼いでいればプロだ、そうに違いないという話も又あるわけですが、僕の中では単にそれではいけなくて、いわゆるプロの演奏家だったりプロのサッカー選手だったり…。そういう特殊性をはらんだ何か、という漠然とした認識が有りました。就活生の時の話です。

今思い返すと、目に見えない漠然とした目標というかエンジニアのあるべき姿というものをずっと追い求めていて、つまるところわからなかったのです。何でしょう、そんな伝説のいきものじゃあるまいし、もちろん素晴らしいエンジニアの方々は今仕事をしていたり勉強会だったりでお会いするわけですが、この頃はそんな具体的なイメージはないのです。よくわからない。なので、僕の中で、職業としてエンジニアをやるためにはこうあるべきだ、という妄想が膨らんでいたような気がします。そのためにどういう場所に見を置けば私はプロのエンジニアになれるのだろう、そんなことをずっと考えていました。このへんの過程というのは無駄に見えて、実は今すごく活きているのですが、そのあたりは横道にそれるのでひとまずおいておきます。

さてそんななかで僕がふと視線が開けた、というか考え方が変わったタイミングというのはありました。信頼出来るエンジニアの方からふと言われたことです。「どこに身をおいても、結局エンジニアとして伸びるかどうかは自分次第だ。」ということです。学び続けるには自分で学び続けるしか無いわけです。ああ、なんて当たり前なんだろう。いや、そうに違いない、と思ったわけです。なんだかこの時にふと肩の力が降りて、ああ、そうか、僕は僕で学び続ける覚悟がある、腹をくくっているのだから、自分自身が伸び伸びと学べる環境を選ぼう、とそういう判断をするに至ったのです。

これは今でも変わらず、働き続けてからも変わらないことなのです。僕はこの先も、どういう環境であれ、いろんなことを学ぶ機会があるだろうし、むしろ自分から学ぶ機会を得て、時にそれを伝えながら、自分で学びたいだけ学べばいいわけです。そしてそれを活用する場所があれば、自分の学んだことを試しながら、さらに誰かの為になることができる。そういう良い循環を作っていくというのは、結局のところどこで働こうとも、事業を作ろうとも、一人で働こうとも、変わらずに一緒なのだと思います。なので、僕はたとえ後輩の、とても近くにいて色々世話を焼きたい後輩であっても、「ここにいけ」とか「その選択はよくない」とかいうことというのはほとんど無くて、彼ら彼女ら自身が何をやりたいのか、何を伸ばして行きたいのか、詰まるところどんな価値を誰のために自分のために何かのために出して行きたいのか、というようなことさえ腑に落ちれば、まぁあまり細かいことは殆ど言わないのです。でもこれがまたなかなか伝えるのが難しく、どうしたらいいものかと思うわけです。どう伝えたらいいのでしょう。

今年もまた、新卒採用の時期というののまっただ中で、たくさんの楽しいエンジニア - この子は何か楽しいことをやってくれそうだな、楽しんで働いているかな、一緒に働いていて楽しめるかな - というようなことを一人ひとり感触で確かめつつ、また新しい出会いを僕自身楽しんでいます。同じエンジニアですから、お互いに良い仕事をして、旨い酒を飲んで、楽しい話を出来ればよいのかなぁ、一緒に日本のWebの業界を楽しくしていけたらいいね、なんてことを想う時期になりました。

2013年1月8日火曜日

多少自省的な、覚書

新年明けましておめでとう御座います。今年もどうぞよろしくお願い致します。

去年は様々な経験をする年となりました。修士論文を書き、trippieceから抜け、新卒として入社するという運びがありました。この過程において、本当に多くの方々に迷惑をかけ、支えられ、機会を与えていただきました。僕にたくさんの機会を与えて下さった方々に感謝をするばかりの年でありました。

そうして多くの場面を経た2012年でありましたが、2013年はさらにエンジニアとして成長をする機会を与えられています。直面している課題は多くあります、しかし、どれもとても魅力的なものです。数学も、エンジニアリングも、人間性も、全て必要です。これらを全うして、しっかりとプロのエンジニアとしての成果を残していくということが2013年の当面の通過点になろうと思います。

エンジニアリングの幅も随分と広がった1年間を経て、今こうして日々業務にあたっていると、僕の広げられる領域というのは随分と広く、深まりました。想像しているだけだった領域にも、実際に手を加えながら吟味することができるようになりました。今年もまた、手を動かしながら、悩み、考え、少しずつ前に進む、そんな一日一日を重ねていくのだろうと思います。

驕らず、図らず、ただ淡々と、今年も充実した仕事をしていきたいと思います。どうぞよろしくお願いいたします。