ソフトウェアのユーザーサポートは、筆者も経験がある。ソフトウェアについては、おおよそのところで他の開発者も一致するだろう。OSの種類やバージョンなどの実行環境、ソフトウェアのバージョンが、まず必要になる。スマートフォンだと機種も重要だ。この前提条件が違うと、そもそも不具合が再現しないことがある。 　次に、操作手順と、その結果何が起きたかだ。結果としてエラーメッセージが表示されるなら、その内容をそのまま正確にコピペする。あるいはスクリーンショットを撮る。 　エラーメッセージは特に重要だ。エラーメッセージが分かると、プログラムのどこの行で問題が発生したのか特定できる。格段にトラブルの原因を見つけやすくなる。 　また、手順を書く際、可能なら、最小手順で同じトラブルが発生する方法が書いてあるとよい。ソフトウェアの問題は、再現性があると、ほぼ確実に修正することができる。100回やって100回起きる現象は直しやすい。逆に再現性がない、100回やって1回しか起きない現象は、直すのが難しい。 　そして可能なら、原因の推測も書いてあるとよい。質問者の方が、自身の環境について多くの情報を持っている。たとえば、前日に他のソフトウェアをインストールしたなら、そのソフトウェアが原因のこともある。 　それ以外には、何をしたくて操作したのか、期待とどう違っていたのかも書いた方がよい。そもそも、それはバグではなく仕様である、といったことも多い。あまりにも似た問い合わせが多いと、仕様がまずかったということで改善されることもある。 　こうした情報のうち、環境にまつわる情報は、ソフトウェア側で自動収集できる。そのため私の場合は、ユーザーサポートのメニューを選択した際は、必要な情報を自動収集して出力し、残りの情報をユーザーに記入してもらっていた。 　また、世間に出回っている多くのソフトでは、エラーが起きた時に、各種の情報を集めて、その内容をサーバーに送る機能を用意している。ユーザーに適切な情報を提出してもらうことは開発者以外には難しいので、そうした工夫をしているわけだ。 　プログラミング系のＱ＆Ａには、昔からプログラマーの中で、ある程度の共通認識がある。有名なものとして、結城浩氏の「技術系メーリングリストで質問するときのパターン・ランゲージ」がある。 　公開されたのは2001年と20年前。メーリングリストという現代ではあまり使われないコミュニケーションツールだが、内容は色あせていない。WebベースのＱ＆Ａサイトなどでも共通して使える内容である。この文書から、関係する大項目をいくつか箇条書きで抜き出してみる。 ・実行手順を箇条書きで書く。 ・こうなって欲しかったという期待した結果を書く。 ・実際に起きた結果を書く。 ・どこから期待通りにならなかったかのステップを明記する。 ・条件を具体的に書く。 ・エラーメッセージをそのまま記載する。 ・自分がどう考えたのかを書く。 ・参考文献を適切に引用する。 ・関連するプログラムをコンパクトに抽出して示す。 ・自分の環境を書く。 ・事前に自分で調べる。 ・本についての疑問があるなら、著者本人に質問する。 　こうしたことが書いてある。 　最後の「著者本人に質問する」というのは、ソフトウェアのユーザーサポートでもよくある問題だ。全然違うソフトの質問をしてくる人が一定数いる。 　たとえば、Google Chrome のユーザーサポートに、Adobe Photoshop の使い方を尋ねられても困るわけだ。こうしたことはよくあり、「それは、そのソフトの作者に聞いて下さい」という回答が一定数ある。