21言語67ヶ国に展開するレシピサービス、クックパッドグローバル化の裏側

2017年9月29日(金)
西野 竜太郎Think IT編集部

取材協力:クックパッド株式会社 滝口 健太郎氏

料理レシピサービスのクックパッドもグローバル化を推し進めている企業の1つです。プロダクトのコンセプトをしっかり維持しつつ各国各地域の食文化に根ざしたコミュニティーを形成するためには、開発組織も自ずとグローバルなチームになっていきます。海外事業の拠点であるイギリス在住の滝口氏に、クックパッドにおけるサービス展開について聞きました。

クックパッド株式会社では2014年から本格的に海外展開を進め、今では21言語67ヶ国(2017年6月時点)でサービスを展開しています。海外事業に携わるメンバーは全世界で約150人近くで、そのうち日本人の割合は約10%と多国籍なチームになっています。グローバルのヘッドクォーターはイギリスにありますが、それ以外にも日本、スペイン、インドネシア、レバノンなど世界中に拠点があります。

いろんな国を巻き込んでコミュニティーを成長させていく

地域ごとの食文化を考えて日本のクックパッドとはプラットフォームこそ別にしていますが、"毎日の料理を楽しみにする"というミッションや、レシピ作者がレシピを投稿しユーザーから「つくれぽ」*11としてフィードバックをもらってまたレシピを投稿する、そういった好循環のサイクルがコミュニティーを成長させていくという基本的なサービスの方向性は同じです。

[*11] 「つくりましたフォトレポート」の略で投稿されているレシピをユーザーが実際に作りその感想を写真付きで投稿するしくみ

様々な言語、背景、食文化を持つユーザーに使ってもらえるサービスにするためにはその地域の文化の理解は必須です。そのため、チームの多様性もグローバルプロジェクトの成功のための重要な要因になります。そこで、クックパッドでは組織をスケールさせるためにプロジェクトの開始当初からコミュニケーションは英語で行ない、社内システムも日本人向けの日本語のみに対応しているものからグローバル仕様のものに移行しました。その結果、採用に日本語のスキルという制約がなくなって世界中から優秀な人を採用できるようになり、この多様性が今のクックパッドを支えています。

検証のサイクルをいかに早く回せるかがキーになる

私たちのプロダクトチームは「Squad」という単位に分かれていて、各Squadにプロダクトオーナー、デザイナー、エンジニアが存在する構造になっています。また、ゴール設定の仕組みとしてOKR(Objectives and Key Results)*12を採用していて、期の最初と最後にレビューがあります。Squad内でどのようにプロジェクトを進めるかはそれぞれ違う文化を持っているため総括するのは難しいのですが、リーン開発やデザインスプリントなど、Build-Measure-Learn(構築-計測-学習)のサイクルを細かく回していくようなプロセスを採用しているSquadが多いです。

[*12] 目標と主な成果による管理手法、インテル発祥とされその後多くのグローバル企業で採用されている

リリースはプロジェクトの終わりではなく、イテレーションの通過点です。リリースされた機能が実際にどのようにユーザーに使われているかを定性的・定量的にモニタリングをしながら改善を繰り返していきます。一般的にはどのようなプロダクト開発においてもこの仮説と検証のサイクルを回すことは重要なのですが、特に海外展開となると仮説と現実のギャップが大きくなりやすくなります。たとえば日本ではどこでもネットワークにアクセスできるのは当たり前ですが、インドネシアではスーパーマーケットやキッチンにネットワークがないことも珍しくないため、ネットワークにアクセスする前提で作った機能が全く役に立たないということもあります。このように自分は当たり前だと思っていたことが当たり前ではなかったということが世界のどこかで毎日起こるので、そのギャップに早い段階で気付いて方向修正できるかが重要になります。

中東などで現地ユーザーに受け入れてもらうためには

企画・設計段階では、プロダクトとして実現したい世界や、コアとなる普遍的な価値を元に機能をデザインします。ここではあまりグローバリゼーションは意識していません。ただし、いざ開発段階になると、その実装方法が特定の国に依存しすぎていないかや、各国で違う法律に基づいたケアができているか等、法務部との連携の必要性が発生します。

ロケール選定は市場規模や経済の成長度合いなどを参照していますが、それに加えて食文化の豊かさや、その地域に情熱を持ってクックパッドのプロダクトの改善に取り組む人がいるか、という点も重視しています。

I18N、L10Nにおいては、そのプロダクトにおいて何が重要かを考えています。クックパッドではこれから急成長を迎えるアジアやアフリカにも力を入れています。そのような国ではモバイル端末のスペックが低かったり、ネットワーク速度が遅かったりします。そのような環境でもプロダクトが快適に使えるようにするために、現地に行って現地のモバイル端末で自分で開発した機能を使ってみたり、国内向けのプロダクトを開発していたときよりもパフォーマンスチューニングに力を入れたりしています。このように、タスクの優先度はプロダクトを展開するロケールによっても変わってきます。

中東も重要なマーケットなので、ローカルに受け入れてもらえるようにするために細かな変更を加えています。中東では英語を読める人の割合は高く、LTR(Left to Right)のサービスを使うことも珍しくないのですが、それでもRTL(Right to Left)に対応していると"自分の国のサービス感"が出てローカルの人に受け入れてもらいやすくなるそうです。それ以外にも画像のプレースホルダーを魚や米のような中東の人に馴染みが薄いものから、地域や宗教に関係なく食べられている芋や鶏に変更するなどしています。

RTLであるアラビア語のアプリ画面

RTLであるアラビア語のアプリ画面

もしこのような変更をしないでリリースした場合は、例えば日本人にとっては「あるWebサービスにアクセスしたら中華フォントで表示されて、読めるんだけど日本人向けでないように見える」と感じるのようなことが起こるのかもしれません。同じ文字コードでもフォントによって中国語の簡体字・繁体字、日本語、韓国語で形が違うことがあるのですが、漢字圏外の人にとっては見分けが付かないという話を聞いたことがあります。このように現地の人は分かるが開発者は気付かないという問題が至るところにあるのだと思います。本質的にはプロダクト開発はコアとなる価値をいかにユーザーに伝えるか、そして価値を伝えるのを阻害している要因を減らすのがL10Nだと考えています。

各種プラットフォーム、多言語対応の技術的ハードル

クックパッドのバックエンドとして採用しているRuby on Railsや、Android、iOSは標準でI18Nをサポートしているので、基本的には標準的な方法に従っています。ただしモバイルアプリはウェブと違ってアプリストアの制約があるため、いつでもアップデートすることができません。そのため、もしリリース後に間違って翻訳されたフレーズを見つけて更新したいと思っても、決められたリリース日まで待たなければなりませんし、いざリリースをしようとしても、サポートしている言語が多いために一部言語の翻訳が間に合わなくてリリースを延期したりといったようなことがありました。そうした経験からアプリの起動時に非同期で最新の翻訳ファイルを取得して上書きする半リアルタイムな翻訳を更新する仕組みを作りました。

また、言語の影響をダイレクトに受ける検索もよく問題が起こります。検索クエリやレシピのテキストを分割するトークナイザー*13では、英語のようなスペース区切りの言語では問題はないのですが、タイ語のようにスペース区切りでない言語や、ドイツ語やハンガリー語のような合成語が多い言語など、トークナイズが難しく、これはテキストがマッチしたかどうかによって結果を返す検索システムにおいては重要なことで、それに依存してユーザーが求めていた情報を返すことができなかったり、逆にユーザーが求めていない情報が含まれてしまったりします。

英語(上)とハンガリー語(下)の比較

英語(上)とハンガリー語(下)の比較

[*13] 入力された文章(ここでは検索クエリ)を解析して最小単位の字句(トークン)に分割処理する機構

ユーザーが求めているコンテンツを返すという視点から見ると、検索結果に何を表示すべきかという判断は、しばしば文化的要因に左右されます。もし、ある宗教において食べてはいけない食材を使ったレシピが検索結果に含まれていたら不快に思うかもしれません。同じ言語圏でも物理的に距離が離れている地域では気候が違い、手に入る食材が違うので、テキストでマッチしたからと言って表示してもユーザーは嬉しくないかもしれません。このようにユーザーのコンテキストに応じて結果をフィルターしたりスコアリングの調整をしています。

すべての言語を話せるようになって文化を理解できるのは理想ですが実際には難しいので、問題に直面したらその問題が起こっている国に行ってディスカッションしながら現地で一緒に作業します。しかし、サポートする言語が増えるたびに特定の言語に限る対応策を増やしていくと、システムがメンテナンスできなくなるほど複雑になってしまいます。自然言語処理と機械学習を組み合わせたスケーラブルなアプローチを、今後ますます強化していく必要があります。

翻訳は改善を重ねるもの、地域ごと適任者に権限を移譲

クックパッドでは翻訳は社内で実施しています。翻訳はUIと同様に何度も改善を重ねるので、日常的に使っている社内の人間が担当しています。訳者は、レシピのチェック、ユーザーサポート、ASO(App Store Optimization)、検索エンジンの精度チェック、検索辞書の整備などを兼ねている場合もあります。

プロダクト内の文言の翻訳については上記の理由から社内で実施していますが、コンテンツ、たとえばレシピそのものの翻訳に関しては、ただ翻訳をしてもユーザーにとって有益とは限りません。たとえば日本語のレシピをそのまま翻訳して中東に持っていった場合に、家庭にある調理器具、手に入る材料、味覚の好みの違いから受け入れられないかもしれません。一方で毎日の料理とは別に日本食に興味があるという人のニーズは満たすことはできるので、その場合は、その地域で手に入る材料で代替できるものを提案するなど、工夫をする必要があると思っており、将来的にはそのようなサービスを提供する可能性はあります。

新しい機能を開発するときには、今ユーザーはこういう問題に困っていて、そのための解決策はこれで、これくらいの効果があることを見込んでいて、画面遷移はこれで……というものが書かれたデザインドキュメントを作成しています。翻訳を依頼するときはそれをセットにしてコンテキストを伝えるようにしています。

仕上がってきた訳文の評価は行なっていません。クックパッドでは各地域に翻訳やコミュニティーの運営などを権限移譲していて、定期的なレビューはありますが、何をどうやるかまでの指示はないので、どういう翻訳にするか、それがどのくらいの影響を与えるかという判断は、その地域内で行われています。

たとえば、スペイン語圏はスペインからアメリカ、南米と広がっていますが、スペイン語圏の担当者は「同じスペイン語圏でもスペインとアメリカとメキシコでは使われている単語が違うし、レシピも違う」と考えて、アプリストアの説明文とスクリーンショットを各地域ごとに作り直しました。このようにローカルの人に権限移譲していくことにより、その地域に合わせたサービスを作っています。

その他のマイナー言語の翻訳も同様で、リリースする言語・地域にはその言語や文化に詳しい担当者がいて、その人が翻訳も行うことでその地域に適した表現に対応しています。

グローバルな開発体制とコミュニケーション

クックパッドの場合はチームが地理的に分散しているので、実はコミュニケーションが一番大きな課題だと思っています。ビデオチャットによるミーティングもしますが、ミーティングではアジェンダがあり何を話すかはある程度事前に決まっています。例えば廊下ですれ違ったときやランチで話すようなちょっとした問題の共有や不満を拾うのが難しくなってしまいます。また、意思決定が行われる場所と実装者が遠ければ遠いほど、意図が伝わりにくくなってしまいます。エンジニアがなぜこの機能を作っているのかわからないままプロジェクトが進むと社内外注のようになってしまうなど、モチベーションを保つのが難しくなる問題も起こります。

多国籍なチーム

多国籍なチーム

そのような対策のためエンジニアは普段、SlackやGitHubをベースに会話をしていますが、話しやすい雰囲気を出すために絵文字を多用したり、業務と全然関係のない話やissueを立ててみたりしています。それでも、全くお互い顔も見たことがない中での開発は難しいので、入社したらまず出張して来てもらう、何か大きなプロジェクトをやるときは物理的に集まるなどして、直接コミュニケーションをする機会を作っています。

どのように海外展開をするのかは、プロダクトのミッションや扱うコンテンツの性質によって変わります。クックパッドでやっていることがそのまま他のプロダクトでも活かせるかはケースバイケースです。私はこのプロジェクトに入るまではグローバリゼーションは何か特別なもののように思っていました。しかし、実際にやっているのは、思い込みでサービスを作らないとか、細かく検証を行うなど、今までやってきたものと大きく違いません。ひとまず英語の翻訳だけ追加してみるというのも戦略の1つだと考えます。

この記事のもとになった書籍
ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応

西野 竜太郎 著
価格:2,400円+税
発売日:2017年10月16日発売
ISBN:978-4-295-00255-0
発行:インプレス

ソフトウェアグローバリゼーション入門 国際化I18Nと地域化L10Nによる多言語対応

Webアプリケーションやスマートフォンが広く使われる現在、世界中で使われるソフトウェアを開発・配布するための障壁は薄まりつつあります。しかし、多くの人たちに使ってもらうには、さまざまな言語や文化に対応した、グローバルなソフトウェアを開発しなければなりません。本書はソフトウェア開発におけるグローバリゼーション(Globalization, G11N)をテーマにしています。その概要と開発プロセスについて触れた後、二つの大きな分類である国際化(I18N)と地域化(L10N)について、それぞれ詳しく解説しています。

Amazon詳細ページへImpress詳細ページへ

合同会社グローバリゼーションデザイン研究所

IT分野の英語翻訳者。合同会社グローバリゼーションデザイン研究所代表社員。

米国留学を経て国内の大学を卒業後、2002年からフリーランスの翻訳者とソフトウェア開発者に。2016年に合同会社グローバリゼーションデザイン研究所を設立。著書『アプリケーションをつくる英語』(2012年、達人出版会/インプレス)で第4回ブクログ大賞(電子書籍部門)を受賞。産業技術大学院大学修了(情報システム学修士)。東京工業大学博士課程単位取得退学。長野県生まれ、愛知県育ちで、趣味はアニメーション鑑賞。

Twitterアカウント: @nishinos
個人ブログ: http://blog.nishinos.com/
企業サイト:http://globalization.co.jp/

“オープンソース技術の実践活用メディア” をスローガンに、インプレスグループが運営するエンジニアのための技術解説サイト。開発の現場で役立つノウハウ記事を毎日公開しています。

2004年の開設当初からOSS(オープンソースソフトウェア)に着目、近年は特にクラウドを取り巻く技術動向に注力し、ビジネスシーンでOSSを有効活用するための情報発信を続けています。クラウドネイティブ技術に特化したビジネスセミナー「CloudNative Days」や、Think ITと読者、著者の3者をつなぐコミュニティづくりのための勉強会「Think IT+α勉強会」、Web連載記事の書籍化など、Webサイトにとどまらない統合的なメディア展開に挑戦しています。

また、エンジニアの独立・起業、移住など多様化する「働き方」「学び方」「生き方」や「ITで社会課題を解決する」等をテーマに、世の中のさまざまな取り組みにも注目し、解説記事や取材記事も積極的に公開しています。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています