IT系サービス・ゲームの運用ノウハウのまとめ
大規模モバイルゲームの運用経験や非ゲームのITサービス等々の運営で得た知見をまとめようと思います。
●何を目指すか?
まずは、何を目指すのかです。運用で目指す方向性は大きく分けて2つあります。
1,最小の工数で最大の成果を得る
(直線的な成長、維持を目指す)
2,指数関数的な成長を目指す
当然、「今の売り上げ、ユーザー数を維持」しながら、「大きく数字を上げる」チャンスもつかみたい、というのがみんなの望むところですが、どちらに比重を置くかによって、優先順位を時間の掛け方が異なってきます。
まずは、自分たちが何を目指しているのか?
今のサービスは維持を目標に、プロフィット機関であり続け、他のサービスを立ち上げて、組織としてグロースするのか?
今のサービスも最大限ストレッチする必要があるのか?
を上司、メンバーを含めて、360度コンセンサスを取るべきでしょう。
私は、現状の維持を大前提に「空き工数」をできる限り作り、「低リスク」で新しい試みに挑戦するのが好きです。
そのために、以下では数字を維持しながら、空き工数を作るための運用術を紹介します。
●維持、成長のために
プロダクトのライフサイクルがピークから減少に転じるようなライフサイクルであっても、プロダクトのKPIが維持、成長し続けるためには、何をすれば良いのか?
基本的には、以下の項目に関して、 チーム内でブラッシュアップを続けることだと思います。
- 何をやるか、の企画精度を上げる(
サービスのPDCAを回し続ける) - どのようにやるか、をスリム化する(効率化を徹底する)
- みんなで強くなる、に向き合い続ける(チーム力を強化する)
1.何をやるかの精度をあげる
・振り返りをしっかり行なう
企画の精度を上げる、とはPDCAを回し続けることを指します。
狙った施策を投入した際に、マーケット(ユーザー)はどのように反応したのか?
自分たちの頭の中で思い描いていたイメージとのずれを確認します。
この頭の中のイメージとマーケットとのズレを認識して、狭めていくために振り返りを行います。
自分のイメージのどこが良くて、どこが悪いのかを可視化し、肌感覚を持って理解することで、「狙った」企画で「当てる」ことができるようになります。
振り返りを行う上でのTipsとしては、以下のものがあります。
・リリース前に、振り返りのイメージを持っておく
どのタイミングで、 どの数字を使って振り返りを行なうのかを施策立案時に明確にしておきます。
振り返りをスムーズに行なうことができるとともに、 企画時にありがちな「なんとなく面白そうだが、 実際は対した効果を産まない企画」の不備に気づくことができます。
この様な企画は、ターゲットが不明瞭、ユーザーに与える体感( いわゆるUX)が不明瞭、 サービス内の他の機能との関係性が考慮されていない、 企画者が実際にその企画が動き、 どのようなアウトプットを生むのかをイメージできていないことに よることが多いのです。
数字という厳格な指標を持っての効果測定をイメージするこ とで、企画の不明瞭さに気づくことができます。
・ナレッジとして蓄積、共有をする
振り返った内容はナレッジとして、 チーム全員がアクセスできるようにし、きちんと蓄積します。
新しくジョインしたメンバーが過去に逆上って、何がうまく行き、 何がうまく行かなかったのか、
現在のサービスはどのような思想の上に、 設計されたものなのかを素早くキャッチアップできるようになります。
また、障害を発生させてしまった場合は、その経緯、どうすれば防げたのかも確認します。
・不要な運用施策を辞める
サービスの運用では過去始めた施策が対した効果も生まなくなっているのに、 そのまま工数をかけて運用されているということが起こりがちです。
また、不要と感じていても、施策を考案、実行したのが上の立場の人間であると、施策の運用をストップしようと言い出しづらい雰囲気であったりします。
そこで、定期的にチーム全体で、 継続実施中の施策に継続する意味があるのかを確認する必要があります。
既に効果を生んでいない様であれば、施策の継続をストップするか、軽量化し、小工数で回せるように修正します。
例えば、新規集客系の施策はリリース時ほどの効果を運用期には得られなくなってくるものです。
マーケットのたいていの見込み客にはリーチ済みであるためです。
ただし、大多数には見向きもされない仕様でも、 一部の人は愛着を持って使用しているケースは多々あります。
そのようなユーザーへの最低限の配慮や説明は必要でしょう。
2,効率化:どのようにやるか、をスリム化する
効率に関して重要なことは、"無駄な開発をしない"ということです。
無駄な開発、作業をしないことで、少ないコストでKPIを上げたり、大きなユーザーへの価値を提供することができます。
・中長期の開発計画を立てる
中長期的な開発計画、マイルストーンを作ることで、場当たり的な開発を無くすことができます。
サービス開発で良くあるのが、必要だと思って作ったけど、その後追加する他の仕様とバッティングして不要になる、というもの。
もしくは、その時は必要だと思って作ったけど、サービス運用の全体方針からはずれているというもの。
中長期で開発内容を見通しておくことで、そのような無駄に気づくことができます。
また、今後の開発を可視化しておくことで、大きな開発を小分けにして、開発ラインが空いている部分に組み込むことができます。
サービスを統括するマネージメントレイヤーからしても、何をする予定かが見えていないと不安なものです。
・できる限りの作業を自動化する
できる限り作業、本質的な価値の源泉ではない部分に使う時間を減らします。
単純な作業時間もそうですし、考える時間もそうです。
例えば、ゲームであればマスタテータの作成などは可能な限り、自動化します。
プランナーが意図したい条件を入力すれば、マスタデータが自動でできる仕組みを作るのです。
エクセルの数式やVBAを使用することで、ルーティン作業の自動化、効率化ができます。また、場合によっては、エンジニアと相談して、OPEを作成してもらうのも良いでしょう。
また、このようにエクセルを含めたシステムを仕様することの利点は、作業時間の短縮だけでなく、アウトプットの均質化をもたらすことです。
仕組みを作ることで、熟練のメンバーでもジョインしたてのメンバーでも同じアウトプットを出すことができます。
・ヴィジョンを掲げる
ビジョンを掲げることには、サービス運用において2つの効果があります。
1つ目はそれによってモチベートされるメンバーがいるということ。
2つ目はメンバーが上位メンバーに判断を仰がず、自主判断できるようになることです。
これにより、上司の指示待ち、相談待ちのような無駄なタイムロスがなくなります。
1つ目のモチベートされるという点ですが、やはり人というのは、自身を超えるより大きな存在、目標の為に働くことに意義を感じるものだと思います。
単純な数字を追うこと、自身の物質的な満足を満たす以上のものをメンバーに提供することができます。
また、2つ目はビジョンというより大きな文脈から判断すべき事象の妥当性を確認できるからです。
メンバーが企画を考える際も、何も制約の無い状態で考えるのは難しいものです。
そんな時もビジョンを元に、「理想の世界観を定義し、現実のギャップを埋める施策を考えて」というと考えやすかったりするものです。
3,チームビルディング:みんなで強くなる
サービスの運用が劇的にうまくいくようになる方法は、チームを強くすることです。
1人の力でできることは限られていますが、数人以上のチームの力が強くなった時の効果は大きいです。
・メンバーの育成
チーム力を上げるための方法の一つは、メンバーを育成することです。
メンバー育成は、必要な前提知識をシェアする、仕事の背後にある考え方や思想を教える、当人の職種以外の周辺領域のスキルや知識を身につけさせる。
WEBサービスやゲームなど、プランナー、エンジニア、デザイナー、マーケター、営業など様々な専門知識のメンバーが関わっているプロジェクトの場合、メンバーが担当外のスキルや知識を身につけることで、そのセクションとのコミュニケーションが円滑になります。
・モチベート
メンバーをモチベートすることも、チーム力を上げることにつながります。
メンバーをモチベートするためには、先に触れた「ヴィジョンを与える」以外にも
・新しい経験をさせる
・真価を発揮させる
得意なポジションに当てはめて、自己肯定感を上げることでモチベートします。
・小まめに声をかける
こちらも、自己肯定感を上げるためと、相手の状況を正確に把握するためです。
・話を聞くべき時は、きちんと聞く
アクセプトされるかどうかは置いておいて、話(意見)を聞いてもらえると人は一定の自己重要感が満たされます。一方で、話を聞いてもらえない場合は、本人自身の中で悶々と思考が拗れていきネガティブな方向へ進みます。
・チーム力を上げる
チーム力を上げるために、効果的なことの一つに「メンバー間の信頼関係を上げる」という点があります。
メンバー間の信頼関係が高いと、コミュニケーションが活性化し、コミュニケーションの不足や不備による遅延や手戻り、品質の劣化が起こりづらくなります。
また、ブレストなどのアイデアを出す場でも、意見が活発に出てくるようになります。
チームの信頼関係が高いかどうかは、雑談が自然に生まれるか?、自然に笑っている人が多いかどうか、などを見てチェックします。
●マネージメントの心得
ここからは、サービス運用というよりは、少し上の視点。マネージメントとしての心得についてです。
・人材の流動性の担保
人材を一つの職務、チームに固定化しないことは重要だと考えます。
もちろん、異動は短期的にはコストです。一見、同じ従業員には慣れて生産性の高い職務をやってもらうのが得な様に見えます。
しかし、本当のサービス運用は知的生産であり、単純労働ではありません。
多様な世界を理解して、様々なアイデアを生み出せるようになってころ生産性が上がります。
チームからしても新しいメンバーのジョインにより、他のサービスや職務での経験を活かせてもらうことは重要です。
私はジョインするメンバーが来るたびに、
・過去、何をしていたのか?
・その経験でこのチームで活かせそうなことは何か?
・チームにジョインしてみて、おかしいと思うこと、違和感を感じることは何か?
をヒアリングしていました。
「世界を固定しない」ということがサービスの運営では重要です。
・チャレンジできる枠を必ず確保する
ルーティーンワークは人を飽きさせるものです。
本人の性格にもよりますが、キャッチアップの早い優秀な人材ほど、ルーティーンワークを嫌がる傾向もあります。
チームの中にチャレンジングな領域を必ず用意して、適宜メンバーを挑戦させることが組織の活性化には重要です。
・ユーザーに与える価値に焦点を当てる
もちろん、売上やユーザー数は重要です。しかしながら、サービス運用の局面ではチームの能力や努力ではどうしてもコントロールしきれない場合があります。
そのようなときは、「ユーザーに与える価値」に焦点を当てることがオススメです。
数字はコントロールしきれませんが、「ユーザーに与える価値」は努力で増やすことができます。また、「ユーザーへ与える価値」が長期的には売上やユーザー数に跳ね返ってくるものでもあります。