こんにちは、匠平@show60です
昨年10月、ROXX の back check 事業部に開発エンジニアとして入社して3年が経つころにプロジェクトマネージャー (以下 PjM) へと肩書きが変わりました。
ここではスクラム開発を採用する back check 開発チームにおける PjM の役割について紹介したいと思います。
チームが直面してきた課題
2021年の春ころ、back check 開発チームはプロダクトバックログアイテム (以下 PBI) の不足という課題に直面していました。PBI がないとはつまり開発チームのお仕事がないことであり喫緊の課題でした。
主にプロダクトオーナー (PO) が中心となって顧客・他部署からのフィードバックの収集の見直し、リファインメントの効率化などを進めることで解消に向かっていったのですが、将来に渡って継続的に PBI を安定供給できる体制を整える必要があります。
PO、PjM の役割
一般的にイメージされる PjM のお仕事としては、プロジェクト範囲の定義・要件定義、予算・リソース・品質・リスクの管理、進捗管理・報告などがあります。
The roles and responsibilities of the Project Manager are as follows:
- Define project scope
- Gather requirements
- Identify activities, dependencies, sequencing, and time estimates.
- Identify resources needed
- Manages the budget
- Reports to business leadership on project progress
- Focuses on process
- Allocates tasks
- Prioritizes features
- Ensure quality
- Manage vendors
- Manages risk
参考: Project Manager vs Scrum Master vs Project Owner
固定のスクラムチームで自社プロダクトを運用する back check では、予算・リソース管理などは PO が持っており、品質・リスク・進捗に関することは開発チームが責任を持っています。
PO の役割についてはスクラムガイド (記述時点最新の2020年版) にその定義が存在します。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
- プロダクトゴールを策定し、明⽰的に伝える。
- プロダクトバックログアイテムを作成し、明確に伝える。
- プロダクトバックログアイテムを並び替える。
- プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
参考: スクラム公式ガイド 2020年版
この説明に加えて、「上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。いずれの場合も、最終的な責任はプロダクトオーナーが持つ。」とあります。back check における PjM はまさにこの部分を担っており、これら PO の仕事の一部を委任される形で PBI の作成を行っています。
現在は主に CS や顧客からの要望・フィードバックから課題を見つけ出し、その課題に対するアプローチを考えて要件定義するまでの役割を担っています。作成された解決策は PO との確認を経て、プロダクトバックログは PO の責任下から外れることなく PBI として開発チームへ届けられます。
チーム分割の布石として
PjM という役割の採用はチームが直面していた PBI 不足の解消という短期的な目的だけでなく、将来的な開発チームの構成に向けた中長期な目的のための一ステップでもあります。
back check 開発チームはこの1年でスクラムガイドで推奨される10名を越えるまでにメンバー拡充してきました。1枚岩のスクラムチームでは小回りが効きづらく、すでに身動きが取りづらいところも散見されておりチームの分割の検討が開始されています。
チーム分割は、人数規模の問題を解決するためだけではなく、技術的・ビジネス的にも価値のある必要があります。
分割案のチェックリスト
- ミッションがあるか
- そのミッションはチームに限定合理的な意思決定をもたらす重力を生み出さないか
- 定常的に仕事が存在するか
- アーキテクチャ、ビジネス境界、チーム境界が一致しているか
- 分割後のチームのチームリーダーを任せられる人物はいるか
- 分割後、メンバー増加に十分耐えうるか
各チームにはスクラムマスターと開発メンバーが存在し、PO が各チームに開発してもらいたい PBI を割り振るようなチーム分割をイメージしています。その際に PjM は自分が要件定義を担当した PBI の受け渡しの説明だけでなく、その後のメンバー間との対話を引き続き担うことも可能です。
PO とのコミュニケーションで齟齬があると致命的な問題になってしまうため、普段のコミュニケーションや信頼関係の構築が重要です。また当然他部署との連携も必要なので、全方面において良い関係を構築していく必要があります。
まとめ
ご紹介させていただいたように back check 開発チームの PjM は、CS や顧客からの要望・フィードバックからの課題発見から、解決方法の提案、要件定義までを主に行っています。 ユーザーにとっての負の解消だけでなく、その期待を超えるようなアイデアを考えて提案することもできます。
私がこれまで開発メンバーとして関わってきたころと比べ、ユーザーへの価値を決める初期のステップに携わることが多いため、実際にユーザーに届いて使ってもらえるときの喜びをより一層感じることができています。
当然それだけの責任も伴いますし実際に使われるまでは不安も大きいのですが、チームメンバーはその実現のための技術的な相談や必要なサポートをしてくれます。みんなで良いものを作ることにとことん向き合えることにとてもやりがいを感じています。
最後に
そんな私たち back check チームに興味をお持ちいただける方、リファレンスチェックという新しい市場のスタンダードを一緒に作っていきたいという仲間を絶賛募集しています。 ご紹介させてもらった PjM のポジションだけでなく、開発ポジション、デザイナーも募集していますので
