個人的に、第1部の「アルファギーク vs 学生」について思うところが多いので、そちらについて書きます。進行や議論の流れなどへの批判は、他の方が既にたくさん書いているので、あの混乱の中でも重要だと思った話がいくつかあったので、それを取り上げたいと思います。なお、アルファギークの方はブログなどを通して、少なくとも名前は全員知っていたので、多少の前提知識がある者の弁としてお聞きください。

今回、討議された中で最も重要だと思ったのが、最後に金子さんがまとめで仰った

学生と企業側間での情報の非対称性

だと思います。naoyaさんの「学生がブラック企業に行かないようにすることが、業界にとって大事」という発言を受けて出てきた議論だと記憶しているのですが、学生はそういう企業を探す方法を知らない、という話。これは僕自身の経験からも、大いに頷ける内容でした。

そして、それを受けて出てきた、ひがさんの

社員がこういうことをしている、と伝えるのが大切

社員が情報を外に出しやすい空気を会社につくる

という発言が、一番生産的な結論だと思います。惜しむらくは、この議論が全く盛り上がらずに流れてしまったことですが・・・。

逆に、danさんやよしおかさんが自己責任を強調されるのは、どう見てもマッチョ論で、あまり生産的な議論につながるとは思えなかったです。

結局自分でやるしかないなんてことは、みんなわかってるに決まってるじゃないですか。それを強調しすぎたのは、明らかにマイナスな印象を生み出したと思います。だからどうするのか。どこから始めたらよいのか。そのためにOSSの話などが出てきたと思うのですが、うまくそちらに繋がらなかった印象があります。

以下、ログです。途中、danさんとよしおかさんの掛け合いで混乱した部分はあまりメモをとれませんでしたが、それ以外は概ね再現されていると思います。しかし開催の趣旨、全く無視されてましたね・・・。

開催の趣旨

IT業界へのネガティブなイメージを振り払う

このイベント開催の経緯

先日、IT業界のネガティブなイメージが拡大したイベントがあった・・・。それに対して、ひがやすをさんがアルファギークと学生を対談させればよいのでは、と発言。それに対して、技評が応えた。

パネラー紹介

ギーク側

dankogaiさん （以下、dan)

にぽたんさん ライブドア （以下、にぽたん）

naoyaさん （以下、naoya）

よしお ひろたかかさん （以下、よしおか）

ひがやすをさん （以下、ひが）

学生側

益子謙介さん （以下、益子（メガネスーツ））芝浦工大3年 IT系を目指している 会場ではメガネスーツと呼ばれていた 

新井貴晴さん　（以下、新井）芝浦工大3年 

田村健太郎さん　（以下、田村）一橋大　モバイルの会社でCTOやってる

源馬照明さん　（以下、源馬）名古屋大学大学院　8月にはてなでインターンやってた

ひが

IT業界が泥ばかりでもないが、光ばかりでもない。

光の部分だけを協調しても意味がない。

いいところも悪いところも見て欲しい。

将来は学生の方にもIT業界に来て欲しい。

dan

SIに関してはあまりよく知られていない

よしおか

IT業界について整理したい。

ドメイン別

• 基盤技術系 OS、コンパイラなど
• エンタープライズ系
• ミッションクリティカル系 社会の基盤、インフラ
• Webサービス
• 組み込み系

ビジネス形態別

• ソフトウェア製品開発、販売
• SI
• コンサルティング
• 運用サービス、サポート
• Webサービス

それぞれの業界で、意見が違うという前提の元で討議してみたい。

ひが

SIer系

自身は自由に何をやっても良い立場

OSSをずっとやってる

いちおうSIerのこともわかっている

しかしプログラムを書くことを認めてもらっている

よしおか

ソフトウェア製品のサポート

ＯＳやコンパイラを20年ほどやっていた

naoya

Webサービス

クライアントさんがいるというよりは、ユーザサイド

独立系

前職のISPでは協力会社がいたので、その立場もわかる

にぽたん

Web系

データセンターを持っている

インフラっぽいこともやっている

昔はWeb系の受託開発もやっている

かつてはそちらの方が中心だったが

dankogai

組み込み以外は全部やったことがある

現在はしいて上げればコンサルティング

しかし手を動かしている

まだ誰もやっていない

人が手をつけていないことをあえてやっている

泥のように働くってどういうこと？

はてなキーワードが表示される

にぽたん

肉体労働をやって泥まみれになったこともある

いろんな人のイメージがあるので、勝手に定義してしまうのはどうかと

naoya

記事を読んだ 少し泥を協調しすぎかな、と

金融などはフローを覚えるのに10年くらい働くのが必要と言う意味だったのでは

学生は自信満々で即戦力でいろいろやりたがる

そこにギャップがあったのではないか

自分も入ってすぐプログラムをばりばりかいて第一線で働きたいと思っていた

実際はあまりうまくいかなかった

大人数でものを作らないといけない

趣味のプログラムと業務のプログラムは結構違う

よしおか

IPAのひとが不用意に発言しすぎた

IT業界が協調されすぎた

メディアがおもしろおかしく書くのは当たり前

OSSに参加するのがオススメ

学生のうちからできる

企業に勤めているひとも、したたかにやっていく方法はある

下積みというところもあるが、自分でやるひとはいろいろある

ひが

学生に喋らせよう

益子

なぜこの業界だけ泥が協調されたのかよくわからない

dankogai

その間日も当たらない

泥の中には「評価されない」も入っている

新井

ITは最近になって注目されはじめた

田村

銀行とかもたぶん泥のように働いている

源馬

たぶんどの業界でもある

ドクターに進んでも、ニートになってしまう人もいる

自分の今の生活も、朝パソコンを立ち上げて、論文を読んでと、いろいろやっている

これは仕事だとすれば泥かも

dankogai

論文は外に出して評価されるから良いのでは？

源馬

（ドクターを出ても）就職する際には、論文より実務経験の方が重視されている気がする

35歳定年説

大学を卒業して10年働くと32歳だ

陽の当たるのは3年だけ?!

ひが

（自身は）プログラマーとして外に出だしたのが35くらい

プログラミングに価値を付けられれば、35歳とか関係ない

よしおか

ひとのせいにしてはいけない

35歳定年は（もちろん）法律で決まっているわけではない

いつになってもデビューできる

naoya

入社して1年くらいは下積みをやっていた

入社して3年目くらいでプロダクトが評価された

自分でプログラムが書き続けられるひとなら問題ない

しかし、どうやったらひがさんやよしおかさんのようになれるのかわからない人は不安になっているのではないか

31が目の前だが、だんだんマネジメントも増えてきた

これはこれで結構面白い

無自覚に管理職になってしまうのは結構辛いかも

35くらいまでに自分はなにがしたいのか、何が面白いかを自覚しておくのが重要

にぽたん

デザイナになりたかった

デザインセンスがなくてプログラマになった

プログラムが面白すぎた

下積み時代があったから今がある

某SIerの人と話したら、若いひとが早く上流に行きたがってた

コード書くのがいやなひとは上に行きたがる傾向にある

コードを書きたい人は、そういうことをさせてくれる場所を探す、作るかしないといけない

よしおか

OSSと受託では結構違う

受託で書いたコードは相手にもっていかれてしまう

OSSやWebサービスは自分がattachした充実感がある

OSSが受託開発より気持ちいいのは、書いたコードが自分のものになるから

田村 (CTO)

できるものに感心があるので、コードにはあまり興味がない

dankogai

ショック！

田村

プロダクトが目的であって、コードではない

dankogai

CTOがコードに興味がないってのは珍しい

naoya

コード自体に興味があるひとと、そうでない人は確かにいる

しかしCTOは興味を持った方が良い

源馬

コンピュータサイエンスの知識はある

はてなのインターンに参加して、あまり知識だけでは通用しないことを感じた

社会に貢献したいとは思うが、漠然としている

新井

アルバイトをしていて、お客様にサービスを提供して、お客様に喜ばれると嬉しい

益子

プログラムをやりたくて大学に入った

でも、だんだんコードだけではなく、製品のプロセスに興味が出てきた

コミュニケーションを取るためにプログラムを書く

naoya

世の中に新しいものを提供するには、技術を知っているひとの発想が必要

世界を変えるプロダクトを作るには、プログラマの力が絶対必要

益子

（技術を）知っているからこそ限界を感じてしまったりもするのでは

よしおか

それはないです

限界を決めているのは自分

言葉で説得するのではなく、コードで語るひとたちがハッカー

源馬

コードを書くこと自体が好き

外からやれって言われるのが嫌い

dankogai

コードを書いているうちにいつの間にか有名になってしまうのがアルファギークという理解でOK?

源馬

そうですね

自分はktkrリーダをOSSでリリースしている

dankogai

素晴らしい

そういうことをしていれば、学生のうちに注目されてしまうこともあるね

OSSにコミットしている人の中には、泥の段階をすっとばしている人もいる

好きなことをやっているうちに、起業してしまったひとなどはいるのか？

源馬

あまり知らない

dankogai

自分は嫌いなことを避けているうちにこの立場になった

にぽたん

アルファギークのことがよくわからない

自分はアルファギークだとは思っていない

ひが

泥にこだわってもあまり生産的にな話にならない

よしおか

ひがさんは10年間業務をしつつ、Javaに巡り会った

そしてそれを会社の主力事業にまでして、自由な立場を得た

自分で勝ち取った立場

ひが

Seasarやるまでは、普通のひとだった

プログラミングは好きな方だったが、会社の評価はあまりよくなかった

設計するひとたちがコードも理解できないといけない

丸投げモデルはいずれ崩壊するという危機感を抱いていた

会社がもっとコードを書ける人を育てていかないといけないという風潮になった

会社にもOSSを出して、コードをかけることをアピールした

よしおか

自分でやったというところがポイント

たいていのひとは手を動かさずに文句を言うだけ

ひがさんは成功例を出したというところが素晴らしい

ひが

一般的なエンジニアのキャリアパスが気要らないけど、どうしようもないと思っている人は結構いるのではないか

OSSなどで出して行けば、アピールできるかも

dankogai

OSSでは実はマネージャが不足気味

naoya

マネジメントは非常に重要

技術を極めたいと思っているひとがいて、世の中に貢献したいと思っているとする。

製品に結びつけて、世に出せるひとが必要。

マネジメントをする人にも技術力が必要

そうでないと技術の有無が見極められない

よしおか

経営や管理の重要性

ギークは技術技術と言いがちだが、マネジメントの重要性も認めるべき

技術をお金に換える人が少なすぎる

OSSが金になるか、という質問には意味がない

お金に結びつけるセンスがないひとが多いだけ

ひがさんに質問

なぜOSSか

ひが

オープンソースにするといろいろな人からのフィードバックが得られるから、出した

会社がきちんと認めていてくれても、OSSの考え方が好きなので外に出したと思う

ひがさんに質問

会社は変わったのか、特に丸投げの空気などは

ひが

変わっている。実際に新人研修でも、コードをきっちり教えるようになった。

質問

プログラムなどをあまりやらずにSIerに入ってしまうのが問題なのではないか

よしおか

それに対する回答はない

就職先は自分できちんと選ばないと

自分の人生

naoya

みんなちょっと自己責任論に偏りすぎ

会社に入ってからプログラムを書き始める人は結構いると思う

自分は会社に入ってから自分で勉強した

しかし忙しすぎて勉強できないところもあると思う

会社を辞めても良い

よしおか

教育やOJTを与えるのは経営者

それを与えないのは馬鹿な経営者

自分の人生は自分で決めなきゃ

SIerにいる人からの質問

入って数年は新しい技術に敏感だったひとたちが飼い慣らされてしまった

ビジネスモデルに負けている感がある

よしおか

それはその方がぬるま湯的で楽だから

ひがさんがはそこに危機意識を持っている

ウリがないところは、そのうち単価が安いところに駆逐されてしまう

よしおか

業界の中で、すごく苦労しているひとたちがいる

上流指向だけでは、差別化する要因がなくなる、ただの価格競争になる

全部自分たちの中でやれるSIerが付加価値を出せる

dankogai

外注が始まったのはいつ頃からか

ひが

就職する頃には既にあった

なぜSIerが存在するのか

日本企業は社員を勝手に解雇できない

社員を遊ばせておくのはもったいないので、下請けを使わざるを得ない

dankogai

SI業界はなぜ建設業界や公共事業的な流れに似ているんだろう

なぜ自分たちの中でやらないの？

ひが

簡単に首にできなにので。

dankogai

DECやIBMはそんなに簡単に首にしてたっけ？

よしおか

企業は利潤を生むために存在している

人件費を削ると、価値を生み出す力がなくなってデススパイラルに陥る

中国やインドなどでは一次受けがかなりの人数を持っているんで、あまりピラミッドは深くならない

よしおか

日本には技術を蓄積しないで、舌に流せばよいと思っている人たちが多い

中国やインドのひとたちは自分たちの技術をさらに磨こうとがんばっている

経営の問題

価値があることを認めさせるギークも少ない

みんなで高めあってもっともうけようとする人も少ない

スーツもギークもどちらも必要

技術者側がアピールしないだけ

益子

（業界が変わらないのは）ぬるま湯が気持ちいいからか

よしおか

そうだ

少しでもいい生活がしたいなら、したたかに自分から変えていくしかない

いやだと思うなら、自分が変えていくしかない

dankogai

ソフトウェアと製造業を単純に比較することは出来ない

中国で会社を作ったことはあるが、教育をしていない段階では、（中国人社員の生産性は）比べものにならないくらい低かった

よしおか

OSやコンパイラなどはそこまで進化していないのだから、経験のあるひとがOSSなどに集えば何かが起こるのではないか

dankoga

それには反対する！

彼らの知識が邪魔になることもありうるのではないか。

過去のコンピュータの知識が邪魔になることも

GFSを見ろ

よしおか

RDBMSなどは変わっていない

（混乱中）

田村

自己責任を押しつけてくるのはいやだ

naoya

どうやってそういう会社を探す？

田村

リクナビなど以外の情報の取得方法がわからない

naoya

学生がブラック企業に行かないのが淘汰に繋がって良いが、企業もどうやって伝えれば良いのかわからない

益子

離職率が36%

ネガティブ転職が多い

ビジョンが見えてなくて適当に入った会社だから、簡単にやめる

次のビジョンもない

自分が何ができるのかわかっていない

自己分析能力が欠けている

源馬

起業することで社会を変えることが出来る

日本は起業するのに優しい社会か

田村

企業すること自体は難しくない

ただ、学生間での情報の格差がすごい

自分はたまたま起業系のサークルにいたから情報が豊富にあったが、普通にしていたら考えもつかないと思う

益子

就職サイトでみてもどこか良いのかわからない

文で差別化なんかできない

職場を見せるインターンのようなことをどんどんやるべき

よしおか

それは本当にその通り

ひが

社員がこういうことをしている、と伝えるのが大切

社員が情報を外に出しやすい空気を会社につくる

ひが

ピラミッドのトップにいるSIerは潰れてしまえ、と思っている

SIerにいるなら会社を変えてみる努力もするべき

dan

会社いやならやめればいいじゃん

日本の業界がどうの、とか言うな

にぽたん

みんなこの感じでは残糞感があるんじゃない？

目を付けた会社に自分から動いていく勇気を持つことが重要

naoya

自分ができるのは、自分がいる産業を大きくすること

そこでエンジニアがハッピーになれる業界にしたい

はてなは現在拡大路線

よしおか

自分の人生は自分のもの

東京は勉強会がすごくある

今日みたいなセッションも雇用と思えばこれる

ustでも見れる

自分で何かを変えようと思えば変えられる

最終的には自分の人生は自分で決めよう

ひが

まずは行動しよう

月に一回ひがやすを飲み会をやろうと思っている

益子

最初の方は言っていることがよくわからなかった

最後のほうは学生目線でいろいろ言えて楽しかった

学生が足りない部分もある、それは認める

しかし、企業側にも足りないところがある

田村

情報の非対称が問題

改善したい

源馬

はてなのような会社ががんばると良いと思います

がんばってください

終わり

出演者の方の感想リンク

アルファギークが空回り - ひがやすを blog

エンジニアの未来サミットに行ってきた - 未来のいつか/hyoshiokの日記

エンジニアの未来サミットについて、色々考えてみました - にぽたん研究所

エンジニアの未来サミットで学生役してきた - タムケンブログ

まとめ

syttruの日記

感想追記

個人的には、知人である源馬さんが、はてなマンセーを言い過ぎているような気がして、多少気になりました・・・。はてなだけ良くても意味がないので、業界全体にどうやって繋げていくのか、という流れで話をして欲しかった。

源馬さんと知り合いだったため、終了後の楽屋に潜り込むことができたのですが、みんなぐったりしていました。お疲れ様でした・・・。

はじめにアイデアと大まかな実現を方法が示され、後は2人でペアプログラミングをしながら作っていきました。仕様書などはなく、作っては面白さを追求して改良を重ねる開発、ユーザビリティテストの結果をフィードバックさせて良いものに仕上げる仕事は、とてもエキサイティングでした。

技術的な相談はもとより、様々な面で良くしていただいたid:antipop,  id:motemen (Git神), 我々の気づかないところまでディレクションをしてくれたid:nmy, 見やすいデザインでランキングの魅力をアップさせてくれたid:tikedaに感謝します。

そして何より、インターンのペアに恵まれました。僕の稚拙なコードや設計のあらを指摘してくれ、ペアプログラミングを通じて多くのことを教えてくれたid:nanto_viに感謝します。ありがとう。一緒に仕事ができて楽しかったです。また銭湯行きましょう。

なにぶん速度面やバグなどでご不便をかけることがあるかもしれませんが、その際はサポートやはてなアイデアにフィードバックをお寄せ頂ければ幸いです。その際にはキーワードチームの皆さん、よろしくお願いいたします。

キーワードチームの皆さんと、オフィスにて 撮影cho45さん

 
1日目: はてなイントロダクション
id:jkondoからはてなの概要とインターンの趣旨について、id:naoyaからはてなの大規模システムについて、それぞれプレゼンテーションがありました。その後はウェルカムパーティー。

メンバーがかなりすごいバックグラウンドの人ばかりで、気後れするも、ビールの力でわいわいやっているうちに時間は過ぎていきました。

2日目: Perlオブジェクト指向プログラミング
id:antipopからPerlでのOOPについて解説。OOPとは何か、なぜOOPかという説明からはじまって、実際のコードを使った解説へと進みます。デザインパターン、テスト駆動開発等についても触れていきます。（テストがない状態でのリファクタリングは、すぐに泥沼化すること等）

恥ずかしながら普段はC言語しか使わないので、OOPには馴染みが薄かったのですが、一応Objective-CとC++を使ったことがあるので、その知識を動員してなんとか乗り切りました。Observerパターンを使う課題があって、とりあえず本の通りに実装したら綺麗に動いて感動。この日は割と遅くまで残って課題をこなしました。

3日目: ORマッパー
id:onishiからはてなの内製ORマッパーであるDBIx::MoCoについて解説。MoCoはid:jkondo開発とのこと。社長がライブラリを作っている会社・・・。ライブラリを自作すると、必要な機能をコンパクトに実装できて良いらしい。対応DBはMySQL。名前の由来は、近藤家にあるいい感じのクッションらしいです・・・適当!

この日はTodoリストを管理するCLIアプリケーションを作成。この日の課題を5日目まで使い回すので、もう少し頑張っておくべきだったか・・・。

4日目: MVCによるWebアプリケーション作成
昨日の課題をModelとして、ViewとControllerを実装します。これまた自社フレームワークであるRidge (id:naoya作) を使う方法を、id:motemenのご指導のもとで学んでいきます。Ridgeには簡易サーバも付いているので、自分のローカル環境で試すことが可能です。ViewにはTemplate Toolkitが使われていました。

昨日のORマッパに比べて結構簡単に感じたのですが、画面遷移のセオリーがわからず、アクションがごちゃごちゃのまま設計したところ、厳しく採点されてしまいました。また、ちょっとつっこんだことをやろうと思うとすぐにControllerが汚くなってしまうので、Modelをまた弄り直して・・・と結構手戻りが発生して意外と消耗。

5日目: ユーザインターフェイス
この日の講義はid:secondlifeから。JavaScriptを使って、昨日までの課題のUIを改良します。言うまでもなく自社ライブラリのTen.jsを使います。このTen.jsも、社内に様々なJSライブラリが氾濫していることを憂慮した社長が勉強しまくって（id:onishi曰く、id:jkondoは非常な頑張り屋とのこと）作ったそうです。

先週も書きましたが、JSとDOMの概念を全然知らなかったので、僕はここで結構躓きました。。id:GemmaにHello Worldから教えてもらって頑張ってみたのですが、その日のうちに課題終わらず。一応完成した人も、土日で完成度を上げていたようで、どうやらみんな土日に休むという概念はないらしい。

6日目: ThriftでRPC
この週から発展課題に入り、はてなの中でも割と導入してから日が浅い技術を扱います。この日はFacebookによるRPC実装Thriftが題材。異なる言語や処理系の間でRPCできるのですが、IDLをちょろちょろ書くと（サポートがあれば）スケルトンを生成してくれて、そこに処理を書くだけになっている親切設計。これは研究でも活用できるかも。

課題は異なる言語でサーバとクライアントを書くもの。呼び出す処理自体はただの加算と乗算なので簡単だったため、余った時間でいろいろな言語に走る人が多かったです。人気はC++とRubyでした。Scalaでサーバを実装したcho45さんやCocoaでクライアントを実装したhakobeさんのような猛者も現る。

この日は時間が余ったため、先週終わらなかった課題を実装・・・。

7日目: 大規模データ設計
id:naoyaから、大規模なデータを扱うシステムについての講義。DB設計や、Linuxのキャッシュについての話が前半で、後半は課題で使うアルゴリズムの説明でした。

課題は2つから選択可能で、僕ははてなブックマークから抽出したキーワードの転置インデックスを用いて、キーワードからブックマークの検索を行う課題をチョイス。Cosine Similarityという尺度を使って検索するのですが、データファイルが数百MBあるため、ナイーブに実装するとメモリ消費量が大変なことになります。そこで・・・というところまで含めて課題です。

8日目: HadoopによるMapReduce
id:stanakaからMapReduceを使ったデータ処理について講義を伺いました。GoogleのMapReduceのオープンソース実装Hadoopを使って、実際にMapReduceプログラミングをするところまでが内容です。Java以外の言語でHadoopを使うHadoop Streamingについても詳しい解説アリ。

課題では、RFC仕様書のテキストデータすべてを読み込んで転置インデックスを作り、検索まで実装。僕はn-gramを使って順位付けを行う方法でやりました。MapReduceを二回回せば、n-gram入りの転置インデックスができます。MapとReduceの進行表示を見てにやにやする、異様な一日。ほとんどの人がMapReduce初体験だったので、盛り上がりました。

9日目: はてなを支えるインフラストラクチャ
id:hideokiからはてなのインフラについての講義。冗長化でいかにSPOF (Single Point of Failure) を回避するかという話や、ロードバランサ等のお話を伺いました。また、分散ファイルシステムMogileFSや、内製のサーバ管理ツールについても説明。1OSしか搭載しないサーバでも仮想化しておくと、ゲストOSがコケた際にホストOSから再起動できて便利、などのノウハウも。

この日は課題はなしで、昨日までの課題の再提出や、復習に充てる日になりました。僕はこの隙に課題を再提出して、なんとか及第点に到達。

10日目: 結果発表、配属決定
この日までの課題の評価で、後半に進むことが出来るかが決定されます。残念ながら10人のうち、1人が後半に進むことができませんでした。

その後、後半で配属される各チームのプレゼンテーションを見てから自分の希望するチームを選び、人数調整のあと晴れて配属先が決定となります。みんなそれぞれこだわりがあるので、この作業が結構難航。15分くらいわいわいやった末に、無事チームが決定。

僕ははてなダイアリーキーワードチームに配属になり、id:nmy, id:antipop, id:motemenにお世話になることになりました。id:nanto_viとはチームメイトです。皆さん、来週からよろしくお願いします!

以上までがこの2週間の流れでした。インターンのページにカリキュラムがなかなか出てこないので、日報を頼りに書いてみました。読み返してみると、やはり相当詰め込まれてますね (^^;) これでインターンのイメージが多少なりとも伝わると良いな、と思います。9月のインターンは明日が8/20が申込み〆切のようなので、迷っている方はお早めに! 

インターンが課題でどういうものを作ったかは、id:Gemmaの日記で見られます。
http://d.hatena.ne.jp/Gemma/20080814/1218709185

後半もよろしくお願いします!

8/17追記

インターンの申込み〆切は18日ではなく20日でしたので訂正しました。

このエントリは、Webアプリケーション未経験者の私が無謀にもはてなインターンに応募し、苦労している視点から書いています。同期のインターンは皆優秀で、私はどちらかというと着いていくので精一杯なのですが、未経験者の視点から書くのも逆に意味があるのかなと思い、インターンに来るまでにやっておいて良かったこと、やっておけば良かったことをメモしておきます。

Perlの知識
はてなはPerlの会社です。「初めてのPerl」（リャマ本）と「続: はじめてのPerl」（アルパカアルカパ本）は読んでから行きましょう。特に「続」の方が重要で、リファレンスやオブジェクト指向はもちろんのこと、テスト等も使った課題が待ち受けています。私はスクリプト言語自体にそんなに馴染みがなかったので、この本を読んでいなかったら正直死んでいたと思います。なんらかのLLを常用している方なら「Perlクックブック」とかでも良いのかもしれません。

*NIXシェルの知識
基本的にターミナルを使って作業することになります。はてなの独自フレームワークをローカルに入れて課題をこなすのですが、自分のPCにインストール or インストール済みVMWareイメージをもらって使う、という選択ができます。いずれにしても*NIXのシェル操作は必須です。zsh + screen厨多し。

エディタの知識
Emacs vs Vimの論争に着いて行けるようにしましょう。基本的にはどちらかの陣営につくことになります。便利なEmacs LispやVimscriptを入れて、自慢し合いましょう。どちらも使ったことのないひとは、とにかく入れてみて、キーバインドを覚えましょう。

JavaScript + DOMの知識
ユーザインターフェイスプログラミングをさせられます。これが結構盲点で、DOMに触ったことのなかった私は現在ここで結構ハマっています。同期ではこの周辺に強い人が多いので、助けられながら何とかやっています。JavaScriptの簡単な構文と、DOMを弄る知識は身につけていきましょう。ライブラリなどを少し使ってみるのも良いと思います。ちなみにはてなは自社製ライブラリです。

はてな社員の知識
id:jkondoやid:naoyaはもちろんですが、id:antipopやid:secondlife、id:onishi, id:nagayama、id:motemen 等、京都でエンジニアとして勤務しているひとたちの知識を仕入れておくと良いです。僕に教えてくれるひとしか書いていません。すみません。ここに書かなかったひとも、今度いろいろ教えてください。

最後のはネタですが、会社に来てからでも良いので、どの社員の方がどの分野に強いのかを把握しておくと、いろいろ聞きやすいかも知れません。社員の方は全員恐ろしく優秀なので、どの分野のことでもさっと答えてくれますけどね!

他にも必須ではないですが、バージョン管理システムに多少慣れておくと良いでしょう。社内のバージョン管理システムはgitなので、自分でしばらくgitgitしてみると良いと思います。この辺はすぐになんとかなると思うので、あまり重要ではないです。

Web系アプリやLLの経験なしで、「はてな面白そうだぜ！とりあえず行けばなんとかなるやろ！」という勢いで応募してしまう人がいると思いますが、全くおすすめできません。勢いで応募してしまった私が断言します。同期は皆なんらかの経験を持っていて、さくさく課題を進めて行きますが、私は結構息切れしています。C言語で画像処理をしている人間には、新しいことが多すぎます。

しかしこのエントリにある事柄を予習してから参加されれば、課題についていくことは可能だと思います。まあ、同期は課題にさらに付加機能を付けて提出しているようですが・・・。

実際のインターンのプログラムも公開を検討していると聞いていますので、もしかしたらそのうち応募ページに掲載されるかもしれません。

最後になりますが、はてなの環境は素晴らしく、社員の方も皆親切です。社長とも気軽に話せるし、手作りのお昼は出るし、冷蔵庫にはドクターペッパーが常備されているし・・・。

そして何より、ゼロベースだった私が飛躍的に成長している感覚があります。上ではおすすめできないと書いたのですが、未経験でもWebアプリケーションに興味を持っている人は、今すぐ応募するべきです。それは、このインターンがWebアプリの開発を学ぶ最短経路だと感じるからです。大学や大学院に通いながら片手間で勉強しているよりも、はるかに早いスピードで知識を身につけることができます。id:umedamochioが言われている、「高速道路」ですね。

はてなのインターンはその辺の「就業体験」とは全く違います。彼らはプロダクションレベルのコードを求めてきます。そして、実際にインターン生のコードがプロダクトに入る可能性があるのです。そのことに、私は今からわくわくしています。

未経験者こそ行くべき、というようなことを言えるほど甘い環境ではありません。しかし、向上心があり、今からインターンに向けた勉強を始められる方なら、飛び込んでみる価値はあると思います。このエントリはそのような方を対象に書きました。Webの世界にわくわくしている、まだ何者でもないひとへ、９月のインターン募集がまもなく始まります。あなたの夏の予定のなかに、はてなを加えてみてはいかがでしょう。

8/11 追記
インターンが発表されていますね。デザイナーのインターンもあるようです。
http://www.hatena.ne.jp/company/staff/intern

はてなのCTO naoyaさんの発表を聞いて来たのですが、創業時から現在までのインフラ構築の工夫や苦労を語られていました。

はてなnaoyaさん
はてなを支えるバックエンドシステム
関西のエンジニア業界を盛り上げたい

アジェンダ
はてなのサービスを支えるバックエンドシステムを解説
創業時からこれまでの変遷

はてな
ハードウェア350台
14ラック
トラフィックはピーク時は200Mbps

はてなの2001年創業時
人力検索
PentiumsIIIの自作PCで動していた
CGIがボトルネック
CGI->Apache::Registryに変更

mod_perlサーバのメモリ消費が多い
mod_perlが必要ないリクエストもmod_perlが応答する
staticな情報もmod_perlが応答してしまう
Reverse Proxyで三層構造に
静的ファイルはmod_perlなしのフロントが
動的ページはバックエンドが返却

アクセス増加に伴いリソースが不足
Web/DBでハードを分けて分散
PostgreSQL->MySQLへ変更
Web+DB PressでMySQLがおすすめされちた
監視用にNagios導入−＞ケータイへメールして監視

Webサーバ自体のリソースの不足
Reverse Proxyとバックエンドのハードウェアを分離

当時のはてな
会社を支えるだけの収益はまだ見えず
受託開発を開始
同じようなプログラム開発の繰り返し
Hatenaフレームワーク作成
MVCフレームワーク
Perlオブジェクト指向
DB操作、mod_perl API

はてなアンテナ開発
複数の異なるサービスをひとつのサイトで運営
Reverse Proxyで振り分け

試行錯誤により徐々に三層構造に
フレームワークにより開発が効率化->はてなアンテナ
はてなアンテナのヒットによってサーバが増え始める

負荷が増大
mod_perlを増設
mod_reireのRewriteMapで振り分け
DBをテーブル単位で分割
巡回サーバを追加
結合していないテーブルを別のサーバに振り分けていた

増え続けるハードウェア
形がバラバラのPCケース
場所
熱
メンテナンス性

商用サーバは高品質だが効果的

サーバーケースを設計
ケースを設計
サーバーは自作
エアフローも考慮

MySQLが過負荷
MySQLレプリケーション
レプリケーションでレプリカを増やす
参照クエリはスレーブへ、更新はマスタへ
レプリケーションはサポートされたばかりで少し危なかった
振り分けロジックはフレームワークで吸収

mod_perlサーバを継続的に追加
MySQLスレーブを継続的に追加

ルータもLinuxボックス

サービスは週末に開発

2003年はてなダイアリーサービス開始
はてなダイアリーのバックエンド
過去の反省を活かしたテーブル編成

Revese Proxyが接続集荷場に

サービス毎に一つ以上配置
一部はDNSラウンドロビン
ロードバランサを買うお金がなかった
2004年2月東京移転
サービスを一日停止してトラックで搬送
当時のサーバー台数は50台
配送の様子をリアルタイム配信したりしていた

続々サービス追加
フレームワークのバージョンアップ
設計の見直し、UTF-8対応

サーバー追加
トラフィック追加

続くブログブーム
予測不可能なトラフィックの伸び
商用サーバ納期数週間では間に合わない

自作サーバの利点
早い、うまい、安い
柔軟に構成変更可能

mod_perlサーバが落ちると数分の一の確率で繋がらなくなる
Rverse Proxyはフェイルオーバー機能を持っていないため
mod_proxy_balancer追加

開発合宿でブックマークが開発

エンジニアが増加、サービス追加が続く

当時の運用の問題点
SPOF多数
まともにフェイルオーバーしていたのはmod_prxy_balancerのみ

人力対応の限界
回線飽和
ベストエフォート100Mbps回線
太い商用回線を借りるほどのお金がない
電力不足
サーバを追加したらブレーカーが落ちる
運用担当の踏ん張りに依存
消耗戦

運用の複雑化
属人的な運用体制の限界

Klabさんとの出会い
DSASオープンソースで完璧な可用性
こんなに簡単!Linuxでロードバランサ
ほとんどお金をかけずに耐障害性を上げていた

DSAS構築の経験からアドバイスを頂く
安心して寝たいから頑張る
データセンターを見学させていただく

LVS+keepalived
Linuxでロードバランサ
VRRPを使ってサーバの入れ替えを自答でやってくれるｍ
MySQLの手前にLVSを導入
内向けロードバランス
多数のSPOFが解消される

運用の効率化
アプリケーション担当とインフラ担当の仕事の分離が可能に
インフラ側はアプリケーションのことをあまり知らなくてもLVSの操作で切り替えができるようなった
さーくらインターネットiDCへ
DC分の収益は確保できるまでに成長
一年がかりでデータセンター移行
また車で移動・・・
データセンターで体を動かすとなぜか充実感

データセンター移行に伴い
インフラチームを発足、体制強化
古いサーバーをリプレース
CentOS、64bit化
Web+DB部分はほぼ冗長化

故障後のリカバリが面倒な箇所を一部商用サーバに
商用サーバはメモリの故障なども検知可能なのが助かった
メモリが壊れてビット反転、テーブルが壊れるなどあったので・・・

64bt化の追い風
メモリ4GBの壁を突破
メモリが安くなった
DBデータの大部分をOSがキャッシュできる
テーブル分割の必要性が下がる

MySQLのマスタがSPOF

マルチマスタ化
お互いにお互いのスレーブの関係

ファイルサーバがSPOF

DRBDの導入
ブロックデバイスのドライバ
ネットワーク経由でRAIDのようなことが出来る
DRBDで画像保持
lighttpdで画像は信
Squidでキャッシュ
大容量ファイルはMogileFS

新しいインフラが出来るまで
はてなインフラのターニングポイント
klabさんに感謝
チーム体制の役割分担
DC移転タイミングでの再設計
オープンソースでも高可用性インフラ

攻めのインフラ

フレームワークの刷新
Rails, Catalystと比べると古い
自社開発のPerlフレームワーク
Ridge+DBIx::MoCo
ORマッパDVIx::MoCoは近藤社長が開発
メソッドチェインが実装されている
ローカルで開発可能

自分たちで作る意味
コアの設計を自分たちで変えられる
サーバーリソースを使い切れない多数のホスト
バッチ処理専用サーバ
メルサーバ
トラフィックの少ないサーバ

仮想化技術の導入
Xen
1台のハードウェアで複数のOS
現在450ホスト中100ホストが仮想環境で動作中

仮想ホストをディスクレスサーバーで
中央のファイルサーバからOSのイメージを転送

ログ解析が終わらない
大規模データ処理に時間がかかる
Hadoopの導入
GoogleのMapReduceのOSS版
分散ファイルクラスタ

さらなる運用の効率化
OSの自動インストール
PXE Bootでインストール
はてな内RPMレポジトリ
Perlモジュール、カスタマイズしたソフト、自社ライブラリ

Puppet
Capistrano

数百台規模のサーバー情報の管理
スペック、用途、ラック番号、負荷グラフ
サーバー管理ツールの開発
サーバーホストの情報はサーバーから自動取得
負荷状況調査
他ツールとの連携
Nagios設定ファイルの自動生成Capistranoへデプロイ先を自動配信

バックアップツールNotch

はてなと風力発電

試行錯誤のうちに定番手法に行き着くことが多い

守りから責め攻めに転じることができた
インフラの仕事はとてもクリエイティブ
自分たちの得意技を活かして運用効率化できる

インターン募集中

ご自身でプレゼンにうるさいと言っているだけあって、非常に素晴らしいプレゼンテーションでした。冗談を入れてくるタイミングが非常にうまく、引き込まれて行くのを感じつつもう止まらない・・・という至福。

個人的には、金出先生の業績の代名詞であるLucas-Kanade trackerのお話が面白かったです。学生さんだったLucasさんと共同で作ったのは良いものの、金出先生はあまり価値のないものだと思い、適当な学会に出しただけだったとか。それが未だに引用され続けているのは不思議な話だ、と言われていました。金出先生をもってしても、研究の価値を計りかねることがあるというのは意外。それでもちゃんと発表して世に出したから今の評価があるのでしょう。どんな成果でも世に問うことは大切かもしれません。

他にも、実装だけの研究にも、十分価値があると言われていたのが印象的でした。「たとえ理論が既存のものであっても、実装で10倍速くなったなどの成果が出れば、その高速化の理由がわからなかったとしても十分意味がある」と言われるなど、Workするものを重視する、金出先生の価値観がにじみ出ている内容でした。

金出語録
成功するにはかわいくないといけない

かわいいのは大事です。

講演メモ

アメリカの博士課程について
アメリカの博士課程は一貫課程（途中で修士をもらうことも可能）
修士コースのみは職業技術養成課程
学位は「私的」なCertificate
課程、学位、学科の科目などは自由に設定可能
「誰を育てたか」は教授個人や学位の重要な評価軸
院生は研究プロジェクト遂行の重要な「スタッフ」
学生なしに大学の教育は存在しない
そのなかで教育が行われる
教官のプロジェクト資金から院生の授業料・生活費が引き出される
CMUは私学のため、指導学生一人に毎年$80k〜100k
大学に奨学金が払われる
教員から見れば「投資」
大学院生も自分に投資されていることを知っている

金出先生の学生になるまで
アドミッション
試験はGREのみ
すべて書類選考+電話インタビュー

ロボット研究所ではAdmission Committee (教官3〜5, 学生2〜3人で構成) が選択の（ほぼ）全権を持つ
一般学科はAdmission CommitteeはQuality Controlと調整役 (あまり成績がひどいようなら口を挟んでくる)
基本的には個々の教授が個々の学生をAcceptする

狭き門
学生・教授の両者にとって狭き門
CSやRoboticsのように人気のある学科の場合
Acceptしても他の学校に行かれてしまう
志願者(100%)->Accept(5〜10%)->Enroll(その50%)
CS 400人->60人->25人
Robotics 300人->25人->15人
学科で異なる選考過程

学生は複数の大学に志願しているので良い学生は奪い合い
正体Visiting、勧誘電話、時にはOffer条件の交渉まであり

レコメンデーションレター重要
具体的に書かなければいけない
良いことばかりではなく、少しは悪いことも書いてあるくらいが良いバランス
自分で書いてしまうのはすぐにばれる

学生-指導教官の決め方
CS, Roboticsの場合
アドミッションだけではまだ誰が指導教官か決まらない
Immigration courseで先生が自分の研究室を売り込む
先生が”Marriage” proposalを書く
一般的学科
Admission時から決めている
衝突はAdmission Committeeが調整

他大学の学生から熱烈なアプローチがあることも
見込んだヤツがきちんと当たって良い学生だと嬉しい

PhDになるまでのRequirement
Subject, Research, Speaking/Writing
TAがかなりの負担

研究
はじめは先生に提示された研究をやってみる
Thesis Proposal, Thesis Research , Thesis Document, Public Defense
期間は人によりけりで3〜8年
Yieldは意外に低い
Roboticsで100人入って学位を取るのは80人くらい
やめてもらう仕組みもある
辞め方も様々
見込みがないから辞めてもらう場合
見込みがないことに気づくいて自分から辞めて行く場合

学生評価
CS/Robotics
Black Friday
年2回の全教官合同会議による全学の評価会
評価 SP, USP, n-1, termination

一般的学科の方式
基本的には教授の一声
成績、資金（教授のお金がなくなったから辞めてもらう場合もある)

指導教官と学生の関係

指導: 指導する-される
教授としての高い知のプレッシャー
本の宣伝キター!!
アメリカはできるところを見せておく必要がある
どこまで自分の好みを押しつけるべきか

雇用: サポートする-される
雇用者としての「従わせる」プレッシャー
学生は非常に素直
学生が「〜して良いか」と頻繁に聞いてくる
プロジェクトの要求をどこまでさせるべきか
学生の時間を奪ってしまうことを肝に銘じておくべき

友達: お互いの存在を楽しませる-楽しむ
同輩としての「好かれる」プレッシャー
First name basisの関係

教授の息子や娘は簡単に大学に入れる
アドミッションにちょっと交渉すれば入れる

H.T. Kungの「学生発達理論」
教授は神様->意外と出来ないヤツ->それだけのことはある

金出先生は学生をどう育ててきたか
良い研究とは何か
“Good science is in the real world problem”
Alan Newell

「役に立つか」「本当に働くか」
“Newness is not virtue, usefulness is “.
“There are more new things than old ones”.
「新しいこと」はたいてい誰かが考えたけれどつまらなかったこと
“Anything that works is OK.”.
“People remember those who made it really work first, not those who said it first.”
「新しいこと」よりも「良いこと」を

研究テーマ
研究の「メッセージ」「ストーリー」を大事にする
こうして、ああして、こうなって
夢がふくらむ
話せば話すほど、話が大きくなる
後付も良くある（後から考えたストーリーもOK）

Multi based-line stereoから話が発展
部屋も3次元化
「NBAをコートで見る」をキャッチフレーズにし続けた
実際にスーパーボウルでコート全体を3D化

NFSからTransformativeなことを求められた際に気づいた
システムに求められるのは、人の機能を代替することではない
システムが人を助けるのは、人の能力をオーバーしたときだけ
System’s Help = Person’s Intent - Person’s Capability

First-Person Outside in vision
外界からシステムがその人の思考や興味を知ることはできない

人を納得させるのはDetailsとQuantityである
金出語録
“Overwhelm the audience (by details and quantity)”
圧倒しろ
“If people ask how your method works, they are not convinced yet. If they were, they would ask ‘how much is your program?’”

“Science is Detail”

プレゼンにうるさい
研究の価値は人がわかってなんぼのもの
下手なプレゼンテーションは研究の価値を減らす
ストーリーが一貫して記述されているか
日本の論文は〜は重要である、と書いたのにそのことを書かない場合がある
先行研究を否定する必要はない
たいしたことないことを大きく見せる必要はない
聴衆心理学を講義する
こう書いたらどう思うか、を考えろM”A paper must be a mystery story, and its presentation is its dramatization”
“Don’t expect that your audience is eager to listen to you”

テーマ・分野・アプローチ
強い好みはあるが固定しない
しつこく続けてあきらめない
まず例題をやらせてみることで、最後までの見通しをひとまずつかせる
極端を試す、考える

Lucas-Kanade tracker そんなに評価されると思わなかった
最初はただテーラー展開したら良いことが起こっただけど思った
変な学会に1回だけ出した
その論文が未だに出回っている

いろいろな学生
できる学生、何でもどんどんやる学生
何でも聞く学生、何でも訊く学生
先生の感覚を学生にどう伝えるか

結論
教官本人が楽しむ*ことをしなければ、学生はついてこない
*「楽しむ」とは何か
Positiveに知的成果に「素直に」興奮すること

質疑応答
良くできる学生はどんな人間か
しつこい
人がよい
知識を関連づけられる

論文の書き方
無駄なdefinitionは省く

成功するにはかわいくないといけない

PDFファイル

大学院受験シーズンが近くなってきたせいで、NAISTに見学に来るひとの対応をすることが多くなってきました。その際に大多数に聞かれるのが、NAISTの入試について。ペーパーテストがない面接入試のため、皆さん逆にどうやって対策して良いか不安になるようです。確かに僕も最初は不安でしたので、気持ちは大変わかります。

言い切ってしまって良いか多少不安はありますが、以下にだいたいのところを書きます。面接の中で数学、英語はあるのですが、一番重視されるのは出願の際に提出する小論文と、それに関する面接項目です。そのため、対策に最も時間をかけるべきは小論文です。

こういう話をすると、どうやって書いたら良いかわからないと言われることも多いので、そんなときは大体僕が書いた小論文を渡して説明しています。

しかし

• 毎回印刷するのも手間
• 結構需要があるらしい
• NAISTに興味を持ってくれる人を増やしたい

といった理由で、思い切って公開してしまうことにしました。

内容についてですが、友人の小論文と比較した場合、僕の書いているものはかなり研究に踏み込んだ内容になっているようです。つまりここまで具体的な提案はなくても良いらしい。また2カラムである必要はありません。参考文献も話の展開上特に要らなければ、書く必要はないでしょう。

他の人の小論文が見たければ、NAISTの有名人、小町さんのサイトが参考になるでしょう。

ちなみに僕の研究テーマは、ほぼ小論文に書いた路線でやっているので、あの時期にいろいろ考えておいてよかったと思うことも多いです。

それでは、駄文ではありますが、誰かの役に立つことを願っています。

僕はただの好奇心で見に行ったのですが、id:jkondoさんやid:naoyaさんとお話しできて楽しかったです。（自分のやってきたことを多少プレゼンする機会もあって少し焦った）スタッフの方も非常に親切で、お昼までごちそうになってしまいました。

大きな炊飯器でご飯が炊かれていたのがなんだかアットホーム。id:reikonさんとid:jkondoさんのあうんの呼吸な掛け合い何度か目撃し（特にごはんのタイミング）、この会社がどう成長してきたかの一端を垣間見た思いでした。パートナー大事ですね、パートナー。

烏丸御池の駅からすぐ近くのオフィス

透明なパーティションで区切られた空間

中央のテーブルの端にはpolycomがあって東京オフィスと常時接続されています

噂の卓球台だ!

オフィスはイメージより広くはなかったのですが、アクリルのパーティーションのおかげもあって狭さはない感じ。固定されたデスクトップPCで広いモニタを使っている人、ノートPCで好きに動き回っている人など様々でした。このあたりは自分の好みで選べるようです。エンジニアはデスクトップが多めとのこと。

何度かメディアやブログで拝見していたオフィスですが、実際に行ってみても快適そうな。はてなの皆さんありがとうございました!

日付を超えるときは東京のホテルにいて、友達と話しているうちにいつの間にか針が12時をまわって、それで24歳。新幹線で関西へ帰って来て、そのまま知り合いのつてで京都はてなを見学して（自慢!）、学校に帰ってコードを書いたり実験したりしているうちに、またいつの間にか誕生日も終わっていきました。

以前「海馬」という本の中で糸井重里さんが「30歳の誕生日は人生の縮図」だと言っていたように記憶しているのですが、毎年の誕生日だって、たぶんそうなんじゃないかと、漠然と思っています。きっと今日と同じ様なことを毎日続けていくのが自分で、こんな風にばたばた毎日を過ごしていく一年になる予感がしています。

少し動いてみるだけで、遠いと思っていた世界がぐっと近づいた気がしたのが昨年でした。今年もその路線を踏襲して自分に多少の負荷をかけながら、押しつぶされそうになりながらも、ギリギリ乗り越えていく様な（今は乗り越えられていないことも・・・汗）生き方を続けて行く予定です。

僕を支えてくれている本当に多くの方々、友達、家族、彼女、ありがとう。今年もたくさん迷惑をかけると思いますが、よろしくお願いします。

研究で先代からの資産（コード）を利用するため、GUI作成にgladeを使う羽目になっているのですが、gladeのおそらく1.x系と2.x系で.gladeファイルのフォーマットが変わっている様子。現在パッケージで簡単に手に入るのは2.x系なので、1.x系で作られたファイルを変換する必要あり。調べたところ英語のソースしかなかったので、書いておきます。

1.x->2.xへのコンバータはlibglade-convertという名前で付いてきます。普通に引数に1.xのファイルを指定してやれば完了。。戻す機能はなさそう。以上。

ちなみに、最新の3.x系はCのソースを吐いてくれないので、今の実験プログラムを大幅書き換えしないと使えない模様。特に必要ないので無視の方向で。

[追記]
あとから調べたら、普通に書いてる人いますね(汗
ORCA愉快日記 Ruby/GtkとRuby/Gtk2のサンプルを書いてみた