メンターになるには、どんな条件が必要ですか？
まだ学習中の言語でも、メンタリングできますか？
複数の言語でメンタリングできますか？
キューにあるすべての解答をメンタリングすべきですか？
解答が何日も、何週間もキューに残っている場合はどうすればよいですか？
その解答について提案することが何もない場合はどうすればよいですか？
一度も解いたことのない演習をメンタリングしてもよいですか？
解いたことはあるけれど、別の言語で解いた演習をメンタリングしてもよいですか？
一度目を通した解答は、必ずメンタリングしなければなりませんか？
何度説明しても学習者が理解してくれない場合はどうすればよいですか？
自分の提案に対して学習者が防御的になったときは、どう対応すればよいですか？
自分が間違っていると思っていても、最後の判断は学習者に任せるべきですか？
提案はどう表現するのがいちばんよいですか？
コードの整形、コメント、命名規則を守るよう指導すべきですか？
メンターになるには、どんな条件が必要ですか？
メンタリングするのに、その言語のエキスパートである必要はありません。
自分がメンタリングする相手よりも、ほんの少しだけ初心者を卒業していれば十分です。
解答の中に、別のやり方で書けそうだと思う箇所があれば、それを提案してみましょう。
必ずしも_より良い_やり方である必要はなく、その言語でよく使われる別の書き方であれば十分です。
提案を取り入れるかどうかを決めるのは学習者ですが、少なくとも選べる選択肢は増えます。
まだ学習中の言語でも、メンタリングできますか？
理想を言えば、すでに知っている言語でも、学び続けることに終わりはありません。
言語によっては、数週間から数か月ごとに新しいバージョンが公開されます。
新しく学ぶべき言語機能が増えるだけでなく、まだ知らない既存の機能が残っていることもあります。
学習者が使った機能を見て、それが初めて目にするものだということもあるでしょう。
ですから、メンタリングは言語についてもっと学ぶよい機会になります。
複数の言語でメンタリングできますか？
無理なく対応できると感じるだけの数の言語で、メンタリングしてかまいません。
得意な言語を複数担当しても、学習中の言語を担当してもかまいません。
キューにあるすべての解答をメンタリングすべきですか？
その時点で、ある解答について中身のある建設的なコメントが思い浮かばないのであれば、そのメンタリングのリクエストは別のメンターに任せたほうが、学習者のためになることがあります。たとえ返答までの待ち時間が長くなったとしてもです。
解答が何日も、何週間もキューに残っている場合はどうすればよいですか？
学習者が答えられない具体的な質問をしている場合は、その質問に答えられる人に任せたほうがよいでしょう。
そうでなければ、その解答は、自分にとって難しかった演習のものかもしれません。まだ解いていないか、解いたけれどあまりうまく解けなかったと感じている演習です。
その場合は、解答をじっくり見て、学べるものがないか探してみましょう。
何か学べたなら、その解答から具体的に何を学んだかを添えて、学習者にお礼を言うとよいでしょう。
あるいは、学習者に解答の説明をお願いしてみるのもよいでしょう。
いわば「逆メンタリング」ですが、丁寧に敬意をもってお願いすれば、喜んで説明してくれる学習者もいます。
そのうえで、別の方法を検討したかどうか、なぜその方法を選んだのかを尋ねてみましょう。
あるいは、解答全体は理解できなくても、指摘できる点がいくつか見つかるかもしれません。
たとえば、関数の仮引数にnやmだけを使っているなら、意味のある名前を付けることを提案できます。
どれもしっくりこない場合は、そのリクエストを未回答のままにしておいてかまいません。
メンタリングは任意の活動です。
ある言語のメンターだからといって、その言語のすべての演習をメンタリングしなければならないわけではありません。
その解答について提案することが何もない場合はどうすればよいですか？
解答の気に入った点を伝えるだけでもかまいません。
実際、解答のどこが具体的に良いと思うかを伝えるのは、どんなメンタリングのやり取りでもよい出だしになります。
そうしたあとで、演習への別のアプローチについて提案がなければ、学習者に「よくできました！」と伝えるだけで十分です。
学習者が複数のイテレーションを提出している場合は、最新のイテレーションがどこで改善されているかを指摘できるかもしれません。
一度も解いたことのない演習をメンタリングしてもよいですか？
学習者の解答を見て、自分もその演習を解いてみたくなることがあります。特に、その解答で使われている方法が、これまでに考えたどの方法よりも演習を簡単に見せてくれるものだった場合はなおさらです。
演習を解き終えたころに、きっかけとなったメンタリングのリクエストがすでになくなっていても、少なくとも次に備えることはできています。
解いたことはあるけれど、別の言語で解いた演習をメンタリングしてもよいですか？
ある言語で慣用的な書き方が、別の言語でもそうとは限りません。そのため、メンタリングする言語で演習を解いておくのがいちばんよいでしょう。
2つの言語の解答がよく似ていて、それぞれで何が慣用的かを判断できるほど両方の言語に詳しければ、一方の言語の解答をもう一方に置き換えるのはそれほど時間はかかりません。
解答を置き換えているうちにメンタリングのリクエストがなくなっていても、少なくとも次に備えることはできます。
一度目を通した解答は、必ずメンタリングしなければなりませんか？
解答を見て、いくつかの理由からメンタリングしたくないと気づくことがあります。たとえば、次のような場合です。
- 学習者の質問に答えがわからない。
- コードが冗長だったりわかりにくかったりして、どこから指摘すればよいかわからない。
- コードから、その学習者がまったくの初心者で、多くの基本的な助言が必要だが、そこに割ける時間も忍耐も自分にはないとわかる。
- 学習者のコメントから、やり取りが不快だったり面倒だったりしそうだと感じる。
そのメンタリングのリクエストが自分向きではないと思ったら、「メンタリングを開始」ボタンを押す義務はありません。
何度説明しても学習者が理解してくれない場合はどうすればよいですか？
学習者が、まるでわざと理解しようとしないかのように見えることもあるでしょう。
自分が知っている説明の仕方をすべて出し切ったと感じたら、その議論を切り上げて、学習者にメンタリングのリクエストを出し直すよう提案してもよいでしょう。そうすれば、難しい点をよりうまく説明できる別のメンターが担当できます。
自分の提案に対して学習者が防御的になったときは、どう対応すればよいですか？
学習者が、わざと回りくどい方法を使ったのは、言語の機能をもっと学びたかったからだと説明することがあります。たとえその機能が演習にいちばん適しているわけではなかったとしてもです。
Exercismは学習のためのプラットフォームであり、競技プログラミングのサイトではありません。そのため、いちばん洗練された、あるいは効率的な方法を使わないことには、十分な理由があります。
その方法をもっと慣用的に書けたはずだと気づいたなら、その方法の使い方について提案してみましょう。
いずれにしても、フィードバックをもとに別のイテレーションを提出するか、メンタリングの枠を空けるために議論を終えるかを提案できます。
学習者が、その言語や演習にいちばん適しているとは言えないプログラミングパラダイムにこだわることがあります。
たとえば、常にオブジェクト指向パラダイムを使いたがり、比較的シンプルで素直な解答を、多数のメソッドを通る迷路のような制御フローを持つ、小さなクラスの爆発に細分化してしまうことがあります。
学習者がそのパラダイムを教条的に信奉しているほど、別のアプローチを説得しようとしてもたいていは実を結びません。
試してみることはできますし、提案に応じてくれるかもしれません。しかし、学習者が頑ななら、次に進むのがいちばんよいでしょう。
学習者が提案をきっぱり断ることもあります。
たとえば、mapとjoinの代わりにreduceを使うことを提案できます。reduceなら繰り返しが1回で済みますが、mapとjoinではmapで1回、joinでもう1回と、2回の繰り返しが必要だからです。
しかし、mapとjoinのほうが読みやすいという理由で、学習者がそれを断ることもあります。
mapとjoinのほうがreduceより読みやすいこともある、と学習者に同意してかまいません。
慣れる時間が増えればreduceにも親しめるようになると提案できますし、mapとjoinを使うことに_問題がある_わけでもありません。
学習者が正しい部分については同意してかまいませんし、学習者が抱いている誤解や誇張を正そうと試みてもかまいません。
自分が間違っていると思っていても、最後の判断は学習者に任せるべきですか？
たとえば、Clockの演習を解くときに、60や24のようなマジックナンバーを使わず、意味のある名前を付けた定数として定義するよう提案したとします。
学習者は、この文脈なら60や24が何を表すかは明らかだと答えるかもしれません。
提案はすでに伝え、学習者はそれを退けたわけです。
そこで言い争っても得るものはなく、かえって信頼を損ねるだけかもしれません。
提案はどう表現するのがいちばんよいですか？
必ずしも_より良い_とは限らないものを別案として提案するときは、前置きとして「別の方法としては、〜というやり方もあります」と添えるとよいでしょう。
たとえば、「別の方法としては、everyとincludesを組み合わせて使うやり方もあります」のように書きます。
解答で学習者が使っていない言語機能（everyやincludesなど）を紹介するときは、それを説明しているドキュメントへのリンクを添えるとよいでしょう。
提案の前置きとして「〜を検討してみてはいかがでしょうか」を使う方法もあります。
たとえば、「split()の代わりにスプレッド構文を使ってみてはいかがでしょうか」のように書きます。
学習者にぜひ別の方法を使ってほしいと強く思うなら、「いかがでしょうか」を外して「〜を検討してみてください」で始めてもよいでしょう。
たとえば、「デフォルト引数の使用を検討してみてください」のように書きます。
提案をいくつか並べるときは、それぞれの導入の言い方を変えるとよいでしょう。
解答の気に入った点を挙げるには、箇条書きが効果的です。
一方、提案を並べるときに箇条書きを使うと、よそよそしい印象を与えることがあります。
カジュアルで会話的な言い方で提案すると、学習者にとって検討しやすく、受け入れやすくなります。
提案するときに使わないほうがよい言葉の1つが「〜すべき」です。
たとえば、「デフォルト引数を使うべきです」のように書いてしまいます。
「〜すべき」「〜しなければならない」といった言葉は、押しつけがましい印象を与えかねません。
コードの整形、コメント、命名規則を守るよう指導すべきですか？
コードの整形やコメント、命名規則といったことを、いつ、どれくらい強く指摘するかについては、メンターの間でも意見が分かれるでしょう。
一方では、Two Ferのような演習の早い段階で、悪い癖が付く前にこうしたことを考えてもらいたいと思うかもしれません。
あるいは、あれこれ作法を押し付けて初心者を萎縮させたくないと思うかもしれません。
他方、より高度な演習に取り組む学習者は、規約をすでに知っていて、目の前の課題に集中するためにあえて無視していることもあります。
規約ばかり気にするのは細かすぎると、反発を感じるかもしれません。
その言語にフォーマッターやリンターがあるなら、それらを紹介するのに適した演習を選ぶとよいでしょう。
そうでなければ、特定の規約からの逸脱が本当にひどい場合は、それが起きた場所で指摘するとよいでしょう。
メンターによって判断が分かれるのは、何をもって「本当にひどい」と見なすかという点です。
