Wellingtoneは2016年からプロジェクト実務者を対象にアンケートを行ってきましたが、その間ずっと、上位2つの課題は常に同じ2つでした。それは、「トレーニングが不十分なプロジェクト管理者」と「あまりにも多くのプロジェクトを同時に進めようとする」ことです。2026年の報告書では、トレーニングの状況がようやく改善され、課題の順位は8位にまで下がりました。しかし、複数のプロジェクトを管理することの難しさは、依然として変わっていません。
複数のプロジェクトを管理するとは、進行中の複数のプロジェクトを1つのポートフォリオとして扱い、共有の優先順位付け、共有の人員配置、そして統一された意思決定サイクルのもとで運営することを指します。ほとんどすべてのガイドブックでは、これを「可視性の問題」として扱っており、そのため、ほぼすべてのガイドブックが結局のところ、より大きなダッシュボードの導入を推奨することになります。可視性は確かに役立ちます。しかし、最初に問題となるのはそこではありません。
要約: マルチプロジェクト管理とは、可視性という衣をまとった「引き算」の問題です。ポートフォリオを左右する重要な数値は「同時進行の上限」であり、これは1週間で実質的な意思決定を行えるプロジェクトの数を指します。 その上限を超えるものはすべて、管理されているのではなく、単に監視されているに過ぎません。このガイドでは、その上限の見つけ方、プロジェクトの受け入れ段階でそれを徹底する方法、スプレッドシートとポートフォリオ管理ソフトのどちらを選ぶべきかを正直に判断する方法、そして上限を定めた後にマルチプロジェクト・ポートフォリオをまとめるための7つのステップについて解説します。
複数のプロジェクトを管理するとはどういうことでしょうか?
複数のプロジェクトを管理するということは、同じ人材、予算、注意力を奪い合う個別のプロジェクトを調整しつつ、それぞれのプランを損なわないようにすることです。マルチプロジェクト管理では、各プロジェクトは独立したまま維持され、実際に管理するのは、それらのプロジェクトが共有する制約条件となります。
その境界線は常に曖昧になりがちで、それがコスト増につながります。PMIのライブラリに寄稿した実務家は、この問題を次のように端的に指摘しています。「プロジェクトで共有される要素が『あなた』だけであるなら、それらのスケジュールをマージする理由はありません。それでもマージしてしまうと、実際の疑問に答えるために誰も読み解けないプランを作り上げてしまうことになります。」
ここでは3つの用語が混同して使われていますが、自分が実際にどの手法をやっているかを把握することで、どのような成果物が必要かが分かります。
| 用語 | その役割とは | 成功とはどのようなものか | 通常、誰が責任者となるのでしょうか |
|---|---|---|---|
| 複数のプロジェクト | 人員やカレンダー時間を共有する、関連性のないプロジェクト | 各プロジェクトを確実に遂行し、誰のスケジュールも重複しないようにします | プロジェクトマネージャーやチームリーダーの方へ |
| プログラム | 関連するプロジェクトが接続して一つの成果を生み出す | たとえ1つのプロジェクトが遅延しても、全体としてのメリットは得られます | プログラムマネージャー |
| ポートフォリオ | 組織が資金提供を決定したすべてのプロジェクト | 仕事の組み合わせは戦略に沿っており、価値の低い仕事は削減される | PMOまたはポートフォリオマネージャー |
この情報を検索している人の多くは、最初の行のようなことをやることになっており、3行目のようなレポート作成を求められている状況にあります。
このガイドでは、PMO(プロジェクト管理オフィス)の意味での正式なポートフォリオではないプロジェクトであっても、一貫して「ポートフォリオ」という用語を使用しています。その理由は実用的なものです。プロジェクト間で人員や意思決定を共有するようになった瞬間、ガバナンスの層を除けば、ポートフォリオマネージャーが使用するのと同じ仕組みが必要になるからです。優先順位付けされたリスト、キャパシティの可視化、そして中止の仕組みが必要となります。
あわせて読みたい:プロジェクト管理・プログラム管理・ポートフォリオ管理:全体像を解き明かす
なぜ複数のプロジェクトを管理するとうまくいかなくなるのか
複数のプロジェクトを並行して進める仕事が失敗する原因は、4つの明確なパターンがありますが、その中には「努力不足」や「頑張り不足」は含まれません。それぞれの原因には異なる解決策があるため、画一的なアドバイスではうまくいかないのです。
「共有されている人物」こそが真の依存関係なのです
2つのプロジェクトのタイムラインが明確で互いに独立していても、同じシニアエンジニアが両方のクリティカルパスに位置している場合、スケジュールが衝突することがあります。タイムライン管理ソフトは日付を表示しますが、プリヤが3つすべてのプランにおいて第3週、第4週、第7週の制約要因となっていることを示すことはめったにありません。ウェリングトーンの調査回答者たちは、リソース管理をプロジェクト管理のどの段階においても定着させるのが最も難しいプロセスの一つとして挙げています。なぜなら、この競合は1つのプラン内部ではなく、プラン間の境界で生じるからです。
所有するすべてのプランにおいて、切り替えコストは目に見えないものです
どのプランにも、「集中力を取り戻す」ためのアイテムは含まれていません。Microsoftの「2025年ワークトレンドインデックス」特別レポートによると、従業員はコアタイム中に2分おきに作業を中断されていることが明らかになりました。31,000人のナレッジワーカーを対象とした付随するアンケートでは、従業員の48%、管理職の52%が、仕事が混沌としていて断片化されていると感じていると回答しました。誰かの担当に3つ目のプロジェクトを追加しても、作業負荷が3分の1増えただけというわけではありません。 その人に、作業に戻るたびに再調整しなければならない新たな状況のセットを課したことになるのです。
レポート作成が、節約しようとしていた時間を奪ってしまう
担当するプロジェクトが増えれば増えるほど、その説明に費やす時間が週の中で多くなります。ウェリントンの調査データによると、回答者の72%が毎月半日以上を費やして、プロジェクトのステータス情報を手作業でまとめています。約半数は、リアルタイムのプロジェクトKPIにアクセスできません。これは、プロジェクトを「舵取り」するのではなく、単に「説明」しているに過ぎません。人が手作業で作成したステータス報告書は、読まれる時点で既に古い情報となっています。
いかなる者も、いかなる業務も停止する権限はありません
この問題が最も深刻な被害をもたらすのは、それが最も可視性が低いからです。プロジェクトは、緊急性があるという理由で誰にでも追加されてしまいますが、削除されることはほとんどありません。あまりにも多くのチームが、あらゆるアイデアがプロジェクト化されるのを防ぐための明確な選択基準を持っていません。停止メカニズムがなければ、ポートフォリオは膨れ上がる一方となり、その中の各プロジェクトは手薄になっていきます。
複数のプロジェクトを1つのシステムとして管理すると、何が変わるのか
複数のプロジェクトを1つのシステムとして管理することで、3つの点が変化します。プロジェクトが緊急事態になる前に注目が集まるようになり、あるプロジェクトの遅れが他のプロジェクトに静かに波及するのを防ぎ、新しい依頼が山積みになるのではなく、比較検討されるようになるのです。上記の失敗例は、システムがない場合に何が起こるかを示しています。システムを導入することで、どのような変化が生まれるのかをご紹介します。
困難なプロジェクトには注目が集まります
管理されていないポートフォリオは「騒音曲線」に従います。つまり、最も騒ぎを起こしているプロジェクトが最も注目を集めるのです。複数のプロジェクトを効率的に管理している場合、この状況は変わります。意思決定に割けるリソースには限りがあることを理解しているため、後で修正するのに多額のコストがかかる初期フェーズのプロジェクトや、予定通りに進んでいないプロジェクトに、相対的に多くのリソースを割り当てるようになります。6週目に突然問題が発生する「静かなプロジェクト」は、ほぼ例外なく、2週目から5週目にかけて誰も意思決定の時間を割り当てていなかったプロジェクトなのです。
あるプロジェクトでの遅れが、他の3つのプロジェクトへと静かに波及するのを防ぎましょう
ベースラインが設定されたポートフォリオであれば、プロジェクトBが1週間遅れたことで、共有されているデザイナーがプロジェクトDのレビュー段階と競合してしまうことが一目でわかります。一方、ベースラインが設定されていないポートフォリオでは、その遅れが表に出ることなく吸収されてしまいます。2つのプロジェクトが同じ月に完了できなくなるまで、誰も気づかないのです。
長期的な影響は大きな損失につながる可能性があります。1つのプロジェクトが1週間遅れた程度なら挽回可能です。しかし、同じ根本原因によって3つのプロジェクトがそれぞれ4日ずつ遅れた場合、四半期全体の利益を失うことにもなりかねません。
新たな依頼は、ポートフォリオを薄めるのではなく、むしろ充実させるものです
「受け入れゲート」がなければ、新しいプロジェクトはすべて追加されていくだけです。しかし、それがあれば、新しい依頼は「強制機能」となります。これにより、既存の優先順位の可視性が確保され、比較(「これは現在5番目にあるものよりも価値があるか?」)が求められるようになり、その過程で「ゾンビプロジェクト」を排除できることもあります。
チームに適切な「受付ゲート」が整備されていれば、何を追加するかという会話は、何を中止するかという会話へと変わり、ポートフォリオは広がっていくのではなく、その都度より洗練されたものになっていきます。
「並行処理の限界」:可視性を高めただけでは、過負荷のポートフォリオの問題は解決しない理由
「同時進行の上限」とは、1週間のうちに実質的な決定を下せるプロジェクトの数を指します。ここで重要なのは「追跡」ではなく「決定」です。その上限を超える分は、管理されているというより、単に監視されているに過ぎません。
多くの人が見落としているのは、この視点の転換です。彼らは、問題の原因を「すべてを把握できないこと」だと決めつけ、統合されたビューを提案します。しかし、5つのプロジェクトを管理する権限と余裕しかないマネージャーに、14のプロジェクトを表示するダッシュボードを見せても、何も解決しません。それは単に過負荷を可視化したに過ぎず、可視化された過負荷はかえって辛く感じられます。なぜなら、自分が手薄にしているすべてのプロジェクトをリアルタイムで目の当たりにしてしまうからです。
ヨハンナ・ロスマン氏は、まさにこの問題にキャリアを捧げてきており、このテーマに関する著書も執筆しています。同氏は著書『Manage Your Project Portfolio』の中で、この分野全体を次のように定義しています:
すべてをやることが可能です。ただ、すべてを同時にやることできません。
すべてをやることが可能です。ただ、すべてを同時にやることできません。
ロスマン氏は、ポートフォリオ管理に高度な統計学や複雑な数学は必要ないと明言しています。必要なのは、仕事を「最優先」から「実施しない」まで順位付けする意思のある人々です。実際に重要な計算は、ナプキンに書き留められる程度の簡単なものです。
毎週、プロジェクトの意思決定に実際に割ける時間を数えてみてください。これには、ステータスの確認、障害の解消、スコープの再交渉、優先順位の再設定などが含まれます。納品業務に加え、自身の成果物も担当している多くの人にとって、その時間は40時間ではなく、4~6時間程度です。
次に、プロジェクトごとの意思決定コストを見積もります。順調に進行しているプロジェクトなら週に約45分、初期段階のプロジェクトや政治的な要素が絡むプロジェクト、あるいは軌道から外れているプロジェクトの場合は2時間近くかかります。ほとんどのポートフォリオは、こうしたプロジェクトが混在しています。例えば、順調なプロジェクトが3つ、困難なプロジェクトが2つある場合、(3 × 0.75)+(2 × 2)=6.25時間の意思決定コストとなります。
意思決定に5時間しか割けないマネージャーは、すでに予定を1時間以上超過しており、最も注意を必要とするにもかかわらず、最も手薄になりがちな困難なプロジェクトが真っ先に犠牲になってしまいます。
ここで重要なのは、番号が会話にどのような影響を与えるかという点です。「手一杯です」というのは、ステークホルダーが異議を唱える余地のある感覚に過ぎません。一方、「私のキャパシティは4つですが、現在は8つを抱えています。そこで、一時停止することを提案する4つはこちらです」という言い方であれば、ステークホルダーはあなたと共にその判断を下さなければなりません。
すべてのマルチプロジェクトシステムに不可欠なもの
どのようなツールを使って構築する場合でも、機能するマルチプロジェクトシステムには以下の10の要素が備わっています。これらの一つでも欠けていると、特定かつ予測可能な失敗を招くことになります。
- プロジェクトの完全な一覧。誰も承認していないプロジェクトも含め、進行中のすべてのプロジェクトを1つのリストにまとめます
- プロジェクトごとに所有者を1名指定する。所有者となるのは1人の個人であり、決してチーム名にしてはいけません。
- 明確な順位付け。「高」という3段階の分類ではなく、1位から最下位までの順序付きリスト
- 同時進行の上限。一度に進行できるプロジェクトの最大数として合意された数
- 人員の割り当てマップ。誰が複数のプロジェクトにコミットしており、どの週にどのプロジェクトに従事しているか
- プロジェクト間の依存関係。あるプロジェクトが別のプロジェクトの成果を待つような引き継ぎ
- プロジェクトごとのベースライン。当初のスケジュールと範囲を明確にしておくことで、遅延を記憶に頼るのではなく、数値的に把握できるようになります
- インテークゲート。新規のリクエストがプロジェクトになる前に通過する、明確に定義されたプロセス
- 停止メカニズム。仕事を一時停止または中止する権限を持つ、特定の担当者または会議の場
- レビューの頻度。順位が実際に変動してもよいとされる、毎週決まった時間帯を設けること
「ベースライン」については、ひと息ついてじっくり検討する価値があります。ウェリングトンのアンケートによると、回答者の3分の1がベースラインが設定されていないプロジェクトを抱えており、その結果、ポートフォリオ全体において「進捗は遅れているのか?」という質問に答えることが不可能になってしまいます。
7つのステップで複数のプロジェクトを管理する方法
これらのステップは、使用するツールに依存しません。いずれもスプレッドシートで実行可能ですが、スプレッドシートだけでは限界を感じる段階を過ぎれば、専用のソフトウェアと併用することでより効果的に機能します。
ステップ1:すべてのプロジェクトを整理し、それぞれに所有者を1名ずつ指定する
進行中のプロジェクトをすべて1ページにリストアップしましょう。頼まれて引き受けたもの、形式上は中断中だが依然としてメッセージが入ってくるもの、引き継いだプロジェクトなども含めます。それぞれのプロジェクトに、必ず1人の担当者の名前を割り当ててください。
このステップでは、ほぼ例外なく、予想以上に件数が増えてしまい、多くの人が驚きます。自分の業務量を「4つのキャンペーン」と説明するマーケティング担当者は、ウェブサイトのリニューアル、定期的なニュースレターの刷新、そして2件のベンダー移行を加算すると、通常は9アイテムを書き出すことになります。実際に書き出したことのない数字に対して、上限を設定することはできません。
ステップ2:リストを「1」から「決して」の順にランク付けする
一貫した順序を徹底しましょう。2つのプロジェクトが同順位を共有した場合、その後、より粘り強く電子メールを送り続けた方が優先されます。
プロジェクトの優先順位は、要求の声がどれほど大きいかではなく、期待される価値と遅延によるコストに基づいて付けましょう。「絶対にやらない」というカテゴリーは、最優先のプロジェクトと同じくらい重要です。率直に断ったプロジェクトは、もはや注意力を奪うことはありませんが、曖昧なまま放置されているプロジェクトは、決断を迫り続け、コストを発生させ続けることになります。
ステップ3:並行処理の上限を設定し、案件の受け入れ時にそれを徹底する
上記の「意思決定時間」の計算式を使って上限値を算出し、それを厳守すべき数値として扱ってください。ポートフォリオが満杯になった場合、何かが終了するか一時停止するまで、新しいプロジェクトを開始することはできません。
これはタスクの1つ上のレベルに適用される「作業中のリミット」であり、カンバンチームがボード上で用いるのと同じロジックを取り入れています。この仕組みを機能させる鍵となるのが「インテークゲート」です。新しい依頼が入り、優先順位が付けられ、既存のタスクを置き換えるか、あるいは待機することになります。ゲートがなければ、リミットは単なる好みで済んでしまいます。ゲートがあれば、リミットはルールとなり、「まだです」という返答は、単なる謝罪ではなく、正当な理由として受け入れられるようになります。
ステップ4:共有されるタイムラインではなく、共有される人員を把握する
週単位で、誰がどのプロジェクトにコミットされているかを可視化しましょう。このキャパシティプランニングの確認は、複数のプロジェクトを並行して進める上で最も有用なステップですが、多くのチームがこれを省略してしまいます。
必要なのは、次の2つのことです:
- プロジェクト全体で約80%を超えるコミットメントを抱えている人は、その水準を超えると、たった一つの変更がプランを狂わせ始めるという閾値に達しています
- 同じ2週間の間に3つのプランに名前が挙がる専門家。これは、個々のプロジェクトプランでは決して指摘されないような日程の衝突です
スプレッドシートでは、縦軸に担当者、横軸に週を配置した表になります。ポートフォリオ管理ソフトウェアでは、これは「ワークロードビュー」として表示されます。いずれの場合も、得られる結果は同じです。つまり、月が明けてからではなく、その月が始まる前に再調整すべき担当者の短いリストが得られるのです。
各プロジェクトの締め切りと実際の空き時間を照らし合わせたプロジェクト管理カレンダーを使えば、予定の衝突を、実際に発生する当日の朝ではなく、1週間前に可視化することができます。
ステップ5:すべてを網羅する1つのビューではなく、意思決定ごとに1つのビューを作成する
各ビューは、それが答えるべき質問を中心に設計し、その回答に役立たない要素はすべて削除してください。あらゆるユーザー層に対応しようとする単一のビューは、結局誰の役にも立ちません。
ほとんどのポートフォリオは、以下の3つのビューで網羅されます:
- プロジェクト、所有者、フェーズ、次のマイルストーン、フラグを1行ずつ表示するポートフォリオの健全性ビュー
- 1人あたりの週ごとの割り当て状況を示すキャパシティビュー
- すべてのプロジェクトにわたって、今後7日以内に期限を迎えるタスクのみを表示した「今週ビュー」
経営幹部は1つ目を読んで、2つ目と3つ目は実行に移してください。4つ目の「すべてのビュー」を構築しようとすると、ダッシュボードが放置されてしまう原因になります。
ステップ6:毎週、「中止か継続か」の検討会を実施する
毎週30分の定例枠を1つ設け、そこで順位が実際に変動したり、何かを一時停止したりできるようにしましょう。このミーティングの目的はただ1つ、何かを一時停止するか順位を見直して、その週を締めくくることです。
アジェンダは3つの質問です。「共有メンバーマップで何が変わったか?」「現在、どのプロジェクトが制約となっているか?」「優先順位の上位を守るために、何を中止または延期するか?」もしこのミーティングで何も一時停止されない場合、それは単なるステータス報告会に成り下がっており、その兆候として出席者の集中力が徐々に散漫になっていくことが挙げられます。
また、「中止」を宣言できる担当者を明確に指定することも不可欠です。週次レビューが機能するのは、その場にいる誰かが、上層部への報告を経ずにプロジェクトを一時停止する権限を持っている場合に限られます。多くのチームでは、その役割はディレクター、PMOリーダー、または部門長が担います。小規模なチームでは、人員配置を管理する者がその役割を担います。その担当者の名前を、レビューの定例業務範囲(Terms of Reference)に明記してください。その場にプロジェクトを一時停止できる権限を持つ者がいない場合、そのミーティングは単なる助言の場にとどまります。
ステップ7:調整に費やす時間から「制作時間」を守る
プロジェクトが1つ増えるごとに、成果が生まれる速度よりもはるかに速いペースで、ミーティングやスレッド、進捗確認の数が膨れ上がります。調整業務はまとめて行い、実際に仕事が行われる時間をしっかりと確保しましょう。
プロジェクト横断的なステータス確認をすべて同じ2日間に集中させ、その他の日は定期的なミーティングを入れないようにすることを検討してください。ステータスの共有には、電話ミーティングの代わりに文書による報告や非同期のコミュニケーションを活用しましょう。ロスマンはここで、コンテキストスイッチとマルチタスクの間に有用な区別を設けています。各プロジェクトを整理された状態で切り替えるのであれば、コンテキストスイッチは対処可能ですが、マルチタスクではすべてのプロジェクトを同時に抱え込むことになってしまいます。
3つのコードベースを扱うエンジニアは、各プロジェクトに異なるエディターの色を設定することで、この問題を解決することがよくあります。脳が認識する前に、目がどのプロジェクトを扱っているかを把握できるからです。これにより、切り替えにかかる負担がなくなるわけではありませんが、再読み込みにかかる時間は短縮されます。
複数のプロジェクトを追跡するためのシステムの選び方
複数のプロジェクトを追跡するための現実的な選択肢は3つあります。Wellingtoneの調査によると、回答者の22%は依然としてMicrosoft Excelでプランを立てており、さらに11%はプロジェクト管理ソリューションを一切使用していないことがわかりました。この業界の3分の1は、スプレッドシートや頭の中で管理を行っており、その多くが問題なく業務をこなしています。
| アプローチ | その有効性 | 限界に達する場面 | こんな方に最適 |
|---|---|---|---|
| スプレッドシート(Excel、Google スプレッドシート) | プロジェクトごとに1行、列は自由に設定可能、セットアップ費用はゼロ | あなた以外誰も更新しない;要約と実際の仕事との間にリンクがない | 各プロジェクトに1人の所有者がいる、2~6つのプロジェクト |
| 単一プロジェクト向けツール(Trello、Jira、Microsoft Project) | 1つのプロジェクトのワークフローの中でも優れた手法 | プロジェクト横断的なロールアップは、アドオン、プラグイン、または手動でのエクスポートです | プロジェクト間で人員がまったく共有されていないチーム |
| ポートフォリオ管理機能を備えたソフトウェア(ClickUp、Asana、monday.com、Smartsheet、Wrike) | ロールアップビュー、プロジェクト横断的な作業負荷、ステータスの自動化 | 成果が出るには階層的な意思決定が必要であり、簡単なリストを作成するだけの場合に比べて、より多くのセットアップを要します | 6つ以上のプロジェクトがリソースプールを共有している場合 |
スプレッドシート
スプレッドシートを使えば、プロジェクトごとに1行ずつ、所有者、フェーズ、次のマイルストーン、進捗状況のフラグを簡単に記載できます。要約を行う段階では、実に有効な手段です。
問題は技術的なものではなく、構造的なものです。スプレッドシートは現実を反映したものであり、最後の手動更新時点での情報しか反映されていません。Excelでの複数プロジェクトのガントチャート作成は可能であり、実際に頻繁に作成されていますが、リンクされたタスクがおよそ15件を超えると、依存関係の編集が不安定になりがちです。
こんな場合に最適: 2~6つのプロジェクトがあり、プロジェクト横断的なビューを把握する必要があるのがあなただけの場合こんな場合はスキップ: 正確な情報を維持する必要がある人が複数いる場合、またはプロジェクト間で人員が共有されており、その人員のキャパシティを把握する必要がある場合
単一プロジェクト向けツール
Trello、Jira、Microsoft Projectは、それぞれのプロジェクトのワークフローにおいて強力なツールです。可視性の高い仕事を行う小規模チームにとっては、Trelloのボード型モデルに勝るものはありませんし、Jiraのプロジェクト管理モデルはエンジニアリング業務の処理能力を高めるために設計されています。
そのリミットは継ぎ目に現れます。これらはいずれも、1つのプロジェクトのボード、バックログ、またはスケジュールを中心に構成されているからです。プロジェクト全体を俯瞰するには、通常、プラグインやマスターファイル、あるいは金曜日に誰かがスプレッドシートにデータをエクスポートする必要があります。プロジェクトが3つならまだ何とかできますが、9つになると非常に負担が大きくなります。
最適なケース: すでに特定のエコシステムに深く組み込まれており、プロジェクト間で同じ人材が起用されることがほとんどないチーム避けるべきケース: 「来月、誰が過負荷になるか」という、プロジェクト横断的な疑問が主な関心事である場合。これらのツールは、そのような疑問には間接的にしか答えられません
ポートフォリオ管理機能を備えたソフトウェア
ClickUp、Asana、monday.com、Smartsheet、Wrikeはいずれもポートフォリオ機能に対応しています。これは、各プロジェクトをステータス、所有者、日程が記載されたレコードとして扱うビューに加え、プロジェクトを横断して1人あたりの作業量を表示するワークロードビューを備えていることを意味します。この機能により、データをエクスポートすることなく、プロジェクト横断的な疑問に直接答えることができます。
正直なところ、初期段階での綿密な検討にコストがかかります。これらのツールはすべて、まず階層を決定することを求めており、第1週目に不適切な階層を選んでしまうと、第6ヶ月になってそれを修正するのは非常に面倒です。プロジェクト数が6件未満の場合、セットアップにかかる労力が報われることはほとんどありません。
最適なケース: 共有リソースプールを活用する、6つ以上の並行プロジェクトがある場合。 適用しない場合: プロジェクトが3つあり、全員がすでに参照しているスプレッドシートがある場合。
カテゴリー別ではなくツールごとの比較をお探しの方には、小規模チーム向けのプロジェクト管理ソフトウェア特集で、エントリーレベルの製品を網羅しています。その層に何を組み込むべきかについてさらに詳しく知りたい場合は、より広範なプロジェクトポートフォリオ管理プロセスの解説記事をご覧ください。
また、プロジェクト全体のリソース管理やキャパシティプランニングを改善するために、以下のAIツールの活用も検討してみてください:
締め切りが重なる複数のプロジェクトを、どのように優先順位付けすればよいでしょうか?
期限の近さではなく、「遅延コスト」に基づいて優先順位を決めましょう。期限は「誰かがいつまでに何かを求めたか」を示すものですが、遅延コストは「期限がずれた場合に実際に何が起こるか」を示します。2つの日程が真に競合している場合、役立つのはこの遅延コストという指標だけです。
2つのプロジェクトが同じ週に重なる場合は、次の4つの質問を順番に自問してみてください:
- もし2週間遅れたら、何が問題になるでしょうか?「規制上の期限」「契約上の違約金」「できれば実現したいローンチ」――これら3つが異なる答えとなります
- 締め切りは外部からのものですか、それとも社内でのものですか?社内の締め切りは交渉の余地があることが多く、厳格に守られることはめったにありません
- 下流で待機しているのは他に誰がいるでしょうか?他の2つのチームのボトルネックを解消するプロジェクトは、誰のボトルネックも解消しないプロジェクトよりも優先度が高いのです
- 分割は可能でしょうか?依存関係を解消する部分を先にリリースすることで、多くの場合、その競合は完全に解消されます
そして、ステークホルダーへの回答は個別にではなく、まとめて提示しましょう。納期が競合する状況では、通常、双方が「自分たちの納期だけが唯一正しい」と信じているものです。4つのスレッドでやり取りするよりも、1つの部屋で直接話し合った方が、対立はより早く解決します。アイゼンハワー・マトリックスは、個人レベルでのこの問題に対する合理的な最初の選別ツールですが、プロジェクトの所有者が自分以外の人物になると、その有効性は薄れてしまいます。
複数のプロジェクトを1ヶ月目以降も円滑に継続させる方法
多くのマルチプロジェクト管理システムは、導入当初は機能しても、6週間も経たないうちに静かに廃れてしまいます。上記の7つのステップを実践すれば、機能するポートフォリオを構築できます。これらの手法を実践することで、誰も開かないような「単なる飾り物」へと朽ち果てるのを防ぐことができます。
構成が変わった場合は、上限値を再算出してください
並行処理の限界値は、現在の「安定したプロジェクト」と「困難なプロジェクト」の組み合わせに対してのみ有効です。プロジェクトが最終スプリントに入った場合、新しいステークホルダーが加わった場合、あるいはスコープの再交渉が行われた場合など、あらゆる要因によって、意思決定にかかるコストが45分から2時間に変化する可能性があります。少なくとも毎月再計算を行い、その数値を一度きりの決定ではなく、週次レビューの継続的な成果として扱ってください。
「共有メンバーマップ」の更新担当者をローテーションで回す
キャパシティビューの管理をたった1人に任せてしまうと、その人が休暇を取ったり、納品業務に追われたりした週には、その情報は機能しなくなってしまいます。スプリントごと、あるいは月ごとに所有者をローテーションで割り当てましょう。その週に誰かの名前が記載されているからこそ、マップは常に最新の状態を保てるのです。全員が等しく正確さを重視しているからではありません。
当初のプランが何だったか忘れてしまう前に、ベースラインを設定しておきましょう
ベースラインを保存せずに開始したプロジェクトは、最初の変更が反映された時点で成果を測定できなくなってしまいます。たとえプランがまだ大まかなものであっても、実際の仕事を開始してから最初の1週間以内にプロジェクトのベースラインを確定させてください。比較の基準となる大まかなベースラインは、保存さえされていない完璧なプランよりも、はるかに有用です。
毎月、「ゾンビプロジェクト」の状況を点検しましょう
3ヶ月前に一時停止されたものの、正式に打ち切られていないプロジェクトは、依然として質問やミーティング、そして罪悪感を生み出し続けています。月に一度、優先順位リストの下位をざっと確認し、「過去30日間に、これについて誰かが決定を下したか?」と自問してみてください。もしない場合は、そのプロジェクトを明確に「中止」状態に移行させましょう。中止されたプロジェクトにはコストはかかりません。一方、曖昧な状態で存続しているプロジェクトは、誰かが「まだ進行中なのか」と疑問に思うたびに、注意力を奪うことになります。
レポート作成層と意思決定層を分離する
ポートフォリオの全体像が経営陣への報告資料となる瞬間、正確さよりもストーリー性を重視して最適化し始めることになります。真実(フラグ、キャパシティ、阻害要因)を伝える明快な運用ビューと、ステークホルダーにストーリーを伝える別のプロジェクトモニタリング層を分けて管理しましょう。これらを同一にしてしまうと、真っ先に真実が失われてしまいます。
3つのポートフォリオ、3つの異なる形
同じ7つのステップでも、プロジェクト間で共有される要素によって、生成されるシステムは大きく異なります。ここでは、3つの一般的なケースにおける成果物の例をご紹介します。
6人のスタッフで11件のクライアントプロジェクトを運営しているエージェンシー
ここでの制約要因は、請求可能な人員であり、各プロジェクトの形はほぼ同一です。優先順位の決定要因は主に商業的なもので、プロジェクトクライアントよりもリテーナー契約のクライアントを優先し、更新四半期のクライアントをその他のクライアントよりも優先します。重要な指標はキャパシティビューです。なぜなら、7つのブランドを1人のデザイナーが担当していることが、リスクのすべてだからです。
ここでいう並行処理の上限は、ポートフォリオごとではなく、1人あたりに適用されます。つまり、各人が同時に進行中のクライアントプロジェクトは2つまでとし、3つ目については、そのうち1つがレビュー段階にある場合に限り許可されます。スコープクリープは、週次レビューの段階で発見されるものです。
4つの取り組みを推進している社内プロダクトチーム
社内チームの場合、プロジェクト数は少ないかもしれませんが、プロジェクト間の相互依存関係はより深いものです。2つのイニシアチブが同じ基盤となる仕事を待っている確率が高く、そのため、キャパシティよりもプロジェクト間の依存関係の方が重要になります。優先順位は依存関係図に基づいて決定すべきです。たとえ経営陣からは最も可視性が低い仕事であっても、下流の仕事のボトルネックを最も多く解消できるものが最優先となります。
上限は低く、多くの場合3つ程度です。なぜなら、各イニシアチブには単なる調整ではなく、真の意味での設計やエンジニアリングの思考が求められるからです。失敗のパターンは、顧客への提供日が定まっていないためにプラットフォームプロジェクトの優先順位が下がり、その結果、それに続くすべての作業が停滞してしまうことです。
5つの現場を統括する建設マネージャー
複数の建設プロジェクトを管理する場合、通常の優先度とは逆になります。共通の制約となるのは、機材、下請け業者、検査期間であり、これらにはソフトウェアでは解消できない現実的な工程コストが伴います。例えば、現場Bで予約されていたクレーンが間違った週に割り当てられてしまうと、現場Bでは人手が遊休状態になり、現場Cでは検査日程の再調整が必要になります。そこで重要なのが、各現場のスケジュールよりも優先して管理される、機材や下請け業者を網羅した共有リソースカレンダーです。
現場への立ち会いには代替手段がないため、上限は意思決定にかかる時間と同じくらい、移動時間によって設定されます。ここでは、天候のせいでそれ以上の間隔を一定に保つことが難しくなるため、週次レビューは文字通り「毎週」行われます。
マルチプロジェクト・ポートフォリオを台無しにする5つの失敗
複数のプロジェクトを扱うポートフォリオを台無しにしてしまう5つの過ちとは、共有されていないプランをマージしてしまうこと、「高優先度」を単なるランクとして扱うこと、個人単位ではなくポートフォリオ単位で上限を設定すること、意思決定を行う代わりにステータス報告に終始すること、そして100%のキャパシティを前提に計画を立てることです。それぞれをその「症状」として挙げる価値があります。なぜなら、そうすることで問題に気づくことができるからです。この記事を読んでいる方のほとんどは、少なくとも3つはこうした過ちを犯したことがあるでしょう。
あなた以外には共有されていないプランをマージする
具体例: 共有リソースや引き継ぎがないプロジェクトをまとめたマスタースケジュール。しかし、どちらのプロジェクト所有者の疑問にも答えられないため、誰もそのスケジュールを開こうとしない。
解決策: 各プロジェクトごとに個別のプランを立て、その上に簡潔な要約層を構築します。スケジュールは、真の依存関係や共有の担当者が存在する部分のみをマージしてください。
「高優先度」をランクとして扱う
具体的な状況: 6つのプロジェクトが「優先度高」とタグ付けされており、毎日注目されるのは、最も最近フォローアップを行ったステークホルダーが担当するプロジェクトです。
解決策: 順序付きリストを強制します。順位は整数であり、2つのプロジェクトが同時に3位になることはありません。
1人あたりではなく、ポートフォリオ全体の上限を設定する
具体例: チーム全体で進行中のプロジェクト数を8件までに制限することに合意しているにもかかわらず、あるデザイナーは依然として6件のプロジェクトに携わっている。ポートフォリオ全体としてのリミットは守られている一方で、個々のメンバーは自身のリミットをはるかに超えてしまっている。
解決策: 実際に仕事が行われる範囲に上限を設定しましょう。1人あたりの同時進行プロジェクト数を制限し、ポートフォリオ全体の総数は、それらの制限数の合計となるようにします。
意思決定ではなく、ステータス報告を行う
具体的な状況: 毎週行われるポートフォリオミーティングで、各プロジェクト所有者が自身のプロジェクトについて説明するが、優先順位の見直しは一切行われず、同じ障害要因が3週連続のメモに記されている。
解決策:進捗報告を自動化し、ミーティングでは制約条件とトレードオフの検討にのみ時間を割くようにしましょう。
100%のキャパシティを見込んだ計画立案
具体的な状況: 各メンバーは複数のプロジェクトにフルで割り当てられているため、1人の欠勤や1つのスコープ変更が、3つのプランに波及してしまう。
解決策: 人員配置を約80%程度に抑え、意図的に余裕を持たせておきましょう。複数のプロジェクトからなるポートフォリオにおいて、この「余裕」こそが変動を吸収する唯一の要素です。数値を用いてその必要性を説得する必要がある場合、この「余裕」の可視性を高めるメトリクスが「フロー効率」です。
ClickUpで複数のプロジェクトを管理する方法
ClickUpは前述のポートフォリオ管理機能を備えたカテゴリーに属しており、マルチプロジェクトの仕事において重要な要素は、本ガイドですでに説明した成果物と対応しています。

- ClickUpのダッシュボードは、ポートフォリオの健全性を一目で把握できるビューです。プロジェクトごとに1枚のカードを作成し、所有者、フェーズ、ステータスを表示します。これらは、金曜日にエクスポートしたデータではなく、リアルタイムのタスクデータから生成されます。実務担当者の72%が、こうしたレポートを手作業でまとめているのが現状です。
- ClickUpの「ワークロードビュー」は、ステップ4で紹介したメンバーの共有マップであり、1人あたりのキャパシティを時間、タスク、またはストーリーポイント単位で設定できます。過負荷の状態は、単なる直感ではなく数値として明確に表示されます
- ボードビューの「作業中」リミットを設定することで、ステップ3で設定した並行処理の上限を、チームが実際に目にするレベルで適用できるようになります
- ガントチャートには、プロジェクト間の依存関係やクリティカルパスが示されています。このクリティカルパスこそが、前述の製品チームにとって成否を左右する重要な要素なのです
- ClickUp Brainと専門的な自律型スーパーエージェントが、ポートフォリオに関する質問を平易な言葉で回答します。どのプロジェクトが遅れをとっているか、またその担当者が誰かを把握するために、わざわざレポートを作成する必要はもうありません

実践例: ニューヨークのブランディングエージェンシー「Plus972」(従業員50名未満)は、1つのワークスペース内で30件以上のクライアント案件を並行して進行させています。具体的には、3つの開発チーム、デザインチーム、プロジェクトマネージャー(PM)、およびプリセールス業務が連携しています。このセットアップは、前述したのと同じアーティファクトに基づいています。 各スペースは実際のビジネス機能に対応しており、上部にはポートフォリオビューが表示され、ダッシュボードでは、かつてはステータス報告としてやり取りされていたSlackのメッセージのやり取りに代わって、キャパシティや障害要因がリアルタイムで可視化されています。
シニアプロジェクトマネージャーのカテリーナ・ブリク氏は、以前、チームが「システムを頭の中で把握することで、エージェンシーのスケジュールを守っていた」と述べています。
率直なリミット
このカテゴリの他のツールと同様に、ClickUpではポートフォリオビューを有効に活用する前に、「スペース」「フォルダ」「リスト」の階層構造を決定する必要があります。そのため、単一の目的のためのタスク管理ツールから移行してきたチームは、通常、最初の1週間をプロジェクトそのものではなく、この階層構造の決定に費やすことになります。プロジェクトが2つまたは3つで、それぞれに所有者が1人ずついる場合は、共有スプレッドシートを使った方が、実用的な要約を素早く作成できます。 ClickUpが最も適しているのは、プロジェクト数が担当者の人数を上回り、プロジェクトをまたぐ質問が毎週寄せられるようになった場合です。
「引き算」から始めましょう
もしここから一つだけ学ぶことがあるとすれば、それは「数える」ことです。進行中のプロジェクトをすべて書き出し、意思決定に実際に割ける週あたりの時間を算出し、それを割ってみてください。算出された数字が「同時進行の上限」となります。それを超えるプロジェクトは、自覚があるかどうかに関わらず、すでに疎かになっているのです。
そして、さらに難しい部分に取り組みましょう。リストに優先順位をつけ、プロジェクトを中止できる権限を持つ人物を特定し、中止が許可される週単位の枠をカレンダーに確保してください。ウェリングトンの10年にわたるデータによると、業務量そのものは決してスキルの問題ではなく、個人の能力がどれほど優れていても、増え続けるポートフォリオの問題を解決することはできないことが示されています。
上限が設定され、ランクが確定すれば、ソフトウェアは単なるプロジェクトの保管場所ではなく、プロジェクト横断的な疑問に答えてくれるツールへと変わります。ClickUpを無料で使い始め、1つのワークスペースでポートフォリオビュー、ワークロードマップ、ウィークリーレビューを構築しましょう。
複数のプロジェクトの管理に関するよくある質問
1人が一度に管理すべきプロジェクトの数はいくつでしょうか?
ほとんどの人は、実際には3~5つのプロジェクトを並行して管理することが可能です。その正確な数は、プロジェクトのサイズよりも「意思決定コスト」によって決まります。プロジェクトの意思決定に充てられる週当たりの時間を、順調に進んでいるプロジェクトなら1件あたり週約45分、初期段階のプロジェクトや政治的な要素が絡むプロジェクト、あるいは予定から外れているプロジェクトなら1件あたり週2時間で割ってみてください。PMIのライブラリに寄稿している実務家たちは、3つのプロジェクトを同時に進めることは可能だが、1つだけを進める場合よりも時間がかかり、ストレスも大きいと述べています。
面接で「複数のプロジェクトをどのように管理していますか」と聞かれたら、どう答えますか?
「優先順位をつける」といった抽象的な言葉ではなく、具体的なシステムや実際に取ったトレードオフを挙げて回答してください。プロジェクトの数、優先順位の付け方、競合を特定するために使用したツール、そしてその結果として一時停止または再交渉したプロジェクトを1つ挙げてください。面接官は、あなたが根拠に基づいて「ノー」と言えるかどうかを判断しようとしています。そのため、すべてを完了させたという回答よりも、中止した事例を含む回答の方が説得力があります。
プロジェクト管理において「80/20の法則」とは何でしょうか?
80/20の法則、すなわちパレートの法則によれば、プロジェクトの成果の約80%は、仕事全体の約20%から生じるとされています。これを複数のプロジェクトに適用すると、価値の大部分を占める少数の成果物や意思決定を特定し、それらを最優先で確保すべきだということになります。この割合はプロジェクトごとに異なるため、厳密な比率としてではなく、どこに注力すべきかを見極めるための「視点」として捉えてください。
Excelで複数のプロジェクトを管理することはできますか?
はい、実際に業界の多くの人がそうしています。Wellingtone社の2026年のアンケートによると、回答者の22%が依然としてMicrosoft Excelでプランを立てていることが判明しました。 プロジェクトごとに1行ずつ、さらに所有者、フェーズ、次のマイルストーン、進捗状況のフラグを記載した単一のシートは、それ自体で有効なポートフォリオの要約となります。しかし、複数の人がその内容を最新の状態に保つ必要が生じたり、プロジェクト横断的なキャパシティ配分が必要になったりすると、この方法は機能しなくなります。なぜなら、このシートは現実をリアルタイムに反映したものではなく、手作業で作成された現実のコピーに過ぎないからです。
マルチプロジェクトのガントチャートとは何でしょうか?
マルチプロジェクト・ガントチャートは、複数のプロジェクトのタイムラインを1つの共有軸上にプロットすることで、重複するマイルストーンやプロジェクト間の依存関係をまとめて可視化します。これは、プロジェクト間で実際に仕事を引き継ぐ場合に最も有用であり、単に並行して進行しているだけの場合にはあまり役立ちません。タスクレベルで統合したチャートは、誤った情報になる前にまず見づらくなってしまうため、すべてのタスクではなく、マイルストーンに限定して作成するようにしましょう。

