こんにちは、株式会社HRBrainでエンジニアをしているしっぽくん（@shippo_kunn）です。
この記事はHRBrainのAdvent Calenderの3日目の記事です。
最近はいくつかのプロダクトを跨いだチームで開発をしています。日頃の仕事内容については先日インタビュー記事を書いていただいたので興味ある方は下記を参照してください。
はじめに
今回は先月PjM（Project Manager）にトライしてみた時の反省点や良かったことを箇条書きでまとめてみました。手前味噌ではありますが何かの参考になれば幸いです。
個人の振り返りに基づいた記事であるという前提の上でご覧ください。
この記事の対象者
- プロジェクトを初めて管理する人
前提
弊社では下記のツールを用いて開発をしています。適宜ご自身の環境に読み替えてください。
- JIRA: チケット管理
- GitHub: コード管理
- Notion: 仕様やドキュメント管理
- Figma: デザイン管理
- Slack: チャットツール
- Autify: E2Eテストツール
プロジェクト開始
事前に危険性を洗い出すこと
- 有識者とプロジェクトについて知見を交わし、デグレ対応にどのくらい時間が必要なのかを認識合わせしておく
- キックオフミーティングでは仕様の確認だけでなく、変更する箇所の危険性も洗い出しておくべき
- この場にPdM（Product Manager）とQAエンジニア（Quality Assurance）も同席すること
- エンジニアは必須
ドキュメントに不備がないか確認すること
- Product Backlogや仕様書、Figmaがあるかどうかを確認する
- ある場合はJIRAのエピックチケットにリンク付けすること
- 開発をする上で常に確認できるようにするため
達成条件などは最初に確認すること
- 最低限下記は欲しい
- やりたいこと（要求定義があればそちらで代替する）
- ユースケース（こちらも同様）
- 対応しない場合のリスク
- 完了条件
- 危険性
- リリース目標
- 着手開始
- 開発期間
- QA期間
- リリース目標
- リリース締め切り（ここがデッドライン）
- 関連資料
- 撤退条件
プロジェクト進行中
前提条件が変わったらアサイン・スケジュール含め再検討する場を設けること
- 前提条件が変わった例
- 担当者が急遽抜けてしまった
- 事前に把握していなかった危険性が見つかった
- 仕様が大きく変更した
- 担当者が変わった場合などは、難易度や危険性含めアサインされたメンバーが対応できるものか、サポートメンバーが必要なのかを検討すること
- PdMや関係者に前提条件が変わったことをエスカレーションすること
- 危険性が新たに見つかった場合は振り返りなどでなぜ事前に見つからなかったのかを考えること
アサインしたタスクの責任が取れなくなった人にはエビデンスを残してもらうこと
- 責任＝リリース後に保守作業ができる
- 副業などを対象としている（また退職間近のメンバー）
- エビデンス＝事前に挙げた危険性の考慮や完了条件を満たしているものを項目として挙げ、それら項目が満たしたのかを残してもらう
- フロントエンドの場合はスクリーンショット
- バックエンドの場合はAPIレスポンスが望ましい
- ただし手作業だと手順を間違える可能性があるため、自動化が望ましい
- クエリ叩くだけなどのインテグレーションテストの粒度まで落とす等の対応が理想
- ゴールデンテスト：実行してその時の結果差分が想定通りかどうかを見る
- メリット：テストを丸々実装する必要がない、デグレの心配がない、autifyよりも広い範囲をカバーできる、ランニング中の工数が減る
- デメリット：ロールとかを対応しなきゃいけない、実装は多少必要なのでイニシャルコストはかかる
- 参考： https://swet.dena.com/entry/2020/03/16/173000
スケジュールについて温度感の足並みを揃えること
- 足並みを揃えることでエスカレーションの判断が特定メンバーに依存しなくなる
- デッドラインはどこで、現在はどこまで進んでいるのかを常に認識しておくこと
- 把握するためにStoryPointなどを振り分け全体の工数感を知ることは大切
- タスクの細分化や不確定要素の高いものを優先的に潰すことで確実性を高める
リリース前後
リリースできそうな状態になったら改めてお触り会をすること
- 触っていくことでどんな機能を作ったのかを再確認する
- エンジニア以外の人にも触れてもらうことで違う視点の意見を取り入れる
- 事前準備はしっかりすること
- 触れる環境
- アクセス方法
- 事前のデータ
- ここでリリース前に仕様が違う場合はリリースブロック要素として対応すること
プロジェクトが完了したらお片付けすること
- プロダクトの仕様書がある場合はマージすること
- FigmaやNotion、必要であればGitHubも
- 振り返りの場を設け、ドキュメントを残すこと
- 難航した場合は次のプロジェクトに活かすため
- 順調に進んだ場合は型化をするため
リリース後には利用率の経過を定期的にウォッチすること
- そのためにはログを仕込むことを忘れないこと
- 機能の利用率とプロダクト自体の利用率の変化をウォッチすることで、プロジェクト当初に考えていた顧客への影響度を測定することが可能
- 影響度合いが大きい場合は今後のリファクタリングや追加実装を考慮に入れる判断材料になる
記事の最後に
1つ1つは当たり前のことですが、1つ1つを丁寧にやっていくことで良いプロダクト開発になっていくと思います。
PjMだけでなく開発メンバーも理解しておくことで円滑なプロジェクト開発ができるはずです。
また、HRBrainでは引き続き仲間を募集しておりますので最新の募集状況などは下記からご確認ください。