はじめに
こんにちは。Product Management Group で プロダクトマネジメント をしている坂東（@7auto）です。
リソース的な問題で「やるべきことがたくさんあって、小さめの改善やPJに手が回らない」そんなお悩みを持つ方はたくさんいらっしゃるのではないでしょうか。
サービスが大きくなるとPJの規模も大きくなっていきます。その結果、小さめのPJや改善の優先度が下がりがちになります。 一方で、小さめのPJや改善はサービス利用者の声から生まれることも多く、これを放置し続けることはサービス体験の悪化に繋がります。
そこで大きなPJと並行して、こうした小さめのPJや改善に対し「最小のコミュニケーションコストで機能リリースする」というコンセプトで立ち上げからリリースを行いました。
「全員集まったのはキックオフと振り返りだけ」そんな定例もDailyも無いPJを通して、低コストなだけでなく個人の成長にもつながるメリットがあるように感じられました。
本稿ではそこから得られたことを共有できればと思います。
低コストをコンセプトにした背景
当時、自分は本件の他に3PJ（そのうち開発が2件）を同時進行していました。
他のPJではアジャイルな開発方式を取っており、毎週スプリントイベントDailyMTGを実施しながら漸進的に進めていました。
アジャイルな開発方式を取ることで不確実性への対処は容易になる一方、コミュニケーションに割く時間が大きくなります。 そのため、３開発をアジャイルにすると時間的な面で自分がボトルネックになる懸念を感じました。
そこで、開発規模が一番小さかった本件のPJはアジャイルにとらわれず、できるだけコミュニケーションコストを下げるようPJを設計しました。
メンバー構成・削ったこと・スケジュール感
このPJメンバー構成はプロダクトマネージャー（自分）、デザイナー、バックエンドエンジニア、フロントエンドエンジニア、プロセスエンジニア、直接手は動かさないプロジェクトマネージャーの６名で、それぞれが別のPJも兼務していました。
プロダクトマネージャー、デザイナー、エンジニアは一緒に仕事するのが初めてのメンバー同士でした。 また、各メンバーが別のPJを兼務している都合上、全員が揃うのを待つことはせず、各工程をFIXさせて次の工程に進めるウォーターフォールに近い形になりました。 実際のリリースまでのスケジュールはざっくりと以下のような流れになりました。
- 2週間：PdMが企画・ドキュメント化
- 2週間：デザイナーがUI/UXを確定
- 4週間：エンジニアが開発
- 2週間：PEがQA
- リリース
コミュニケーションを削れるだけ削ったため、リリースするまでに全メンバーが顔を合わせたのはキックオフだけで、アドホックなMTGも数えるほどでした。
PdMとして気をつけていたこと
コミュニケーションを削るということは、デザイナーやエンジニアはドキュメントから必要十分な情報を引き出せる必要があることを意味します。
なので企画の段階で体験やお問い合わせ時の対応なども考慮し、要件・体験・実装を意識したPRDを作成していきました。 それでもいくつか質問を受けるケースがありましたが、質問を受けた際は2分以内で答えるくらいの気持ちでやりました。*1
結果的に特に大きなトラブルもなくスムーズにリリースできました。
このPJを通して得られたこと
低コストで大きな手戻りもなかったので、全体的にスピーディーに無駄なく価値提供できました。 今回のような方針でPJを設計することで、手が回りにくい小さめのPJも並行して動かせると感じました。
また、リリースを通して客観的に自身を見直す機会を得られたことも非常にポジティブにとらえています。
ウォーターフォールに近い開発スタイルとなったことで以下を意識する必要があったため、（仕事をする上で当たり前でありますが）普段の仕事の姿勢を改めて考える良い機会になりました。
- 自身で作成したスケジュールに責任を持つ
- 情報伝達の内容に責任を持つ
- 状況変化に対する報連相の意識が高める
特にこのPJではDailyもないので「明日共有すればいいや」という気持ちにならなかったことが大きいと感じました。
また、自身のドキュメンテーションの質を客観的に見直す良い機会となりました。 PdMとしてはドキュメントで必要十分な情報を伝えなければならなかったことで、以下を改めて意識することになったためです。
- 不明瞭さを残さない
- 無駄なことを書かない
- 読み手のコンテキストを意識する
最後に、今回は小さいPJかつ初めてのメンバーとの仕事だったので、PJ運用でトライしたかったことを小さく試すことができました。
PJ規模が大きくなると、PJ運用のスケジュールへの影響も無視できないため、積極的なトライがしにくくなります。 そのため、こうした方式のPJは実験、息抜き、マンネリの解消といった意味も持たせることができるように感じました。
おわりに
小規模なPJであれば、コミュニケーションを削ぎ落としてPJの並列数を増やすことができました。また、副次的に仕事の質やプロセスを見直すという価値も持たせることができました。
小規模の開発に割くリソースがない方、時間がないとお悩みの方、いつものやり方にマンネリを覚えている方は、勇気を持ってどこまで軽量にリリースできるかを楽しんで見てはいかがでしょうか？
最後に宣伝です。BASE ではプロダクトマネジメントをするメンバーを募集しています。 興味がある方は下記の紹介資料や、採用情報もぜひご覧ください。
*1:リリース後の振り返りでエンジニアからFBを頂いたのですが、すぐに返答することがDaily（強制的に集まって問題を確認する場）を設けずに済んだ要素になっていたようです。
