1-1. プロジェクトの目的

プロジェクトを始める前に「なぜこのプロジェクトを行うか」を一文で定義する。解決すべき課題と、このプロジェクトでどう解決するかをセットで明示する。

項目内容
背景・課題何が問題で、誰が困っているか
解決アプローチこのプロジェクトでどう解決するか

⚠️ 定義しないと…

開発が進むにつれ「これって本当に必要？」という議論が頻発する。判断軸がないため、意思決定のたびに全員が集まって議論し直す羽目になる。最終的に「作ったけど誰も使わないもの」が完成するリスクが高い。

1-2. 達成ゴール（完了の定義）

プロジェクト完了時点で「何が実現しているか」を明文化する。抽象的なゴールではなく、「〇〇ができる状態になっている」と一文で表現できるレベルまで落とし込む。

項目内容
完了の状態「〇〇ができる状態になっている」と一文で表現できるか
完了の判断者誰が「完成した」と判断するか

⚠️ 定義しないと…

「完成した」の認識が人によってズレる。開発者は「動く」と思っても、依頼者は「まだ足りない」となり、終わりのない手戻りが発生する。いつリリースするかも決められなくなる。

1-3. 成功指標（KPI）

ゴールを数値で測定できる形に落とす。定性的な「良い」「使いやすい」ではなく、計測可能な指標を設定する。

指標例説明
月間アクティブユーザー数サービスが実際に使われているかの指標
登録件数・継続率獲得と定着を測る
機能カバレッジ率定義した機能がどれだけ実装できたか

⚠️ 定義しないと…

「成功した/失敗した」を判断できない。リリース後に「思ったより使われていない」と感じても、何と比べて少ないのかの基準がないため改善の優先度が立てられない。

1-4. 非ゴール（やらないことの明示）

今回のプロジェクトで意図的に対応しないことのリストを作る。「やること」だけでなく「やらないこと」を明示することが、スコープを守る最大の武器になる。

⚠️ 定義しないと…

開発途中で「あの機能も追加して」という要求が次々と発生する（スコープクリープ）。断る根拠がないため全部受け入れた結果、納期が延び、品質が下がる。「最初からそれは対象外と決めていた」と言えないため、関係者間で不満が生まれる。

✅ 実践のヒント

「非ゴール」は否定的に聞こえるが、実際には「今は対象外、将来検討」として記録することで要求を否定せずに受け取ることができる。スコープを守りながら関係者の納得を得る有力な手法。

4つの定義をうまく書くコツ

目的・ゴール・KPI・非ゴールの4つは連動している。目的が明確であればゴールが導ける。ゴールが明確であればKPIが設計できる。KPIが設計できれば非ゴールが自然に見えてくる。最初に目的の定義に集中することが、他の3つをスムーズに導く近道だ。

定義良い例悪い例（曖昧な例）
目的EC サイトのカート離脱率を下げ、月間売上を 20% 向上させるユーザー体験を改善する
ゴールカート追加からの決済完了率が現状の 40% → 60% に改善した状態買いやすいサイトになっている
KPI決済完了率、カート放棄率（週次計測）、月間売上（月次計測）ユーザー満足度が上がる
非ゴール商品レビュー機能の追加・多言語対応・アプリ版の開発は今回のスコープ外（定義なし）

プロジェクト憲章の目的・ゴール設定で最も重要なのは「全員が合意している」ことだ。どれだけ精緻な文書でも、関係者が読んでいなければ意味がない。憲章を作ったらキックオフミーティングで全員に説明し、質問・異論を受け付ける時間を設けることが、後々の認識ズレを防ぐ最も効果的な方法だ。

目標・ゴール設定でよくある失敗パターン

プロジェクト憲章の目標設定は「書いたつもり」になりやすい。以下の失敗パターンを事前に知っておくことで精度が上がる。

失敗パターン何が起きるか防止策
目的が「〜の向上」「〜の改善」で終わる完了条件が曖昧なまま開発が進み、「完成した」「まだ足りない」で認識が割れる目的に数値と期限を含める。「6ヶ月で決済完了率を40%→60%に改善」のように書く
KPIを計測できない指標にするプロジェクト終了後に「達成したかどうか」が判断できず、成否の合意形成ができないKPIは計測方法（誰が・どこから・どの頻度で取得するか）もセットで定義する
非ゴールを定義しない要件定義フェーズ以降で「あれもできるはず」という追加要求が際限なく出続けるスコープ外を明示的にリストアップし、「今回対象外の理由」を一文添える