ガールフレンド（仮）でフロントエンドエンジニアをしている鈴木です。

ガールフレンド（仮）は
2012年よりサービスが開始されたブラウザで遊べるソーシャルゲームで、
今年の10月で10周年を迎えた長寿タイトルです。
私自身もガールフレンド（仮）に従事して7年目に突入しました。

今回はガールフレンド（仮）を長期運用してきた中での教訓を紹介したいと思います。

最新の仕様の全容が追えるようにしよう

ユーザー様に長く遊んでいただくために、
運用の過程でイベントなどの機能に対して仕様が付け足されていくわけですが、
運用を重ねれば重ねるほど、その付け足しも重なっていくので、
長期運用タイトルでは最終的に仕様がとても複雑になりがちだと思います。

私はガールフレンド（仮）にジョインする前は別のソシャゲプロジェクトを
３件渡り歩いていたのでソシャゲの知識はありましたが、
ジョインした時点でも既に仕様は複雑化していたので、
その複雑さに驚愕したのを覚えています。

また、仕様追加の過程で、追加分の仕様書が作成されていきますが、
これがまとまって管理されていなかったので、
資料からは正確な仕様を把握することは困難な状況でした。
（古い機能については資料自体が行方不明ということもありました...。）

このような状況ですと、実際のコードを読むことでしか仕様把握が出来ないので、
時間がかかるのはもちろん、仕様把握漏れによる不具合にも繋がる恐れがあります。

ですので、機能ごとに資料をまとめた場所に置いておくなど、
仕様を追いやすいようにする観点を持っておくと良いと思います。

定期的に機能の断捨離をしよう

定期的にゲームのアップデートを行い、機能を追加していくことになると思いますが、
長期運用しているとその機能の数も膨大になっていきます。

そして、共通モジュールに手を入れないといけないような改修案件だったり、
導入しているライブラリなどのサポート切れによる移行対応など、
影響範囲の広い対応が必要な機会も少なからず発生します。

そうなると、影響範囲の調査、実装、テストが必要になるわけですが、
機能の数に比例してこれらのコストも膨れ上がっていきます。

ですので、定期的に機能の断捨離をした方が良いと思っています。

とはいえ、一度追加してしまった機能を削除するというのは、
提供するサービス面から見ればマイナスでしかないので、
提案しても中々受理されないかもしれません。

なので、アップデートで機能が追加される際に
削除を提案出来れば受理されやすいように思います。

その際に削除対象の機能が不要だという評価材料を
添えることが出来ると良いと思うので、あらかじめその計測が出来る
仕組みを盛り込んでおけると良いと思います。

長期に運用をしていると、周囲では新しい技術が流行していくので
それをゲームにも取り入れたくなるのは珍しくないと思います。

ただ、安易にこれを取り入れてしまうと、多くの技術がゲーム内に
内在することになり、カオスな状態になってしまいます。

なので、既存の技術を新技術で置き換えるのが良いと思いますが、
常に運用が走っているソーシャルゲームでは中々難しいと思います。

現に、ガールフレンド（仮）では、過去に新技術で取り入れようとして
頓挫した痕跡があり、技術の異なる基盤が複数存在する状況となっています。

私がジョインした時点でプロジェクト内でこの基盤は廃れており、
新たに機能を追加する際は元の基盤が採用されていました。

廃れた原因は、学習コストが必要な他、
開発の効率面でメリットが享受出来ていなかったので、
当時のタイトなスケジュール下においては
チーム内に浸透しなかったのではないかと推測します。

結果、機能ごとに基盤が異なるので、無駄に学習コストがかかるので
完全に負の遺産と化してしまいました。
（採用した技術自体も世間的に廃れてしまいました...。）

こうならないためにも新技術の安易な導入は避け、
導入する場合はチーム内に浸透させる道筋を立てた上で導入するべきです。

ただ、長期的に新技術に触れられない期間が続くと技術成長の機会が無く、
精神衛生的に良くないので新技術に触れる機会を設けるのも大事です。

そこで、保守が不要な単発の施策においては
積極的に新技術を取り入れることをお勧めします。

今回は長期運用だからこそ出てくる問題点について書かせていただきました。

ガールフレンド（仮）はブラウザゲームですので、ネイティブアプリが主流の昨今では
多少事情が異なることはあると思いますが、長期に運用を続ける際の参考になれば幸いです。

最後までお読みいただき、ありがとうございました。