プラハチャレンジのカリキュラムを一部公開してみる
こんばんは！株式会社プラハCEO兼エンジニアの松原(@dowanna6)です！
昨年12月に「中級エンジニアを育てる」というコンセプトで立ち上げたオンラインブートキャンプ PrAha Challenge（プラハチャレンジ）がちょうど1年を迎えました。
先日プラハチャレンジ初の卒業生にインタビューもしたり、1周年を無事迎えられたのを機にプラハチャレンジの中身を一部お見せしたいと思います。
プラハチャレンジの進め方
プラハチャレンジにはこんな課題が70個ほど用意されています：
生徒さんは各々の時間に上記の課題に回答し、「ペア」と呼ばれるチーム単位で回答の相互レビューを行います。プラハチャレンジは2名1組のペアで進めていただくピアラーニング中心のカリキュラムなので、課題に答えたらお終いではなく
- 課題に回答する
- ペアと相互レビューする
- 回答結果についてペアと話し合う
- お互いに納得したら次の課題に取り組む
という進め方を前提としています。
なぜペアと相互レビューするのか？
エンジニア界隈には知識の習得フェーズを表す変わった表現があります。
知らない → 理解した → 完全に理解した → 何もわからない → ちょっと分かる
右に行くほど高いレベルで知識を習得していることを示します。「React完全に理解した」は公式チュートリアルの丸バツ問題を作り終えた段階で、「Reactちょっと分かる」と言ってる人は十中八九コアコミッターだそうです。
このような表現が生まれるほど、開発関連の概念は「理解した！」と思っても実は勘違いだったことがよくあります。
勘違いを防ぐためには他人に説明してみることが何より効果的だと考えています。かのアインシュタインが「六歳児に説明できなければ、理解したとは言えない」と豪語したように、誰かに説明してみると
「え、それってこういうケースだと破綻しない？」
「じゃあ〇〇はXXってこと？」
「僕はこうだと思うな」
みたいな問いや反対意見を返されることがあり、こうした問答を繰り返していくと正しい理解に辿り着きやすくなります。そのため課題を一人で進めるのではなくペアで進めるピアラーニング形式を採用しています。
ペアが揃って勘違いすることはないの？
あると思います。
実はそれを防ぐためにプラハチャレンジでは2~3組のペアを合わせた「チーム」という概念が存在して、ペアで会話したものの少し理解に不安がある事
柄はチームで相談していただく仕組みになっています。
こうすれば、仮にペアの2名が揃って勘違いをした場合、他ペアから「でも私たちのペアは違う考え方をしました！」と反対されることで勘違いに気づきやすくなります。
三人寄れば文殊の知恵と言いますし、集合知は侮れません。三人寄れば代替されてしまう程度なら文殊の知恵は意外と大したことないのではないか？という疑問はさておき、しっかり知識を理解していないと大人数から浴びせられる疑問や反対意見に耐え切れないため、1年ほどメンターを努めた経験から過去そこまで大きな勘違いがチーム単位で起きたことは観測できていません。
チーム単位で集まる会は毎週開催されるため、ここに疑問を持ち込んでディスカッションをすることである程度の不明点は解消されることが期待されます。
チームでも解決しなかった場合はどうするの？
チームで話し合っても解決できない疑問が残った場合、メンターに相談できます。
株式会社プラハに所属し日々エンジニアとして開発している人しかメンターにはなれないため、そこそこちゃんとしたエンジニアがメンターとして登場します。
本来の予定では社内から何名かメンターを手伝ってもらえるはずだったのですが「やっぱり恥ずかしい」という事で最終的に今メンターをしているのは自分一人です。こんなはずじゃなかった。
どんなことをメンターに聞けるの？
過去メンターに寄せられた質問をいくつか抜粋してみました：
SPAなどでログイン認証を行う場合、access_tokenは何処に保存するべきなのでしょうか？？
リバースプロキシとアプリケーションサーバー間のCookieの共有はどうされているのでしょうか？Nginxでは、proxy_cookie_domainと呼ばれるCookieのドメインを書き換えてくれる設定があるみたいなので、こちらの設定を行っているのでしょうか？
TypeScriptの型エラーで検出できる場合でも、テストをした方がいいのでしょうか？
コントローラーは値の受け渡しのみ、リポジトリはDB操作のみに特化して、それ以外のドメインオブジェクトの操作などの処理はできるだけユースケースに押し付けるべきでしょうか。
以下のようなテストコードを書きました。
これはアサーションルーレットに該当するでしょうか？
また、仮に直すとしたらどのように修正しますか？
POSTはシンプルリクエストなのに、PUTはなぜプリフライトリクエストなのでしょうか？
トランザクションのISOLATION LEVELは、実務ではどの設定値にすることが多いのでしょうか？
概ね週1回の頻度でメンターとチームメンバー全員でオンラインのビデオ会議に集まり、上記のような質問に関して質疑応答を繰り返していきます。
メンターとして注意していること
1年ほどプラハチャレンジのメンターを務めて色々なことを考えたので、意識していることをまとめてみました
愚問は存在しない
「何かを知っている」という状態には段階があるように思います。
例えば「無知の五段階(Five orders of ignorance)」を参考にすると
無知の欠如（全部知ってる）
知識の欠如（知らないことがある、でも知らないことを知っている）
気づきの欠如（知らないことがある、かつ知らないことに気づいてない）
過程の欠如（知らないことを知らないことに気づく術がない）
メタ無知（無知に段階があることを知らない）
初学者の頃は自分が聞くべきことさえ思いつかなかったり、どう質問すれば効果的に回答を得られるか分からないことがあります。これは気づきの欠如・過程の欠如の段階に居るためで、決して本人が何らか能力的に劣っていたり、努力が不足しているわけではありません。
そんな方にとって的確な質問をすることは非常に難しく、かつ勇気の要ることです。
「めちゃくちゃ初歩的な質問をしてしまってバカにされたらどうしよう」
「周りはみんな分かりきっていることを聞いてしまったら申し訳ない」
という気持ちを抱えながら、それでも一歩前進するために勇気を振り絞った質問に対して「初歩的な質問ですね」「そんな簡単なことは聞かないでください」「ググれば？」みたいな空気を出してしまうと、その方はもう2度と質問をしなくなってしまうかもしれません。
なのでメンターセッションにおいては「愚問は存在しない」というスタンスを示すことを重視していました。例えば「constで定義した変数に再代入できない！なぜ！」という質問を受けたとして、
constはいつ頃生まれた概念なのか？（プログラミング言語の歴史を学べる）
constが存在すると何が嬉しいのか？（イミュータブルな部分が増えるほど保守が楽になるなど設計に関する概念を学べる）
constで定義しても要素を更新できるオブジェクトや配列は何が違うのか？（少しCS的な話に触れられる）
などなど、いくらでも有意義な質問に広げることができます。
質問は別の質問のキッカケにもなるので、全ての質問はレベルを問わず歓迎されるべきです。それ自体が愚問である質問など存在しない。質問を受け取った人に問いを広げる力がないから愚問になるのである、みたいなことを常に意識して、以下のようなツイートを定期的に投げかけていました。
まず自分以外が発信した情報を調べる
メンターセッションで回答する際は、自分以外が発信している情報（可能な限り一次情報）をまず調べてから回答しています。webの仕様について聞かれたらRFCを読んだり、自分より遥かに詳しい方々が当該テーマについて語っている記事を引用した上で自分の意見を述べたり。
「自分の頭で考えることなんてたかが知れてるから、より確実なソースに当たって回答の精度を高めたい」というのも一つの理由なのですが、もう一つの理由は「すでに世の中に出回っている情報を調べるだけでそれなりのレベルのエンジニアになれる」というメッセージを伝えたいからです。
少し脱線しますが僕は自分の頭に全く自信がありません。10歳の従兄弟に神経衰弱でぼろ負けして嘲笑されるし、台所にハサミを取りに行ったのに愛犬としばらく遊んだら何も持たずに帰ってくるし、謎解きゲームで問題を解けた事もほとんどありません。競プロも緑が限界です。
それでもエンジニアとしてそれなりに開発できているのは沢山の情報を日々インプットしているからです。日々の開発作業で僕自身が生み出したアイデアを実践することは1%もなく、99%は世界のどこかに居る（居た）達人の考え方を真似たり、達人が作ったツールを使っているに過ぎません。巨人の肩にしがみついている状態です。
ここでケントベック氏の名言を引用すると、
「私は偉大なプログラマーではないが、偉大な習慣を身につけたプログラマーだ」
（意訳。原文は“I'm not a great programmer; I'm just a good programmer with great habits."だそうです）
なのでメンターセッションで「回答します。Aです」と答えるよりは「自分はこの情報をこうやって見つけました。これを読んで、こう考えた結果、Aだと考えています」と答えることで、再現性の高い知識の習得方法（習慣）を伝えるように心がけています。
「この人は得体の知れない魔法を使って問題を解いている訳ではなく、知識が豊富で調べ方が上手いだけ。真似すればすぐ越えられるぞ」と思ってもらえるような再現性の高いメンターの方が、上達の道筋やイメージが見えやすくて良いのではないでしょうか？
food for thought
英語にはfood for thoughtというフレーズがあり、直訳すると思考のための食べ物なのですが要は「考えるキッカケ」でしょうか。
考えるキッカケをたくさん提供することがメンターセッションでは重要だと考えていて、例えばDB設計に関する相談を受けた時には「こういうユースケースが新たに生まれたらどう対応しますか？」と問いかけてみたり、「他の設計パターンもあるけど、それぞれどういうメリデメがありそうでしょうか？」と議論を始めてみたり、「この記事を読んでみるとさらに理解が深まるかもしれませんよ」と提示してみたり。
次の思考のキッカケを会話の中で沢山生み出せるよう気をつけています。メンターセッション以外の場でも、プラハチャレンジのslackチャンネルにはこんなことを定期的に呟くbotを稼働させています：
どんな人に向いてるの？
プラハチャレンジは座学で一方的に知識を教わるのではなく、教え合い・話し合いを通したピアラーニングを中心に据えているため他者との議論を通じて知識を深めたい方に向いています。
例えばカリキュラム後半に用意されている「チーム課題」では、参加者でチームを組んで実在する企業のCTOやPOからサービスの要件をヒアリングしながらWEBアプリケーションを作る機会があります。
実際に参加者が作業をしていたリポジトリのPRを拝見すると：
議論が白熱してコメント数が64件に達したPRまでありました。
チーム課題に限らずプラハチャレンジでは正解をそのまま提示されることが少ないので「これが正しいのではないか？」「いやこうじゃないか？」と参加者同士が会話しながら回答を模索する必要があります。そのため技術的な議論をできる仲間が欲しい！というモチベーションをお持ちの方ほど、プラハチャレンジから多くのことを得られるかもしれません。
また本コースのカリキュラムとは別に様々な行事も用意されているため、こうしたイベントに積極的に参加している方ほど沢山のことを学んでいるように感じます。
輪読会
輪読会では参加者の投票で課題図書を選びます。過去に輪読の課題図書になった本は以下の通りです：
達人プログラマー
リファクタリング
Engineers in Voyage
ドメイン駆動設計 モデリング/実装ガイド
これらの課題図書に関して一人一問クイズを作成して、隔週で集まった際にお互いが作成したクイズに答え合うような進め方をしています。例えば過去にはこんなクイズが出題されていました：
普段は異なる会社で異なるサービスを開発している参加者同士「うちではこんな風になっているよ！」と互いの知識を持ち寄ることで学びが深まるため、個人的にはメンターとしても楽しみにしているイベントの一つです。
競プロ会
AtCoderを使った競プロも行われています。全探索や動的計画法などテーマを絞って勉強したり、毎週土曜日に行われるBeginner Contestに参加してみたり。
僕は競プロが大の苦手なのでリタイアしてしまいましたが、今でも残っているメンバーは処理速度を求めてRustやC++に切り替えていたり、計算量も予測しながらコードを修正していたり、気持ち良いくらい競プロにハマっていました。
ゲーム交流会
こちらは純粋な娯楽目的ですがスマブラやAmong Usなどのゲーム会を開催しました。
メンターという立場も忘れてパックンフラワーを使った崖際コンボを中心に勝ちを狙いに行きましたが普通に負けました。
まとめ
長々と書いてしまいましたが、昨年末に一念発起して用意してみたプラハチャレンジが無事1周年を迎えられて本当に嬉しく思います。プラハチャレンジ第4期の実施時期は未定ですが、ご興味をお持ちの方は是非以下のHPから第4期の開催通知にご登録ください。
そもそもプラハチャレンジを作ろうと考えた理由や背景についてはこちらの記事で解説していますので、よろしければこちらもご覧ください。
この記事が気に入ったらサポートをしてみませんか？