クレジット
タイトル: フォーラムで質問するまえに読み返してほしいエッセイ
著者:
Tark_IOL
作成年: 2022
はじめに
『分からないことがあったら何でも質問してね!』
これは、新人さんなら誰もが聞く言葉ですね。しかし、質問の仕方──どのように質問をしたら相手からより良い回答を引き出せるのか、ということを知る機会はあまりないでしょう。このエッセイでは、友人や先生に質問するときとはちがう、SCP-JPにおける「質問」について紹介します。フォーラムで質問するまえにはぜひこのエッセイを思い出してください。
もし、あなたが質問で失敗をしてここにやって来たのであれば、自分のやり方・ふるまいのどこに問題があったのかを考える手がかりとして、このページを活用してください。
前提として、以下をご理解ください。
- このエッセイは質問をするにあたって他のサイトメンバーから回答をより引き出しやすくするためのエッセイです。
- このエッセイは役立つ回答がポストされることを約束するものではありません。あなたの問題が解決することを私は祈っていますが、上手くいかないときもあるでしょう。
- このエッセイは初心者を意識して執筆されています。後述の内容に関連する話として、ある程度の活動経験がある方であれば、望む答えを引き出すために検索ボックスにうち込むと良い単語のいくつかは容易に思い浮かぶでしょう。
- これはガイドではなく、エッセイです。このエッセイに他人を誘導してくださることは幸いですが、この記事の内容を基に他人、特に初心者に高圧的にふるまうのは控えてください。
0.コミュニティは助け合いの場です
確かにサイトメンバーの多くは新人の助けになりたいとは思っていますが、質問に答えるかどうかはメンバーの自由です。ですから、失礼な質問、何を聞いているのかよくわからない質問は答えてもらえないことが多くなります。そのことで相手に文句は言うことはできません。
まとめ: 質問に答えるかどうかはメンバーの自由です。あなたを助けたくなる質問文を書きましょう。
1.ルールにしたがい、マナーに気を使いましょう
以上のガイドラインは「最低減守らなければならないルール」です。そのため、そこにダメと書いていないことであっても、相手に迷惑であったり、自分勝手なふるまいをすべきではありません。フォーラムでは一対一で話をしていると思っていても、たくさんの人がそのやり取りを見ています。
問題を解決しようとあなたに協力してくれている相手には、あなたもできる限り協力しましょう。あなたはここでは一人の大人として見られていますから、学校の生徒のように受け身であってはいけません。
まとめ: 相手に迷惑であったり、自分勝手なふるまいをすべきではありません。協力してくれる相手にはあなたも協力しましょう。
2.質問する前に自分で調べ、試しましょう
SCP-JPではこれまでの積み重ねによって、さまざまな場所にアドバイスが残されています。質問して回答を待つのも時には必要ですが(八方ふさがりの時は特に!)、まずは調べてみましょう。
初心者の場合は、ガイドハブやお役立ちリンク集に載っているガイドやエッセイを調べてみると良いでしょう。SCP-JPでの活動における問題への多くの答えはここに用意されているはずです。時には落ち着いて読み返しましょう。いざ質問したら簡単な見落としを注意されるかもしれません。
SCP-JPのメインサイトやDiscordではもちろん検索機能を活用することができます。しかしこれらを利用するのは活動に十分に慣れた時まで待っても良いかもしれません。ほしい答えを呼び出すために打ち込むべき言葉をあなたは知らないはずです。
また、Wikidot構文に関する初歩的な質問には、「構文をコピペしなおしたら動いた」「調べたら書いてあった」といった、実は自分の手ですぐ解決できる質問が常に多いものです。
- ガイドハブ - もしかするとあなたの質問は基本的なことかもしれません。SCP-JPで運用されているガイドラインの一覧はこちら。
- お役立ちリンク集 - 他のサイトメンバーに伝えたいことをまとめたエッセイやデータベースへのアクセスはここから。執筆の方法論の他にも、アノマリー分類ガイド(ACS)などの構文コンポーネントやフォーマット集、特殊オブジェクトクラスやK-クラスシナリオなどをまとめたリストまで。
- Wikidotシンタックス - よく使う構文について。ここに答えが書いてあるような質問はすべきではないでしょう。
- 日本語表現用Wiki構文拡張スタイル - 縦書き、ルビなど日本文芸的な表現をしたいとき。
- 難解Wikidot構文 - SCP-JPでよく使われるちょっと便利な構文たちについて。単一ページ遷移構文や多重折りたたみなどなど。
- SCPスタイルリソース - 色んな記事で見かけるしかけたちのテンプレート集。カッコイイヘッダー、画像カルーセル、ログイン/ログアウトフォーマットなどなど。
- 第一回SCP-JP構文調査 - SCP-JPサイトメンバーが「ちょっとほしいな…」と思って作った(作ってもらった)構文がまとめられています。もしかするとあなたがほしかったものがここにあるかもしれません。
まとめ: 質問する前にまずは調べましょう・試しましょう。
3.相手に届くタイトル/はじめの文を書きましょう
きちんとあなたの質問を解決できる人に届けるためには、タイトルと概要文にて、その質問について具体的に、しかし簡単に書いておくことが大事です。概要文は一覧から見える情報の中では一番分量が多いので、必ず活用してください。
- 質問についての説明: 本文の要約
- どのような人からの手助けがほしいか: SCP・Tale・GoIF記事を書いた経験、翻訳した経験、Wikidot構文を操れるレベルなど
まとめ: 他人が読んで実際の問題が予想できるタイトルと概要文を書きましょう: 本文の要約を意識してください。
4.相手に状況が伝わる本文を書きましょう
「この質問文で、何も知らない相手に分かってもらえるか?」と、投稿前に質問文を見直してみましょう。解決の上で注意すべき点などの前提を相手に伝えていなかったために、提案がムダになってしまうことや、両者が一から十まで説明しなくてはいけないことは、よく聞く話です。
質問の前に調べたこと・試したこと、その結果分かったことは必ず書きましょう。他にもどのページを参考にしたのか書いておくとなお良いでしょう。
問題が起きるまで順番がある場合は、そこにたどり着くまでの流れをくわしく書くべきです。あなたのやり方や考え方にありえないミスがあっても、多くの場合、あなたは分かっていません。
あなたの目的を達成するために必要な方法はあなたが考えている一つだけではないかもしれません。より良い解決方法を引き出すためにも、質問の動機や目的を書いておくべきです。その目的を設定した背景までしっかり書けていると、回答者が色んな解決案を教えてくれるかもしれません。
Wikidot構文についての質問のときは、問題が起きているページのURLを必ず書きましょう。口で説明するより、現場を見た方が早いものです。いつから問題が起きたのか分かるようにページリビジョンも書いておきましょう。リビジョンと編集履歴はページ下部の「履歴(History)」から確認することができます。
質問によっては以下の定義に当てはまらない情報もあるでしょう。そういうときは、「他人が読んでも、あなたの希望と状況が分かる」文章を目指してください。
一般的な質問
- 質問の背景
- 質問の動機・理由・目的
- (問題が起きているページ)
- ここまで調べたことや試したこと
- 調べた上で疑問に残ったこと
構文についての質問
- どういうことを実現したいのか
- 上記の動機・理由・目的
- あなたが実現したい機能を再現できる構文を募集するとき: 思い描いている動きとデザイン、設置先の記事のあらすじ・実際の記事(できればURLを書くこと)
- 構文が思った通りに動いていないとき: 思っていた動き・デザイン、実際の動き・デザイン、問題が起きている下書きのURL、どのような操作と思考の流れで問題が起きたか
- 構文が思った通りに動いていないとき: 問題が起きているページとそのページリビジョン
- ここまで調べたことや試したこと
- 調べた上で疑問に残ったこと
「分からないことが分からない」というがんじがらめはしばしば起きることです。この「わかる/わからない」のグラデーションには大まかに5つの段階があるとされています。この段階に合わせて、質問フォーラムに書くことを整理してみましょう。
全部わかっている
そんなあなたは質問フォーラムに用事はないはず。
わからないことがわかっている
どこにつまづいているのか言語化できている人はここです。
上で書くと良いと言われている情報をできる限り整理して、質問フォーラムに行きましょう。
わからないことがわからない
とりあえず調べた結果、それっぽいアドバイスを見つけたけど、まだもやっとしていてなんだかよく分からないという人はここです。
以下の情報をできる限り整理して、質問フォーラムに行きましょう。分かりやすく言えば、やりたいこと、やりたいことを実現するためにつまづくまでに思っていたこと、どこまで分かった・できたかを書いてください。
- 一般的な質問
- 質問の背景
- 質問の動機・理由・目的
- (問題が起きているページのURL)
- ここまで調べたことや試したこと
- 構文についての質問
- どういうことを実現したいのか
- 上記の動機・理由・目的
- 構文が思った通りに動いていないとき: 思っていた動き・デザイン、実際の動き・デザイン、問題が起きている下書きのURL、どのような操作と思考の流れで問題が起きたか
- ここまで調べたことや試したこと
わからないことがわからない状況を何とかする方法を知らない
一覧を見たもののどのガイドを参考にしたらいいのか見当もつかないあなたはここです。
以下の情報を言語化にできるか、抱えている問題に関係する言葉を知らないか、もう一度確認してください。もしできたら、ガイドハブやお役立ちリンク集から関連しそうなガイドやエッセイを探しましょう。それでもできなかったら質問フォーラムで聞いてみましょう。
- 一般的な質問
- 質問の背景
- 質問の動機・理由・目的
- (問題が起きているページのURL)
- 構文についての質問
- どういうことを実現したいのか
- 上記の動機・理由・目的
「わからない」ことにレベルがあることを知らない
まずは上の項から始めましょう。
参考文献: 質問時に大切にしているポイント>レベルに応じた質問内容
とはいえ、長すぎる文章では読むのをいやがられていまいます。必要・重要なところだけをおさえた分かりやすい文章を目指したいものです。
まとめ: 具体的で読みやすい本文を目指しましょう。
5.回答が来たとき気を付けること
回答が返ってきたらありがとうの気持ちを伝えましょう。
解決したのであれば、そのことをはっきり伝えましょう。そして、タイトルに【解決済】と一言そえておきましょう。もし回答をもらってあなたの努力の結果、解決したのであれば、その努力の流れを返答の文の中に書くのも良いでしょう。
一回の回答で解決できなかったときも返答の文を書きますが、このときはあなたがどこでつまづいているのか説明しなければなりません。でなければ、相手はどう工夫して説明しなおしたらいいのか分からなくなってしまいます。
一般的な質問
- 回答を読んだ上で疑問に残ったこと
- 回答を読んだ結果、途中までは分かった場合: なぜそう思った・分かった・考えたか
構文についての質問
- 回答をもらった上で再度つまづいた点
- つまづくまでの流れ
- 回答を読んだ上で疑問に残ったこと
- 回答を読んだ結果、途中までは分かった場合: なぜそう思った・分かった・考えたか
まとめ: 回答にはありがとうの気持ちを、そして未解決の場合はどこにつまづいたのか伝えましょう。
6.他に気を付けること
同じ質問を色々な場所でしないようにしましょう
一般的に回答を書き上げるまでにはそれなりに時間がかかります。やっと回答文ができたと思ったら、別の場所で解決していたというのは、回答者にとって一方的に時間がうばわれたことになります。
まとめ: 同じ質問を色々な場所でしないようにしましょう。
本題のない質問はやめましょう
本題のない質問というのは「質問してもいいですか?」や「構文にくわしいひとに聞きたいことがあります」などといった質問のことです。誰でも答えられるはずの質問に、("私のスキルは足りないだろう"とみんなが考えて)誰も答えてくれないという悲しい結果を招きます。
まとめ: 「私の話を聞いてほしい」と頼むのではなく、ただあなたの抱えている問題を伝えてください。
ネガティブな受け答えはやめましょう
自分のスキルが思ったよりぜんぜん足りないとき、ネガティブな気持ちになることは誰にでもありますが、言葉にだすのはやめましょう。あなたの相談に乗ってくれているサイトメンバーのやる気や親切心がしぼんでしまいます。
まとめ: 自分の実力が無くてもネガティブな言葉は口に出さないようにしましょう、相手の親切心・やる気をしぼませます。
感情的に言い返してはいけません
相手のアドバイスがあなたにとって受け入れられないことだったとしても、感情的になって言い返してはいけません。そのような言葉を使いかけたら、一度落ち着いてから相手の文を読みなおしてみてください。それでも相手の言葉があまりにとげとげしいと感じたのであれば、サイトスタッフにこっそり相談してください。まちがっても相手に直接怒ってはいけません、ケンカになった場合あなたにメリットは一切ありません。
敬語にありがちなこととして、落ち着いて書いているのにけんか腰に見える文章もあります。投稿前に読みなおしてみましょう。
注意されたことがわからなくてもとりあえずごめんなさいとあやまる、そんな気の弱い人も中にはいるかもしれません。しかし、行動がなおらなければ、それは反省しておらず、自分の行動を良くしようとする気持ちがないものだと、ほとんどの人は考えています。
なぜ注意されたのかよく分からない時は、注意してくれた人に聞いてみましょう。教えてくれるはずです。
まとめ: 返信するまえに一度文章を読みなおしてみましょう: 感情的に反応してはいけませんし、敬語は落ち着いてていねいに使いましょう。
一連の問題に対しては一つのスレッドのみ使いましょう
一連の問題にもかかわらず、また質問ができたからといって新しくスレッドを作ることはやめてください。このとき、問題の全体像や背景を調べ直す、聞き直す手間がまたかかってしまうので、時間のムダです。
ちなみにこの行動はage行為・スパム的行為であり、程度によってはサイトルール・ディスコードのルールで禁止されている・しないほうがよい、とされている行動とみなされるかもしれません。追加の質問を行う際は、メインサイトにおいては概要文にそのことを書くなど工夫すると良いでしょう。
まとめ: 一連の問題に対しては一つのスレッドのみ使いましょう
構文の作成を頼むときは具体的に
※この項はどちらかというと中堅以上むけの内容になっています。しかし以下の内容を理解できるようであれば、構文のオーダーメイドのハードルがぐっと下がることはまちがいありません。
構文の作成を頼むとき、あなたと構文を書いてくれる人の間で、完成イメージが大きく異なっていると、構文の作成に大きな苦労をすることになってしまいます。そういった事例をさけるために、相手には具体的な説明をこころがけましょう。
どうしても難しい言葉づかいになりますが、以下のような情報があるとすり合わせが楽になります。
- 構文の使用目的(その構文を設置することでそのような気持ちを読者にひき起こすか)
- 思い描いているデザイン
- クリック・マウスオーバーなどでページに変化を引き起こすとき: 思い描いている動き・機能(ページの遷移・タブの開閉・イラストの動作など)
- クリック・マウスオーバーなどでページに変化を引き起こすとき: それぞれの動き・機能が連携・分岐するのであれば、その順番/流れ
- 上記のデザインや変化、つまり機能についての設置目的・使用目的
基本的にあなたのふんわりとしたイメージは伝わりません、言語化しましょう。また、できればモックアップや完成イメージを用意してみましょう。もし既存の何かを再現・模倣したいというのであれば、それが分かるURLを伝えるとベストです。
例えば…私が以前、いつもお世話になっている方に構文の作成を依頼した際に、提示した情報をそれぞれ整理すると以下のようになります。
構文の使用目的:
- 機関リポジトリのデザインを再現することで、読者に学術機関のウェブサイトから論文を読んでいる空気感を味わせたい
思い描いているデザイン:
思い描いている動き・機能:
- テーブルは論文の情報(形式や作成者、言語、掲載誌等々)を記載する場所である
- テーブルは使用者によってテーブルの個数や内容を適宜変更することができる
- テーブル内に単一ページ遷移構文のリンクを設置し、本文に移動させる
完成した様子は実際の記事を参照してください。構文についてはページソースか、ディスカッションの解説ポストをご覧ください。
まとめ: 構文の作成を頼むときは完成形をくわしく言語化・画像化して共有しましょう。
7. 回答者の立場こそ思いやりを
ここまで読んでいただいた中堅以上のサイトメンバーの中には、間違ったことを言ったら迷惑だから回答しないでおこう……という人もいるでしょう。しかし新人のみなさんの勇気を受けて、回答を返してあげたいと思っているすばらしい人がいることも私は知っています。
回答者の立場に立ったとき、常に持っていていただきたいのが「思いやり」です。特に以下の点に注意すべきでしょう。
- 相手の知識・技能レベルに合わせた回答をしましょう
- 同じ議題について話している場合でも、定義や前提が異なるために議論がすれちがうことがあります: すり合わせをするときは押しつけにならないように・もしかしたらあなたの前提には誤謬が含まれるかもしれません
- 価値観に基づく主張なら、相手の価値観を尊重した上で妥協点を探しましょう
- 上から目線を避けましょう: 内容の平易化・敬意をこめた表現の使用・意図せず人格/価値観/知性に対する攻撃になる表現の回避、が効果的です
これらの内容は『より良いディスカッションの為に』を参考にしたものです。価値観の異なる相手との会話のとき、このエッセイは大変有益な視点を与えてくれます、特に新人さんと向き合う前は読んでおくべきです。同様の観点では『批評に関するポリシー』を読みなおすことも大事でしょう。
おまけ: 良い質問の例
タイトル:
他の人の記事を編集してしまいました
概要:
編集で中身を開いて構文を見ていたのですが、まちがえて保存してしまいました。もどすにはどうしたらいいでしょうか。
本文:
自分の下書きを書いているなかで、以前読んだ記事の構文の演出がステキだなと思い、編集ボタンを押して中身を見ていたのですが、作業中にまちがって保存ボタンを押してしまいました。その結果、ページのレイアウトがくずれてしまいました。 - (質問の背景)
なんとか前にもどしたいと思って、WIkidotの使い方エッセイから「History(履歴)」なる機能を見つけたのですが、他の人の記事でこれをさわっていいのでしょうか。 - (質問の目的・質問前に調べたこと・調べた上で疑問に残ったこと)
また、こうした場合、サイトスタッフや著者さんに連絡したほうが良いのでしょうか。 - (調べた上で疑問に残ったこと)
その記事は下のURLのものです。
ページのURL - (問題が起きているページ)
今回の例は、他人の記事の構文をコピーするために編集ボックスを開いたら編集してしまってそのまま保存もしてしまった!という初心者にありそうな失敗です。
この文では、質問するにあたっての背景について説明し、起こしてしまった失敗の解決方法についてたずねています。幸い自分で「リビジョンの差しもどし」機能を発見できたようですが、実際の作業に当たっての注意点を聞きたいようです。
この質問者は、第4章で紹介したグラデーションで言えば「わからないことがわかっている」段階です。質問の背景、調べた結果分かっていること、その上で分からないことまでしっかりかけている本文ですね。質問者としては実際に問題が起きているページにアクセスしなくても問題を解決できるぐらいには状況がよく書けているので、完成度は十分でしょう。
私としては差しもどした後にページのディスカッションや著者のPMに一言入れてくれれば十分なのではないかなと考えています。なお、この質問者が参考にしている『Wikidotの使い方エッセイ』では、ページを編集してしまう危険性なしにページを観察できる「ページソース」という機能も紹介されているので、恐らく回答者は回答時にページソースについても説明してくれることでしょう。
タイトル: 説明通り構文を入れたのですが出てきません
概要: ガイド通りに構文をコピペしたのですが、「インクルードを行おうとしたページ、 component:xxxxxxは存在しません」と出てきます。サンドボックスではこの構文は使えないのでしょうか。
本文:
サンドボックスⅢ上でシリーズ-JP『████』のフォーマットを使いたくてコピペしたのですが、「インクルードを行おうとしたページ、 component:xxxxxxは存在しません」と出るだけで、実際にはフォーマットが出ません。- (質問の目的・質問の背景)
コピペミスかなと思ってコピペしなおしても出ませんでした。以前、サンドボックスⅢの構文が邪魔になって構文が動かないという下書きをみたことがあるのですが、今回も同じようにサンドボックスⅢでは動かない構文なのでしょうか。 - (質問前に調べたこと・調べた上で疑問に残ったこと)
以下がその下書きのページとハブのURLです。
下書きのURL - (問題が起きているページ)
ハブのURL
今回の例はインクルード構文で別のページの要素を呼び出そうと思ったが思い通りにいかなかったというあるあるな失敗です。今回はエラーメッセージが表示されるタイプの問題です。回答者としてはエラーメッセージを書いてもらえると、実際のページを調べてみる前に問題の概要をおおよそつかめます。エラーメッセージがでないときは、言葉を尽くして説明することで、問題を解決できそうな人に気づいてもらい、やはりURLを貼って実際の現場を見てもらうほかないでしょう。
この質問者は、第4章で紹介したグラデーションで言えば、「わからないことがわからない状況を何とかする方法を知らない」に相当する段階です。しかしエラーメッセージを含め質問の背景がしっかりと書かれているので、回答者としては解決すべき問題がほとんど分かっているという良い状態でしょう。
[[include component:XXXXXX]]
さて、上のようなインクルード構文はinclude以下に記載されたページからそのページの要素を持ってくるという動きをしますが、サイトを指定しない限り同じサイト内(つまりここではサンドボックスⅢ)の指定されたページ名から持ってくるものを探してきます。この質問の場合、呼びだしたいページはメインサイト(SCP-JP)に存在するため、以下のようにサイト名を指定しなければならなかったんですね。
[[include :scp-jp:component:XXXXXX]]
実はWIkidotシンタックスの他のページを埋め込むで紹介されている要素ですが、見出しと説明内容がいまいちリンクしておらず、ページの内容を覚えていないという人も多いでしょう。
おまけ: チェックリスト
質問前チェックリスト
-
そのタイトルと概要文は、他人が読んで実際の問題が予想できる文章ですか?:本文の要約ができていますか?
そのタイトルと概要文は、他人が読んで実際の問題が予想できる文章ですか?:本文の要約ができていますか?
-
あなたのやりたいこと/抱えている問題の状況が分かる、具体的で読みやすい本文になっていますか?: 例えば以下のことはできるだけ書いてありますか?
あなたのやりたいこと/抱えている問題の状況が分かる、具体的で読みやすい本文になっていますか?: 例えば以下のことはできるだけ書いてありますか?
-
ここまで調べたこと・試したこと: 参考ページのURLも一緒に
ここまで調べたこと・試したこと: 参考ページのURLも一緒に
-
調べるとっかかりも分からないとき: あなたの希望・要望(やりたいこと)をできる限り言語化して伝えてください
調べるとっかかりも分からないとき: あなたの希望・要望(やりたいこと)をできる限り言語化して伝えてください
-
「私の話を聞いてほしい」と頼んでいませんか?: ただあなたの抱えている問題を伝えてください
「私の話を聞いてほしい」と頼んでいませんか?: ただあなたの抱えている問題を伝えてください
-
構文の作成依頼のとき: 完成形をくわしく言語化・画像化して共有できていますか?
構文の作成依頼のとき: 完成形をくわしく言語化・画像化して共有できていますか?
返信前チェックリスト
-
解決したとき: 解決したことを伝えましょう、タイトルにも【解決済】の一言を
解決したとき: 解決したことを伝えましょう、タイトルにも【解決済】の一言を
-
アドバイスを受けて自分の努力で解決したとき: その努力の流れをぜひ伝えてください
アドバイスを受けて自分の努力で解決したとき: その努力の流れをぜひ伝えてください
-
よく分からなかったとき: 「分からなかった」だけでなく、つまづきポイントと「分かった」ところをくわしく伝えていますか?
よく分からなかったとき: 「分からなかった」だけでなく、つまづきポイントと「分かった」ところをくわしく伝えていますか?
-
感情的に反応していませんか?: 敬語は落ち着いてていねいに使いましょう
感情的に反応していませんか?: 敬語は落ち着いてていねいに使いましょう
-
ネガティブな言葉を使っていませんか?: 相手の親切心・やる気をしぼませます
ネガティブな言葉を使っていませんか?: 相手の親切心・やる気をしぼませます
-
参考文献(外部サイト)
このエッセイは@yamad365著『コミュニティ等で質問する際に覚えておいてほしいこと』に大きな影響を受けて執筆されています。この場で氏に最大限の感謝を。
また、このエッセイがまだ優しい内容だなと感じた方がいれば、以下の参考文献に直接あたるのもよいでしょう。
参考文献(SCP-JP)
協力者
以下は、本エッセイに生かされた、参考文献とテクニカルスタッフ特有の視点を授けてくださった方々です。R74さんにはチェックボックス構文の作成もお願いしました。
批評者
クレジット
タイトル: フォーラムで質問するまえに読み返してほしいエッセイ
著者:
Tark_IOL
作成年: 2022