こんにちは、インフラストラクチャ部の大山（@ohyama00）です。
業務ではプロダクト（主にウェブゲーム）のインフラ運用・整備や機能開発など、人が足りていないところのお手伝いを中心に行っています。

このエントリはGREE Advent Calendar 2015 4日目の記事です。昨日は藤田さんのSchema.org を利用してユーザーに優しい検索結果を提供しようでした。

それでは本日もよろしくお願いします。

はじめに

最近GREEでは、内製ゲームを自社以外のプラットフォームに提供するという取り組みを始めています。

これらのゲームは基本的にAWS上に構築されており、GREEのプラットフォームが提供する機能や、内製ゲームが共通で使う環境から切り離されて動作しています。オンプレとして安定稼働していたゲームをパブリッククラウドに移植するにあたっては様々な作業が発生しました。

発生した作業（の一例）

• ミドルウェアのバージョンアップ
• GREEの共通化されたシステムからの切り離し
• ゲームシステムの見直し（機能追加/削減）
• サーバー構成やデプロイ方法の見直し

上記は案件の開始前からある程度見込まれていた作業でしたが、それらの作業を進める上で各部署間のコミュニケーションやワークフローに変化が見られました。

本記事では、オンプレからパブリッククラウドへの運用形態の変化に伴って起きた技術以外の変化について紹介します。正直なところ現時点では、その変化を上手く乗り切ったというよりは、振り返ってみて少しずつフローを変えて、ようやく上手く回り始めた段階になります。

開発チームとインフラのやり取り

内製ゲームの場合

まず、GREEにおける開発チームとインフラの関係を簡単に説明します。といっても事業領域によって役割も変わってきていますので、ここでは内製のウェブゲームに限った話になります。
GREEではゲーム開発を担当するチームとそれらを横断的にサポートする部やチームがいくつかあり、インフラストラクチャ部もそのうちの一つです。インフラストラクチャ部は各チームに対してインフラ環境の構築やその運用整備などを提供しています。

開発チームとインフラのやり取りは主にChatWorkとJIRAによって行われています。使い分けは以下のようになっています。その他必要に応じてMTGが設定されます。

• ChatWork: インフラに関する相談などのコミュニケーションツールとして使用
• JIRA: 開発チームからインフラへの依頼に使用。ChatWorkで相談後依頼としてチケットが切られるケースや、定型業務に関してはテンプレートも用意されている

GREEの内製ゲームは大部分がリリースから数年経過しており、運用は非常に安定しています。内製ゲームを担当するインフラの運用チームには障害対応まで含めてかなりの量の手順が保存されており、運用の大部分はそのチームだけで対応可能です。それ以外の非定型の依頼や相談については別途担当のチームが対応にあたっています。

以上のように内製ゲームでは長い運用経験の積み重ねによって、定型業務とチーム間の役割分担ははっきり別れた構成になっています。

本案件における体制とやりとり

今回の移植では案件ごとに開発+インフラの2チームが担当として作業を行いました。ゲーム側とインフラを跨ぐような作業も多く、互いの担当チームで検証しながら進める形が取られました。また、当初開発側の人員が足りていなかったこともあり、インフラから開発チームにインフラを中心に見る人員が一人派遣されました。

やり取りの方法は内製から特に変更せずチャットベースで、適宜必要な箇所はJIRAを切っていくという形で進めました。

手順として、インフラから検証環境と本番環境の2つを提供し、開発側が検証環境でゲームを動かしてみて必要な設定を調査、それらを随時共有してインフラが本番環境に反映するというフローになっていました。結果として、このフローはいくつかの理由であまり上手く回りませんでした。

検証環境での確認項目の認識ずれと不具合の切り分けの難しさ

検証環境での確認は、どんな不具合があるか不透明だったこともあり、不具合があったら共有します程度の取り決めで特にフォーマットを決めずに行いました。また開発中であるということもあり、不具合があった場合もスルーされてしまう傾向がありました。結果このタイミングでの確認はおそらく大丈夫というくらいの感覚であっさりと通過し、その後このタイミングで見つけていれば...という不具合をリリース直前に本番環境で修正することになりました。

パブリッククラウドに関してはまだ社内でも知見が十分になく、発見された不具合がインフラ起因なのかゲーム起因なのか判別が難しいものがいくつかありました。それらの不具合のいくつかは共有されずにスルーされてしまっていました。

小さな課題を共有するために

実際にはこのタイミングでインフラ、開発チーム双方にも確認しなければならない項目があり、必要なのは小さな情報も共有出来るコミュニケーションコストの低い方法でした。

今回のケースではインフラから開発チームに人を派遣しており、これは共有チャットに投稿されない小さな情報を拾える点で効果的でした。開発とインフラの双方に課題が発生するケースでは情報を拾って共有する人材を配置するのはおすすめできます。

案件の後半ではそれに加えて結構な頻度で直接話し合いながら設定や更新作業が行われました。開発チームとインフラのやり取りという意味では案件が進むにつれチャットも活発化し、小さな情報を共有できる土壌が整ってきていました。

共通化されない情報の共有について

複数の案件が並列に走っていたため、初期の頃は情報共有が十分でなく、ゲームAで踏んだ罠をゲームBが踏むような時期がありました。特にパブリッククラウドでは案件ごとに環境が別れている、かつそれぞれで変更が柔軟に行えるのは利点でもあり、共有する情報の判断が難しい部分がありました。

この問題はチーム間の定例での資料共有やゆるい情報共有の場を持つことで解決に向かいました。ただ、これは全体を情報共有して各自が取捨選択するという形に落ち着いており、根本的な解決策は今後の課題として残っていると考えています。

役割分担の境界線について

環境がオンプレからパブリッククラウドに移ることにより、開発チームとインフラの役割分担にも変化がありました。

インスンタンスの起動や破棄が楽に行えるパブリッククラウドでは、前述したJIRAで依頼して作業を待つより、自分たちで実施してしまったほうが早いケースがいくつもあります。これに関しては、一部の開発チームでは必要に応じてサーバーの台数調整を自ら行っています。当初インフラ側では、作業の押し付けと捉えられないかどうかを懸念していましたが、開発チームが協力的だったこと、依頼するフローがなくなるメリットなどもあり、スムーズに導入が進みました。

運用がある程度安定してからは、デプロイツールなどの今まではインフラが管理していたツールの開発チームへの移管も進んでおり、今後もある程度まではこの流れが続くのではと考えています。

おわりに

今回は内製ゲームをパブリッククラウドに移植する案件を例に、技術以外の課題や変化をご紹介しました。

こういった話は技術的な話に比較してあまり語られないような気がしますが、かなり広範囲に渡って発生し得る問題なのではないかと考えています。
特に技術的な転換点においては、コミュニケーション方法やワークフローも合わせて見直す必要があるということは見込んでおくべきコストかなと思います。

この事例共有が開発に集中できる環境を整えるための参考になれば幸いです :)

明日はRobin Boucherさんの話です。引き続きGREE Advent Calendar 2015をお楽しみください。