
プロジェクトマネジメントにおいて、成果物を「どうやって作るか(開発アプローチ)」を決めるのと同じくらい重要なのが、「いつ、どのようなペースで顧客(または本番環境)に届けるか」を設計することです。
PMBOKでは、この成果物を提供するリズムやペースのことを「デリバリー・ケイデンス(Delivery Cadence)」と呼んでいます。
ケイデンスとは元々、自転車のペダルを回すペースなどを指す言葉ですが、プロジェクトにおいては「価値を届けるリズム」を意味します。PMBOK第8版では、このデリバリー・ケイデンスを大きく4つのパターンに分類しています。それぞれの特徴と具体例を見ていきましょう。
単一のデリバリー(Single delivery)
プロジェクトの「一番最後」に、すべての成果物を一括でドカンと納品するパターンです。
- 特徴: プロジェクト期間中は一切の納品(本番リリース)がなく、最終日にすべてが公開・提供されます。従来の予測型(ウォーターフォール)開発で最も一般的な形です。
- 具体例: 業務プロセスの再構築(BPR)プロジェクト。システムやマニュアルがすべて完成し、新プロセスに切り替わる「カットオーバーの日」までは、現場に提供されるものはありません。
複数のデリバリー(Multiple deliveries)
プロジェクト期間中に、何度かのタイミングに分けて成果物を提供するパターンです。
- 特徴: 納品のタイミングはバラバラでも構いません。順番に提供していく場合(直列)もあれば、別々のチームが並行して完成したものを随時提供していく場合(並列)もあります。
- 具体例: 新薬の開発プロジェクト。「前臨床試験の結果」「フェーズ1の結果」「当局の承認」といった具合に、各関門を突破するごとにマイルストーンとして成果物が提出されます。
定期的なデリバリー(Periodic deliveries)
複数のデリバリーと似ていますが、「2週間ごと」「毎月月末」といったように、規則的で固定されたスケジュールに基づいて提供するパターンです。
- 特徴: 主に適応型(アジャイル)アプローチ、特にスクラム開発などでよく採用されるリズムです。一定のペースを保つことで、チームの作業予測が立てやすくなります。
- 具体例: スマートフォン向けアプリの開発。「2週間に1回」のペースで社内レビュー用のバージョン(内部デリバリー)を作成し、問題がなければそのまま市場(アプリストア)へリリースします。
継続的なデリバリー(Continuous delivery)
準備ができた(テストをクリアした)機能から、絶え間なく、次々と本番環境へリリースし続けるパターンです。
- 特徴: 現代のソフトウェア開発における最先端のアプローチです。「プロダクション・レディ(いつでも本番に出せる状態)」を常に維持し、人間の手作業を極力減らし、テストやデプロイ(展開)を「自動化」することで実現します。
- 具体例: 大手Webサービスやクラウドプラットフォーム。ユーザーが気づかないうちに、1日の間に何度も細かなバグ修正や機能追加が本番環境に反映されています。
「アプローチ」と「ケイデンス」は分けて考える
この「デリバリー・ケイデンス」を学ぶ上で大切なのは、「開発アプローチ(予測型か適応型か)」と「デリバリー・ケイデンス(納品ペース)」は、必ずしも1対1で固定されるものではない、という点です。
例えば、「開発自体はアジャイル(適応型)で2週間ごとに機能を作っている(定期的)けれど、顧客への納品は半年に1回まとめて行う(複数、または単一)」という組み合わせも十分にあり得ます。
顧客が「こまめに新機能を使いたい」のか、それとも「現場が混乱するから、リリースは年1回にまとめてほしい」のか。
どのように作るかという「開発手法」だけでなく、顧客が最も価値を受け取りやすい「納品のリズム」をテーラリング(調整)することも、これからのプロジェクトマネージャーに求められる重要なデザインスキルです。

