先に要点
受託開発やWebシステムの本番切り替えで、よく出るのが 当日は誰が立ち会えばよいですか という話です。
ここが曖昧なまま進むと、技術的には切り替えられても、承認が出せない、業務確認ができない、障害時に誰へ電話すべきか分からない、といった形で止まりやすくなります。
この記事では、本番作業の立ち会いは誰が必要なのかを、受託案件の実務に寄せて整理します。
本番切り替え全体の流れから見たい場合は、カットオーバーとは？本番切り替え・移行日・確認手順の基本を整理 が前提になります。
切り替え当日に一時停止をどう扱うかは、メンテナンス画面はなぜ必要？切り替え作業での使いどころと出し方の基本 もつながりやすいです。
この記事は 2026年4月22日時点で、IPA のモデル取引・契約書関連資料と AWS Prescriptive Guidance の roles and responsibilities / cutover 関連資料を確認しながら整理しています。ここでは法的助言ではなく、受託案件で本番作業を揉めにくく進めるための実務整理としてまとめます。
結論: 立ち会いに必要なのは「承認」「技術確認」「連絡」の3役
本番作業に全員集合する必要はありません。
ただし、次の3つは必ずどこかに置いた方が安全です。
- GO / STOP を判断する人
- 技術的に切り替えと復旧を実行できる人
- 関係者への連絡を一本化する人
この3つが分かれていないと、作業は終わったが公開してよいのか分からない 障害時に誰も決められない クライアントへ連絡する窓口が複数あって混線する という事故が起きます。
クライアント側で最低限ほしい立場
クライアント側は、単に見守る人ではなく、業務影響を判断する役割を持ちます。
1. 業務責任者
一番大事なのは、この状態で公開してよいか を業務目線で判断できる人です。
たとえば次のような確認は、ベンダーだけでは決めにくいです。
- 問い合わせが止まっていてよい時間帯か
- 受注停止を延長してよいか
- 店舗、営業、サポートへ連絡済みか
- 画面表示より業務運用を優先すべきか
小規模案件なら、社長や担当者本人が兼ねることもありますが、最終判断者が誰か は事前に固定した方が安全です。
2. 業務確認担当
本番環境で最低限の受け入れ確認をする人です。
検収 の本番版に近く、技術詳細までは見なくても、次のような確認ができる人が必要です。
- ログインできる
- フォーム送信できる
- 受注や予約が入る
- 通知メールが届く
- 管理画面で確認できる
ここを曖昧にして クライアント誰か見ておいてください にすると、結局誰も確認していないことがあります。
3. 連絡窓口
クライアント側にも窓口は必要です。
担当者が複数いる案件で、営業、情シス、現場責任者へベンダーが直接ばらばらに連絡すると、判断が割れやすくなります。
ベンダー側で最低限ほしい立場
受託側は、手を動かす人だけでなく、進行と判断を持つ人を分けておくと安定します。
1. 実作業責任者
サーバー切り替え、アプリ反映、DNS 変更、データベース 更新、確認手順の進行を理解している人です。
実際に手を動かす担当と同一でも構いませんが、少なくとも runbook の全体を説明できる必要があります。
2. 技術確認担当
実作業責任者と兼任でもよいですが、理想は別目です。
本番作業中は、作業した本人ほど 通っているはず というバイアスがかかります。
そのため、ログ、疎通、主要画面、メール、外部連携をチェックする役を分けると事故に気づきやすくなります。
3. 切り戻し判断に必要な担当
誰が切り戻しを実行するか だけでなく、誰が切り戻し案を出し、誰が承認し、どこまで戻すか を決めておく必要があります。
このあたりは、ロールバックとは？切り戻しとの違いと実務での使い分けを整理 と対で考えると分かりやすいです。
実務では「立ち会い必須」より「連絡体制必須」
現地に集まるか、オンライン待機かは案件次第です。
重要なのは、物理的に同じ場所にいることより、連絡が止まらないことです。
最低限、次のような形は用意した方が安全です。
- 当日専用の連絡手段
- 主要メンバーの電話番号
- 作業開始、切替完了、確認完了、切り戻し開始の連絡先
- 連絡の順番
- 夜間作業時の不在時代替
AWS Prescriptive Guidance でも、移行時は役割分担を明確にし、RACI 的に責任をはっきりさせることが勧められています。
受託案件でも考え方は同じで、誰がやるか と 誰が最終責任を持つか を分けておくと混乱が減ります。
よくある役割分担の形
小規模案件で使いやすい形にすると、だいたい次のようになります。
| 役割 | 主な担当 | 当日の役目 |
|---|---|---|
| クライアント業務責任者 | 発注側 | 公開可否、停止延長、業務影響判断 |
| クライアント確認担当 | 発注側 | 主要業務の動作確認 |
| ベンダー実作業責任者 | 受託側 | runbook 進行、作業実行、状況報告 |
| ベンダー技術確認担当 | 受託側 | 疎通、ログ、外部連携、解除前確認 |
| 外部事業者窓口 | ホスティング / DNS / SaaS | 障害時エスカレーション |
立ち会い不要にしやすいケース
逆に、毎回クライアント同席が必要とは限りません。
- 閲覧中心の小規模サイト
- 書き込みや決済がない
- 事前確認環境で十分に検証済み
- 当日確認項目が短い
- 作業失敗時の影響が限定的
このような案件では、クライアントは待機のみ、または作業後報告だけでも回ることがあります。
ただし、その場合でも GO を出す条件 と 報告タイミング は決めておくべきです。
立ち会いが重くなりやすいケース
次のような案件は、立ち会いを軽く見ない方が安全です。
- 会員、受注、決済、予約がある
- 外部連携が多い
- 旧環境と新環境が短時間混在する
- データベース 変更を伴う
- 夜間作業で切り戻しの可能性がある
この場合は、誰か一人いればよい ではなく、業務判断者と技術判断者を分ける前提で考えた方がよいです。
事前に決めておくべきこと
本番作業前に、受託案件では少なくとも次をそろえておくとかなり安定します。
- 作業責任者
- クライアント側の最終承認者
- 主要確認項目と担当者
- 連絡手段と連絡順
- 作業中止条件
- 切り戻し条件
- 作業後報告の期限と形式
この整理は、実務上は要件定義や提案書の時点から少しずつ置いておくのが理想です。
その意味では、要件定義で最低限決めることは？受託開発であとから揉めやすい項目を整理 や 提案書の前提条件とは？受託開発であとから揉めない書き方 とかなりつながっています。
よくある失敗
クライアント担当者が「見るだけ」になっている
本人は立ち会っていても、何を判断するか決まっていない状態です。
この場合、何か起きたときに 社内確認します で止まりやすくなります。
ベンダー側が営業窓口だけで本番に入る
営業担当が悪いわけではありませんが、技術判断と切り戻し判断を即答しにくいことがあります。
本番作業には、少なくとも実作業責任者か技術責任者を入れた方が安全です。
外部サービスの問い合わせ先が整理されていない
DNS、メール、決済、CDN、ホスティングが絡むのに、契約主体や問い合わせ窓口が整理されていないと、障害時に時間を失います。
まとめ
本番作業の立ち会いで大事なのは、全員参加ではありません。
承認する人 技術的に切り替える人 連絡をまとめる人 を事前に決めておくことです。
受託案件では、とくにクライアント側の業務責任者と、ベンダー側の実作業責任者を明確にしておくと、公開可否、停止延長、切り戻し判断がかなりスムーズになります。
現地立ち会いかオンライン待機かより、役割分担と連絡体制の設計を優先した方が事故は減ります。
参考リンク
- IPA: 情報システム・モデル取引・契約書（第二版追補版）
- IPA: システム開発の健全化に向けて
- AWS Prescriptive Guidance: Understanding roles and responsibilities
- AWS Prescriptive Guidance: Workstreams in a large migration