こんにちは。READYFORでプロダクトチームのリードを務めている斉藤です。
本記事は「READYFOR Advent Calendar 2024」の23日目の記事としてお届けします。
はじめに
現在、私が所属するREADYFORのプロダクトチームは以下の6名体制で開発を行っています。
- プロダクトマネージャー（PdM）：2名
- エンジニア：4名
昨年から今年にかけてメンバーの入れ替わりがあり、もともと少人数（PdM：1名、エンジニア：3名）で開発していたチームがメンバー拡大し、READYFORでは最大規模のプロダクトチームとなりました。
しかしメンバーが増えたことで、これまで問題となっていなかった新たな課題に直面しました。
この記事では、チーム体制が変化する中で発生した課題 と、それをどのように解決してきたかの取り組み を共有します。
チーム拡大による新たな問題点
まずは、以前の私たちの開発フローについて振り返ってみます。以下はチーム人数が増える前、少人数体制で運営していた時の作業分担です。
旧ワークフロー
- プロダクトマネージャー（PM）
- ビジネス要求の収集、要件定義
- 仕様策定・タスク分解
- QA（品質保証）
- エンジニア
- 設計（デザイン含む）
- 実装・テスト
少人数のため、役割が厳密に分けられるというより、PMがリードし、開発フェーズに入るとエンジニアが引き継いで進める形が一般的でした。また、フロントエンド（FE）・バックエンド（BE）のエンジニアが1名ずつ だったため、それぞれが設計から開発までほぼ1人で行っていました。
チーム拡大で顕在化した課題
- 開発ごとに要件・仕様・設計のばらつき
- 「どの情報が揃えば開発に進めるのか」や「いつその情報を確定すべきか」が曖昧で、開発案件ごとにばらつきが発生
- メンバー間のやり方や理解の差による認識齟齬が頻発
- 新しいメンバーにとって「次に何をすべきか」が不明瞭で手探りの状態に
- 担当者が不明確でタスクの漏れが発生
- 設計やタスク分解の責任者が曖昧だったため、都度コミュニケーションが発生
- タスクが宙に浮いて漏れたり、スケジュールが遅延する原因に
改善への取り組み
これらの課題を解決すべく、チーム全体で以下の改善に取り組みました。
改善 その1：開発ステップごとに必要な状態を可視化
まずは開発フローを振り返り、「各開発フェーズで何が揃っているべきか」を洗い出しました。
続いて、必要な情報を網羅できるよう要件定義テンプレートを改善しました。
notionを使って管理しています。情報を一元管理できるよう基本的にはここからすべての資料へアクセスできるようにしています。（より詳細な資料が必要な場合はサブアイテムとして紐づける）
担当PdM：TBD, 主幹エンジニア：TBD
## 1. 背景
担当プロダクトマネージャーが記入。プロダクトの外にはどんな世界があってどんな人たちが関わっていて、
なぜ今回の要求が満たされるべきなのかを理解しやすくするための補助として書く
…
## 2. 要求
担当プロダクトマネージャーが記入。開発に関わるすべてのメンバーが同じ目的のためにその実現方法を議論できるようにする。
要求が複数ある場合、スコープ議論しやすいようMust / Should / Could / Won’tの優先度をつけておくと尚良し
### 機能要求
利用者視点の言葉で「誰が何のために何をしたいのか」を端的に表現する
- 《Who: 誰》が《Why: 何のため》に《What: 何》をできるようにしてほしい
### 非機能要求
性能・セキュリティなど、機能要求以外でシステムがどうあるべきか・どんな制約があるのかを記入する
- パフォーマンス水準
- ユーザーの個人情報の開示が適切な範囲で行われること（Must have）
- 実行者代理モードが適切な権限統制のもと機能すること（Must have）
- … （かけられるコストなど、今回特別なものがあれば追記。なければ削除）
## 3. 要件
担当プロダクトマネージャーと主幹エンジニアが記入。
PdMはビジネス・UI/UXの観点から、エンジニアはシステムの観点から、要求を満たすためシステムがどう振る舞うべきかを網羅する
- …
### デザイン（あれば）
担当プロダクトマネージャーかデザイナーが記入。Figmaのリンクを貼る
https://figma.com/…
### 設計（あれば）
主幹エンジニアが記入。
開発の対象となるドメインに登場する主要な概念を新旧含めて洗い出し、
名前がついていないものには名前をつけ、関係性を整理した図
（正式な日本語ラベルとの対応、モデルごとの設計思想もあると良い）
https://figma.com/…
### その他留意事項・備忘録（あれば）
設計・実装などこの後のプロセスにおいて参照すべきことがあれば書き留めておく
…
## 4. 受け入れ条件
担当プロダクトマネージャーが記入。
開発完了後にPdMが受け入れテストを実施するために使う。As-Given-When-Thenの4ポイントがわかるように書くこと
見積もり前にはドラフトを作成し、スプリントに投入する前までにFixさせる
- [ ] 《Given: 前提条件》において、《As: 誰》が《When: 操作》をすると、《Then: システムに期待する振る舞い》になる
- [ ]
## 5. 見積もり前チェックリスト
主幹エンジニアがチェックをつける。
スプリント中の開発がスムーズに進むように、すべてのチェックがついてから見積もりを始める
- [ ] 背景・要求・受け入れ条件が記載されていること
- [ ] 機能要求を満たす要件が網羅されていること
- [ ] パフォーマンスなど非機能要求を満たすために留意すべきことがあれば要件に反映されていること（「〜というリスクがあるけど実際に動かして確かめよう」も対応方針の一つ）
- [ ] ローディング時の振る舞いについて要件が定義されていること（標準的なローディングでOKであればそのことを書く）
- [ ] エラー時の振る舞いについて要件が定義されていること（標準的なエラーでOKであればそのことを書く）
効果
- 要件定義漏れや考慮不足がなくなり、手戻りが大幅に削減
- メンバー間での認知コスト・コミュニケーションコストを軽減
改善 その2：責任範囲を言語化
次に、各メンバーの役割と責任範囲を定義し、言語化することでタスクの曖昧さを排除しました。
特に、PdMとエンジニアを繋ぐ役割として、「主幹エンジニア」 のポジションを設置しました。
主幹エンジニアの役割
- 要件定義や仕様策定にエンジニア視点を反映させる
- PdMとエンジニア間の相談窓口として機能する
- 各フェーズでのタスク進捗を見守り、スムーズに進められる体制を作る
そして新しいワークフローを構築しました。
新しいワークフロー
効果
- 開発に入って以降の要件の手戻りが減少
- 開発責任の所在が明確化され、担当者を探す手間が大幅に減少
- 開発進捗の遅延の減少
さいごに
チーム開発において、いかにコミュニケーションを円滑にすることが大切であるかを実感した1年でした。
メンバーひとりひとりが最大限の力を発揮できるよう今後も改善を進めていきたいと思っています。
今回の取り組みが、似た課題を抱えるほかのチームのお役に立てば幸いです。
最後までお読みいただきありがとうございました！