- システム保守で発注者が揃えるべき11種類のドキュメントと役割
- 整備の優先順位（インフラ構成図・パスワード管理表を最優先に）
- 既存ベンダーから資料を受領するための実践的な交渉方法
- ドキュメント陳腐化を防ぐための発注時の工夫
システム保守でドキュメント不足が引き起こす3つの問題
「ベンダーを変えようとしたら、資料がなくて身動きが取れない」「担当者が退職してシステムの全容がわからない」――こうした声は、システムを外注している企業から後を絶ちません。
保守ドキュメントが整備されていない状態が続くと、次の3つの問題が発生しやすくなります。
- ベンダー依存の固定化：資料がなければ他社への切り替えが実質不可能になります。現行ベンダーへの交渉力も失われます
- 障害対応の長期化：システム構成を把握した担当者がいないと、障害発生時の原因特定に時間がかかり、業務影響が拡大します
- 改修コストの増大：「なぜこうなっているか」がわからない状態で機能追加を依頼すると、調査費用が見積もりに上乗せされます
この記事では、発注者側が最低限揃えておくべきドキュメントの種類と、現実的な整備方法を解説します。
システム保守に必要なドキュメント11種類
保守ドキュメントは大きく「開発成果物（ベンダーが納品すべきもの）」と「運用ドキュメント（社内で管理すべきもの）」の2種類に分けられます。
開発成果物（ベンダーから受領すべき資料）
1. 要件定義書
システムに「何を求めるか」を文書化したものです。開発後に「そんな機能は頼んでいない」という認識齟齬が起きたとき、最初に参照する資料です。発注者としてレビューし、合意した内容を記録として保持してください。
2. 基本設計書（外部設計書）
画面構成・帳票・外部連携など、ユーザーから見える仕様をまとめた資料です。改修を依頼する際に「現状の仕様がどうなっているか」を確認するために使います。
3. 詳細設計書（内部設計書）
データベース設計・プログラム構造など、実装レベルの仕様書です。ベンダーを変更する際に必須となる資料ですが、「渡せない」と言われるケースも多いため、契約時に納品物として明記しておくことが重要です。
4. テスト仕様書・テスト結果報告書
どのようなテストを実施したか、どの条件で正常動作を確認したかの記録です。障害対応時に「この動作は仕様か不具合か」を判断する根拠になります。
5. インフラ構成図
サーバー構成・ネットワーク構成・利用しているクラウドサービスの一覧です。障害対応やセキュリティ対策の際に「どこに何があるか」を把握するために必要です。AWSやGCPなどのクラウド環境では、構成図だけでなく設定値（IP・セキュリティグループ等）もあわせて受領してください。
6. ER図・テーブル定義書
データベースのテーブル構造と項目定義をまとめた資料です。データ移行や連携システムの追加を検討する際に不可欠です。
運用ドキュメント（社内で整備・管理する資料）
7. 操作マニュアル（エンドユーザー向け）
現場の担当者が日常業務で使うための手順書です。担当者が変わっても業務が継続できるよう、画面キャプチャ付きで整備することを推奨します。
8. 運用手順書（管理者向け）
バッチ処理の実行手順・バックアップ手順・ユーザー追加・削除の方法など、日常の管理業務をまとめた資料です。定期作業は「誰がいつ何をするか」をチェックリスト形式で管理すると漏れが減ります。
9. 障害対応手順書
障害発生時の連絡先・対応フロー・よくある障害と復旧方法をまとめた資料です。特に「ベンダーへのエスカレーション基準（いつ連絡するか）」を明記しておくと、夜間・休日の判断に迷いません。
10. 変更管理台帳
いつ・誰が・どのような改修をしたかの履歴を記録する台帳です。「以前は動いていたのに急に動かなくなった」という問題の原因を追いかける際に役立ちます。Excelやスプレッドシートでもかまわないのでシンプルな形式で継続管理することが重要です。
11. パスワード・アクセス情報管理表
サーバーのSSH情報・クラウドコンソールのアカウント・FTPアカウントなど、システムにアクセスするための情報を安全に管理する資料です。担当者の退職・ベンダー変更時に「アクセス権がわからない」という事態を防ぎます。パスワードマネージャー（1Password・Bitwardenなど）を活用すると管理が楽になります。
ドキュメント整備の優先順位
すべての資料を一度に揃えようとすると途中で止まります。以下の順序で段階的に整備することを推奨します。
| 優先度 | ドキュメント | 理由 |
|---|---|---|
| 最優先 | インフラ構成図・パスワード管理表 | 障害時・ベンダー変更時に即座に必要 |
| 高 | 障害対応手順書・運用手順書 | 日常運用の安定化と夜間対応品質に直結 |
| 中 | 要件定義書・基本設計書・変更管理台帳 | 改修・機能追加の品質向上と認識齟齬の防止 |
| 低（長期） | 詳細設計書・ER図・テスト仕様書 | ベンダー変更・大型改修時に必要だが整備コストが高い |
既存ベンダーから資料を受領するコツ
「今から資料をくれ」と依頼しても断られるケースや、出てきた資料が実態と乖離しているケースがあります。以下の3点を意識してください。
1. 契約時に納品物として明記する
新規開発・改修の契約時に「成果物一覧」として詳細設計書・ER図・インフラ構成図を含めておくのが最も確実です。後から要求するより、契約段階で決めておく方が費用・期間ともに合意しやすくなります。
2. 保守契約の更新タイミングで交渉する
保守契約の更新時は交渉の好機です。「更新条件としてドキュメント整備を含める」形で提案すると、ベンダーも対応しやすくなります。
3. 段階的に資料化を依頼する
「すべての設計書を今すぐ」ではなく、「次の改修作業と合わせて該当箇所の設計書を更新してほしい」と段階的に依頼する方法も有効です。コストを分散しながら徐々にドキュメントを充実させられます。
資料を受領しても「陳腐化」が問題になるケース
受領した時点で正確だったドキュメントも、改修を繰り返すうちに実態と乖離していきます。「最初にもらったけど今は全然違う」という状態が最も危険です。
陳腐化を防ぐには、改修の際にドキュメントの更新も作業範囲に含めることが鉄則です。見積もりの段階で「資料の更新作業も含む」と明示し、コストを認識した上で発注することで、常に最新の状態を維持できます。
まとめ：保守ドキュメント整備のポイント
- 発注者が持つべき資料は「開発成果物（ベンダーから受領）」と「運用ドキュメント（自社管理）」の2種類
- インフラ構成図とパスワード管理表を最優先で整備する
- 新規契約・改修依頼時に納品物として明記するのが最も確実
- 改修のたびにドキュメントを更新させる仕組みを作ることで陳腐化を防ぐ
- 資料が整っているとベンダー変更時の選択肢が広がり、コスト交渉力も向上する
この記事をシェア