プロジェクト憲章

Charter is not a dictionary label; it is a short decision contract that states why a project or initiative exists, who owns it, what is in scope, and how success will be judged. In practice it is used for aligning sponsors, teams, and reviewers before work starts by making owners, boundaries, evidence, and review triggers explicit.

Name the decision owner and sponsor before listing tasks. State the problem, intended outcome, and non-goals in one place. Define scope boundaries and review triggers before resources are committed. Use the charter as the baseline when change requests appear.

• Name the decision owner and sponsor before listing tasks.
• State the problem, intended outcome, and non-goals in one place.
• Define scope boundaries and review triggers before resources are committed.
• Use the charter as the baseline when change requests appear.

The owner reviews Charter weekly or at milestone changes for status, open issues, and overdue commitments. Changes to Charter are approved only after the affected owner, scope, customer or internal outcome are named. The review checks whether Charter improves decisions and execution, not whether the document merely exists.

• The owner reviews Charter weekly or at milestone changes for status, open issues, and overdue commitments.
• Changes to Charter are approved only after the affected owner, scope, customer or internal outcome are named.
• The review checks whether Charter improves decisions and execution, not whether the document merely exists.

Charter changes decisions by making the owner, boundary, required evidence, and review trigger explicit before work proceeds. Charter helps teams decide whether to start, stop, resize, or resequence work using evidence rather than meeting momentum. Charter reduces rework because assumptions, unresolved questions, and follow-up responsibilities are visible enough to challenge.

• Charter changes decisions by making the owner, boundary, required evidence, and review trigger explicit before work proceeds.
• Charter helps teams decide whether to start, stop, resize, or resequence work using evidence rather than meeting momentum.
• Charter reduces rework because assumptions, unresolved questions, and follow-up responsibilities are visible enough to challenge.

the work is a one-step task with no shared risk ownership and budget are already explicit elsewhere the document will be longer than the decision it protects

• the work is a one-step task with no shared risk
• ownership and budget are already explicit elsewhere
• the document will be longer than the decision it protects

• Define the decision question, accountable owner, and time horizon before using Charter as an operating artifact.
• Separate evidence from opinion so Charter supports judgment instead of decorating a preferred answer.
• Record what was accepted, what was deferred, and what signal would cause a future change in Charter.
• Use Charter to choose a management action, not merely to produce a tidy document or status label.
• Revise or retire Charter when the boundary, owner, evidence, or operating context changes materially.

Charter will not speed execution when ownership remains ambiguous. Charter becomes storage instead of a decision aid when it is too long to use. Charter needs change history or teams cannot reconstruct why the decision moved.

• Charter will not speed execution when ownership remains ambiguous.
• Charter becomes storage instead of a decision aid when it is too long to use.
• Charter needs change history or teams cannot reconstruct why the decision moved.

A team uses Charter after noticing that discussion keeps producing activity without a clear management decision. For Charter, the team defines the intended outcome, names one accountable owner, and lists the evidence that would change the decision. During the Charter review, the team compares current evidence with the recorded boundary, adjusts the scope, and assigns follow-through work. The Charter record now helps people see why the action was chosen, what risk was accepted, and when the decision should be revisited.

Separate nearby terms by the decision each one supports. Business plan | Explains the business logic | Charter defines the operating authorization Scope | Draws the boundary | Charter connects boundary to owner and outcome Project | Organizes execution | Charter authorizes why that execution should exist

• Charter is not valuable because the label exists; it is valuable only when it changes a decision or execution behavior.
• More detail is not automatically better for Charter; the useful level is the one that clarifies ownership and review.
• Charter is not a one-time workshop output because the artifact must stay current while the decision remains live.