世界最大級のモノリシックRailsサービスと言われて
![クックパッド 技術部部長 兼 エンジニア統括マネージャー 庄司嘉織氏](http://cz-cdn.shoeisha.jp/static/images/article/10988/10988_001.jpg)
クックパッド 庄司嘉織氏は2012年11月に入社。入社当初はサービス開発を担当した後、ユーザー投稿を担当する部の部長になった。その後、同社で動画配信サービスを立ち上げることになり、「だったら開発は俺にやらせてくれ」と立候補した。後に人事部長を引き受けた時にはエンジニアならではの視点も交えた社内制度を推進してきた。
クックパッドのサービス開始は1998年。10年が過ぎた2008年にアプリケーションをRuby on Railsにリプレースした。理由として庄司氏は「クックパッドではユーザーに価値を早く届けることを一番大事にしており、そのためにはサービス開発をいかに早く回せるかが重要になります。その観点で採用しました。加えて当時、ORMからテンプレートまでフルスタックでそろっているフレームワークは、ほかにあまりありませんでした」と話す。
Railsはサービスを早く開発することに効果的だったものの、次第にサービスの規模が大きくなっていく。2015年3月、RubyとRailsのコミッターを務める松田明氏が、海外のイベントで「The Recipe for the World's Largest Rails Monolith」としてクックパッドを紹介したことで「世界最大級のモノリシックRailsサービス」として知れ渡るようになった。
大きくなると全体把握が難しくなってくる。テストの分散化やデプロイツール自作など弱点を補いながら開発を回していたものの、次第に開発スピードが鈍化するなど巨大モノリシックの問題が顕在化してきた。エンジニアの間でも危機感が共有され、「今、大丈夫でも将来破綻するならすぐにでも手を打たなくてはならない」ということで、現在はサービスとプラットフォームの両面からマイクロサービス化を進めているところだ。
なお同社ではこれまでも改革を試みたことがあるものの、壮大すぎて頓挫してしまった経験があるそうだ。「現在は切り抜けたとは言えず、まだ道半ばです。地道に進めています。今度はやりきろうと思います」と庄司氏は決意を語る。長い時間をかけて大きくなるまで構築したシステムを機能や性能を維持しつつ、分解して身軽になることはそう簡単ではないはずだ。
庄司氏によると、HTMLを出力するなどフロントのビュー開発にはRailsが有利であるものの、他の言語が有利な場合もあるため、適材適所で進めているという。例えば特定のAPIサーバーにはGoを採用するなど。これは社内コンテストの結果を受けて採択された。要件を定め、各エンジニアが得意の言語で開発して競ったところ、Goが最も早かったという。庄司氏は「結果で早いと分かれば誰も文句ないですからね」と言う。合理的だ。
エンジニアには「じゃましない」、しかし採用は妥協しない
現在日本にいるクックパッドのエンジニアは100人ほど。Rubyや最先端技術を使いこなすエンジニア集団となる。
エンジニアに対する会社の基本的なスタンスは「じゃましない」(庄司氏)。仕事の開発も新機能のキャッチアップなどのスキルアップも本人に委ね、好きにさせる。自由に実験できる環境も提供している。例えば本番とは別に検証用で使えるAWSアカウントがある。庄司氏は「ほぼ無制限。100台のサーバーを立ち上げるにしても誰の許可も要らないようにしています。どんなに作っても、壊しても大丈夫。エンジニアには好きに使える環境が必要ですから」と話す。
ここまで自由を与えるのは「そのほうがコストがかからないから」だそうだ。仕事を進めるうえで「これはいいけど、これはダメ」など制限をつければつけるほど、管理にコストがかかる。その代わり、採用は厳しくする。入口のハードルは高くしておいて、入ったら自由に開発に専念してもらうほうがエンジニアにも管理側にもいいという考えだ。
実際、庄司氏は採用担当には「クックパッドにいるエンジニアの平均レベルを高められる人を」と注文している。そうなるとクックパッドの平均よりも高いレベルでないと採用されないことになる。厳しい。庄司氏は「もし人が足りなくて平均レベル以下を雇ったら平均が下がります。ポール・グレアム(有名なLISPプログラマ)がかつて『技術の世界では、いったんダメなプログラマを雇ってしまったらお終いだ。会社が技術的に平凡になってしまい、その後、回復した例を私は知らない』と話していました」と語る。エンジニア採用で妥協しないのは負のスパイラルに陥らないため。
たとえ人手不足になったとしても積極的に外注を使うことはしない。なぜなら知見を会社に蓄積するためだ。例えば人手不足で外部に任せるとなると、知見が外部にたまってしまう。サービスを完成させるまでの試行錯誤には貴重な知見も混じる。そうしたものが外部に蓄積してしまうのは惜しいという考えだ。
具体的な採用プロセスはどうしているかというと、応募者には自分が書いたコードとGitHubのアカウントを提示してもらう。言語はRubyでなくてもかまわない。学歴や実績はあまり気にしない。応募者のソースコードとGitHubでスキルと活動状況を判断しているという。庄司氏は「サービス開発するためのエンジニアを求めているのですから」とあくまで実戦力重視だ。