株式会社ラフティ | Time Craft Consulting
Chapter 6 本番リリース・運用
「終わらせる」ではなく「守り続ける」
多くのITプロジェクトは、
リリースをゴールだと勘違いした瞬間に壊れ始めます。
-
無事にリリースできた
-
期限に間に合った
-
大きな障害は出なかった
ここでプロジェクトが終わったと思った時点で、
運用フェーズの地獄は確定します。
この章では、
「なぜリリース後に崩壊するのか」
「どうすれば守り続けられるのか」
を、構造の話として整理します。
6-0. リリースでプロジェクトは終わらない
多くのITプロジェクトは、
本番リリースをゴールだと誤認した瞬間に壊れ始めます。
-
無事にリリースできた
-
期限に間に合った
-
大きな障害は出なかった
ここで「終わった」と判断したプロジェクトほど、
運用フェーズで必ず破綻します。
本番リリースとは、
-
実際の利用が始まり
-
想定外が表面化し
-
本当の判断が求められる
最も不確実性の高いフェーズへの突入です。
6-1. リリース直後に起きる「責任の空白」
リリース直後、運用が崩壊するプロジェクトには
必ず次の状態が発生します。
-
誰に連絡すればいいか分からない
-
これは障害なのか仕様なのか判断できない
-
判断が止まり、現場が疲弊する
これは偶然ではありません。
運用責任者・判断者を決めないままリリースした結果です。
最低限、リリース前に決めるべきなのは次の3点です。
-
運用責任者は誰か
-
判断者は誰か
-
判断できない場合のエスカレーション先
これが決まっていない運用は、
必ず現場に責任が押し付けられます。
6-2. 障害対応と改善要望を分ける
運用フェーズで最も多い失敗は、
すべてが「緊急対応」扱いになることです。
-
本当の障害
-
仕様漏れ
-
改善要望
これらが同じ窓口・同じ優先度で扱われると、
運用は一気に破綻します。
正しい運用では、必ず次を分けます。
-
障害対応：止めなければならないもの
-
改善要望／仕様変更：止めなくてもよいもの
この切り分けは、
現場ではなく判断者の責任です。
6-3. バグ修正と仕様変更のリリースルール
運用を安定させるために、
リリースの出し方は必ず定義しておく必要があります。
バグ修正と仕様変更は同列ではありません
-
バグ修正：想定通りに動かない不具合
-
仕様変更／仕様漏れ：合意不足・設計不足の結果
これを同じリリースで扱うと、
-
何が直ったのか分からない
-
利用者が混乱する
-
信頼が下がる
という結果になります。
サイレントリリースの条件を決める
サイレントリリースは禁止ではありません。
ただし、条件を明確にします。
-
利用者の操作・挙動が変わらない
-
影響範囲が限定的
-
判断者が明確
※ 「誰がOKを出すか」を必ず定義すること。
定期リリースを基本とする
-
仕様変更・改善要望は定期リリースに集約
-
いつ出るか分からない運用を禁止
これだけで、
現場・利用者・経営者のストレスは激減します。
6-4. 運用を属人化させない設計
運用が長期化すると、
次の状態に陥りやすくなります。
-
あの人しか分からない
-
その人がいないと止まる
-
休めない
これは努力不足ではありません。
運用設計の失敗です。
属人化を防ぐために必要なのは、
-
判断基準の明文化
-
最低限の手順共有
-
情報の集約場所を一つにすること
完璧なドキュメントは不要です。
次に何をすればいいか分かることが重要です。
6-5. 運用ルールがないプロジェクトは必ず腐る
「柔軟に対応しよう」
この言葉が出た運用は、
ほぼ確実に腐ります。
運用に必要なのは、
柔軟さではなく最低限のルールです。
-
どこまでが契約内か
-
どこからが追加対応か
-
判断を止める基準は何か
これを決めずに運用を始めると、
-
善意が搾取され
-
現場が疲弊し
-
信頼関係が壊れます。
6-6. 契約と運用の境界線
多くの運用トラブルは、
契約と運用の境界が曖昧なことから起きます。
-
どこまでが保守か
-
どこからが開発か
-
無償対応の範囲はどこまでか
契約は、
相手を縛るためのものではありません。
関係を壊さないための道具です。
運用フェーズこそ、
契約と現実のズレを意識する必要があります。
6-7. 本番リリース・運用フェーズのまとめ
本番リリース・運用で最も大切なのは、
終わらせることではなく、守り続けること
-
責任を決める
-
判断を止めない
-
現場に押し付けない
これができたプロジェクトは、
時間が経つほど安定します。