2026年10月23日 · tech-expert.moscow編集部
まず、何を引き渡す必要があったかを明確にする
「稼働用データベース」という言葉は、テーブルスキーマ、テストレコード一式、本番データのコピー、設定済みですぐに使えるシステムなど、さまざまなものを意味し得ます。そのため確認は、技術仕様書、契約の付属書、合意済みの引渡し手順、成果物の構成に関する通信記録から始めます。展開後に、どの期間の、どのデータと機能が、どの環境で利用可能であるべきかという具体的な基準が必要です。
想定される資料の一覧を作り、各項目に実際に受領したファイル、リンク、アクセス情報を記載すると役立ちます。引渡し日、受領方法、プロジェクトのバージョンも別途記録します。これにより、コンポーネントの欠如、開けない状態、合意済み内容との相違を区別できます。backupという名前のフォルダーがあるだけでは、適切なバックアップが入っていることの裏付けにはなりません。
ソースコード、スキーマ、データはそれぞれ役割が異なる
コードはアプリケーションのロジックを記述します。データベーススキーマは保存構造を定めます。マイグレーションはその構造を段階的に変更します。初期データは、利用者のロール、ステータス、設定、マスターデータなどを作成する場合があります。本番レコードには運用中に蓄積された情報が含まれます。これらは相互に関連しますが、一つが別のものを代替するわけではありません。
例えば、マイグレーションにより空のテーブルが正常に作成され、アプリケーションにログイン画面が表示される場合があります。しかし、それだけでは文書、操作履歴、ファイルが移行されたとは確認できません。逆に、データは渡されていても、コードのバージョンが別のフィールドを想定している場合もあります。その場合のエラー原因は一式の互換性であり、必ずしもデータベースの欠如ではありません。
データベースと併せて確認すべきコンポーネント
- エクスポートの内容。 スキーマ、レコード、シーケンス、必要な関数、その他のオブジェクト。対象テーブルや期間による制限の有無。
- バージョン。 データベース管理システム、拡張機能、アプリケーションの実行環境、記録されたソースコードのバージョン。
- ユーザーと権限。 アプリケーションに必要なロールと、インストール手順書で定められた権限。
- ファイルストレージ。 データベースから参照される、アップロード済みの文書、画像、その他のオブジェクト。
- 設定と依存関係。 サービスのアドレス、タスクキュー、スケジューラー、検索インデックス、外部連携の要件。
- 手順書。 ビルド、復元、起動、確認の手順、および許容される環境パラメーターの一覧。
機密情報や本番用パスワードを、誰でも閲覧できる通信に含めたり、ソースコードと一緒に公開したりしてはいけません。調査に必要な情報は、安全な方法での提供、または管理された環境内での確認について協議します。匿名化したコピーを使う場合は、置換した情報と、それが確認対象の機能に及ぼし得る影響を説明することが重要です。
SQLファイルの存在だけでは復元成功とはいえない理由
エクスポートの形式とパラメーターは重要です。例えばPostgreSQLでは、一つのデータベースの通常のエクスポートだけでは、クラスター共通のオブジェクトすべては含まれず、ロールやテーブルスペースは別途扱う必要があります。スキーマのみのエクスポートにはユーザーレコードが含まれません。そのため、アーカイブのサイズやファイル拡張子から分かる引渡し内容は予備的なものにとどまります。
復元の確認では、ログと処理の完了状態を考慮しなければなりません。ツールがエラー後も処理を継続した場合、一部のオブジェクトが復元されていない可能性があります。画面が起動したことも、データの確認に代わるものではありません。特定文書を開く、既知の期間のレコードを検索する、計算を実行する、想定される元データを使った報告書を作成するなど、事前に合意した確認操作が必要です。
元の資料を保存しながら確認する方法
- 受領した一式を元の状態で保存し、ファイル目録を作成して、受領時の事情を記録する。
- 調査用に別の作業コピーを作成する。そのコピーで稼働中の本番システムを置き換えない。
- テスト環境の仕様を記録し、プロジェクトの要件と照合する。
- 復元手順、エラー、警告、実際に作成されたオブジェクトを確認する。
- 合意済みのシナリオを実行し、入力データを含め、各手順の結果を記録する。
- 一式の修正・補充のために行った操作を別途列挙し、結果への影響を確認する。
未知のインストールスクリプトやダンプを実行する前に、その内容と安全な実行方法を技術的に評価する必要があります。復元は、アクセスを制限した専用環境で行います。これにより、引渡し後にすでに変更が蓄積している可能性がある稼働中サーバーの特性と、引き渡された一式そのものの特性を区別することもできます。
判明した相違点の記述方法
「データベースが動かない」という一般的な指摘の代わりに、期待される機能、初期条件、確認する資料、操作手順、実際の結果、それを裏付けるログを表にまとめると役立ちます。添付ファイルが開けない場合は、データベースのレコードだけでなく、対応ファイルの存在、パス、アクセス権限も確認する必要があります。履歴がない場合は、提供されたコピーがどの期間を含んでいるかを明らかにします。
各結論は、資料の特定のバージョンと結び付けます。新しいファイルを追加した後に正常起動しても、それだけで当初の一式が完全だったとはいえません。同様に、不適切なサーバーバージョンでの障害自体は、引き渡されたコードの不具合を裏付けません。調査では、結果が観察される条件を明確に示す必要があります。
鑑定人に用意すべき資料
技術仕様書、引渡し目録、ソースコードのアーカイブまたは合意済みのリポジトリアクセス、受領したデータベースのコピー、手順書、エラーメッセージを提供してください。以前は動作していた、または要件で定められたシナリオの一覧を添え、その根拠も示してください。以前のサーバーへのアクセスが残っている場合は、その状態の記録方法を事前に協議してください。
チェックサムは、保管と調査の各段階を通じてファイルが変わっていないかを確認する助けになります。ただし、それ自体は作成者、作成日時、一式の契約適合性を証明しません。技術調査では、提供資料に基づき、構成、互換性、動作の再現性を明らかにできます。契約上の効果を評価するには、文書と紛争の事情を別途検討する必要があります。
調査のための質問事項
- 引き渡された一式にはどのようなソフトウェアコンポーネントとデータが含まれ、合意済み機能の確認にはどの資料が不足していますか。
- ソースコード、データベーススキーマ、提供されたデータの各バージョンは相互に適合していますか。
- 引渡し時の手順書に従い、技術仕様書に定められた環境でシステムを展開できますか。
- 復元と確認シナリオの実行時にどのような具体的エラーが発生し、その技術的原因は何ですか。
- 所定の機能を再現するには、どのような追加コンポーネントや操作が必要ですか。