読者の質問に次の記事で答える：質問の集め方

質問が届く場所を先に決める

質問を募るときは、募集文を書く前に、どこで受けるかを決めます。受け口が曖昧だと、質問が複数の場所に散らばって拾い漏れが起きます。

受け口を決めるときの条件は三つです。

• 質問者が個人情報を出さなくても送れます。
• 編集側が毎週決まった時間に確認できます。
• 質問と回答の対応を後から追えます。

アソバースを例にすると、確認済みの範囲で使えそうな手段は限られます。フレンド機能やチャット機能は未提供なので、それらを受け口にする前提は置けません。作者の公開プロフィールには、本人が公開を選んだ場合に限り、SNSや問い合わせページのHTTPS URLを載せられます。自作ゲームを公開する人は、この問い合わせページを質問の受け口にする考え方があります。この場合、ログイン用のメールアドレスは公開されないので、受け口は別に用意する必要があります。

作品のレビュー欄は質問置き場にしないほうが無難です。レビューは1〜5点の評価と感想を残す場所で、評価順の掲載条件にも関わります。質問が混ざると、作品の評価と質問が同じ欄に並び、どちらも読みにくくなります。

マガジン自体に質問の受け付け窓口が現在あるかどうかは、この記事からは断定できません。実際に送る方法は、現在の案内で確認してください。

受け口は、最初は一か所に絞るのが現実的です。複数にすると、仕分けの手間が先に増えます。

募集文で質問の形をそろえる

次に、募集文を書きます。募集文の役割は、質問を「記事にできる形」で届けてもらうことです。「何でも聞いてください」と書くと、返ってくるのは「おすすめを教えてください」のような広すぎる質問になりやすいです。

扱いやすい質問には、次の三つが入っています。

1. どんな場面か（何を作っていた、何を遊んでいた）
2. 何に困ったか、何が分からないか
3. すでに確かめたこと

募集文はこの三つを書いてもらう型にします。たとえば次のような文です。

作る・遊ぶ・届けるの途中で止まったことを、次の三点で教えてください。①何をしていたか、②どこで分からなくなったか、③自分で確かめたこと。名前やメールアドレスは書かなくて構いません。いただいた内容は、個人が特定されない形に直してから記事で扱います。

最後の二文は省略しないでください。名前を書かなくてよいこと、記事では改変して使うことを先に示すと、質問者は安心して書けます。編集側も、後から許可を取り直す手間が減ります。

もう一つ決めておきたいのが、答えられない領域の表示です。法律や著作権の個別判断、料金や規約の細部は、記事の中で断定できません。募集文に「規約や法律の細かい判断は公式の案内や専門家の確認を案内します」と書いておくと、質問者の期待を最初に調整できます。

届いた質問を四つに仕分ける

質問が届いたら、すぐ記事にせず、まず仕分けます。判断軸は「いまある根拠で答えられるか」と「何人の役に立つか」の二つです。

• 記事にできる、判断の目安：根拠があり、似た困りごとが他にもありそうです、扱い：一本の記事の主題にします
• 短く答える、判断の目安：根拠はあるが、記事一本にするほどではありません、扱い：記事の中の一節や補足で扱います
• 今は答えられない、判断の目安：根拠が足りない、または仕様が不明です、扱い：「現在の案内で確認する」と明記します
• 範囲外、判断の目安：個別の法律判断、他人の個人情報、未提供の機能の約束などです、扱い：理由を添えて案内先を示します

冒頭の三件を、確認済みの事項で仕分けてみます。

「ZIPで投稿したら画面が真っ白になる」は、記事にできる質問です。入口は直下のindex.htmlであること、素材は相対パスで指定することが案内されています。この二点を確認する手順を記事にできます。ただし、質問者のコードの中身までは分からないので、原因の断定はせず、確認項目を並べる形にします。

「オンライン対戦を三人でやりたい」は、短く答える質問です。オンライン対戦は「潮目のオセロ」と「灯りのチェス」のみで、リンクで招待できる友達は1人です。投稿作品向けの共通対戦APIは未提供です。したがって三人対戦の方法は提示できません。「未提供なので、現状ではできません」と言い切れる質問は、長い記事にせず短く返すほうが親切です。

「どの作品でも記録は残りますか」も、短く答えられます。保存があるのは「余白の庭」「WAVE / WAVE」「かたちのあいだ」の三作品で、他の十作品の記録や録音は画面を開いている間だけです。

仕分けで見落としやすいのは、「今は答えられない」を「範囲外」に入れてしまうことです。前者は後で根拠が見つかれば答えられる質問で、後者は性質上答えない質問です。両者を分けておくと、後日の見直しで答えられる質問を拾い直せます。

質問を記事にするまでの流れ

仕分けで「記事にできる」と判断した質問は、次の順に進めます。

1. 質問を一文にします。 「ZIPで投稿すると真っ白になるとき、最初に何を確かめればよいか」のように、問いの形に直します。この一文が記事の題名と冒頭になります。
2. 似た質問を束ねます。 同じ原因に行き着く質問が複数あれば一本にまとめます。逆に、一件の質問に二つの問いが入っていたら分けます。
3. 根拠を先に集めます。 公式の案内や確認済みの仕様から、答えの根拠になる部分だけを拾います。根拠が見つからない部分は、この段階で「答えられない部分」として別に書き出します。
4. 答えを手順か判断基準にします。 「こうすれば直ります」と結果を約束せず、「この順に確かめ、こうなったら次へ進みます」という形にします。質問者の環境は編集側から見えないためです。
5. 下書きを書き、答えられない部分を残します。 分からない部分を本文から消さず、「この部分は現在の案内で確認してください」と書きます。
6. 質問者の特定につながる情報を落とします。 作品名、固有の表現、細かな状況は、意味が変わらない範囲で変更します。

進行の管理には、簡単な台帳が役立ちます。列は次のくらいで足ります。

• 受け取った日、記入内容：質問が届いた日付です
• 質問の一文化、記入内容：手順1で作った問いです
• 区分、記入内容：四つの仕分けのどれかです
• 根拠、記入内容：参照した公式の案内や仕様です
• 状態、記入内容：未着手／執筆中／公開済み／保留です
• 公開した記事、記入内容：回答した記事の題名です

「保留」の行が長く残る場合は、受け口か募集文に原因があります。たとえば「今は答えられない」が多いなら、質問が仕様の細部に偏っています。募集文の三点（場面、困りごと、確かめたこと）が守られていないなら、書き方の例をもう一度見直す合図です。

答えを返すときの約束

質問を集めるより難しいのは、返す約束を守り続けることです。三つの約束を決めておくと運用が崩れにくくなります。

返す時期を現実的に決めます。 「次の記事で必ず答えます」と書くと、答えを出せない質問が出たときに約束が破れます。「届いた質問は仕分けの上、答えられるものから順に扱います」としておけば、保留も正直に伝えられます。

答えられなかった質問も見える形にします。 範囲外や保留の質問は、黙って捨てると質問者には無視されたように見えます。記事の末尾に「今回は扱えなかった質問」を短く並べ、理由（根拠が不足、公式の案内を確認してほしい、など）を一言添えます。

記事が古くなったら直します。 仕様は変わることがあります。回答記事には、確認した時点を書いておきます。後で食い違いに気づいたら、訂正を記事の冒頭に明記します。質問に答える記事は、読者が後から参照するので、訂正の跡が残るほうが信頼されます。

自作ゲームで質問を受ける人にも同じことが言えます。遊んだ人から「操作が分からない」と届いたとき、返答を作品の紹介文や遊び方に反映すれば、同じ質問は減ります。アソバースの投稿画面には、公開済みURLや本人の検証済みアップロードから紹介文と遊び方の下書きを作る機能があります。「この文章を使う」を押した場合だけ反映され、生成しただけでは公開されません。質問への答えを紹介文に取り込むときも、最終的な文面は必ず自分で読んで確かめてください。

次の行動

まず受け口を一か所だけ決め、本文で示した三点（場面、困りごと、確かめたこと）を入れた募集文を書いてみてください。質問が数件たまったら、台帳に並べて四つに仕分けます。その時点で「記事にできる」が一件でもあれば、一文化から始められます。