こんにちは
Relicでフロントエンドエンジニアをしていました高橋です。
これまでフロントエンドエンジニアとしてプロダクト開発に関わってきましたが、改めて自分のなりたい像を考え、事業を作れる人材になるためにより事業を推進するポジションにつきたいと感じ、PMを目指しました。
ということで、様々な方に相談した結果まずはPMとして経験を積む必要があるのでweb制作やLPなどのPMから挑戦させていただくことになりました。
ちなみに今回、私がPMとしての役割は以下になります。
・QCDを保ってリリースする
・アサインを確保する
・スケジュール通りリリースする
これまで経験したPMの基本の「キ」があり、型があると思い、整理する意味も込めて記事を作成しました。
今、整理すると当たり前のことですが、いざ業務をしてみるとPMの型のどの段階にして次、何をしないといけないのかがわからなくなるのでやはり基本は重要だと感じました。
PMの型
物事にはなんでも型、流れがあり、PMも型があると私は思います。
エンジニアの場合でも何も考えずにとりあえず、手を動かしてコードを書くと、「あれ、このコンポーネント使いまわせるくない？」「あれ、これhooksにした方がいいくない？」なんてことが起きてリファクタ祭り開催になりますよね。（考えながら実装してもリファクタは起きると思うので、ある程度は仕方ないと思いますが…）
なので、PMも型があり、その基本の型に沿ってプロジェクトを進めることでプロジェクトがスケジュール通りに進むと思います。
結論からになりますが、私が学んで思ったPMの型は以下になると思います。
①wbsを確認
②概算実装工数を出す
③アサインを決める
④進捗確認（デザイン、開発）
⑤確認/検証
⑥リリース
①wbsを確認
そもそもWF（ワイヤーフレーム）がいつFixして、デザインがいつFixして、実装がいつ着手できて、いつリリースするのか？というプロジェクト全体のスケジュールを把握します。
wbsが明確に決まっていても、そもそもエンジニアの工数が足りないので、プロダクトを作りきれないっていうこともあるので、スケジュール通りに開発を進めることができるのかを確認するためにwbsを把握することはプロジェクトを進める上での初めの一歩になります。
また社内リソースを把握していて、共有してもらったwbsだとリリースできないことがわかっているのであればwbsを共有していただいた時点で再度スケジュールを検討してもらうこともできます。
また各案件のwbsを記載してまとめるとスプレットシートに、まとめると情報が分散しなくて便利です。
②概算実装工数を算出する
wbsを確認して問題なければ、いきなりデザインをするのではなく、まずWFを作成すると思います。
そして、WFを作成した時点でどんなプロダクトになるのかの全体像がなんとなくイメージできるので、概算の実装工数を算出します。
概算の実装工数を算出することで1人のエンジニアが何人日（1人日 = 8時間）で実装完了することができるのかを把握することができます。
また概算の実装工数を出す際に、「あ、レビュー後修正の時間を出し忘れていた！」という考慮漏れがないように実装工数チェックシートを作成しました。
まだまだエンジニアとしてもPMとしても経験が浅いので、このようなチェックシートを使ってできるだけ精緻な実装工数を出すようにしました。
またプロダクトの改修やある程度経験があるエンジニアがいれば、概算実装工数をレビューしていただくのもいいと思います。
算出した概算の実装工数に対して内訳を添えて、何にどれくらいの時間がかかりそうかを共有することで、自分の概算実装工数の見積もりとすり合わせすることができるので、どんどん精緻になっていきます。
③アサインを決める
①、②のステップで、どれくらいの期間エンジニアを確保しないといけないかがわかりました。
Relicでは、プロダクトディスカバリー事業部でwebサイトやLPなどの制作案件に関わるエンジニアが基本的に決まっているのでそのエンジニアの工数が余っているのかを確認します。
もし余っていないようだったら、外部に相談・連絡をしてリソースを確保します。
④進捗確認
進捗確認とざっくり書いていますが、「デザイン」と「開発」の進捗確認です。
③でアサインを決めてエンジニアの工数を確保したが、デザインがスケジュール通り来ないってこともなくはないです。
世界のエンジニアで暇な方なんていないと思いますので、次々と開発を進めないといけない案件があるわけなので、スケジュール通りにデザインがくるか進捗を確認する必要があります。
もし、デザインが進捗通りに来ない場合は、他の案件に一時的に入ってもらったり、デザインが遅れたことでリリースを遅らすなどリカバリー対応が必要になってきます。
またデザインがスケジュール通りに来て、エンジニアが実装を着手しても思っているよりも「〇〇の機能実装が重い…」なんてことが起きるので、その際もリカバリーを考え、エンジニアのアサインを増やしたり、タスク分担を変えたりなどリカバリー対応を行います。
こうやって、日に日に変わるプロジェクトの状況によって適宜相談して最適な形で進めていくのがPMの仕事であると感じました。
⑤確認/検証
実装が完了すれば、確認/検証を実施して世の中にプロダクトとして出せる品質が担保されているのかをチェックします。
このステップは、エンジニアで完結したり、外部の方にテストしていただいたりするので一概にPMの仕事とは言えないですが、今回私は確認/検証を行ったので紹介させていただきます。
テスト項目をまとめたスプレットシートを作成し確認/検証を実施します。
確認/検証をする中で、修正箇所に関してもリリースできないような重大な修正箇所があったり、プロダクトにあまり影響がない軽微な修正があると思います。もちろんリリースまでに全ての修正が完了し完璧な状態でリリースできれば最高ですが、そうもいかない時があるのでその場合はどの修正を行うのか、修正が大きくリリースに間に合わないのでリリースを遅らすなど最後の判断もPMの仕事だと思います。
⑥リリース
最後にプロダクトのリリースを行います。
リリース作業自体は、おそらくエンジニアが実施していただけるだろうと思っていますがリリース後に再度確認/検証を実施し、修正箇所があればすぐに修正したりどうにもすぐに治せそうにない場合は切り戻しを行います。
確認/検証で問題なければリリース完了になります。
以上が、私がPMの型となる基本の「キ」の流れだと思います。
まとめ
今回は本当にPMの基本の「キ」になる部分になると思うので、これからPMをやってみようと思う方や、すでにPMをされている方がそうだった！と再確認する気かになれば幸いです。
まだまだPMとしては半人前でさらにPLを理解し、アサインを決めれるようになっていきたいと考えています。
採用のお知らせ
株式会社Relicでは、エンジニア・デザイナーを積極的に採用中です。
またRelicでは、地方拠点がありますので、U・Iターンも大歓迎です！🙌
少しでもご興味がある方は、Relic採用サイトからエントリーください！