システム保守のメイン作業として、問い合わせを受けた内容についての回答を行う。
この回答時に作成すべき資料について書いてみる。
回答方法として、電話での口頭回答が一番楽ではある。
ただし、回答結果がもの（資料）として残らないため、問い合わせ元は回答を受けたのかどうかすら分からなくなってしまうことがある。
そのため、可能な限り資料を作り、それを提出・説明することで回答することが望ましい。
（緊急時は資料を作る時間が無いと思うので、この限りではないだろう）
調査結果をまとめた資料（ここでは「調査結果報告書」とする）に盛り込むべき内容を整理する。
どんな調査結果報告書を思い浮かべるだろうか？
調査結果報告書の目的は、起きた事象と調査結果を盛り込むこととなるため、へたに作ると調査結果が
伝わらない資料が出来上がってしまう。
調査結果が伝わらない資料では意味が無い。
あくまで資料を作るのが目的ではなく、調査結果を伝えることが目的である。
俺が作っていた調査結果報告書は以下のような構成としていた。
これは長い期間、その問い合わせ元と付き合ってきた結果、出来上がったものなので、すべての調査結果報告書として適用できるとはいえないと思う。
まぁ、参考になれば。
１．問い合わせ内容
問い合わせ元から受けた内容を可能な限りそのまま記載する。
これによって、何についての調査結果なのかを問い合わせ元に思い出してもらう意味合いもある。
２．現状
問い合わせ元が気になった事象により、現時点でシステムに起きている状況を記載する。
仕様どおりであっても、バグであっても、どんなことが起きたを書くことが重要である。
３．影響
その事象により、起きている問題点があれば記載する。
不正なデータが出来てしまったのか、画面の動きだけが不正なのか、はたまた仕様どおりなのか。
４．対策
起きている問題点を解消するための方法を記載する。
このとき２つの観点が必要である。
１つめは「今すぐに起きている事象を解消するべき方法」（暫定対応）
２つめは「恒久的に取るべき対応策」（恒久対応）
例としては、「暫定対応」としてデータ対応を行い、「恒久対応」としてプログラムの修正を行う。
という感じ。
また、対策については問い合わせ元が選択できるように、複数の案を作成すると喜ばれると思う。
問い合わせ元が選べるというのが大事。
ただし、システム保守担当にどのように負荷がかかるのか、それぞれの案を対応する場合の
おおよその作業規模（工数）もつけると良いかも。
５．所感
これは必要に応じて記載する。
俺の場合「なぜこのような事象が発生したのか」を書いていた。
画面に配置している項目やボタンが分かりづらい、とかユーザが勘違いしていた、などの起因となった操作など。
上記で大体はまかなえていた。
また、このような内容をまとめる上で、以下を意識して作っていた。
・表題（ヘッダー）
一言で何についての資料なのかが分かるように要約した文言。
これは「１．問い合わせ内容」にもつながり、問い合わせ元に思い出してもらう意味合いもある。
・作成者（ヘッダー）
誰が作った資料なのかが分かるように所属も含めて記載する。
誰が作ったのか分からない資料は意味が無い。
・作成日（ヘッダー）
いつ作った資料なのか分かるように記載する。
このとき、日付は自動設定しない。
印刷したとき、資料を開いたときの日付では、いつ時点での調査結果のか分からず、後で苦しむ。
こんな調査結果出てきたけど、今のシステムにも適用される事象なのかが分からない。
・資料枚数
上記の調査結果について、必ずＡ４で１枚にまとめる。
複数枚になると、問い合わせ元が読む気にならない。
Ａ４で１枚にならない場合には、盛り込む内容が多すぎる。
書ききれない場合には、別紙を作り、その別紙で詳細を述べる。
これは結構大事だと思った。
問い合わせ元は、少なからず忙しい中、時間を割いて調査結果に目を通しているので、１枚で一通り分かる資料を求めている。
・図
文章では伝わらないことが多い（日本語は難しい）ので、図化した資料を付けることで、格段に伝わりやすくなる。
書く方も読む方も図があると認識合わせしやすい。
・作成後に他メンバーにチェックを依頼する
自分で作成した資料は、必ず他メンバーにチェックをしてもらうこと。
これをしないと、つじつまの合っていない資料が出来上がり、問い合わせ元からの信頼を失いことにつながる。
ちょっと面倒だけど、とても大事なこと。
こんな感じですわ。