業界別プロジェクトマネジメントガイド · IT、ソフトウェア、デジタル
ソフトウェアプロジェクトマネジメント：ライフサイクル、役割、手法、KPI
ソフトウェアのプロジェクトマネジメントとは、ソフトウェア製品や機能を、ディスカバリーと要件定義から、設計、開発、テスト、リリースを経て継続的な改善まで、計画・調整・提供することです。ソフトウェアは変更しやすい一方で見積りが難しいため、ほとんどのソフトウェアチームは短いイテレーションで作業を管理し、文書ではなく動くソフトウェアで進捗を測ります。
要点
- 要件は変化し、見積りは不確実であるため、ソフトウェアのプロジェクトマネジメントは短いイテレーションで進めます。
- スクラム、かんばん、DevOps、計画駆動型のアプローチは、習慣ではなく作業の性質に基づいて選びましょう。
- デリバリーはDORAメトリクスとフローメトリクスで、成功は成果指標で追跡しましょう。
- コードレベルの作業には開発者向けの課題管理ツールを、部門横断の計画にはWrikeなどのプラットフォームを使います。
ソフトウェアのプロジェクトマネジメントの特徴
- 要件は変化する。 ユーザーは、動くものを見て初めて自分が何を望んでいるかがわかることがよくあります。
- 見積りは不確実。 作業の多くは新しい問題解決であるため、チームは固定の日付ではなく、範囲と過去のスループットに基づいて予測します。
- デリバリーは継続的に行える。 テストとデプロイを自動化すれば、チームは週に何度もリリースできます。
- 技術的負債。 期日に間に合わせるための近道は、返済しない限り将来の作業を遅くします。参考： スクラムにおける技術的負債.
- 品質は作り込むもの。 コードレビュー、自動テスト、監視が、プロジェクト終盤の大規模なテストフェーズに取って代わります。
- プロダクトとプロジェクトの重なり。 多くのソフトウェアチームは長期にわたって存続するプロダクトチームであるため、「プロジェクト」はリリース、機能群、新製品であることがよくあります。
チームがコードにアジャイルの価値観をどう適用しているかの概要は、次をご覧ください： アジャイルソフトウェア開発.
ソフトウェア開発ライフサイクル（SDLC）
| フェーズ | 行うこと | 主なアウトプット |
|---|---|---|
| ディスカバリー | ユーザー、課題、目標を理解し、リサーチとプロトタイプでアイデアを検証する | 課題の記述、プロダクトビジョン、初期のプロトタイプ |
| 計画 | スコープを形づくり、バックログに優先順位を付け、リリースとキャパシティを計画する | プロダクトバックログ, リリース計画, ロードマップ |
| デザイン | UXデザイン、アーキテクチャ、技術的アプローチ | デザイン、アーキテクチャの意思決定、受け入れ基準 |
| 開発 | レビューと自動テストを伴いながら、小さな単位でコードを書く | 動作しテスト済みのインクリメント |
| テストと品質保証 | 自動テスト、探索的テスト、性能テスト、セキュリティテスト | テスト結果、解決済みの欠陥 |
| リリースとデプロイ | 本番環境へのデプロイ。多くの場合 継続的デリバリー パイプライン | リリースされた機能、リリースノート |
| 運用と改善 | 監視し、ユーザーを支援し、成果を測定し、学びをバックログに反映する | メトリクス、インシデント、新しいバックログアイテム |
アジャイルチームでは、これらのフェーズは一度だけ順番に行われるのではなく、毎回のイテレーションの中で継続的に行われます。参考： アジャイル開発ライフサイクル.
主要な役割
| 役割 | 主な責任 |
|---|---|
| プロダクトオーナー／プロダクトマネージャー | プロダクトビジョンに責任を持ち、価値に基づいてバックログを並べる。参考： スクラムのプロダクトオーナー |
| エンジニアリングマネージャー | エンジニアを率い、採用、育成、デリバリーのプラクティスを担う |
| テックリード／アーキテクト | 技術的な方向性と品質に責任を持つ |
| 開発者 | ソフトウェアを設計、構築、テストする |
| QA／テストエンジニア | テスト戦略、自動化、探索的テスト |
| UX／プロダクトデザイナー | ユーザーリサーチとインターフェースデザイン |
| スクラムマスターまたはデリバリーリード | プロセスをファシリテートし、障害を取り除く。参考： スクラムマスターの役割 |
| テクニカルプロジェクトマネージャーまたはプログラムマネージャー | チーム間の依存関係、タイムライン、リスクを調整する。参考： テクニカル・プロジェクトマネージャー |
| DevOps／SRE | ビルドパイプライン、インフラストラクチャ、信頼性 |
ソフトウェアプロジェクトの手法
| アプローチ | 適する場面 | 備考 |
|---|---|---|
| スクラム | ステークホルダーから定期的にフィードバックを得ながら新機能を構築するプロダクトチーム | 計画、レビュー、レトロスペクティブを伴う固定期間のスプリント |
| かんばん | 保守、プラットフォーム、サポートのチーム。継続的なフロー | スプリントの代わりにWIP制限とフローメトリクス |
| エクストリーム・プログラミング（XP） | 強固なエンジニアリング規律を求めるチーム | ペアプログラミング、テスト駆動開発、継続的インテグレーション |
| DevOps | 自らサービスを構築・運用するチーム | デリバリーを自動化し、運用の責任を共有する |
| ウォーターフォール またはVモデル | スコープ固定の契約、規制対象またはセーフティクリティカルなソフトウェア | 正式なフェーズ、文書化、検証 |
| スケーリングフレームワーク | 1つのプロダクトに多数のチーム | 参考： SAFe と LeSS |
選択肢の比較は アジャイルとウォーターフォールの比較 と かんばんとスクラムの比較.
必須の文書とテンプレート
| 文書 | 目的 | テンプレート |
|---|---|---|
| プロダクトバックログ | プロダクトに必要となり得るすべてを並べたリスト | プロダクトバックログテンプレート |
| ユーザーストーリー | ユーザーの視点で書かれた要件 | ユーザーストーリーのテンプレート |
| スプリント計画 | スプリントゴールと選択した作業 | スプリント計画テンプレート |
| リリース計画とロードマップ | 何をいつリリースするかの大まかな見通し | リリース計画のテンプレート, プロダクトロードマップのテンプレート |
| 要求事項文書 | スコープ固定の作業や受託開発の場合 | ビジネス要求文書テンプレート |
| レトロスペクティブのメモ | チームが合意した改善 | スプリントレトロスペクティブのテンプレート |
| RAIDログ | チーム間のリスクと依存関係 | RAIDログテンプレート |
これらとあわせて、アーキテクチャ決定記録と完成の定義を維持します。参考： 完成の定義.
ソフトウェアのプロジェクトマネジメントのKPI
| KPI | 測定対象 | 主な用途 |
|---|---|---|
| デプロイ頻度 | コードが本番環境に届く頻度 | デリバリー能力（DORAメトリクス） |
| 変更のリードタイム | コミットから本番環境までの時間 | フローの速さ（DORAメトリクス） |
| 変更失敗率 | 障害を引き起こしたデプロイの割合 | リリースの品質（DORAメトリクス） |
| サービス復旧時間 | 障害がどれだけ早く修正されるか | 回復力（DORAメトリクス） |
| サイクルタイム | 作業開始から完了までの時間 | 予測とボトルネックの発見 |
| スループット または ベロシティ | 週またはスプリントあたりに完了した作業 | リリースの予測 |
| 流出欠陥 | リリース後に見つかったバグ | テストの有効性 |
| 成果指標 | 利用率、コンバージョン、継続率、タスク成功率 | ソフトウェアが価値を提供しているか |
参考： アジャイルのメトリクスとKPI に関するガイドをご覧ください。
よくある課題
- 日付もスコープも固定。 日付を固定してスコープを調整し、過去のスループットに基づいて範囲で予測します。
- 膨らむ技術的負債。 スプリントごとにリファクタリングとプラットフォームの作業のためのキャパシティを確保しましょう。
- チーム間の依存関係。 依存関係を見える形で整理し、共通のマイルストーンで足並みをそろえ、 スクラム・オブ・スクラム または同様の同期の場を使います。
- 仕掛り作業が多すぎる。 次を適用： WIP制限 を適用し、新しく始める前に完了させます。
- 成果ではなく出力を測ること。 リリースをストーリーポイントだけでなく、ユーザーとビジネスの目標に結びつけましょう。
ソフトウェアのプロジェクトマネジメント向けソフトウェア
開発チームには、コードリポジトリやCI/CDパイプラインと連携する課題管理ツールに加え、ボード、バックログ、スプリントレポートが必要です。プロダクトマネージャーやデリバリーマネージャーには、ロードマップ、チーム間の依存関係のビュー、エンジニア以外も読めるレポートも必要です。
Jira は、エンジニアリングチームで課題管理に広く使われています。 Wrike が最も強力なオールインワンの選択肢です（ 当サイトのツールランキング は、ソフトウェアの作業をマーケティング、サポート、デザインなど他部門と並行して計画する必要がある場合に、アジャイルボードとガントビューを1か所で使えて便利です。あわせて参考： スクラム用ソフトウェアツール.
このトピックの無料テンプレート
よくある質問
ソフトウェアのプロジェクトマネジメントとは何ですか？
ソフトウェアのプロジェクトマネジメントとは、ソフトウェア製品や機能を、ディスカバリーから開発、テスト、リリースを経て継続的な改善まで、計画・調整・提供することです。
ソフトウェアのプロジェクトマネジメントにはどのようなフェーズがありますか？
SDLCのフェーズは、ディスカバリー、計画、設計、開発、テスト、リリース、運用と改善で、通常は短いイテレーションで繰り返されます。
ソフトウェアのプロジェクトマネジメントに最適な手法は何ですか？
スクラムは機能開発チーム、かんばんは継続的なフローやサポート、DevOpsのプラクティスは自らサービスを運用するチーム、ウォーターフォールやVモデルはスコープ固定や規制対象の作業に適しています。
ソフトウェアのプロジェクトマネジメントにおけるDORAメトリクスとは何ですか？
DevOps Research and Assessmentプログラムによる4つのデリバリー指標で、デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間です。
アジャイルチームでは誰がソフトウェアのプロジェクトマネジメントを行いますか？
責任は分担されます。プロダクトオーナーが優先順位を管理し、チームが自らの作業を計画し、スクラムマスターがファシリテートし、テクニカルプロジェクトマネージャーがチーム間を調整することもあります。
ソフトウェアのプロジェクトマネジメントではどのように見積もりますか？
次のような相対見積り ストーリーポイント を使うか、過去のスループットとサイクルタイムから予測し、日付は範囲で示します。
ソフトウェアのプロジェクトマネジメントではどのような文書を使いますか？
プロダクトバックログ、ユーザーストーリー、スプリント計画、リリース計画、ロードマップ、完成の定義、そして受託開発の場合は要件定義書です。
ソフトウェアのプロジェクトマネジメントにはどのようなソフトウェアが使われますか？
コードリポジトリと連携したJiraなどの課題管理ツールに加え、ソフトウェアの作業を他部門と一緒に計画する必要がある場合はWrikeなどのプラットフォームを使います。
ソフトウェアのプロジェクトマネジメントでは技術的負債をどのように扱いますか？
バックログで見えるようにし、イテレーションごとに返済のためのキャパシティを確保し、プロダクトオーナーとの計画の話し合いに含めます。
ソフトウェアのプロジェクトマネジメントとプロダクトマネジメントの違いは何ですか？
プロダクトマネジメントは何をなぜ作るかを決め、ソフトウェアのプロジェクトマネジメントはそれをどのように、いつ届けるかに焦点を当てます。
ソフトウェアのプロジェクトマネジメントにはどのようなスキルが必要ですか？
開発プロセスの理解、アジャイルのプラクティス、リスクと依存関係の管理、技術系とビジネス系のステークホルダーとのコミュニケーション、データに基づく予測です。