制約

プロジェクトの大きな枠組みを、開始前に確認する

英語で制約は constraint、複数の制約条件は constraints、プロジェクトの制約条件は project constraints と表します。「予算はいくらまでか」「いつまでに何を届けるか」「どの人員・技術を使えるか」を明らかにし、実行できる範囲をそろえます。

開始時にこうした大枠を確認する代表的な文書が、プロジェクト憲章（Project Charter）です。目的、目標、主要な範囲、前提条件・制約条件、責任者と権限、承認要件などを整理し、プロジェクトの実施とPMの権限を正式に認める役割があります。制約は憲章の一部であり、憲章そのものの別名ではありません。

PMはスポンサーなどの承認を受けた枠組みを確認し、詳細な計画と実行方法を具体化します。制約を並べるだけでなく、誰が決めた条件か、根拠はどの文書か、どこまで自分で判断できるかを開始前に確認することが重要です。文書の名称や運用は組織によって異なります。

参考：PMI：Project Charter、国土交通省公開教材「海洋開発ビジネス概論」第II部4.2（PDF）。

「前提条件」と「制約条件」は、同じ意味ではない

日常語ではどちらも「仕事を始めるときの条件」と呼びますが、プロジェクト管理では区別します。前提条件（assumptions）は、計画のためにいったん正しいものとして扱う仮定です。未確認の仮定を、変更できない制約と決めつけないようにします。

途中で前提が崩れたときは、その事実を記録して影響を評価します。「仮定だったから自由に変えてよい」という意味ではありません。承認済みの費用や納期、範囲に影響するなら、変更管理の対象です。

参考：PMI：制約・前提条件の分析。表の状況と金額は説明用で、実際の案件ではありません。

変えられない条件と、承認を得て変える条件

「開始時に決めたから、すべて永久に変更不可」ではありません。一方で、「進行中に事情が変わったから、PMの判断だけで変更できる」わけでもありません。条件の根拠と、委譲された権限・許容範囲で扱いを分けます。

指示した上司・役員が承認権限者なら、その了承を得てから変更します。ただし、直属の上司なら必ず承認できるとは限りません。スポンサー（Project Sponsor）や変更管理委員会（Change Control Board / CCB）など、組織・案件で決めた承認経路を使います。外部の契約や法令上の条件は、社内の了承だけでは変更できないことにも注意します。

新しく判明した制約も、担当者が黙って納期や予算に織り込まず、関係者へ共有します。変更の相談と、変更の承認は別です。「相談した」「反対されなかった」だけで承認済みとは扱いません。

制約を変更する場合の注意点と手順

変更管理は change control と呼ばれます。APMは、承認済みの基準計画（baseline）への変更要求を記録・評価し、承認・却下・保留を判断するプロセスと説明しています。

1. 条件と根拠を特定する：現行の制約、憲章・契約・計画の記載箇所、決定者と承認経路を確認する。
2. 変更が必要な事実を記録する：発生した事情、変更前後の条件、変更しない場合の影響を分ける。
3. 全体への影響を評価する：予算・納期・範囲・品質・人員・リスクを確認し、条件を維持する代替案とも比べる。
4. 権限者の判断を受ける：決裁範囲を超える変更は実施前に承認を得る。緊急時も、事前に定めた緊急対応権限と報告手順に従う。
5. 承認後に記録と計画を更新する：判断者・日付・理由・版を残し、関係者へ共有する。必要なら憲章も見直し、過去の条件を消して経緯を失わない。

例えば「APIが使えないため別方式へ変更したい」というとき、同じ予算・納期・品質で対応できるかを先に評価します。追加予算や期限延長が必要なら、その変更を承認できる人へ判断を求めます。根拠のない「この方法しかない」と、実際に選択肢を限定する制約を混同しないことが大切です。

参考：APM：What is change control?。分類・例・手順は一次資料を踏まえたJPMの実務上の整理です。個別案件の契約・法令・社内規程を優先して確認してください。

PjMの役割を確認する ／ 確定期限と探索中の計画を分ける

更新：2026年10月13日