システム開発では、公開日がゴールのように扱われることがあります。しかし実際には、公開後に現場の使い方が見え、改善点が出てきます。
公開後の運用を考えていないと、問い合わせや要望が散らばり、何から直すべきか判断しにくくなります。
公開直後は、問い合わせが増える

新しいシステムを使い始めると、操作方法の質問、想定外の入力、権限の追加、表示文言への違和感などが出てきます。
これは失敗ではなく、実運用に入ったからこそ見える情報です。重要なのは、問い合わせを集約して優先順位を付けることです。
- 操作方法の質問
- 権限やアカウントの追加
- 入力ルールの確認
- 軽微な表示や文言の修正
- 想定していなかった業務パターン
改善要望は、その場で全部対応しない

公開後は、利用者から多くの要望が出ます。すべてをすぐに対応すると、方針がぶれたり、重要でない修正に時間を使いすぎたりします。
要望は一度集め、業務影響、利用頻度、緊急度で整理するのが現実的です。
- すぐ直す不具合
- 次回改善で対応する要望
- 効果を確認してから判断する要望
- 運用ルールで吸収する要望
保守と改善を分けて考える

保守は、システムを安定して使い続けるための対応です。一方、改善は、業務をより良くするための追加や変更です。
この二つを分けておくと、緊急対応と計画的な改善を混同せずに進められます。
まとめ
- 公開後にも運用設計が必要
- 問い合わせ窓口を決める
- 改善要望は一度整理する
- 不具合対応と改善対応を分ける
- 使いながら育てる前提を持つ


