リリース計画って、ベンダーに任せておけばいいんじゃないの？
こんな声、現場でもよく聞きます。実際、リリース作業そのものは開発ベンダーや保守ベンダーが実行するので、そう思うのも無理はありません。
でも、こんな場面を想像してみてください。
リリース当日。予定通りリリースは完了した。
しかし翌朝、初回稼働が始まった瞬間に障害が発覚。
「どうする？」「誰に連絡する？」「業務は止める？続ける？」
対応方針が何も決まっていない。復旧の目処も立たない・・・。
リリースは、システムを本番環境に出すイベントです。成功すれば何事もなく過ぎていきますが、失敗すると業務に直接影響が出ます。最悪の場合、業務が止まります。
つまり、リリースは非常に業務リスクの大きいイベントです。
だからこそ、計画を引き、慎重に進める必要があります。そして、その計画の中にはベンダーに任せられる部分と、発注者側で考えなければならない部分があります。
この記事では、リリース計画で「何を・誰が・どう考えるべきか」を解説します。
この記事でわかること
- リリース計画がなぜ重要なのか
- リリース計画で考えるべき3つのこと
- コンティンジェンシープランの考え方と具体例
- リリースまでの流れ（計画→判定→実行）
なぜリリース計画が重要なのか
リリース計画が重要な理由はシンプルです。
リリースに失敗すると、業務に影響が出るからです。具体的には、次のような影響が考えられます。
- データが正しく移行されず、業務データに不整合が生じる
- 処理性能が劣化し、業務が滞る
- 外部システムとの連携が止まる
いずれも、発生すれば業務の遅延や停止につながります。しかも、リリースは本番環境での作業です。テスト環境と違って、影響範囲は実際の業務そのものです。
ベンダー任せでは守れない領域がある
「リリースはベンダーがやるのだから、計画もベンダーに任せればいい」
この考え方は、半分は正しいです。
リリース作業そのもの、たとえばデプロイ手順や切り戻し手順などは、ベンダーの方が詳しいです。ここはベンダーに任せて問題ありません。
一方で、業務への影響や、業務側の対応策については、ベンダーだけでは考えきれません。なぜなら、ベンダーはシステムのプロであって、発注者側の業務のプロではないからです。
たとえば、リリース後の初回稼働日に障害が発生した場合。
- 業務をどこまで止めるのか
- 手作業で代替できる業務はあるのか
- 顧客や取引先への連絡はどうするのか
こうした業務観点の対応策は、発注者側でなければ考えられません。
- リリース作業に関する計画 → ベンダーに任せてOK
- 業務影響に関する計画 → 発注者側が主導して考える
実際に、過去のプロジェクトでこんなことがありました。
ベンダーにコンティンジェンシープランを作成してもらったのですが、その内容はリリース作業中のトラブル対応に限定されていました。リリース後の初回稼働で障害が起こった場合の対応策が、まったく考えられていなかったのです。
幸い、そのプロジェクトでは障害は発生しませんでした。しかし、もし障害が起きていたら、コンティンジェンシープランがない状態で業務が停止し、復旧にかなりの時間がかかっていたと思います。
リリース計画は、ベンダーに「全部お願い」では済みません。業務を守るための計画は、発注者側が自ら考える必要があります。
リリース計画で考える3つのこと
リリース計画で考えることは、大きく3つあります。
1. リリーススケジュール
リリーススケジュールは、どのタイミングで何を実施するか、役割分担をどうするかを整理したものです。
ここは基本的にベンダーに任せます。実際にリリースを実行するのは、開発ベンダーや保守ベンダーなどのITベンダーだからです。
ベンダーに整理してもらう内容としては、次のようなものがあります。
- リリース日時（開始・完了予定）
- 作業手順とタイムライン
- 担当者と役割分担
- 作業環境の準備事項
発注者側としては、ベンダーが作成したスケジュールをレビューし、業務への影響（停止時間帯や利用者への周知タイミングなど）を確認することが役割になります。
2. コミュニケーションプラン
コミュニケーションプランは、リリース当日に「誰が・誰に・どうやって連絡するか」を可視化したものです。
リリースは順調に進めば問題ありませんが、トラブルが発生することもあります。そうした場合に迅速に対応できるよう、事前にコミュニケーションの流れを決めておきます。
具体的には、次のような項目を決めます。
- エスカレーションルート（誰が誰に報告するか）
- 連絡手段（電話・チャット・メールなど）
- 連絡先一覧（関係者の連絡先をまとめておく）
- 報告タイミング（作業開始時・完了時・障害発生時など）
特に重要なのは、トラブル発生時のエスカレーションルートです。
たとえば、リリース当日にシステム障害が発生した場合のエスカレーションは、次のような流れになります。
エスカレーションルートの例
ベンダー担当者（検知・一次対応）
↓ 障害発生を検知、即時報告
発注者側 PM（状況把握・方針判断）
↓ 業務への影響を確認、対応方針を決定
プロジェクトオーナー / 責任者（最終判断）
↓ 切り戻しの承認、利用者・関係部門への連絡指示
関係部門・利用者（影響通知）
「何かあったら連絡します」ではなく、「誰が・誰に・何分以内に・どの手段で連絡するか」まで決めておくことで、いざというときに迷わず動けます。
連絡手段も事前に決めておくことが重要です。普段使いのチャットツールは、リリース作業中にベンダーがスレッドに流してしまうと情報が埋もれることがあります。リリース専用のチャンネルや連絡ルートを事前に設定しておくのがよいでしょう。
3. コンティンジェンシープラン
コンティンジェンシープランは、リリース失敗時やトラブル発生時にどのような対応を取るかを、あらかじめ決めておく計画です。
ここがリリース計画で最も重要です。
リリーススケジュールやコミュニケーションプランとは違って、コンティンジェンシープランは「うまくいかなかった場合」の計画です。
リリースがうまくいけば、コンティンジェンシープランの出番はありません。しかし、うまくいかなかったとき、このプランがあるかないかで、復旧までの時間が大きく変わります。
コンティンジェンシープランの詳しい考え方は、次の章で解説します。
コンティンジェンシープランの考え方
コンティンジェンシープランを考えるには、次の流れで進めます。
1. 失敗パターンを洗い出す
まずは、「何が起こりうるか」を洗い出します。
リリースで起こりうる失敗パターンには、たとえば次のようなものがあります。
| 失敗パターン | 具体例 |
|---|---|
| データ移行の失敗 | データが正しく移行されない、一部データが欠損する |
| 性能の劣化 | リリース後に処理が重くなり、応答が遅い・データ登録に時間がかかる |
| 外部連携の不具合 | 連携先システムとのデータ送受信が止まる |
| 機能の不具合 | リリースした機能が想定通り動作しない |
この洗い出しは、ベンダーと一緒に行うのが効果的です。ベンダーはシステム構成やリリース手順を理解しているので、技術的な観点から起こりうるリスクを挙げてもらえます。
2. システム観点の対策を考える
失敗パターンが洗い出せたら、それぞれに対するシステム観点の対策を考えます。
対策は、影響度によって大きく2つのレベルに分けて考えます。
- 軽微な場合：その場で調査・対応する（設定変更など）
- 重度の場合：切り戻しを実施する（リリース前の状態に戻す）
たとえば、性能劣化が発生した場合を考えてみます。
- 一部の画面で応答が遅い程度（軽微） → 原因を調査し、SQLチューニングや設定変更で対応
- 全体的に処理が重く、業務に支障が出るレベル（重度） → 切り戻しを実施
この軽微/重度の判断基準も、事前に決めておくことが重要です。当日になって「これは切り戻すべきか？」と迷っている時間が、復旧を遅らせます。
ここはベンダーが主導して考える領域です。切り戻し手順や判断基準について、ベンダーに整理してもらいましょう。
3. 業務観点の対策を考える
システム観点の対策と並行して、業務観点の対策も考えます。
ここが、発注者側が主導して考える領域です。
たとえば、次のような観点で検討します。
| 観点 | 検討内容 |
|---|---|
| 業務の継続可否 | 障害が起きた場合、業務を止めるのか、続けるのか |
| 運用回避策 | システムが使えない間、手作業で代替できる業務はあるか |
| 利用者への周知 | 利用者や顧客にどのタイミングで何を伝えるか |
| 対応体制 | 業務側で誰が判断し、誰が対応にあたるか |
失敗時の影響が大きい場合は、運用回避策まで具体的に考えておくことが重要です。
たとえば、「データ登録ができない場合は、Excelで手動記録し、復旧後に一括登録する」といった代替手段です。
システムの復旧はベンダーに任せられますが、復旧までの間に業務をどう回すかは、発注者側でしか決められません。IT部門だけでなく企画部門など現場に近い人と一緒に決めましょう。
4. 初回稼働日の監視・対応まで考える
コンティンジェンシープランで見落としがちなのが、リリース後の初回稼働日です。
リリース作業が成功しても、実際に利用者が使い始めてから問題が発覚するケースは少なくありません。
- 実データでの処理で初めて性能問題が顕在化する
- 特定の業務パターンでのみ発生する不具合
- データ移行の不整合が業務を進める中で発覚する
初回稼働日に関して、次の点を事前に決めておきましょう。
- 監視体制：誰がどの指標を見るか（エラーログ、処理時間、問い合わせ件数など）
- 検知方法：異常をどうやって検知するか（アラート、利用者からの報告など）
- 対応方針：異常を検知した場合、誰がどう動くか
リリース当日だけでなく、初回稼働日まで含めてコンティンジェンシープランを作ること。これがリリース計画の品質を大きく左右します。
リリースまでの流れ
リリースまでの流れは、大きく3段階あります。
1. 計画作成
最初のステップは、ここまで解説してきたリリース計画の作成です。
リリーススケジュール、コミュニケーションプラン、コンティンジェンシープランの3つを整理します。
2. リリース判定
計画ができたら、次はリリース判定です。
リリース判定とは、プロジェクトオーナーや責任者に対して、リリースの承認を得る場です。
この場では、リリース計画だけでなく、リリースまでに実施した内容も報告します。特に重要なのはテスト結果です。品質に問題がないことを示し、「リリースしても問題ない」という承認を得ます。
リリース判定で報告する主な内容
- テスト結果（品質に問題がないこと）
- リリース計画（スケジュール・コミュニケーション・コンティンジェンシー）
- 残存リスクとその対策
リリース判定は「責任の移譲」でもある
リリース判定には、もう一つ重要な意味があります。それは、責任の移譲です。
リリース判定を経ることで、「この計画と品質でリリースする」という意思決定の責任が、プロジェクトオーナーや責任者に移ります。
逆に言えば、リリース判定を受けずにリリースを実行した場合、その意思決定の責任は現場のプロジェクトメンバーに残ります。
リリースが成功すれば問題は表面化しません。しかし、もし失敗した場合、「誰がリリースを承認したのか」が問われます。判定プロセスを経ていなければ、事実上「プロジェクトメンバーが独断でリリースした」ことになってしまいます。
実際に、過去のプロジェクトでリリース判定を受けずにリリースが行われたケースがありました。責任者も現場の人も、いつリリースが行われるのかを知らないままリリースが実施されていたのです。
幸い、そのときは問題が起きませんでした。しかし、もし障害が発生していたら、責任の所在が不明確なまま対応に追われることになり、大きな事故につながっていたと思います。
リリース判定は、品質確認の場であると同時に、責任を適切に移譲するためのプロセスです。 省略してはいけません。
3. リリース実行
リリース判定で承認を得られたら、リリースを実行します。
リリース当日は、コミュニケーションプランに従って関係者に状況を共有しながら進めます。トラブルが発生した場合は、コンティンジェンシープランに従って対応します。
まとめ
この記事では、リリース計画の考え方と進め方を解説してきました。
リリース計画で考えることは、次の3つです。
- リリーススケジュール — いつ・誰が・何をするか
- コミュニケーションプラン — 誰が・誰に・どう連絡するか
- コンティンジェンシープラン — 失敗したらどう対応するか
そして、この3つの中で最も重要なのは、コンティンジェンシープランです。
コンティンジェンシープランは、システム観点と業務観点の両面で考える必要があります。
- リリース作業に関する計画 → ベンダーに任せてOK
- 業務影響に関する計画 → 発注者側が主導して考える
リリースは業務リスクの大きいイベントです。だからこそ、「ベンダーに任せればいい」で済ませず、発注者側として考えるべきことをしっかり考え、計画を引いてから臨みましょう。
おまけ：NGパターン
NG① コンティンジェンシープランがない
リリース計画にコンティンジェンシープランが含まれていないケースです。
- リリース作業の手順は決まっている
- しかし、失敗した場合の対応策が決まっていない
この状態でリリースに臨むと、トラブル発生時にその場で対応策を考えることになります。
リリース失敗時は、最悪の場合、業務が止まるため迅速な復旧が必要です。事前プランがないと対応が後手になり、復旧までに時間がかかります。
特に見落としがちなのが、リリース後の初回稼働日です。リリース作業自体が成功しても、翌営業日に問題が発覚するケースは少なくありません。リリース当日だけでなく、初回稼働日までカバーしたコンティンジェンシープランを作りましょう。
NG② リリース判定を受けない
リリース判定を受けずにリリースが実行されるケースです。
- リリースが成功すれば表面化しない
- しかし失敗した場合、責任の所在が不明確になる
リリース判定を経ずにリリースを実行すると、事実上「プロジェクトメンバーが独断でリリースした」という形になります。
成功すれば問題化しませんが、失敗した場合、責任が現場メンバーに集中するリスクがあります。
判定プロセスを通して、プロジェクトオーナーや責任者に意思決定の責任を適切に移譲すること。これもリリース計画の重要な要素です。
関連記事