ビジネス

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

前職ではソーシャルゲームの運用移管をやっていた@dorarepです!

 

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

そのまま利益出るんだったら売らないから、基本的にはより安く運用できないと意味がないわけですね。

 

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

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

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

 

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

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

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

作業手順書の作成

作業内容の洗い出し

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

 

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

場合分けも含めて言語化していきます。

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

可視化することで場合分けによって手順が複雑になっていることを認識でき、場合分け自体無くせないの?っていう発想に至りやすくなります。

作業手順書の作成

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

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

 

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

 

これはどんな人でも絶対に作業ができるレベルに落とし込むという意味で1点。

あとそもそもssh自体いらないんじゃない?みたいな話もありますし、ssh含めて自動化できちゃうよねーみたいな話もあります。

またssh configこう書けば楽に入れるよーみたいなノウハウ含めて共有しチーム全体で最適化することができます。

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

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

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

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

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

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

 

作業手順書を初めてきた人がすぐに再現できるレベルで作ると?

  • 最適化しやすくなる。
  • 属人化がなくなり、アウトソースしやすくなる。

仕様書を構造化する

仕様書の問題

仕様書って情報が点在していたり、無駄な情報量が多かったりしていて、それを作業に結びつけるのが大変だったりします。

たとえば「イベント開催日」という設定をいれたかったとして、それが資料のどこにあるのか探すだけでも時間がかかってしまいます。

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

仕様書を用意してあげる

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

具体的には作業に必要な情報を洗い出します。たとえばソーシャルゲームのイベントだったら、開催日、イベントのタイプ、イベント名、ボスの名前などですね。

 

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

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

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

 

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

企画者も嬉しい

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

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

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

自動化することができる

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

 

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

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

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

 

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

 

仕様書をエンジニアが構造化し、それに記入してもらう運用にすると?

  • 仕様書の無駄な情報が削ぎ落とされ、作業効率が上がる。
  • 構造化されることで、自動化しやすくなる。

 

作業内容を自動化する

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

 

純粋に一連のコマンドはスクリプトにしちゃうなんてのはすぐできるでしょう。

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

 

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

1秒でも削れたら削る

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

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

 

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

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

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

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

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

 

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

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

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

 

またデータの受け渡し等を含めて俯瞰的に作業全体を眺めたとき、そもそもここの受け渡しいる?みたいなのもあるかもしれません。

たとえばアートが企画者に画像を渡してその画像をエンジニアに渡していた場合、そもそもアートがエンジニアに渡せばよくない?みたいな話もあります。

アートがGitでプルリク投げる運用にすればそもそもエンジニアもいらないよねーみたいなこともあります。

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

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

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

 

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

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

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

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

 

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

 

効率的に自動化するためには

  • 実際の作業にかかるコストだけでなく、作業漏れのリスクなども含めた潜在的なコストも意識する。
  • エンジニアだけでなくチーム全体を最適化することで、結果的にエンジニアの作業コストも減る。
  • 抽象度高く汎用的な実装をすることで、新規実装でも使いまわせる道具を増やす。

 

考え方

ちょっとずつ変えていく

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

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

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

高い目標を持つ

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

それこそ仕組みを1から作り直す必要も出てくるのではないでしょうか。

 

たとえばこのチームのエンジニアを0にするにはどうすれば良いかという視点で考えたとき、破壊的な変更が必要になるでしょう。

各自のPC内のローカルDBに対して作業を行なっている場合、誰かの作成したマスターデータをエンジニアがそれぞれ入れ込む必要が出てきます。

しかし開発用のDBサーバを立てて全開発メンバーがそのDBを参照しながら開発を進めていくことで、誰かがマスターデータを入れ込めば全メンバーがそのデータを共有しながら開発を進めることができます。

純粋にマスターデータの受け渡しのコミュニケーションコストや、入れ込みコストがなくなります。

そして最終的に設定のみで定常作業が終わるようにすればエンジニアなしで作業を完遂させる未来も見据えることができます。

 

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

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

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

改善を楽しむ

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

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

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

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

 

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

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

 

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

おわりに

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

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

 

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