2021年に新卒で入社してからずっとSWETグループのIKです。
現在SWETグループにおけるゲームチームのプロジェクトマネージャー(以下、PM)をしています。 当記事では、自分がプレイヤーからPMになっての変化について発信していけたらと思います。
はじめに
SWETグループの属するIT本部品質管理部は、ゲーム・ソーシャルライブ・ヘルスケア・スポーツなど様々な事業を展開し続けるDeNAグループ全体の様々な品質にコミットしている部署です。
その中で、SWET(SoftWare Engineer in Test の略)グループは、ソフトウェアテストを起点とした、「DeNA サービス全般の品質向上」と「DeNA エンジニアの開発生産性向上」の両方により、価値あるものを素早く提供できるようにすることをミッションとしています。
SWETでは2024年7月までは、次のようなチーム体制になっていました。
- ゲーム領域
- iOSチーム
- Androidチーム
- CI/CDチーム
これが、さまざまな事情により2024年8月から自分がゲームチームのPMをすることになりました。
はじめてのマネジメントで直面した課題と解決策
課題1. 未経験のPM業に対するハードルの高さ
PMの仕事には、遂行する施策ごとの予算と実績の管理(予実管理)が含まれます。 これはプレイヤーとして仕事をしていた時には経験したことのない仕事でした。 予実管理では、
- 施策ごとに予算がどれだけ必要かを計算し、最適な配分を決定する
- メンバーの進捗管理、施策の完了に対する締切の定義、管理
- タスクに対するアサインの決定
を考慮しなければなりませんでした。
これらは単に技術開発の視点から考えるだけではなく、関わっている案件のスケジュールや状況といった「案件全体の情報」やチームメンバーのスキル、 手の空き具合といった「ゲームチーム全体のバランス」を重視する必要があります。
解決法
そもそもPMについて深く知る必要があると感じ、
を読みました。
まず、職務として次のことを行なう必要があることを書籍から学びました。
ステークホルダーエンゲージメント
- 案件メンバーと関係構築のために何ができるかを考え、実行
- 案件に対するゲームチームの役割と責任を明確にし、案件側と合意を得る
- 施策の目的・生み出す価値の共有
- 情報を案件から引っこ抜いてくる
チームメンバーのマネジメント
- ゲームチームのメンバーに合わせた動機づけを行う
- 情報共有
- 各施策、タスクのアサイン
計画・進捗確認
- ゲームチームの施策の価値とは何か言語化する
- 予算の管理、案件側と施策の合意
- 施策に対する開発アプローチの決定
- タスクの優先順位の決定
- 進捗管理
- バックログの管理
測定
- 各施策の成果物の効果測定
不確かさ・複雑さへの対応
- リスク管理
- リスクをリストアップする
- リストアップしたリスクに対して許容範囲を決める
- 許容範囲をはみ出そうになった時どうするか決める
- 可能であれば案件側が握っているリスクリストを得る
引き継ぎ前は
- 施策ごとに予算がどれだけ必要かを計算し、最適な配分を決定する
- メンバーの進捗管理、施策の完了に対する締切の定義、管理
- タスクに対するアサインの決定
を行なう必要があると思っていましたが、解像度がかなり低かったことがわかります。
課題2. 知るべき情報が一気に増えた
ゲームチームでは、次のような複数の施策を展開しています。
- 静的解析器の開発、メンテナンス、導入サポート
- 静的解析の結果を収集し、ダッシュボード化する仕組みの開発、メンテナンス、導入サポート
- 高結合レベルテスト
- オートパイロットフレームワークの導入、開発、メンテナンス
- インゲームに対するマスターデータとロジックの統合テストの仕組みの開発、保守
- その他社内ツールの開発、運用
これらの施策のうち、自分は静的解析の仕事を主体として取り組んできました。
しかし、PMになってからはゲームチームが当時行っていた施策をすべて把握する必要がありました。 自分が関わってなかった施策に対しては当然解像度が低かったため、すべての施策のキャッチアップをしなくてはなりませんでした。
解決法
当然ですが、PMはゲームチームの施策についてもっとも詳しい立場であるべきであり、これが施策の方向性を正しく示す助けとなります。 また、関わっている案件の状況やスケジュールもゲームチームの中で一番知っている必要があります。 冒頭にも書いた「案件全体の情報」を得るためにはとにかく多くの情報を手探りで探しながら取捨選択をしないといけません。 情報収集と分析を繰り返し、解像度を徹底的に向上させることが成功に繋がります。
- 社内議事録を片っ端から読む
- 施策上の関係者と連携し、案件の状況や担当者の困りごとのヒアリング
- 関わっている案件の人と雑談する中で課題を拾い上げる
をし、関わっている案件の情報を積極的に入手しました。 それを持ち帰ったうえで、課題1の解決方法でも記載したPMの職務に照らし合わせて業務を遂行することで、 案件側とも信頼関係を築くことができました。
課題3. コンテキストスイッチが増えた
PMとしての業務が始まり、単純に考慮するべき事柄が増えたことで、日々の作業において多くのコンテキストスイッチが発生するようになりました。 それにより
- 1つのタスクに深く没入しにくくなる
- 疲れの増加
を実感する機会が増えました。
解決法
コンテキストスイッチが増えること自体は、PMとしての役割上避けられない側面もあります。 そこで、「サーヴァントリーダーシップ」というリーダーシップの1つのスタイルに着目しました。 このスタイルでは、リーダー自身が「仕える者(Servant)」としての役割を果たし、組織やチームメンバーを支えることを重視します。 その考え方に基づき、他のチームメンバーができるだけコンテキストスイッチに直面しなくて済むようにサポートすることに注力しました。
具体的には
- 基本的に任せた仕事をやり切るまで別の仕事をアサインしない
- 他部署とのコミュニケーションは基本的に自分がやる
の2点を意識しました。
この取り組みにより、メンバーが1つのタスクに没頭できる時間が増え、集中力向上とモチベーション維持に貢献できたと思います。 また、疲労感やストレスの軽減にも寄与できました。 この環境がよりよい成果を引き出す基盤となっています。
気づきと学び
信頼関係構築により、仕事の依頼が来る
PMとして業務を遂行する中で、改めて「人との信頼関係」の重要性を実感しました。 私はもともと人と話すことが好きだったことと、関東圏に引っ越したことを契機に意識的にオフィスへの出社を増やしました。
リモート環境が整った時代ではありますが、実際に現場に足を運び、対面でコミュニケーションを取ることで得られる 「現場の空気」や「表に出ない課題」を感じ取ることができると学びました。
また、それらをSWETに持ち帰り施策として取り組み案件に貢献しました。
結果として、案件の関係者から一定の信頼を得ることができ、 その信頼が新しい仕事の依頼に繋がることを実感しています。 いわゆる「仕事が仕事を呼ぶ」状態が生まれ、よいサイクルを構築できつつあります。
興味深いのは、信頼関係構築が進むにつれて、直接関わりがなかった別案件の関係者からも仕事の依頼をもらうケースが増えてきたことです。
チームをうまく回すコツを掴んだ
ゲームチームを運営する中で重視しているポイントをご紹介します。
締切の明確化
稀に案件側から相談が来ることがあり「優先度は高くないので、手が空いたらやってほしい」といわれることがありました。 一見できるときにタスクをやればいいと思いますが実は違いました。 どんなタスクにも、完了したら喜ばれる時期があります。 たとえば
- QAに入るまでに完了しているとQAの負荷が減らせる
- バージョンx.x.xまでに完了しているとリリースに間に合う
などです。依頼主が締切を示さなかった場合はPMが締切を提案するのがベストだと学びました。
コミュニケーションの取り方の工夫
最初自分は
- できるだけMTGを減らす
- テキストコミュニケーションでできるだけやり取りを減らす
ことがコミュニケーションのベストプラクティスだと考えていました。 しかし、PMをするうえでさまざまなバックグラウンドの人とコミュニケーションを取る必要があります。 中には、自分がベストプラクティスだと考えていたコミュニケーションが「堅苦しい」印象を与えてしまうこともあったようです。
なので、相談する相手に応じてコミュニケーションの取り方を工夫する必要があることを学びました。 工夫することで、より多くの情報を相手から引き出すことができます。
自分のモチベーションの変化
最初自分がSWETに配属されたときのモチベーションは「開発者の開発体験をよくするためのツール開発をしたい」でした。 しかし、PMになったときに上記のモチベーションはできることを自ら狭めていることに気づきました。 今ではPM業務を通じてQCD(Quality, Cost, Delivery)への影響を意識するようになり、幅広い視点で施策を検討することが自分の新しいモチベーションになりました。
未経験から学んだこと、これからの展望
PMとしての業務を通じて、視野を広げることの重要性を痛感しました。 今後はよりよい施策管理を実現するとともに、チームメンバーの成長や業務環境をよりよくするためのチームビルディングに注力していきます。 さらに、自身のマネジメントスキルを深め、SWET全体の発展に貢献していきたいと思います。
本記事が皆様の参考になれば幸いです。 DeNA Testing Blogではソフトウェアテストやその隣接領域に関する記事や勉強会の登壇資料などを投稿しています。 また、弊社ではDeNA EngineeringやDeNA公式Xアカウント@DeNAxTechでも情報の発信をしております。 ブックマーク・フォロー等よろしくお願いします!