おじさん、はじめての【プロジェクトリーダー】でレベルアップな件

# はじめに
はじめまして＆こんにちは。
AppReviewチーム配属の[＠kuniyosh1](https://qiita.com/kuniyosh1)です。
ゲーム全般大好きです！

2024年12月1日で、グリーに入社してから2年が経ちましたが、今回初めてアドベントカレンダーの記事を書かせていただく事になりました。
グリーに入社するまでは、自身の記事を世に発信するような機会はなかったので、緊張もありながら楽しさの方がちょっとだけ勝っています。

グリー入社当時、僕は33歳で、いわゆるミドル転職を経て、未経験ながらもゲーム業界へ憧れて足を踏み入れました。
ミドル転職についてネットで調べてみると、「人間関係の構築ができない」や「会社の方針に着いていけない」など、転職の失敗談がいろいろとでてきたのでゾッとしましたが、幸いな事に僕はとても恵まれた環境で働けています。

さて、このあとの本題では、AppReviewチーム内で行っている「表示検証」という業務の効率化プロジェクトを、今期僕がリードさせていただいた経験を振り返り、得られた知見について書いていきたいと思います。

社会人歴13年目にして、初めてプロジェクトをリードする中年の足掻きをご覧ください。
# 本題の前に
プロジェクトの内容について触れる前に、「表示検証」という業務について簡潔に説明させてください。
表示検証とは、ゲーム内外の販売物などに表示される画像や文章に、 **ユーザーへ誤認を与える表示（不当表示リスク）** がないかを検証する業務です。
ユーザーへ誤認を与えてしまうと、「騙された！金返せ！」となってしまい（いわゆる炎上）、ユーザーにご迷惑をお掛けしてしまうだけではなく、会社の信用問題にまで発展してしまう懸念などもある事から、不当表示リスクを検知する事を目的に検証を行っています。
（以前[こちらの記事](https://qiita.com/sanshi/items/c7b16779e77c858afe7d#:~:text=%E3%82%82%E8%A1%8C%E3%81%84%E3%81%BE%E3%81%99%E3%80%82%EF%BC%88-,%E3%81%93%E3%82%8C%E3%82%92%E8%A1%A8%E7%A4%BA%E6%A4%9C%E8%A8%BC%E3%81%A8%E5%91%BC%E3%82%93%E3%81%A7%E3%81%84%E3%81%BE%E3%81%99,-%EF%BC%89)でも紹介しています！）
# プロジェクトの進行
## プロジェクト開始のきっかけ
ある日、AppReviewチームのマネージャーである[さんし](https://qiita.com/sanshi)さんから声を掛けられました。
「Kuniyosh1さん、 **表示検証業務の20%効率化** をお願いできますか。 **プロジェクト化してリーダーをやってください** 」と。

昨今のモバイルゲーム業界は冬の時代と言われており、長期に渡り安定したゲーム運営を続ける事はそう簡単ではありません。
僕が所属する部署は品質管理の部門ではありますが、「品質第一に甘んじず少しでもコスト貢献をしよう」という部長やマネージャーの思いも、今回の依頼の背景にはあったように思われます。

何はともあれ、プロジェクトリーダー未経験のひよっこリーダーの誕生です。
以前、自身の担当タイトルで表示検証業務の効率化を経験していた僕は「効率化の経験はあるし、今回もなんとかなるでしょ！」と安直に考えていました。
## 初めての「プロジェクト」
プロジェクト初心者だった僕は、[部長](https://qiita.com/shumai-hime)にオススメされた[PMBOK](https://www.shuwasystem.co.jp/book/9784798047164.html)（現在は品切れ中です）を読んでみました。
PMBOKとは、 **Project Management Body Of Knowledge** という言葉の頭文字を取ったもので、「プロジェクトマネジメントの知識体系」について書かれた本です。
僕が読んだPMBOKは、ソフトウェア開発を例に書かれたものでしたが、どのプロジェクトにも共通するような、コミュニケーション・役割・進捗管理など、参考になる情報も多く得られました。
PMBOKを読むだけではなく、先輩社員の **M本さん** へもアドバイスを求めました。
M本さんからは「プロジェクトに関わる各種データは、使わないと思っても集計してグラフ化しておくと後々便利」「一人でやり過ぎずに、メンバー全体へ仕事を振っていくのも重要」という超ありがたいアドバイスをいただきました。このアドバイスは本当にその通りでした。
## 着手
まずやらなければならない事を一通り書き出してみて、いろいろと着手してみました。
下記はその一部です。

- [x]  **業務状況の把握** 
協力会社へ業務詳細のヒアリングを行い、 **何にどのぐらいの工数を掛けているのか** を把握しました。
検証フローは細かく分けるとたくさんあるのですが、調査を進めると、 **検証の実施とそれに関わる管理** が工数の大半を占めていました。
上記から「 **検証を効率化** する事で、それに付随した **管理工数も削減** できるだろう」と狙いを定めました。
　
- [x]  **検証業務の課題点の洗い出し** 
そのほかにも調査を進めていくと、少しずつ課題が見えてきました。
・見なくても問題ない検証範囲まで検証していて、過剰品質になっていそう
・上記に伴い、検証の管理工数も増大していそう
長期運用タイトルが増える中で、各タイトルの仕様変更に合わせて、品質優先で検証範囲が長年にかけて少しずつ拡大されていった結果、上記のような状態になってしまっていました。
上記が課題の全てではありませんでしたが、主に効率化すべき課題として目を付けました。
　
- [x]  **効率化手段の検討** 
以前、自身の担当タイトルで行った表示検証の効率化を参考に手段を検討しました。
後述しますが、結果的にはこれはあまり参考にはなりませんでした。
　
- [x]  **計画の作成** 
いつまでに何をする必要があるのかを洗い出し、ロードマップやWBSを作成しました。
今回は、10月に10%の効率化、11月に15%の効率化、12月に20%の効率化、と段階的な目標を設定し、それに沿って計画を作成しました。
　
- [x]  **プロジェクトのゴールについてマネージャーとすり合わせ** 
作成した計画をマネージャーとすり合わせると、「本当に20%いけるの？」と質問をされ、僕は固まってしまいました。
「え、いけるかどうかじゃなくて、それを目指してやる物じゃないんですか？」と回答しましたが、「それだとプロジェクトの意味がないよ。ちゃんと現実的に20%に到達できるかを考えて、その上でゴールをセットしなきゃ」との返答でした。 **まさにその通りです。** 
マネージャーからのフィードバックをもとに、改めて過去の外注費の傾向などを綿密に調査し直した結果、「12月時点での20%効率化は無理があるのでは」という結論に至り、上期（2024年7月～12月）に15%、下期（2025年1月～6月）に5%の、通期で20%の効率化へゴールを修正しました。
また、効率化の対象は「2024年12月に協力会社へお支払いする想定の外注費用」である事もここですり合わせました。
## キックオフ
関係者を集めてキックオフミーティングを実施しました。
キックオフで共有した内容は主に下記です。

- プロジェクトの目的
  - 表示検証業務の20%効率化
　
- 計画
  - ロードマップ・WBSの展開
　
- メンバー・役割
  - オーナー（リスクを伴う意思決定）：さんしさん
  - リーダー（全般の意思決定・進行管理）：kuniyosh1
  - メインメンバー（担当プロダクトの効率化実施）：M本さん、Y崎さん、O黒さん
　
- 効率化の担当タイトル
  - タイトルＡ：M本さん
  - タイトルＢ：Y崎さん
  - タイトルＣ：O黒さん
　
- 問題～対策
  - 問題
    - 表示検証業務が肥大化し、過剰品質/過剰工数になっているものがある
      - 費用対効果が悪く事業にネガティブインパクトを与えている
  - 課題
    - 適正品質/適正工数に最適化する
      - それによってコスト改善をする
  - 原因
    - 表示検証の外注体制を構築してから約7年という月日が流れ、品質優先で手厚くなっている部分や、各ゲームの機能追加に伴って追加された作業などが多数あり、年月とともに過剰品質になっていた
  - 対策
    - 過剰品質/過剰工数の棚卸し・最適化
      - 検証対象の整理
        - 検証すべき「対象」は適切か調査し、最適化する
      - 業務フローの整理
        - 管理業務や検証の「手段」は適切か調査し、最適化する
      - 管理体制の整理
        - 表示検証の「組織規模」は適切か調査し、最適化する
## 効率化の進行
早速効率化を進めようと「僕が考えてきた最強の効率化手段」をメンバーに展開してすり合わせを行ったところ、「その効率化の観点はこのタイトルでは難しいかも」など、タイトルごとに様々な齟齬が発生してしまいました。
理由としては、検証対象や仕様書の作りが違うなど、タイトルごとの微妙な差分を考慮できていなかった点にあります。
改めて、各タイトルに合わせた効率化手段の検討を行い、なんとか効率化に着手しはじめる事ができ、順調に進みはじめました。
また、検証業務の効率化の他にも複数の課題を解決していきました。
以下で主な取り組みを紹介します。
- [x] **検証業務の最適化** 
主に検証対象の調査を行い、検証範囲を縮小しても不当表示リスクが小さい検証箇所を削減する事で、検証工数を削減しました。
　
- [x] **管理体制の最適化** 
プロジェクトの開始前は、業務が肥大化してしまっていた事から、リーダー業務を行えるメンバーの増員が必要な見込みでした。
それに対して、検証チームの管理者/リーダー/テスターの役割をそれぞれ精査し、本来の役割に再配置したことで、管理者/リーダーの工数を確保し、増員をする事なく体制を維持する事ができました。
　
- [x] **アサインの最適化** 
弊社から協力会社へは、翌週の検証規模に合わせてた業務発注（弊社ではアサインと呼びます）を毎週行っていましたが、管理業務の見直しの一環で、アサイン方法も見直しを行い、これまでよりもスリム化されたアサインが可能になりました。
# 進捗と学び
## 進捗
具体的に削減できた外注費用はお見せできませんが、どのような進捗で上期の効率化が進んだのかは下記グラフの通りです。
![タイトルなし.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3947760/ed80b0a7-fcb1-e281-f440-7d86239a32eb.png)
記事を作成している12月中旬時点では **14.16%の効率化** で、 **目標達成率は94.4％** という進捗です。
12月の目標にはまだ少し足りていませんが、 **上期トータルでは目標に対して130.9%の達成率** という点はポジティブに感じています。
## 学び
プロジェクトを通して多くの学びを得ましたが、特に下記をお伝えしたいです。

:::note
 **計画が8割** 
プロジェクトに着手をし始めた頃は、計画を練るために、調べる事や考える事が雑多にあり、膨大な情報を整理して計画に落とし込むのに非常に手間取りました。
その分、効率化が具体的に進行しはじめてからは、追加の調査などはほぼ発生せず、スムーズに進捗した気がします（担当メンバーの皆さんがシゴデキだったという点も非常に大きいですが）
もちろん全て計画通りという訳にはいかないですが、 **時間をかけて計画を作り込む事で、後の進行が楽になる** という事を実感しました。
:::
:::note
 **一人で考えすぎない** 
これはM本さんにアドバイスを受けて、意識していても僕は失敗してしまいました。
「自分がプロジェクトリーダーなんだから、全部考えなければ」となってしまう場面がたびたびあり、そのせいでプロジェクトの進行が遅れる、というシーンもあったように思います。本当に良くなかったです。
何事も一人で考えこまずに **周囲に相談する事で、簡単に解決できる** かも知れません。
:::
:::note
 **仕事の任せ方** 
これはプロジェクトマネジメントとは直接関係のない気づきですが、マネージャーのさんしさんとのコミュニケーションで感じた事を紹介したいです。
リーダー任命に伴い、さんしさんへ相談をする機会が以前よりも増えましたが、さんしさんは僕からの相談にあえて答えは出さずに、僕に考えさせる機会を与えてくれていたような気がします。
プロジェクトのゴールを再設定する際のやり取りも、そのように解釈しています。
 **「考えさせる」というのは、人材マネジメント上では非常に重要** だと感じました。
:::
# まとめ
プロジェクトを通して、周囲の方々と意見交換をしながら過ごした半年は非常に有意義でしたし、一人では成し得ないような成果がでた事が素直に嬉しかったです。
 **おじさん、レベルアップを果たせた** と言えそうです。
今回の学びを活かして、今後も品質とコストのバランスを意識して、素晴らしいゲーム体験の提供に尽力していきたいと思います。
それでは、皆さん良いクリスマスを！