リリースタイトルに携わるエンジニアとしてサービスの運用を考える話

2018年12月14日公開 2019年4月16日更新

これはドリコム Advent Calendar 2018 の 14日目です。
13日目は青木慎さんによる HTML5+JavaScriptのゲーム開発に元Unityエンジニアが挑戦してみましたです。

はじめに

2018年にドリコムに新卒入社した渡邉です。クライアントエンジニアとしてソーシャルゲームの運用プロジェクトに配属され、新規機能の開発から運用ツールの導入、デザイナーさんのトラブル対応まで色々なお仕事をしています。

本記事は入社から現在までで、運用プロジェクトにおけるエンジニアとして働いて感じたこととその中で学んだことからサービスの運用を考えてみる記事です。エンジニアとしてどのように運用に関わっていくのか、より良いサービスをつくっていけるのかについての初歩的な内容を述べており、ガチガチの技術的な話ではなくエンジニアと運用プロジェクトの関わり方を考える記事になりますので、エンジニア以外の方も含め幅広く読んでいただければと思います。

私は今までゲーム開発自体は経験があったのですが、ほぼ部活動や個人の趣味で制作してきたものであり「出したら終わり」が基本だったため、実際に「サービスを運用する」といったことを考える機会はありませんでした。そこから会社に入り実際にソーシャルゲームの運用プロジェクトのメンバーとして過ごしていく中での経験や、勉強したことに基づいた記事となっています。勉強したことの中でも、特にGoogleが提唱するSite Reliability Engineering(SRE)を参考にしています。こちらはインフラやバックエンドサイドのエンジニアに関する内容となっていますが、本稿で述べるアプリ開発におけるクライアントエンジニア目線の話にも繋がっています。

運用業務は減らすべし

まずはじめに、運用プロジェクトには当然「運用業務」があります。これにはリソースの配信や画像を作成して登録する作業、成果物のチェックといった様々なものが存在し、毎日のように行われています。特に人間による手作業で行われ長期的に価値を産み出さないものは、SREではトイルと呼ばれています。例えば、画像の形式がレギュレーションに沿っているかなど、人の手で行うよりも機械で行った方が得意な「リリースごとに繰り返し行われる作業」のことを、アプリ開発ではトイルと定めて良いと考えております。プロジェクト内においてトイルが多いということは、つまり新規開発などのユーザーに直接届けるためのものに費やす時間が減ってしまうということになります。その他にも新しいことに挑戦できなくなることによるキャリアアップの停滞といった問題も存在します。

自動化できるところは自動化する

エンジニアはこのトイルを減らすために動くことができます。私は実際の現場で「デザイナーがデザインを制作しそれを登録する作業」が問題であるとして取り組むことがありました。デザイナーにはやはり「新しいデザインを産み出すこと」に時間をかけていただきたいと思いますし、そのような環境を用意したいと思います。そこでエンジニアである私が行ったのが「自動化ツールの導入」です。ボタン一つクリックするだけで「必要なファイルを自動で書き出す」「テクスチャやシェーダー等のパラメータを自動で設定」といった、誰にでもできるような単調な作業をツール側で行うことができ、それによりデザイナーの貴重な時間を守ることができます。

自動化でミスを減らす

自動化により減らすことができるのは時間だけではありません。人間の手作業ではどうしても起こってしまうミスも減らすことができます。これは人間が確認を行う場合と比較して、機械による確認は精度が常に一定であり、確認者によって確認にバラつきがあったり見落としが発生してしまうことがないためです。ミスがあった場合、例えば「画像の設定が間違っているため表示できない！」といったことが起きると最初に気づくのは主にプランナーです。そしてプランナーからデザイナーやエンジニアの方に画像に問題があるとして調査依頼が来ます。こうなってしまうと、作業の手戻りが発生し、プランナー・デザイナー・エンジニアの三者の時間も損なってしまうことになります。また、ここで気づくことができればまだ良いのですが、万が一気づけずにユーザーが目にする本番の環境に出てしまっては大変です。

このように、エンジニア主体で身近な問題を自動化することでプロジェクト全体の効率を上げ、さらに品質を上げていくことができるのはエンジニアリングの魅力だと感じています。

開発チームと運用チーム

サービスを提供するプロジェクト内の作業にはざっくり「開発」と「運用」があります。開発とは「サービスをリリースすること」、運用とは「リリースされたサービスを提供し続けること」になります。ゲーム開発で言うなら、開発は「ユーザーにとって便利な新機能の追加」や「新しいイベントモードの開催」、運用は「ガチャの更新」や「不具合の修正」などがあげられます。

開発と運用が完全に分かれているのはよくない

サービスの運用において、開発を行うチームと運用を行うチームがしばしば分かれていることがあります。開発と運用がはっきり分かれていると、コミュニケーションや目標設定において大きな障害となります。これは両者間では使用される技術やモチベーションが異なっていることによります。開発チームが目指すものは「新しい機能をリリースし、ユーザーにそれを届けること」です。そして運用チームは「サービスに問題が起きないようにしたい」と思っています。しかしながら、サービス障害のほとんどは新しい機能や新しい種類のユーザートラフィックといった要因によって引き起こされるとされています。つまり新しい機能をリリースするほどサービスに問題が発生する可能性が高くなるということであり、両チームが目指すものは互いに反することになってしまっています。どちらもプロジェクトをより良いものにしたいという思いは変わらないのですが、これではうまくいきません。

開発と運用のバランス

このようにどのぐらい新規開発にリソースを費やし、どのぐらい不具合対策にリソースを費やすかを考えていくことはソーシャルゲームの運用においても考えられる話題です。ここではこの問題に可用性を考えるというアプローチをとりたいと思います。SREにおいて可用性は強く意識されています。

可用性を考える

可用性とは「どれぐらいサービスが意図した通りに利用できるかの割合」を表します。

可用性は100%を目指すものではない

なんとなく考えていると、可用性は高ければ高いほど良いように思えます。しかしながら可用性を100%にすることは間違っていると言われています。なぜなら100%と99.999%の可用性の違いはユーザーから見ればわからないことがほとんどであるためです。そしてユーザーが使用する別のサービス（自宅のWiFiや使用する端末など）も合わせたサービス利用全体の可用性はさらに下がってしまい、自分たちのサービスの可用性を高めたところで他のサービスの可用性に埋もれてしまうことがあります。さらに可用性を99.99%から99.999%にするような一桁上げるためのコストは、9の数が増えるほどに大きくなり、ユーザー体感の向上のためにはどんどんコストに見合わないものになっていきます。不具合を徹底的に無くすために何回もチェックをしたり設備を整えたりするためには、エンジニアの作業時間や設備投資にかかるお金を過剰に消費してしまうことになります。不具合対策はあくまでプログラムの品質であり、サービスの品質はこの他にも新機能のリリースなども含まれます。つまり開発と運用全体を合わせてサービスの品質であるので、プログラムの品質ばかりに目が行ってしまい、遊んでくれるユーザーの満足度を高めることができなければ本末転倒です。

可用性を損なってもいい”予算”

SREではエラーバジェットという考え方があります。バジェット(budget)とは予算です。これは「ある期間内でこれだけは不具合が出てしまっても許容する」というまさしく不具合を出せる予算のような使い方をします。つまりあまり不具合が起こらず「予算が残っている」状態の場合は、予算の分開発リソースを多めにとり開発速度を上げていったりします。また不具合が多く起きてしまい「予算を使ってしまった」状態になったときは開発速度を落として対応を行い、最悪の場合はリリースを止めるといった対応がとられます。エラーバジェットは予め定められた可用性の目標を100%から引いたものになります。つまり99.999%を可用性の目標にしているプロジェクトでは、0.001%はエラーが発生しても良いという考え方になります。

誰が見てもわかることが大事

以上のように、明確な指標を定め誰が見ても「これぐらい良い」「これぐらい悪い」といった状況が把握できるようになることが大切なことであると思います。エラーバジェットの考え方は「そろそろヤバい」という状況をはっきり見えるようにし、それに呼応してメンバーが動くための考え方です。主観的な考え方では対立を発生させ行動の指標とすることはできません。重要なのは「こういう時はこうする」といった行動に移すことができるためには客観的に見られる根拠を用意する必要があり、それをエンジニアリングで解決していくのがエンジニアだと思っています。

おわりに

最後になりますが、私が新卒エンジニアとして運用プロジェクトで過ごし、感じたこと思ったことを述べていきます。

ユーザーに価値を与えることを第一に考える

大事なのは「ユーザーにどのような価値を届けるか」です。開発でも運用でもこの点は意識していく必要がありますが、運用プロジェクトではすでに多くのユーザーに遊んでもらっている状態であるため、より「どういったイベントを求めているのだろうか」「どこに不満を感じているのだろうか」といった点をリアルタイムに考えながら進めていかなくてはなりません。例えば新しいイベントを考える場合でも、それによる利点が「ユーザーが今までにない新しい体験を味わえて楽しめる」ではただの主観になってしまいます。なぜ楽しめるのかを考え、客観的に見ても納得できる根拠が必要です。またそれらを考える場合は「どういったユーザーがその価値を受け取るのか」というターゲットも考える必要があります。極端な例では「強い武器の需要を出すため、超カタい敵が出るイベント」を考えたとしても、実は全プレイヤーの上位1%しか満足できず、残りのプレイヤーは基礎ステータスすら足りないためほとんど楽しめないなんてことがあってはいけません。「ユーザーの80%はこの辺りはこれぐらいの能力を持っているから、その人たちに満足してもらうイベントを用意する。さらにもっと上位のプレイヤーには難しい裏ルートも攻略してもらう」といったように、データを取りつつ届ける先や届けたい価値を意識しなくてはなりません。そしてエンジニアとしてはこのデータや価値が何であるのかをしっかりと考え、時には計測してエンジニア以外のチームメンバーと議論していかなくてはなりません。

エンジニアとして半年ちょっと過ごしてみて

私が今まで過ごしてきて大事であると感じたのは「目的を意識すること」です。ソーシャルゲームの運用では「いかにユーザーを楽しませるか」が大切であり、その目的があってこその開発効率向上や不具合対策だと思います。エンジニアといいますとコードを書いて実際に動くものをつくり出していく仕事だと思っていましたが、本稿で述べたようにプロジェクト全体の環境を良くしたり、エンジニアだからこそ調べられるプロジェクトの状態を計測しチームを引っ張っていけたりと、できることの幅が広い夢のある職業です。私も今はまだ理論としてSREを勉強している途中であり、所属プロジェクトに還元するところまでたどり着けてはいませんが、いつかはエンジニアリングでチームを先導できる立場になれるよう頑張りたいです。