リリース期限に間に合わせるためのPJTマネジメント 4つの学び

こんにちは。
この記事はユアマイスター Advent Calendar 2021年の7日目の記事になります。

今回は、「自宅で作れる贅沢ごはん！おすすめ3選！」みたいなテーマで元々書こうとしていましたが、3周回って、タイトルにあるテーマでまとめました。

このテーマで書こうと思った経緯

直近、参画していたPJTで、タイトなスケジュールの中でリリースしきることを体験し、上司・先輩から多くの学びを得ました。これまで関わったPJTや自分が担当していた開発案件では、何かしらの理由でリリースが遅れることが大半であっため、この学びを言語化する、また他の方にもここで得た学びを共有したいと思い、当記事を書いています。

仕様設計・エンジニア依頼時

× こういう形で実装したいので、この通りお願いします。
◯こういう形で実装したいが、時間がかかりそうな箇所があれば教えてください。妥協できるポイントは妥協してスピードを早めたいです。

「言われた通りに作ってしまうかもしれないから、気をつけて欲しい」

仕様・UIを固めてエンジニアさんに依頼する際に、そのまま実装してもらおうとすると、ビジネス上そこまで重要度が高くなくても、実装上はすごく時間がかかるというポイントを見過ごす可能性があります。
例)デザインの綺麗さ、凝ったUIなど。

期限がタイトな場合は、特にエンジニアさんとコミュニケーションをとって、短期間で重要度が高い部分をカバーできる実装方法を考えなければいけません。

エンジニア実装中

×  〇〇日まででお願いしているから、それまで待とう。
◯ 定期的に進捗を確認しよう。進捗が悪いならば、サポートをお願いしたり、要件を変えたりとフォローをしよう。

遅延が発生する際は、後になればなるほど、取り返しがつかなくなります。各自の進捗を1箇所で見えるようにし、日次で進捗通りにいっているかを確認することで、期限通りにリリースできる確率が高まります。

後発的な仕様変更の検討時

仕様漏れで新要件が出てきた場合

新しい要件が出てきて、間に合わない..
◯必要な部分だけ入れて、次のフェーズで実装しよう

開発する中で仕様漏れなどが発覚したときに、それら全てを100%解決しようとすると、要件はどんどん膨らんでいき、期限に間に合わなくなります。100%ではなく、最低限耐えられる方法は意外とあるので、ちゃんと一回考えてスコープを決定。拾いきれなかったものは、後対応で拾う方針にすることで、後から後から要件が増えていくことを防げます。

既存仕様の変更を検討する場合

 改めて考えるとこっちの方が良い。変更を検討しよう。
◯一度FIXしたもので、重要な部分でもないなら、開発スピードを優先する。

「俺たちが、彼ら（エンジニア）の手を止めてはいけない。」

後から良いと思った変更内容だとしても、重要度が高くなく、その検討に時間がかかり、エンジニアの手を止めてしまうなら、次のフェーズで拾うことを考えます。

終わりに

全体的に言えることは、リリースまでにやること・やらないことを常に分けることを意識し、要件を膨らませない工夫が大事だと思いました。

学んだだけではなく、同じような案件がきた時のために、日々意識して行動を変えていかなければと思います。
ここまで読んでいただき、ありがとうございました！