2
1

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 1 year has passed since last update.

STECH / 愛知工業大学 システム工学研究会 共同企画Advent Calendar 2022

Day 17

半年ほどメンターをして感じた答えやすい質問の特徴

Last updated at Posted at 2022-12-16

本記事は STECH / 愛知工業大学 システム工学研究会 共同企画 Advent Calendar 2022 の17日目の記事です

はじめに

 僕は Tech Select という学生向けプログラミング学習コミュニティでメンターを務めています。基本的には、学習している学生から質問が来ると答えるといったことをやっています。あーこれ僕も詰まったことあるわー的なものから、なんやこれ?? ってなる質問までたくさん回答できる機会があり、新鮮な気持ちになります。
 その質問の中でも、答えやすく感じたものと、そうでなかったものがありました。今後僕が質問する時にも役に立つと思うので、メンターやってた半年を振り返ってその違いをまとめてみようとと思います。

質問する前に

 自分がつまずいたときに、まずやるべきことは調べることです。質問の記事なのに最初に書かれてるのが自己解決かよと感じるかもしれませんが、何かで躓いたときはすぐに他人に頼ろうとせず、まず自分で解決しようとすることが一番大事です。では、どのタイミングで質問すべきかというと、15 分以上かけても解決できない場合です。Google が提唱している 15 分ルールというものがあり、これは 15 分より早く質問するのは相手の時間を無駄にし、15 分経っても質問しないのは自分の時間を無駄にするというものです。
 まぁメンター制度は質問するためのものだから、時間奪ってもいいじゃんって考えるかもしれませんが、エンジニアは調べる能力の成長が大事なんです。だからこそ、質問は 15 分掛けても解決しないときにするのがベストです。
 

質問でほしい情報

質問する際に一番もったいないやり取りは、回答者側が質問の意図や問題の原因を把握できず、質問者に質問で返してしまう時間です。質問者は再度自分が躓いている点について送信しなければならず、回答者も再度確認しなければなりません。そこで、どのような情報があれば、解決しやすかったのか、振り返ってみました

エラー情報

 エラーで動かない場合は必須です。文字で "動作しなかった" という報告のみを頂いても、原因を特定することが難しく、再度どのようなエラーが出ていたかを尋ねることになり、お互いに時間を無駄にしてしまいます。
 ちなみに、このエラーを画像でなく、テキストで送っていただけると非常に助かるなと感じることもありました。見たことないエラーだとその分を実際に検索することが多いのでコピペで調べられるとちょっと楽でした。

うまく動作していないとされるコード

 エラー文等からうまく動作していないコードの場所が推測できる場合は一緒に送っていただけると回答しやすかったです。コードでエラーが吐かれている場合はその情報がないと解決が難しいですもんね。追加で、どういう処理を実装しようとしていたか等の詳細もあったときにわかりやすいなと感じました。

解決のためにやったこと

 この情報があるととっても助かります。エラーが出た時に調べて出てくる方法を試しても解決できなかった場合があるとします。この時、試した内容を送っていなければ、質問解答者も同じ解決しなかった手法を提案する可能性があります。また、この手法で解決できないということは、このあたりに原因がありそう、と事前に推測を建てながら原因考えることもできます。

解決後

 解決できた方法が、自分にとって理解できる方法であれば問題はないですが、解決法の中で気になる点があれば積極的に聞くべきだと思います。質問する上で一番大事なことは、問題を解決することでなく、解決方法を理解することだと思ってます。その場しのぎで動作しても、理由がわかってなかったら次似た問題が発生しても躓いちゃうかもしれないです。

メンターをしている感想

 学生エンジニアの方でメンターをやってみたいと感じている方向けに、自分の感想を述べさせてもらうと、趣味の開発、チーム開発とはまた違った新鮮な学びや体験が多くでき楽しいです。また、テキスト形式でのコミュニケーションの練習もできたなと感じてます。このコミュニケーションは個人開発ではもちろん体験できないものですし、あまり知らない方とのやり取りのため知り合い同士で行うチーム開発とはまた違った体験ができます。また、常に対峙する内容がエラーやバグであるというのも興味を惹かれる方がいるのではないのでしょうか。僕は特段にエラーとの格闘が好きだ!!  って人間ではないのですが、知らないエラーを質問者と話し合いながら解決できた時は達成感があり、今後のための学びにもなったなと感じてます。
 メンターをすることで開発とはまた違った体験ができるので、この記事で興味が啜られた方はぜひやってみることをお勧めします。

おわりに

まとめるとこんな感じです。

  • 15 分は自分での解決を試みる、無理なら質問する
  • 質問は原因にたどり着くための情報を載せる
    • エラーの出力
    • ソースコード
    • 解決のために試した方法
  • 解決しても納得するまで質問する

 自分もまだまだ技術者として未熟な人間なので、これからたくさん質問する機会があると思ってます。だからこそ、このようなメンターをする機会を頂き、質問される側を体験できたことは非常に貴重な機会だったと思っています。この記事の内容が参考になれば幸いです。

2
1
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
2
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?