「うちの開発チーム、開発が遅いんですよね」、と思ったことがあるPdMは少なくないはず。でも、本当に問題は開発チームにあるのでしょうか？
この記事では、「いや、それはPdMの責任として考えようぜ」という話と具体的にどうすればいいのか？をまとめました。
（僕が直近この問題で失敗したので、その反省を兼ねて）
この記事の要約
- 開発遅延の多くはPdMの責任範囲内で改善可能な要因が絡んでいる
- 要件定義の曖昧さ、意思決定の遅延、スコープ管理の甘さが主要な原因
- 自責思考で改善に取り組むことで、チーム全体の開発効率を劇的に向上する
「開発が遅い」の正体を自責の視点で分解する
PdMが影響できる「遅さ」の本当の要因
多くのPdMが見落としがちなのは、開発チームの「待ち時間」です。Microsoftの研究では、開発者は作業の中断や文脈の切り替えなしに多くのタスクや大きなタスクを完了したときに生産的だと感じることが判明しています。つまり、開発効率の問題は技術的なスキルよりも、作業環境や情報提供の質に大きく依存しているのです。
具体的に、PdMが影響できる「遅さ」の要因は以下の通り：
- 要件定義の曖昧さによる手戻り：仕様確認のやり取りで数日から1週間のロス
- 優先順位の混乱とスコープの膨張：追加要件で当初予定の1.5倍以上の工数に
- 意思決定の遅延：承認待ちで開発が数日停止するケースが頻発
- ステークホルダー調整の不備：外部依存で想定外の遅延が発生
開発チームの「待ち時間」を可視化する重要性
Googleなどの研究では、開発者生産性に影響する要因として、コード品質、技術的負債、インフラツールとサポート、チームコミュニケーション、目標と優先順位、組織変更とプロセスが因果関係を持つことが判明しています。
この「待ち時間」が発生する主な場面：
- 仕様確認待ち
- 承認・レビュー待ち
- 外部依存による待機
- 意思決定待ち
これらの多くは、PdMの働きかけ次第で改善可能な領域なんです。
要件定義とスコープ管理の自己診断
曖昧な要件がもたらす開発遅延の実態
ソフトウェア開発における要件定義の重要性は広く知られています。要件定義の欠陥による影響は、開発が進むにつれて指数関数的に増大することが業界では常識とされており、できるだけ早期に要件を明確化することが重要です。
例えば、ユーザー管理機能の開発で「（ユーザーが自分の情報を編集できるようにしたい」という曖昧な要件を出したとしましょう。その結果として、
- どの項目が編集可能なのか後から追加で定義（2日のロス）
- 編集権限の範囲が不明確で再設計（1週間のロス）
- バリデーションルールの追加仕様（3日のロス）
など合計で約2週間の遅延が発生、ということが発生し、これはPdMの責任と言えるでしょう。
要件定義の質を上げる実践的チェックリスト
曖昧な要件を避けるために、基本中の基本ですが、意識しておくべき点は以下かなと思っています（自責の念を込めて）
機能要件チェックリスト
- 誰がその機能を使うのか（ユーザーセグメント）
- なぜその機能が必要なのか（解決したい課題）
- 何を実現したいのか（具体的なアウトプット）
- どのように動作すべきなのか（処理フロー）
- いつ機能が発火するのか（トリガー条件）
非機能要件チェックリスト
- パフォーマンス要件（レスポンス時間、同時接続数）
- セキュリティ要件（アクセス権限、データ保護）
- 運用要件（ログ出力、エラーハンドリング）
- 保守要件（データバックアップ、復旧手順）
適切なスコープ設定の技術
また、スコープクリープ（当初予定していた範囲を超えて機能や要件が膨らむこと）は、開発遅延の主要因の一つ。
効果的なスコープ管理のために、使えるのはMoSCoW法です。
| 優先度 | 説明 | 判断基準 |
|---|---|---|
| Must have | 必須機能 | これがないとプロダクトが成り立たない |
| Should have | 重要機能 | ユーザー価値を大きく向上させる |
| Could have | あれば良い機能 | 追加価値は提供するが必須ではない |
| Won’t have | 今回は対象外 | 将来のリリースで検討する |
この優先度付けを開発着手前に必ずステークホルダーと合意することで、スコープクリープを大幅に削減できます。
意思決定とコミュニケーションの最適化
意思決定の迅速化が開発効率に与える影響
迅速で質の高い意思決定を行う組織は、市場での優れたパフォーマンスを示し、収益成長率も高いことが容易に想像できるでしょう。これは開発プロジェクトにも直結する問題です。
例えば、UIの色を決めるだけに1週間かかったケース。関係者が多すぎて、全員の合意を取ろうとすると普通にこのくらいかかってしまいます（特に大企業）。その間、フロントエンド開発は完全にストップ。このとき必要なのは、意思決定の方法を事前に決めておくこと。
効果的な意思決定プロセスの設計
上記のようなケースを防ぐために、RACI責任分担表（Responsible, Accountable, Consulted, Informed の頭文字を取った、意思決定における役割分担を明確にするフレームワーク）を活用して、意思決定プロセスを明確化することが重要です
（つまり関係ない人には口を出させず、それぞれに対して責任を持っている人が責任範囲で全力を出す仕組み）
- Responsible（実行責任者）：実際に作業を行う人
- Accountable（説明責任者）：最終的な責任を負う人（通常1人）
- Consulted（協議対象者）：意見を求められる人
- Informed（報告対象者）：結果を知らされる人
例えば、機能仕様の決定において：
- Responsible：PdMの田中さん
- Accountable：プロダクトオーナーの佐藤さん
- Consulted：エンジニアリードPMの斉藤さん、デザイナーの山田さん
- Informed：開発チーム全体、営業チーム
このように役割を明確にすることで、意思決定にかかる時間を大幅に短縮できます。
ステークホルダー調整の効率化
複数のステークホルダーが関わるプロジェクトでは、調整コストが膨大になりがちです。ブルックスの法則（人を増やしても開発は早くならない）が示すように、関係者が増えるほどコミュニケーションコストは指数関数的に増加します。
効率的なステークホルダー調整のためには、ステークホルダーマップの作成が有効。
影響度・関心度マトリクス
- 高影響・高関心：密接な連携が必要（週次定例）
- 高影響・低関心：満足させる必要あり（月次報告）
- 低影響・高関心：情報提供で十分（メール共有）
- 低影響・低関心：最小限の関与（四半期報告）
リリース計画とプロジェクト管理の見直し
現実的なリリース計画の立案
そして多くのPdMが犯す過ちは、楽観的すぎる見積もりです。ソフトウェア開発における計画錯誤（Planning Fallacy – タスクにかかる時間を過小評価してしまう心理的バイアス）は広く知られており、実際の開発時間は当初予定の1.5〜2倍かかることが一般的です。
ここまでを全てのPJでやると計画コストが高いですが、特に規模が大きくかつリスクが高いPJで有効な計画立案の方法は以下の通り
- Three-Point Estimationを活用
- 楽観的見積もり（O）：最良の場合
- 悲観的見積もり（P）：最悪の場合
- 最頻値見積もり（M）：最も可能性が高い場合
- 期待値 = (O + 4M + P) / 6
- バッファ時間の設定
- 開発作業：20%のバッファ
- 外部依存：30%のバッファ
- 新技術導入：50%のバッファ
外部依存の管理とリスクヘッジ
さらに、プロジェクトの遅延要因として見落とされがちなのが外部依存。Google Playストアの審査、外部APIの仕様変更、法務チームのレビューなど、開発チームがコントロールできない要素が多数存在します。
外部依存を管理するために有効なフレームワークが依存関係マトリクス
| 依存先 | 依存内容 | リードタイム | リスクレベル | 代替案 |
|---|---|---|---|---|
| App Store審査 | アプリリリース | 1-7日 | 中 | 段階的リリース |
| 外部API | データ連携 | 1週間 | 高 | モックデータでの先行開発 |
| 法務レビュー | 利用規約確認 | 2週間 | 低 | 事前相談 |
このマトリクスを元に、クリティカルパス（プロジェクト完了までの最長ルート）を特定し、ボトルネックとなる依存関係を事前に解決していきます。
開発効率を上げるPdMの実践技術
案件の分割とバッチサイズの最適化
大きな案件を小さく分割することで、開発効率は劇的に向上します。Amazonが提唱するTwo-Pizza Teamの考え方のように、小さなチームで小さな機能を継続的にリリースする方が、大きなチームで大きな機能を一度にリリースするよりも効率的です。
効果的な案件分割の原則：
- ユーザー価値ベースでの分割
- 各分割単位で独立したユーザー価値を提供
- 1-2週間でリリース可能なサイズ
- 技術的依存関係の最小化
- 他の機能への影響を最小限に抑制
- データベース設計の変更は慎重に検討
- フィードバックループの最短化
- 早期にユーザーフィードバックを取得
- 方向修正のコストを最小化
開発チームの生産性向上支援
PdMとして開発チームの生産性向上に貢献できる具体的な方法：
集中できる環境の提供
- フロータイム（連続した集中時間）の確保
- 不要な会議の削減（週20時間→10時間への削減目標）
- Slack等での非同期コミュニケーションの活用
情報アクセスの最適化
- よくある質問のFAQ化
- 仕様書の検索性向上（Notion、Confluenceの活用）
- デシジョンログ（意思決定の経緯と理由を記録したもの）の整備
継続的な改善プロセスの確立
トヨタ生産方式のカイゼン（小さな改善を継続的に積み重ねる思想）をプロダクト開発に応用することで、長期的な効率向上を実現できます。
ふりかえりの効果的な実施方法
- KPT法の活用
- Keep：続けたいこと
- Problem：問題だったこと
- Try：次に試したいこと
- 定量的な振り返り
- ベロシティ（1スプリントで完了できる作業量）の推移
- バグ発生率の変化
- リリースサイクルタイムの短縮
- アクション重要度の可視化
- 実装容易性×効果の大きさでマトリクス化
- まずは「簡単で効果の大きい」改善から着手
「遅い」を指摘する前にすべきこと
自責での改善余地の洗い出し
開発チームに問題提起する前に、PdMとして自分の改善余地を徹底的に洗い出すことが重要です。
PdMとしての改善チェックリスト
要件定義
- 仕様書の曖昧な表現を具体化できているか
- 受け入れ条件を明確に定義できているか
- 非機能要件も含めて網羅できているか
意思決定
- 意思決定のプロセスを事前に合意できているか
- 承認者の役割分担が明確になっているか
- 決定事項の背景情報を適切に共有できているか
プロジェクト管理
- 現実的な見積もりとスケジュールになっているか
- 外部依存とリスクを洗い出せているか
- バッファ時間を適切に設定できているか
建設的な問題提起の方法
問題を指摘する際は、データに基づく現状分析と具体的な改善案をセットで提示することが重要です。
効果的な問題提起の構造
- 現状の客観的な事実
- 「前回のリリースが予定より2週間遅れました」
- 「スプリントの達成率が60%でした」
- 原因の仮説と根拠
- 「ログを確認すると、仕様確認の時間が全体の30%を占めています」
- 「開発チームへのヒアリングでは、要件の解釈に迷う時間が多いとの声がありました」
- 具体的な改善提案
- 「要件定義書のテンプレートを作成し、必須項目を明確化します」
- 「週1回の仕様確認MTGを設定し、疑問点を集約して解決します」
組織全体の改善文化醸成
個人の改善だけでなく、チーム全体で改善に取り組む文化を作ることが重要です。Googleの研究では、心理的安全性がチーム効果性の最も重要な要因であることが判明しています。
改善文化醸成のための具体的施策
- 失敗の学習機会化
- ポストモーテム（障害や問題の事後分析）の実施
- 責任追及ではなく再発防止にフォーカス
- 成功事例の共有
- 改善による効果の定量的な測定
- 他チームへの横展開
- 継続的改善の仕組み化
- 改善提案の評価プロセス
- 小さな改善でも評価する制度
今日から実践できるアクション
すぐに実施できること（今日〜1週間）
- 現在進行中のプロジェクトの要件定義チェックリストでの自己診断
- 開発チームとの週次1on1で「困っていることはないか？」のヒアリング
- 意思決定プロセスの明文化（RACI表の作成）
短期で改善できること（1週間〜1ヶ月）
- ステークホルダーマップの作成と調整プロセスの最適化
- 外部依存関係の洗い出しとリスクヘッジ策の検討
- ふりかえりプロセスの導入と改善アクションの実行
中長期で取り組むこと（1ヶ月〜3ヶ月）
- 案件分割の最適化とリリースサイクルの短縮
- 開発チームの生産性向上支援施策の実行
- 組織全体の改善文化醸成に向けた取り組み
Q&A
Q: 開発チームから「要件が曖昧」と言われますが、どこまで詳細に定義すべきでしょうか？
A: 受け入れ条件が明確に定義され、開発チームが「これで実装できる」と感じるレベルまで詳細化することが重要です。目安として、仕様書を読んだエンジニアが30分以内に実装方針を立てられる程度の詳細度を目指しましょう。不明点がある場合は、質問形式で整理して事前に解決することをお勧めします。
Q: ステークホルダーが多すぎて意思決定が遅くなります。どう対処すべきでしょうか？
A: 意思決定の階層化が効果的です。全ての決定に全員を巻き込むのではなく、影響度に応じて決定権者を分けましょう。例えば、機能仕様はPdMとエンジニアリードPMで決定、予算に関わる大きな変更はプロダクトオーナーの承認、といった具合に役割分担を明確化することで、意思決定速度を向上できます。
Q: 外部依存による遅延をどう防げばよいでしょうか？
A: 並行作業とモックアップの活用がカギです。外部APIの完成を待つのではなく、モックデータでフロントエンド開発を進める、App Store審査の時間を見込んでスケジュールを調整するなど、依存関係を分析して先回りした対策を取ることが重要です。また、代替案も含めて複数のシナリオを準備しておくことをお勧めします。
参考情報
参考文献・調査
- Microsoft Developer Division: “Software Developers’ Perceptions of Productivity” (2018)
- Microsoft Research: “The SPACE of Developer Productivity” (2021)
- Google Research: “What Improves Developer Productivity at Google? Code Quality” (2021)
- McKinsey & Company: “Decision making in the age of urgency” (2019)
- McKinsey & Company: “The need for speed in the post-COVID-19 era” (2020)
- Standish Group International: “CHAOS Report” (various years)
- Google’s Project Aristotle: Research on team effectiveness
関連書籍
- 『リーン・スタートアップ』エリック・リース
- 『プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける』メリッサ・ペリ
- 『INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント』マーティ・ケーガン
コメント