🔰

QC → PM を目指す人に捧ぐ新米PMのお話

に公開

はじめに

こんにちは。jinjer の仲嵩です 🙋‍♀️
2024年 5月からジンジャーAPIのプロジェクトマネージャー(以下、PM)を担当させていただいています。その前は QC としてプロダクトに関わっており、jinjer では QC -> PM のキャリアパスも選択することができます。
ジンジャーAPI の PM デビュー時のギャップや失敗、そして QC 業務とのリンクを交えつつお話させていただきます。

日本一の開発組織を目指している jinjer のジンジャーAPI は PO(PdM)、PM、SE、SRE という体制で開発しています。

ジンジャーAPI PMのお仕事

スクラムイベントの運営
SMとしての役割もあり、開発チームとのデイリースクラム、スプリントプランニングやリファインメント、スプリントレビューなど開催しファシリテートをおこないます。

チケット単位のアサインと優先度調整
jinjer では 2週間スプリントを採用しているプロダクトが多いです。スプリントプランニング決めたことがそのまま進むことは少なく、その都度スプリントバックログの優先度やアサイン調整をおこないます。

各プロダクトとの調整
田村さんの記事にもあったように、ジンジャーAPIは、人事労務や勤怠管理、給与など横断的に複数プロダクトのデータを扱います。そのため、それに応じて各プロダクトの PM や QC へ調整と情報収集をおこないます。

仕様とテスト観点レビュー
仕様書やテスト観点、エビデンスレビューや UAT をおこないます。レビューで PM が見逃したものは結果として課題となることも少なくありません。
QC のときは QC が品質管理の最後の砦だと思っていましたが、PM となった今でも変わらず最後の砦だと思い取り組んでいます。

課題分析と改善
主に開発や品質管理の観点で、レトロスペクティブやメトリクス※ から分析をおこなって改善活動につなげています。
どのプロダクトも品質については悩みの種で、そこに直接アプローチできるのは QC の経験があるこその強みだと感じています。
※メトリクスについては山田さんの記事をどうぞ

PMになったときのギャップ

1日に流れる情報量は10!?20倍!?

PMデビュー初日に感じた一番のギャップでした。
多くの情報がこれまで経験したことのないスピードで飛んできます。必要な情報や判断すべき情報の精査は慣れるまで一苦労でした 😅

自分が判断する立場である

QC だった当時は、QC チームで問題が発生したら解決案を PM や上司に相談ということがほとんどだったのに対し、当たり前ですが PM だとそれが逆の立場になるわけです。
頭ではわかっていることなのですが、判断すべき場面に遭遇して初めて「自分が決める立場」を自覚しましたし、同時に「判断するための準備」も必要だということに気づきました。

判断に迷う場合は、判断するための情報を引き出すことや、PMO や PdM へ相談・報告も重要になってきます。
QC のときから PM ならばどうするかという視座高く捉えられていたら、このギャップは低減できたと思います 🤔

PMとして失敗から得られたこと

問題が起きていることに気づきやすいようにする

コードフリーズ日に要件を満たす実装が不可であることが開発チームから報告を受けたことがありました。デイリーミーティングでは問題が発生していることを検知ができていないことが原因の一つでした。

この問題を事前検知するため、開発チームと共に以下の 4 つを心がけています。

  1. 親チケットからタスクを子チケット化(工数目安: 1-2日)して必要な作業を見える化
  2. 1のチケットをタイムラインで管理し、デイリーはこれをベースに確認する
  3. リリース判断をコードフリーズの 2営業日前におこなう
  4. デイリー前にメンバーはチケットステータスを最新化、PMは今日の確認ポイントを準備する

課題に気付けるようにする

余程のことがない限り課題がないチームはありません。課題がないまたは答えられないのは、課題があるかどうかを分析できていないということかもしれません。

また、課題に気づきネクストアクションを取ったら安心するのではなく、そのアクションは有効か、有効でない場合は別のアクションの必要可否を判断するためにも、経過観察が必要です。

PM デビューしたての頃は、なかなかこの活動ができず課題があるかどうかを分析できていませんでした。

課題に気づくために、PMとして以下のメトリクスを計測し、これを元に分析をおこなっています。jinjer の QC チームで行っている品質レポートや不具合分析スキルはここでも活きると考えています。

1、2 はプロダクト横断、3はジンジャーAPI独自のものです。

  1. ベロシティと LOC
  2. 検知タイミングごとの不具合数
  3. 不具合総数と内訳の推移

まとめ

SE から PM というのは良く耳にするキャリアパスですが、QC から PM のキャリアパスもこれからは増えていくと思います。
QC が PM になったら、品質管理に強い!という個性を持った PM になれるのではと考えています。

おわりに

jinjer では、「日本一の開発組織」を目指して一緒に奮闘してくれる仲間を募集しています。
今回の記事で少しでも jinjer に興味を持ってくださいましたらましたら、気軽にお問い合わせくださると嬉しいです 🌻

jinjerテックブログ

Discussion