メンターを見つける方法と効果的な質問の仕方

三時間溶かしてから聞くのが、いちばんもったいない

エラーが出て、検索して、出てきた記事を上から試して、直らない。気づいたら午前中が終わっていた。そして先輩に聞いたら、三分で「それ環境変数が読めてないだけだよ」と言われる。誰にでも覚えのある光景です。

このとき失われているのは三時間だけではありません。自分で考える時間が長すぎると、何を試したかの記憶も曖昧になり、質問すらうまく組み立てられなくなります。教えてくれる相手を見つけることと同じくらい、どのタイミングで、どう聞くかが成長の速さを決めます。

十五分で線を引く

多くの現場で使われている目安が、十五分です。十五分自力で試して解決しなければ、誰かに聞く。逆に、十五分経つ前には聞かない。

前半の縛りは、自分で考える習慣を失わないためにあります。手を動かす前に聞いてしまうと、答えは手に入っても、次に似た問題が来たときにまた聞くことになります。後半の縛りは、組織の損失を減らすためです。一人で半日詰まるのは、本人にとっても会社にとっても割に合いません。

十五分のあいだにやることは、解決そのものではなく、質問できる形に整えることです。エラーメッセージを最後まで読む、どこまでは動いていたかを特定する、変数の中身を出して確かめる。これをやっておけば、仮に自力で解けなくても、聞いたときの返答の精度が上がります。

「試したこと」が無い質問は、答えるのに時間がかかる

質問の質は、才能ではなく形式で決まります。前提、起きていること、試したこと、知りたいこと。この四つが揃っていれば、相手は推測せずに答えられます。

書きながら原因に気づいて、送る前に解決してしまうことも珍しくありません。それでも、この整理は無駄になりません。自分の理解の穴がどこにあるかが、書き出すことではっきりするからです。

四つのうち、抜けると一番痛いのが最後の「知りたいこと」です。本当に困っていることを言わず、自分が思いついた解決策の使い方だけを聞いてしまうと、答えがずれます。「配列から要素を削除する方法を教えてください」と聞かれた相手は、削除の方法を答えます。ところが本当の目的が「条件に合わないデータを画面に出したくない」だったなら、元の配列を削らずに表示側で絞るほうが素直かもしれません。手段だけを聞くと、その選択肢は出てきません。最終的に何をしたいのかを一文足すだけで、前提から見直した答えが返ってきます。

二度目も答えてもらえる人になる

聞ける相手をどこで見つけるかは、社内の先輩、マッチングサービス、勉強会やコミュニティなど、状況によります。ただ、どこで出会っても続くかどうかを決めるのは同じものです。

答えをもらったら、やってみた結果を必ず返してください。「教えていただいた方法で解決しました。描画のタイミングの話が特に分かりやすかったです」の一言があるだけで、相手には「伝わった」という手応えが残ります。逆に、答えたきり何の反応も無いと、次に時間を割く気持ちは薄れます。

相手の時間を減らす工夫も効きます。コードはスクリーンショットではなくリンクやコードブロックで渡す、聞きたいことは箇条書きにする、といった小さなことです。教わるだけでなく、自分が答えられる質問には答える側に回る。この循環に入れた人のところに、情報も助けも集まってきます。