崖っぷちからの生還

気がつけば会社は売上がない状況なのにもかかわらず社員は100人を超えようとしていた。
計算すればわかることだが、100人の給与を払うことを考えるといかに安い給料だとしても100人×60万（保険、税金や間接費含む人件費）として、月に6,000万かかる計算である。
100人の組織を毎月維持することはメチャクチャ大変なのである。
安定的に月に6,000万の利益を出せるサービスを作ることは並大抵の話ではない。

会社は2009年に複数社から7,000万を調達していたわけだが、それが１ヶ月ちょっとで溶けてしまうレベルだ。（だから、普通は売上が立つまで組織を拡大しない）

が、國光さんはそういう意味では凡人ではなかったといえる。

そして、その頃に丁度ホットだったのが、Mobage、GREE問題である。
どの会社もどちらのプラットフォームにゲームをリリースするかを考えていた時代だ。
（個人的にはプレステVSサターンのようだなと薄ぼんやり考えていた）

会社の選択としては「GREEへゲームを出す」であった。
その結果として会社は2010年10月に増資を受けている。
GREEへのゲームの提供を決め、当時のGREEの状況からも「これからは乙女ゲーだ」というような話もでていたが、結果としてgumiは全く違った路線を歩むことになる。
この切り返しの早さは國光さんの明確な強さであった。

2010年9月にドラゴンコレクションがリリースされ、大きな結果が存在していたため「これはいける」という感触をサードパーティ各社が持っていた時期でもある。
しかしながら会社には明確に大きな課題があった。
「売れているゲームが無い」問題である。
当時の財務担当者がよく徹夜で業務をしていたが、資金繰りが大変だったことは察せられた。

2010年12月、私の元同僚が入社したときに管理担当者に言われたことが「今では國光の求心力も失われ……近々給与が払えなくなるかもしれない」といったことだった。
（財務状況を把握していた訳ではないので、真偽の程は定かではないが非常にインパクトがあった台詞なので記憶している）
とはいえ求心力が完全に失われていたか、というと別にそうでもなかったはずだ。

「いかに売れるソーシャルアプリをつくるか」という勉強会なども行われ、

・幅広いターゲットにシンプルなゲームを設計し、ソーシャル要素を持たせる
・友達紹介の最大化
・チュートリアル突破率の改善
・ログインしたくなる仕掛け
・継続的に課金したくなる仕掛け

といったものが盛んに議論されていた。

そうした活動が実を結んだのか、単に天運なのかはわからないが、
2011年1月「さんごくっ！」、
2011年2月「任侠道」、
2011年3月「デュエルサマナー」がリリースされて明確に風向きが変わる。
会社を維持できるだけの結果が出始めたからだ。
「國光さんは持ってる」とよく言われるが、それを感じた瞬間でもあった。

噴出する技術的課題

この辺りで技術的な課題が一気にやってきた、というか明らかになった。
要するに「売れてないゲーム」というのは「売れていない」という問題の前に技術的な問題は隠されてしまっていたからだ。

主に、
「ゲームの高速水平展開問題」
「負荷に対する問題」
「スマホ対応問題」
である。

ゲームの高速水平展開

このときの喫緊の課題は「ゲームの高速水平展開」で、
要するにどうやってこの売上を拡大させるか、という点が重要だったわけだ。
結果として、
「任侠道」→「海賊道」「騎士道」
「デュエルサマナー」→「デュエルインワンダーランド」「デュエル英雄譚」
「さんごくっ！」→「せんごくっ！」
のように展開された。
技術的にやっていたことはなんてことはない「枠組みの流用」である。

１日も早くリリースすることが命題であったし、自分たちの成功体験をなぞることには大きな意味があった。
元のゲームフローはそのままに、ガワ替えするのはターゲットを広げる方法として間違ってはいなかったのだった。
（変に差別化を狙ったゲームは逆に全部こけた）

そして、水平展開を最初に行ったが故に技術的な課題も水平的に展開された。（明確な技術的失敗）

とはいえ、問題を解決してから展開するという余裕はとてもじゃないがなかった。

負荷に対する対策

売上が上がるまでは、まともな負荷というものにさらされたことがなかったために、負荷に対する対策というものを完全に失念していた。
この頃はまだきちんとデータベースの水平分割を行っておらず、どちらかというとデータベースよりもTokyoTyrantが負荷でよく死んでいた。
TokyoTyrantの名誉のために言い添えておくとTokyoTyrantが悪かった訳ではない。
単に「キャッシュ」という名目でネットワーク越しにあるKVSへ何度もアクセスにいくプログラムが悪かったのである。

当時社内で一部で使われていたランキングモジュールなどは、Keyをランク、Valueをスコアに割り当てており、順位が入れ替わる度にKeyとValueに対して範囲ソートするという考えられる限り最悪な使い方をされていた。
（1万人のランキングとすると、誰かの順位が入れ替わるたびに最悪で1万個のKeyを舐めていく）
滅茶苦茶重いんです、みたいな話を受けて見に行ってみれば「こんなん動くわけないやん」というのが日常茶飯事でもあった。
（まともな共通化ができていなかった）

また、GREEプラットフォームAPIに対するアクセスもすべてが同期的であり、処理が詰まるとAPIがタイムアウトで全部失敗するというなるべくしてなったバグもあった。
結果として、非同期処理としてジョブキューを導入したり、キャッシュはローカルメモリに対して行うなどの対策が個別に取られた。

スマホ対応問題

同時に課題となったのが「スマホへの対応」が必要になってきたことだった。
ガラケーは貧弱なFlashしか動作しない上に、まともなHTMLを表示することすらできず、低解像度であった故に高速に開発が出来たが、スマホ化に関してはリッチ化が求められた。
スマホ対応に関しては素材解像度の問題もあり、単純な工数の増大に収まらずかなりの対応を迫られる割にシェアはそこまででもないので見返りが少ないという状況であった。
しかし、スマホの未来は迫っており対応は必須といえた。

とはいえ、これらの技術的な解法は大きな問題ではない。
どれも解決可能な問題だからだ。
どちらかというとすべては人的課題へ収束していくのであった。