はじめに
こんにちは！ テクノロジー戦略本部 開発二部の瀬尾です。
私は現在、弊社の中期経営計画2024にあるバイセルリユースプラットフォーム(Cosmos)の販売領域プロダクトを新規開発しているチームでプロダクトマネージャー(PdM)を務めています。
このチームには前PMから引き継ぐ形で参加しており、最近大きなマイルストーンを達成できたので、その振り返りと得られた知見を紹介したいと思います。
対象読者
以下のような課題を抱えているプロダクトマネージャーの参考になれば幸いです。
- 途中からプロダクト or プロジェクトのマネジメントを引き継いで立て直しを図りたい
- プロダクトマネジメント手法の具体例を知りたい
当時の開発状況
状況：新規開発中。いくつかの機能はできている。
チーム：エンジニア4名 + PM1名(PMが抜けて私が参画)
開発スタイル：アジャイル
重要度：社内で最も重要なプロジェクトの一つ
状況把握
途中参加でしたので、まずは現状把握を行いました。チームメンバーの中でプロジェクトの最初から参加しているエンジニアや利用者となる事業部の担当者に状況を聞くと以下のような課題を抱えていることがわかりました。
エンジニア視点の課題
- ゴールが漠然としていて見えていない
- これまでにスケジュール計画は何度も変更され、現在の計画も現実的ではないと思われる
- エンジニアがなんのために何を作るのか、あまり理解していない
- モチベーションが低下している
- 各エンジニアがそれぞれの担当領域を開発しており、お互いの開発内容を理解できていない
- プロダクト利用者となる事業部とのコミュニケーションが上手くいっていない
事業部視点の課題
- どういう仕様になるのかあまり理解できていない
- デモ環境で開発中プロダクトを触れるようになっているが、どこが開発途中でどこが完成しているのかわからないのでフィードバックがしづらい
- なんとなく不安
やったこと
一度立ち止まる
もともと参画したときは、それまでの方針に則ってリリースまで推進できれば良いと思っていました。しかし、上記の様に状況をざっと把握した結果、方針の軌道修正をした方が良さそうに感じました。
そこで一度立ち止まる事にしました。新たな計画を立てるまでの間、エンジニアの皆さんには、今開発しているものを一旦切り上げて、DevOps環境整備を行ってもらいました。これまで開発効率が悪いところがあっても、環境整備に使える時間がなく、やりたくても出来ていなかった事を集中期間を設けてやってもらう事で、これ以上のモチベーション低下を抑える効果もありました。
ビジョンを打ち立てる
次に、漠然としてしまっているゴールを設定をするためにも、開発チーム、事業部を始めとするステークホルダーに、すこし抽象化した概念で共通認識を持ってもらい、みんなが同じ方向を向く必要がありました。そこで「このプロダクトがリリースされた時、こういう世界になる！」というイメージを言語化し、共有しました。また、ビジョンを実現するためにこのプロダクトでは以下を重視する事を共通認識としました。
- ユーザーにとって分かりやすく学習コストが低いユーザビリティ
- 大量のデータでもストレスなく操作できるシステムパフォーマンス
ビジョンができると、チームメンバーと一緒に同じ方向を向きながらプロダクトの方向性について相談できている感覚を得られるようになりました。そこから、少し抽象度を下げてプロダクトのwhy(なぜ作るのか)、what(なにを作るのか)の部分が出来ていきました。
その後、開発が進んで行くことになるのですが、機能単位でのwhy、whatも明確にして、チーム全員がなんのために目の前のタスクをやっているのか、理解してもらいながら進めることが出来ています。
役割を分ける
前任のPMはエンジニアリング領域、ピープルマネジメント領域、プロダクト領域などプロジェクト推進に関連するすべての領域を担当していました。忙しすぎて様々な面でやり切れない部分が出てきていた感は否めません。
そこで、同じ轍を踏まないように役割を分けることにしました。いろいろ変遷はあったのですが、現在は以下のような体制になっています。
まず、プロダクトマネージャー(私)は事業も含めた広義のプロダクトに責任を持ち、why、whatの部分に集中することとしました。プロダクトが利用者に価値を提供できるよう、向かうべき方向を示し、決断することが責務になります。具体的には要件定義、画面設計、仕様策定、デザインの決定、開発スコープの判断、ステークホルダーとの調整、成果物のリリース判断などを行います。また、これはどんなプロジェクトでも意識していることですが、組織上、私はテクノロジー戦略本部に所属しているので、できるだけビジネスサイドへ立ち位置を寄せ、事業部に信頼してもらう事もミッションとなります。
ピープルマネジメントは部門長のマネージャーが直接行うことにしました。具体的にはメンバーの目標設定やキャリア相談、評価、人員調整などです。これらがPMの責務だと、特に期の変わり目などに多忙になり、エンジニアが質問したいのに捕まらないなど、PMがプロジェクトのボトルネックになりがちでした。また、上流工程に評価者がいない事で、エンジニアが言われた仕様の物をただ作るのではなく、異なる意見でも遠慮なく言ってもらいたいという意図もありました。
テックリードはプロダクトのhow(どうやって作るのか)の部分と、品質について責任を持つ事としました。エンジニアリングを主導し、チームの技術面をサポートします。仕様策定についても工数がかかりすぎる部分があればプロダクトマネージャーと落とし所を相談したりします。
プロダクトマネジメント領域とエンジニアリングマネジメント領域、両方に関わる存在として、エンジニア兼サブプロダクトマネージャーがいます。立て直しにおいて彼は非常に重要でした。どちらかの領域でボトルネックが発生したり手を借りたいときに、プロジェクトを広く理解している彼が補助エンジンとなって適宜、さまざまな役割を果たしてくれました。
見積もる
ビジョンと役割が決まったら、これから登る山の大きさを測ります。
まず、ユーザーストーリーマッピングを作成しました。ユーザーの業務に対してプロダクトが提供する価値を漏れがないよう洗い出します。ここでは機能ではなく、「ユーザーが〇〇することができる」など価値の粒度で記述します。
次にプロダクトバックログを作成しました。ユーザーストーリーマッピングを元にストーリー単位でチケットを切り、優先度が高い順に並び替えます。また、価値提供するために必要な物の開発タスクに適宜、分解します。分解は全てではなく、このあとの見積もりをするにあたって必要なものは分解しました。
最後にプロダクトバックログを元に工数を見積もります。最初の工数見積もりはTシャツサイズ(S,M,L)で大雑把に見積もりました。詳細な見積もりは後に開発を進めながらリファインメントでプロダクトバックログの上位にあるものから精査していきました。初期の見積もりで一旦ロードマップは作成しましたが、不確実性コーンの考え方をステークホルダーにも共有し、リリース日は不確実性が収束した後に設定することを了承してもらいました。
再スタート
こうして計画を立て、再スタート、、、といきたいところですが、その前にチーム内で「各エンジニアがそれぞれの担当領域を開発しており、お互いの開発内容を理解できていない」課題を解決するため、体系的にスクラム開発をやろうという事になりました。そこで全員でスクラムガイドを読み込み、きちんとスクラムイベントを開催することにしました。さらに社内のスクラム開発有識者に一時的に参加してもらってサポートしてもらい、チームにスクラム開発が定着していきました。
こうして再スタートする事ができ、スプリントを重ねていきました。スプリントレトロスペクティブでしっかり振り返り、改善を重ねながら開発が進行していくと、感覚としては開発効率が上がっているけど定量的にどうなんだろう？という疑問が出てきました。そこで、開発効率の見える化施策として「Findy Team+」を導入しました。導入の経緯や結果については以下を参照していただければと思います。
そうして開発が進んでいき、最近、目標としていた大きなマイルストーンに、立て直した計画通りに到達することができました。途中、リソースの増員やスコープの見直しなど様々な事があったのですが、その辺りの話はまたの機会にできればと思います。まだまだプロジェクトとしては道半ばで、新たな課題もあるのですが、ユーザーに価値提供できるよう、これからもチーム一丸で頑張っていきたいです。
まとめ
以上が引き継ぎ案件の立て直し期にやったことの紹介になります。
振り返って重要だったなと思うのは、役割の分担を決めたことと、フレキシブルに動けるエンジニア兼サブプロダクトマネージャーの存在です。PMというフワッとした何でも屋責任者1人では、よほどのスーパーマンでないと大きなプロジェクトを動かすのは難しいと思います。プロダクトマネジメント、エンジニアリングマネジメント、ピープルマネジメントと領域を分けて考え、プロジェクトマネジメントはチーム全員がオーナーシップを持って推進力となる事が大切だと感じています。
最後にBuySell Technologiesではエンジニアを募集しています。興味がある方はぜひご応募ください！
