【1. プロジェクト背景・目的】
- 現状の課題・問題の明確化
- プロジェクト実施の必要性
- 組織戦略との関連性
- 期待される価値・効果

【2. スコープ定義】
- 含まれる作業・成果物
- 含まれない作業（除外事項）
- 境界条件・前提条件
- 制約事項・リスク要因

【3. 目標・成功基準】
- SMART原則に基づく目標設定
- 定量的・定性的成功指標
- 受け入れ基準・品質基準
- 測定方法・評価タイミング

【4. ステークホルダー】
- 関係者の特定・分類
- 期待・要求事項の整理
- 影響力・関心度の分析
- コミュニケーション方針

【5. 概算予算・スケジュール】
- 全体予算の概算
- 主要マイルストーンの設定
- 重要な依存関係
- リソース要求事項

【スコープ設定のプロセス】

Step 1：要求事項の収集
- ステークホルダーからの要求
- ビジネス要求・機能要求
- 品質要求・制約条件
- 仮定事項・リスク要因

Step 2：要求事項の分析・整理
- 要求の優先順位付け
- 要求間の依存関係分析
- 実現可能性の評価
- コスト・スケジュールへの影響

Step 3：スコープ境界の明確化
- 含まれる作業の詳細化
- 含まれない作業の明示
- グレーゾーンの解消
- 変更管理プロセスの設定

【実例：システム導入プロジェクト】
含まれる作業：
✓ 要件定義・設計・開発・テスト
✓ データ移行・システム連携
✓ ユーザー研修・マニュアル作成
✓ 運用開始支援（3ヶ月間）

含まれない作業：
× 既存システムの改修
× ハードウェアの調達・設置
× 組織変更・業務プロセス見直し
× 運用開始後の機能追加

【分解の基準】
- 管理可能な単位まで分解
- 成果物ベースの分解を優先
- 80時間ルール（1作業パッケージ≤80時間）
- 責任者を明確に割り当て可能

【分解の方法】
1. 成果物分解法
   主要成果物 → サブ成果物 → 作業パッケージ

2. フェーズ分解法
   プロジェクトフェーズ → アクティビティ → タスク

3. 組織分解法
   組織単位 → 担当業務 → 個別作業

【品質チェック】
□ 100%ルール：上位要素の合計が下位要素と一致
□ 相互排他性：重複する作業がない
□ 測定可能性：進捗・完成を測定可能
□ 管理可能性：責任者が管理可能な粒度

【新商品開発プロジェクト】

1.0 市場調査・分析
  1.1 市場環境調査
    1.1.1 業界動向調査
    1.1.2 競合他社分析
    1.1.3 顧客ニーズ調査
  1.2 市場規模・ポテンシャル分析
    1.2.1 市場規模推定
    1.2.2 成長性分析
    1.2.3 ターゲット市場特定

2.0 商品企画・設計
  2.1 商品コンセプト開発
    2.1.1 アイデア創出・選定
    2.1.2 コンセプト設計
    2.1.3 コンセプト検証
  2.2 詳細仕様設計
    2.2.1 機能仕様策定
    2.2.2 品質基準設定
    2.2.3 コスト目標設定

3.0 試作・テスト
  3.1 プロトタイプ開発
  3.2 性能・品質テスト
  3.3 市場テスト・評価

4.0 量産準備
  4.1 生産プロセス設計
  4.2 サプライチェーン構築
  4.3 品質管理体制整備

5.0 マーケティング・販売準備
  5.1 マーケティング戦略策定
  5.2 販売チャネル構築
  5.3 プロモーション企画・実行

【クリティカルパス法（CPM）】

手順：
1. アクティビティの洗い出し
2. 依存関係の特定
3. 所要期間の見積もり
4. ネットワーク図の作成
5. クリティカルパスの特定
6. スケジュール最適化

クリティカルパスの特徴：
- 最も時間のかかる経路
- 遅延すると全体に影響
- フロート（余裕時間）ゼロ
- 重点管理の対象

【PERT法（確率的スケジューリング）】
3点見積もり：
- 楽観値（O）：最も楽観的な場合
- 悲観値（P）：最も悲観的な場合
- 最頻値（M）：最も起こりやすい場合

期待値 = (O + 4M + P) / 6
標準偏差 = (P - O) / 6

例：システム開発タスク
O = 10日、M = 15日、P = 26日
期待値 = (10 + 4×15 + 26) / 6 = 16日
標準偏差 = (26 - 10) / 6 = 2.7日

【リソース制約の考慮】

1. リソース要求量の算出
   各タスクの必要リソース × 期間

2. リソース負荷の可視化
   期間別・リソース別の負荷グラフ

3. 制約の特定
   - 人的リソースの制約
   - 設備・機器の制約
   - 予算・調達の制約

4. 調整方法
   - タスクの順序変更
   - リソースの追加・変更
   - スケジュールの延長
   - スコープの調整

【実例：開発チームのリソース調整】
問題：設計フェーズでエンジニア負荷が120%
対策：
- 非クリティカルタスクの後ろ倒し
- 外部リソースの一時活用
- 作業の並行化による期間短縮
- タスクの優先順位見直し

結果：負荷を95%に調整、品質確保

【外部リスク】
市場・競合リスク：
- 市場環境の変化
- 競合他社の動向
- 顧客ニーズの変化
- 規制・法制度の変更

技術・供給リスク：
- 技術標準の変更
- サプライヤーの問題
- 原材料価格の変動
- 自然災害・不可抗力

【内部リスク】
組織・人的リスク：
- キーパーソンの離脱
- スキル不足・経験不足
- 組織変更・体制変更
- コミュニケーション不足

技術・品質リスク：
- 技術的困難・課題
- 品質基準未達
- システム・機器の障害
- 設計・仕様の変更

【プロジェクト管理リスク】
スケジュール・コストリスク：
- 見積もり精度の問題
- 依存関係の複雑化
- リソース確保の困難
- 承認・意思決定の遅延

【ブレインストーミング】
- 多様なメンバーでのアイデア創出
- 批判せずに自由な発想
- 量を重視した網羅的識別
- カテゴリー別の整理

【チェックリスト法】
- 過去プロジェクトのリスク一覧
- 業界標準のリスクカタログ
- 組織固有のリスク要因
- 段階的なチェック実施

【SWOT分析】
- 強み（Strengths）の活用不足リスク
- 弱み（Weaknesses）による障害リスク
- 機会（Opportunities）の逸失リスク
- 脅威（Threats）による悪影響リスク

【専門家判断】
- 経験豊富な専門家への相談
- 類似プロジェクトの教訓活用
- 外部コンサルタントの知見
- 業界ベンチマークとの比較

【確率×影響度による評価】

確率の定義：
- 5：ほぼ確実（81-100%）
- 4：可能性大（61-80%）
- 3：可能性中（41-60%）
- 2：可能性小（21-40%）
- 1：可能性極小（0-20%）

影響度の定義：
- 5：致命的（プロジェクト中止レベル）
- 4：重大（主要目標未達成）
- 3：中程度（一部目標未達成）
- 2：軽微（軽微な影響）
- 1：無視可能（ほぼ影響なし）

リスク値 = 確率 × 影響度

【リスクマトリックス】
     影響度
     1  2  3  4  5
確率 5  5 10 15 20 25
   4  4  8 12 16 20
   3  3  6  9 12 15
   2  2  4  6  8 10
   1  1  2  3  4  5

優先度：
- 15-25：高（即座に対策必要）
- 8-12：中（計画的対策必要）
- 1-6：低（監視継続）

【多面的評価基準】

検知可能性：
- リスクの早期発見可能性
- 兆候・指標の明確さ
- モニタリング体制の整備

対策可能性：
- 対策の実行可能性
- 必要リソースの確保可能性
- 技術的解決手段の存在

タイミング重要度：
- プロジェクト段階での重要性
- 他のリスクとの関連性
- 対策タイミングの制約

【評価例：技術的困難リスク】
- 確率：4（過去の類似案件で頻発）
- 影響度：4（スケジュール大幅遅延）
- 検知可能性：3（設計段階で発見可能）
- 対策可能性：2（高度な専門性必要）
- タイミング：5（初期段階で対策必須）

総合判定：最高優先度での対策実施

【4つの基本戦略】

1. 回避（Avoid）
   リスクの根本原因を除去
   例：技術的困難を避けるため実績ある技術を選択

2. 軽減（Mitigate）
   確率・影響度を低減
   例：バックアップ要員の配置、定期レビューの実施

3. 転嫁（Transfer）
   リスクを第三者に移転
   例：保険加入、アウトソーシング、契約条件

4. 受容（Accept）
   リスクを受け入れて監視
   例：低優先度リスクの経過観察

【戦略選択の基準】
- リスクの重要度・緊急度
- 対策コストと効果
- 組織の能力・リソース
- ステークホルダーの許容度

【対策計画の要素】

1. 予防策（Preventive Actions）
   リスク発生を防ぐ事前対策
   - プロセス改善・標準化
   - 事前チェック・レビュー
   - 研修・スキル向上
   - 冗長性・バックアップ

2. 検知策（Detective Actions）
   リスク発生を早期に発見する対策
   - 定期的なモニタリング・チェック
   - 警告システム・アラート設定
   - 進捗報告・レビュー会議
   - KPI・指標による監視

3. 是正策（Corrective Actions）
   リスク発生時の対応策
   - 緊急時対応プロセス
   - エスカレーション手順
   - 復旧・回復計画
   - 代替手段の実行

4. 改善策（Improvement Actions）
   再発防止・継続的改善
   - 根本原因分析
   - プロセス・システムの改善
   - 教訓の共有・活用
   - 予防策の強化

【実行計画の作成】
- 対策の優先順位付け
- 実施スケジュール
- 責任者・担当者の明確化
- 必要リソースの確保

【効果測定】
- リスク値の再評価
- 対策の有効性確認
- コスト効率の評価
- 副次的影響の確認

【継続的監視】
- 定期的なリスク見直し
- 新たなリスクの識別
- 対策の継続的改善
- 組織学習の促進

【内部ステークホルダー】
プロジェクトチーム：
- プロジェクトマネージャー
- チームメンバー
- 技術専門家
- 品質管理者

経営・管理層：
- 経営陣・役員
- 部門長・管理職
- 予算承認者
- 意思決定者

関連部門：
- 営業・マーケティング
- 人事・総務
- 法務・コンプライアンス
- IT・システム部門

【外部ステークホルダー】
顧客・市場：
- エンドユーザー
- 顧客企業
- 販売チャネル
- 市場・業界関係者

パートナー・供給者：
- サプライヤー
- 外部委託先
- 技術パートナー
- 協力会社

規制・社会：
- 規制当局
- 業界団体
- 地域社会
- メディア

【分析軸】
影響力：プロジェクトへの影響度（高・中・低）
関心度：プロジェクトへの関心度（高・中・低）

【4象限分類】
A：高影響・高関心（重点管理）
- 経営陣、主要顧客
- 密接な連携・頻繁なコミュニケーション
- 意思決定への参画

B：高影響・低関心（関心喚起）
- 関連部門長、重要な外部パートナー
- 関心を高める働きかけ
- 定期的な情報提供

C：低影響・高関心（情報提供）
- 一般従業員、業界関係者
- 適切な情報提供
- 期待管理

D：低影響・低関心（最小限管理）
- 間接的関係者
- 必要最小限の連絡
- 効率的な管理

【経営層向け】
内容：戦略的視点・投資対効果
頻度：月1回定期報告 + 重要時点
方法：役員会議・個別面談
形式：エグゼクティブサマリー

【中間管理職向け】
内容：進捗状況・課題・リソース
頻度：週1回定期 + 必要時
方法：定例会議・メール報告
形式：詳細報告書・ダッシュボード

【実務担当者向け】
内容：具体的作業・スケジュール
頻度：日次・週次の密な連携
方法：チームミーティング・チャット
形式：作業指示・進捗共有

【外部パートナー向け】
内容：契約・仕様・品質基準
頻度：契約条件に基づく定期
方法：正式会議・文書連絡
形式：契約書・仕様書・報告書

| ステークホルダー | 情報ニーズ | 頻度 | 方法 | 責任者 | 成果物 |
|-----------------|-----------|------|------|--------|--------|
| 経営陣 | 戦略・ROI | 月次 | 会議 | PM | サマリー |
| 部門長 | 進捗・課題 | 週次 | 報告 | PM | 報告書 |
| チーム | 作業・調整 | 日次 | MTG | リーダー | 議事録 |
| 顧客 | 仕様・品質 | 週次 | 会議 | PM | 資料 |

【Step 1：現状認識の統一】
- 各ステークホルダーの立場確認
- 課題・問題の共有
- 目標・期待値の明確化
- 制約条件の確認

【Step 2：選択肢の検討】
- 複数案の提示
- メリット・デメリットの分析
- リスク・影響の評価
- 実現可能性の検討

【Step 3：利害調整】
- 各ステークホルダーの要求整理
- 優先順位の調整
- トレードオフの明確化
- Win-Winの解決策模索

【Step 4：合意形成】
- 段階的な合意構築
- 残課題の明確化
- 実行条件の確認
- 文書化・記録

【RACI Matrix】
R（Responsible）：実行責任者
A（Accountable）：説明責任者
C（Consulted）：事前相談
I（Informed）：情報共有

例：システム導入プロジェクト
| 意思決定事項 | PM | 部門長 | 経営陣 | IT部 | ユーザー |
|-------------|----|----|----|----|-----|
| 予算承認 | C | C | A | I | I |
| 仕様決定 | A | C | I | R | C |
| 導入時期 | R | A | C | C | I |
| 研修計画 | R | C | I | C | A |

【Plan：対応計画】
1. 状況把握・影響度評価
2. 原因分析・調査計画
3. 対応策の検討・選択
4. 実行計画の策定

【Do：対応実行】
1. 緊急対応・応急処置
2. 根本対策の実施
3. 関係者への連絡・報告
4. 進捗管理・調整

【Check：効果確認】
1. 対策効果の測定
2. 副次的影響の確認
3. ステークホルダー満足度
4. 完了条件の確認

【Act：改善・標準化】
1. 教訓の抽出・共有
2. プロセス・システム改善
3. 予防策の強化
4. 知識・経験の蓄積

【緊急・重要（最優先）】
- システム全面停止
- 安全・品質問題
- 顧客への重大影響
- 法的・コンプライアンス問題

【重要・非緊急（計画的対応）】
- 性能・効率の改善
- 将来リスクの対策
- 組織・プロセス改善
- 技術・スキル向上

【緊急・非重要（効率的処理）】
- 軽微な不具合修正
- 一時的な運用変更
- 個別の要求対応
- 短期的な調整

【非緊急・非重要（後回し・削除）】
- 優先度の低い改善
- 影響の小さい変更
- 重複する作業
- 不要な作業

【問題】：顧客への納期遅延が発生

Why1：なぜ納期に遅れたのか？
→ テストで不具合が多数発見されたため

Why2：なぜテストで不具合が多数発見されたのか？
→ 開発段階での品質チェックが不十分だったため

Why3：なぜ開発段階での品質チェックが不十分だったのか？
→ レビュープロセスが形式的になっていたため

Why4：なぜレビュープロセスが形式的になっていたのか？
→ レビュー担当者のスキル・時間が不足していたため

Why5：なぜレビュー担当者のスキル・時間が不足していたのか？
→ 適切な人材配置・育成計画がなかったため

根本原因：人材配置・育成計画の不備

【問題】：プロジェクト品質低下

【要因分類】
人（Man）：
- スキル不足
- 経験不足
- モチベーション低下
- コミュニケーション不足

方法（Method）：
- プロセス不備
- 手順不明確
- チェック機能不足
- 改善サイクル未確立

機械・ツール（Machine）：
- システム不具合
- ツール不足
- 環境不備
- 技術的制約

材料・情報（Material）：
- 要件不明確
- 仕様変更頻発
- 情報不足
- 品質基準曖昧

環境（Environment）：
- 組織体制
- 文化・風土
- 外部環境
- リソース制約

【問題・課題の収集】
- 定期的な振り返り会議
- 改善提案制度
- 顧客フィードバック
- データ・指標分析

【改善策の検討・評価】
- 根本原因分析
- 複数案の比較検討
- 実現可能性評価
- 効果・コスト分析

【改善の実行・展開】
- パイロット実施
- 効果測定・検証
- 本格展開
- 標準化・定着

【学習・共有】
- 成功事例の共有
- 失敗から学ぶ分析
- ベストプラクティス化
- 知識・ノウハウ蓄積

【個人レベル】
- 振り返り習慣の定着
- スキル向上計画
- 経験・知識の記録
- 他者からの学習

【チームレベル】
- チーム振り返り
- 知識共有会議
- 相互学習・支援
- 集合知の活用

【組織レベル】
- 改善事例データベース
- 教訓・ノウハウ集
- 研修・教育制度
- 文化・風土改革