第22話｜リリースできますか？｜東央ソリューションズ―― 実務統合型PM論・連載小説

午前十時。

東和物流本社会議室。

大型モニターには一枚の資料が映し出されていた。

『リリース判定会議』

会議開始十分前。

東央ソリューションズの控室。

高梨はノートPCを開き、最後の資料確認をしていた。

不具合一覧。

品質サマリー。

リスク一覧。

運用回避策。

何度も見返した資料だった。

それでも、もう一度確認する。

ドアが静かに開いた。

黒田だった。

「確認は終わったか。」

「はい。」

高梨はPCを閉じた。

黒田は壁にもたれながら、高梨の表情を見つめる。

「……まだ迷ってる顔だな。」

高梨は少しだけ苦笑した。

「分かりますか。」

「当たり前だ。」

黒田も笑わない。

静かな空気が流れる。

「高梨。」

「お前は、Goだと思うのか。」

その問いに、高梨は少しだけ考えた。

「はい。」

「課題は残っています。」

「本番でしか確認できない作業もあります。」

「それでも。」

「残っているリスクは把握しています。」

「対策も準備しました。」

「現時点でできることは、やりました。」

黒田は一度だけ頷いた。

「なら、それで行こう。」

高梨は顔を上げる。

黒田は静かに続けた。

「今日の判定は、お前一人の判断じゃない。」

「開発も。」

「品質も。」

「営業も。」

「会社としてGoを出す。」

「責任は組織で負う。」

高梨は何も言えなかった。

黒田はドアノブに手を掛ける。

「PMは最後に決める役目じゃない。」

「決められる状態まで、みんなを連れてくる役目だ。」

少しだけ振り返る。

「ここまで、よくやった。」

そう言って部屋を出ていった。

高梨は静かに息を吸う。

そして、その後を追った。

東和物流本社会議室。

田辺が出席者を見渡した。

「それでは、本日のアジェンダはリリース判定です。」

「東央ソリューションズより、品質状況をご報告ください。」

高梨は静かに立ち上がった。

「ご説明します。」

画面が切り替わる。

最初に映し出されたのは、不具合サマリーだった。

重大　0件

高　3件

中　12件

低　31件

「重大不具合はすべてクローズしています。」

「高優先度不具合は三件残っていますが、いずれも業務影響は限定的であり、運用回避策および恒久対応計画を整理済みです。」

神谷は腕を組みながら資料を見る。

白石は静かにメモを取り続けている。

黒田は高梨の説明を黙って聞いていた。

続いて、リリース判定チェック結果が表示された。

・重大不具合　解消済み

・業務シナリオテスト　完了

・外部結合テスト（IT2）　完了

・運用手順書　整備済み

・監視設計　完了

・障害連絡体制　確認済み

・ロールバック手順　レビュー完了

高梨は、一項目ずつ説明していく。

会議室にはキーボードを打つ音だけが響いていた。

説明が終わると、田辺が資料を閉じた。

「品質面については理解しました。」

「一点だけ確認させてください。」

「本番移行についてです。」

会議室の空気が少しだけ張りつめる。

「移行計画書は確認しました。」

「ただ、本番当日にしか実施できない作業がありますよね。」

高梨は頷いた。

「はい。」

「DNS切替、本番接続先への切替、ジョブスケジューラの有効化などがあります。」

「これらは事前リハーサルができないため、当日はタイムチャートに沿ってダブルチェック体制で実施します。」

黒田が補足する。

「手順書はレビュー済みです。」

「担当者もすべて割り当てています。」

「想定されるリスクについても、対応手順を整理しています。」

田辺はゆっくり頷いた。

「承知しました。」

数秒の沈黙。

そして、田辺が口を開いた。

「東和物流としては、リリース可と判断します。」

白石が続く。

「DX推進室も異論ありません。」

神谷も頷いた。

「営業としても問題ありません。」

最後に黒田が静かに言った。

「開発としても異論ありません。」

「残課題はあります。」

「ですが、それを管理する準備は整っています。」

「東央ソリューションズとして、リリース可能と判断します。」

高梨は何も付け加えなかった。

PMとして説明すべきことは、すべて説明した。

その判断を会社として引き受けるのは、管理職の役割だった。

会議は終了した。

夕方。

東央ソリューションズ。

大会議室は、本番移行準備室へと姿を変えていた。

壁にはタイムチャート。

切替手順。

緊急連絡網。

担当一覧。

監視項目。

高梨は一枚ずつ確認していく。

「監視班、待機確認。」

「インフラ班、切替手順確認済み。」

「開発班、初期確認担当配置済み。」

チェック欄が埋まっていく。

最後に残った一枚。

『本番移行タイムチャート』

23時30分　バックアップ開始

0時00分　システム停止

0時20分　データ移行

1時10分　本番設定変更

1時40分　ジョブ有効化

2時00分　業務確認開始

高梨は、その表を静かに見つめていた。

レビューは終えた。

手順も確認した。

担当者も決めた。

抜け漏れはない。

そう信じている。

それでも。

本番環境だけは、やり直しが利かない。

高梨は資料を閉じると、部屋の時計に目を向けた。

リリース開始まで、あと十三時間。

準備は整った。

あとは、予定どおり進むことを願うしかなかった。

ケーススタディ

第22話では、ついにリリース判定の日を迎えました。

重大不具合はすべて解消。

一方で、高優先度の不具合はまだ残っています。

本番環境でしか実施できない切替作業も控えています。

つまり、

「不安要素がゼロではない状態」

で、プロジェクトは最終判断を迎えました。

現実のシステム開発でも、

「すべての課題が解決してからリリースする」

というケースはほとんどありません。

重要なのは、

残っているリスクを正しく理解し、管理できる状態になっているかどうかです。

それでは、このケースからPMは何を学ぶべきでしょうか。

ケーススタディ

Q1

リリース判定では、なぜ「重大不具合が0件」という情報だけでGo判断してはいけないのでしょうか。

A1｜解答例

リリース判定は、「品質判定」ではなくリスク判定だからです。

重大不具合がなくても、

• 高優先度の不具合が業務へ大きな影響を与える可能性がある

• 運用体制が整っていない

• 障害発生時の対応手順が決まっていない

といった状況であれば、安全にリリースできるとは言えません。

逆に、

不具合が残っていても、

• 業務への影響範囲を把握している

• 回避策が準備されている

• 恒久対応の計画が立てられている

• 利害関係者がそのリスクを理解し、合意している

のであれば、リリースを判断できる場合があります。

PMに求められるのは、

「不具合をゼロにすること」ではなく、「リスクを説明し、管理できる状態をつくること」です。

Q2

Go／NoGo判定では、どのような項目を確認すべきでしょうか。

A2｜解答例

リリース判定では、不具合件数だけではなく、さまざまな観点から総合的に評価する必要があります。

例えば、次のようなチェックポイントです。

• 重大不具合は解消されているか

• 高優先度不具合の回避策は整理されているか

• 外部結合テスト（IT2）は完了しているか

• 業務シナリオテストは完了しているか

• ロールバック手順はレビューされているか

• バックアップ取得手順は確認されているか

• 監視設定は完了しているか

• 障害発生時の連絡体制は整備されているか

• 本番移行タイムチャートはレビューされているか

• 関係者がリスクを理解し、合意しているか

重要なのは、

「品質が良いか」ではなく、「安心してリリースできる準備が整っているか」という視点です。

Q3

十分な準備を行っても、本番障害はなぜ発生してしまうのでしょうか。

A3｜解答例

どれだけ準備を重ねても、

本番環境には、

本番でしか確認できない要素

が存在するためです。

例えば、

• 本番環境固有の設定

• 切替作業

• 実データによる処理

• 利用者数やアクセス負荷

• 他システムとのリアルタイム連携

などは、事前に100％再現できるとは限りません。

だからこそPMは、

「障害をゼロにすること」

だけを目指すのではなく、

障害が発生した場合でも、

• すぐに検知できるか

• すぐに連絡できるか

• すぐに原因調査へ着手できるか

• 必要であれば切り戻せるか

というインシデント対応能力まで準備しておく必要があります。

リリースとは、

「問題が起きないこと」を保証するイベントではありません。

問題が起きても対応できる状態で、本番を迎えることなのです。

このケースで本当に学んでほしかったこと

プロジェクトでは、

「不具合をゼロにしてからリリースしたい。」

そう考えることは自然です。

しかし、現実の大規模プロジェクトでは、

限られた期間や予算の中で、すべての課題を解決しきれないことも少なくありません。

そのような状況でPMに求められるのは、

完璧を目指すことではなく、

残っているリスクを正しく把握し、そのリスクを関係者へ説明したうえで、組織として意思決定できる状態をつくることです。

Go判定とは、

「もう問題はありません。」

という宣言ではありません。

「残るリスクを理解し、それでも前へ進む」という組織としての意思決定です。

そして、その判断が正しかったかどうかは、

リリース当日に障害が発生したかどうかだけでは決まりません。

必要な情報を集め、リスクを評価し、対策を準備したうえで判断したのであれば、その意思決定自体には十分な価値があります。

PMの役割とは、

未来を当てることではありません。

限られた情報の中で、組織として最善の判断ができる状態をつくること。

それこそが、リリース判定におけるPMの最も重要な役割なのです。