新しい業務システムの公開日が近づいてきた。開発は順調に進み、テストも一通り終わった。ところが、いざ公開直前になって「不具合が出たら誰が直すのか」「利用者から問い合わせが来たら誰が答えるのか」が決まっていないことに気づく。こうした場面は珍しくありません。開発の進捗ばかりに気を取られ、公開後の体制を後回しにしてしまうためです。
公開後に慌てて担当を決めようとすると、開発会社と社内のどちらが何をするのか曖昧なまま運用が始まり、対応が遅れたり、同じ問い合わせに複数人がバラバラに答えてしまったりします。公開前に決めておくべき内容を整理します。
保守の範囲を具体的に言葉にする
「保守」という言葉は人によって指す範囲が違います。不具合の修正だけを指す場合もあれば、サーバーの監視、データのバックアップ、機能追加の相談まで含む場合もあります。契約や依頼をする前に、どこまでを保守と呼ぶのか言葉にしておく必要があります。
「不具合が出た場合」「新しい要望が出た場合」「サーバーが止まった場合」、それぞれ誰が最初に動きますか？
この質問に即答できない場合は、まだ体制が固まっていないということです。公開前にこの3つのケースを分けて、担当と対応の流れを確認しておきましょう。
問い合わせ窓口を一本化する
利用者からの問い合わせ先が複数あると、同じ内容が別々の担当者に届き、対応にばらつきが出ます。まずは社内の窓口を一つに決め、そこから開発側や各担当に振り分ける形にするのが基本です。
想定例として、社内の情報システム担当が一次受付を行い、操作方法の質問はその場で回答、システムの不具合らしきものは開発会社へ連絡する、という分け方があります。これなら利用者は迷わず、社内も状況を把握しやすくなります。
外部委託が必要な条件と、社内対応で足りる条件
すべてのケースで外部の保守契約が必要なわけではありません。判断の目安を整理します。
外部委託を検討したほうがよい条件
- システムの構造やソースコードを理解できる人が社内にいない
- 不具合の原因調査に専門知識が必要な技術要素を使っている
- 公開後も機能追加や仕様変更が継続的に発生する見込みがある
- 業務時間外やシステム障害時にも一定の対応スピードが求められる
社内対応や運用改善で足りる条件
- 操作方法に関する質問が中心で、マニュアルやFAQの整備で解決できる
- 利用者数が少なく、問い合わせ件数自体がそれほど多くない見込みである
- 軽微な設定変更や表示の修正程度で、構造的な変更は想定していない
- 社内に一定のITリテラシーを持つ担当者がいて、簡単な一次切り分けができる
後者に近い場合は、まずFAQページの整備や操作マニュアルの改善を優先し、外部委託の範囲を絞ることで、無駄なコストを抑えられる可能性があります。
対応の記録を残す仕組みを決めておく
問い合わせや不具合対応は、記録を残さないと同じ質問が繰り返されたり、過去の対応内容が引き継がれなかったりします。公開前に、問い合わせ内容と対応結果をどこに記録するか、誰が入力するかを決めておくと、後からFAQの作成や保守範囲の見直しにも使えます。
記録の形式は難しいものである必要はありません。表計算ソフトの簡単な一覧でも、問い合わせ管理ツールでも、継続して残せる方法であれば十分です。
公開前に確認しておきたいチェックリスト
- 保守の範囲（修正・監視・機能追加の相談）を言葉にして共有したか
- 不具合発生時に最初に連絡する相手を決めたか
- 利用者からの問い合わせ窓口を一本化したか
- 社内対応で足りる範囲と外部委託が必要な範囲を切り分けたか
- 対応記録を残す場所と担当者を決めたか
- 業務時間外の対応方針（翌営業日対応か即時対応か）を決めたか
- FAQやマニュアルなど、問い合わせを減らす材料を用意したか
保守と問い合わせの体制は、公開後に少しずつ整えていくこともできますが、最初の数週間に混乱が起きやすいのも事実です。公開前にできる範囲で決めておくことで、運用開始後の負担を減らせます。