Shoeisha Technology Media

CodeZine(コードジン)

特集ページ一覧

Rubyが魅力的でないとうちのビジネスが困る――クックパッドが取り組むRubyへの貢献とエンジニア育成

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2018/08/27 14:00

 クックパッドは1998年にサービス開始し、2008年にRuby on Railsにリプレースしてからちょうど10年。その間、クックパッドはRubyの会社として常にトップランナーを走り続けてきた。実際、「世界最大級のモノリシックRailsサービス」として知れ渡り、その開発で培ったノウハウをコミュニティに対して発信してきた。そんなクックパッドが、Rubyに対してどのように付き合っていったのか。Rubyを採用した経緯や課題、競争力の高いエンジニア集団で居続けるための戦略について、同社 技術部部長 兼 エンジニア統括マネージャーを務める庄司嘉織氏に聞いた。会社を挙げたRubyやオープンソースへの貢献やエンジニアとの関わり方も興味深い。

目次

世界最大級のモノリシックRailsサービスと言われて

クックパッド 技術部部長 兼 エンジニア統括マネージャー 庄司嘉織氏
クックパッド 技術部部長 兼 エンジニア統括マネージャー 庄司嘉織氏

 クックパッド 庄司嘉織氏は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でスキルと活動状況を判断しているという。庄司氏は「サービス開発するためのエンジニアを求めているのですから」とあくまで実戦力重視だ。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 近藤 佑子(編集部)(コンドウ ユウコ)

    CodeZine編集部 副編集長。1986年岡山県生まれ。京都大学工学部建築学科卒業、東京大学大学院工学系研究科建築学専攻修士課程修了。「院試浪人中に暇だったから」「プログラマーの友人が増えたから」という理由でプログラミングやWeb制作を学び、IT企業への就職を目指していたら、一時は就活生として有名...

  • 加山 恵美(カヤマ エミ)

    フリーランスライター。茨城大学理学部卒。金融機関のシステム子会社でシステムエンジニアを経験した後にIT系のライターとして独立。エンジニア視点で記事を提供していきたい。EnterpriseZine/DB Onlineの取材・記事や、EnterpriseZine/Security Onlineキュレータ...

All contents copyright © 2005-2018 Shoeisha Co., Ltd. All rights reserved. ver.1.5