はてなインターン2013に参加して参りました、そして与太話がしたい

幸運にもはてなインターン2013に参加する機会に恵まれましたので、謹んで参加して参りました。
「参りました」っていうのは、「精神的に参ってしまいました」とかそういう意味合いではありません。謙譲語です。
(非常に遺憾な事に、他のインターン参加者のブログを見ると、僕が精神的に参っている人のように描かれているので)

さて、本エントリの前半でははてなインターンの全般の話を取り上げます。が、このへんは他のインターン参加者のブログの方が詳しいし丁寧だと思うので、そちらを読むと良いでしょう。本エントリではできるだけ技術的な部分 (というか、開発プロセスのあたり) に触れて行きたいと現時点では考えていますが、スピリッチャルな内容になるかもわかりません。

エントリの後半は与太話です。それは例えばソフトウェアエンジニアの話かもしれないし、漫画家の話かもしれないし、サラリーマンの話かもしれないし、あるいはそう、ロックバンドの話かもしれない。端的に言うと「俺の演りたい音楽と、みんなの聴きたい音楽は違う」みたいな話です。危うい。

そんな感じです。
さあ！　以下から文章が崩れます！！

はてなインターン全般の話

まあ、こういうエントリを読んじゃう皆さんはもうご存知の事だと思うので、もはや説明不要な感じがしますが、念の為に説明をすると、京都にある「はてな」っていう会社がやっているインターンシップのことです。だから「はてなインターン」って言うんです。結構分かりやすい。
「はてな」がどんな会社か分からないって？　ほら、君が今見てるウェッブサイトを運営してる会社です。すごいでしょ！

インターンの前半

インターンの前半2週間は研修みたいな感じです。どんなことを勉強するかというと以下な感じ。

• Perl の基本的な文法・書き方
• DB の基礎知識、SQL の知識、O/R マッパとはなにか
• Javascript の基本的な文法・書き方、イベントドリブンなプログラミングの知識
• WAF (Web Application Framework) の知識、使い方
• 簡単な iOS アプリの作成
• 評価アルゴリズムの検討・考察 (講義・演習では、はてなブックマークのホットエントリーアルゴリズムを題材に)
• Web サービスの企画ワークショップ

超盛りだくさんですね！
まあぶっちゃけ、2週間でこれだけ詰め込めばみんなソルジャーになるし、これだけやればそこそこの Web アプリケーションだったら作れますよね！　という感じ。
非常に均整の取れた良いカリキュラムだったと思います。大変勉強になりました。

特にすごいと思ったのは Perl の講義と DB/SQL の講義で、Perl の講義は1日しか無いのにも関わらず「初めてのPerl」と「続・初めてのPerl」の内容を一通りさらう感じの内容だし、
DB/SQL の講義はこちらも1日しか講義の時間が無いのに「パフォーマンスの良いSQLとは何か」だとか「O/R マッパの使い方と、その利点・欠点」だとか、そういう部分にまで踏み込んでいて凄まじい。

あと、はてなの世界観は結構面白くて、色々と参考になりました。例えば……

• WAF は使わない
• O/R マッパは使わない
• MVC における Model の部分は、Service 層と Model 層とに細かく分けて責務を分配する
  • Service 層は主にビジネスロジックを記述する。実際に DB にアクセスするのはこのレイヤだけ。
  • Model 層はデータそのものを操作する処理を記述する。ざっくり言うと Row オブジェクトみたいな感じ (理解間違えているかも)。
  • Model 層は DB にアクセスしてはならない
    • SQL を発行する部分を Service の責務にのみ限定しておくと、パフォーマンスチューニングがやりやすくなる
    • 誰が SQL を発行しているのかさっぱりわからん！！！！　という状況に陥りにくくなる

「WAF は使わない」「O/R マッパは使わない」というのは、「既存のものを使わない」という意味合いで、
必要に応じてプロジェクト毎にドメインに適した WAF や O/R マッパを自作して利用するとのことです。
これには利点があって、そのことについては後に述べます。

しかしまあ、Service 層と Model 層に分けるの、本当に便利！　ファンになりました！

(ここで述べているのは比較的新しいサービスの話らしいです。古いサービスはその限りでは無いとの事)

インターンの後半

インターンの後半2週間は、実際に開発チームに所属してそこで新機能を実装する～という流れでした。
僕ははてなブログチームに所属して AtomPub API の実装を行いました。良い API です。
参考: はてなブログAtomPub APIを公開しました。サードパーティのブログ投稿ツールを利用・作成できます - はてなブログ開発ブログ

さて開発フローの話です。
はてなは開発に GitHub Enterprise を利用していて、これが非常に良い。どんな感じで使っているかと言うと

• プロジェクトのリポジトリを GitHub Enterprise にホスティング
• Feature や Bug Fix はブランチを切ってそこで作業
• ブランチを切るや否や即 Pull-request にする
• 実装済みになる、つまり本流に Merge されるまでは Pull-request は Open しっぱなし

という感じ。
こうすることによって、進捗が可視化できるのと共にこまめなレビューが実現出来て良いです。
あと、Pull-request のコメントにチーム間で共有したい事をあれやこれや書いておくと捗る感じです。

また今回のインターンでは後半最初の1週間、毎日午後イチでコードレビュー会があって大変素晴らしい感じでした。
コードレビューは本当に本当に重要です。コードレビューはプロジェクトに加わりたての時こそ特にやるべきで、
コードレビューしてもらえるとそのチームのしきたりだとか文化・風習を知ることが出来るので、早くチームに馴染む事が出来るようになります。
なので、チームにニューカマーがジョインした時、最初の1週間くらいはチームメンバ―でコードレビューを積極的に行えば良いのでは無いかと思いました。

そして何より、コードレビューされると自分のコードの粗が見えるし、それに対する処方や議論も生じるので、コードの質・レベルが目に見えて向上します。
ご存知の通り、GitHub は行ごとにコメントが出来て、ご多分に漏れず GitHub Enterprise も行ごとコメントが可能なのでこれが非常に便利です。
コードレビューを細かい粒度で行えるので、フィードバックも細かく行えますし、修正すべき点が一目瞭然となります。
というかGitHub の行ごとにコメント出来る機能、そのあまりのお手軽さと便利さのお陰でついついコメント付けたくなっちゃうので、自然とコードレビューが活発になります。
コードレビューを促進させるにはまずその環境を整えるところから、という感じでしょうか。GitHub 最高！

あと先に書いたように、既存のフレームワークを利用しないので、「フレームワーク固有の知識」みたいなのが要求されなくて良いです。
ほら、結構重厚なフレームワークとか賢いフレームワークとかって、使いこなすためには一定の学習量が必要じゃないですか？　そのコストがほぼ無い。
前述したように、プロジェクト固有のフレームワークみたいなのは存在しているので、「え？　それじゃあ結局そのフレームワークについて勉強しなきゃ駄目じゃん」
と思われる向きもあるかもしれませんが、プロジェクト固有のフレームワークは結構薄いしそのドメインに特化しているので扱いやすく、わかりやすいので大した問題にはならないのです。
そのプロジェクトのドメインとかビジネスロジックとかを理解すれば自然と使えるようになる感じ。不要な機能とかが無いので、そこに変に気を取られる事もない。
(あと、重厚なフレームワークを知っていたとしても、そのプロジェクトのドメインやビジネスロジックについては改めて勉強しなければならないわけじゃないですか。
なので、プロジェクト固有のフレームワークを使う時とあまり学習コストに差が出ないような気がしています)
そういった感じで、本格的に開発に加われるようになるまでの学習コストが低くて済むので、プロジェクトに途中で加わった人間にも優しい感じがしました。

あとちょっと細かい話をすると、XML::XPath は新規のプロジェクトであれば、利用する理由は最早存在しないでしょう。
XML::LibXML というモジュールが XPath インターフェースを提供しているので、おとなしくそっちを使った方が良いです。
この件については、後日機会があればどこかに書きたいと思っています。

インターンを総じての感想

いや、もう本当に最高でした。ここまで学べるインターンっていうのは全国的に見ても珍しいのではないでしょうか。
「金を払ってでも受けたい！」というレベルの内容なので、これに参加出来た自分は本当にラッキーでした。

その高いクオリティの内容を実現できているのは、はてなの社員の皆さんの尽力によるもので、
ぶっちゃけ「ここまでリソース割いてもらって申し訳ねえ！！！！」っていう気持ちが生まれました。
本当にありがとうございました。今度飲みに行きましょう。

ここからは与太話だ

さあ、ここらで終わっておけば良かったのに書かずにはいられない。
以下からは与太話というかエモトークという、苦悩の記録というか、なんだかロクでも無い感じなので、特に興味のない人は上手に読み飛ばして、
一番下に貼ってある「はてな社員のお薦め書籍一覧」でも見て下さい。そして適宜アフィなどを踏むと良いでしょう。

さてインターンの成果は最終的に格付けされる。この事実に関しては多くの人が既にご存知のことだろうと思う。
インターン生のチームごとにその成果を発表して、それが投票によって順位付けされるのだ。
ちなみに優勝チームは、はてなブックマークのアマゾン商品サジェストの精度を向上させる、という内容のもの。
参考: はてなインターン2013でブログチームの連勝記録を打破してきた - 平常運転
つーか、アマゾンの商品サジェストの精度アップさせたの本当にすごい！　リスペクトしかない。

して、我々の作った AtomPub API はどういう結果だったかというと、同率4位という結果だった。
率直に述懐するならば、この結果に関しては納得がいっていない。
納得がいっていないのは自分だけ、或いは関係者だけで、他の人は納得してるゼ？　っていう指摘はまあもっともだと思うし、まあそんなもんだろうとも思う。
「これだけ頑張ったんだから」とか「時間をかけたんだから」とか、そういうファクタが評価される事は十中八九無い。むしろ無駄に時間をかけるのは最悪の仕事とも言える。
しかし、ここで「仕方が無い」だとか、そういう口触りの良い言葉で自分を納得させるのは容易だけれど、ここで引き下がるわけには行かない。
曲がりなりにも自分たちのチームが作ったプロダクトであり (それが社員の皆さんのサポートを死ぬほど受けていたとしても) 、
その完成形を「負けても仕方が無かった」という妥協で片付けてしまうのは何かを決定的に間違えている気がする。

それを踏まえて。
この結果は仕方が無かったのだろうか？　本当に？

さて、はてなブログの Web API 実装は僕の念願というか、インターンで僕のやりたかった事のひとつだった。
しかし、サービス側の視点に立てば WebAPI は利益化しにくいだろうし、むしろ悲観的な目線に立つとするならば SPAM を増やす要因にしかならないと言える。
一方で、アマゾンの商品サジェストの精度向上は利益向上に直結するし、一見するとネガティヴなファクタは存在しないっぽい。

これだけを考えると、間違いなく Web API を実装するよりもアマゾンの商品サジェストの精度を向上させた方が良いように思える。
ただ、「アマゾンの商品サジェストの精度向上」のタスクをやりたかったか？　と訊かれると、それはあんまりやりたくなかった事だったろうと思う。
(そもそも、「アマゾンの商品サジェストの精度向上」という発想が僕には無かった)

これは、自分のやりたいことと他者の欲しいものとが上手くマッチしていなかったということなんだろうか？
つまり、この時点で決していたのだろうか？
取り組む題材を選択する時点で結果は決まっていたのか？

ところで、「自分 (開発者) が欲しい機能・実装したい機能」と、「ユーザが望む機能」、そして「会社が望む機能」はそれぞれ関係しているのだろうか？

仮に、「ユーザが望む機能」と「会社が望む機能」とが独立しているとすれば、ユーザが望む機能を実装したとしても会社が収益をあげる事は不可能だろう。
しかし世の中はそうなってはいない。従って、少なくともこの二者間には何らかの関係性が存在していると考えられる。

一方で、「開発者が欲しい機能・実装したい機能 (以下、やりたい事と書く)」と「ユーザが望む機能」、そして「開発者がやりたい事」と「会社が望む機能」には関連があるのか。
小さいスタートアップなんかだと、社員全員が (ほぼ) 同じ方向を向いているだろうし、ユーザ数も少ないからユーザもほぼ全員同じ方向を向いてるはずで、
そういう場合は先に述べた関連性は強いと思うんだけど、組織やサービスが大きくなってくるとそうもいかなくなると思う。
組織とかサービスが大きくなると、社員はそれぞれ別のヴィジョンを抱き始めるだろうし、今までそれぞれ一人ひとり意識して気を配れていたユーザは
その数が多くなるにつれて「ユーザ」という漠然としたひとかたまりとして扱われるようになるだろう。
そうなってくると、開発者がやりたい事だけをやって価値を届けるのは不可能に漸近して行く。

仕事をするにあたって最高なのは、「やりたい事をやって価値を届けられる、あるいは評価される」という事なのは言うまでもないけれど、
そう言ってばかりもいられないから、次点として来るのが「やりたくない事をやるけれど、価値を届けられる」というので、
更にその下に「やりたい事をやって価値を届けられない」、「やりたくない事をやった挙げ句に価値を届けられない」という風に続く。

やりたい事だけをやってユーザに価値を届けられる、他者から評価される、給料がもらえる……と言うのは理想的で、そうだったら本当に最高だと思う。
けれども、そんな虫の良い話がそこら中に転がっているはずもなく、時には自分のやりたくない事もやらなくてはならないだろうし、
もしかしたら、自分のやりたくないことしかやれない、という最悪な状況にも陥る事も容易に予想できる。
ただ、エンジニアとして、というか人間として「興味のあることをやりたい」だとか「面白そうなことをやりたい」っていう欲求は止められないと思う。
それを無理矢理我慢して、やりたくない仕事 *1 を延々やり続けると、いずれ人間は発狂して壊れると思う。
だから、そこら辺の折り合いを上手く付ける為にはどうすれば良いのかっていう話で、これ超難しい。

今回のインターンは最後の最後で、つまり成果が順位付けされた瞬間から、ここら辺の話を強く意識せざるを得なくなってしまった。
求められているのは問題解決のスキルだけに限定されない。問題探索、問題発見のスキルも間違いなく必要なのだ。
あと、それによって明らかになった問題がやりたい事であろうと、そうでなかろうと、それによる利益を客観的に評価して取り組める力も。
その事を今まで意識したことは無かった。今回のインターンでそれに気づけた。
そこには気づきがあったのだ。結果的に良かった。結果的に良かった。

さてさて。結局のところ、今回の成果である AtomPub API は「やりたい事をやって価値を届けられない」プロダクトだったのだろうか？
まあ、インターン成果の順位を見る限りではそういう風味がある。けれども、本当の所どうなんだろう。わからない。
ただ、少なくとも誰かには価値を届けられていれば良いな、と強く思っている。

……いやー、しかしまあ、なんだろうなー！
確かに AtomPub API は地味だったよなー！　もっと派手な見せ方とかをすれば良かったのかな？
でもね。AtomPub API、本当に良いAPI なんだよ、マジで！
なので皆さん是非ご利用下さい！！！！！！

(ふろく) はてなの社員がすすめる！　書籍一覧

適当に、覚えてる限り貼ります

初めてのPerl 第6版

続・初めてのPerl 改訂第2版

Perlクックブック〈VOLUME1〉

JavaScriptパターン ―優れたアプリケーションのための作法

実践ハイパフォーマンスMySQL 第2版

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

プログラミングの基礎 (Computer Science Library)

リーン・スタートアップ ―ムダのない起業プロセスでイノベーションを生みだす

*1:例えば CSV ファイルを目バリデーションし続ける仕事とか