開発組織のスピードを向上させるための体系的な思考プロセス。課題の特定から施策の優先順位付けまでをカバーするフレームワーク。 ## 開発スピードの構造 ``` 開発スピード = 人数 × 一人当たり生産性 × 稼働率 向上させるには： - 人数を増やす → 採用・増員 - 一人当たり生産性を上げる → プロセス改善、技術改善、スキル向上 - 稼働率を上げる → ムダの削減、集中できる環境 ``` ただし、**単に人を増やせば速くなるわけではない**（ブルックスの法則）： - オンボーディングコスト - コミュニケーションコスト - コードベースの複雑さによる限界 ## 思考プロセス ### 1. 現状のボトルネックを特定する **問い**: 開発が遅い理由は何か？どこで時間を使っているか？ #### 1-1. 開発プロセスのどこで時間がかかっているか - 仕様確定・要件定義 - 設計 - 実装 - レビュー - テスト（自動・手動） - QA・バグ修正 - リリース作業 #### 1-2. 待ち時間・ブロッカー - 仕様待ち（PdM、デザイナー） - レビュー待ち - QA待ち - 他チームへの依存（API、インフラ） - デプロイ待ち #### 1-3. やり直し・手戻りのコスト - 仕様変更による手戻り - レビューでの大幅な修正 - バグ修正の手間 - テストの失敗とデバッグ - リリース後の緊急対応 #### 1-4. 技術的な制約 - ビルド時間、テスト実行時間 - デプロイの時間と頻度 - 技術的負債による開発速度への影響 - アーキテクチャの複雑さ - レガシーコードの保守コスト #### 1-5. 人・スキルの制約 - 特定の人にしかできない作業（属人化） - スキル不足で時間がかかる部分 - レビュアー不足 - 並行作業できない理由 ### 2. 目標開発スピードを定量化する **問い**: どれくらい速くなれば良いのか？ #### 2-1. 事業が求める開発スピード - 現在：月に何機能リリースしているか - 理想：月に何機能リリースしたいか - ギャップ：何倍にする必要があるか #### 2-2. 将来の開発要求 - 来期の開発規模感（今期比） - 新規プロダクト・大型施策の有無 - タイムラインの制約 #### 2-3. 実現可能性の評価 - 今の延長線上で達成可能か - 抜本的な改革が必要か - 段階的に到達するのか、一気に変えるのか ### 3. 改善施策を考える **問い**: ボトルネックを解消し、スピードを上げるには何をすべきか？ #### 3-1. すぐにできる改善（Quick Wins） - ムダな会議・作業の削減 - レビュープロセスの改善 - 並行作業の促進（ブロッカー解消） - 小さな自動化 #### 3-2. プロセス改善 - 仕様確定の早期化・明確化 - レビューの分散化（待ち時間削減） - QAの前倒し・シフトレフト - デプロイ頻度の向上 - ふりかえりと継続的改善 #### 3-3. 技術改善 - CI/CDの高速化 - テスト自動化の拡充 - 技術的負債の計画的返済 - アーキテクチャのモジュール化 - 開発ツールの改善 #### 3-4. 人・組織の強化 - **採用・増員**: 何人、いつまでに、どのレベル - **スキルアップ**: ペアプロ、モブプロ、勉強会 - **属人性の解消**: ドキュメント化、ナレッジ共有 - **レビュアー育成**: レビュー品質とスピード向上 - **チーム文化**: 心理的安全性、主体性 #### 3-5. スコープ・優先順位の最適化 - 本当に必要な機能か（やめられることはないか） - MVPでリリースして段階的に拡張 - 技術的負債返済への投資時間確保 ### 4. 施策の優先順位付けと実行計画 **問い**: 何から手をつけるべきか？ #### 4-1. インパクト×実現性マトリクス - **高インパクト × 高実現性**: すぐやる（Quick Wins） - **高インパクト × 低実現性**: 計画的に取り組む - **低インパクト × 高実現性**: 余裕があればやる - **低インパクト × 低実現性**: やらない #### 4-2. タイムラインの設定 - **短期（〜3ヶ月）**: 今期中に効果を出す - **中期（3〜6ヶ月）**: 来期に向けた準備 - **長期（6ヶ月〜）**: 組織・技術基盤の抜本改革 #### 4-3. 責任者とリソース配分 - 各施策の責任者・推進者 - 必要なリソース（時間、予算、人） - 既存の開発タスクとのバランス #### 4-4. 成功指標の設定 - 開発スピード指標（リードタイム、ベロシティ） - 品質指標（バグ率、差し戻し率） - チーム指標（エンゲージメント、稼働率） - 定期的なモニタリングと振り返り ### 5. 継続的な改善サイクル - 月次・四半期でのレトロスペクティブ - 指標のトラッキング - 施策の効果検証 - うまくいかない施策は見直す - 新たなボトルネックが見つかれば対応 ## 推奨アプローチ **開発スピード向上の施策は、大きく以下の優先順位で考える：** 1. **まず効率化**（生産性を上げる） - プロセス改善、自動化、ムダの削減 - 投資コストが低く、効果が早い - 人を増やす前にやるべき 2. **次に増員**（量を増やす） - 効率化してから人を増やす方が効果的 - オンボーディングコストを考慮 - 採用は時間がかかるので早めに計画 3. **並行して技術基盤強化**（将来への投資） - 技術的負債の返済 - アーキテクチャ改善 - 短期的には遅くなるが、長期的には必須 ## 関連ノート - [[開発組織の作り方]] - [[Engineering Manager (EM)]] - [[Four Keys]] - [[技術的負債]]