ケルベロスの最初の取り組み

こんにちは、コザキです。
私は、2017年末にアカツキに転職し、かれこれ3年。Think@(シンカ)というチームリーダーを務めております。

Think@はゲーム事業のリスクマネジメントを強化するためにできた組織で、現在は事業推進・企画といった領域と幅広く自由に仕事をさせてもらっています。(Think@の詳細はこちら

今回は、アドベントカレンダー一発目。
ケルベロスの最初の取り組みである「開発・運用レギュレーションの確立」(以下、レギュレーション)を紹介したいと思います。

この記事は、特に仕組みづくりに携わる人に、何か一助になれば幸いです。

きっかけ

2018年の秋だったと思います。Think@として横軸での活動の認知されてきた中、とあるプロジェクトから相談を受けました。

「外部開発にてアカツキとして守っておくべきものはあるのか」

これまでにも外部リソースを使った開発はありましたが、今回は企画・エンジニアリング・クリエイティブ制作など大部分を外部リソースにて開発を行うものです。外部開発の品質を担保することができるようになれば、将来の事業部の可能性を広げられるため、今回「内部開発と同様の品質を達成する」という課題を対応することとなりました。

当時は、各プロダクトチームで蓄積されてきたノウハウはあるものの、チームをまたいで共通言語として呼べるようなノウハウはありませんでした。開発や運営のラインが増えてくる中、属人化されたスーパーマンの支援では限界が来るし、個別最適では品質にばらつきが生まれてしまう。ということから、アカツキとしての基準を作ろうということで、CAPS(キャップス:組織の詳細はこちら)と法務を巻き込み、レギュレーションの作成に着手しました。

作成アプローチ

CAPSで積み上げていたノウハウがあったので、それをベースにしつつ、あるべき姿を定義して現状とのギャップを埋めていくというアプローチをとりました。
約60を超えるテーマに対し、Think@の2名とCAPSの2名で担当を割り振り、隔週でそれぞれがレギュレーションを言語化。そしてそれを参加者でクロスレビューし、のちに法務観点で全ページをレビューしました。

<レギュレーション> ※一部抜粋

レギュレーション一部

例:法令表記、ガチャ確率表記、おまけ施策、インシデント発生時のエスカレーション、など60を超えるテーマを扱う

現場の情報収集はCAPS、法的見解は法務、全体推進はThink@といった役割で、それぞれの得意分野でシナジーを生かし、約半年間かけて作成しました。

大事にしたこと

レギュレーションの確立にあたり、大事にしたことを伝えたいと思います。

①段階を持った導入
 作成当初から運用されることは必須とはしていませんでした。むしろ狙っていた用途は「共通言語」とするということです。Think@やCAPSがそれぞれの理解・認識でプロダクトを支援していては、プロダクトチームは混乱してしまいます。様々な横軸組織がプロダクトチームとコミュニケーションとする際に、共通言語として使うことで、プロダクトチームに混乱を起こさないようにしました。
 また、網羅的な運用を当初から目的としていなかったのは、我々が作ったものが完璧ではないという認識でいたからです。把握できていない現場の状況はいっぱいあるだろうし、第1版はブラッシュアップ前提で作りました。

②柔軟な対応姿勢
 レギュレーションの強制力の定義は、とても気を付けました。例えば、「景品表示法のおまけ20%制限」ならば基準や根拠がわかりやすくルール化しやすいのですが、「商品の割引率」を一定に制限したルールは好ましくありません。プロダクトによっても販売方法や思想は多種多様であり、各プロダクトが最大限の力を発揮できるためにも、その時の状況を鑑みながら柔軟に対応してくことが重要でした。
 このやり方は、コミュニケーションコストが発生しますが、守る側と攻める側がお互い納得できる状況を作るためには欠かせない考えだと思っています。

③クリティカルなものに絞る
 レギュレーションができた後、プロダクトで認識してもらいたいルールを必要最小限に絞りました(60項目中、3~5項目くらいだったかと)。ただでさえ60項目以上あるレギュレーション。運用はもちろん、理解することさえ難易度が高いなかで、「できたのでよろしく」と脳死コミュニケーションしようとするものならば、大事な何かが失われていたのではと思います。。。
 また、他にも ”第三者チェック”というプロダクトチームとは別の部隊がチェックする仕組みを導入しました(僕が導入したというよりCAPSチームが立ち上げてくださいました。この仕組みの詳細は、後続のアドベントカレンダーで投稿されるのでお楽しみに)。これはプロダクトに追加的な負担がなく、クリティカルリスクを回避できるというものです。プロダクトチーム側のメンバーはクリエイティブ制作をミッションとしているので、他の役割で担える負荷はできる限り他で担いたいという想いからです。

さいごに

 つらつら書きましたが、エンタメの制作現場では、クリエイターがのびのびと仕事ができることが大事で、彼らしかできないことに集中できる環境を周りが支援する必要があると思っています。
 当記事が、レギュレーションなどの仕組みづくりをする側の人間の一助となれば幸いです。

大事な要素をサマルと・・・

・共通言語としてのベースをまず作る
・作り手は完璧ではないという認識を持つ
・なので柔軟に対応する姿勢を持つ
・クリティカルな事象だけ適用する
・むしろ関与者が気づかない形で達成できたらwonderful

 明日以降も他のメンバーによるアドベントカレンダーが続きます。ぜひぜひ覗いていただければと思います。また、私は12月22日にも記事を書く予定です。ケルベロスの将来について。乞うご期待。では。

この記事が気に入ったらサポートをしてみませんか?