ゲームは動かないのに、どこへ尋ねればよいかも分からない。そんなときは、ゲームを直すより先に問い合わせを書くところでつまずきます。Steamで買ったのだからSteamに送ればよさそうに思えても、開発元に尋ねるべき問題なのか迷います。ここで必要なのは原因を推測することより、どの窓口にどの場面を伝えるかを決めることです。
以下に出てくるパズルゲーム、バージョン1.2.0、3回の結果、問い合わせ文は、すべて説明のための架空の例です。実際にゲームを実行した記録でも、サポートチームにメッセージやファイルを送った記録でもありません。公式の経路はSteam、Factorio、Larianの公開案内で確認しますが、問い合わせ文を書き直す部分はこの架空の場面に限ります。
Steamで購入しても、問い合わせ先は問題の種類で選びます
開発元が示されていない架空の例で、実際に問い合わせを送ったものではありません。
Valveが開発したゲームの問題は、Steamサポートに直接問い合わせるよう公式に案内されています。Steamアカウントや購入、Steamのダイアログに表示され、ゲームの起動を妨げるエラー、ゲームを読み込んだ後に起きる認証・CDキーのエラーも、Steamサポートの案内に含まれます。反対に、サードパーティー製ゲームを起動した後のバグや想定外の動作は、Steamの認証・CDキーに関する問題でなければ、開発元やパブリッシャーに問い合わせるよう案内されています。Steamのサードパーティー製ゲームに関するサポート案内
同じ案内には、ライブラリで該当ゲームのサポート項目を開き、開発元の連絡先を探す方法も載っています。サードパーティーのサポート先が見つからない場合は、Steamサポートに連絡先を尋ねることができます。
実際の問い合わせには、ゲーム名も書いておくほうが安全です。ゲームごとの掲示板なら省いても通じるかもしれませんが、複数のゲームを受け付ける窓口では、何について話しているのかが抜けることがあります。エラーコードがないなら、画面が変わらなかったことをサーバーエラーに言い換える必要もありません。存在しない文言を作らず、見た場面を説明します。
公式フォーラム内でも、質問の行き先は分かれます
二つの質問を分けた架空の例であり、一方のやり取りがもう一方へ自動的に伝わるという意味ではありません。
Factorioのヘルプでは、バグやクラッシュの報告を公式フォーラムのバグ報告エリアに案内しています。ゲームの進め方や使い方を尋ねる人には、ほかの利用者から助けを得るためのエリアを案内します。連絡先のページでも、バグ報告、ゲームの遊び方、アイデアや提案を別々に挙げています。技術サポートの連絡先を見つけても、そこへ何を送るべきかという案内まで読む必要があるのはこのためです。Factorioのヘルプ · Factorioの公式連絡先案内
Larianの開発者フォーラムに掲載された2023年の告知は、Baldur’s Gate 3の問題やバグをサポートチームに送るよう案内しています。該当フォーラムのエリアは、プレイヤー同士で助け合ったり回避策を話し合ったりする場として分けられています。この資料は当時の役割分担を示す一例です。返信までの時間や、現在のすべての受付方針を証明する資料だと広げて解釈しません。Larianのバグ受付案内
そのため、公開の議論と公式窓口では質問が異なります。ほかのプレイヤーには「同じ画面を経験しましたか？」と尋ね、開発元には「この動作は意図されたものですか？」と尋ねることができます。どちらの場合も、相手が前のやり取りをすでに読んでいるとは考えなくてかまいません。
件名は原因を当てるより、見た場面を捉えます
バージョン1.2.0は、この例のために決めた値です。
架空の問い合わせの最初の件名は「ゲームが壊れています」、本文は「次に進めません。バグですか？ 早く直してください」です。これを「早急な対応をお願いいたします」に変えても、相手が得る場面の情報は増えません。件名に場所と操作を入れることが先です。
Factorioの報告案内では、実際に問題が起きたバージョンと発生した状況を件名に入れるよう求めています。この案内は2014年5月16日に初めて掲載されたもので、Steam全体に共通する書式ではありません。Factorioのバグ報告案内
この記事の架空の場面では、パズル一覧から3番目のパズルを選び、ピースをすべて完成させた後、結果画面の「次のパズル」ボタンを押しました。結果画面はそのまま残りました。次のパズルへ移ると予想した根拠は、ボタンの名前です。説明書や別の準備手順が必要かどうかは、この例では確認していません。その部分を原因やルールとして断定しないようにします。
観察した範囲も狭くしておきます。音楽は流れ続け、カーソルは動きましたが、ほかのボタンが反応したかどうか、どれくらい待ったかは分かりません。そこで、「ゲーム全体がフリーズした」ではなく、「ボタンを押した後も結果画面が残った」と書きます。入力機器と実際のゲーム名も、この架空の例では決めていません。
回数は数え、分からないことは分からないままにします
実測したエラー発生確率ではなく、例のために決めた3回の結果です。
この例では、同じ操作経路を3回たどったことにします。2回は結果画面が残り、1回は次のパズルへ進みました。どの試行で残り、どの試行で進んだかという順序は決めていません。3回中2回という集計は、説明のために作った条件であり、実際のテスト結果ではありません。
だから「一度も進めません」とは書きません。1回は進んだ記録があれば、次の画面をまったく開けない問題と、同じ操作でも結果が変わる問題を区別できます。この小さな架空の集計をパーセンテージやゲーム全体のエラー発生確率に変えると、数字の示す範囲が変わってしまいます。
問い合わせを丁寧にするために、確認回数を増やさなければならないわけでもありません。実際には1回経験して終了しただけなら、その1回を書けば十分です。追加で確認したことがあれば操作と結果を併記し、確認していない待ち時間や環境条件は空欄のままにしておきます。
添付は場面に必要な分だけ、問い合わせ文は短く
以下の問い合わせ文と図は、実際に送ったメッセージや入手したファイルではありません。
結果画面のキャプチャには、ボタンの名前と残った画面を示すことができます。ただし、1枚だけでは、ボタンを押す前か後か、どれくらい待ったかまでは分かりません。複数の画像を添付するなら、どの場面が先で、場面の間に何をしたのかを書きます。実際に添付を求められる内容は、提出先の案内で確認してください。
架空の画面にメッセンジャーの通知や別の人の名前が表示されていても、それはパズルのボタンを説明する資料ではありません。Steamのオンライン行動規則は、個人情報の公開、嫌がらせ・スパム、他人の情報の不適切な収集・配布を禁じています。Steamオンライン行動規則
公式Factorio Wikiは、ログにセッションの日付・時刻、アップデーターのログイン名、一部ファイルの完全なパスが含まれ、通常は機密情報ではないと説明しています。これは文書が挙げる一般的な情報であり、読者のファイルを調べた結果ではありません。この記事では、ログの作り方や個人ファイルを削除・隠す手順を定めていません。Factorioログ文書の情報範囲
> 例示用バージョン1.2.0で「次のパズル」ボタンを押しても、結果画面が残ります。パズル一覧から3番目のパズルを選び、ピースをすべて完成させてから、結果画面の「次のパズル」ボタンを押しました。同じ操作経路を想定した3回の例のうち、2回は結果画面が残り、1回は次のパズルへ進みました。画面が残ったときも音楽は流れ続け、カーソルは動いていました。ほかのボタンの反応と待ち時間は確認できていません。次のパズルへ移ると予想しましたが、別の準備手順が必要かどうかは分かりません。この動作は意図されたものですか。意図されたものでない場合、どのような情報を追加すればよいか教えていただけますか。
ゲーム名と端末情報は、この例では決めていません。実際の提出先で何を入力し、どの添付を求められるかを確認する必要があります。この短い問い合わせ文も、実際のゲームにそのまま投稿する報告ではありません。観察、期待、未確認の項目を一つに置いてみるための例です。
似た件名は比較の出発点にすぎません
実際に同じ問題の記事を見つけたという意味ではなく、仮の比較です。
検索で「次のボタンが動きません」という件名を見つけても、ログイン画面のボタンとパズルの結果画面のボタンは別の場面かもしれません。Factorioの報告案内も、確実に同じ問題の既存報告を見つけた場合は、そこへ情報を追加するよう求めています。件名が似ているからといって、自分の経路や結果を先の投稿に合わせて書いてはいけません。
本文にない条件は、質問として残すことができます。たとえば「一覧から直接選んだ場合も同じでしたか？」と尋ねる形です。「私もです」という返信の数を、同じバグに困っている人数へ書き換えたり、1人の利用者の操作説明を、全員が問題ないと確認したかのように広げたりはしません。コメントと本文が実際に述べた範囲だけを残します。
追加の質問を受けたら、最初の文章全体をもう一度貼るのではなく、尋ねられた部分だけを補います。パズル一覧を通ったかと聞かれたら、3番目のパズルを直接選んだと答えます。待ち時間を聞かれても測っていなければ、そう答えます。後から確認した内容には、そのときの条件を添え、異なる場面を一つの結果のように混ぜないようにします。
同じ画面を見たという話、原因を調べているという話、修正を計画しているという話、修正が終わったという話も、それぞれ異なります。返事がないという事実だけで、無視されたとかバグではないと結論づけることはできません。計画があるだけで、修正版や解決日を約束することもできません。ここまで区別しておけば、最初の質問に必要な情報と、まだ分からない情報を一緒に残せます。