このユニットの結論
本番稼働しても、初期の安定化を終えても、システムは「完成」しません。業務や制度が変わり、使っているソフトウェアも古くなるからです。
稼働後の改善・変更の受付・保守・更新を、誰が、どの予算と手続きで続けるかを、プロジェクトを閉じる前に決めて引き継ぐことで、システムを使い続けられる状態に保ちます。
1. 何の話か
大きなプロジェクトが本番稼働を迎え、稼働直後の集中対応も終わりました。プロジェクトの体制は縮小され、多くのメンバーが別の仕事に移っていきます。
ところが、利用部門からは「この画面をこう変えてほしい」「来年の制度の変更に合わせてほしい」という声が、稼働後も届き続けます。その声を、誰が受け止めるのでしょうか。
このユニットは、STAGE 14 の最後として、稼働した後もシステムを育て続けることを考えます。
2. なぜ必要か
稼働後の体制と手続きを決めないと、
- 変更の要望を受ける窓口がなく、要望が個人のメールや口頭で散らばる
- 声の大きい部署の要望から順に対応し、本当に大事な変更が後回しになる
- ソフトウェアの更新やセキュリティの修正が放置され、古いまま使い続ける
- プロジェクトで得た知識が、メンバーの異動とともに失われる
ということが起きます。やがて「またシステムが古くなった」と、次の大きな刷新が必要になります。
3. このユニットで分かること
- 稼働後に続く4つの仕事（改善・変更の受付・保守・更新）
- 変更の要望を受け付けて決める流れ
- プロジェクトから運用へ引き継ぐもの
4. 稼働後に続く4つの仕事
| 仕事 | 何をするか | きっかけの例（教材上の例） |
|---|---|---|
| 改善 | 使いにくさや手間を減らす | 同じ種類の問い合わせが続く |
| 変更の受付 | 業務や制度の変化に合わせた要望を受け、対応を決める | 組織の変更、新しい商品や取引の追加、法令や制度の変更 |
| 保守 | 不具合を直し、今の動きを保つ | 稼働後に見つかった不具合 |
| 更新 | 使っているソフトウェアや基盤を新しくする | ソフトウェアの提供元の支援の終了、セキュリティの修正 |
どれも、プロジェクトのように「始まりと終わり」がある仕事ではなく、ずっと続く仕事です。
5. 変更の要望を受け付けて決める流れ
稼働後の変更も、プロジェクトの途中の変更（04-06）と同じように、手続きに沿って決めます。一般的には次のような流れです。
- 受け付ける：窓口を1つにし、要望を記録する（REQ-005 変更要求書）
- 分ける：不具合の修正か、改善の要望か、業務や制度の変化への対応か
- 影響を見る：どのシステム・どの連携・どの業務に関わるか。費用と時間
- 決める：優先順位を付け、誰が承認するかを決めておく
- 実施して確かめる：テストし、本番に出し、効果を確かめる
- 記録する：変更の経過を台帳に残す（PRG-008 変更管理台帳）
変更は、決められた手順（必要なら計画停止を含む）に沿って本番に出します。出したあとは、日々の運用の手順（OPS-003 運用手順書）も変更に合わせて直します。
6. プロジェクトから運用へ引き継ぐもの
プロジェクトを閉じる前に、次を運用の担当へ引き継ぎます。
- 残っている課題と要望：今回の対象から外した要望（01-05）や、稼働後に後回しにした不具合
- 設計の理由：なぜこの作りにしたのかの記録
- 手順と体制：運用の手順書、保守を担う会社と窓口
- 効果の確かめ：投資の目的どおりの効果が出ているかを、稼働後に測る指標（BUS-004 効果測定指標一覧）
引継ぎの計画は、稼働直後の支援と合わせて作ります（OPS-009 稼働直後支援・運用引継ぎ計画）。
CASE FACTFROZEN正本に記載されたアステリア案件の事実
アステリア案件に関係する記載
- M18 本番稼働
- M21 初期安定化完了
- マルチベンダー（Vendor A〜D）
- P-011 山下 恵 — 本番移行・運用リーダー
- 成果物に OPS-009 稼働直後支援・運用引継ぎ計画がある
正本の時間軸は M21 の初期安定化完了までです。M21 より後のアステリア案件の体制・保守の契約・変更の受付の手続き・次の段階の計画は、正本に記載がありません。未確定 このユニットでは、M21 より後の案件の計画を想定しません。
7. THINK — プロジェクトの残りで全部やってしまう
（教材上の例）プロジェクトの体制が縮小される直前に、利用部門から改善の要望がまとまって届きました。プロジェクトの担当者が次のように提案しています。
「メンバーが残っているうちに、プロジェクトの残りの予算で全部対応してしまいましょう。」
問題
この提案を受け入れてよいでしょうか。
判断例を開く
判断
そのまま受け入れるべきではありません。
確認すること:
- 要望に優先順位は付いているか。すべてに対応する必要があるか
- 急いで変更を入れることで、稼働したばかりの本番を不安定にしないか
- プロジェクトの予算を、稼働後の改善に使ってよいか（誰が承認するか）
- 今後も要望は届き続ける。そのための窓口・予算・体制は決まっているか
今届いた要望を片づけても、稼働後の要望を受ける仕組みがなければ、同じ問題が続きます。
8. よくある失敗
- 「稼働したら完成」と考え、稼働後の予算や体制を用意していない
- 変更の窓口を決めず、要望が個人に直接届く
- ソフトウェアの更新を「動いているから」と先送りし続ける
- 設計の理由を残さずにプロジェクトを閉じ、あとで変更の影響が分からなくなる
- 投資の効果を、稼働後に一度も確かめない
9. 成果物との接続
- OPS-009 稼働直後支援・運用引継ぎ計画：稼働後の支援と、運用・保守への引継ぎを計画する
- REQ-005 変更要求書：変更の要望を受け付けて記録する
- PRG-008 変更管理台帳：変更の経過を残す
- BUS-004 効果測定指標一覧：稼働後に効果を確かめる
- OPS-003 運用手順書：日々の運用と定期作業の手順。変更に合わせて最新に保つ
10. AI WORKFLOW — 要望の整理を手伝わせる
AIは、たまった要望を分類し、似たものをまとめる下書きに役立ちます。
指示例:
「次の変更の要望の一覧を、不具合の修正・改善・業務や制度の変化への対応・その他に分け、同じ内容のものをまとめてください。それぞれに関わりそうな業務を挙げ、確かめる必要があるものとして示してください。優先順位は付けないでください。」
11. REVIEW — AIの整理を確認する
- 分類が正しいか（不具合を改善の要望として扱っていないか）
- まとめた要望が、本当に同じ内容か（要望を出した人に確かめたか）
- AIが優先順位や対応の可否を決めていないか
ADVANCED深掘り — 実務者向けに一段深く
深掘り — 技術的負債の棚卸しと、変更の安全性の指標
負債を一覧にして利子を見積もる
急いで作った部分、古くなった部品、テストのない処理、誰も中身を説明できない処理。こうした「あとで直すつもりのもの」を技術的負債と呼びます。放置すると、変更のたびに余計な時間と障害という利子がつきます。棚卸しして一覧にし、1 件ごとに「毎月いくらの利子（余計な時間、障害の件数）がかかっているか」を見積もります。利子の大きいものから返します。
返済を予算にする
業務からの要望と負債の返済は、同じ人が同じ時間で行います。「変更の作業量の 2 割は負債の返済に充てる」のように、割合で予算を決めておくと、要望に押し出されて返済がゼロになることを防げます。
変更の安全性を 4 つの数で見る
変更をどれだけの頻度で本番に出しているか。変更を決めてから本番に出るまでの時間。変更が原因の障害の割合（変更失敗率）。障害から復旧するまでの時間。この 4 つを月次で見ると、「変更が怖くて出せない」状態か、「安全に小さく出せている」状態かが分かります。世界で共有されている考え方では、この 4 つは DORA 指標と呼ばれます。
完成しない前提の体制
要望をどう受け、優先順位を誰が決め、どの頻度で出すかを、稼働後の体制として決めておきます。「完成したら終わり」の体制のままだと、最初の要望が来たときに誰が決めるかで止まります。
現場で確かめる問い
- 技術的負債の一覧があるか。1 件ごとに、毎月の利子（余計な時間、障害）を見積もっているか
- 返済に充てる作業量の割合が決まっているか。直近の月に実際に充てられたか
- 変更の頻度、本番に出るまでの時間、変更が原因の障害の割合、復旧時間を月次で見ているか
- 稼働後の要望を誰が受け、誰が優先順位を決め、どの頻度で出すかが決まっているか
アステリア案件の稼働後の変更の体制と、負債の扱いは、正本に記録がありません。記録なし
12. 人間が判断すること
- 稼働後の改善・保守・更新の予算と体制
- 変更の要望の優先順位と、承認する人
- ソフトウェアの更新をいつ行うか
- 次の大きな投資が必要かどうか
13. 判断演習
あなたは、プロジェクトから運用へ引き継ぐ計画を作る担当です。
プロジェクトを閉じた翌日に、利用部門から変更の要望が1件届いたとします。その要望が「受け付けられ、決められ、本番に出るまで」に関わる人と手続きを、引継ぎの計画に書くつもりで挙げてください。
あなたの記録あなたの考え。事実ではありません
判断ノート
このユニットで覚えてほしいこと
システムは、稼働した後も、改善・変更・保守・更新を続けて初めて使い続けられます。
プロジェクトを閉じる前に、その仕事を誰がどう続けるかを決めて引き継ぎます。