システム不具合対応マニュアルの作り方。知識が少ない人でも動ける初動手順

システム不具合は、担当者が休みの日にも起こります。詳しい人だけが対応できる状態では、基幹ソフトが止まったときに社内の動きが遅れます。

一人総務・少人数総務で大切なのは、すべてを一人で抱えることではありません。知識が少ない人でも、最初に何を確認すればよいか分かる状態を作ることです。

この記事では、画面写真、発生範囲、サーバー構成、システム会社への連絡内容を、実際に使えるマニュアルへ落とし込む考え方を整理します。

マニュアルの目的は、すぐ直すことではなく初動をそろえること

不具合対応マニュアルというと、原因を突き止めて直す手順を細かく書くものと思われがちです。しかし、少人数の管理部門で最初に必要なのは、専門的な復旧手順ではなく、初動のばらつきを減らすことです。

画面が開かないのか、特定の端末だけなのか、全社的に止まっているのか。最初の確認がそろうだけで、システム会社へ渡す情報の質が上がります。結果として、復旧までのやり取りも短くなります。

最初に確認する項目を固定する

不具合が起きたときは、慌てて電話をしたくなります。ただ、情報が少ないまま連絡すると、結局その場で聞き返されることが増えます。

発生時刻、対象部署、対象端末、エラー画面、業務停止の有無は、最初に確認する項目として固定しておくと実務で使いやすくなります。

確認項目	見ること	システム会社へ伝える意味
発生時刻	いつから起きているか	ログ確認や直近変更の確認につながる
対象範囲	一人だけか、部署全体か、全社か	端末問題かシステム側問題か切り分けやすい
画面写真	エラー表示、入力画面、警告内容	口頭説明の不足を補える
業務影響	受注、売上、請求などが止まっているか	対応優先度を決めやすい

ツリー形式にすると迷いにくい

文章で長く説明すると、慣れていない人ほど途中で迷います。そこで、確認事項はツリー形式にすると使いやすくなります。

たとえば『画面は開くか』『他の人も同じか』『業務が止まっているか』という順番に枝分かれさせます。答えがはい・いいえで進む形にすると、判断に慣れていない人でも初動を進めやすくなります。

細かい説明よりも、最初にどこを見るかが分かることを優先します。特にパート社員や別部署の人にも見てもらう場合は、専門用語を減らした方が機能します。

画面写真とサーバー構成図は、言葉より早い

システム不具合では、文章だけで状況を説明するのが難しい場面があります。画面写真を添付すれば、エラー文言や入力内容、どの画面で止まっているかが一度に伝わります。

また、サーバー、共有フォルダ、基幹ソフト、端末の関係を写真付きで整理しておくと、社内の人にもシステム会社にも説明しやすくなります。言葉で何度も説明するより、構成図を一枚見せた方が早い場面は多いです。

知識が少ない人に読んでもらう

マニュアルは、作った本人には分かりやすく見えます。けれど、実際に使う人が同じように理解できるとは限りません。

私の場合、マニュアルを改善するときは、知識が自分より少ない人に見てもらうことを重視します。分かりづらい表現、どこを押せばよいか迷う箇所、写真が足りない箇所は、作った本人より利用者の方が気づきやすいからです。

システム会社へ送るテンプレートを作る

不具合時のメールは、毎回ゼロから書くより、送る型を決めておく方が安定します。件名、発生状況、画面写真、影響範囲、急ぎ度、連絡先を入れるだけでも、相手は動きやすくなります。

緊急度が高いときは電話も使いますが、電話だけでは記録が残りません。電話で初動を早め、メールで写真と事実を残す。この組み合わせが少人数総務には向いています。

対応後にマニュアルを更新する

不具合が解消すると、ついそこで終わりにしたくなります。しかし、同じ問題が次に起きたときに強くなるのは、対応後に更新したマニュアルです。

実際に迷った点、システム会社から聞かれた点、先に写真を撮っておけばよかった点を追記します。不具合対応は、次回の初動を早くするための材料にもなります。

AIやGemini Notebookに戻すと次回が早くなる

メールで残した対応履歴や、マニュアルの更新内容は、AIやGemini Notebookに読み込ませる資料としても使えます。よくあるエラー、確認順、システム会社へ伝える項目を整理しやすくなります。

もちろん、入れてよい情報と入れてはいけない情報の線引きは必要です。個人情報、社外秘情報、認証情報は入れず、社内で共有できる範囲の手順やFAQとして使います。

担当者が休みの日を前提に作る

システム不具合対応は、詳しい担当者がいる日にだけ起きるわけではありません。休みの日、外出中、別のトラブル対応中にも起こります。だからこそ、マニュアルは担当者本人のためだけではなく、代わりに初動を取る人のために作ります。

代替要員には、完璧な復旧を求めません。最初に状況を止めずに確認し、必要な写真を撮り、システム会社へ渡せる情報を集めるところまでできれば十分です。代わりの人が動ける範囲を決めることが、属人化を下げる第一歩になります。

業務停止の有無で優先順位を変える

セキュリティの確認先：IPAの中小企業の情報セキュリティ対策ガイドラインには、情報漏えい・システム停止などを想定した「中小企業のためのセキュリティインシデント対応の手引き」も用意されています。自社マニュアルは、影響範囲の確認、社内報告、外部連絡、復旧後の再発防止へつながる順番で整えます。

同じシステム不具合でも、緊急度は違います。受注が止まっている、伝票が発行できない、請求処理ができない場合は、社内への影響が大きくなります。一方、特定の表示だけの不具合であれば、急ぎ度を下げて確認できます。

マニュアルには、業務停止の有無を必ず入れておきます。止まっている業務、影響する部署、代替手段の有無を確認できると、社長やシステム会社へ報告するときにも判断材料になります。

実際の初動は「一台だけか、全社か」を先に分ける

不具合の第一報を受けたら、最初に報告者の端末で実際の現象を確認します。ここで重要なのは、その端末だけの問題なのか、同じ機能を使う複数人や全社で起きているのかを切り分けることです。

1. 報告者の端末で、何が起きているかを見る
2. ほかの端末や部署でも同じ現象があるか確認する
3. 画面、時刻、操作内容を写真やメモで押さえる
4. 画像はメール、緊急性は電話でシステム会社へ伝える
5. 社長へ「起きていること」と「現在の対応」を報告する

復旧時刻は、初動の段階では分からないことがあります。社内が知りたい情報ではありますが、根拠のない時刻を約束せず、システム会社へ確認しながら分かる範囲を更新します。最初の30分は、原因を言い切ることより、影響範囲と事実をそろえることを優先します。

写真を撮るときは、写してはいけない情報にも注意する

画面写真は便利ですが、個人情報や取引先情報、金額、IDなどが写り込むことがあります。社外へ送る可能性がある写真では、必要な部分だけを切り出す、不要な情報を隠す、送付先を確認することが大切です。

不具合対応では急ぎたくなりますが、情報管理を崩してよいわけではありません。マニュアルに『写真を撮る前に確認すること』を入れておくと、慌てた場面でも守りやすくなります。

社内への一報も型を決めておく

システムが止まっているとき、社内から同じ問い合わせが重なることがあります。総務が個別に答えていると、システム会社とのやり取りが進まなくなります。

そのため、LINE WORKSなどに出す一報の型を用意しておくと便利です。『現在この機能で不具合が出ています』『確認中です』『代替処理はこの方法です』『次の案内は何時ごろ出します』という形にすると、社内の不安も下げやすくなります。

第一報では「しないでほしい操作」を先に示す

原因や復旧見込みがまだ分からないときでも、二次的な混乱を防ぐ指示は出せます。プリンターの中に印刷データがたまり続ける場合は「印刷しないでください」、基幹ソフトの一部処理に影響がある場合は「この処理は止めてください」と、行動を具体的に伝えます。

• タイトル：「基幹ソフトにおける不具合の発生について」など、ひと目で対象が分かる形にする
• 発生状況：現在確認できている事実だけを書く
• 影響範囲：対象の機能、端末、部署を示す
• 依頼事項：止める操作や代替方法を短く示す
• 見通し：不明な場合は不明と伝え、確認中であることを書く

復旧後は、システム会社へ過去ログの確認を依頼し、原因と再発防止を話し合います。設定変更やマニュアル修正まで進められる場合もあれば、イレギュラーで原因を断定できず、再発時に追加調査する形で終わる場合もあります。原因不明を無理に埋めず、次に集める情報を決めておくことも実務的な再発対応です。

復旧後は原因よりも再発時の動きを残す

原因の詳細は、システム会社でないと分からないこともあります。総務側で無理に技術的な原因を説明しようとすると、かえって不正確になる場合があります。

復旧後に残すべきなのは、次に同じ現象が出たときの動きです。どの画面で起きたか、何を確認したか、どこへ連絡したか、どの時点で復旧したか。ここを残すと、再発時に同じ迷いを繰り返さずに済みます。

小さな不具合も記録の対象にする

大きな障害だけを記録する運用にすると、日常的なつまずきが残りません。実務では、少し表示が違う、いつもより処理が遅い、特定の端末だけ動きが変という小さな違和感が、後で原因究明の手がかりになることがあります。

すべてを細かく報告書にする必要はありません。日付、画面、起きたこと、対応したことを短く残すだけでも十分です。小さな記録が積み重なると、システム会社へ相談するときに『以前も似たことがあった』と伝えられます。

担当者の判断を責める資料にしない

不具合対応の記録は、誰かのミスを探すためのものではありません。責める空気があると、現場は不具合や違和感を言いにくくなります。結果として、問題の発見が遅れます。

マニュアルにも、記録の目的を明確にしておくとよいです。次に早く動くため、同じ確認を減らすため、システム会社へ正確に伝えるため。目的が共有されると、現場も情報を出しやすくなります。

総務がいない時間帯の入口を決める

営業時間外、休憩中、外出中など、総務がすぐに反応できない時間帯もあります。そのときに誰へ連絡するか、どこへメモを残すか、業務を止める判断を誰がするかを決めておくと安心です。

完璧な体制を作る必要はありません。最低限、困った人が最初に見る場所と、システム会社へ伝える前に集める情報が分かるだけで、対応の遅れは減らせます。

マニュアルは完成品ではなく運用品として見る

一度作ったマニュアルを完成品として扱うと、現場の変化に追いつかなくなります。端末が変わる、画面が変わる、連絡先が変わる、担当者が変わる。小さな変化でも、古い手順のままだと使う人が迷います。

年に一度だけでも、実際に開いて確認する日を決めておくとよいです。防災訓練と同じで、使わない期間が長いものほど、定期的に触っておくことが実務では効きます。

少人数総務では、完璧なマニュアルを作る時間を確保しづらいこともあります。その場合は、最初から完成を狙わず、実際に起きた不具合を一つずつ追記する形でも十分です。現場で起きたことから育てる方が、机上で作った分厚い資料より使われることがあります。

初動マニュアルのチェックリスト

• 発生時刻、対象部署、対象端末を確認する
• エラー画面を写真で残す
• 業務停止の有無を確認する
• 電話で急ぎの初動を取り、メールで記録を残す
• 対応後に、次回使える手順へ戻す

不具合マニュアルは、初動で集まる情報量で見る

マニュアルは細かいほど良いとは限りません。知識が少ない人でも、最初に何を確認すればよいかが分かることが大切です。初動で写真、時刻、対象部署、業務停止の有無がそろえば、システム会社への連絡はかなり早くなります。

初動項目	確認する内容	システム会社へ伝わること
画面写真	エラー画面、対象画面、入力内容	状況を目で共有できる
発生時刻	いつから起きているか	サーバーや処理ログを追いやすい
対象範囲	一人だけか、部署全体か、全社か	障害の広がりを判断できる
業務停止の有無	伝票発行や受注などが止まっているか	緊急度を決められる

発生直後の情報を整理する：影響範囲と緊急度を切り分け、社内共有メモとベンダー連絡文を作る場合は、システム不具合の初動整理ツールを使えます。紙や共有フォルダへ残す型は、システム不具合初動メモで確認できます。

あわせて読みたい関連記事

このテーマに近い実務記事です。必要なところから読み進めてください。

• 一人総務は、ベンダー・現場・社長の情報格差を埋める橋渡し役になる
• システム改修で現場が反発する理由。変化への不安を総務がどう受け止めるか
• ベンダー・現場・社長の情報格差を埋める。一人総務が中に立つ実務
• Gemini Notebookでシステム変更履歴を管理する。基幹ソフト改修を社内FAQ化する方法

よくある質問

まとめ

システム不具合対応マニュアルは、専門家のように直すための資料ではありません。少人数総務では、最初に何を確認し、誰に何を伝えるかをそろえることが重要です。

画面写真、発生範囲、業務影響、連絡履歴を残し、対応後に手順へ戻す。これを続けると、担当者の頭の中だけにあった対応が、社内で使える仕組みに変わります。