「ゲーム開発マネジメント勉強会 vol.2」に行ってきました

「ゲーム開発マネジメント勉強会 vol.2」に行ってきました。

management-for-game-development.connpass.com

場所は目黒のアカツキです。

最近は業務でチームで開発を意識することが増えてきたため、勉強させてもらいました。

前半は登壇発表、後半はトークセッションという構成でした。

いきなり感想

具体的な話が多く聞けたので、非常に参考になりました。

登壇発表では、実際にアサインされたチームでの事例が話されました。チームごとに抱える課題、そしてそれをどう解決するのか、という内容が方針と手段をそれぞれ具体的に示されており、非常にイメージしやすかったです。

トークセッションでは各社ごとの違いが示されたのが興味深かったです。たとえばチームで用いているツール、用いることをやめたツール、最初にやること、定期的にやること、やらないこと、といった内容がありました。特にツールは各人思うことが多いようで、非常に面白かったです。

考察

マネジメントを「ゴールを示し」「安心できる環境を作り続ける」と定義しているのは、自分がまだ曖昧にしか見えていない PM のミッションを非常に明確化している印象を受けた。

また、多くの課題がある状況下での対処法として、無理矢理にでもシンプルな課題へと落とし込み、しっかりと進捗を実感できるようにすることでチームのモチベーションを下げずに進む、というのは非常に参考になる考え方だった。

トークセッションの中では、特にチームビルドの重要性と、そのために必要なマネジメントを感じることができた。自分ができるからみんなもできるだろう、ではなく、全員ができるような環境をいかに作っていくか、自分が環境づくりができるような関係性をどう作っていくか、ということが、マネジメントをする者にとって非常に重要な課題であると認識できた。

発表メモ

開発マネジメントとは

スピーカーにとってのマネジメントとは

• 開発を統括しゴールを目指すこと
• 仕事の話なので収益化は当然必要
• 「価値向上」を「計画」し、「実行」し、そこに「責任をもつ」こと

なのですが...

• 特にゲーム開発では普遍的なマネジメントモデルがない
• PM いない場合もある
• P 兼任のディレクターがいたりする
• P がいっぱいいる場合もある
• 立場と裁量が噛み合わっていないこともある

メンバーがマネジメントへの意識が希薄な場合が結構ある

• メンバー全員がマネジメントの意味を理解できているケースは少ない
• PM チームへの啓蒙も必要
• そうするといざというとき協力を頼めるようになっていく

事例1

• PM にゲーム作る（ディレクター業務）以外をやってほしい的な事例
• 実行のリスクをどう管理するか
• 見守ることは管理ではない
• リスクとは：コスト、スケジュールなど様々ん危険性をまとめた言葉
• リスクの把握をすることがマネジメント
• 把握とは：想定外の事態で何が起こるのかを予測しておく
• 想定外事象は影響度と発生率で評価する
• 例：インゲーム部分が決まらないと他のとこ作れないから影響度デカイ、みたいな
• わかりにくい事象でも各メンバーが報告しやすい関係性をいかに作っていくか
• 厳しく、優しく、上から、仲良く、混ざっていく、などやり方は様々
• PM もメンバーの一人（あくまでスピーカーが用いている考え方）
• あまり評価のやり方は固定しない方が良い
• 具体的な手法：視点を増やして精度を上げる、執念深く対策しまくる

事例2

• 売上悪いから助っ人して、的な
• 期待値：PDCA 回して KPI を改善する
• やること：ゴールへの道筋を示す
• 答えが簡単ならそもそも PM の増員とかいらないはず
• 複雑な事象をシンプルな問題に見せかける（これだけだと詭弁ぽい）
• もうちょっとちゃんと言うと...
• やることが多すぎるとリスク管理も困難、結果メンバーのモチベーションも下がる
• シンプルな大目標中目標を作って進捗を見えるようにする
• シンプルなゴールに向かうストーリーを用意し、進捗している実感を得られるようにする

疑問

• Q. シンプルなゴールとは、1番大きい課題や、近いものをまとめてしまう感じ？
• 本質に近いものを抽出する
• 事例：格ゲーなら格闘部分が楽しめるならチュートリアル改善は後回しでいいだろ、みたいな
• それらを現場主導で発見し、いかにスムーズに導くか、がマネジメント

事例3

• 炎上してるからなんとかして、的な
• リスク管理できるところまでスリム化する
• それができてから、作業遅延解決とか改善の話を始める
• やっちゃいけないのは、このまま頑張れ、的な放置
• ↑安心できる環境を作る、というマネジメントができていない

まとめ

• マネジメントとは
  • 道筋を示すこと
  • リスク把握、対策を継続的にやること
  • 安心して開発できる環境を作り、改善を続けていくこと

トークセッション

トーカー

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

BTS/ITS

• JIRA は BTS としては有用（タスク量の可視化が容易なため）
• Wrike よかった
• Trello っぽい使い方もできる
• カンバンもガントもできる
• ゴチャゴチャしてない
• 管理が得意な人がやるとすごく高速にできる
• 欠点：高価
• EP は年間100万円
• 他のツールは？
• asana
• shotgun
• 物理カンバンの欠点はトラッキングできないこと
• とはいえ、そもそもタスクに対するトラッキングしない

CI

• jenkins の用途は？
• 静的解析とか
• プランナのデータ反映とか
• ガチャのシミュレーション（設定と合ってるか検証）とか

プロジェクト初期にやること

• ミッションの共有
• 何を届けるか
• 誰を相手にするのか
• 何を作るか
• 優先度の低いことを出すのが大事
• みんなで「やらないこと」の共通認識をつくる

スプリント

• 初期で設計もやってしまう（オレオレ設計を避ける）
• プレイ会ベースで振り返りをしている
• 朝会で良かったこと報告してチームビルドにつなげたりしている

ふりかえり

• 同じことをやってるような人たちでふりかえる
• KPT の量をチーム間で共有する
• K を多くすることが目標だったりもする
• サンクスカードとか
• スプレッドシートはみんな同時に書けるから良い
• 一斉に書くと、促されてみんな書くようになる

PM の悩み

どこまでチームメンバーに自己管理を任せるか

• 管理は個人の話
• ただし仕事はチームのものなので発信はしてほしい
• 発信の仕方は訓練次第
• タスクをちゃんと聞き取るのは発信者ではなくチームの課題
• プロトのときは個人で管理しないとやれないものも多い
• チームによりけりではある
• @まとめ
• 基本個人に任せたい
• ただし個人のスキルに依存してしまう
• なのでそれらを拾う動きは必要

Q. マイクロマネジメントは悪か？

• 最終的には悪だと思う
• ただし必要なタイミングはあると思う
• 最初とか
• 上から言われるのではなく、自分でタスク管理できたほうがモチベーションにもなるはず

上層部とのすれ違い

• そんなにあるか？
• 上から余計なこと言われても自分だけで止めたりとか
• 報告頻度とかコミュニケーションをいかにしていくか
• 数値ですぐ報告できるような準備はしておく
• でもまあ普段からコミュニケーションしているのでそんなに問題にならない