2012/12/03

[#vgadvent2012] 湯豆腐の季節ですね

※この記事はVOYAGE GROUP　エンジニアブログ : Advent Calendar 2012の3日目の記事として書かれています。

Advent Calendar3日目です！@suzu_v が担当させて頂きます。さて、エンジニアブログによるとテーマについては
VOYAGE GROUPに少しでも絡んでいればOK
とのことです。 @katzchang さんに見習って湯豆腐を作ろうとしたのですが（むしろAdvent Calendarで前日が料理ネタだなんて思っていませんでした・・・）料理にはまったく自信がないので、僕は社内勉強会について書きたいと思います。

4月に入社してから以下のような勉強会に参加してきました。
  • 機械学習勉強会
  • SICP読書会
また単発のものでは、fluentdについて調査した内容を発表したり、JenkinsやHiveなどについて話すこともありました。また、昼休みに勉強会が不定期的に行われるので、弁当を食べながら他のエンジニアの方々の発表を聴く機会も多いです。

こう振り返ってみると、自分でもいろんなところで発表するという習慣が身に付いてきたと思います。何か発表するというのはスライドをつくるというところからではなく、普段の社内グループウェア上での何気ない書き込みから始まっていることが多いです。何気なく「これ試してみたいなぁ、調べてみたいなぁ」というと30秒後くらいに「じゃあ調べてみてね。発表してね」という先輩方のフォローが入り、あれよあれよという間に会議室が抑えられ、気が付けばさくっと十数人のエンジニアが集まる、というようなことが日常的にあります。こういうフットワークの軽さがあるので、他部署の方でもエンジニア同士話をする機会が多くて楽しいです。

そういえば先日、第3回若手Webエンジニア交流会でLTをしてきました。


内容はSICPの2章についてです。SICPについては社内で勉強会がいくつか走っており、僕もその一つに参加しています。データとは何か、とすごく漠然としたタイトルですが、内容は淡々とデータに関する決まりを書いていったらデータとうまく付き合えるということについて書いています。社内勉強会をしていると、このスライドの中にあるような発見が多々あります。LTではその一部分のエッセンスを抜粋して発表してみました。１人で読むと自分の中だけで発見が終わってしまいますが、一緒に勉強し、楽しみを見つけられるのは読書会の良さだと感じています。

僕はSICPを読んでいますが、Lisperではありません。ただSchemeはこういう用途のエッセンスを伝えるのにすごく良い役割を僕らに提供してくれていると思います。あくまで学部生用の教科書ですから、そういう内容を神話的にするのもきっと違います。業務に直接的に影響してくるかというと、そうではありません。こういった抽象化の考え方というのは少しずつ時間をかけて僕自身のコーディングスタイルに良い影響を与えてきたと感じています。社内でコードレビューなどをすると「そこの抽象化の壁が・・・」的な話が自然に出てくるので、ある種の共通言語になっている感もあります。

去年まで、こうした本に触れる機会というのは社会人になってからはないのだろうなぁと思っていたのですが、去年以上に様々な角度からいろんなことを学ぶ機会を得ています。社内の勉強会もそうですし、日常の些細な会話においても、学ぶ機会が転がっています。振り返るとSICP読書会に出ることになったのは駒場のおいしいホルモン屋で飲んでいた時だった気がします。


なんだか積もる話をしてしまいました。明日は @chisei さんです。お楽しみに！
時刻:

2012/11/30

サブロク会議に参加しました

サブロク会議に参加しました。

株式会社VOYAGE GROUP - 事業開発の仕組み http://voyagegroup.com/business/development-system/

引用すると、以下のとおりです。

360°会議（通称：サブロク）

中長期的な事業成長に繋がる新規事業、事業改革、重要課題の解決等の提案をBOARDメンバーを中心とし選出されたクルーが真剣に議論し、その場で最終意思決定を行う事業開発の仕組みです。年に2回開催されます。

普段の仕事の中では触れることのないトピックについて、いつもと異なるメンバーで議論し、そして実際に最終意思決定まで行う、という会議です。まさか自分が参加すると思っていなかったので、呼ばれたときは「えっ」というリアクションを思わずしてしまいました。今日、そのサブロク会議が終わりました。せっかくなので振り返りがてら、文章に起こそうと思います。

まず、参加して個人的に感じたことが２つあります。１つは、自分の会社の事業モデルを全然把握できていなかった、ということ。もう１つは、自分のエンジニアとしての事業をつくる価値についてです。

VOYAGE GROUPは様々な事業領域があります。メディア・リサーチ・アドテクノロジーを中心としつつも、各分野にアセットがあります。ただ、僕の立場としては普段係る領域はごく一部なのです。端的に言えば、他の部署の仕事やビジネスモデルについてよく知らないわけです。強いて言えば、ビールとピザ片手にエンジニア同士で「あそこの作り、もうちょっとこうしたらいいんだよなー」「そうですねー」という会話をするのが僕の情報源だったりします。なので全体観というところで捉える機会というのは意外となかった。意外と言うよりも、なかった。そしてそれらを把握できていないということに気がつけました。どこに売っているのか、誰がどのように事業を広げているのか、何を目的にしているのか、その事業の肝は何なのか。そういうことを知りませんでした。知らないと当然改善案や、明日からどのようにしていけばよいだろうか、という提案は出せません。正直なところ、僕は把握するので精一杯でした。全然知らなかった。

そして各領域についてエンジニアリングの関わる範囲は多岐にわたります。外部システムとの連携であったり、どんなデータを保有するかという視点であったり、そもそもサービスとして実現可能かという点であったり、エンジニアとしてそれを作るべきか作らないべきかという判断であったりします。そういう視点で今日の提案を見ていることが多かったです。そういう視点を織り込みつつ（そして譲れないところは「それはできません」と主張する義務が僕達エンジニアはあります）、様々な事業のこれからのかたちを考えることができたのは、とても良かったです。今の自分の見識では判断しかねる領域については、単純に僕の知識が狭いということであったり、一エンジニアとしてのポリシーが曖昧であるということに他ならないからです。Webの事業という大きなドメインを捉えつつも、成長性と実現可能性を踏まえてエンジニアの視点から適切な解答を行うという面について、僕の眼の未熟さを感じました。

今大きく感じていることは、参加できてよかったということに尽きます。普段ボードの方々がどんな議論をしているのか、そういう様子を垣間見ることができました。話し合いのスタンスも見えました。5人5チーム、それぞれの案を明日の事業につなげようと、議論を重ねていってそれぞれの分野の強みを重ねあわせて、徐々によりよい形になっていく様を見ました。実際にいくつかの最終意思決定がその場で成されました。僕が言うのも何ですが、そういう体験や場であったということが、今日の会議の何より大きな影響だったのではないかな、と思います。

そんなこんなでここ4週間くらいずーーーっとそんなような事業よりのことを頭に巡らせていました。商品を見れば何かを想起し、Webサイトを見れば新しいカタチを考え、バナーを見れば新しい広告の形を想像し、家に帰れば一日に考えた案を振り返る、そんな過ごし方をしていました。そんな中、今日はサブロク会議明けにビールを飲みながらSICPの無限ストリームのところの話はやはり美しいなぁと思ったり、Haskellはよくわからないけどすごいなぁと思ったりして、そういういろんな物事が頭の中をぐるぐるした日でした。
時刻:

2012/10/31

「継続的データ解析環境の構築」についてad:tech Tokyo de テック勉強会で発表してきました


昨日から東京国際フォーラムでad:tech Tokyoというイベントが開催されており、その中で開催されたテック勉強会で発表してきました。会場を提供していただいたspacyzの皆様、どうもありがとうございました。また発表を聴きに来てくださった方々、どうもありがとうございました。

内容はJenkinsとHadoopを利用して継続的にデータを解析する環境をつくる方法についてです。やはりデータを解析するために、解析を回しやすい環境を作らなければなりません。データを観察して、なぜそうなっているのかという仮説を立て、実際に計算機を回し、結果を出します。高い成果を上げるには人の頭で考える部分に時間を割かなければなりませんが、Hadoopを利用した解析においては手軽に回す環境をつくるということが実はやや面倒なのではないかと感じています。なので、Jenkinsを利用してそういった作業を効率的にしてみたらどうだろう、と考えたのが発端でした。

今関わっているアプリケーションは全てAWS上で動作しています。発表ではあまりそのへんには触れられなかったのですが、Fabricとbotoを組み合わせてELB以下のEC2インスタンスを取得し、各EC2インスタンスに色々なコマンドを送る、といったことをやっています。そして何より、Elastic MapReduceを如何に気軽に利用できるかという点が肝になってきますが、HiveクエリやMapReduceのJavaアプリケーションの実装後は全てJenkinsに任せることで、実際にHadoop上でジョブが回せるようになっています。Elastic MapReduceでジョブを回すにはS3に配置してelastic-mapreduceコマンドを実行する必要がありますが、やはりそのへんをあまり意識せずに解析ジョブを流すことができるようになったのはとても楽です。各々の細かい資料については参考資料にいろいろ載せてありますので、参照していただけると幸いです。

発表後に「Hiveで解析するときにログの形式とか入ってるデータが変わったらどうするの？」と@katzchangさんから聞かれたのですが、うまく答えられませんでした。今のログの形式は基本的なdelimiterがあれば簡単に解釈できるものと、そうではなくて正規表現マッチが必要なものがあります。後者についてはPythonでmapperを書いて流しこむようにしているのですが、とはいえそもそも何らかのカラムが追加されるなど、ログに入ってくるデータが変更された場合には根本的に何か対応できるかというとそうではなく、やはり運用でカバーする部分が多くなってしまうと思います。僕のところでは異なる形式のログを扱っているところはありますが、そもそもS3のバケットが分かれており、分析対象としても疎だったりするので、あまりそういった場合に直面することがありませんでした。ただカラムを足すような場合にも昔のデータを参照して時系列で一元的に分析したい、という場合は起こると思うので、適切なmapperを実装して、Hiveテーブルのスキーマに流し込めるようにするというのが現実的なところなのかな…と思います。

とはいえ発表できて良かったです。話していて、理解の浅い部分が明確になりました。そもそも発表の発端は@bash0C7さんとの「発表することになったのでよろしくね」「えっ」「えっ」という会話だったりして不思議なものですが、とても良い機会になりました。改めてありがとうございました！

今日もこれからad:tech Tokyoにいってきます。
時刻:

2012/10/27

美容室での会話

僕は割りと美容室での会話が好きです。大体髪を切りに行くのは休みの日で、大抵どこか楽な気持ちでいるので、会話が弾みます。

今年引っ越してから行きつけだった美容室が遠くなってしまったので、何軒か行っていたのですがどうも馴染まず。しかしやっと最近落ち着いて気軽にいける美容室を見つけました。今日はひさびさに休みらしい休みだったので、そこの美容室にいきました。そこでの話が興味深かったのです。

大抵美容室に行くと仕事の話をします。割りと客層も僕に近いか、若い社会人の方が多いようで、美容師さんはいろいろな業界の話を知っていたりします。気さくな方なのでいろいろな話をしてくれますし、僕もいろいろ話をします。iPad miniとNexus 7とKindleどれがいいんですかねーみたいな話から、そのへんのおいしい飲み屋の話をしたりもします。そんな中で、美容師さんの仕事についての話になりました。エンジニアの海外カンファレンスで参加費2,30万くらいのとかってよくあるんですよ、というような話からのくだりです。

「美容師にも講習があってね、大体高くて5日間で10~15万くらいかな。確かに講習を受けると技術は学べる。けど、実際にお客さんと接している時にそれが使えないとだめなんだよね。そしてその技術はすぐに使えるかって言うと、そうじゃない。お客さんの髪質だったり、頭の形も違うし、その人の雰囲気にあったスタイルにしていかなきゃいけないんだよね。そうやって講師をしてくれる人ってやっぱりすごい人が多いし、実際にすごいんだけど、だからといって講習に行ったからといってその人になれるわけじゃなくて。それよりもこうやって毎日お客さんと接してその人にあったスタイルを自分なりに提供するってことがやっぱり大事なんだよね。」

「そういう意味では毎日がテスト。よく学生の時にテストがやだなぁって言ってたけど、今って毎日が本番なんだよね。今日本番やって、また次の日も本番。だからその日のうちに振り返って、明日の本番に備える。ある意味一番の練習になってるのかもしれないけど、練習っていうかやっぱり全部本番なんだよね。」

まあそうですよね、と言いつつ、やっぱりそういうシビアな環境ってすごいな、と思いました。やっぱりなんだかんだ東京の美容師さんは技術は相対的に見ても高いそうなのですが（ちなみに僕は鈍感なのでそのへんはさっぱりわかりません。）、結局技術があっても自分なりに考えてお客さんにあったもの出さないとだめなんだよね、という話をしました。僕は美容師さんの世界は全然知らないのですが、こう聞いていてやっぱりプロだなあと思うのです。

エンジニアもある意味では毎日本番で。システムは稼働し続けているし、開発も毎日続けている。やっぱりそういう中でサービスのローンチだったりアップデートだったりサーバの移行だったり色々なイベントがあって、そこに向けて淡々とやっていくというスタイルが多いと思います。ただ、なんだか、１日に何人ものお客さんと常に１対１で対応して、毎日それを続けていくというのはすごいことだな、と思ったのです。

最近は毎日仕事にとりかかる時に「何を進めるか」を考え、そして「何が進んだか」を確かめるようにしていました。将来的になりたいエンジニア像が漠然とあって、そこに向かっていくように毎日のタスクをこなしつつ、学ぶ方向性を決めるということを毎日意識するようにしています。でも、毎日が本番という気持ちで向かっていたかと決してそんなことはなくて、かなり波があるというのも事実です。

自分は本当にプロと言い切れるのかな、と感じた時間でした。
時刻:

2012/10/20

大きなシステムのアーキテクチャを自分の頭で考える。

今日からインターン、Sunriseがスタートしました。

大規模サービス構築プログラム「Sunrise」｜VOYAGE GROUP　インターンシップ　～ミチをソウゾウせよ～ https://voyagegroup.com/internship/sunrise/

Sunriseはその名の通り、大規模サービス構築をテーマとしたインターンです。内容としてもサービスのインフラに主眼をおいています。内容の目安としては100万人を超えるサービスのインフラをどのように構築するか、といったところが焦点となってきます。普段アプリケーションを開発している子たち向けに、どのような考えでインフラを作っているか、という話を中心に展開しています。

実際にインターンが始まって、こうして参加者の子たちと実際に話していると、ああインターンが始まったのだなぁという実感が湧いてきます。今日の朝は@makogaさんによるワークから始まり、手を動かしながら実際にシステムを計測を行うところから進んで行きました。みんななかなか慣れていない作業に最初は困惑しつつも、徐々に慣れていって考察を深めていったのはさすがだなぁと思ってみていました。

今回は僕もSunriseに講師として参加することになり、早速今日発表をしてきました。僕が発表したのはAWSに関する話、そしてSSPであるFluct と、今開発しているcosmiの話をしました。学生にとってはなかなか触れることのない、アドテクノロジーの世界。普段表示されているバナーの裏に存在している、いくつものステークホルダーとシステム。そういうシステムのインフラがどのように構築され、そしてどのようにアプリケーションが動いているのか、というトピックについて俯瞰するような形で講義を行いました。

とてもむずかしい部分ではあるのですが、なるべくそのシステムの要件や構築の背景についても話すようにしています。なぜかというと、リアルな仕事の現場で、実際にそのような要件が与えられて、その上でコスト感や規模感を自分たちで考えてインフラを設計する、というところまで見て欲しいからです。特にアドテクノロジーの分野の場合、関連するシステムやプレーヤーも多く、何が必要なのかということを理解するのに敷居が高いという部分はあります。でもそれは例えば自分がスタートアップでシステムを一から作るという場合でも一緒です。先がわからない。どこまで作りこめばいいのか見通しが立てづらい。急激なアクセスが何時来るかはある程度しか予想できない。ビジネスがどんな規模で成長するのかを見込まなければいけない。そういう背景を踏まえて、インフラの構成やアプリケーションの設計ができるエンジニアになってくれたらいいなぁという想いがあります。

学校でOSI参照モデルやネットワーク、OSの仕組みについて勉強しているかも知れません。そして自分でWebアプリケーションを作成できる。それは素晴らしいことです。しかし、必要になった時に本当に必要となるものを自分の手で、頭で、作れるのか。本当に自分はそういう背景知識を活かして実践できるのだろうか。知識としてただあるだけではなくて、実際に使えるものにしていく。自分がそういう立場になった時に、プロのエンジニアとして環境に適応していくことができる。そしてユーザにサービスを届けることが出来る。ビジネスを作っていける。そんなきっかけになれば、と思っています。

やっぱりそういう大きなサービスを支える、そして自分から創りあげる、そういうエンジニアが増えたら、もっと楽しくなるのではないかなぁと最近よく考えるようになりました。僕もまだまだ知らない事だらけですが、こうして教えることをしながら学んでいって、自分で考えることのできるエンジニアが増えていったら素敵だなあと思います。

来週の最終発表が今から楽しみです。
時刻:

2012/10/11

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

人がコーディングしている様子を見る、というのは僕にとって愉しみの一つです。機会があればよく「どんな環境で実装されているんですか？」というようなことだったり、「今なぜそこから実装されようとしたんですか？」というようなことを聞いてみたいけれど隣で色々思いを馳せながら眺めていたりします。

などと思っていたら自分のコーディングしている様子が晒されるイベントにいつの間にか参加することになり（！）、そのイベントが昨日行われました。

僕が学生（就活生がメイン）の前で1時間ひたすらコーディングをするという会です。ディスプレイをプロジェクタで投影し、手元の動きをカメラで2枚目のプロジェクタに映されながらコーディングします。隣で @katzchang さんに解説していただきました。（といっても事前打ち合わせはほとんどなかったです。）

お題は自由だったので、ひとまず最近勉強しているFlaskで小さな掲示板でも作る、ということにしました。スキーマ定義が面倒なのでMongoDBで、あとはローカルでサーバたちあげてテストすればいいだろう、という極めてざっくりな方針で進めることとしました。

ひとまず気合をいれてツイート。

まずGithubリポジトリを作成。(https://github.com/suzuken/livecoding2012-10-09)

次にローカルのpipでFlask周りの物をインストール。ひとまずREADME.md書いてcommit。git push origin master。

init · 78e80b4 · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/78e80b4b24dbb171e36989ec0461fe1d83bc19b0

そして次にFlaskの最小限のコードを書く。この時にvim環境について質問があったのでツイート。
そしてcommit。

add endpoint · fba1f7f · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/fba1f7f43121223ecf3fc6bf3fe8828cc9db1591

次にMongoつなぎましょう。ということでMongoKitをimportして、簡単にDocumentクラス書いて、とりあえずエンドポイント書いてpush。

adding mongokit · 728381c · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/728381cd57a740f8ddf572ce977420c76df76870

そしてここから色々調整。ひとまずviewを作ろう、ということでTwitter bootstrapを落としてきてstaticディレクトリへ。そしてささっとviewと作成。表示完了。次にログイン作ろう、と思ったらFlaskのsession周りについて全然調べていない、ということで色々焦っていたら時間が経ってきたので、とりあえずブログのエントリを表示できるようにしよう。ということでテストデータを挿入するためのエンドポイントを作成。更新。しかしMongoKitでエラー。Documentの定義ミス。もう一度更新、しかしエラー。挿入は成功したが、redirectの設定を間違える。このあたりでつい弱音が…。


そしてもう一度挿入。今度はうまくいった。ここで大分時間消費…。あと20分…、とかだった気がします。 実際にやっていて気がついたんですが、60分間も人目にさらされながらコーディングするっていうのはなかなか体力が要ります。45分を過ぎた当たりで若干酸欠になってきます（※個人差有り）。ということでこの時間帯はもう全然進まなかったです…。とりあえずMongoへのinsertとfindだけ作って表示しただけになってしまいました。おまけにcommitするのも全然忘れていたため、下記のカオスなコミットオブジェクトが生成されることになります。コミットメッセージからも余裕の無さが伝わってきますね。

bootstrapたして、dbつないで、addして、findしました。余裕がありません · a2580d3 · suzuken/livecoding2012-10-09
https://github.com/suzuken/livecoding2012-10-09/commit/a2580d320b6d5480a3f701a8e2e21e048e1e9190 



という当たりで1時間経ちました。ライブコーディング終了。ヘトヘトです。やってみるといろいろテンパッていろいろ想定外で進まない…などなど色々起こってますね…。

コーディング後は、まぁとりあえずビールを飲みつつ、色々質疑応答しました。割りとツール周りのことを多く聞かれました。zshの話、tmuxの話、あと多かったのがvim周りの質問でした。補完（僕の補完はvimデフォルトのままです。でもみんな意外と知らないのかも知れません。）、バッファ、移動、削除、カーソル移動、などなどです。あとはドキュメントの読み方についても聞かれました。

そういえば僕も学生の時には「現場のエンジニアは一体どんな風にコーディングしているんだろう」とよく思ったものでした。実際にそれを見れるというのは面白い機会だったのかなぁと思います。なんというか、実際そんなに差はないと思います。なんだろう、僕自身あまり学生の時からすごく変わったかというと、確かに触れている時間は増えましたが、すごくコーディングスタイルが変わったかというとそうではないです。でもいろんな要件や環境になれてきた、というのはあると思います。良くも悪くも現場感の伝わるイベントになったような気がします。

とは言え、思わず漏れる本心…。
でも他のエンジニアの方々のライブコーディングはみたいです。（できればビール片手に！）
時刻:

2012/10/05

エンジニアの育て方を考える

最近になってよくエンジニアの対話について考えるようになりました。

最近あるインターンが始まりました。Guildというインターンです。これは僕のような入社して日の浅いエンジニアが、学生やそれに準ずるエンジニアに対して実践型の育成を行なっていくというスキームを持ったプラグラムです。

就業型実践育成プログラム「Guild」｜VOYAGE GROUP　インターンシップ　～ミチをソウゾウせよ～ http://voyagegroup.com/internship/guild/

こういうインターンの場合、学生一人ひとりに合わせて方法を変えていかなければなりません。一人ひとり癖がありますし、スキルも異なります。また事業に対する理解度も最初は浅いでしょうし、所属するチームのやり方も様々です。そんな中でもフレキシブルに、かつ着実に学びを得られるような環境をつくる、ということについて最近は考えています。

育てる、と言いつつ僕は育てられてばかりです。不思議な事ですが、大学院にいる時よりも学習ペースが上がりました。それは時間に対して自分でしっかり管理するようになったからとか、評価してくれる人がいるからだとか色々な要因がありますが、総じて環境による影響は大きいです。同じような関心ごとをある人に囲まれて、日々それとなくご飯を食べたりお酒を飲んだりしながら技術の話をして、帰り道や運動している時や帰って風呂に入っているときにふと「あ、あそこはもっとこうすればよかったなぁ」なんて思って次の日にとりかかるのです。今もそうです。こうして帰宅して文章を書きながら、あのときこういうふうに問いかけていたら良かったのかな、なんてことを思い返しています。

前に出て講義形式で教える時と、対話しながら教える時では、今はやり方が異なります。対話しているときは特に問いかけていることが多いです。ゲーテとの対話 ほど諭すことができるほど高尚ではありませんし、アプレンティスシップ・パターン に書いてあるほど定型的なやり方を心得ているわけではないのですが、人によって問いかけが多かったり少なかったりします。たとえばとあるMVCフレームワークに関するチュートリアルをやっていたとして、MVCに関して理解していることを確かめようと思った時には、大体頭の中に以下の様なツリーを描きます。

  • なぜMVCの構造が必要なのか
    • Model View Controllerそれぞれの役割を把握しているか
      • 複数人で開発する場合はどうか
      • MVCの構成は自分の感覚とズレはないだろうか
        • それはもしかしたら正常かもしれない
    • HTTPリクエストをなぜControllerで捌くのだろうか
      • そもそもHTTPリクエストには何が含まれているのだろうか
      • ControllerのプロパティにModelインスタンスの参照を渡すのは妥当だろうか
    • なぜModelでデータの操作をするのだろうか
      • そもそもModelによって抽象化しているものは何なのだろうか
      • このチュートリアルではModelにどのような工夫がなされているだろうか
    • Viewに表示する際にどのようなフローを経ているだろうか
      • そのフローは合理的だろうか
（すごく偏っている気もしますが）大体こんなことを大枠として捉えておいて、相手の状況によって質問を変えます。コード自体は動いているのだけれど、なぜそのように書いているのかが自分でも理解できていないという場合もありますし、MVCっぽい書き方をしていても何かエッセンスを捉えていないコードになってしまっている場合もあります。そういうときに上の簡易的なツリーをたどって質問をします。僕が対話をするときには大体そういう方針をとっています。もちろん話題は多岐にわたりますし、MVCの話だったのに開発フローの話になったり、Webサーバの話になったり、Gitの話になったりします。それはそれでよくて、学びのきっかけとしてチュートリアルというものがあれば良いのかな、と思っています。

ただ、もちろんこんな一例にすぎないことで完結するものでは当然あるわけもなく、日々少しずつ続けていくということをしています。逆も然りで、僕も気がつけば教わっていたという場面が多々あります。そういうとき、「ああ、巧いなぁ」と感じたりもします。教えているようでなくて、気がついたら本人が気がつく環境が作られていた、ということなのです。僕ももう少しそういう環境づくりをうまくできたらなぁとよく思います。

前も一度書いたのですが、「誰のために何ができるのか」というのはやはり僕の中で日々の大きな部分を占めている関心ごとなのです。相変わらず変わらないなあ、などとこの文章を書きながらまた思い返しています。

時刻:

2012/10/02

Programming Hiveを購入した。


Programming Hive、出ましたね。Hiveのドキュメントはapacheプロジェクトのページで閲覧できるものの、まだドラフトのドキュメントと混ざっていたりして見づらいので、こうしてまとめられて出版されることは好ましいことです。

Programming Hive - O'Reilly Media http://shop.oreilly.com/product/0636920023555.do

早速購入し、今日の午前中に読んでいました。目次は以下のとおりです。

Chapter 1 Introduction
Chapter 2 Getting Started
Chapter 3 Data Types and File Formats
Chapter 4 HiveQL: Data Definition
Chapter 5 HiveQL: Data Manipulation
Chapter 6 HiveQL: Queries
Chapter 7 HiveQL: Views
Chapter 8 HiveQL: Indexes
Chapter 9 Schema Design
Chapter 10 Tuning
Chapter 11 Other File Formats and Compression
Chapter 12 Developing
Chapter 13 Functions
Chapter 14 Streaming
Chapter 15 Customizing Hive File and Record Formats
Chapter 16 Hive Thrift Service
Chapter 17 Storage Handlers and NoSQL
Chapter 18 Security
Chapter 19 Locking
Chapter 20 Hive Integration with Oozie
Chapter 21 Hive and Amazon Web Services (AWS)
Chapter 22 HCatalog
Chapter 23 Case Studies

1~8章あたりは基本的にリファレンス的なものです。

それ以降は比較的実践的な内容が続きます。9章では比較的実践的にパーティショニングを使った事例などが出てきます。13,14章ではUDF, UDFA, SerDeの実装についてや、Mapper/Reducerの実装について説明されています。12章でHiveの拡張に関する開発環境の整え方について書いてあるのはなかなか親切だなぁと感じました。16章ではThriftとの連携について、17章では各種ストレージの利用について言及されています。ストレージハンドラ実装の際の参考にもなるかもしれません。

また21章ではAWS上での利用についても触れられていますが、ここでは比較的導入的な記事に留まっていました。23章のケーススタディーは面白いです。たまにreportされているNASAでの利用事例についても解説されています。

個人的にはHiveを拡張する際の実装に大いに参考になる一冊になりそうです。特に10,13,15,17章あたりはすぐに実践に活かせそうです。8章で今後広まるであろうIndexについて触れられているのも良かったですが、内容はまだ薄いといった感じです。（とはいえ、HiveのJIRAを追っていない限りは得られない情報も多いので、そういう意味ではよいまとめだと思います。）またHiveを俯瞰するという点でも簡潔にまとめられていて好印象でした。ただHiveというプロダクトの性質上、万人に必要な本ではないということも踏まえて、バランスのとれた本だと思います。
時刻:

2012/09/28

最近取り組んでいることの振り返り

4-9月で句末ということもあり、最近はここ半年やってきたことを振り返る時間が少しばかり増えました。せっかくなのでここにもメモとして残しておきたいと思います。

  • Jenkins
    • MapReduceアプリケーションのビルド・デプロイ
    • 管理アプリケーションのビルド・テスト・デプロイ
    • 高機能crontab的な使い方もし始めているが、やっぱりcrontabはcrontabであるべきで、なんだかJenkinsは少しリッチ過ぎる気がしてる
    • さらにいうとJob間のパラメータの受け渡しがもっとやりやすかったり、JobからJobへのフックがもっとフレキシブルにできたらいいなぁと思っている
      • でもそこまで望むのも間違っている気もする。
  • Hiveの調査、導入。中間データ設計。
    • Mapperを書いたり、パーティションと格闘したり。
    • Hive入れてよかった。Hiveのない生活はもう考えられません。
      • いわゆるRDBのクエリのチューニングと違って、MapReduceの振る舞いやら元データの展開やらネットワークコストやらいろいろ考えることがあって楽しい。
      • あと何だかんだHiveの、なんというか幅のある設計は良いなぁと思ってる。UDF, TRANSFORM, SerDe, ... 
  • AWS環境に大分慣れた。
    • AutoScaling設定
    • boto + FabricでELB以下のEC2にデプロイ
      • プログラマブルなインフラ美味しい。
      • アプリケーションエンジニアというか、インフラをアプリケーションとして操っている感じ。
      • AWSすごい。
    • CloudFormationをつかったPreview環境運用
    • EMRの癖
      • ちょっと普通のHadoopと違うけれど、S3と仲良くすると旨み多し。
  • subversionからgitへの移行
    • プロダクトの整理という意味ではこれが一番大変だった。
    • Jenkinsでのデプロイ環境を作るのに、どうしてもgitに移行したかった。
    • でもgit移行してプロダクトの見通し良くなったので、やってよかった。大変だけど。
      • チームでお互いのコードが見えやすくなったのは、思った以上に快適何じゃないかと思う
    • サブシステム（gitでいうならリポジトリ）の大きさをどの程度にするかが難しい。増やしすぎず、大きすぎず。
      • submoduleも使い過ぎると逆によくわからなくなる
        • Jenkinsで、というよりFabricでデプロイするときに色々来にしなきゃならないのであまりsubmodule増やしたくない
  • mongoと格闘
    • 最初はmongoshell便利とかいって悦に浸る
    • データが増えるとやっぱり火山
    • レプリカのシンクロナイズ怖い
  • Nutchの調査・導入
    • EMRでうまくNutchを使う
    • 分散インデックスとの戦い
    • でももっといいソリューションがあった気もしているのでおいおい見直したい。
  • SolrとCarrotをつかった簡易テキストマイニング
    • 最初全然わからなかったけど、lucene-gosenに少しだけお世話になりました
      • 知らぬ間にNgramでテキストフィールド持ってて、試しにクラスタリングしたら全部同じクラスタになったという悲しい思い出が
    • これはあまり成果が出なかったのでちゃんとやりたい
  • R, R, R
    • さくっと何か傾向を見たり検証をするという機会には使っていたけれど、ルーチンワークに入れられなかった
      • ちゃんと日々のプロセスに組み込みたい
    • Rで解析したデータをちゃんと人に伝わる形で見せるというのは比較的悩ましい課題
    • 自分が勉強するのもそうだけど、ちゃんと周りに統計のこと伝えるの大事だと思った
  • 機械学習周り
    • 3ヶ月くらいライトな機械学習勉強会を開いた。週1。
      • もっと濃くすればよかったと反省している。
      • せっかく会社でやるなら実践の比率を上げたほうが良かった。
    • PRMLは部分的に読んでる。けどまとまった勉強時間取らないと身にならないことが目に見えている。
    • SVMの赤本は今半分くらいまで読んでる。実装しながら。
  • 少しPHPを触ったりした
    • FuelPHPで小さいアプリケーションを作ったりした
      • 作っているときは良かったが、運用はあまり気持ちよくない
      • 使いやすいルーティング機能があって、使いやすいテンプレートエンジンがあれば良いんじゃないかって最近思ってる
      • Taskは無いより便利だけど、バッチ書くならPythonか、shellで書いたほうが楽、というかoilコマンドがあんまり好きじゃないのかもしれない
        • 好みの問題かもしれない
    • debugとかレビューとかでは触れる。けどそのたびに、「ああ、自分はあまりPHPのことを知らなかったんだな」と思ったりする。
      • でもWebアプリケーションを作る上では、自分はPHPの作法に慣れている。
        • 要は慣れと経験の問題かもしれない。

色々浅いままの部分も多いので10月からも頑張ります。
時刻:

2012/09/11

虐殺器官とアルケミストを読んだ。


今日は帰ってゆっくりしているので、週末に読んだ本の話でもします。

まず、「虐殺器官」。急に混じりっけもなく強烈な名前出してごめんなさい。めったに読まないSF。理系だからSF好き、ということもなく、たまたま本屋であまりにも強烈なタイトルが目に止まったので読んでみました。

出だしからあまりにも強烈な風景の描写。そして「ぼく」の存在。この主人公である「ぼく」は国の暗殺部隊の一員として描かれています。ある感覚を麻痺させて、暗殺に対する感覚を鈍らせる。そのある種の感覚麻痺状態における自我。それがこの本のなかのぼくによって支配されています。主人公は冷静で客観的に描かれていますが、読んでいるとこっちの感覚まで麻痺してくるようです。

話の中で人間とことばの関係について触れられています。これは僕としては興味深く読んでいました。自然言語処理周りのひとが好きそうな話がでてきます。そして脳。医学。大量虐殺を引き起こす仕掛け。もういろんな領域の知識が詰まっていて、どうやったらこんな凄まじい本を書けるのだろうと思えてしまいます。本当に凄まじい本、という印象でした。

前に読んだ半藤さんの「昭和史 1926-1945」において、熱狂という観点から戦争を描いていた場面がありました。なんだかそれを彷彿とさせました。ことばの仕掛け。そんなことが頭の中をよぎって、あっという間に読み終わりました。

Amazon.co.jp： 虐殺器官 (ハヤカワ文庫JA): 伊藤 計劃: 本
http://www.amazon.co.jp/%E8%99%90%E6%AE%BA%E5%99%A8%E5%AE%98-%E3%83%8F%E3%83%A4%E3%82%AB%E3%83%AF%E6%96%87%E5%BA%ABJA-%E4%BC%8A%E8%97%A4-%E8%A8%88%E5%8A%83/dp/4150309841/ref=sr_1_1?s=books&ie=UTF8&qid=1347369355&sr=1-1

もう一冊読みました。「アルケミスト」という本です。これはこれで珍しくこういう類の本を読みました。なんだかもう、純粋という感じです。まっすぐな少年、夢にまっすぐ向かって走って、いろんな人を惹きつけて、という物語です。

でもこの話の中にたくさんのエッセンスが詰まっています。小学生が読んでも楽しいし、大人になって読んでも楽しめる。二度美味しい。そして大人になってから読むと味わい深い、きっとそんな本です。素敵な物語でした。なぜ少年はこうも人を惹きつけられていけたのだろう。1つ1つの出逢いの中でなぜこんなにも前に進めたんだろう。途中でとてもファンタスティックな展開になっていきますが、不思議と魅了されます。

こうやって平易な言葉でたくさんのものを詰められるというのは素敵なことだなぁと思うのです。

Amazon.co.jp： アルケミスト―夢を旅した少年 (角川文庫―角川文庫ソフィア): パウロ コエーリョ,Paulo Coelho,山川 紘矢,山川 亜希子: 本
http://www.amazon.co.jp/%E3%82%A2%E3%83%AB%E3%82%B1%E3%83%9F%E3%82%B9%E3%83%88%E2%80%95%E5%A4%A2%E3%82%92%E6%97%85%E3%81%97%E3%81%9F%E5%B0%91%E5%B9%B4-%E8%A7%92%E5%B7%9D%E6%96%87%E5%BA%AB%E2%80%95%E8%A7%92%E5%B7%9D%E6%96%87%E5%BA%AB%E3%82%BD%E3%83%95%E3%82%A3%E3%82%A2-%E3%83%91%E3%82%A6%E3%83%AD-%E3%82%B3%E3%82%A8%E3%83%BC%E3%83%AA%E3%83%A7/dp/404275001X

------

余談ですが、先週の月曜日に全社朝会でスピーチする機会がありました。ローテーションで回ってくるので、前回は僕の番だったのです。そこで時間に関する話をしました。教える側と、教えられる側の時間の話。今話している目の前の同僚も、たくさんの背景を抱えてここに立っている、という話。祖母の話。一日一日を大切にしましょう、という話。

文章を読む、人の話を聴く、プログラムを読む。なんだかそんな受け手側ばかりになっていると、ありがたみを忘れてしまいそうになります。

逆に、教えてばかり、書いてばかり、伝えてばかりでも、伝えることに鈍感になってしまいます。

そんな当たり前のことなんですが、意外と言われると自意識には存在していないものなのかも知れません。なので、最近は毎日そんなことを1回は思うようにしています。

中途半端な余談でした。
時刻:

2012/08/26

「データビジュアライゼーションの美」が面白い


   


デビッド・マキャンドレス 「データビジュアライゼーションの美」 | Video on TED.com http://www.ted.com/talks/lang/ja/david_mccandless_the_beauty_of_data_visualization.html



TEDのビデオを見ていました。 

毎日データに触っているのだけれど、僕は視覚化に疎いです。

視覚化すると気がつくことがよくあります。単純にExcelでデータを並べてグラフにしただけで傾向がつかめた、とかは普段からよくあることなのではないかと思います。

このビデオでプレゼンをしているデビッド・マキャンドレスさんはもともとプログラマで、今はData Journalistをしているそう。気になったところを箇条書きで紹介。


  • "Data is the new oil."ならぬ、"Data is the new soil." 
  • 人間は視覚から取り込んだ情報を「言葉」「概念」といった領域に落としこんでいく。
  • 人間は視覚からのほうが他の知覚よりも情報を得るスピードが早く、毎日視覚からデータを多く得ている。 
  • ヴィジュアルを作ることは、知識を凝縮するということ。 
  • データは相対的なものの見方をしないと誤った印象を与えてしまう。 


ネットに情報が詰まっていて、関連を持って保持されているということはやっぱり面白いことだよな、と改めて思った次第です。ビデオを見ていただければ、そのスライドから色々伝わるかと思います。
時刻:

可能性に打ちひしがれていてもどうしようもない

「私には可能性がたくさんある」というのは決して良い面ばかりではない。

今日、フットサルをしてきた。久々にしっかりと運動をした。高校まではずっと部活でサッカーをやっていたが、大学に入ってからはギターばかり弾いていたのでほとんどサッカーをしていなかった。こうして久々にサッカーをしてみると楽しいものだ。東京は暑いが、サッカーの面白みはどこでやっても変わらない。球を蹴るのが純粋に楽しい。

さっきご飯を食べながら、キルケゴールの「死に至る病」を読み直していた。重い題名だが、死というよりは絶望について述べられている本だ。ここの本の文脈では絶望というのは、キリスト教で言うところの神様が超えられるもので、一般人の我々には常に存在しているものだ。

「死に至る病」ではざっくり言うと、「絶望と向き合わないと絶望を抜けられないのだよ」という示唆を与えてくれる。

ひとは何もしなければ可能性に満ち溢れている、と僕はよく感じていた。制限されないからだ。中学生の頃だろうか、僕自身が何者かになろうとすることが、かえって自分を狭めてしまうのではないだろうかという念に駆られていた。「プロサッカー選手になる」でも、「大学教授になる」でも、ましてやプログラマになるというのでもなく、ただただ自分が何者であり、何になるのかを枠にはめることが、自分にとってはマイナスなのではないだろうかと、切に感じていたのだ。それも日常のあらゆる場面で。僕は昔から算数、そして数学が得意だったけれど、だからといって数学ばかりやっているのもなぜか良い気持ちにはならなかった。可能性を狭めているような気がしたからだ。なんだったら英語を話せたほうがいろんな人と会って価値観を広げられるかもしれないし、もしかしたらもっとサッカー部の活動に打ち込むほうが良いのかもしれない。などと、様々なことに手を出しては、可能性を広めたような気になっていたのだ。

進路を決めるということも可能性を狭めることだと思っていた。例えば、大学。例えば、仕事選び。何かに自分をはめてしまえば、自分はその枠のなかの存在になる。僕はなぜかそれがずっと嫌だった。ギターを始めたのはそういうものに対するある種の衝動だった。別のことに没頭したくなるのだ。

でもね。やらなければわからないものだ。いつからだろう。去年事業をやり始めてからかも知れない。もしくは大学のサークルで身を粉にしたからかもしれない。わからない。でもね、面白さとか、好きなこととか、その先にある楽しみとか、どんな人と会えるかとか、やってみないとわからないんです。行動しなきゃわからない。それって可能性を狭めてるのかなって思うと、全然そうじゃないんですね。当たり前のことが、僕はわかっていなかった。

そんなことを考えながら、今の自分の状況について改めて考えたりしていた。キルケゴールはまた良い示唆を送ってくれている。「絶望がなければ可能性は見えない」。キツイ状況の時って、あとからみると自分が一歩踏み出していたということに気がつく。僕は今、あまり自分を追い込んでない。余裕がある。バランスをとってる。それが今の僕の成長の妨げ、というよりは自分が「学ぶべき」と思っていることに対して自分が追いつけていない理由なのかもしれないな、と思った。
時刻:

2012/08/16

関連性と記憶に関する覚書

文脈の中でものを覚え、使いながら本質を探る。手探りだけれども、ただの手探りではなく、少しずつ何かを使いこなそうとする。そういう場面に最近触れることが多くなった。

何らかの事象を記憶しようとしたとき、別の事象、もしくはそれらが属する集合といった視点でものごとを覚えようとしたことは誰でもあるだろう。中学校のテストで歴史の年号を語呂合わせで覚えようとするのは分かりやすい関連性の例だ。他にも以下のようなものには触れる機会が多いのではないかと思う。

  • 英単語を意味とスペルだけではなく、特徴的な文章と共に覚える。
  • 漢字を読み方と書き方だけでなく、その由来と共に暗記する。
  • 数学の公式を語呂合わせで覚える。2次方程式の解の公式などは良い例。
関連性をもたせると覚えやすい。最近だと私は数学ガールを読んでいるのだが（ガロア理論はまだ途中。他は全部読んだ。）、数式と共に本の中での楽しい会話と風景が描写されることが増えた。覚えるものの情報の総量は、事象そのものを記憶するよりも多くなるにも関わらず、だ。これはある種、人の記憶容量の大きさを示しているのかもしれない。コンピュータだって記憶という観点からは、もっと富豪的に入れてあげたほうが覚えてくれるのかもしれない。

普段何かの情報を得ようとするとき、私は関連性を常に意識している。本を読む、人から聴く、Webで見つける。どんな場合であれ、その情報に触れたのが、どのような場所で、どのような人から発せられ、そのとき近しい出来事で何が起きており、過去のものとどんな関連性があるのか。そしてその情報の中にはいくつのファクターがあり、それら同士がどのように影響しているのか。そういうことを1つのイメージに起こしながら情報を受け取る癖がついている。そして大体興味のないものというのは気がついたら忘れている。頭が何段もの引き出しになっているならば、使われない情報は下の方の引き出しの奥の方にしまわれていっているのかもしれない。

昔学んでいた速読にもそういう手法が背景にあった（あれは事象を一気に頭の中に自然に取り込んで、関連性を見出すことを頭に任せるというトレーニングが大事だった）。マインドマップはより意識的に構造を整理する必要があった。一回一回書きだすのは大変なのだけれど、体から出てくる偶発性によってまた記憶のための関連性が生まれる。例えばPCじゃなくて手書きをすると、幾何学的に整った図形にはならない（なるはずがない）が、癖のある字なり図ができあがる。手書きの文字は図なのではないかと最近は思うほどだ。手書きの文字・図は予期せぬ関連性を生み出す。だから記憶に残る。そして記憶に残るだけではなく、関連性を引っ張りだしてきて、発想を広げてくれる。こういう認識に私は確信をもっているので、何かを多少自由に思い巡らせたい時には紙とペンを持つ。

---

ここまでの話は当たり前だ、と感じる人も少なくないと思う。最近の僕の課題はこれをどう人に伝えるかということだ。話し合いや、他の人の学習にもこういう考え方、前提を共有しておきたいものだ。

ふとエンジニアの同期から「業務外のことをどのように学んでいるか」という問いかけがあった。そういえば自分はどうしているのだろうな、と考えてみた。普段から、学ぶことを仕事に活かし、仕事で今学びたいことを使うようにしているので、そもそも業務外という括りが的を得ていないのかもしれない。だがそれだと答えにならない。もう一つ深ぼってみると、業務外のことを学ぶ、というのはおそらく、学んでみたいことを学ぶ、ということにこの場合言い換えられるのではないだろうかと考えられた。

エンジニアとしては色々な学び方の方向性が考えられる。もっと最適化のアルゴリズムを知りたい、JavaScriptを使ってなめらかなUIを作れるようになりたい、システムコールについて深掘りしたい、など人によって様々だ。私は好きなように学べばいいと思うし、好きな事を学ぶことが一番健康的でその人のためになると思っている。（逆に言うと好きな事をやるなら、その学習に自分自身で責任を負うべきだ、とも思っている。それがためになる、ということの裏返しなのかもしれない。）そしてその学びたいことに行き着くきっかけがあるはずだ。学びたいことには2種類ある。新しいことを知りたいというケースと、深く知っておきたいというケースだ。

新しいことを学ぶというのは案外コストが大きい。調べていると知らないことばかりたくさんでてくる。何かを学び始めるにはその学ぶことを精査すべきだ。精査して、もし自分がそれを学んでためになりそうで、どこかで活きてきそうならそれを学べばいい。ただ、この活きてきそう、というのは曖昧な境界だ。これはお金を稼ぐという意味なのだろうか。はたまた、知的な興味をより刺激して、新しい世界が見えそうだという意味なのだろうか。この判断は曖昧だ。あまりに一般に使われている技術から外れていなければ、そんなに心配しなくても活かす機会もあるだろう。自分が新しいことを学ぶときにはそういうラインでものを考えているようだ。

深掘りする場合には戦略を練る。今知っているのはその技術のどこまでなのだろうか。その技術はこれから先どこに向かうのだろうか。そういうことをまず俯瞰する。俯瞰して、自分のスキルの具合に検討をつけてみて深掘りすることに意義があるのであれば、本格的にどの方向に向かっていくかを決める。それは必ず技術のコアな方向に向かっていなければならないと思うし、自然とそういう方向に興味が向いていくものなのではないかと思う。

こう文章を書いていると、どういう方向に自分が学んでいけばよいかを相談できる人がいる環境というのはそうではない環境と比べて優れているといえるということに気がついた。相談できる人はきっと、いろんな関連の中から物事を学んできているはずだ。そのように学んできていれば、逆に自分が教えるときにも、適切なアドバイスをすることができるようになるのではないだろうか。


時刻:

2012/08/14

自戒

4日間ほど実家に帰省していた。帰省をすると考え事をする。そのときのメモを後のために残しておく。

  • 環境によって自分を制限しない
  • 人によって自分を縛らない
  • 領域によって自分を狭めない
4月からの環境に甘えていた部分はないか。ゼロベースで鳥瞰して、今日までの仕事を生産していた。結果、自分の想像よりまったくもって不十分だった。Data Scientistとして仕事をしたいのに、解析基盤づくりばかりしていた。僕に足りないのは分析スキルと分析の経験。そのための時間と環境を自分で作ることに時間を割きすぎた。もっと貪欲にやりたい。

  • 友達を大切にする
  • 礼儀を正す
当たり前だけれども、蔑ろにしてしまった部分があったと思うところが多々ある。指摘してくれる人はいない。自ら正す。

  • 尊敬なしには学べない
学ぶ際には、相手を尊敬する。敬う。その姿勢が足りなかった。今自分が深く省みなければならない点はここだ。年齢も立場も関係なく、相手を敬わなければ学べない。それによって学ぶ機会を多く失っていたと感じられた時間が多かった。だからといって自分から何か生めていたかというと、そうとも感じていない。なんて無意義な時間を作ってしまったのだろう。

仕事や生活の棚卸をした。まだまだ足りないところばかりだ。
時刻:

2012/07/30

読書した。＆サービス分析に関するメモ書き。

今日は代休だったので、のんびりと過ごしていた。朝は銀行関連の手続きをして、昼は概ね勉強していた。数学ガールのガロア群論を半分ほど読んだ。また、アルケミストを読み始めた。

最近データに触れてばかりいる。モデルを考えるときは数学的な世界に一回潜り込まなければならないが、やはり事業目線で何が本質的に必要なのかを洞察する力というのは大事だということも改めて感じている。頭のトレーニングとして、もし自分が今もサービスを運営していたら何を分析し、何をしていただろうということを風呂に入りながら考えていたので、メモしておく。前提として、

  • 自分たちのサービスのゴールがわかっている

ものとする。

ユーザ行動の分析に関する再考

まずは、ユーザを追いかけよう。自分のページでユーザが何をやっているのかを確かめよう。当時はmixpanelやGoogle Analyticsを使って解析していたが、自分たちだからこその追いかけ方がある。それをアプリケーションの設計段階からできれば組み込んでおくこと。（脊髄反射で組み込んでしまうくらいがちょうどいいと最近は思っている。）

具体的にはアプリケーションログを出力して、その解析を適当な周期で行うことになる。自分たちで解析しよう。ユーザの行動はログでしか追えないと思うくらい、ログを追おう。実際のところ自分たちのDBに入っているユーザのデータとログを組み合わせれば、全てのユーザ行動はつかめる。

チームメンバーに共有する。そしてまた仮説を立てる。

問題はどこを問題とし、課題とし、紐解いていくかだ。まずは鳥瞰して、次に虫の眼で見よう。全体の傾向を掴んで、それをまずはチームに共有しよう。チームに共有したら、気づきが絶対にあるはずだ。それを元に詳細な分析をしていこう。ユーザがどの程度アクティブであるかを知ろう。どの程度というのは時間軸で見れば良い。時間軸で見て、ある傾向があれば次はユーザ属性ごとに見よう。そして、サイトに特化したユーザ属性について、さらに切り分けよう。どういうカテゴリにコンテンツに惹きつけられているユーザが、どういう行動をしているだろうか。何か特徴は無いだろうか。

ユーザ目線からコンテンツを分析することに関する再考

ユーザ行動を追えたら、コンテンツを分析していく。

コンテンツのカテゴリ分けは必要か？

コンテンツの分析は明示的なカテゴリに左右されがちだが、運営側の都合で設けたカテゴリは本質的ではない場合もある。明示的なカテゴリを一旦忘れて分析することも必要になってくるだろう。

カテゴライズされているものについては、まず自分たちで作ったカテゴリが必要であるかどうかを検証しよう。カテゴリというのはユーザに運営側から伝えるメッセージだ。ユーザは勝手にカテゴリ分けされているものをカテゴリとして判断してしまう。でもそれは理にかなった振る舞いになっているだろうか。大いに検証する必要がある。大抵の場合、サービスにはコンテンツが少ないのだ。ただただ、デザイン上の理由で、運営上の理由で、綺麗に見せたいがためにカテゴリ分けするほうがよっぽど損をするときだってあるのだ。

ユーザに基づいたコンテンツのあり方を検討するために

どのユーザが何を見て、どのようなコンテンツについてよく見ているだろう。

ユーザの趣向性が分かったと仮定して、ユーザ行動からコンテンツに加算していく。そのコンテンツは、なぜそのユーザに好かれたのか、反応を示しているのかということについて、仮説を立てよう。それはコンテンツを分析するためのヒントになる。

また、ユーザ自身から発せられたメッセージからヒントを得るのも良い。たとえば、検索。たとえば、コメント。ユーザが自由に行動する場所があって、考えていること、もしくは望んでいることを書いてくれているなら、それを活かさない手は無い。

分析はユーザに見えなくてよい。シンプルに快適に。

ユーザが欲しい物を、とにかく一番に出そう。クールさとパーソナライズの両立は大変だが、ユーザがそのページに来た瞬間にユーザのほしいものを届ければ、ユーザをファンに出来る。「そこにいけば面白いものが待っている」のか、「すぐに便利なものを見つけられる」のか、「安くて良い物が見つかる」のかどれでも良いのだが、ユーザのほしいものをそのサービスでだけ届けてあげる。できれば簡潔に。そうすれば、また来てくれる。

分析した結果は、チームにとっても自分にとっても、さらに有益なものとして返ってくるだろう。

書いてはみたが、一般に定義されている言葉を使わないで平易に説明するのはやはり難しい。こういう考察は良くない。

時刻:

2012/07/29

今日やったこと

今日はRの勉強をしつつ、分布について調べていた。手元で手軽に分布に応じた乱数を発生させられるのは、勉強のためにとても良い。

それと、ちゃんと調べてはいないが、EiganとLAPACKというのを知った。


まったく統計には関係ないが、FuelPHPの2.0のalpha/betaが出ていた。 

明日は休みなので、引き続きRの勉強をする。あとは数学ガールのガロア群論も読み終えたい。
時刻:

2012/07/24

Rのマインドマップ

とてもわかりやすいマインドマップがあったので紹介します。Rに関するマインドマップです。よくまとまってます。

R: A Language and Environment for Statistic... - MindMeister 思考マップ http://www.mindmeister.com/ja/37638437/r

Rの起源となったS言語についてや、Rが成り立っているエコシステムについてわかりやすくまとめられています。知らなかったツール類もまとめて見つけることができました。 
時刻:

チーム開発について最近思うこと

久々にとあるチームにジョインして、後から入る人間としてプロダクト開発に携わる機会に恵まれました。

今までは自分の作ったシステムに人を受け入れるというケースがほとんどだったので、今こういうフェーズで客観的にチーム開発について考える機会を設けられたことは良いことです。自戒を込めて、振り返ります。


何かをシステムを作るとき、自分で全体像を掴めない状況で開発などできません。設計も出来ません。誰かの権限の中で、部分的に触るのも無理です。「この範囲はあなたの責任でやってください」と言われるのが一番ありがたいし、やりやすいのです。

任せられている範囲内であれば、自分なりにそのプロダクトに則しつつ、少しずつ部分的に担当している範囲を改良していけるものだと思うのです。しかし、どの範囲まで責任をもてば良いのかわからずに、どうして自分が考慮すべき範囲を判断することができるのでしょう。そういう憂慮すべきことが頭の中を支配して、開発の手は止まってしまいます。

なんだか最近はそういう環境に苛まれています。そういう環境でなんとか自分のやるべき範囲を無理やり自己判断して取り組んだ後、何らかの不具合があれば容赦なく責任は降ってくるのです。そんなものは理不尽以外の何物でも無いです。

僕がチーム開発時に望むのは、
  • どの範囲に責任を持つべきか明確であること
  • サンドボックスが提供されていること
  • 「改善」については常に受け入れ可能であること
  • なぜその範囲を開発しなければならないかを知れる、もしくは調べられる環境であること
  • どこまでが取り消し可能で、どこからが取り消し不可能な操作なのかが明確になっていること
ということです。

どこからどこまでを壊していいのか。どの範囲を私は改善すれば良いのか。そしてどこまで改善して良いのか。何を考慮すべきなのか。システムの妥当性を検証するために十分な情報は私に与えられただろうか。そしてこの操作はクリティカルなものなのだろうか。

そういうものを提供するということは、安心して健全な開発をするためには欠かせないものなのだと改めて感じている次第です。

参考:
Joel on Software - http://japanese.joelonsoftware.com
時刻:

2012/07/16

WordPressからBloggerに移行してみました。
時刻:

2012/06/13

2012年度人工知能学会( #jsai2012 )の気になるセッション

今日から人工知能学会が始まりました。去年は参加しましたが、今年は仕事に就いたということもあり（正確には去年もしていたけれど大学院生だった）、現地には行きません。資料を見て気になったものを幾つかピックアップしておきます。

NoSQLデータベースokuyamaの構造の解説。

Kachakoの解説。Apache UIMA - Apache UIMAに準拠している。

ペアワイズ類似度の変形。

どのような方法で次元削除をしているのかが気になります.

異常ログと相関の高いログを抽出している。どのような要素をもって異常ログとみなしているのかが気になります。

概要より

LODで多く用いられているSPARQLのような問い合わせ言語は，事前にスキーマについての理解がなければ適切な検索クエリを作成することができない．そこで我々が提案しているファセット検索を拡張した多面的メタデータ検索をLODに適用することで，スキーマの理解なしに多様な条件を用いたLOD検索を実現するとともに，LODの特徴を利用した複数のEndpointを横断する関連検索も実現する．

"スキーマの理解なしに"というところが、確かに必要な点だと思います。LODを利用する際に一番困るのは、利用したいデータセットのスキーマがわからないことです。（スキーマレスなようで、スキーマはある。幅広いスキーマを許容する枠組みがLOD、というかRDFの構造だと個人的に思っています。）なので、こういうアプローチは気になるところです。

推薦手法についてじっくり読みたい。

Amebaのデータを利用してユーザ推薦手法を検討している。

BioSPARQL.orgの話。

 

JSAIの資料はjsai2012 Scheduleにて公開されているので、ひとまずPDFを読んでおきたいと思います。
時刻:

2012/05/01

節目と音楽


http://kawakei.cocolog-nifty.com/photos/uncategorized/2008/06/05/kpict2660.jpgより


もう5月ですね。昨日は結婚式で演奏してきました。僕は演奏のみしに行きましたが、やはり節目というのは鮮やかです。例えば子供が生まれて親戚が一人増えたり、いとこが高校に入学したり、年齢がちょうど5回巡って還暦になったり。そういう時間的なものが作り出す物事が、最近はより人間的で尊く感じるようになりました。

演奏は明治記念館で行いました。明治記念館に行くのは2回目、3年ほど前に演奏で行きました。そのときは確かサークルのメンバーと一緒に行った記憶があります。時々こうして呼ばれて演奏することというのがあるのです。ありがたいことです。毎回、演奏に対する感覚というのが変化しています。「させていただく」から、「時間をつくる」に。そして「時間をつくる」から、「音楽を愉しむ」へと、僕自身の経験や心の余裕と共に変化しています。

思えば催事ごとにはいつも音楽があるものです。自分が演奏をしない時でも、その場その場でどんな音楽が流れているのかに注目してしまいます。きっとそこで流れている音は、その場所の空間と、時間が在るということを恣意的に表現しようとしているのではないかと、勘ぐりたくなってしまうのです。運営側からしたら、僕は面倒な客かもしれません。でもたまにあるのです。恣意的ではなく自然に流れているときが。そういうときには、感嘆の意を施設の方に届けたくなるものです。ほんと、すごいんですよ。場所と時間に溶け込む音楽というのが、たまにあるんです。

そんなことを思いながら、なるべく自然に演奏をしようと思っていた一日でした。いや、しようと思うことが既に自然発生的ではないのでは。何も考えないということは難しい。難しいということは既に意識をしてしまっているということで。時間は勝手に経つものですから、それについて正面から考えること自体が不恰好なのかもしれません。
時刻:

2012/04/20

読書について

自分のための時間ができたら、読書をしよう。そんな場面に出会うことが増えました。季節は春、絶好の学びだし日和です。僕も研修の真っ只中にあり、そうした同期の話を聴きつつ、毎日時間が過ぎていきます。

以前、ぐっと読書について近づくことがありました。僕にとって読書と近づく時期というのは、心に迷いがあったり、自分の不甲斐なさを感じる時が多いです。何かを求めて本を読んでいます。本を読むときはいつもそうです。何かを学ぶために本を読んでいます。どこか路頭に迷いそうな、とぼとぼと帰り道を歩きながら、考えていることを確かめるためにも本と向き合うことがあります。

ここでは、読書について、慣れていないと感じている誰かのために書いてみようと思います。ここでは学習のための読書について自分なりに書いてみたいと思います。

失敗したこと



どんな本にも、存在している理由があります。そして、書き手がいます。執筆者というのも様々で、本の内容も無数にあります。その中から、自分のためになる１冊を選んで、対峙する。本を読むという行為はいつもそうです。

なぜ本を読みますか。１冊１冊に、読む理由は異なるはずです。人生観を変えるために読む本もあれば、知識を得るために読む本もあります。

僕は一時期、ビジネス畑の本にはまり、１ヶ月に３万円程度をビジネス本に注ぎ込むという生活をしていたときもありました。そのときはそのときで良かったです。知識が増えていると思いました。そのころ僕は学生でした。今の自分に活きているところはもちろんありますし、たしかに知識は残ったように思います。しかしそのころは釈然としませんでした。純粋な興味で読み始めたものが、今必要なものではなかったからです。自分で学ぼうとして選んだ本が、いつの間にか見栄をはるための読書になってしまったかのようでした。若気の至りだったのかもしれません。その後、哲学書にはまり、とりわけドイツの哲学に惹かれました。そして哲学の起源に興味をもっていきました。どんどん興味は移り変わって、読書を楽しみ、自分の趣向性の移り変わりをもう一人の自分が楽しんで見ているかのような感覚になりました。

何か自分を探求するために読書をするということも、あってしかるべきものなのかもしれません。僕は人の考えについての興味が人一倍大きいようで、それについての知識を本から得ました。そして人についてより深く考えられるようになったと感じています。いつも主体的でした。

では失敗したように感じている、ビジネス本の読書というのはどんなものだったのだろうか。なぜだったのでしょう。主体的に学ぼうとしたのに、学べませんでした。頭の痛い問題でした。

何のために本を読むのか



研修で、良い示唆がありました。仕事というのは、重要であるが緊急なものに追われがちで、重要であるが緊急でないものに対して時間をかけづらくなってしまう。重要であるが、緊急性の高くないもの。これには、今の僕の段階においてだいじなもの、学習が含まれます。意図的にこの時間をかけなければ、能力は身につかない。当たり前のことを見直す良い機会でした。

しかし、いざ学習をする時間ができると、意外と何をしていいかわからなくなるものなのかもしれません。学習、そうだ、本を読もう。動機としては良いと思いますが、本質的ではないです。それは、余った時間を有効に利用していると自分に言い訳しようとしている場合がほとんどです。理由のない読書なんて、結局のところ必要ありません。自己満足に終わらず、学習をするために読書をする。その覚悟がないと、結局のところ時間の無駄に終わってしまうというのが、多くの場合ではないかと、色々な人の話を聞いていて思うのです。

１冊１冊と向き合う度に、自分はなぜこの本を読むのか。この本を通じて、何を学ぼうとしているのかを明確にすることは大事です。僕は本の表紙を開く前に、かならずそのことを考えるようにしています。例えそこで１分費やしても、読了後の成果は全く異なるものになることを知っているからです。

本を読めているか？



実際に取り組む本が決まり、読み始めました。読むこと、それ自体が目的なわけではありません。最終的に何を得るのかが大事です。読んでいる最中に僕が常に意識していることは以下のことです。

・結局著者は何を主張したいのか
・主題は何か
・主題に対してどのように理由付けされているか。著者の意図は。
・従来手法、又は他の考えと比較して何が違うのか
・それに対する私の考えは何か。その根拠は何か。

シンプルにするとこれらに答えられれば読書の目的は概ね達成できるように思います。シンプルですが、いざ尋ねられると答えられないかもしれません。実際に身近な人に、今読んでいる本について上記の質問をしてもらえればわかりやすいと思います。わかりやすく自分の言葉にして説明できなければ、結局その本から自分の身になることは何一つ得られていません。ましてや、その知識を利用して他のことに活かし、他の人に影響することなど到底出来ないものだと思います。どれだけシビアに、積極的に読書できているかをその都度確認することは、どんな読書でも大事です。

１冊の本の世界に閉じない



１冊の本は、新しい視点を開くトリガーに成り得ます。新しい視点を得る。これは本の魅力です。今まで考えようともしなかったことが、読書のあとではその世界の大きさを知ることになる。そんな体験を何度もしました。日本の歴史を学べば戦争の価値観についてさらに追求したくなり、インターネットの起源について学べばそれを考えついた人の思想をより追って行きたくなるものです。

どんな本でも、１冊のなかに森羅万象を詰め込むことなんてできません。著者は神様じゃありません。その文章の背景に、いろいろな要素があります。その人が読んだ本があります。今はWikipediaがあります。Googleで調べることも、身近な友達に聞くこともできます。興味をもった自分は、その世界に深く携わっている人の中でもっとも未熟なはずです。例え、誰かから薦められた１冊だったからといって、盲目的にその１冊だけを信じることは、偏った見識に捉えられることにほかなりません。その分野について知らなければならないのであれば、あらゆる可能性からそれについて調べるべきです。でも、いきなり全てを調べることはできません。それで全く構わないはずです。なぜなら、世の中のどんな人も、そうして学習し始めているはずです。本を読み始めた時と同じように、興味のあるものから調べていけばいいです。難しく考える必要は全くありません。

本の世界から飛び出た時に必要な物は、最初に本を読んだ時にその分野の要素をつかむことです。できれば、メインとなるトピックを掴んでおくと、その後の探索が行いやすいでしょう。常に鳥瞰することを意識すると、どんな本でも接し方が変わります。ミクロの目も大事ですが、マクロの目がないと生きて来ません。自分の意見をより確固としたものにするには、そうした検証を加えてからでも遅くはないはずです。これによって初めて、その分野の人たちと会話ができる入り口に立てるのではないかと思います。


読書は楽しいです。
時刻:

2012/04/13

桜との比較

桜ってすごい。

入社して、約10日が経ちました。新鮮なことがあります。上司がいるということです。今まで、自分でやることをすべて決めてきました。何を作るか、何を学ぶか、何を考えるべきか。部下という言葉は好きではありません。でも、チームなら好きです。何を考えるべきか。そういうことを教えることのできる人というのはやはり素敵なものです。

僕も新入社員として研修を受けさせていただくことになり、早2週間ほどが経ったことになります。研修という形すら、新鮮なのです。研修を形作る側の方々のことを考えてしまいます。新入社員というのは、現時点でコストでしか無く、その事実を受け止めた上で、研修なり学習をしていくというのが、新卒の定めであると感じます。

思えば、まだ売り上げを上げていない、利益を出せていない人たちが給料を貰うということすら、違和感を感じるのです。儲けることができない人たちがなぜ給料を貰えるのか。会社というのは実に不思議な仕組みです。時間を減ることを前提として、僕らは給料を戴いているのです。なので、研修を受けているだけで給料をいただくということは、畏怖であり、恐縮であり、今後への期待を背負っているということに他ならない、という感覚に陥るものなのではないかと思います。少なくとも、僕はその感覚が今一番大きいです。

さて。エンジニアという立場を通して、仕事を通して、学習というのは通らざるをえない道です。いやしかし、この言い方に僕は違和感を覚えます。僕は学習が楽しいのです。何なら四六時中、パソコンの前でプログラムについて考えていることは全く苦ではありません、むしろそうしていたいという気持ちになることもあります。学習をすること。それが仕事になっているならばそうしているのかもしれません。

しかし、何時の頃からか、学習するだけでは生きていけないと思った自分がいます。不思議なものです。大学にいるだけでは感じなかったことなのかもしれません。

シンプルに言うと、「誰かの役にたったのか」ということ。それだけしか今は考えていません。これもまた、不思議なものです。エンジニアリングについてどんどん知識は付いてきていて、付き合う人も増えてきて、少しずつ責任も増えてきて、歳を重ねてきて、そう思うのです。そういうものなのかもしれません。理由はわかりません。でもそう思います。

そういう文脈において。誰かに考えさせることができるという力。これは何事にも代えがたいものではないかと思います。僕の興味は大学に入ってからどんどん移り変わって、結局は人を中心に巡っていました。簡潔に言えば、

・ビジネスについて知りたい（ビジネス本ばかり読む
・人が何を考えているか知りたい（心理学ばかり深掘りする
・音楽ってすごい（音楽の価値について考え始める
・音楽って哲学だ。（認識について考え始める
・哲学考えた人ってすごい（また人間について考え始める
・ものをつくる人ってすごい（エンジニアリングに戻る
・チームって面白い（スタートアップは面白い
・誰かの想いを叶えることって面白い。エンジニアリングはすごい。

というような過程を経てきました。（ざっくり過ぎますね。）誰のために何ができるか。そんなことをいつも考えています。

まだわかりません。でも、また春になって。色々な考え事をして、ふと帰り道に家の近くの桜の木を見ていて、自然であるということは本当にすごいことだなと思うのです。咲いているだけなのに、思慮に耽らされてしまいました。まだまだ学ぶことは多いと感じた一日でした。
時刻:

2012/04/03

入社しました

4月から株式会社VOYAGE GROUPに入社しました。

まだまだ未熟者ですが、皆様どうぞよろしくお願いいたします。今月は研修が続きますが、早く業務につきたいです。
時刻:

2012/04/01

卒業と退職

昨日、慶應義塾大学理工学研究科を卒業しました。

学部と大学院合わせて6年間を日吉と矢上で過ごしました。大学院に居た、というよりは大学4年から修士2年までは研究室に居たというほうが事実を的確に表しているかもしれません。研究室メンバーに恵まれ、良い環境で研究をすることができました。修士2年になってからは研究と並行して、trippieceの事業をはじめとして、外に出て何かしらのプロジェクトを行う日が続きました。そんなときでも、研究室に戻ればいつでも気のおけない研究室メンバーがいてくれたことは、いつも僕の心の支えでした。そして研究を通して、僕はWebについて複数の側面から触れることが出来ました。研究のメインは3年間を通してセマンティックWeb、そして去年1年間はLinked Dataに特化して研究を行いました。学問と実践の両方で経験を積めたことは、今の僕の考えや行動の指針に大きな影響を与えています。3年間指導してくださった先生と、一緒に研究してきたメンバーには本当に感謝しています。

研究で得た知識は、気がつけば実践で活きていました。そして実践で得た知識もまた、研究に活きていました。

もう一つ区切りがあります。以前から何回か触れていましたが、trippieceの事業から僕は身を引きます。何人かの方からtrippieceに残らないのかと聞かれることも多かったので、ここでご報告させてください。

自分が作り始めた、大好きなサービス・大好きなメンバーと離れることは正直辛いものです。trippieceを始めてから約1年が経ちました。始めた最初の頃は何一つ形のなかったサービスを作りました。実は最初は僕自身、自分の作っているサービスが本当に価値を生み出せるものなのかわかりませんでした。今思うとその当時は、必死にコードを書きましたが、ものづくりに没頭しているとは言えない状態でした。最初の半年間は、そういう齟齬との戦いでした。最初はスタートアップを始めたというだけで注目されるものですが、メンバーのプレッシャーは日々高まり、チームとして結果を出すことへの焦燥感と義務感が混じり合ったような気持ちを共有しているような状態でした。

半年経って、僕らはしっかりと話し合いをし、初めて自分たちの作るべきプロダクトの像を掴みました。そしてその4カ月後、フルリニューアルを行いました。今年の1月のことでした。コードベースも全面的にブラッシュアップしました。やっと自分たちが思っているプロダクトの原型を作ることができたと思っています。

フルリニューアル以降の僕のtrippieceでの仕事は、trippieceの開発基盤を徹底的に整えることでした。次の大きな機能を入れるまでに、素早く仕事を行うことのできる環境を作ることを自分自身の仕事にしました。最近の仕事は以下のようなものです。

  • コードのリファクタリング

  • アプリケーションリファレンスの作成

  • 開発用チュートリアル(機能追加、バージョン管理)

  • データベースマイグレーションの追加

  • コアコントローラの再設計・再実装

  • サーバ設定に関するドキュメント執筆

  • 日々追加されるコードのレビュー

  • ユーザ行動の分析

  • 毎日、リリース


自分でコードを書く時間は徐々に減っていき、人に伝え、メンバーが仕事をしやすくするために費やす時間が増えていきました。コードベースの保守性も高まり、ある程度の機能であれば僕自身が実装しなくても仕事が進むようになりました。先日のUI変更は僕はまったくコードを触りませんでした。

こうしてプロダクトの運用を続けていく中で、毎日気づきがたくさんありました。

自分の作っているものに魅力を100%感じられないと、結果を生み出すことのできないプロダクトを産み出してしまうものなのかもしれません。コードを書くという行為はエンジニアの仕事ですが、それは時として逃げの手段にもなりかねます。納得していないものを作る、無駄なものを作っている、作業をしているフリをする。コードを書くことで自分の責任から逃げることができるのも、またエンジニアなのではないかと思います。そして全ては結果となって自分に返ってきます。現実を直視し、ユーザの課題に対して最大限効果的な施策を、最小限の機能で実現すること。この繰り返しが、1年を通しての僕の基本でした。

スタートアップにおけるエンジニアの役割は、エンジニアリングに関すること全てです。しかし、限られた時間で機能を追加し続けていく中で、僕自身のエンジニアリングは視野を広げる余裕を持つことができなくなってきました。trippieceでは毎日最低1回、何かしらの変更をリリースしていました。trippieceではある時期から、毎日アプリケーションを変更することを日課にしていました。ユーザにとって何も変更されていないように見える部分でも、１つ１つのコードの質を上げ、良くしていくことに専念していました。コーディングについてはそれで良かったのですが、オペレーションに関して僕は未熟でした。ミドルウェアについての知識がなく、毎回手探り状態でした。今はAmazon EC2に救われていますが、コーディング以外の面で僕は攻めのエンジニアリングをできなくなっていました。

ユーザの課題を解決するために、施策を行うこと。これをロジカルに落とし込み僕の得意とするところです。概してエンジニアというのは、時間をムダにすることを嫌います。僕もその例に漏れず、極めて仕事の時間感覚については厳しくなっていました。いわゆるビジネスサイドのポジションについている人というのは大局的で理想的な話にフォーカスしがちですが、僕達のようなWebサービスの運営者は、プロダクトそのものを通してしか、ユーザに自分たちの考えを伝えることはできません。その厳しさを味わった1年間でもありました。

たくさんメンバーと話をして、機能を作っては消し、そしてまた作り変えるということを続け、走り続けた1年間でした。この経験は今こうして言葉にしてみても、実際に携わってみないと伝わらないことがたくさんあるように感じています。

最後に。僕はスタートアップが好きです。ものを作ることが、やはり好きです。どれだけコンセプトの話し合いに時間を費やそうとも、コードを書く時間が減ろうとも、チームでプロダクトを作ることはそれ以上にたくさんのことを教えてくれました。

trippieceメンバーのみんな、お世話になりました。どうもありがとう。
時刻:

2012/03/26

これから大学でWebを学ぼうとしている人たちへ



大学を卒業される皆様、おめでとうございます。僕のFacebookのタイムラインは華やかな卒業写真で埋め尽くされています。卒業、というものから連想するのは、終りと始まり、すなわち入学です。もう来週には新しい期が始まり、たくさんの人達がいろいろなスタートを切ろうとしています。

僕は２年前、大学院に入りました。もう既に配属される研究室も決まっており、心機一転気分を高揚させて学び始めたのを覚えています。そしてこの２年間でたくさんのことを学びました。研究では大好きなWebのことを学ぶ時間をとれましたし、仕事ととしてもスタートアップをやりながら、起きている時間はほとんどずっとWebのことを考えながら過ごした２年間でした。そこで、今、２年前の大学院入学時、又は大学に入ったことには感じていなかった、知らなかったことを改めて文章にし、これからWebのことを学んでいく方々にとって何らかの道標となるようにと思いつつ、記してみたいと思います。

これから大学でWebを学ぼうとしている人たちへ。きっと今そういう人たちが増えているんじゃないかと思います。テレビにも新聞にもWebというのは何か新しく、希望があり、これから日本を明るくしていくものだという期待感が溢れているような気がします。そして実際にFacebookを使ってみたり、Twitterを触ってみたり、モバゲーやGREEでゲームをしてみたり、mixiで友達とコミュニケーションを取ったりしながら、それらが存在していることがごく当たり前であるように感じてしまうのではないでしょうか。

でも実際にWebを学ぶというと、いまいちピンとこないかもしれません。Webを学ぶということはプログラミングを学ぶということなのでしょうか。HTMLを飾り付けるためにタグを弄ることなんでしょうか。そもそも大学で学ぶ必要がないような気もしてきますね。

Webに限らず、広く使われている技術の背景には、学問としての蓄積があります。学問というのは、時として堅いものです。とても階層的で、とても方法論ばかりに感じられます。それでも、学問があります。大学では例外なく、学問に携わることになります。なぜなら大学の先生方は、学問の世界で活躍されていて、成果をあげているからです。すごく一般的な話ですね。

もしあなたがWebに興味があって、将来Webに携わりながら仕事をしたいと思うなら。これはとても大変なことです。あなたがいつも使っているアプリケーションの裏に、どんな人達がいるのでしょう。

・どんなアプリケーションを作るか考える人たち
・どういうアプリケーションを作るかが決まってから、それらをどのように作るか考える人たち
・アプリケーションを実際にコーディングする人たち
・作ったアプリケーションをみんなに使ってもらうために広める人たち
・動いているアプリケーションがちゃんと動き続けているかどうかを監視している人たち
・アプリケーションについて賞賛や批判をしてくれるユーザからの声を聞く人たち
・技術的に難しいと思われることを、何とかして方法を見つけて形にする人たち
・そのアプリケーションをより多く利用してもらうために、様々なサービスと連携をするために交渉する人たち

きっとまだまだたくさんいますね。そして何より、ここにはWebの基盤を作っている人たちのことが書いてありません。そもそもWebって何でつながっているのでしょう。どうしてみんなインターネットを使うことができるのでしょう。なぜ画面に画像や日本語や動画が綺麗に配置できて、世界中のどこからでもアクセスできるようになっているのでしょう。そしてそもそもコンピュータがなければ、どうやってWebでつながることができるのでしょうか。Webで仕事をするということは、たくさんの人たちに支えられながら価値を生み出すということに他なりません。

Webでビジネスをするということは、実はとても大掛かりな仕組みの上で行なっているというイメージがついたかと思います。大掛かりな仕組みをずっと維持してきて、ようやく最近になってWebで仕事ができるようになってきたのです。こういうと途方もなく感じられるかもしれません。使うユーザが増えれば増えるほど、データが消えた時のリスクも増え、一度にたくさんアクセスされるとパフォーマンスも下がってしまいます。例えば、Facebookのユーザは8億人を優に超えているそうです。8億人の利用するアプリケーションを運用する大変さは、もはや想像できません。でもそういうときにも、エンジニアは仕事をしなければなりません。そのための基礎が学問で、それを学ぶところが大学です。

何を学んでも無駄にはならないものだ、いつか役に立つとよく言われるものです。Webをやりたいなら、Webが好きで学んでみたいなら、まずコンピュータサイエンスの基礎をやりましょう。これは本当に無駄にならないものです。なぜPCが動いているのか、WindowsやMac、Linuxっていうのはなぜ動いているのだろう。よく聞くメモリとかCPUというのはどういう働きをしていて、何のために存在しているのだろう。そういう純粋な観察からどんどん調べていけば、コンピュータがなぜ動作しているかがわかってくるはずです。そのとき、コンピュータの科学のもつ世界の広さにびっくりするはずです。大変ですが、とても楽しものです。同様にプログラミングについてもどんどん試してみましょう。もちろんここでも、なぜ動いているのかを勘ぐりながら試して見ることが大事です。そして、プログラミングは本当に楽しいものです。自分の意図したとおりに、コンピュータを動かすということを初めて経験した時、どんな人でも目を輝かせる瞬間があります。この瞬間を味わってもらいたいです。もちろん、プログラミング言語もWebを支えているたくさんの人たちによって作られたものだということを忘れないで下さい。コンピュータの世界であっても、その裏にはそのシステムをつくっている人たちがいます。学び始めはその人たちから教えてもらうばかりになってしまうでしょう。いつか、どんな形であれ、その学びを誰かに伝えて行きましょう。きっとそれが、あなたの好きなWebを、より魅力的な場所にするためのきっかけになるはずです。

Webで仕事をするというのはこんなに長い道のりを経て行き着かなければならないのでしょうか。それでもいいでしょう。でも、少し仕事を試してみてもいいでしょう。実は、仕事から学ぶこともたくさんあります。人によっては大学の外に出て学ぼう、という人もいます。

Webで仕事をしてみようとすると、たくさんのことをやらなければなりません。ですが、まだアプリケーションを作ったことのない友だちをたくさん集めて、みんなで考えた魅力的なアプリケーションを作ってみるという試みは、とても楽しいものです。そしてやはりそこでたくさんの学びを得るはずです。複数人で開発をするにはどうしたらよいのだろう。まだ公開したくないので、仲間内だけで閲覧できるようにしたい。どういう機能を足したらユーザが喜んでくれるかをみんなで話し合って結論を出すにはどうしたらよいのだろう。実際にユーザが喜んでいるかどうかを、どのようにして調べたら良いのだろうか。魅力的なデザインをするには、どこから手をつけたらいいのだろう、単純にHTMLをかけるから素晴らしいデザインができるわけではない…。色々なことに気がつきます。技術だけあっても、アイデアだけあってもダメです。考えて、作ることが大切です。そして、すごく頑張らなければいけません。なぜなら、そうやって日々頭をひねって、プロダクトを作っている、あなたよりもすごく優秀な人たちが世界に何万といるのです。Webで働くということは、そういうことです。

Webを学ぶということ。学ぶことは無数にあるように感じられて、本当に終わりがないようなものです。それでも、いまあなたはきっとそのWebに携わっている人たちから何かを得て、何かを感じて、そしてWebが好きになったはずです。その気持ちが本当ならば、きっとWebを学び続けられるはずです。

そして何より、Webを学ぶことは楽しいです。
時刻:

2012/03/16

春休みの過ごし方



先月無事修士論文を提出し、大学でのほとんどの予定を終えて、僕は晴れて春休みを迎えていました。遊びに行く友達たちを見ながら春休みであることを感じ、そして僕も例に漏れず、南の島にいって休んでみたりしています。

春休みというのは長いもので、２ヶ月もあります。１ヶ月は休めるかもしれないけれど、２ヶ月も休むのは僕には無理かもしれません。それどころか、１ヶ月も休むだけだったら一体何をすればいいのだろうとすら考えています。どうも、何もしないことと休むということを混同してしまっているのかもしれません。

当の僕はというと、相変わらずtrippieceのことばかり考えていました。大学院での研究が一段落すると、自分でもびっくりするくらい時間が作れるものです。一日中、自分の手塩にかけたアプリケーションをさらに育てることに費やせるのです。そんな時間感覚が今まで欠如していたのか、１つのことに集中するということにすごく喜びを覚えた時間でした。仕事と遊びの境に自分がいるのかもしれないけれど、それはそれで楽しいような感じがしていて、厳しいものでもあり楽しいものでもあり、そんな空間の中で時間を過ごすことに悦に浸っていたような気がしています。

音楽をみんなで作るときにたくさん話し合いをするように、プロダクトをつくるときにエンジニアでもたくさん話しをすべきなのでしょう。僕の仕事はコードを書くことがメインではすっかりなくなってしまいました。それはとても良いことです。コードを書く事自体が目的になってしまうのはダメなのです。誰のためにどんなものを作りたいのかということを、常に忘れてはならないのです。だんだんtrippieceも大人の手段を使って、賢く成長しようとしているフェーズになって来ました。コードベースは今までになく良い状態を保ち、どんな機能の追加にでも対応できるような枠ができあがりつつあります。誰が作っても、変わらず成長し続けるアプリケーションでいて欲しい。そう思いながら、現段階で想定される範囲のことを実現するためのコストを最小限に抑えるための仕組みを構築してきました。僕の春休みはそうやって過ぎつつあります。

思えば、学生生活の間で時間の費やし方というのがどんどん変わって行きました。満員電車の中でもずっと読書をしていた時期もあれば、10分の空き時間にコーディングを進めることも日常茶飯事でした。ギターを弾くときも効率良く淡々と練習し、食事の時間も完全に計算していたこともありました。しかし波があるもので、最初は時間を切り詰めて効果が上がっていたものが、徐々にうまく回らなくなってしまうようになってしまいました。生活から楽しみが消えて、味気ない時間を過ごしたことだけが残っているようでした。不思議なことに今度はどんどん時間に感覚が緩んで行きました。１つ１つに余裕をもって、何かを感じながら、その時々に感じた何かを大事にしながら、過ごすようになりました。すごく良いことでした。いろんなことが見るようになりましたし、集中するときには一気に作業が進むようになりました。集中しているときには怖いくらい周りのことを気にしませんが、大抵それも１日のうちの２，３時間程度で、他の時間はすごく自然に過ごしています。

春休みはもうすぐ終わりそうですが、色々な波を超えて、次に備えているものへの期待感を着々と醸成しつつある、そんな時間を過ごせているのだろうと感じています。

 
時刻:

2012/01/05

2012正月



実家に帰省して、



色々と考え事をしていますが、



やはり、



外は寒く、



それでもトスカチーナのパフェは美味しく、



十勝平野は広く、



つけ麺はおいしかったです。

明日東京に戻ります。

※500g太りました
時刻:
登録: 投稿 (Atom)