引き取りの基準はプロジェクト終了の直前に作ると遅い
受入条件は、最終の検収会議で新たに書く要件一覧ではありません。何が完了かを作業の前に定め、その物差しでテストと終了の可否を判断すべきです。顧客の受入条件を作業開始前にできるだけ明確に定義し、それを受入テストの根拠に使うことは、作業管理ツールの指針にも共通する案内です。[6]
受入条件には少なくとも六つの要素が要ります。どの機能・システム・環境・データが範囲か、どの結果が出れば完了か、テスト結果・ログ・リポジトリ・文書・設定内容のうち何を提出するか、誰がどの環境で再確認するか、誰がREADY、READY WITH CONDITIONS、HOLDを決めるか、未完了項目をどの条件で残せるかです。
この構造がなければ、検収会議は「おおむね動いているようだ」と「我々は開発を完了した」がぶつかる場になります。
機能検収と運用引き取りをなぜ分けるのか
二つのゲートは互いにつながっていますが、同じ問いには答えません。
英国政府のサービス準備性レビューの指針も、利用者受入テスト、結合テスト、非機能テストを運用受入テストと区別します。さらに、試験済みの復旧計画、未解決の欠陥、セキュリティ課題、データ移行、引き取り後の運用責任者までを確認対象に置きます。[7]
機能検収が終わったからといって運用引き取りまで自動で終わるわけではありません。逆に運用文書をすべて受け取っても、中核機能が合意条件を満たさなければ機能検収は通りません。
- 機能検収ゲート
- 機能検収ゲートは合意した要件が作られたかを確かめる関門であり、中核の流れ、役割ごとの許可と遮断、計算とデータ変更、外部連携、非機能の基準、未解決の欠陥と除外範囲を見ます。
- 運用引き取りゲート
- 運用引き取りゲートは、引き取る組織が供給者に頼らずシステムを統制できるかを確かめる関門であり、ソース、ビルド、配備、アカウント、データ、復旧、セキュリティ、監視、保守の境界を見ます。
リリース判断につながる検証 — 主要フローを検証し、実行結果と残る条件をリリース判断の根拠につなげます。
引き取りマトリクスは何を問うか
次の表でFは機能検収、Oは運用引き取り、Bは両方のゲートに影響する項目を指します。領域ごとに、合意する基準・必須の証跡・引き取る側が自ら行うこと・代表的なHOLD条件を併記します。
READY WITH CONDITIONSは、リスクの範囲と暫定の対応策、責任者、完了期限がすべて定まったときだけ使います。HOLDは、現状では技術・運用の引き取りを完了しないという意味です。この判定が代金の支払いや法的な所有権に及ぼす効果は契約と法務検討の領域であり、ここでは扱いません。
領域 | ゲート | 合意する基準 | 必須の証跡 | 引き取る側が自ら行うこと | 代表的なHOLD条件 |
|---|---|---|---|---|---|
| 要件・受入条件 | F·B | 要件の識別子と適用バージョン、完了条件、除外範囲が固定されている | 要件一覧、受入テストの結果、未完了・例外の一覧 | 中核要件とテスト結果を標本で追跡し、例外の承認者を確認 | 基準が事後に変わったか、中核要件の結果がない |
| ソースコード | O | 合意範囲のアプリケーションコード、DBマイグレーション、ビルド・配備スクリプト、設定テンプレート、必要なIaCが含まれる | 最終コミットとタグ、リポジトリ一覧、ソースアーカイブのハッシュ、LFS・サブモジュール一覧 | 本番配備版がどのコミットから作られたかを追跡 | 本番版と受領ソースが違うか、中核コードが欠けている |
| リポジトリの所有権 | O | 個人アカウントではなく引き取る組織がリポジトリと組織設定を統制する | 所有組織、管理者一覧、チームと権限、ブランチ規則、Webhook・デプロイキー一覧 | 引き取る組織の所有者が設定・権限・保護規則を変更 | ベンダーの個人や組織だけが所有者で、発注側は協力者にとどまる |
| ビルドの再現性 | O | 指定したソースリビジョンと文書化された環境で成果物を作り直せる | ランタイム・コンパイラのバージョン、ロックファイル、ベースイメージ、ビルドコマンド、ログ、成果物のハッシュまたは来歴 | 綺麗なランナーや新しい機材で自ら直接ビルド | 特定の開発者PCや到達できない私設レジストリでしかビルドできない |
| 配備手順 | O | 引き取る組織のアカウントで検証・本番環境へ配備できる | パイプライン定義、配備ランブック、環境一覧、設定・機密情報の参照方式、ヘルスチェック | 引き取る側が非本番環境へ直接配備し結果を確認 | 文書化されていない手作業やベンダーのアカウントが必須である |
| 資格情報・アカウントの所有権 | O | アカウントは組織名義で、個人の共用アカウントを使わない。権限、復旧手段、多要素認証、機密情報のライフサイクルが定まっている | アカウント・ロールの目録、復旧連絡先、多要素認証の状態、機密情報の交換・失効の記録 | 自組織のアカウントでログインし、ベンダーの接近を交換・失効 | 最上位管理者や復旧メールをベンダーだけが統制するか、資格情報の出所が不明 |
| ドメイン・DNS・クラウドアカウント | O | 登録者、支払い主体、復旧連絡先、最上位管理者、更新責任を引き取る組織が統制する | レジストラ、DNSゾーン、クラウドアカウント、請求、サポートの目録 | DNS変更、ドメイン更新、クラウドサポート要請の権限を確認 | ドメインやルートアカウント、決済アカウントがベンダー名義でしか存在しない |
| データの書き出し・移行 | B | 対象データの範囲・形式・保存・整合性検証の方式が合意されている | データ辞書、スキーマ、書き出し・移行スクリプト、件数・合計・ハッシュの検証結果 | 標本または隔離環境で書き出しと取り込みを実施 | 完全な書き出し経路がないか、移行後に件数・金額・関係の整合を確認できない |
| バックアップ・復旧 | O | バックアップの生成だけでなく、合意した時点へ復旧できる | 方針、保管場所、直近の成功記録、復旧試験の報告、測定した所要時間 | 隔離環境で直近のバックアップを復旧しアプリケーションを確認 | 成功ログだけで復旧試験がないか、引き取る側がバックアップに接近できない |
| セキュリティの指摘 | B | 検証の範囲・方法・バージョンと、すべての未解決指摘が開示されている | セキュリティ試験報告、機密情報スキャン、未解決項目、再試験の結果、リスク受容者と期限 | 開示された指摘が現在の配備版と合うかを標本で確認 | 重大な未解決課題の影響・緩和策・責任者がないか、機密情報がコードに残る |
| 依存関係・ライセンス | O | 実行に必要な内外の構成要素と接近経路、サポート終了の状態を把握する | ロックファイル、SBOM、私設パッケージ一覧、構成要素のバージョン・ハッシュ・ライセンス・EOL情報 | 新しい環境ですべての依存を取得し導入してビルド | 必須の私設パッケージに接近できないか、誰が保守するか分からない |
| 監視 | O | 運用状態が見え、通知が行動できる担当者に届く | ダッシュボード、通知規則、ログの権限と保存、通知経路、ランブック | 試験通知を発生させ、受信・確認・対処の経路を検証 | 運用の可視性がベンダーのアカウントにしかないか、通知の受け手がいない |
| 文書 | O | 文書が最終版と一致し、実作業を再現できるほど具体的である | アーキテクチャ、データフロー、API、バッチ・cron、配備、バックアップ、障害対応、アカウント目録 | 文書だけを見てビルド・配備・復旧のいずれかを実施 | 中核の手順が口伝でしか残らないか、文書が過去の版を説明している |
| 既知の問題 | F·B | すべての既知の欠陥・制約・技術的負債を影響とともに開示する | 課題の識別子、影響バージョン、再現手順、影響度、回避策、責任者、目標日 | 標本の課題を再現し、現在の状態と回避策を確認 | 中核業務・セキュリティ・データに影響する課題が隠れているか、所有者がいない |
| 瑕疵・保守の境界 | O | 欠陥、変更要求、運用作業、外部障害を技術的に分類し、受付と判定の手順を定める | 分類表、支援窓口、稼働時間、証跡の要件、上位移管、外部ベンダーの境界 | 同じ例示チケットを双方が同じ種別に分類するかを確認 | 障害が起きても、どの組織も受付・判定・対処を担わない構造 |
| 運用責任者 | O | システム、ソース、クラウド、データ、セキュリティ、障害対応の責任役割と代理者が指名されている | RACIまたは所有者台帳、担当者と代理者、権限確認の記録 | 実際の所有者が初回の配備・復旧・通知訓練に参加 | IT部門のような抽象的な組織名だけで、実際の権限を持つ担当者がいない |
ソースコードを受け取ったというだけでは足りない
ソースコードの圧縮ファイルを受け取ることと、ソフトウェアを統制することは違います。最終の本番版がどのコミットとタグから作られたかが分かり、課題・プルリクエスト・リリースの記録と設定が残るリポジトリを引き取る必要があります。GitHubを使う場合、リポジトリを移管すれば新しい所有者は中身だけでなく課題、プルリクエスト、リリース、プロジェクト、設定まで管理できます。[1] ただしWebhookや機密情報、デプロイキーもつながったまま残りうるため、移管後に権限と機密情報を別途監査する必要があります。
リポジトリが特定の担当者一人に依存してもいけません。GitHubは、所有者一人と連絡が取れなくなるとプロジェクトへの接近が絶たれうるため、組織ごとに複数の所有者を勧めます。[8] これは特定製品の機能ではなく、ソース管理の権限を個人に集中させないという運用原則として読めます。
GitHubを使わない案件でも物差しは同じです。プラットフォームが何であれ、引き取る組織がリポジトリ、権限、変更履歴、保護方針、パッケージ保管庫を直接統制する必要があります。
すべての案件にビット単位の再現ビルドが要るわけではない
再現可能なビルドの厳密な定義は、同じソースとビルド環境、手順で誰もがビット単位まで同じ成果物を作れることです。これを確かめるにはソースリビジョン、依存のバージョン、ビルドフラグ、環境変数、成果物のハッシュが要ります。[9]
しかし、すべてのSI案件の最小の受入条件をただちにビット単位の同一性に定める必要はありません。リスクに応じて二段階に分けるほうが現実的です。基本は「作り直せるビルド」です。綺麗な環境で受領したソースリビジョンを取得し、固定したランタイムと依存で実行可能な成果物を作れることです。
セキュリティ・規制・サプライチェーンのリスクが高いシステムは、ここに成果物のハッシュとビルド来歴を加えます。SLSAは、ソフトウェアが改ざんされていないこと、どのソースから生成されたかを追跡するビルドトラックと来歴検証の仕組みを提供します。[2] どの水準を選ぶにせよ、「ベンダーの開発者のノートPCでビルドできた」という説明は引き取りの証跡ではありません。引き取る側が自らの環境で作り直す必要があります。
アカウントはパスワード一覧ではなく統制権として引き取る
引き取り文書にパスワードを平文でまとめておくのは良い引き継ぎではありません。まずアカウントと権限の目録を作り、組織名義のアカウントと個人アカウントを分ける必要があります。機密情報は承認された機密管理ツールや安全な手段で移し、ベンダーが知っていた鍵とパスワードは引き取り完了後に交換または失効させます。
OWASPは、機密情報を生成・交換・失効・満了というライフサイクルで管理し、もう必要ない、あるいは露出の可能性がある機密情報は失効させるよう勧めます。[3] 利用の記録と管理操作も監査できる必要があります。
とくに次のアカウントが抜けやすいところです。ドメインのレジストラとDNS、クラウド・ホスティング・データベース、CI/CDとパッケージレジストリ、メール・SMS・決済・地図などの外部API、アプリストアとモバイル署名、監視・ログ・セキュリティの道具、バックアップ保管庫と暗号鍵、SaaSの請求・支援アカウントです。各アカウントには所有者、管理者、支払い主体、復旧メール、多要素認証、更新日、ベンダーの接近終了日が要ります。
バックアップのファイルより復旧の結果を受け取る
バックアップの一覧や「直近のバックアップ成功」の画面だけでは復旧可能性は分かりません。引き取りの時点で必要なのは、実際の復旧試験の結果です。
少なくとも七つを確認します。どの時点のデータを復旧したか、どの環境へ復旧したか、復旧にどれだけかかったか、アプリケーションが復旧データで正常に起動したか、利用者・権限・添付・外部保管まで含まれたか、復旧後のデータ整合を何で確認したか、復旧に必要な暗号鍵とアカウントは誰が所有するかです。
運用引き取りで復旧試験を求めるのは、別の復旧アーキテクチャを設計するためではありません。すでに納品対象に含まれるバックアップが、引き取る組織の権限と手順で実際に動くかを確かめるためです。英国政府のサービス準備性レビューも、実行可能で試験済みの緊急・継続・復帰の計画を確認対象に置きます。[7]
依存関係の一覧はビルドファイルだけでは終わらない
package.jsonやpom.xml、requirements.txtのようなファイルは出発点です。実際の引き取りにはさらに八つの情報が要ります。正確な構成要素とバージョン、直接・間接の依存関係、私設パッケージと権限、構成要素のハッシュ、適用ライセンス、サポート終了または廃止の状態、運用に必要な外部SaaSとAPI、依存の置換・更新の責任者です。
多国共同のSBOM指針は、ソフトウェアを開発する組織だけでなく、購入し運用する組織も対象に含めます。最小の要素には構成要素のバージョン、依存関係、ハッシュ、ライセンス、SBOM生成の道具とバージョンなどが入ります。[10]
SBOMがあればすべてのセキュリティリスクが消えるわけではありません。しかし、どの構成要素を運用しているか分からない状態よりは、脆弱性・サポート終了・ライセンスの影響を判断する出発点を与えます。
セキュリティ検収の目標は脆弱性ゼロの証明書ではない
セキュリティの成果物には、少なくとも試験対象のバージョン、範囲、方法、判定の物差し、実施日、指摘事項、再試験の結果が要ります。未解決の指摘には影響、緩和策、リスク受容者、責任者、処理期限を残します。
OWASP ASVSは、ウェブアプリケーションと実行環境の技術的なセキュリティ統制を検証し、調達要件を定義する土台として使えます。[11]NISTも、供給者が検証活動を行ったという主張だけでなく、検証結果や設定・実装の情報、未解決の脆弱性、補完措置を調達と引き取りの過程で確認するよう案内します。[4][12]
重要なのは「セキュリティ検査をした」という一行ではなく、五つの問いに答えられるかです。何を検査し何は検査しなかったか、どのバージョンと環境を検査したか、未解決の課題は何か、いま運用を止めるべき課題は何か、誰がいつ修正したか、あるいはリスクを受容したかです。
監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。
監視もアカウントと人までつながる必要がある
ダッシュボードのURLを受け取ったからといって監視を引き取ったことにはなりません。引き取る組織がログと指標に接近でき、通知が実際に対応する人へ届く必要があります。Google SREは、通知が利用者の問題を示し、緊急で、受け手が行動できるものであるべきだと強調します。[5] 呼び出しにつながるすべての通知は、行動可能でなければなりません。
そのため引き取りの過程で試験通知を一度発生させるとよいでしょう。通知が正しい経路に届くか、担当者がランブックを見つけられるか、必要な運用アカウントで接続できるかを確認します。通知は鳴ったが受け手がいない、あるいはベンダーのアカウントでしかダッシュボードが見えないなら、運用引き取りは終わっていません。
既知の問題を残すことと隠すことは違う
すべての既知の問題を直した後でなければ引き取れない、というわけではありません。影響が限定的で回避策があり、担当者と完了期限が定まった問題は条件付きで残せます。
ただし既知の問題には、少なくとも七つの情報が要ります。影響を受けるバージョンと機能、再現手順、利用者・データ・セキュリティ・運用への影響、暫定の回避策、修正の責任者、目標日、引き取り判定への影響です。
「今後改善予定」は処理計画ではありません。とくに中核業務の停止、権限の迂回、データの毀損、復旧の失敗につながりうる問題は、単なる残作業へ格下げしてはいけません。
瑕疵と保守の法的な意味より先に技術的な分類を合わせる
次の区分は法的な責任を決めるためのものではありません。障害や要求が来たとき、チケットがどの窓口へ行くべきかを決める技術・運用の分類です。実際の費用、責任、期間、法的な効果は契約と別途の法務検討に従います。
双方が同じ事象を違うように分類すると、対応が始まりません。ベンダーは追加開発と言い、発注側は既存の欠陥だと主張する間、運用の障害はそのまま残ります。したがって分類の物差し、必要な証跡、最初の判定者、意見の相違を調整する経路を引き取り前に決める必要があります。
発生する状況 | 技術・運用上の分類候補 | 引き取り前に決めること |
|---|---|---|
| 合意した受入条件と実際の動作が違う | 欠陥の候補 | 再現の証跡、深刻度、修正と再試験の手順 |
| 新しい機能や変わった業務規則を求める | 変更要求の候補 | 影響分析、承認、別途の日程・費用の算定手順 |
| 誤った運用データや設定のために障害が起きる | 運用・データ支援の候補 | 設定とデータの所有者、復旧の責任 |
| 外部APIやSaaSの障害または仕様変更 | 外部依存の障害 | 一次確認者、ベンダーへの照会、回避と代替の範囲 |
| ランタイムやライブラリのセキュリティ修正やサポート終了 | 保守・更新作業の候補 | 監視、更新の決定権者、回帰検証の責任 |
引き取り会議では実演より再実行が重要だ
実務では六段階の順序がよく合います。まず引き取り候補を固定します。ソースのタグ、成果物のバージョン、データベーススキーマ、配備環境、引き取りマトリクスのバージョンをまとめて束ねます。次にベンダーが先に証跡を提示します。機能の結果、ビルド・配備のログ、アカウント一覧、データ検証、復旧試験、セキュリティ報告と既知の問題を説明します。
第三に、引き取る側が同じ作業を再び行います。自組織のアカウントでリポジトリを取得し、ビルドし、非本番環境へ配備します。データの書き出しと取り込み、バックアップからの復旧、試験通知も標本として実行します。第四に、例外を別の台帳へ残します。欠けた項目ごとに影響、回避策、責任者、完了日、再検収の方法、現在の判定を記録します。第五に、アカウントの所有権を移します。引き取る組織の所有者と復旧手段を確認したうえで、ベンダーの接近を必要な範囲まで下げ、機密情報を交換または失効させます。第六に、機能検収と運用引き取りにそれぞれ署名します。機能は通ったが運用引き取りがHOLDなのか、どの項目が条件付きなのかを区別します。
実演はベンダーができるという事実を示します。引き取る側の再実行は、ベンダーがいなくても組織が運用を続けられるという事実を示します。二つは別の証跡です。
条件付き引き取りができる場合と止めるべき場合
条件付き引き取りは、未完了の項目があるという事実だけでは許されません。四つがすべて揃う必要があります。影響範囲が限定されていること、現在の運用を保つ回避策があること、修正の責任者と完了期限が定まっていること、未完了の項目が引き取る組織の独立した修正・配備・復旧の能力を奪わないことです。
一方、次の八つの状態は運用引き取りを止める理由になります。最終の本番ソースとリポジトリを統制できない、引き取る側が綺麗な環境でビルドできない、ベンダーのアカウントなしでは配備も本番環境への接近もできない、ドメインとDNS、クラウドの最上位管理者と復旧手段を引き取れていない、データを完全に書き出せるか分からない、バックアップはあるが復旧試験がない、重大なセキュリティ課題やコードに埋め込まれた機密情報の処理責任者がいない、運用通知を受ける人と障害対応の所有者がいない、です。
文書の数より重要なのは、引き取る組織がシステムの次の変更と次の障害を自ら担えるかです。
ソフトウェア引き取りの完了条件
ソフトウェアの引き取りは、機能一覧にチェックを入れきる行為ではありません。引き取る組織が次の問いに「はい」と答えられる必要があります。ベンダーが明日から参加しなくても、我々はこのソフトウェアの現在の状態を説明し、ソースを直し、作り直し、配備し、データを移し、復旧し、セキュリティの問題と障害に対応できるか、です。
この問いに答えるために必要なのは、より多くの文書ではなく、所有権と実行可能な手順、検証の証跡、明確な運用責任者です。機能検収と運用引き取りを分ければ、何が終わり、何がまだリスクとして残るかをようやく正確に判断できます。
