#ソシャゲの話をしよう。「運営のミスとPDCAサイクル」
#ソシャゲの話をしよう 。
どうも、死に急ぐ生命の果実です。
みなさん、ソシャゲ遊んでますか？
運営の不手際にイラっとしたり、詫び石貰ってほっこりとかしてますか？
今回はそんな「運営のミスとPDCAサイクル」のお話をしたいと思います。
ざっくり以下のような構成でお話をできればと考えております。
運営のミス
運営のミスというのは、ソシャゲをやっていれば頻繁に出くわします。
して、今回は「運営のミスとはなんぞや」を定義しながら、その裏に潜む問題に焦点を当てていきたいと思います。
運営のミスといえば何を思い浮かべますか？
たとえば簡単なところではイベント期間やお知らせなどの記載ミスとか。
やや重めであればイベントのバランス設計や報酬設計のミスとか。
深刻なところでいくと、特定の動作で必ず落ちるアプリの不具合とか。
あと、ゲーム自体が進行不能……などなどが思いつくかもしれないですね。
とはいえ。
我々ユーザーが観測できるのはあくまで表面上のミスだけです。
運営ミスに対して謝罪と補填と修正があれば、まあ大抵のことは許しますよね。
というか、一通り騒いだらあとはキレイさっぱり忘れてしまいます。
潔いというか、ユーザー側もまぁそんなもんですよね。
PDCAサイクル
さて。
話は少し変わりますが「PDCAサイクル」というものをご存じでしょうか。
Plan（計画）、Do（実行）、Check（測定・評価）、Action（対策・改善）ので構成される仮説・検証型プロセスを循環させ、マネジメントの品質を高めようという概念。
……とのことです。最近はネットでなんでも調べられるので便利ですね。
ソシャゲを含むサービスの運営も、わりとこのPDCAサイクルを意識することが多いですね。
年間のスケジュールやひとつのイベントに対し、計画・実行・測定・対策を検証していくというかんじです。
スタッフの熟練度や精度はさておき、こういうプロセスごとに目標を設定するのは、それなりに役に立つので個人的にはもっと重視してよいと思っています。
さて。
そのPDCAサイクルのそれぞれの工程において、ミスは発生します。
その代表的な例と影響範囲をそれぞれ軽く見ていこうと思います。
Plan（計画）でのミス
この段階は文字通り施策のプランを立てることが目的です。
内容はもちろんのこと、誰に対してどんな施策を行うのか、それによってどんな効果が発生するのか、利益はどれくらいが見込め、またコストはどれくらいかかるのか。どのラインを越えれば成功か……。などなどの事項をあらかじめ計画しておき、施策の準備や実行、振り返りの際の基準にするのですね。
このフェーズでの失敗とは、「そもそもずさんな計画を立ててしまう」ということです。
「なんかおもしろそうだからやってみよう」とか、「まぁとりあえずやったらなんとかなるんじゃない？」のような感じで、勢いで施策が見切り発車するときに多く見られます。
すごく切羽詰まって次から次へ施策を打ちたいが回ってないような現場や、逆に余裕がありすぎてその場のノリや空気が支配する現場ではわりと発生します（偏見）。
このフェーズでのミスの影響範囲は広いです。
なぜならこれは、後に続くD・C・Aのすべてのフェーズに悪影響を及ぼすからです。
計画フェーズがずさんであればあるほど、実行フェーズは失敗する可能性が上がるし、なにを評価フェーズではなにを基準に判断すればいいか指針がなく、対策フェーズではなにを基準に振り返ればいいかわからない。悪循環の始まりです。
Do（実行）でのミス
この段階はソシャゲでいえば施策の新規開発やデータ実装、そしてリリース作業などにあたります。
ユーザーが観測して指摘する運営ミスというのは、大抵このフェーズでです。というか、他のフェーズをミスしていてもユーザーの立場からは観測のしようがないのです。
ここでのミスの例はわかりやすいですね。
表示や画像が間違っているとか、バグで進行不能。新規機能が落ちる。報酬が獲得できないなどなど。
大抵の場合ユーザーには実害が伴うという意味では、それなりに大事ですが、ものによってはリカバリが効くといえば効きます。（だからといっていいというわけではないですが）
Check（測定・評価）でのミス
施策中、あるいは施策が終わった後の効果測定を怠る、または間違えるなどですね。
イベントはやって終わり、ではありません。
アクティブユーザー数や新規ユーザーの推移や、課金や売上などなどの数値を測定し、後につなげなければならない。のですが。
そもそも計画段階でスベってると、先にも書いたように評価基準が設定されてない場合もありますし、ここで数値を取る仕組みがそもそも実装されてなかったりします。
新規機能を入れたのに、ユーザーがどれだけ遊んでくれていたのかを測定していなければ、次に続かないですよね。
真の意味での「やりました。あとは知りません。HAHAHA」という状況です。
あと、これがやっかいなのは、計画的に運用を始めないと、後から数値測定のための仕組みを入れるのが結構面倒だったりする場合があります。
で、これがないと上長にまともな報告もできない。
「今回のイベントはTwitterでみんなが盛り上がってるので成功です！」
……という、とんちんかんで内容のない報告が上がる可能性すらあります。
Action（対策・改善）でのミス
ここでのミスは、シンプルにいえば、「改善しないまま同じイベントを繰り返す」です。
つまり、不具合や運営ミスがあった場合同じ過ちを繰り返す可能性が高いわけですね。
ただ、そもそもこのフェーズがうまくできるには、前述したP・D・Cがうまくいっていないと難しいです。
PDCAサイクルは下からの積み上げが重要なので、前提がちゃんとできていないと対処の仕様がないのですね……。
計画はガバガバ、実装のミスは多く補填でマイナス計上、効果測定はできてなくて、そもそもその仕組みも入っていない……。こんな施策のどこをどうして改善したものか。
まぁ、検討材料の土台が揃っていない以上、改善は難しいでしょう。
不本意でしょうが、同じイベントを全く改修なく、あるいはその場のノリでバランスだけ調整して次回リリースという流れになりがちです。
主題のまとめ
こうしてPDCAを振り返ってみると、どこかひとつが転んだだけでも全体のサイクルに影響を及ぼし、次回同系統の施策を行う際にもガバでスタートすることが多いのも想像していただけると思います。
ユーザーからは見えない部分ですが、運営のミスはこういう見えないところで起こっているのです。
こういった状況が続くと、表向きは緩やかに、あるいは急激に、インフレなどの状況が悪化して、品質は下がり、コンテンツの寿命に影響を及ぼします。
よくないですね。
しかしながら、あくまで起こっているのは内部のため、これに対してユーザーができることはあまりないのです……。（お布施をしても解決はしません）
運営内部、あるいはディレクターなど進行管理クラスに、こうしたサービスやソシャゲの運用経験がある人が就けば、あるいは改善が可能かもしれません。
運営にはゲームクリエイターに夢見る未経験の若者よりも、そういった経験豊富で現場経験のあるスタッフを雇ってほしいなぁ……と思います。
結びに
言いたいこととしては、「ユーザーの見えてないところの運営ミスはかなり重要で重篤度が高い」ことと、「運営自身がそれを自覚しているかが勝敗を分ける」ことです。
まぁ、とりあえずユーザーとしてできることは静観です。あと、詫び石は基本的には負の産物なので求めないこと。
（詫び石を配る文化が定着した運営は、いろいろなものがずさんになる印象があります。（※個人の感想です）
運営が組織的な欠陥を自覚し、PDCAサイクルに向き合うようになれば、すぐにでも解決するかもしれません。
まずはちゃんとユーザーの動向を見て、新しいイベントのプランニングをしてくれることを祈ります。
本日僕から言いたいことは以上です。
この記事が気に入ったらサポートをしてみませんか？