業務システムを使い始めた後の「ここを直して」の伝え方｜不具合と要望の分け方

「〇〇の画面が動きません」。業務システムを使い始めてしばらくすると、作る側にはこういう連絡が届きます。受け取った側は、ここから質問を重ねることになります。いつからですか。誰が使っている時ですか。どのボタンを押した時ですか。画面には何と出ましたか。

このやり取りだけで日をまたぐことがあります。連絡した側からすると、頼んだのに直らない。作る側からすると、何が起きているのか分からない。どちらも悪くないのに、直るまでの時間が延びていきます。伝え方を少し決めておくだけで、この往復はかなり減らせます。

不具合と要望は別のもの

最初に分けておきたいのが、不具合と要望です。

不具合は、約束どおりに動かないことです。仕様書に書いた計算が合わない、保存したはずの内容が消えた、エラーが出て先に進めない。約束を守れていないので、契約で作る側が直す範囲に入れているのが普通です。直してもらえる期間は契約によります。

要望は、約束に無い変更を新しく頼むことです。項目を1つ足したい、並び順を変えたい、この帳票も出したい。使い始めてから出てくるのは、むしろこちらの方が多いと思います。要望は新しい作業なので、見積もりをもらってから進めるのが普通です。

分ける基準は、仕様書と、納品前の受け入れテストの記録です。そこに書いてあることと違う動きなら不具合、書いていないことなら要望になります。どちらか判断がつかないものも出てきます。その時は、判断がつかないと書いたまま送ってください。社内で結論を出そうとして連絡が遅れるより、ずっといいです。

作る側がすぐ動ける書き方

不具合を伝える時は、作る側が同じ現象を自分の手元で起こせるように書きます。起こせれば、原因はたいてい短い時間で見つかります。起こせないと、推測で直すことになり、直ったかどうかも確かめられません。

書く項目は、次のとおりです。

1.いつ起きたか（日時。一度だけか、毎回か）2.誰のアカウントで操作したか3.どの画面で、何をしたか（押したボタン、入れた値を順番に）4.どうなったか（画面に出た文言はそのまま写す）5.本来はどうなるはずか6.使っていた端末とブラウザ

2の誰のアカウントか、は抜けやすい項目です。権限によって見える画面が違うので、社長のアカウントでは起きず、パートのアカウントでだけ起きる不具合があります。

5の本来どうなるはずか、も書いてください。書いた本人には当たり前でも、作る側には、どれが正しい結果なのかが分からないことがあります。

エラーの文言は、要約せずにそのまま写すか、画面ごと撮ります。「エラーが出た」だけでは、何百とある原因の候補から絞り込めません。

画面の記録のしかた

言葉で手順を書くより、操作しているところを録画して送る方が早い場面もあります。とくに、手順が長い時や、どこで押し間違えたのか本人にも分からない時です。

Mac では、shift キーと command キーと5キーを同時に押すと、画面を収録するためのツールバーが出ます（Apple のサポートページ）。Windows 11では Snipping Tool に録画の機能があり、Windows ロゴキーと Shift キーと R キーを押すと録画する範囲を選ぶ画面が開きます（Microsoft のサポートページ）。どちらも2026年9月時点の案内です。

録画まで要らない時は、画面の写真（スクリーンショット）1枚でも助かります。Mac なら shift キーと command キーと3キーで画面全体を（Apple のサポートページ）、Windows なら Windows ロゴキーと Shift キーと S キーで範囲を選んで撮れます（上の Microsoft のページ）。撮る時は、エラーの部分だけを切り取らず、画面全体を撮ってください。ブラウザの上にある URL の欄や、画面の端に出ている日時、ログインしている人の名前が映っていると、作る側はどの画面の、いつの出来事かを写真だけで追えます。スマホで起きた不具合なら、スマホの画面の写真を撮ります。パソコンの画面をスマホのカメラで撮った写真は、文字が読めないことがあるので、パソコンの側で撮ります。

気をつけたいのは、画面にお客様の名前や住所が映る場合です。録画や写真はメールやチャットで送られ、あちこちに残ります。映らない画面で同じことが起きないか先に試すか、映ってしまう部分を塗りつぶしてから送ります。送り先も、作る側と決めた窓口に限ります。

急ぎかどうかの決め方

届いた連絡が全部「至急」だと、作る側はどれから手を付ければいいか分かりません。急ぎかどうかは、社内で決めて伝えます。

目安にしやすいのは、業務が止まるかどうかと、回避策があるかどうかの2つです。注文が受けられない、請求書が出せない、のように業務が止まるものは、すぐに電話も併用して伝えます。別の画面から入れれば済む、手で計算し直せば済む、のように回避策があるものは急ぎではありません。回避策と一緒に伝えれば、作る側は他の急ぎの件を先に片付けられます。業務に支障の無い見た目のずれや文言の間違いは、不具合でも急ぎではないので、要望と一緒にまとめて伝えれば十分です。

急ぎかどうかを決めるのは、社内で1人に絞っておくと話が早くなります。現場の担当者が思い思いに作る側へ連絡すると、同じ件が何通も届いたり、社内で決めた優先順位と違う順で作業が進んだりします。

要望はまとめて頼む

不具合はその都度伝えますが、要望は社内で集めてから、月に1回などの決まった間隔でまとめて頼む方がうまくいきます。

思いついたその日に1件ずつ頼むと、作る側は1件ごとに見積もりを出し、1件ごとに作業の予定を組み直すことになります。まとめて届けば、似た変更を一度に済ませたり、同じ画面を触る要望を組み合わせたりできます。頼む側も、今月の予算の中でどれを先にやるかを、一覧を見ながら選べます。

集めた要望には、なぜそれが要るのか、を1行ずつ添えてください。項目を足したい、だけでなく、足すと月末の集計が手作業でなくなる、まで書いてあると、作る側がもっと簡単な別のやり方を提案できることがあります。

直ったと言われた後

「直しました」と連絡が来たら、報告した本人が、報告に書いたのと同じ手順でもう一度操作してみます。あわせて、直した所と同じ部品を使っていそうな、よく使う画面も1つか2つ通しておきます。1か所を直すと、別の画面の動きが変わることがあるからです。同じ現象が出ず、ほかの画面にも変わりがなければ、その件は閉じます。出たら、その結果を同じ件への返信として伝えます。新しい件として送り直すと、作る側で経緯が分からなくなります。

そのためにも、報告には社内で番号を振り、一覧にしておくと便利です。共有のスプレッドシートで十分です。番号、報告した日、中身の要約、不具合か要望か、急ぎかどうか、今どうなっているか、閉じた日。これだけの列があれば、どの件が止まっているかがひと目で分かります。

一覧は、あとで効いてきます。同じ症状がしばらくして再び出た時に、前にも起きた何番の件と同じです、と伝えられます。作る側は前回の原因と直し方から調べ始められるので、最初の時より早く片付きます。保守の契約を見直す時にも、この1年でどんな件が何件あったかを一覧から数えられます。

保守契約で決めておくこと

ここまでの伝え方がうまく回るかどうかは、保守の契約で何を決めてあるかにかかっています。使い始める前に、次のことを作る側と確かめておきます。

• 不具合として無償で直す範囲と、その期間
• 要望の見積もりの出し方と、月ごとの作業時間の枠があるかどうか
• 作る側の担当者が替わった時の引き継ぎ
• 連絡の窓口と手段、対応してもらえる時間帯と急ぎの時の返事の目安

とくに1つ目は、あいまいなまま始めると後でもめやすいところです。どこまでが不具合として直してもらえるのか、それはいつまでなのかを、言葉にして残しておきます。社内の担当者が替わっても伝え方が変わらないように、報告の書き方そのものも業務マニュアルに入れておくと安心です。

使い始めた後の保守で何を決めておくかを含めて相談したい時は、アプリ・システム開発のページをご覧ください。