概要
プログラミングの学習をする際など、技術的なことなる様々な質問をすることが多いと思います。
この際、質問の方法が適切ではないと、以下のようなデメリットが発生します。
- 質問への回答が得られない
- 回答を得るために時間がかかる
- 信用を失う
今回、質問をする際に「やってはいけないこと」の事例をご紹介します。
1. 使用技術が掲載されていない
例えば、Rubyという言語であることを伝えずに、いきなりRubyのコードを張り付けて「ここがわからない」と言う質問をよく見かけます。
そうすると、回答者はまずそれが何言語で書かれているかを考える必要がありますし、別言語と考えて誤った回答をするかもしれません。
少なくても「回答者に対する配慮が足りない人」と言う印象は持たれるでしょう。
特に初学者の方は、自分が勉強している内容（特にRubyやJavaなどの言語）が、すべてのエンジニアの中での一般常識だと思う人がいます。
しかし、言語の種類だけでも山ほどありますし、そこにフレームワークやツールなど組み合わせるとかなりのパターンになります。
そのため、質問するのにあたって関連する技術内容は掲載するべきかと思います。
もちろん「Rubyに関するコミュニティ内の質問」のような特定条件下ものであれば、省略しても構わないと思います。
サンプル
悪い例
下記のputs resultがどのような動作をするのか、教えてください。
value1 = 100
value2 = 20
result = value1 * value2
puts result
良い例
Rubyのコードで質問があります。
下記のputs resultがどのような動作をするのか、教えてください。
value1 = 100
value2 = 20
result = value1 * value2
puts result
ポイント
- 悪い例では、言語の種類を記載していないため、回答者が何言語なのかを考える必要があります。今回の例ではまだ良いですが、場合によっては別言語と誤認し、誤った回答をする恐れがあります。
- 状況によっては、以下の情報もあると良い場合かと思います
- 使用しているOS（Windows、Mac、Linuxなど）
- ローカル環境、仮想環境など実行環境に関する情報
- 使用しているエディタやIDEの種類
- 良い例で記載している部分も、本来は以下の理由であまり望ましい質問ではありません（理由は後述します）。
- ネットで「ruby puts」などのキーワードで調べたりすれば、答えにたどり着くことは難しくない
- そもそも、一度動かしてみればある程度答えは分かる
- 「puts」がわからないのか「result」がわからないのか曖昧なので誤解を招く
2. 必要な情報が不足している
例えば、「エラーが発生した場合の解決方法を教えてほしい」と言う質問の場合、最低限以下のような情報の提示が必要かと思います。
① エラー内容
エラー内容は通常掲載されると思いますが、たまに面倒になるのか「エラーが出ました」で済ましてしまう方がいます。
これで回答できるのは神か預言者くらいです。
せめて、エラーメッセージやログなどのエラー内容がわかる情報は掲載するべきです。
② ソースコード（または操作内容）
簡単なエラーであれば、メッセージだけで解決できるかもしれません。
しかし、多くのエラーはソースコードや操作内容などを確認しないと、エラーが特定できません。
もちろん、すべてのコードを掲載するのは物理的に難しいとは思いますが、例えばエラーログに出ている該当箇所のソースコードくらいは、掲載するべきかと思います。
環境構築やインフラ、ツールなどの質問であれば、ソースコードではなく操作方法などがそれに該当するかと思います。
特に、「回答者の善意で成り立っているコミュニティ」の場合、回答に必要な情報が不足している場合、わざわざ「この個所のソースを見せてください」などと伝えてまで回答してくれる人は少なくなります。
提示物に自信がなければ「ほかに必要な情報があれば提示しますのでご指摘ください」のような一文があるだけでもかなり反応が違います。
③ どこまで対応したか
これも以外と漏れるのですが重要です。
例えば「●●と言うファイルが存在しない」のようなエラーが出たとして、それを質問したら回答としてはほぼ100%の確率で「●●が存在するか確認してください」と回答されます。
しかし、実際に●●が存在することは確認しており、存在しているのにエラーが出るため原因が知りたいと言うケースもあると思います。
その場合、「●●が存在することは確認しております」と記載し、確認したエビデンス（スクリーンショットなど）を提示すれば、そこに問題がないことが先にわかり、別の原因に言及することができます。
加えて、「ファイルが存在するか確認してください」→「すでに確認しました」のやり取りが発生すれば、回答者は回答する気がなくなるかもしれないですし、信用も落とすと思います。
サンプル
良い例
Rubyで計算結果を表示するプログラムを作成しています。
以下のようなエラーメッセージが表示されているのですが、原因が特定できず、解決方法をご教示いただけないでしょうか。
エラーメッセージ
C:\work>ruby test.rb
test.rb:4:in `+': no implicit conversion of Integer into String (TypeError)
from test.rb:4:in `<main>'
ソースコード
value1 = 100
value2 = 20
result = value1 * value2
puts "結果" + result
なお、ほかのrbファイルは正常に実行できているため、rubyのインストールミスでは無いと考えております。
正常に動くパターン
value1 = 100
value2 = 20
result = value1 * value2
puts result
C:\work>ruby test.rb
2000
ポイント
- エラーメッセージとコードが掲載されているため、すぐに結果にたどり着くことができます。
- 他のプログラムが正常に動いていることをエビデンスとともに示しているので、「環境構築ミス」のような可能性を最初から除外することができます（実際、「単純に環境構築ミスでそもそもプログラム実行ができない環境だった」というのは山ほど見ています）。
- ちなみに、「no implicit conversion of Integer into String」とあることから、Integer型とString型を暗黙的に結合していることが原因で、「value.to_s」のように文字列変換する必要がある、と言う回答になると思います。
3. エビデンスを提示しない
上記で例を出した「●●というファイルが存在すること」を確認した場合、それを文書で「確認しました」とだけ伝えるより、確認した結果のエビデンスを一緒に提示した方が良いです。
フレームワークなど使っているとよくありますが、実際に合っていると思っていた置き場所が間違えており、実は期待されている場所にファイルが無いということが良くあります。
その場合、「●●を確認しましたか？」→「確認しました！！」のやり取りだけだと、その間違いに気が付くことができません。
悪い例
エラーメッセージで存在しないと言われている「test.rb」と言うファイルが存在していることは確認済みです
良い例
下記の通り、「test.rb」が指定のフォルダに存在していることは確認済みです。
ポイント
- エビデンスを提示しているため、回答者からの「本当は確認できていないのではないか」と言う疑いを払拭できます。
- 万が一確認方法が誤っていた場合、回答者が気が付く可能性があります。
- Linux環境などであれば、「lsコマンド」などでの確認結果でも良いかと思います。
4. コードやメッセージを画像で張り付ける
初学者の方に多いのですが、特にコードを「画像」で張り付ける方が多いです。
このように画像で提示するのではなく、
このようにコードとしてテキスト形式で張り付ける方が良いです。
value1 = 100
value2 = 20
result = value1 * value2
puts result
slackであればバックフォートで囲んだハイライト機能や
スニペット機能などもあります。
ちなみに、画像でコードを掲載するデメリットは以下のようなものが考えられます。
- 読みにくい（特に長いコードは困難を極める）
- コードをコピーできないため、検索したり、自分の環境で試したりすることができない
- 「回答者への配慮ができない人」と言う印象を受ける恐れがある
5. 返信しない
これはコミュニケーションとしてあり得ないのですが、時々質問回答に対して、何もレスポンスしない人がいます。
特に「回答者の善意で成り立っているコミュニティ」であれば、回答者は質問に回答することで、自分の説が合っているかを確認できるメリットを期待しています。
そのため、回答に対して役に立ったかどうかのレスポンスがなければ、ただ手を動かしただけで、回答者に何のメリットもありません。
また、回答者は回答したら、しばらくは返信に備え、回答内容を忘れないように気に留めています。
一言でも「解決しました」と言われればその件をタスクから消すことができますが、それがないといつまでも頭の片隅に残ってしまいます。
さらに、例えば「●●というコードが怪しいのでそれを見せてもらえますか？」と追加情報を打診しているのに、それにも返信しない人がいます。
その人のために明らかに時間を割いており、さらにコードを見て調べてみようと思っている人に対して、何も返信しないというのは、もはや何がしたいのか私にはわかりません。
「解決したら用はない」と言うコミュニケーションをとるのは勝手ですが、そのたび人に迷惑をかけていることと、大きく信用を失っていることを忘れないでください。
画面の向こうには「人間」がいることを考えましょう。
6. 調べればわかる内容を聞いている
例えばエラーメッセージの場合、実はGoogle翻訳にかけるだけで原因がわかることが多いです。
また、インターネット検索を行えば上位の検索結果に答えが書いてあることもあります。
そのような簡単な内容をすぐに質問してしまうデメリットとして以下が考えられます。
- 自分自身の問題解決能力が向上しない
- 「自走力のない人」と言うネガティブな評価を受ける可能性が高い
もちろん、最初のうちは検索で答えにたどり着いても、それが理解できずに自分の問題に適用できないこともあります。
その場合は、到達した記事のURLは質問時に記載するべきかと思います。
7. 仮説を立てない
これは回答者が回答しやすいためと言うより、質問者の成長のために必要と考えます。
質問をする際、ただ聞くだけではなく「仮説を立てて、それが合っているかを検討する」ということを行うべきです。
仮説をたてずにただ質問するだけだと、自分自身の力にはならないので、成長ができません。
（ただ、エラーが解決するなど目の前の問題が改善するだけです）
質問時に仮説も一緒に記載するのが最も良いのですが、場合によっては自分の中だけでも良いので仮説を立てた方が良いです。
（質問コミュニティの中には、仮説を立てることをルールとしているところもあります）
また、ちゃんと仮説を立てられている人であれば、回答者から見て「わからないなりに努力できている人」という評価を得られ、ポテンシャルの高さを認められることも多いと思います。
サンプル
良い例
Rubyのコードで質問があります。
下記のputs resultがどのような動作をするのか、ご教示いただきたいです。
value1 = 100
value2 = 20
result = value1 * value2
puts result
なお、私としては「resultの内容を標準出力に表示する」という処理であると考えていますが、確証が得られず質問させていただきました。
ポイント
- 仮説を立てているため、それがあっていれば自分で解決したのに近い状態になる（実力がつく）
- ただ聞くだけではなく、可能な限り自分で考えることが重要
- 回答者から見ても、仮説があっていれば「その通りです」というだけで済む
- 仮説が間違っていれば、間違いを訂正するだけで済む
8. 質問回答への返信の途中で質問を書く
これは実際に例を見た方が早いですね。
サンプル
悪い例
先ほどは回答いただきありがとうございます。
教えていただいた方法で解決しました。
この方法は●●の場合も適用できるのでしょうか？
引き続き●●を継続したいと思います。
何がいけないのか
この方法で問題となるのは、内容が「回答への返礼」と言う属性を持っている中、途中でさりげなく質問が入っているので、読み飛ばされる恐れがあることです。
読み飛ばされないとしても、「ん？これはさらに回答が欲しいことなのか？」とよくわからない状況になることもあります。
少なくとも、回答者に対して良いコミュニケーションではないので、「配慮が足りない」と言う印象を受けてしまいます。
改善案
ではどうすればよいか
以下のように、「一通り返信を書いた後、追加で質問を記載する」と言うのが最も親切かと思います。
また、追加質問が当初の質問からかけ離れている場合は、別スレッドを立てるなどして新たに質問した方が良いかと思います。
良いサンプル
先ほどは回答いただきありがとうございます。
教えていただいた方法で解決しました。
引き続き●●を継続したいと思います。
ところで、追加質問となり恐縮ですがもう１点教えていただけないでしょうか。
この方法は●●の場合も適用できるのでしょうか？
9. 情報量が多く、整理されていない
これも、具体例を見た方が良いかと多みます。
サンプル
悪い例のサンプル
職場でCircleCIを導入しようと考えています。
CircleCIを導入する効果はどのようなものがあるのでしょうか？
また、個人的にはCircleCIでCI/CI環境を構築するメリットがわかりません。
実際にコスト削減ができた例を教えてください。
これが導入できれば、一気に生産性向上が図れれば良いなと思っています。
ただ、社内にはやはり反対派もおりまして、どのように説得すればよいか悩んでいます。
Webエンジニアとして活躍されている方の意見をぜひお聞きしたいです。
何がいけないのか
① 質問がいろんな個所に分散している
この文章を見ると、以下の３つの質問があると考えられます。
- CircleCIを導入する効果はどのようなものがあるのでしょうか？
- 実際にコスト削減ができた例を教えてください。
- ただ、社内にはやはり反対派もおりまして、どのように説得すればよいか悩んでいます。
回答者は、文章の中から質問を探し出し、それに回答する手間がかかります。
また、回答自体が漏れてしまう恐れがあります。
一つの文章で複数質問をするのであれば、箇条書き等でまとめて、できれば最初か最後にまとめるのが良いかと思います。
② 質問者の立ち位置がわからない
これは情報が不足していると言う点ですが、質問者がどれくらいの権限を持っているのか分かりません。
例えば、予算等を決める権限を持つのか、交渉相手は誰なのか、今の開発工程はどこなのか、といった点が不足しており、回答にぶれが生じます。
③ 質問なのか感想なのかわからない記載がある
以下の部分については、質問なのか感想なのかわかりません。
ただ、社内にはやはり反対派もおりまして、どのように説得すればよいか悩んでいます。
実際に質問ではなく想いとして書いているのだとしても、こういった相手を悩ませる文言は避けた方が良いと思います。
④ 最後に回答者を限定している
質問の最後に「Webエンジニア」のみの回答に限定してしまっています。
例えばサンプルのCircleCIであれば、Web系案件だけで導入されるものでもありませんし、Webエンジニアではなくコンサルティングやプロジェクトマネージャなど別視点で良い事例を持っている方も多くいます。
無駄に回答を制限して、回答を得られるチャンスを逃していますので、理由がないならあまり記載しない方が良いと思っています。
もちろん、本当に「Web系案件のみ」を「Webエンジニアの立場で導入した」と言う事例のみが知りたいのなら、記載しても良いと思います。
ただ、その場合、最後に記載するのはやめましょう。
最後まで質問を読んだWebエンジニア以外の方は落胆してしまいます（時間を返せと思ってしまいます）。
最初に、「Webエンジニアとしてかかわった事例をお聞きしたいです」のように、Webエンジニア以外の方が質問を読まなくて良いような工夫をするのが良いでしょう。
できれば、無駄にフラストレーションをためないように、「なぜWebエンジニアに限定するのか」と言う理由も簡単に書くと良いかもしれませんね。
改善案
改善案のサンプル
現在開発中のWeb系案件にて、CircleCIを導入しようとしております。
導入事例をお持ちの方がいましたら、以下の内容についてご教示いただけますでしょうか？
- CircleCIを導入する効果はどのようなものがあるのでしょうか？
- 実際にコスト削減ができた例を教えてください。
- 社内に反対派がいる中で説得したと言うような事例があれば、教えてください。
私自身は20名程度の開発チームのリーダーとして業務にかかわっています。
経緯として、私自身の知識不足もありCircleCIにどのようなメリットがあるのか、よくわかっていません。
また予算についても調整が必要で、実際にどれくらいのコスト削減が必要なのかも把握したいです。
その他、同じ部署には保守的な方が多く、それらの方にも導入を賛成してもらう必要があり、何か良い交渉材料も求めています。
ちなみに、導入を推奨しているのは役員であり、かなりの期待を込められているので可能な限り導入するか、導入しないにしても理由を報告する必要があります。
ポイント
- 最初に質問をまとめているので、場合によってはその部分をしっかり読み、後半の経緯を考慮の上回答をすることができます。
- 回答する場合も、冒頭の箇条書きにインライン形式で回答すれば良いので、回答者も楽です
- サンプルでは最初に質問を箇条書きにしていますが、場合によっては最後でも良いかと思います。しかし、「結論を先に書く」と言う考えから見れば、最初に書くのが良いかもしれません。また、「人は読むべき文章かどうかを最初の数行で判断する」ので、最初に経緯を長々と書くのは避けた方が良いです。
- 文章全体を見ればコスト削減だけに言及していて「作業ミスを減らして品質を上げられる」と言うう点が抜け落ちていますが、整理して書いているので回答者がそれに気が付き、指摘することができるかもしれません。
まとめ
何点か、「やってはいけない」事例を紹介しました。
この内容は個人的な考えではあるため、すべてのケースに当てはまるわけではないと思います。
また、他にも「やってはいけない例」はあると思いますが、際限なくなりますので今回はここまでにしたいと思います。
質問力は大変重要な「スキル」だと思います。