これは何
プラハチャレンジのメンターを担当するにあたり役立ちそうな行動や考え方を記載する
プラハチャレンジのコンセプト
プラハチャレンジの卒業生にどうなって欲しいのか
プラハチャレンジの卒業生には、技術的負債を最小限に抑えて新WEBサービスを開発できる最低限の知識を持ち、未知の課題に直面した時に自ら調べて仮説を作れる習慣を身につけて欲しいと考えています。
教えるのではなく、一緒に考える
人の話を一方的に聞くよりも、対話しながら一緒に考えた方が記憶に定着しやすいと考えているため、教えるという立場ではなく一緒に考える立場を常に意識してほしいと考えています。
良い習慣を身につける
プラハチャレンジは「I'm not a great programmer; I'm just a good programmer with great habits」というケントベック氏の言葉を大切にしています。
プラハチャレンジの課題に正しく答えることより、卒業した後に直面する業務上の課題に対応できる良い習慣を参加者が身につけることの方が大切です。正解を一つ覚えるより、正解を見つける方法を一つ身につける方が価値があると考えています。
答えを暗記するのは簡単ですが、コンテキストを理解せずあらゆることに同じ答えを適用するだけでは効果が得られない (opens in a new tab)可能性があるからです。
参加者が良い習慣を身に付けられるよう、答えを得るために自分がどのように調べ、日頃どのような情報に触れ、得た情報をどう解釈したのか、などを伝える方が、答えそのものを教えるよりも大切だと考えています。
メンターセッションの事前準備
メンターセッションの24時間前（airtableに質問が記載される期限）から当日のメンターセッションまでの間に実施すべき事前準備について記載します。
質問を精査する
経験上、プラハチャレンジが始まったばかりの時期は、記載される質問に改善の余地が多い傾向にあります。 (opens in a new tab)
答えやすい質問を作れると周囲の力をうまく借りられるようになるため、「良い質問を作れること」は最優先で参加者に身につけて欲しい能力のひとつです。
もし質問が荒すぎるように感じたらSlackで改善点を伝えて質問を書き直してもらってください。
回答を書いておく
「メンターセッション（当日準備分）」のgoogle docに回答を書いておいてください（リンクはSlackのpraha_challengeチャンネルのbookmarkに記載されています）
土壇場で回答しようとすると大体緊張してうまく喋れないので...
サンプルを用意する(一緒に作る準備をする)
画面を共有しながら一緒に見れるサンプルを用意しておくとセッションがスムーズに行えます。例えばDB設計に関する質問ならdbdiagram (opens in a new tab)に書き出しておく、dockerで初期データ入りのテーブルを作っておくなど (opens in a new tab)。
コードを書くのであればTSのplayground (opens in a new tab)やCodesandbox (opens in a new tab)で用意してくおくなど。
一次情報に近い情報源を探す
QiitaやZennに掲載されている情報は理解しやすく咀嚼されているため導入としては良いのですが、一次情報を見る習慣が失われないよう、可能な限り一次情報に近い情報にあたってください。例えばライブラリに関する質問であればライブラリのソースコードやドキュメントを参照するのがベストだと考えます。
必然的に英語情報を参照する機会が増えると思いますが、良いエンジニアになるために英語は避けられないと考えて、遠慮なく参照してください。
社内を頼る
自信がなければいつでも社内の仲間を頼ってください。times等で「誰か助けて〜」と意見を募るだけでも十分に効果はあると思いますが、答えられそうな人にあたりをつけて名指しで助けを求めた方が良い答えを得られるチャンスは高いように思います。
メンターセッション中
アイスブレイク
セッションが始まったらすぐに質問に取り掛かるのではなく、軽いアイスブレイクを挟んでください。特にプラハチャレンジが始まったばかりの頃はほぼ全員が初対面なので、セッションは強い緊張感に支配されているでしょう。その状態で忌憚なく技術議論を行うのはなかなかハードルが高いので...
アイスブレイクの例としては「最近起きた、ちょっと嬉しいことを教えてください」と誰かに聞いてみるのが一番手っ取り早いですが、世の中にはいろいろなアイスブレイクがあるので好みの物を探してみてください！
笑顔
笑顔はとても大切です。ニッコリ笑いましょう！特に最初の印象が重要なので、初めてのメンターセッションは必ず笑顔で参加しましょう！
愚問は存在しない
無知は五段階に分類できるそうです (opens in a new tab)
- メタ無知（無知に段階があることを知らない）
- 過程の欠如（知らないことを知らないことに気づく術がない）
- 気づきの欠如（知らないことがある、かつ知らないことに気づいてない）
- 知識の欠如（知らないことがある、でも知らないことを知っている）
- 無知の欠如（全部知ってる）
初学者の頃は自分が聞くべきことさえ思いつかなかったり、どう質問すれば効果的に回答を得られるか分からないことがあります。そんな方にとって的確な質問をすることは非常に難しく、かつ勇気の要ることです。
「めちゃくちゃ初歩的な質問をしてしまってバカにされたらどうしよう」
「周りはみんな分かりきっていることを聞いてしまったら申し訳ない」
という気持ちを抱えながら、それでも一歩前進するために勇気を振り絞った質問に対して「初歩的な質問ですね」「そんな簡単なことは聞かないでください」「ググれば？」みたいな空気を出してしまうと、その方はもう2度と質問をしなくなってしまうかもしれません。
例えば「constで定義した変数に再代入できないのですが、どうしてでしょうか？」という質問を受けたとして
- constはいつ頃生まれた概念なのか？（プログラミング言語の歴史を学べる）
- constが存在すると何が嬉しいのか？（イミュータブルな部分が増えるほど保守が楽になるなど設計に関する概念を学べる）
- constで定義しても要素を更新できるオブジェクトや配列は何が違うのか？（少しCS的な話に触れられる）
などなど、いくらでも有意義な質問に広げることができます。受け手次第でどんな質問も良い質問にできる、と考える姿勢が大切だと感じます。
教えるのではなく問いかける
例えば「このテーブルは多対多にすべきでしょうか？」と聞かれたら「一対多の場合と多対多の場合でどのようなメリットとデメリットがあると考えていますか？」と相手の理解を引き出したり、「そのデメリットはこういうケースでは該当しないのではないですか？」と相手の理解を新たな角度から試したり。
質問に答えるのではなく問いかける意識で挑むと効果的なセッションが行えます。
教えるのではなく一緒に考える(同僚のように接する)
ついつい「参加者」と「メンター」という立場で考えがちですが、自分の同僚と議論しているような感覚でセッションに臨むと良いでしょう。自然と「教える」という感覚は薄くなるはずです。
宿題を残す
経験が少ないうちは自分が勉強すべき範囲を設定することが難しいため、経験者から提示される学習ロードマップには大きな価値があります。
セッションの終わり際に「今日の話に興味がある方は〇〇というワードで検索してみると良いかもしれません」といった宿題を残すと、参加者の学習意欲を刺激できます。関連するテーマを思い付いたら、積極的に伝えてください！
事実と解釈を分けて伝える
事実と解釈の境目が曖昧な説明は理解が難しいものです。どこまでが事実でどこからが自分の解釈なのか、意識しながら説明すると良いでしょう。（これは筆者の解釈です）
結論サンドウィッチ
結論を述べる。それを補足する説明を行う。最後にまた結論を述べる。この話し方を勝手に結論サンドウィッチと呼んでいます。
結論から話し始める大切さは改めて説明するまでもないと思いますが、 (opens in a new tab)それだけだと議論している間に「あれ、僕ら何の話をしてたんだっけ？」と忘れてしまうことがあるので、質問について話し終えたら必ず結論をもう一度述べるようにしましょう。その方が参加者の記憶に定着しやすいはず！
30秒以上話さない
何かを説明している時に周りの反応が渋かったり、うまく説明できている自信がないと「これじゃ伝わっていないかも...もっと説明しよう！」と焦って話がどんどん長くなり、校長先生の挨拶みたいになってしまうことがあります。
そういう説明は大体理解されていません。一つの目安として30秒を意識してみてください。30秒以上自分が一方的に喋り続けることがあれば黄色信号です。「ここまでの話で気になったところや分からないところはありませんか？」と質問を挟んでみると良いでしょう。対話を意識してみましょう！
自信があるところ、ないところを区切って伝える
いかにも自信が無さそうに喋ると相手も不安になってしまいます。とはいえ私たちも万能ではないので、自分の解釈に自信がないときもあるでしょう。
そんな時は「ここまではこんな風に解釈していて、ここから先は少し自信がないけどこういう風に解釈しています」といった具合に、自信に応じて説明を区切りましょう。全体を通して不安げに説明されるより、参加者も安心して聴けるはずです。
「自信がないところは後日調べて改めて話しますね」と次回に持ち越しても良いでしょう。毎回その場で全ての質問に完璧に答える必要はありません！
メンターセッションの後
回答をジャンル毎のdocに整理する(知見を蓄積する)
これまでのメンターセッションのやり取りは全て記録しています。Slackのブックマークにリンクが記載されている「メンターセッションの質疑応答集」に「当日のメンターセッション議事録」の内容を転記しましょう。こうすれば次回似たような質問を受けた時に過去の回答が活かせます！
記事を書く
メンターセッションは技術記事のネタの宝庫です！実際私がZennに記載した記事の大半はメンターセッションで会話した内容から着想を得ています (opens in a new tab)
明らかに間違った説明を書いていたら誰かが指摘してくれるので、誤った知識を持ち続けるリスクも回避できるメリットもあります。もちろん間違いがないように事前に調べるのが大前提ですが、ミスをしてしまったり、より良い解釈が見つかる事は絶対にあると思うので...！