学びは3つ
・まずはちゃんと人を集めるところから
・見積もり前に建てた予定日はhopeであってmustではない
・リリース判定は顧客通知の道具ではない
背景
・普段は5人で一つのプロダクトを持って開発している
・今回はインフラや組織基盤のチームなど垣根をまたいで開発していく
・インフラの知識が疎い中でのドメイン統合を自分が推進者で参画
1. まずはちゃんと人を集めるところから
プロダクトチームの自分と、稼働するメンバーを集めて要件と影響調査に必要な頭出しをしていた。普段のチームで最初に行うキックオフのように、PJT要件の読み合わせと会議体のすり合わせを行い、影響調査に進んでもらっていた。
前提として、弊社ではリリース判断資料というものがあり、若手がPJT推進をした際にもちゃんと品質を担保された状態で顧客に公開されるように、ドキュメンテーションとレビューの仕組みがある。
このリリース判断資料を作成するにあたり、EM（エンジニアリングマネージャー）とテックリード（判断資料のレビュワー）をちゃんと定義する必要があることがわかった。
チーム横断なので、そもそもEMをどこの主幹の人にするかから考えて決めた。
そのEMに相談する中で、テックリードが目線を合わせる場にいない問題を指摘された。
クオリティを担保するのにEMはあくまで最終的に確認する責任者であり、リリース判断資料のチェック項目に責任を持つのはテックリードである。
そのため、そもそもリリース判断をできないチーム体制となっていた。
PJTの始めに品質を担保してリリースしていくために誰がどういう役割なのかを定義し、目線を合わせておくことが重要だ。
2. 見積もり前に建てた予定日はhopeであってmustではない
この学びは、PJTの進め方についての誤認について。
自分の働く組織では3ヶ月ごとにOKRというフレームでチームの目標と達成したい結果を定義する。
今回のドメイン統合PJTは顧客通知を伴うもので、リリースの1ヶ月以上前に通知する必要がある。時間がない。そして目標を達成しなくてはならないという意識のあまり、見積もりもしていないタスクの目標日付をmustとして扱ってしまった。日付がそんな希望観測では、思い通りに進むわけもなく、ただ間に合わなさそうな焦燥感にかられるばかりだった。
最初にやるべきは、リリース判断に必要なステップ（マイルストーン）を置くことだった。
もし日付を置くにしても、それはあくまで希望観測だ。
このまま顧客に約束して出そうとするのはギャンブルと変わりない。
スケジューリングの前に必要なステップを並べよう。
3. リリース判断は顧客通知の道具ではない
この学びは、品質ガバナンスにおける目的の誤認について。
リリース判断はリリースできる水準にあるかを確認するためのプロセスがあるが、これをただの顧客通知の手続きとして扱っていた。
リリースの逆算スケジュールに追われる中、どこまでチェックできていればよいのかを確認しようという思考になっていた。その結果、リリース判定の一部を顧客通知で達成すればいいだろうという都合のよい思い込みをしていた。
だがよく考えてみれば、顧客通知を行うということは、いつリリースするかを約束することであり、自社の基準の品質でちゃんとデリバリーできるということを約束できる状態である必要がある。通知できる状態＝リリースできる状態であるべきだ。
その水準にないのに通知を出そうとするのは、品質保証の放棄に近い。
PJTは完了させることではなく、ちゃんと価値を安全で高品質な状態で提供するという前提で望まなければいけない。
まとめ
期限を意識しすぎると焦る。丁寧に調査と見積もりを行なっていくフェーズでは、期限への意識はよくない方向に進み得ることを痛感した。
今回でPJTの初期フェーズでやるべきことが少し見えた。
ちゃんと価値を届けていくために何をしていくべきなのかを引き続き考えていくようにしたい。