プロジェクトの前提
なぜこのプロジェクトが必要なのか。何を達成すべきなのか。
全ての判断の土台となる情報を定義するセクションです。
なぜこのセクションが必要か
よくある失敗パターン
- • 開発終盤になって「そもそも目的は何だっけ？」となる
- • チームメンバーによって「成功」の定義が違う
- • 予算・期間の制約が共有されず、実現不可能な要件が積み上がる
- • ステークホルダーの期待値がバラバラ
プロジェクトの前提を明文化することで、チーム全員が「何のために」「何を目指して」開発しているのかを共有できます。 迷ったときの判断基準になり、スコープの議論も「目的に照らして必要か」で判断できるようになります。
入力する項目
背景・目的
なぜこのプロジェクトが始まったのか、何を解決したいのかを記述します。
記入例
現行のECサイトは2018年に構築され、月間PVが50万を超えた現在、パフォーマンスとUXの両面で限界を迎えている。 カート離脱率が業界平均の1.5倍（45%）に達しており、売上機会損失は月間約2,000万円と推定される。 本プロジェクトでは、カート離脱率を30%以下に改善し、CVRを1.5倍にすることを目指す。
制約条件
予算、期間、技術制約など、プロジェクトの枠組みを定義します。
記入例
- • 予算: 初期開発 3,000万円、年間運用 500万円
- • 期間: 2024年4月〜2024年9月（6ヶ月）
- • 技術制約: 既存の基幹システム（SAP）との連携が必須
- • リソース: 社内エンジニア2名、外部ベンダー5名
成功指標（KPI）
プロジェクトの成功を測る具体的な数値目標を設定します。
記入例
- • カート離脱率: 45% → 30%（33%改善）
- • CVR（コンバージョン率）: 2.1% → 3.2%（1.5倍）
- • ページ読み込み時間: 4.2秒 → 1.5秒以下
- • 顧客満足度スコア: 3.2 → 4.0以上（5点満点）
ステークホルダー一覧
プロジェクトに関わる人物とその役割・期待を明記します。
記入例
- • プロジェクトオーナー: 山田部長（EC事業部）- 最終意思決定者
- • 発注者: 田中課長（マーケティング）- 日次の要件確認
- • 技術責任者: 鈴木リーダー（IT推進室）- 技術選定・レビュー
- • エンドユーザー代表: 佐藤主任（カスタマーサポート）- UXフィードバック
Claude Code での操作例
あなた
「toishiの『ECサイトリニューアル』プロジェクトの前提に、制約条件を追加して。 予算は3,000万円、期間は6ヶ月、SAPとの連携が必須」
AI
制約条件を追加しました。
- 予算: 3,000万円
- 期間: 6ヶ月
- 技術制約: SAP連携必須
ステータスは「下書き」です。承認依頼しますか？
承認のポイント
承認者はここをチェック
- ✓ 背景と目的が具体的で、関係者全員が理解できるか
- ✓ 制約条件（予算・期間・技術）が現実的か
- ✓ KPIが測定可能で、達成基準が明確か
- ✓ ステークホルダーの役割と期待が明記されているか
- ✓ 抜けている制約や前提条件がないか
ベストプラクティス
最初に書く、最初に承認を得る
前提が固まっていないと、後続のセクション（ペルソナ、ユーザーニーズ）の方向性もブレます。 最初にステークホルダーの承認を得ることで、手戻りを防げます。
「やらないこと」も明記する
スコープクリープを防ぐために、「今回は対象外」を明確にしておくことが重要です。 例：「多言語対応は Phase 2 で検討」
数字で語る
「パフォーマンスを改善する」ではなく「ページ読み込み時間を4.2秒から1.5秒に改善する」と書く。 曖昧さが減り、達成確認も容易になります。
なぜこの設計なのか
「やらないこと」を明文化することで、最も多い手戻りを防ぐ
out_of_scope（スコープ外）を書かないと、開発中に「これも必要では？」が無限に湧き、 予算・期限が破綻します。「多言語対応はPhase 2」のように明記することで、 スコープクリープを防ぎます。
目的の一致なしに進めると、後から「そもそも何のために」で振り出しに戻る
「業務効率化」だけでは曖昧すぎて、開発終盤に「これは効率化になっていない」と言われます。 「月末請求処理を48時間→10時間に短縮」のように数値で目的を定義することで、 全員が同じゴールを見て進めます。
制約条件（予算・期限・技術制約）を明文化しないと、開発中に発覚して大幅修正
「SAP連携が必須」を書かないと、SAP非対応の技術で設計が進み、 後から全面的に作り直しになります。制約を最初に共有することで、 実現不可能な要件を事前に排除できます。