今回、弾さんが訪問したのは、（⁠株）ミクシィ。検索エンジン開発からアプリケーション運用まで、ミクシィを作り上げ、支えている4人のエンジニアの方々に逢ってきました。

自己紹介

弾：では、さっそく自己紹介から。

津久井（以下、津⁠）⁠：mixiアプリケーション開発グループマネージャーの津久井です。仕事内容としては、マネジメントが主です。

弾：ちらっと紹介しておくと、かつて僕がマネージャーで津久井さんにコードを書いてもらったことがあります。大昔の話です（笑）（⁠注1⁠）⁠。

平林（以下、平⁠）⁠：平林です。研究開発グループのマネージャーをしていまして、研究開発グループ自体は僕を含めて5人です。仕事としては、マネジメントは2～3割くらいに抑えて、あとはだいたいコードを書いています。

長野（以下、長⁠）⁠：システム運用グループアプリケーション運用チームの長野です。システム運用グループは、mixiと、Find Job!のインフラをやっているチームと…。

弾：じゃあ、データセンター担当みたいな。

長：アプリケーション運用チームは、データセンターに行かない運用チームなので、監視だとか、障害対応、セキュリティ系の実務ですね。アプリケーションのデプロイメントとサーバの設定もやっています。

弾：要は、ロジカルなホストのデプロイメント…。だいたいどんな感じでやっていますか？ すでにOSだけ入ったのが、ずらっと並んでてっていうようなイメージ？

長：インフラ（部隊）にやってもらうのはOSのインストールまでなので、IPリーチャブルになってる状態までで、そこから先はこっちでやります。

大窪（以下、大⁠）⁠：私は開発部のタンポポ開発グループという…。

弾：タンポポ開発グループ…？ まさか刺身タンポポ開発グループということですか（笑⁠）⁠。

大：はい。タンポポ開発グループという名前のグループにいるんですが、チーム名の由来は刺身にタンポポをのせるような仕事をなくすための…[2]⁠。

弾：あ、名前の由来は刺身タンポポなんだ（笑⁠）⁠。マジ？（笑）

大：そういう作業をなくすためのアプリケーションの裏方的な、たとえばライブラリ的な側面や、案件と直接絡まないけど、影響範囲がでかいというようなものの改修を行うグループに属しています。

弾：ミクシィには今、エンジニアって何人くらいいらっしゃるんですか？

津：mixiの開発をやっているメンバーだけで60前後です。運用も含めると80、社内システムとかデザイナも含めると100人くらいです。

お気に入りのシステム・ソフトウェア

弾：これまでやってきたシステムで自分の一番お気に入りは？

津：僕はマネジメントが10割で、コードは一切書いていないので、手がけたシステムっていうのがないんです。しいて言えば、最近話題になっているmixiアプリは僕のチームが手がけているもので、間接的に僕も関わっているところなので、mixiアプリが今、一番気に入っています。

弾：平林さんは？

平：検索システム系はだいたい僕が作っているのですが、その中で気に入ったというか、手こずったのが、ユーザ検索機能です。僕が作ったんじゃないんですけど、mixiがまだ小さい時代から仕様があって、名前とかニックネームとかで検索できるだけでなく、血液型で絞り込んだりとか、出身地で絞り込んだりとか、それを県単位、市単位とかってやっていました。普通の検索システムではないような、いわゆるRDB向けの検索項目がいっぱい並んでるのを、2,000万エントリに近づきつつある規模で動かさなければならないという課題がありました。Hyper Estraierというのを昔作っていて、それをそのまま動かしてて、だいたいユーザ数が1,000万以下くらいのときは問題なく動いていました。ですが、そろそろ東京都全員を抽出するみたいなクエリを投げられるようになると固まってしまうようになってきて。それで急遽、Tokyo Dystopiaっていう検索エンジンを作りました。それはまさにユーザ検索をなんとか持ちこたえさせるためだけに作っていて、全部オンメモリで処理をするとか、インデックスをすごい圧縮して持たせるとかをいちいち作ったので、それのおかげで今はほとんどストレスなく使えるようになっています。その割にはすごく台数が少なくて済んでいて、かつ速くなるだけじゃなくて、検索の適合性も、スコアリングを改善することによってそこそこいい検索結果を出せるようになっているんです。それは単に検索するだけじゃなくて、ユーザのグラフ分析を行っていて、自分からネットワーク的に近いユーザを出すことができるんです。それもすごい計算量がかかるんですけれども、それもTokyo Cabinetのオンメモリモードっていうのを使ってなんとか動くようにしていて。それのおかげで相当複雑な検索なんだけど、ほとんどそれを感じさせない。そのへんはかなり気に入っています。

長：一番は、memcachedをどうやって動かすか[3]っていうのと、Q4M[4]という、奥一穂さんが作られたメッセージキューのしくみを導入したり、あとは画像配信全般ですね。画像が一番苦労しているかなと思います。

弾：画像のどの部分ですか？ あんまりメモリに載らないとか？

長：画像のファイルが10億くらいあります。あとプロフィール画像のアイコンを1ページ50個表示したりというのが普通に行われるので、それをどうやって配信するか。プロフィール画像としては数千万なんですけど、アクセス数がものすごいたいへんなことになります。それをどうやってさばくかというので、Squid[5]を多階層にしたりしています。

弾：大窪さんは？

大：少し昔なんですけど、まだエンジニアの人数が少なくいろいろ試行錯誤していた時期に、昔ライブドアにあこがれていたこともあって、宮川さんのSledge[6]とかを参考にして社内の簡単なフレームワークを作りました。今も使われているんですがそれを実験する意味で動画のサービスを作ったりして、そのあたりが一番お気に入りです。

mixiアプリ

弾：mixiアプリというサービスを出したわけですけれども、ぶっちゃけた話、mixiアプリが当たればの話ですけども、これからは事情がわからない人が書いたコードがいっぱい、実行されるわけですよね。何か対策というのは？

津：たとえば全件走査はできないつくりにしたり、APIに制限を入れています。あとはキャッシュをうまく使うとか、実装を担当しているわけじゃないので具体的なことまでは言えないんですけど、負荷が高くならないようにはしています。

弾：結構怖いんですよね。人様に自由にしていただくというのは。

津：直接データベースをいじれるわけじゃなくて、あくまでAPIをこちらが提供して、そのAPIをたたいてねっていう感じです。

弾：APIさえ監視しておけば大丈夫なはずだと。

津：あと、作ったばかりのアプリケーションは、全員に見えるわけじゃなくて、mixiの審査を通らないといけない。

SNSの健全化

弾：本誌の質問からはみ出ちゃうからもしれないんですけど、SNS（Social Networking Service）のユーザに健全なことを期待するというのは、健全なことなんですか？

一同：（笑）

弾：なんでプライバシーが必要かというと、人間は100％健全ではありませんよ（笑⁠）⁠。だからプライバシーが必要なわけですよね。それで、普通のWebにあまりに健全性を求められるから、SNSみたいなところで不健全でもOKな癒しを求めてたはずなのに、そこで健全化というふうにやられると、なんか、すごい苦しくないですか？ 僕としてはmixiはそういう不健全な人を健全な世の中から守ってほしいというのがあるんですが（笑⁠）⁠。

平：ユーザーが安心安全に利用しやすくするための健全化ということですね。

優れたエンジニアとは

弾：優れたエンジニアってどういう人だと思いますか。

平：僕は2種類いると思っていて、新しいものにどんどん飛びついて、アンテナがすごく広くて、で、短時間で新しいものがどんどん出てくるので、短時間でやって判断して、というタイプが1つで、器用な人はそれでいいと思っています。それはそれでいいエンジニアになれると思うんですけど、たとえば僕は新しい技術とかには全然疎いし、1個のものがいいかどうか判断する能力が全然ないと思っているので、1個に飛びついたらそれをずっとやっちゃう性質なんですね。だからいまだにDBM、20年前の技術をずっとやってるっていう話になるんですけど。そういう結構地味なことをずっとやるのって、モチベーションを保つのがすごく難しいっていう側面があって、となるとそれを一生懸命やるためにはモチベーションを保つ能力はすごく大事だと思っています。じゃあ、そのためにどうするんだっていう話になるんですけど、一番いいと思ってるのは、実際の課題に触れて、たとえば長野さんだったら画像の配信がすごく重いっていう課題に触れてそれを解決するための技術をかき集めてきてインテグレーションして出す。具体的な、しかも本気でやらなきゃいけない課題に自分の身を置けるかが結構重要だなと思います。

弾：ミクシィに入るには、自分で課題を見つけて解くという能力を見ますか？ あるいはそういう技術は社内に入ってから培ってもらえばいいと考えますか？

津：面接では、今まで一番困ったことは何か、それをどうやって解決したかをだいたい聞いてます。そういった意味では、問題に行き詰まって、どう解決したかっていうのは重視していますね。

弾：エンジニアは困ってなんぼだと（笑⁠）⁠。

大：作り終えた過程よりは、作るまでの過程を含めて困っているっていうシチュエーションこそ楽しかったりしますし、そういう実感を得られるっていうのは1つの資格かなあと思います。できあがったから自慢するっていうのだけではなくて、やっぱりその今、困っているんだぜっていうことこそもっと自慢してほしい。

長：自分の隣の席の人は、困ってるとずっと笑ってる（笑⁠）⁠。すごくおもしろい方で、運用なので、グラフとかログとかダーって流れてるのを見て笑ってるんですよ。それは能力としてすごくおもしろい。あと、運用エンジニアというくくりでいうと、結構なんでもできるんですよ。ブート権限を持ってどこのデータだって、MySQLのSELECTコマンドを叩いたりすればすべて見られるわけじゃないですか。で、それをしないっていうのはどういうことなのかなっていうのを自問自答して考えてます。ちょっと前にイベント[7]で、運用エンジニアっていうのは、「⁠地図に残る仕事」（⁠注8）って自分で言ったんですね。地図に残る、道路なり橋なりを作る仕事って、ものすごい自信も持てるし、責任も伴う。そういうことを感じられる人は優れたエンジニアなんだろうなって思います。

平：課題を解決するために計画を立てて物事を進めるということをエンジニアリングだとすると、結局、重要なのは、課題はただ単にゴールだけ設定していると何もできないので、全部必要なものにブレイクダウンして、解けるレベルまで落とし込んでいくというのがすごく大事だと思います。そうすると、最後に出てくるのは自分がちょっとやればすぐ解決できるレベルになっているはずなんですけど、それをどんどん文章にするなり形にしていって、で、1個1個潰していくっていうまとめ方ができる人がエンジニアとしては優れていると思う。

弾：問題を要素まで分解できるということですね。