ぷらこあ

ゆるふわゲームクリエイター / イベントオーガナイザーを目指してます

ゲーム開発マネジメント勉強会 vol.2 に参加しました

ゲーム開発マネジメント勉強会とは

management-for-game-development.connpass.com

@tk_adio さんが立ち上げた ゲーム開発マネジメント研究会 が企画/運営を進める、ゲーム開発に特化したマネジメントの勉強会です。第1回 が7月に開催され、2回目の開催となる今回はゲーム開発マネジメントに携わるメンバーによるトークセッションが行われました。

登壇

ゲーム開発マネジメントの現場から / 開発上がりのPMが気を付けていること

最初は株式会社サイバードでプロデューサーをしている谷 昌宏さん。普段はソーシャルゲームの開発/運営に携わっていて、ゲームサイクルや運営周りのディレクションも行なっているそうです。

📝考えているPM感

  • ゲーム開発において、デベロッパーの末端に行くほどアジャイル/スクラムが形骸化している
  • 裁量が不明瞭であったり、責任に裁量が伴っていないことがある等「意識が希薄」な現場が多い
    • プロジェクトマネージャーが不在/プロデューサーだけど実際はディレクター等
  • PMの能力の良し悪しがチームの幸不幸に関わるのに対し、現場のマネジメントに対する理解が薄かったりする
    • パフォーマンスを出すために "役割を啓蒙する" のも大事だと考える
    • PM以外の他の誰もやってくれないことではある

📝 事例集: "実行" のレイヤー

  • マネジメントにおける実行は リスク管理 にも置き換えることができる
  • 計画通りに行かなかったら何が起こるかを予想し、バックアッププランを立てる
  • リスクは 影響度発生率 の2軸で評価する
    • この軸をPM一人で判断するのは無理
    • ディレクターやリーダーと一緒に視点をたくさん持つ
    • これをどれだけ丁寧に入念にやっていくかがリスク管理の肝
影響度
  • どのくらいの人やタスクに影響があるか
  • 例えば、ゲームのコアが固まっていない場合、影響度が高い
  • 技術サイドから見たら影響度が高いケースもあるので、ゲームデザイン/仕様に止まらず、開発メンバーからリスクをボトムアップする仕組みや関係を構築するのが大事
  • 問題を組み上げる仕組みの一環として、PMは開発チームの中に席を作って一体感を持ってやる等
発生率
  • 経験やスキル、スタッフの実績を見て発生率を判断する
  • 期待に対してブレることもあるのでフレキシブルに評価を変動する

📝 事例集: "計画" のレイヤー

  • 「新作の打ち上げが伸びなくてまずいからなんとかして」
  • 改善ポイントが多くて対策していく必要があっても、終わりが見えない感じを見せないことでモチベーションを担保する
    • 目標をシンプルにする
  • 計画レイヤーで、ゴールに向かっている実感が得られるKPIを設定する
  • プレイヤーズジャーニーをKPIにするのも実感を得やすくてよい
    • ガチャでSSRを引く/ストーリーの山場を迎える等

📝 事例集: "ゴール" のレイヤー

  • 「現場が炎上していて、開発遅延中なので立直ししてほしい」
  • やっちゃいけないのは「今の作業をみんな頑張れ」
    • 炎上しているステータスを認識しているはずなので、終わりの見えないゴールに取り組むことになる
  • マネジメントの面から見ると 「どれだけ安心して仕事が出来る環境を作るか」 が大事
    • シンプルなゴールを提示する等

📝まとめ

  • 開発マネジメントとは開発を統括し、ゴールを目指すこと
  • 道筋を示して、リスクの把握と対策を継続的に実施すること
  • 安心して開発に打ちこめる環境を作り、それを改善し続けることを心がける

トークセッション

登壇者
  • 湯前 慶大さん: 株式会社アカツキ VP of Engineering/認定スクラムマスター/認定LeSS実践者
  • 山浦 大輔さん: 株式会社DeNA ゲームコンテンツ事業部 第一開発部 エンジニアグループ マネージャー
  • 山田 元基さん: 株式会社QualiArts 技術責任者/プロジェクトマネージャー
  • 開 哲一さん: ワンダープラネット株式会社 執行役員 VP of Engineering

f:id:lycoris102:20181021122114j:plain

今回は事前にヒアリングした各項目に対して深掘りするようなスタイルで話が進んでいきました。

内容

📝開発手法について

  • 完全にスクラムとは言い難い組織が多かった
    • 例: 初期の計画や納期をガッツリ組んでいるところが理由で「終わらない」という課題感を避ける
    • 例: プロトタイプはアジャイルで作ったりするが、それから先は計画引けるのであれば引く

📝 BTS(Bug Tracking System) / ITS (Issue Tracking System)

  • JIRA は使いこなせる人が使える印象があり、全員が親しみやすく使える訳ではないという声
    • ただしリリース後のバグトラッキングツールとしては優秀
  • また Wrike を使っているチームもあった
  • 物理カンバンが見える化の側面と使い方の自由度の側面で人気があった
    • アナログは過去のタスクのトラッキングがしにくいがフロー情報として扱っているとのこと
    • もしくはJIRAより機能を落としたカンバンツールとして Trello を上げる人も

📝その他ツール

  • 情報教諭手段として confluence が採用されている組織が多かった
  • 仕様書に関しては、企画者がけっこう好きなツールで作っているとのこと

📝プロジェクト初期にやっていること

📝ふりかえり

  • KPTは1on1でも使用している
  • KPTの他にはサンクスカードを使ったりしている組織もあった

📝PMがメンバーに自己管理をどこまで求めるか?

  • 自己組織化したチーム/PMの役割がいなくてもスムーズに進むチームが理想
  • その上で、マイクロマネジメント/小まめなメンバーに対するケアが必要かどうかという話
    • タックマンモデルにおける形成期では必要なケースは多そう
    • その過程の中で「問題のシェア/発信」「自分自身のパフォーマンスを最大化するセルフマネジメント」の訓練をする
    • 自分でできた方が、その人のやり甲斐にも繋がる

📝オススメの書籍

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

Value Proposition Design: How to Create Products and Services Customers Want (Strategyzer)

Value Proposition Design: How to Create Products and Services Customers Want (Strategyzer)

🍻懇親会

感想

他社がどういうプラクティスを使って開発に臨んでいるのか、あまり表出する機会がないので、こういう勉強会は非常に貴重な機会だと考えています。今回のお話は結構ゲーム分野以外でも同じようなやり方をやっているように感じていて (それ自体は悪いことではなく需要はあると思うのですが) 欲を言えば 「ゲームならではの差異や悩み」 みたいなのがあれば、今後いっぱい聞いていきたさあります。

▲この「ハピネスドア」というプラクティスによるアンケート集計、とても書きたくなったので良さそう。

運営メンバーのみなさん、登壇者のみなさん、ありがとうございました! f:id:lycoris102:20181021125206j:plain