２ヶ月でチームの運用コストを半分以下にした方法

前職ではソーシャルゲームの運用移管をやっていたドラレプです！

ソーシャルゲームの運用移管とは、他社さんの運用していたソーシャルゲームを買い取って安く運用することで利益を求めるビジネスです。

「売却されたゲームで利益を出す」ということは、いかにより安く運用できるかが重要になります。

そこで私は過去、エンジニア10人で運用していたソーシャルゲームを、2ヶ月で日本人2人、ベトナム人3人（うち通訳１名）で運用できる状態にまで持っていきました。

そして2000人超の企業で下半期MVPも取ることができました！

その後も同じ手順で同様の成果を出すことができたため、再現性の取れる確実性の高い手段だと思っています。

そこで今回は、そのときに行った方法をシェアして行きたいと思います。

ゲームの定常作業についての話ですが、ゲーム以外の定常作業についても応用できるのではないでしょうか。

定常作業のコストに悩んでいる方のご参考になれば幸いです！

作業手順書の作成

作業内容の洗い出し

まず作業内容を洗い出していきます。

場合によって違うし言語化できないよーなんてこともよく言われたんですが、場合分けの可視化含めマストな作業です。

なぜならその場合分け自体もコストなため、場合分け自体そもそもない方が良いのです。

可視化することで場合分けによって手順が複雑になっていることを認識できます。

そして「この場合分けはどうやったらなくせるんだっけ？」という発想に至りやすくなります。

作業手順書の作成

洗い出した作業内容を「初めて来た人がすぐに再現できる」レベルにまで落とし込み手順書を作っていきます。

コマンドだったら打ち込む全てのコマンドを列挙して、コードのこの位置は仕様書のここの情報をいれてとかいった形ですね。

このとき、それこそsshレベルからコマンド打ち込んでいった方が良いです。

理由は次の通りです。

• どんな人でも絶対に作業ができるレベルに落とし込む。
• 「そもそもssh自体いらないんじゃない？」なことがある
• 「ssh含めて自動化できちゃうよねー」なことがある
• 「ssh configこう書けば楽に入れるよー」みたいなナレッジ含めてチーム全体で最適化しやすい。

属人化がなくなるとアウトソースしやすくなる

こうして作業を洗い出すことで属人化がなくなり、アウトソースしやすくなります。

たとえば設定の入れ込みだけであればエンジニアではなくデータオペレーターにお願いすることもできますし、アルバイトや海外の人件費の安いところにお願いすることもできるでしょう。

つまり純粋に作業が減って少ない人数で運用できるようになるだけでなく、安い人件費で運用することもできるようになるわけです。

仮に人件費が1/3になれば、人数を1/3にしたのと同じ効果が得られます。

人数も減らせて、人件費も減らせて、二重でお得なわけです。

仕様書を構造化する

仕様書の問題

仕様書って情報が点在していたり、無駄な情報量が多かったりします。

したがって、それを作業に結びつけるのは慣れるまで大変です。

たとえば「イベント開催日」という設定をいれたかったとして、それが初見だと資料のどこにあるのかわかりません。

それを探すだけでも時間がかかってしまいます。

そのため作業が属人化していったり、設定を入れるだけなのに時間がかかってしまったりするわけです。

仕様書を用意してあげる

そのためエンジニア自体が仕様書を構造化して渡しちゃうことをお勧めします。

具体的には作業に必要な情報を洗い出します。

たとえばソーシャルゲームのイベントだったら、開催日、イベントのタイプ、イベント名、ボスの名前などですね。

そしてGoogle Spreadsheetなどに項目を書き込んでいきます。

タブとか情報の分け方は、企画者がやりやすい形でやるか、実装者がやりやすい形でいくかチームによってボトルネックになっている方に合わせましょう。

実装者がやりやすい形は、設定ファイルやマスタデータごとにタブ分けちゃったり、イベントタイプが数値で定義されてる場合その数字でいれてもらうとかですね。

実際に運用で使うときは各項目に対してWIP、FIX、CHANGEDなどのステータスも用意しておくと作業しやすいです。

企画者も嬉しい

こうすることで、企画者自体も必要ない情報を入れることがなくなります。

つまり企画者が仕様書を作る時間自体も削減することができます。

最初は戸惑うかもしれませんが、「これ今まで頑張って書いてたのに使ってなかったの！？」なんてこともあるわけですね。

自動化することができる

こうして必要な情報を構造的に用意できることで、自動化がしやすくなります。

たとえばSQL文を自動で作り出す、なんてのはGoogle Spreadsheetで簡単にできますね。

イベント終了日は必ず開始日の１週間後なんてときもSpreadsheetのレベルで自動化できちゃいます。

自動化することで作業のコストも減ればミスも減っていいことづくしです。

最終的にはGoogle SpreadsheetからAPI経由で読み取って自動的に設定ファイルを作成したり、DBに入れ込むこともできるでしょう。

作業内容を自動化する

洗い出した結果をもとに作業内容を自動化していきます。

純粋に一連のコマンドをスクリプトにすることすぐできるでしょう。

洗い出すことで、ここのViewの値ってDBから取ってこれるよねーみたいのも見えて来ますし、ここ同じデータいれてるから定数切っちゃえば１箇所入れるだけで入れるようになるよねーみたいなのもあります。

そもそも今の実装だと作業量どうしても減らしきれないから新しいの作り直そうかみたいな話もアリです。

1秒でも削れたら削る

このとき1秒でも削れたら削るぐらいの気持ちで自動化していきます。

なぜなら作業の数だけミスを生むリスクがあるため、実際にかかる時間以上のコストがかかっているからです。

たとえばその1秒の作業が漏れていた場合、そのバグで確認作業が止まってしまったり、調査に時間がかかってしまうかもしれません。

コードレビューでも差分がなければないほど精度が上がります。

チーム全体を最適化していく

このときエンジニアチーム以外も効率化していきます。

もちろんそれが理想だよねーという話もありつつ、現実的に他の人の作業を削ることで結果的に自分に生まれてくる時間もあるからです。

たとえばCSチームが毎日100件くるお問い合わせがあったとします。

仮にそのお問い合わせ自体がこないように仕組み自体を変えてしまえば、その時間を別のお問い合わせに使うことができます。

そのため今までCSチームが処理しきれずエンジニアチームに来ていた内容が、CSチーム内だけで解決できるようになるかもしれません。

またチーム間のデータフローを俯瞰的に眺めたとき、「そもそもここの受け渡しいる？」みたいなのもあるかもしれません。

たとえばアートが企画者に画像を渡して、その画像をエンジニアに渡すなんてケースがあります。

その場合、「そもそもアートがエンジニアに渡せばよくない？」ってなりますよね。

そしてアートがGitでプルリク投げる運用にすれば「そもそもエンジニアに渡す必要もなくない？」ってなります。

新規開発の工数削減も視野に入れる

新規開発にかかるコストも削減していきます。

具体的には抽象度をあげて物事を捉えることで、汎用的に作ることをオススメします。

たとえばゲームのイベントで使う討伐ポイントがあったとします。

それを討伐ポイントとして実装してしまうと、その後討伐ポイントの仕様が変わったときや、新しく探検ポイントってのができた時に新しく実装しないといけないかもしれません。

しかし「ポイント」という概念として実装すれば、あらゆるポイントを1つの実装で使いまわすことできます。

さらに「イベントごとのユーザ変数」として実装すれば、ボス討伐数であったり、討伐ゲージだったりありとあらゆる要件に対して使いまわすことができます。

これはYAGNI的ではないと感じる人もいるかもしれません。

しかしゲームは「ほぼ一緒だけとちょっと違う実装を繰り返すことが多い」ので、私はどんどん抽象的にしたほうがリターンが大きいと思っています。

ドラクエをそのまま実装するんじゃなくて、RPGツクールやUnityを作るイメージです。

改善するにあたっての考え方

ちょっとずつ変えていく

人は慣れてることを繰り返し、慣れないことは基本的に嫌いです。

そのため一気に変えると、ついてこれない人もでてきます。

なので、ちょっとずつ変えていくのが好ましいです。

いきなり変えると障害のリスクもありますしね。

関連記事

恋愛やマーケティングに？人が好きになるものの心理法則

高い目標を持つ

今の改善という視点だと、たどり着けない手段があります。

革新的な手段には、高い目標を持たないとたどり着くことはできません。

今の仕組みの改善という目線で見ている限り、どうしても限界があります。

伸び代の限界値を見て、リスクをとって最大値を取りに行くことも必要です。

そのためにも抽象度をあげて俯瞰的に、中長期的な視点で見ることが大事になります。

改善を楽しむ

前のチームではみんなで改善できる点を洗い出して、暇な時間は改善を何か進めてくってのをやってました。

すると目に見えて日々の仕事が楽になっていくので改善が楽しくなってきます。

それまで深夜に帰っていたのが定時帰りできるようになったりするわけです。

そうなってしまうと、ほっといてもみんな運用改善するようになってきます。

またあれめっちゃ便利になったよーありがとーというコミュニケーションも生まれてきます。

この目の前の人に感謝される行為自体がモチベーションの源となりますし、お互いが感謝し合う文化が生まれればモチベーションをあげるベストな環境になります。

関連記事

あなたが部下に任せられない理由とは？モチベーションの関係とあわせて解説

やれよって命令するんじゃなくて、自然と改善が進んでいく組織を作れれば最高なわけです。

おわりに

というわけで前職で行った運用改善の方法についてまとめました！

サーバコスト削減的な話もありますが、それは全く別物になるので今回は省いてます。

一方で暇になるとモチベーション下がるよねーみたいな話もあるので、改善しすぎて暇な人が出たときどうするのーなんてのも考えておくと良いかもしれません。