こんにちは！開発運営支援のプロジェクト共通基盤チームでエンジニアをしています、石山・辻です。
2021年11月13～14日に開催された Cygames Tech Conference において 「ウマ娘 プリティーダービーの大規模シナリオ制作を効率化するソリューション～社内Webアプリ開発運用事例～」 と題した講演を行いました。
ご視聴いただいた皆様・コメントをくださった皆様、本当にありがとうございました！（いっぱい実装しました）
当時の配信映像のアーカイブはこちらになります。
また本講演で使用したスライドは下記の speakerdeck から参照できます。
講演内容は、大規模組織によるシナリオ制作現場で生じる課題を示し、これを解決するためのWebアプリ「こえぼん」「キャラマップ」を紹介しました。
現場ワークフローにこれら支援アプリがどのような手順で組み込まれたのか、講演では一切触れていませんでしたので、気になっていた方も多いと思います。
本稿では、主にシナリオ制作現場とのコミュニケーション方法や、アプリ開発の手順を主題にお伝えしていきます。
開発運営支援とプロジェクト共通基盤チームの役割
Cygames には制作現場の課題を問い合わせる先として、開発運営支援という部署があります。
開発運営支援の取り組みについては、2019年夏に開催された国内のゲーム開発者会議 CEDEC 2019にて詳しく紹介しています。
CEDiL：ゲームを面白くするためのプロセス改善と組織デザイン ～最高のコンテンツを実現するためのカイゼンとは～
また、オウンドメディアに掲載されているこちらのお仕事紹介記事でも紹介をしていますので、よかったらご参照ください。
開発運営支援の仕事とは？開発・運営上の課題解決のための相談窓口【サイゲームス仕事百科】
プロジェクト共通基盤チームは、開発運営支援に集まってくる課題を解決するWebアプリを構築する開発チームです。
プロジェクト共通基盤チームが一番大事にしていること
私たちが一番大事にしていることは、お問い合わせに対して要望の詳細をヒアリングして情報を整理することと、素早くサービスを構築して使用感を受け取り、これを反映するループをすばやく回すことです。
こえぼんのお問い合わせのときは、セリフと音声がずれていないことを確認する作業がとても大変である、といった課題でした。
このときプロジェクト共通基盤は、CyResourceという社内ファイルアップロード・共有サービスを開発・運用していたのですが、そこで最も早く現場に提供できるように、CyResourceをベースに音声ファイルの隣にセリフ表示機能を追加する対応をしました。
すばやく機能を提供することで、その後シナリオの監修機能やシナリオの検索機能の追加要望が寄せられるようになっていきます。
また、こえぼんの対応でシナリオチームとの信頼関係ができたことで、どんどん相談が持ちかけられるようになりました。
このときの相談の一つがキャラマップのもとになるお問い合わせで、キャラクターの関係図の更新作業が大変になっているという課題でした。
ここでも基本的な機能だけに絞ることで、わずか３か月で提供したのがキャラマップのはじまりです。
この後キャラマップもフィードバックの反映を繰り返して、面白いシナリオを創作するためのツールとして活用されるようになりました。
ここまでは対応を行う際のチームのマインドをお伝えしましたが、次はより具体的な手順にフォーカスして要望を受け付け後のWebアプリの運用までの流れをご紹介します。
Webアプリの運用までの流れ
ここではプロジェクトから業務改善の要望を受けた後の流れの概観を示し、その後に意識している点についてご紹介します。
要望を受け取ってから運用開始までの流れは大きく以下のようになります。
- プロジェクトよりシナリオ情報の管理について困っている旨の相談をもらう
- 内容をヒアリングし、プロトタイプの作成を開始
- プロトタイプにフィードバックをもらいつつブラッシュアップ
- プロジェクトとして運用で使えると判断されたタイミングで運用を開始
- 運用後はプロジェクトと定期的にMTGを行い、要望や課題をキャッチアップしそれを改善するという流れを繰り返します
運用開始前のコミュニケーション
こえぼんは既存のシナリオ制作フローを置き換えるものでした。ゲームの制作工程は前後の工程が存在しているため、「プロジェクト側に対応してもらう」または「既存の作業フローを壊さないような実装を行う」といった対応が必要になります。
後者に関しては、例えば既存のフローがexcelでデータを受け渡していたら、同じようなフォーマットでexcelを出力する、といった形です。
前後の工程が存在するということは、依頼をくれたセクションよりも多くの人・セクションに影響が出るということです。
ですので可能な限り早いタイミングで影響の出るセクション・工程を判断し、関わる人へコミュニケーションをとっておくと安全に改善を進められるでしょう。
プロダクトオーナーを決める
実際に運用に入る前には、必ず「プロダクトオーナー」というものを定めるようにしています。
プロダクトオーナーは作成したWebアプリに「どのような機能を載せるか」であったり「実装予定の優先度」などについてプロジェクト共通基盤と共に最終決定を行う人もしくはセクションです。
例えばこえぼんやキャラマップではシナリオチームがプロダクトオーナーになっています。
このような形にしているのは、コミュニケーションのコストを減らすためです。
プロジェクト共通基盤のWebアプリは複数プロジェクトで使われる事を想定して作成しますが、プロジェクトAとプロジェクトBで内容の矛盾するような要求が来てしまった場合（例えば「UIの項目を、増やして欲しいor減らして欲しい」）、どちらを優先すべきかを全てプロジェクト共通基盤で取りまとめて判断することは非常にコストが高いです。
ですので一旦全ての要望をプロダクトオーナー側で整理してもらい、まとまった内容に対してプロジェクト共通基盤と調整する、というシンプルな座組みでやり取りをしています。
slackチャンネルの構成
プロジェクト共通基盤では運用を始めたWebアプリに関するやりとりを行うため、slackチャンネルを以下のように作成しています。
- Webアプリを使用する全てのプロジェクト関係者が参加するチャンネル
- Webアプリを使用するプロジェクト毎のチャンネル
- 主に秘匿性のある情報のやりとりで使用
プロジェクト共通基盤では複数のプロジェクトでWebアプリを運用しています。
以前はプロジェクト毎のチャンネルのみでやりとりをしていましたが、一つのチャンネルで周知した内容を他のチャンネルでも周知する必要があるなど、コミュニケーションのコストが非常に高かったことから、可能な限り多くの関係者がいるところで情報をやりとりするようにしています。
同様に定期的に行われるMTGもプロジェクト毎ではなく、全てのプロジェクトの担当者を集めて行っています。
これも何か要望があったときにその場で他のプロジェクトで問題がないかどうかを判断できるとより素早い意思決定ができるためです。
またslackのチャンネルには問い合わせ用のワークフローを設置し、問い合わせの履歴を残しつつ、フォーマットの統一を行っています。
定期的な情報のキャッチアップ
どのような作業のワークフローも未来永劫変わらないということはありません。
運用を開始した後もプロジェクト側とは定期的にコミュニケーションを取り、新たに生まれた改善点がないかをキャッチアップすると良いでしょう。
最後に
今回の講演では私たち開発運営支援が、シナリオ制作工程の改善で取り組んだ事例を紹介させていただきました。
現場の課題を改善していくには、現場の人々が真に困っていることを汲み取るためのコミュニケーションと、それに素早くフィードバックを返していける体制づくりが大事であることをお伝えできたかと思います。
本講演の内容が皆様の作業効率化の参考になれば幸いです。