当社が提供しているSynergy!（顧客管理・CRMシステム）の開発プロジェクトのPMを担当しています。 今回は主にプロダクト開発の進め方について、これまで試行錯誤してきた内容を書きたいと思います。
下山 倫央（シモヤマ トモヒサ）最近は子供中心の生活です。毎日2人の娘に癒されています。
プロダクト開発の進め方
以前のプロダクト開発は、企画や仕様を決める作業や、開発を実施する作業など、各工程で役割を分担する進め方で行っていました。
以前の開発フロー概要
- 企画された機能に対してデザイナーがワイヤーフレーム/デザインカンプ*1、画面仕様書を作成
- PMがレビュー
- エンジニアなどの関係者にワイヤーフレーム/デザインカンプ、画面仕様書の説明を実施
- 開発着手～テスト～リリース
ただ、この進め方だと、
- 仕様が完全に決まらないと開発が進まない
- ⇒エンジニアが稼働できず、リソースを最大限活用できない
- PMとデザイナーだけで仕様を検討している
- ⇒エンジニアなどの関係者との仕様の認識ずれや仕様検討の後戻りが多い
- デザイナーがワイヤーフレーム/デザインカンプ、画面仕様書を作成している
- ⇒仕様確認や画面仕様書の修正など、デザイナーの負荷が高い
というような課題が出てきました。 そこで、PM、エンジニア、デザイナー、QA(Quality Assurance)などプロジェクトに関わる関係者が一緒に仕様を検討しながら開発を進めるフローに変更しました。
現在の開発フロー概要
- PMが仕様検討のもとになるPBI（プロダクトバックログアイテム）を作成※この時点でエンジニアに仕様の調査や確認を依頼することもあります
- デザイナーがPBIを元にワイヤーフレーム/デザインカンプを作成
- PM、エンジニア、デザイナー、QAでPBIとワイヤーフレーム/デザインカンプを元に仕様検討を実施（リファインメント）
- 仕様検討結果をPBI、ワイヤーフレーム/デザインカンプに反映
- PMが画面仕様書を作成
- エンジニアがタスクを洗い出す（プランニング）※PBIとタスクをGitLabのissue boardを使ってカンバン運用*2しています
- 開発着手～テスト～リリース
開発フローを変更して良かったこと
現在私が担当しているプロジェクトではフローを変更したことにより、下記のような効果がありました。
- エンジニアを含め関係者全員で仕様検討を行うため、エンジニアのリソースも最大限活かせる
- さらに、認識のずれや仕様検討の後戻りが少なくなり、仕様検討の過程も記録することで 関係者全員で振り返ることができるようになった
- どこかの役割に負荷が集中することなく、進捗がスムーズになった
これまでは、「PM・デザイナーが仕様書を作成して、その仕様でエンジニアに開発を発注する」という感じがありましたが、プロジェクトの関係者が一緒に仕様検討を進めることで、以前に比べチームとしての一体感が生まれてきたと感じています。
運用していくうえで見えてきた課題
ただし、良いことばかりではなく、新たな課題も見えてきました。
PBI単位で仕様を検討していくため、将来の全体感が見えない
デザインに関しては直近リリースを行う機能だけではなく、今後リリースされる機能も含めて整合性をとって設計する必要があるため、現在の進め方には課題があります。 一部、将来リリース予定の機能をデザイナーが前倒しすることにより対応している箇所もありますが、この点については今後対応方法を検討する必要があると考えています。
複数のプロジェクトが稼働しているが、プロジェクト間で運用に少しずつ違いが出てきた
運用を変更してから1年ほどたちますが、下記の点についてプロジェクト間で差異がでてきました。
- PBIに記載する内容
- スケジュール管理方法
- PM、エンジニア、デザイナーの役割
- リリース機能に対するフィードバックやバックログの管理方法
- 各種会議体のファシリテーター など
この件に関しては、明確なルールが決まっていなかったことが原因ですので、各PMが集まって情報交換を行い、ルール決めや運用方法の改善に取り組んでいます。 また、各種フォーマットを整備し、プロジェクト間で運用に違いが出ないような取り組みも進めています。
今後について
現在の運用が最適とは考えていません。 仕様決定のプロセス、プロジェクト間の情報共有、各職種間のコミュニケーションなど、まだまだ改善が必要なものがあります。関係者でプロジェクトの振り返りを実施し、当社にとってより良い運用方法を模索していきたいと考えています。
