- はじめに
- 1. プロジェクト着手前 — 企画・提案フェーズ
- 2. 分析フェーズ — 要件定義
- 3. 設計フェーズ
- 4. 実装フェーズ — 開発
- 5. テストフェーズ
- 6. 移行/本番稼働フェーズ — カットオーバー
- 7. 終了フェーズ — 納品とプロジェクト完了
- 8. 公共事業特有の成果物
- 9. 成果物管理の実務ヒント
- クイズ：理解度チェック
- おわりに
はじめに
ITプロジェクトを成功に導くには、優れたコードを書くことと同様に、成果物（Deliverables） を体系的に作成・管理することが不可欠です。韓国のIT現場では、特に公共事業を中心にフェーズごとの成果物要件が法令・行政指針によって厳格に定められています。
本ガイドでは、プロジェクト着手前の企画・提案フェーズから、要件分析、設計、実装、テスト、移行（本番稼働）、終了フェーズまで、各フェーズで作成すべきすべての成果物を整理します。各文書の作成主体、核心内容、実務上の注意点も合わせて解説します。
1. プロジェクト着手前 — 企画・提案フェーズ
このフェーズは、事業が正式に開始される前に発注者とベンダー候補の間で行われる調達・企画活動です。
1-1. RFP（提案依頼書）
- 作成主体: 発注者（クライアント）
- 核心内容: 事業目的、スコープ、要件概要、予算上限、納期スケジュール、評価基準
- 注意点: 技術要件と価格要件は分離して記述する必要があります。韓国の公共事業ではG2B（電子調達システム「나라장터」）への公告要件を満たす必要があります。機能要件を詳細に記述しすぎると競争を制限する恐れがあります。
- 実務ヒント: RFPが曖昧なほど提案フェーズのリスクが高まります。公式Q&A期間を積極的に活用して意図を明確化しましょう。
1-2. 提案書（Proposal）
- 作成主体: ベンダー（受注候補企業）
- 核心内容: 技術提案書（方法論、要員計画、スケジュール、技術スタック）と価格提案書（総額、工数算定根拠）を分離して提出
- 注意点: 価格提案書は技術提案書と物理的に分離して提出し、評価委員が価格を知らない状態で技術評価が行われるようにします。
- 実務ヒント: 提案書の分量は発注者の要件に合わせ、差別化ポイントを冒頭に配置しましょう。
1-3. 事業遂行計画書（Project Management Plan）
- 作成主体: ベンダーのPM
- 核心内容: プロジェクトスコープ定義、適用方法論（ウォーターフォール/アジャイル/ハイブリッド）、要員投入計画、WBS草案、成果物リスト、リスク管理計画
- 注意点: 契約前に提出する場合と契約後に最終版を提出する場合があります。公共事業では着手報告時に合わせて提出します。
1-4. 契約書およびNDA（秘密保持契約）
- 作成主体: 両者の法務・契約担当
- 核心内容: 契約スコープ、支払条件、遅延損害金、瑕疵担保期間・条件、知的財産権の帰属、秘密情報の保護
- 注意点: 瑕疵担保期間（通常1年）とSLA条件を契約書に明確に記載する必要があります。ソフトウェアの著作権帰属も明示が必須です。
1-5. WBS（Work Breakdown Structure、業務分類体系）
- 作成主体: PM + リード開発者
- 核心内容: プロジェクト全体の業務を階層的に分類、マイルストーン定義、各作業単位の担当者・期間・先行関係
- 注意点: WBSは単なるガントチャートではありません。担当者が明確に責任を持てる単位（ワークパッケージ）まで分解してください。
1-6. 着手報告書およびキックオフミーティング資料
- 作成主体: PM
- 核心内容: プロジェクト正式開始宣言、参加要員紹介、全体スケジュール、コミュニケーション計画、週次報告体制、イシューエスカレーション経路
- 注意点: キックオフミーティングでは発注者とベンダー間の期待値のすり合わせ（Expectation Alignment）が不可欠です。合意事項は議事録として残してください。
1-7. ステークホルダー一覧（Stakeholder Register）
- 作成主体: PM
- 核心内容: 発注者・ベンダー・外部機関の担当者情報、役割、意思決定権限、連絡先、影響力・関心度の分類
- 注意点: PMBOKではステークホルダーエンゲージメント計画（Stakeholder Engagement Plan）の作成も推奨されています。
2. 分析フェーズ — 要件定義
現状を把握し、新システムが備えるべき要件を定義するフェーズです。
2-1. 現状分析書（As-Is分析）
- 作成主体: ビジネスアナリスト/コンサルタント
- 核心内容: 現行業務プロセス（BPM）、既存システム機能一覧、データフロー、運用人員の現状、ボトルネックおよび課題の抽出
- 注意点: インタビューやワークショップを通じて現場担当者の視点から作成する必要があります。現状分析なしに設計へ進むと要件漏れが頻発します。
2-2. 要件定義書（SRS: Software Requirements Specification）
- 作成主体: アナリスト + 発注者担当者
- 核心内容:
- 機能要件（Functional）: システムが実行すべき具体的な機能一覧
- 非機能要件（Non-Functional）: 性能、可用性、セキュリティ、拡張性、保守性
- MoSCoW優先順位: Must Have / Should Have / Could Have / Won't Have に分類
- 注意点: 要件にIDを付与してトレーサビリティを確保してください。後でテストケースと1対1でマッピングされます。
2-3. ビジネス要件定義書（BRS: Business Requirements Specification）
- 作成主体: ビジネスアナリスト(BA) + 発注者
- 核心内容: 業務観点の要件、ビジネスルール、用語定義（グロッサリー）、組織図
- 注意点: BRSはSRSより上位の概念です。SRSで技術詳細が定義される前に、ビジネス上の意図を明確にする文書です。
2-4. ユースケース仕様書
- 作成主体: アナリスト
- 核心内容: アクター定義、ユースケース図、各ユースケースの基本フロー・代替フロー・例外フロー、事前・事後条件
- 注意点: UML表記法に従う必要があります。ユースケース数が増えるほど管理が複雑になります。複雑なユースケースはシーケンス図で補完してください。
2-5. インタビュー・アンケート結果書
- 作成主体: アナリスト
- 核心内容: インタビュー対象者、実施日時、質問リスト、回答要約、抽出された要件
- 注意点: インタビュー結果は必ずインタビュー対象者の確認署名を得てください。後で「そんなことは言っていない」という紛争を防止できます。
2-6. 法的・規制要件分析書
- 作成主体: アナリスト + 法務・セキュリティ担当
- 核心内容: 電子金融取引法、個人情報保護法、情報通信網法、ISMS-P、PCI-DSS、公共機関情報セキュリティ指針等の関連法令分析
- 注意点: 規制要件は任意ではなく義務です。設計フェーズ前に必ず特定し、設計に組み込む必要があります。
2-7. ベンチマーキング報告書
- 作成主体: アナリスト/コンサルタント
- 核心内容: 類似システム・サービスの事例分析、機能比較表、技術トレンド、ベンチマーク対象選定根拠
- 注意点: ベンチマーキング結果が要件定義に実質的に反映されて初めて意味を持ちます。
2-8. 分析レビュー結果書
- 作成主体: PM + 発注者担当者
- 核心内容: 要件の完全性・一貫性・トレーサビリティのレビュー結果、発見されたイシューとアクションアイテム、分析フェーズ完了承認
- 注意点: 公共事業ではフェーズ別ソフトウェア監査（감리）報告書と連動します。
3. 設計フェーズ
分析された要件を実際に実装可能な技術仕様に変換するフェーズです。
3-1. システムアーキテクチャ設計書
- 作成主体: アーキテクト/技術リード
- 核心内容: システム全体構成図、HW/SW/NW仕様、技術スタック選定根拠、冗長化・高可用性（HA）設計、ディザスタリカバリ（DR）方針
- 注意点: アーキテクチャ決定記録（ADR: Architecture Decision Record）を文書化することで、設計変更時に根拠を追跡できます。
3-2. アプリケーションアーキテクチャ設計書
- 作成主体: アーキテクト/シニア開発者
- 核心内容: レイヤー構造（Presentation/Business/Data）、コンポーネント図、マイクロサービス境界定義、APIゲートウェイ設計、サービス間通信方式
- 注意点: モノリシック vs マイクロサービスの選択はチームの運用能力も含めて総合的に判断してください。
3-3. 画面設計書（UIストーリーボード）
- 作成主体: UXデザイナー + アナリスト
- 核心内容: 全画面のワイヤーフレーム、画面遷移図（Screen Flow）、UIコンポーネント説明、バリデーションルール、エラーメッセージ定義
- 注意点: 画面設計書は発注者の承認後に開発を開始してください。未承認で開発を始めると大規模な手戻りが発生します。
3-4. DB設計書（ERD含む）
- 作成主体: DBA + 開発者
- 核心内容:
- 論理データモデル: エンティティ、属性、関係定義（ERD）
- 物理データモデル: テーブル名、カラム、データ型、PK/FK、インデックス戦略
- 正規化レベル、パーティショニング戦略、アーカイブポリシー
- 注意点: 論理モデルと物理モデルを混在させると混乱が生じます。段階を分けて作成してください。
3-5. テーブル定義書
- 作成主体: DBA
- 核心内容: テーブルごとのカラム名/日本語名/データ型/桁数/NULL許容/デフォルト値/説明、PK/FK/インデックス一覧、コードテーブル定義
- 注意点: データ標準（用語標準、ドメイン標準、コード標準）を遵守してください。
3-6. インターフェース設計書（I/F設計書）
- 作成主体: インターフェース開発者 + アナリスト
- 核心内容: 外部システム連携一覧、各I/F方式（REST API / SOAP / ファイル / バッチ / EAI-ESB / MQ）、リクエスト/レスポンスメッセージ仕様、エラーコード定義、連携テスト方法
- 注意点: 外部システム担当者との合意内容を文書化し、APIコントラクトを明確にしてください。
3-7. コーディング標準・規約
- 作成主体: 技術リード
- 核心内容: 命名規則（変数/クラス/関数/DBオブジェクト）、コメント規則、例外処理パターン、ロギング標準、コードスタイルガイド、リント設定（ESLint/Checkstyle等）
- 注意点: ツールで強制しない標準は守られません。CIパイプラインにリント検査を組み込んでください。
3-8. セキュリティ設計書
- 作成主体: セキュリティアーキテクト/専門家
- 核心内容: 認証・認可体系（OAuth2、JWT、SSO）、アクセス制御設計（RBAC/ABAC）、暗号化方式（転送時・保存時）、セキュリティログポリシー、APIセキュリティ（レートリミット、入力値検証）
- 注意点: OWASP Top 10を基準に設計段階でセキュリティ脅威を特定し、対応策を講じてください。
3-9. 配備アーキテクチャ設計書
- 作成主体: DevOps/インフラエンジニア
- 核心内容: サーバ/コンテナ（Docker/Kubernetes）構成、ネットワーク構成図、ロードバランサ/CDN設定、CI/CDパイプライン設計、モニタリングスタック（Prometheus/Grafana/ELK）
- 注意点: 本番環境と開発・テスト環境の差異を文書化してください。
3-10. 設計レビュー結果書
- 作成主体: PM + 技術リード + 発注者
- 核心内容: 設計の完全性・一貫性・実現可能性のレビュー結果、レビューコメントとアクション計画、設計フェーズ完了承認
- 注意点: 設計レビューは形式的な手続きではありません。実質的な技術的精査により実装フェーズのリスクを大幅に低減できます。
4. 実装フェーズ — 開発
設計仕様に基づき実際のコードを記述し、基本検証を行うフェーズです。
4-1. ソースコード
- 作成主体: 開発者
- 核心内容: Gitリポジトリ管理、ブランチ戦略（GitFlow / トランクベース開発）、コミットメッセージ規約、コードレビューポリシー
- 注意点: ソースコードは最も重要な成果物です。最終納品は定められたバージョンタグを基準にします。
4-2. ユニットテストケースおよび結果書
- 作成主体: 開発者
- 核心内容: モジュール/関数ごとのテストケース、入力値/期待値、実行結果、カバレッジレポート（JaCoCo/Istanbul等）
- 注意点: カバレッジ目標（例: コードカバレッジ70%以上）を事前に合意し、CIパイプラインで自動計測してください。
4-3. コードレビュー履歴
- 作成主体: 開発チーム全員
- 核心内容: PR（Pull Request）/MR（Merge Request）記録、レビュアーコメント、修正履歴、品質チェックリスト遵守状況
- 注意点: コードレビューはバグ発見だけでなく、チームの知識共有とコーディング標準遵守確認にも重要です。
4-4. ビルド/デプロイスクリプト
- 作成主体: DevOps/開発者
- 核心内容: CI/CDパイプライン定義ファイル（Jenkinsfile、GitHub Actions YAML、GitLab CI）、Dockerイメージビルドスクリプト、Kubernetesマニフェスト、Terraform/Ansibleインフラコード
- 注意点: Infrastructure as Codeを適用することで環境構成の再現性が保証されます。
4-5. 開発イシュー管理一覧
- 作成主体: PM + 開発者
- 核心内容: Jira/Redmine/GitHub Issuesに登録されたイシュー一覧、イシュー種別（バグ/機能/改善/技術的負債）、優先度、担当者、完了日、解決内容
- 注意点: イシュートラッカーはプロジェクト進捗をリアルタイムで把握する最重要ツールです。チャットやメールのみで処理すると履歴が残りません。
4-6. 週次/月次業務報告書
- 作成主体: PM
- 核心内容: 今週完了した作業、進捗率（計画比実績）、イシューとリスク状況、来週の計画、変更事項
- 注意点: 報告書は事実に基づく必要があります。過度に楽観的な報告は後でより大きな問題を引き起こします。
4-7. 技術検討会議録
- 作成主体: 書記（技術担当者）
- 核心内容: 会議日時/出席者/議題、討議内容、決定事項、アクションアイテム（担当者/期限含む）
- 注意点: 技術的意思決定は必ず文書化してください。口頭のみの合意は「そんな決定はしていない」という紛争の元になります。
5. テストフェーズ
開発されたソフトウェアが要件を満たしているか検証するフェーズです。
5-1. テスト計画書
- 作成主体: QAリード/PM
- 核心内容: テスト範囲、テスト種別（単体/結合/システム/性能/セキュリティ/UAT）、テスト環境、開始/終了基準（Entry/Exit Criteria）、スケジュール、担当者、テストツール
- 注意点: テスト計画は設計フェーズから策定してください。開発完了後にテストを計画するのでは遅すぎます。
5-2. テストケース定義書
- 作成主体: QAエンジニア
- 核心内容: テストケースID、要件ID（トレーサビリティ）、テストシナリオ、前提条件、入力値、期待結果、実際結果、判定（Pass/Fail）
- 注意点: 要件IDとテストケースIDをマッピングした要件トレーサビリティマトリクス（RTM）を合わせて管理してください。
5-3. 単体テスト結果書
- 作成主体: 開発者
- 核心内容: 個別モジュール/コンポーネントレベルのテスト結果、合否一覧、カバレッジ数値
- 注意点: 単体テストは開発者の責任です。QAが単体テストまで担当すると開発品質が低下します。
5-4. 結合テスト結果書
- 作成主体: QAエンジニア + 開発者
- 核心内容: モジュール間連携、外部システムインターフェース、バッチ/スケジューラ連携テスト結果、データフロー検証
- 注意点: インターフェース連携テストのために外部システムのテスト環境提供スケジュールを事前に確保してください。
5-5. システムテスト結果書
- 作成主体: QAチーム
- 核心内容: システム全体機能テスト、エンドツーエンド（E2E）シナリオ、回帰テスト（Regression）、インストール/デプロイテスト
- 注意点: システムテスト環境は本番環境にできる限り近い構成にしてください。
5-6. 性能テスト結果書
- 作成主体: 性能テストエンジニア
- 核心内容: 目標TPS（1秒あたりトランザクション数）、レスポンスタイム目標（例: 2秒以内）、同時接続ユーザー数、負荷テスト/ストレステスト/耐久テスト結果、ボトルネック分析
- 注意点: 性能目標は要件定義書に事前に明記してください。「速いといい」という曖昧な要件は紛争の原因になります。
- 主要ツール: Apache JMeter、Gatling、k6、nGrinder
5-7. セキュリティ脆弱性診断結果書
- 作成主体: セキュリティ専門家/セキュリティツール
- 核心内容: OWASP Top 10診断（SQLインジェクション、XSS、CSRF、認証脆弱性等）、KISAセキュアコーディング診断結果、発見された脆弱性の深刻度（Critical/High/Medium/Low）、対処結果
- 注意点: 韓国の公共事業では行政安全部「ソフトウェアセキュリティ弱点診断ガイド」基準に従う必要があります。
5-8. 欠陥一覧および対処結果書
- 作成主体: QAチーム + 開発チーム
- 核心内容: 発見された欠陥一覧、深刻度（Critical/Major/Minor）、欠陥種別、対処担当者、対処内容、再検証結果
- 注意点: Critical欠陥は必ず本番稼働前に100%解消してください。Major以上の欠陥が残る場合の稼働判断は発注者と協議が必要です。
5-9. UAT結果書（ユーザー受け入れテスト）
- 作成主体: 発注者ユーザー（QAサポート）
- 核心内容: 発注者が直接実施した受け入れテスト結果、テストケースごとの判定、最終受け入れ署名
- 注意点: UATは発注者の最終受け入れの法的根拠となります。署名には契約上の効力が生じる可能性があるため、慎重に管理してください。
5-10. テスト完了報告書
- 作成主体: QAリード/PM
- 核心内容: テスト全体サマリ、欠陥状況（発見/解消/残存）、性能測定結果サマリ、本番稼働適合性判定意見、残存リスク
- 注意点: テスト完了報告書は本番稼働判断の根拠文書です。「稼働可能」判定はPMと発注者が共同で決定してください。
6. 移行/本番稼働フェーズ — カットオーバー
開発・テスト環境から実際の本番環境へ移行するフェーズです。
6-1. データ移行計画書
- 作成主体: DBA + データエンジニア
- 核心内容: 移行対象データ一覧、ソース-ターゲットマッピングテーブル、データ変換ルール、移行方式（全量移行/差分移行）、移行スケジュール、ロールバック計画
- 注意点: 大容量データ移行の場合は移行所要時間を事前にドライランで計測してください。
6-2. データ移行結果書
- 作成主体: DBA + QA
- 核心内容: 移行前後のデータ件数比較、エラー件数・種別、例外処理内訳、データ整合性検証結果
- 注意点: 「移行はうまくいった」という口頭確認では不十分です。件数比較とサンプル検証を文書化してください。
6-3. 移行シナリオ/カットオーバー計画書
- 作成主体: PM + インフラチーム
- 核心内容: 本番稼働当日（D-Day）の作業順序とタイムライン、各ステップの担当者・連絡先、Go/No-Go判断基準、ロールバック手順、緊急連絡網
- 注意点: カットオーバー計画は必ずリハーサル（カットオーバーリハーサル）で検証してください。本番で初めて実行するのは高リスクです。
6-4. カットオーバーチェックリスト
- 作成主体: PM + 各パートリード
- 核心内容: 本番稼働前最終確認項目（サーバ起動確認、DB接続確認、インターフェース連携確認、ユーザーアカウント確認、バックアップ完了確認等）、Go/No-Go基準ごとのステータス
- 注意点: チェックリスト項目は「確認した」という記録だけでなく、実際の測定値（例: DB接続レスポンス0.5秒以内）を含めてください。
6-5. 本番稼働結果報告書（Go-Liveレポート）
- 作成主体: PM
- 核心内容: 本番稼働完了確認、初期安定化期間（通常2〜4週間）のモニタリング結果、稼働後発生したイシューと対処結果、安定化完了宣言
- 注意点: 本番稼働直後は集中監視体制を維持してください。ウォールームの運営を推奨します。
7. 終了フェーズ — 納品とプロジェクト完了
プロジェクトを正式に締めくくり、運用チームへ引き継ぐフェーズです。
7-1. ユーザーマニュアル
- 作成主体: テクニカルライター/開発者
- 核心内容: 一般ユーザー向け、画面ごとの操作説明、よくある質問（FAQ）、エラー発生時の対処方法
- 注意点: 最終的な本番画面のスクリーンショットを使用して作成してください。開発中に作成したマニュアルは画面が変更されると無意味になります。
7-2. 運用者マニュアル（管理者マニュアル）
- 作成主体: 開発者/インフラエンジニア
- 核心内容: システム管理者向け、デプロイ手順、設定ファイル説明、モニタリング方法、ログ確認、定期点検項目、障害一次対応手順
- 注意点: 運用者マニュアルなしに引き継ぐと、運用チームが障害時に開発チームに依存し続けることになります。
7-3. システム運用ガイド
- 作成主体: インフラエンジニア/DevOps
- 核心内容: サーバ構成・スペック一覧、主要プロセス管理方法、バックアップ・リカバリポリシー、キャパシティプランニング、セキュリティパッチ管理
- 注意点: インフラ構成図を最新の状態に保ち、構成管理ツールに保存してください。
7-4. 障害対応シナリオ（Runbook）
- 作成主体: インフラエンジニア/DevOps
- 核心内容: 想定される障害種別ごとの症状・原因・対応手順、エスカレーション基準、RTO（復旧時間目標）/RPO（復旧時点目標）
- 注意点: Runbookは経験のない担当者でも高圧状態で実行できるよう、具体的に記述してください。
7-5. ソフトウェア構成管理一覧（SCM）
- 作成主体: 構成管理担当者/PM
- 核心内容: 納品ソースコード一覧（ファイル名/バージョン）、バイナリ一覧、オープンソースライセンス一覧、ビルド方法、設定ファイル一覧
- 注意点: オープンソースライセンス違反は法的紛争につながる可能性があります。納品前にオープンソーススキャン（SBOM生成）を実施してください。
7-6. 完了報告書
- 作成主体: PM
- 核心内容: プロジェクト全体サマリ、目標達成状況、コスト精算（計画比実績）、スケジュール精算、品質精算、主要成果と課題
- 注意点: 完了報告書は最終検収の根拠文書です。発注者担当者の最終承認（押印または電子署名）が必要です。
7-7. 瑕疵担保計画書
- 作成主体: PM + カスタマーサポートチーム
- 核心内容: 瑕疵担保期間（通常納品後1年）、SLA定義（応答時間/処理時間）、担当者連絡先、瑕疵区分（操作方法の問い合わせ vs 実際の不具合）、パッチ展開手順
- 注意点: 瑕疵担保（契約範囲内の不具合修正）と機能追加・変更開発（契約範囲外）を明確に区別してください。
7-8. プロジェクト教訓（Lessons Learned）
- 作成主体: PM + プロジェクトチーム全員
- 核心内容: うまくいったこと（ベストプラクティス）、改善が必要な点、繰り返してはならない失敗、適用したツール・方法論の評価、次プロジェクトへの提言
- 注意点: 教訓文書は組織のプロセス資産（Organizational Process Assets）です。チーム内で共有するだけでなく、PMOに登録して組織全体に活かしてください。
7-9. ナレッジトランスファー教育資料
- 作成主体: 開発チーム/分析チーム
- 核心内容: システム構造説明資料、運用チーム向け研修スライド、ハンズオンガイド、よくある問い合わせと対応方法
- 注意点: ナレッジトランスファーは文書だけでは不十分です。ハンズオン研修を組み合わせ、運用チームが自律的に運用できる能力を身につけるまでサポートしてください。
8. 公共事業特有の成果物
公共機関が発注するプロジェクトでは、法令・行政指針に基づいて追加の成果物が求められます。
8-1. 情報化戦略計画書（ISP）
- 概要: 中長期IT推進ロードマップ策定文書
- 関連指針: 行政安全部「情報システム構築・運営指針」
- 核心内容: 現状診断、情報化ビジョン・目標、課題ごとの優先順位、予算見積り、推進スケジュール、期待効果
- 注意点: ISPは単独事業として発注されることが多く、ISP結果に基づいてシステム構築事業が発注されます。
8-2. 個人情報影響評価書（PIA）
- 法的根拠: 個人情報保護法第33条（一定規模以上の公共機関への義務付け）
- 核心内容: 個人情報処理項目、収集根拠、保存期間、セキュリティ措置、リスク分析と改善措置
- 注意点: PIAは個人情報保護委員会が指定した評価機関が実施する必要があります。
8-3. 情報保護計画書
- 関連法令: 電子政府法、情報通信網法、ISMS-P認証基準
- 核心内容: セキュリティ脅威分析、セキュリティ要件、セキュリティアーキテクチャ、脆弱性対応計画、セキュリティ監視方針
- 注意点: ISMS-P認証が必要なシステムの場合、認証審査基準と連動して作成する必要があります。
8-4. ソフトウェア事業対価算定書
- 関連法令: ソフトウェア振興法、NIPA「SW事業対価算定ガイド」
- 核心内容: 機能点数（FP: Function Point）算定内訳、補正係数適用、投入工数算定、単価適用
- 注意点: 公共事業での対価算定は第三者が検証することが多いため、算定根拠を透明に記述してください。
8-5. ソフトウェア監査報告書（SW監査報告書）
- 法的根拠: ソフトウェア振興法第65条（事業費100億ウォン以上の公共事業に義務付け）
- 核心内容: フェーズ別監査（分析監査/設計監査/実装監査/終了監査）、監査指摘事項、対処計画と結果
- 注意点: 監査は登録された監査法人が実施します。監査指摘事項はすべて対処しなければなりません。
8-6. 著作権帰属確認書
- 核心内容: プロジェクト成果物（ソースコード、文書、データ）の著作権が発注者に帰属することを確認する文書
- 注意点: ベンダーが再利用予定の共通モジュール・ライブラリの著作権処理方式を事前に協議し、明記する必要があります。
8-7. 納品確認書
- 核心内容: 最終納品物一覧（ソースコード/文書/研修/ライセンス等）、各項目ごとの納品確認、発注者検収担当者の署名
- 注意点: 納品確認書への署名により代金支払条件が充足されます。未完了項目がある場合は条件付き受け入れ方式を事前に協議してください。
9. 成果物管理の実務ヒント
9-1. 成果物番号体系
一貫した番号体系は成果物管理の基本です。例:
PJ-2024-001-分析-001 → 2024年001番プロジェクト、分析フェーズ、001番文書
PJ-2024-001-設計-005 → 2024年001番プロジェクト、設計フェーズ、005番文書
9-2. 構成管理（Configuration Management）
- ベースライン設定: 各フェーズ完了時に承認された成果物を凍結（Freeze）します。
- 変更管理（Change Control）: ベースライン後の変更は必ずCCB（変更制御委員会）の承認を得てください。
- バージョン管理: 文書バージョンを
v1.0、v1.1、v2.0の形式で管理し、主要な変更履歴を文書内に記録します。
9-3. ツール活用
| 用途 | ツール例 |
|---|---|
| 文書コラボレーション | Confluence、Notion、Google Docs、SharePoint |
| ソースコード | GitHub、GitLab、Bitbucket |
| イシュー管理 | Jira、Redmine、GitHub Issues |
| 図表作成 | draw.io、Lucidchart、PlantUML、Mermaid |
| テスト管理 | TestRail、Zephyr、Xray |
| 構成管理 | SVN、Git + Git LFS |
9-4. PMBOKの成果物 vs 韓国式成果物
PMBOKで定義される成果物と韓国のIT現場で実際に要求される成果物は、名称と構成が異なる場合があります。例えば、PMBOKの「プロジェクト憲章（Project Charter）」に相当する文書が、韓国では「착수보고서（着手報告書）」や「사업수행계획서（事業遂行計画書）」として通用しています。
クイズ：理解度チェック
クイズ1: RFPで技術提案書と価格提案書を分離して提出する主な理由は？
答え: 価格に影響されない公正な技術評価を保証するためです。
解説: 評価委員が価格を知らない状態で技術力を先に評価することで、価格が高くても技術力が優れた企業が公正に評価を受けられます。価格情報が先に公開されると評価基準が歪む可能性があります。これを「二封筒（Two-Envelope）」方式と呼びます。韓国の公共調達および国際競争入札において標準的な手続きです。
クイズ2: SRSにおけるMoSCoW手法の「M」と「W」はそれぞれ何を意味しますか？
答え: M = Must Have（今回のリリースで必ず実装すべき必須要件）、W = Won't Have（今回のスコープから除外する要件）
解説: MoSCoWはMust Have、Should Have、Could Have、Won't Haveの頭文字を取った優先順位決定手法です。「Won't Have」は「不要」という意味ではなく、「今回のリリース範囲には含めない」という意味で、次バージョンで実装される可能性があります。この手法によりスコープをクライアントと明確に協議でき、スコープクリープを防止できます。
クイズ3: 要件トレーサビリティマトリクス（RTM）の主要目的は何ですか？
答え: 要件IDと設計・開発・テスト成果物IDをマッピングし、すべての要件が漏れなく実装・検証されているかを追跡することです。
解説: RTMを管理することで「この機能はなぜ作られたのか」「この要件はどのテストケースで検証されたのか」を即座に確認できます。韓国の公共事業ソフトウェア監査（감리）では、RTMは必須確認項目です。RTMなしでは要件網羅性の証明がほぼ不可能になります。
クイズ4: カットオーバー計画書でロールバック計画が必須な理由は？
答え: 本番稼働当日に予期しない致命的な問題が発生した際、迅速に前のシステムに戻せるようにするためです。
解説: どれだけ徹底したテストを行っても、本番環境でのみ発生する問題が存在することがあります。ロールバック計画がなければ、深刻な障害発生時の復旧に数時間から数十時間かかる可能性があります。No-Return Point（引き返せない地点）、ロールバック手順、データ復旧方法を明確にしておく必要があります。
クイズ5: ソフトウェア監査（감리）が義務化される公共事業の基準は？
答え: ソフトウェア振興法に基づき、事業費100億ウォン以上の公共情報化事業はフェーズ別監査が義務です。
解説: フェーズ別監査は分析監査、設計監査、実装監査、終了監査で構成されます。監査はKOSA（韓国ソフトウェア産業協会）等に登録された監査法人が実施し、監査指摘事項を対処しなければ次のフェーズへ進めません。100億ウォン未満の事業も自主的に監査を実施することが推奨されています。
クイズ6: 瑕疵担保（하자보수）と保守運用（유지보수）の本質的な違いは何ですか？
答え: 瑕疵担保は納品時の契約範囲に含まれていた機能が正常動作しない欠陥を無償で修正することであり、保守運用は契約範囲を超える機能変更・追加を別途契約により有償で実施することです。
解説: 現場では発注者が瑕疵担保期間中に新機能追加や要件変更を「欠陥修正」として要求するケースが多くあります。これを防ぐには、契約書で瑕疵の定義を明確にし、UATで最終機能範囲を確認した上で署名を受けておく必要があります。
クイズ7: 個人情報影響評価（PIA）が義務化される韓国の公共機関の基準は？
答え: 個人情報保護法第33条により、5万人以上の情報主体に関する個人情報を処理する公共機関、または機微情報・固有識別情報を処理する公共機関はPIAを実施する義務があります。
解説: PIAは単なる文書作成ではなく、個人情報処理過程のリスク要素を分析し、対応策を策定する活動です。PIA結果は個人情報保護委員会へ提出する必要があり、未実施の場合は過怠料が課される可能性があります。
おわりに
ITプロジェクトの成果物は「監査を通過するための書類」ではありません。各成果物はチームが正しい方向に進んでいるかを確認するチェックポイントであり、ステークホルダー間の合意の証拠であり、システムを長年にわたって保守するチームにとっては貴重な知識資産です。
形式的に成果物を作成するのではなく、プロジェクトに真の価値を提供する文書を作る習慣を身につけてください。それが優れたPMと平凡なPMの差を生み出します。