2014年12月で10周年を迎えたグリー。その道は平坦なものではなく現在、最も利益を上げた2012年からは売り上げを落とし、希望退職者を募る事態も経験した。プラットフォームをオープンにするなどゲーム事業に注力する一方、介護施設の口コミメディア、リフォームサービスなどのライフスタイル領域や、広告、投資などに幅を広げ、総合インターネット企業として、新たな売り上げの柱を模索している。
いわゆるガラケー向けからスマートフォン向けゲームへとユーザーニーズが移る中、ゲーム事業の開発体制を刷新し、新規事業の開発体制を統括、グリーを「Refactoring」しようとしているという最高技術責任者（CTO）、藤本真樹氏に話を聞いた。
--現在、グリーが最も注力している分野は。
グリー 最高技術責任者（CTO） 藤本真樹氏
事業の側面でいえば、スマートフォン向けネイティブアプリ開発が基本的なメインターゲットになります。その中でもエンターテインメントとゲームにフォーカスしていて、これが今後の中心です。一方、ノンゲームではいくつかチャレンジをしています。例えば BtoBを対象とした場合は必ずしもネイティブアプリである必要はありませんし、逆にスマートフォンならではの機能を生かすものはネイティブアプリなど、適性に応じて柔軟に対応することです。
--CTOとして注力していることは。
現時点ではプロダクトの開発をスタートする際の環境を個別に最適化することに注力しています。最適化には会社がすべてを統制する方法と、個々のプロダクト担当に任せる方法があります。それぞれにメリット、デメリットがありますし、作成するものや会社の状況や規模によっても変わります。グリーの場合は開発する国も場所もばらばらですし、ネイティブゲームもブラウザゲームも、いわゆるウェブアプリケーションも作っています。そうすると、完全に統制することは現実的ではありません。
なぜプロダクトのスタート時の環境に注力するか、理由はスピードです。まったく統制がないと、極端な話、隣の部署でも同じプロダクトを作ってしまう可能性もあります。しかし、統制することでプロダクト開発をスタートする足を引っぱり、最初の一歩を踏み出すのが遅くなってしまう方がデメリットが大きいと考えます。もちろん、類似したプロダクトをいくつも量産するような環境であれば、フレームワーク化したり統制した方が効率的です。しかし、スマートフォンのネイティブアプリは、次に何がはやるか分かりません。それなら最初の開発スピードを速くして、勝てる確率を高くした方がいいと判断しました。
現在は、グループ全体で500人のエンジニア、2000人近くの社員がいて、100人単位のスタジオがばらばらにある状態です。その状態で、2000人規模の会社でしかできないことをエンジニアリングの面で達成しようとしています。この体制は最初にルールを決めてしまうよりも、後から積み上げて体制を決める方が健全だと思うわけです。
--プロダクトのスタート時の環境改善のための施策とは。
ここ最近の大きな変化は、各スタジオで取り組んでいる分野が共通化してきていることです。われわれは現在、米国と韓国で事業を展開していますが、この2つはゲームスタジオという位置づけです。米国や韓国、東京のスタジオでは現在、基本的にはWindowsとOS X上で動作する統合型のゲーム開発環境であるUnityをメインにスマートフォンのネイティブアプリのゲームを開発しています。
そうすると、情報共有の効果が高くなります。情報共有にもさまざまなやり方がありますが、まずは「人が物理的に集まる場を作る」ということで先月、「GREE Tech Summit」という社内イベントを企画しました。「てくさみ」という通称がついて盛り上がったのですが、米国からインフラやサーバ、クライアントなど、それぞれセクションに特化した6人のエンジニアが来日しました。ノウハウなどを交流することで、まず「●●を担当している▽▽という人がいる」という認識ができた点が成果だと思います。今後、関連することを相談する際にも1度会っていればハードルが低くなります。
プロダクトの開発者は、基本的に横との連携に積極的ではありません。時間があったら自分の仕事に集中したいという考えを持った人が多い印象です。一方、こういったイベントで得られた人脈を生かせば、自分の仕事が楽になるかもしれません。参加者から「もっと拠点間、スタジオ間で共有をした方がいい」という意見が出てきたのはうれしかったですね。もちろん、1番大きなスタジオでは成功例を共有して方向性を話し合ったりしていますが、ウェブ会議ではなく実際に会うことや、どういう人が働いているかの把握は情報共有の基礎なので、重視しています。
実際に人が会う機会は、会社が大きくなるにつれて減っていきます。それでスピードが落ちてしまうよりは、とにかく足を引っぱらずにどう開発作業を積み上げていくかを模索していきます。その次には自動的な、人の手を煩わせない情報の可視化を考えています。例えば、ホスティングサービス「GitHub」のRead Me マークダウンの記載ルールを決めてしまおう、というアイデアがあります。そうすることで、新しいリポジトリが作られたときや依存関係を自動で抽出して把握する、といったことも可能になります。見やすくすることで閲覧のハードルが下がります。そのような自動での情報の透明化です。
そして最後は、コストはかかりますがテレカンなどによるpush型の情報交換です。そこができて、初めてライブラリを共有化や、あるいは将来的には拠点間での共同開発が有為になってくるのだと思います。そこまでできれば、50人規模の会社ではできないようなことができるようになると思います。これは、社内のエンジニアの文化や、オープンソースのサブセットを作る世界と似ています。
グローバルでの連携はこれからです。間違ってはいけないことは、連携ありきで考えるとろくなことにならないということです。会社としてそれを全面に押し出していくと、変な方向に進んでしまうこともあります。それよりも、プロダクトを作る人が低いストレスで環境を構築することが大事であり、その方法を考えるべきです。Face to Faceもその1つ。そしてベネフィットがあった段階で「そういえば連携が取れてたよね」と、いつの間にかみんなが思っているという状態がいいですね。
