GENDAの新人PdMが入社後の半年間を振り返る
自己紹介
こんにちは、GENDAプロダクトマーケティング部の小野寺です。新人PdMとしてGENDAで働き始めて半年が経過したので、今日は入社してからこれまで、どんな仕事をしてきたのかを振り返りたいと思います。
入社までの経緯
私はグループ会社である株式会社GENDA GiGO Entertainment（以下、GGE）から転籍しました。GGEでは情報システム部門で人事システムの保守運用と要件定義、同部門が推進する各種プロジェクトのPjM（プロジェクトマネージャー）を担当していました。PdMに興味を持ったきっかけは、GiGO NAVIという業務支援ツール（※ 以前掲載した原田の記事でも紹介しております。）で初めてPdMの方と一緒に仕事をしたことでした。興味を持った理由は下記2点です。
①ひとつのプロダクトに関わる期間が長い
PjMの場合、プロダクトに関わることのできる期間はプロジェクト期間のみです。そのため、プロジェクト完了後のプロダクト方針決定やロードマップの作成には関わることができません。また、保守運用を担当したこともありましたが、PdMほど主体性を持ってプロダクトに関わることはできませんでした。そのため、期間に限りなくプロダクトに関わることができ、方針やロードマップを決定できる裁量があるPdMに興味を持ちました。
②プロダクトに対するPjMとの考え方の違い
私は先述したGiGO NAVIにPjMとして関わっていました。GiGO NAVIは業務システムだったため「業務の継続性」と「コストカット」をプロジェクトの目的に設定してプロジェクトを推進していました。一方PdMはそれらに加えて、エンドユーザーからアンケートをとり、彼らが利用しやすいようにするにはどうしたらいいかを優先事項として考えているように見えました。業務システムでコストカットに直結しないユーザビリティを考慮するという考え方に触れたのが初めてで、興味深く感じました。
転籍した時の雰囲気
一番最初に、上長との1on1で転籍の提案を受けました。この時、ちょうどPdMの方と一緒に仕事を始め、PdMの業務に興味を持ち始めた頃でした。やってみたい職種だったのですが、当時GGEにはPdMが存在せず社内の需要も高くはありませんでした。GENDAにはPdMチームがあったので、転籍を機にPdMに転向したい旨を伝えたところ、転籍後はPdMチームに配属されることになりました。こうして、PdMという職種に興味を持っていたタイミングで、たまたま転籍の話をいただき、晴れて新人PdMとしてGENDAで働くことになりました。
入社してからこれまで
GENDAに転籍してから半年間に関わったプロダクトと、実施した業務をまとめると以下の通りです。この表をもとに、半年間の業務の詳細やジョインの経緯を振り返っていきます。
GiGO ONLINE CRANE
新人PdMとして、まず最初にアサインされたのはGiGO ONLINE CRANE（以下、GOC）のADMINシステムでした。ADMINシステムとは、オンラインクレーンゲーム（以下、オンクレ）の業務システムのことで、ユーザーからは見ることができません。このシステムを使って現場の業務担当者はオンクレに関するオペレーションを行います。
ADMINシステムの改修
アサイン後に任されたのは、ADMINシステムの改修でした。ここで、情シス時代の経験を活かすことができました。情シス時代に担当していたシステムは全て業務システムだったため、導入や改修時にはまず必ずASISとTOBEの業務フローを作っていました。業務フローを作る目的は下記の通り2点です。
①業務の流れが見えるのでコストがかかっているところがわかる
②他部署や他システムとの繋がりが見えるので検討内容に抜け漏れがなくなる
これらは業務システムである以上GOCのADMINシステムにも共通していることだったため、まずはアサイン時点で存在していなかった定常業務フローを作ることにしました。
業務フローの作成
業務フローを作る時は全体→詳細→さらに詳細と深掘りしていく必要があります。GOC業務はまだ社内で整理が進んでおらず、かつ私にも知見が全くなかったため、いきなり全体の業務フローを作成しては後々抜け漏れが発生すると考えました。そこで手始めに業務の全体像を知るために業務同士の関連図を作成しました。この関連図は、狙い通りADMINシステム上で実施する業務と、それに関連する業務を特定することに役立ちました。
その後、業務関連図から業務フロー化する必要がある業務を特定し、叩き台を作り、それぞれの業務担当者からヒアリングを行いました。まずは店長やチーフクラスで業務全体に詳しい人→業務担当者クラスで自身の担当業務に詳しい人の順でヒアリングを行い、叩き台作成時に疑問に思ったことや矛盾点を埋めていきました。ヒアリングを行っている期間に実際に現場へ足を運び、文字や言葉だけでは理解できなかった部分を目で見てさらに埋めていきました。
現在はこの時に作成した業務フローをもとにADMINシステムの改修ロードマップを作成中です。
ユーザー側の施策実現のために実施するADMINシステムの改修
ADMINシステムの改修と並行して依頼されていたのが、ユーザー側画面の施策実施時に必要なADMINシステム改修のPRD作成でした。ユーザー側画面はユーザーがクレーンゲームをプレイする画面のことであり、施策を実施するために業務担当者によるオペレーションが必要なものもあります。その場合はADMINシステムも改修が必要になり、そのPRDを作成するのが私の担当でした。ここではPjM経験が活きたので、どう活きたのかを下記に記載します。
ADMINシステム側のPRDの作成方法
目的がぶれないよう、ユーザー側の施策を要求事項として、それを達成できるようADMIN側の要件を固めていくことを意識しました。かかる開発工数の多寡ごとに複数案を出し、運用担当者にヒアリングを重ねながらどのような要件にするかを決めています。要件定義時に軸としていることは下記の3つです。
①ユーザー側の施策内容が達成されること
②改修後の運用フローが現場で運用できること
③開発工数が必要最低限であること
この3軸は、PjM時にプロジェクトの方針を決定する際、複数の案を「Quality（品質）」「Cost（コスト）」「Delivery（納期）」で比較し検討していた方法を流用しました。
PRD作成時は下記のように置き換えています
Quality＝①施策内容が達成されること
Cost＝②改修後の運用フローが現場で運用できること
Delivery＝③開発工数が必要最低限であること
GOCはtoCのプロダクトであるため②の観点が抜け落ちがちなのですが、②をおざなりにするとコストの増加など別の問題を引き起こす可能性があるので特に注意を払っています。
コミュニケーション方法
要件定義をする上で、先述した3つの軸はそれぞれ異なる人物が判断します。
①施策内容が達成されること＝ユーザー側のPdM
②改修後の運用フローが現場で運用できること＝運用チーム
③開発工数が必要最低限であること＝エンジニア
そのため、さまざまな立場のメンバーと細かくコミュニケーションをとる必要があり、アサイン当初は大変でした。GOCではプロジェクトのようにメンバー間で共通の目的や期限が存在するわけではないため、これまでの経験の中で最も相手の立場に立って想像することが求められました。
特に気を付けているのは、②と③のコミュニケーションです。
②のヒアリングでは、現場の状況理解が人によって異なるため、一人だけでなく複数人にヒアリングするよう心がけています。
③のヒアリングでは、こちらが何をしたいのかをエンジニアに正確に伝えるよう心がけています。
fanfancy+ with GiGO
GOCと並行して2024年4月下旬〜6月中旬まで担当していたプロダクトがfanfancy+ with GiGO会員アプリ（以下、ffアプリ）です。こちらは推し活専門ショップfanfancy+ with GiGO店舗で利用できる会員アプリです。
ジョインの経緯
ffアプリは元々GENDAのインターン生が中心となって1年ほど開発していたアプリで、そのことはGGE時代から知っていました。
可愛いものや推し活が好きだった私は、プロダクトのデザインがピンク色で可愛らしいffアプリのリリースを楽しみにしていました。上長と雑談していた時に、上記発言をしたところ、「PdMが不在なのでやってみるか」と言われ、ジョインすることになりました。
リリースまでにやったこと
ジョイン時、ffアプリは、何度もリリースの延期を繰り返し、ファーストリリースが当初の予定よりも大幅に遅延している状態でした。
会員アプリというプロダクトの性質上、まずは世の中にリリースし、ユーザーの様子をみないことには改善施策を検討することはできないと考え、ファーストリリースすることをプロダクトの最優先事項に設定しました。
結論から言うと、ffアプリではPjMの経験をフル活用しました。
マスタースケジュールの作成
最優先事項が決定した後は、リリースの延期要因を分析しました。要因は以下の2点でした。
①マスタースケジュールが存在せず、根拠がない状態でリリース日を決めていた
②タスクに優先順位がついていないため、リリース判定基準が曖昧な状態になっていた
そこで、まずはタスクの洗い出しと必要工数をヒアリングし、一般的なマスタースケジュールを作成してリリース日を6月17日に決定しました。
マスタースケジュールの作成と並行して、タスクに優先順位をつけるためにリリース判定基準を作成しました。
ffアプリファーストリリース判定基準
ファーストリリースの判定基準は以下の通りに定めました。
各機能およびUIが、以下の基準の「効果」を満たす状態になっていること
効果＝タスクを達成できたかどうか（想定している仕様通りに動作するか）
効率＝タスク遂行において、ユーザーを戸惑わせたり無駄な操作をさせたりしなかったか
満足度＝ユーザーが不満や不安を感じなかったか
「ユーザビリティ」を基準にした理由は、当時ffアプリには要件定義に抜け漏れがあったためです。QA段階でアプリの仕様を決めていたため、QAフェーズでのタスク発生数が非常に多く、終わりが見えない状態でした。そのため、判定基準にある通りユーザーが不満を感じない最低限の状態が成立すればファーストリリースすることにしました。ファーストリリースまでに対応しない項目は、後のアプリ改修で少しずつ対応し、対応するものについても、正しい仕様が定まっていない場合は実装まで工数が少ない方法を取ることにしていました。
その結果、合計3回のリリース判定会議を経て、予定したリリース日に無事にリリースすることができました。
ファーストリリース直前のトラブル
リリース直前にプレスリリース内容を精査している段階で、広報からある機能について記事内に記載しても問題ないかという質問がありました。結論として、その機能は法的には違法ではないものの、リスクがある可能性があるものでした。
PdMとして3ヶ月目の私は、その機能に法的なリスクを含む可能性があることを認識しておらず、質問を受けて急いで法務確認を行いました。そして、リスク回避のための運用フローを検討し、運用担当者への告知を行いました。プロダクトと法律の関係を考慮するのはPdMならではの経験でした。企業のプロダクトとして提供する以上、法律関係には特に注意が必要であるため、このトラブルを今後に活かしていこうと思います。
リリース後の話
ffアプリはファーストリリースまでの期間、助っ人として参加していましたが、ファーストリリース後は従来通りプロダクトのマネジメントをインターン生が行うことになりました。約2ヶ月間という短い期間でしたが、アプリのファーストリリースに携わることができ、とても勉強になりました。
GiGO Mall Online
ジョインの経緯
ffアプリから離脱後、現在にかけてGiGO Mall Online（以下、GMO）というGGEのECサイトに携わっています。ジョインのきっかけは、GMO改修に関する雑談にたまたま居合わせたことでした。改修のためにまずは業務分析を行う必要があるとのことで、GOCで業務フローを作成していた私に、「やってみないか」と声がかかりました。GOCでの知見が活かせそうだったことと、ECサイトのPdMが楽しそうだと感じたため、ジョインすることにしました。
元々TOBEの姿が決まっている改修だったので、ASISとTOBEの業務フローを作成し、そのギャップを埋めるためにどのような改修が必要かを現在検討している最中です。
半年やってみて思ったこと
最後に、半年間新人PdMとしてGENDAで働いて感じたことをまとめたいと思います。
PjMの経験とスキルはPdMで活きる
PjM時代に培ったプロジェクト管理のスキルは、PdMの業務でも大いに活用することができました。PjMの仕事は「限られたリソースで目的を達成するために周囲の環境を整備すること」だと、私は考えています。PdMとしてプロダクトの施策やロードマップを進める際の、明確な目的を持って目的達成を目指すという点はプロジェクトマネジメントと似ています。そのため、進捗管理とタスクの管理はプロダクトマネジメントでも同様に大切なものだとこの半年間で感じました。
新人でも裁量を持って仕事ができる環境
半年間で関わったプロダクトは3つあり、その中でプロダクトの改修方針やリリースの基準は全て私の裁量で決めて実行してきました。迷った時は上長に相談することもありましたが、誰かの指示を受けてその通りにしたり、誰かの承認がないからプロダクトについて決めることができないという状況はありませんでした。新人でも「新人」という枷がない状態で仕事ができた半年間でした。
やりたいことがあれば手を挙げることができる社風
ffアプリとGMOのジョインの経緯の通り、GENDAは主体的に行動する社員に対して非常に寛大で、その結果として多くのやりたいことが実現できます。新人にも関わらず、半年という短期間で3つのプロダクトのPdMを経験できたのは、この社風にあると考えています。
アザラシのように
突然ですがズキンアザラシという動物は、生まれてから親離れまでの期間がたった4日と、哺乳類の中で授乳期間が最短だそうです。赤ちゃんはたった4日間で、過酷な野生環境で独り立ちできるほどの成長を遂げるということですね。我々PdMチームはアザラシのような驚異的なスピードで成長していこう、ということでnoteのPdM LIBRARYのサムネイル画像にアザラシを採用しています。
ですので、私はまだまだPdMとして新人ですが、これからもGENDAでさまざまな経験を積みアザラシのように成長していきたいと思います。もしGENDAに興味がある方は、ぜひ採用ページをご覧ください🦭