株式会社ディー・エヌ・エー エンジニア特集

  以前勤めていたのはキャリア系のホスティング屋で、ちょっと暇だったんです。それで、もともとPerlのコミュニティで長い仲の山口に「じゃあDeNAに来ない？　こっちのほうが楽しいよ」ってずっと言われ続けてたんですが、正直ほかの会社もいろいろな見ながら考えてました。
  実際にDeNAを決めたときには「コンシューマー」と「ケータイ」の2つのキーワードが頭にありました。私はずっと法人向けのサービスをやってたので、今後はコンシューマー向けもやりたい、と考えているうちにケータイかなという流れですね。それは単純に、ケータイをプラットフォームとしたビジネスを経験したことなかったことがひとつと、普通のケータイに“パイ”を感じたことが大きいですね。
  コンシューマーということは、大きければ大きいほどいいわけです。となると、新しいプラットフォームよりも、既に広まっているプラットフォームのほうがいい。Twitterが盛り上がっているころ、ふと地元に帰ったときに周りが使ってるかというと、意外と使われてない。iPhoneのようなスマートフォンもまだアーリーアダプタしか届いてなくて、もっと自分の親や兄弟が使うようなサービスを考えると、ケータイの方が大きかったんです。

  入ってみてビックリしたのは、インフラ・サーバー周りから、ビジネス・サービスまで考えることができるひとが、けっこう多いんですよね。プログラムだけじゃなくて、サーバーの構築やネットワークのことまでよくわかっている。その上で、お金にするためにはどういうサービスを出せばいいのか？　どうやればユーザー喜んでもらえるか？　ってところまで考えてる。優秀なジェネラリストがたくさんいるってかんじです。すごい強みだと思います。
  もちろんスペシャリスト、ここは絶対すごいという人もいるんですが、上から下までまんべんなく、しかもけっこう深く知ってて、実際にコードを書きながら、企画ともやりとりしながら、負荷分散をちゃんと構築しながら、システムのひとも客のほうを向いている、っていうすごくスペックの高い人が、けっこういる。我々のチームにもいたし、だからオープン化のプラットフォームも短期間でリリースできたのかなとおもいます。
  よくありがちなのが、システムをよく知らない企画のひとが「絵に描いた餅」を持ってきて、技術者もあまり意識しないで作ってしまって、はいリリースってときにはゴチャゴチャになってるって世界ですね。けっこうあるとおもうんですけど、DeNAでは「システム的にはこうしたほうがいいとおもうし、このほうがお客さんも喜ぶよ」っていうことを技術者が言える。これはすごく健全だとおもいます。

  これまでモバゲーでは、MobaSiF（モバシフ）っていう独自フレームワークを使ってたんですが、オープン化ではまったく使ってないんですね。山口のところは「Catalyst（カタリスト）」っていうPerlでいちばん使われているアプリケーションフレームワークを使ってて、ぼくが担当したガジェットサーバーでは「PSGI/Plack（プラック）（外部リンク）」を使いました。
  PSGI/Plackは、宮川達彦さん（シックス・アパートの技術者、日本を代表するPerlギークのひとり）が去年の8月くらいに提案して、開発をはじめたプロダクトプロジェクトです。9月のYAPC（Perlのカンファレンス）で発表されたんですけど、11月のリリースに合わせて、PSGI/Plackを使うという判断は10月までの段階でできました。
  それは作っている途中からIRCのチャンネルでずっと一緒にコードは見てて、忙しかったんでとくに貢献はできなかったんですけど、中身はだいたいわかってるので、問題はなかったですね。まあ、いざとなればコミュニティの知恵を借りながら直せるとも思ってましたから。　CatalystやPSGI/Plackは、今後もDeNAで使われていくとおもいます。Catalystは情報も豊富ですし、もうほかのところでも使われてます。PSGI/Plackも、今度デファクトスタンダードになりうる技術です。モバイルでも展開できますし、HTTPを使う上でとても有益な仕組みですね。

  モバゲーのオープン化に関しては、そもそも8月の段階ではOpenSocialを使うかどうかも決まってなかったんですよ。「OpenSocialで本当にいいの？　独自APIのほうが自由にゲームを作れるんじゃない？」という社内の空気だったんです。でも私としては、OpenSocialを取り入れて、プラットフォームの共通化を図ったほうが良いとおもってました。
  それはOpenSocialを採用しているmixiが先行していたこともあって、我々は半年間でプラットフォームを構築したんですけど、2010年1月のリリース時点でちゃんと100近いゲームを出せたのも、すでにmixiさんで作っていたものを移植しやすかった、というのはきっとあるんですね。そこは選んでおいて良かったとおもいます。
  その同じAPIの上で差異を出すところが競争で、たとえば我々だと完全にOpenSocial準拠の「コアAPI」のほかに、アバターなどを提供する「ゲームAPI」を用意しています。mixiでも、たしか同級生が独自APIですよね。そういうプラットフォームごとの特徴を出せば、ユーザーも飽きることはないし、戦う楽しさもあるとおもいます。
  ただ、ガジェットサーバーの設計にはかなりモンモンとしました。つまりOpenSocialの世界で、このアーキテクチャが本当に技術的に正しいのかどうか正直自信がなかったんです。というのは、OpenSocialにはもともと日本のモバイル環境を考慮した仕様はなくて、OpenSocialを噛み砕きながらガラケー（ガラパゴスケータイ＝独自の進化を遂げた日本のモバイル環境のこと）に落とし込んできたものだったんですね。
  これは最後までモンモンとしてましたね。今はもう変えたいとおもってるくらいなんです。正直、あのアーキテクチャはあまりよろしくはないですね。仕方がないとは思うんですけど、ベターではあるんですけど、ベストではない。ベストはやっぱりあるので、道のりは長くなりそうですけど、そこは目指していきたい。
  システムって生き物なので、変え続けていかなきゃいけないんですね。常に良くすることができますし、チャレンジし続けないと忘れ去られちゃう。これは信念ですね。動いているからといって手を加えないでニッチもサッチも行かなくなるより、むしろ短いスパン、細かい単位で変えていって、技術革新をどんどん取り入れたほうが、後発に追いつかれることもない。っていうのがぼくの考え方です。

  今後のキャリアですが、基本的にコードはずっと書いていきたいですね。マネジメントもしなくちゃいけないんですけど、コードも書いていたい。棺桶に入るまでコードを書いてたいです。
  技術者って、常に新しいモノに触れてないと、陳腐化するとおもうんですよ。言葉って誰でも言えるじゃないですか。実際に触っているひとが言った言葉と、そうでない人の言葉って重みが違うんですね。ぼくは将来マネジメントをズッポリやんないといけなくなっても、コードを書くことを止めるってことはたぶんないとおもいます。
  社内にもそういうひとが増えてほしいですね。コードを書きながらマネジメントもして、しかも新しいことに常に触れている。マネージャーのようなレイヤーのひとが新しいことを知らないと、次のステップの絵が描けないじゃないですか。それはカッコ悪いことなので、常に新しいことを率先して取り入れていく。取り入れるには責任を持たなくちゃいけなくて、責任をもつためには中身を知らなきゃいけないし、中身を知るためには自分がちゃんと触ってないといけない。
  DeNAでは、単純に新しい技術を持ち込むこともぜんぜん可能です。もちろん自分で責任を取らないとだめですよ。中身わかってて、きちんと機能するものでないと当然ダメなんですけど、そこがわかっていれば、どんな新しいものだって使っていいって空気はありますね。そうやって新しい技術にチャレンジできるという意味において、コードを書く人にとっても幸せな会社だとおもいます。