12
19

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

【質問術】ガチで仕事が100倍ラクになる質問テンプレ

Last updated at Posted at 2020-10-30

テンプレだけくれって思う人が大半だと思うので先に提示。
結論から書くブログがあったっていいじゃない。

#質問テンプレ

①聞きたいことの一行まとめ

②起きている問題(起きている現象の詳細/エラーコード/スクリーンショット)

③ソースコード(関連するソースコード/全ソースコード)

④問題解決するために試したこと(コードもあれば追記)

⑤問題について自分なりに考えたこと(デバッグ結果/検索結果/自分なりの原因予想)

#大問題な質問。される側も迷惑です(訳:嫌われます)
「動きません!」や「分かりません!」のような適当な質問はNG?
もしそのような自分勝手な質問しているのであれば、それは「危険信号」。

なぜならプログラミングの質問力は磨かないと学習効率が悪くなるから。

そして更に言うと、

質問力が低い人は転職後にプログラマーとして上手く成長していない人が多い。
転職も上手くいかない可能性すらある。

#最低これは絶対共有しよう!

✅コード
✅現状の問題(エラー等)
✅調べたこと
✅考えたこと

上の項目満たすことで考える力つくし、質問力が上がる。
質問力が低い人と仕事するのは大変なので転職目指している人にとっては必須スキル。

意識しよう。

#Q良い質問って何?
?端的に定義すれば、「低コストで最高の答えを引き出す質問」。

わかりやすく言えば、

回答者の負担に極力ならないけど自分が求めている情報を引き出すことができる質問ということ。

#Qなぜ質問力が必要?
理由はシンプル。

1.質問力を磨くことで問題解決能力が向上する
2.質問がちゃんとできないとエンジニアとして評価されない

1は、質問力を磨くことで「プログラマーらしい思考」ができるようになるから。
質問はプログラマーにわかりやすいように行う必要があるため、上手な質問をできる人はプログラマーらしく考えられているということだね。

2は質問が下手なプログラマーはチームの生産性を下げるから。
質問が下手だと回答者の時間をいたずらに奪いますからね。

多くの初学者は質問する際に「〇〇したら動かなくなりました」と言うことが多い。
しかし「動かなくなりました」というのは結果であり、原因を追求するのに十分な情報ではないよね。

質問が悪い場合、回答者は質問者に対して質問をしないといけない。

「エラーは何か出ています?」とか「このサイトに同じような問題の解決方法が書いてありましたが確認しましたか?」とか。このコミュニケーションは無駄です。

上手に質問できる人なら、最初に質問する段階でその情報を提供して相手の時間を奪わないように配慮できる。

#肝に銘じて
エンジニアはすごく人手不足だが、スキルがないと採用されない理由を教える。
こういう事情を知っておくと転職時に有利です

理由は「スキルがない人材は圧倒的に足手まといだから」

素人に参加されると玄人が書いたら1時間で終わるものに数日かけて、
おまけにレビューに1時間とられて損しかない。 

厳しいかもですが、フリーランスを目指すなら真摯に受け止めてmm

#実際に悪い質問と良い質問を見てみよう!

##悪い質問

〇〇というエラーが生じました。原因ご存じないでしょうか?
調べてみたのですが、全然わかりませんでした。

##良い質問

以下のコードを実行したところ、〇〇というエラーが生じたのですが、原因ご存じないでしょうか?
ユーザー登録の際にエラーが生じているようです。

原因となるコードは〇〇.rbと〇〇.rbと思われます。リンクを貼っておきます。その他のコードは development の branch で確認できます。

エラーメッセージが出ている◯行目が怪しいと思い調べました。
変数△の値が nil になっているのではないかと思いデバッグツールで確認したのですが、想定通り文字列の値が入っていました。

エラー文でググってみたところ、以下のようにstackoverflowには〇〇と書いておりました。
おそらくこの意味は〇〇だということだと思うのですが、今回の問題との関連性がいまいちわかりませんでした。

もし何かご存知であれば教えていただけないでしょうか?

良い質問は、現状を可能な限り共有しており自分が検討した内容まで記載されてる。

回答者は質問に回答する際にこれらの情報を活用することができると思う。

しかし、悪い質問をされた場合は手間でしかない。。。。

良い質問に書いている内容を逐一質問して確認する必要がありそう。
回答するのが面倒だなという印象。

#質問テンプレはこう使う!
##テンプレート活用法1. 聞きたいことの一行まとめ
質問するからには何らかの問題が発生しているはず。それを端的に表現しよう。
そして、相手に何を求めているのか簡潔に書く。
訓練しかない。頑張りなはれ

例文
チャット機能を実装しているのですが、メッセージ受信の際に問題があるので、教えていただけないでしょうか?

##テンプレート活用法2. 起きている問題(起きている現象の詳細/エラーメッセージ/スクリーンショット)
ただ、完結すぎてもわからないので、補足が必要な場合はその続きで書こう。

一度にいろいろな情報を与えられるよりも段階的に情報を与えられる方が人間は理解しやすい。詳細を書く際のポイントは、現状をちゃんと理解してもらえる内容にすること。

「エラーメッセージには△と出ております。この実装は□という機能を追加するために行っています。」

などのように現状を詳しく説明。
説明しておかないとどうせ聞かれる。

なので事前にこちらから情報を提供しておくの。

問題によって質問の仕方は変わるけど、常に「相手の時間を奪わない」ように工夫することが重要

コミュニケーションコストを下げて、相手が調べる時間を減るように工夫してね。

例文
ログを確認したところ NoMethodError というエラーが出ていました。

起きている問題をわかりやすく伝えるには以下を書くことをオススメ。

❶エラーメッセージ
❷スクリーンショット

###喜ばれる情報1. エラーメッセージ
まずはエラーメッセージを書いておくべき。

ほとんどの問題の答えはエラーメッセージに書いてる。ゆえに問題が生じた際に「エラーメッセージが何か」はプログラマーがまず気にすること。
※ HTML/CSS の場合はエラーが出ないので例外です。

なので、エラーメッセージが何かを共有しよう。

もし出ていなければ、それはそれで重要な情報なので、エラーメッセージが出ていなかった場合はその旨もしっかり伝えてね。

「エラーメッセージの見方が分からない」という人は、エラーメッセージの見方から調べて!これは非常に大事。調べて分からなければ、一番の質問テンプレに則りエラーメッセージの見方を質問してみて。

###喜ばれる情報2. スクリーンショット
場合によっては、スクリーンショットで状況を説明しよう。

特に画面の説明する際に重要。

「見た目が崩れちゃったのですが、どうすればいいですか?」とテキストだけで質問されたら「えっなんのこと??」って思うよね。
「どういうふうに崩れているのか」分からないからね。スクリーンショットを撮って共有で対処。

動きのあるものを説明したいのであれば gif を使うのも有効。コンピュータの画面から gif を作成する Kap を使うのがオススメ。

##テンプレート活用法3. ソースコード(関連するソースコード/全ソースコード)
問題と関係するコードを共有しよう。

原因調査をするほとんどの場合は実際のコードを読む必要がある。コードから問題が生じるのでコードさえ共有しておけばなんとかなる可能性が非常に高い。

コードを共有する際も相手が見やすいようにしておこう。

スクリーンショットでコードを共有する人が多いですが、正直オススメしない。。。なぜなら、見にくい上にコピペができないから。回答者に配慮のない質問方法になっちゃうよ。

コードをコピペする以外でソースコードを共有する方法は、GitHub 。
使い方は以下の記事を参考に。

https://techacademy.jp/magazine/6235


例文
※1原因と思われるソースコードの共有
エラーメッセージから middleware.rb が原因ではないのかなと思っています。
https://github.com/mc-chinju/bitflyer-api/blob/master/lib/bitflyer_api/http/middleware.rb

※2念のためにその他のコードを共有
その他のコードは Github の master branch より確認いただけます。
https://github.com/mc-chinju/bitflyer-api/tree/master

##テンプレート活用法4. 問題解決するために試したこと(コードもあれば追記)
問題解決のために試したことを共有!

これは何故重要かと言うと、

共有しておかないと時間の無駄が発生する可能性が高いから。

たとえば「〇〇という問題が起きました」と質問して「それなら△という原因じゃないかなと思いました」と回答があったとする。

しかし、すでに質問者は調査済みだった場合、「△は調べたのですが、違いました」と返答するよね。これめっちゃ無駄。返信時間も無駄ですが、回答者に「これはもしかしたら△かもしれない!!」と考えるに至るまでの時間を奪ってる。非常に無駄。

以下のようにデバッグツールなどを使って試したことを書くといいよ。
他にもコードを変更した場合にどういう変化があったのかなど書くとよい。

例文
エラーメッセージから変数 person が null だと思いました。
ゆえに debugger を用いて person の値を確認したのですが、null ではなくて Person class のインスタンスでした。

##テンプレート活用法5. 問題について自分なりに考えたこと(検索結果/自分なりの原因予想)
問題について自分なりに考えたことを書いておこう。

これは何故重要かと言うと、

考えたことを共有することで、自分が今抱えている問題を客観視できるから。

考えたことを共有するには、情報を整理する必要がある。

「〇〇という理由だと思ったので△△を調べたのですが、□□という理由で違うと分かりました」というふうに論理的に説明する必要がある。これが重要。

論理的に説明していくことによって自分が抱えている問題を追求できる。
△△が原因じゃないと断定できるので「実は●●か▲▲が原因なのではないか?」とか思いつくことも。

具体的には、ググった結果や調査した情報から考えられる原因を書くなどがよい。
原因がさっぱり分からなときは「分からない」と書いておこう。
思い当たる節が少しでもあるなら書いておこう。

これが相手のためだから。


例文
エラーメッセージに NoMethodError と出ていたので調べてみました。
インスタンスにメソッドがない場合にこのようなエラーが生じると stackoverflow に書いてありました。ですが、なぜこのメソッドがないのか理解できませんでした。
他の controller では利用できているメソッドなので不思議です。

12
19
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
19

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?