2025 Advent Calendar Blog

42TokyoのLifeSaverで体感したヴィゴツキー理論

Qiita Advent Calendar 「42Tokyo Advent Calendar」と Adventer Calendar のおひとりさま「HelloWorld! Advent Calendar 2025」に参加中です。(「42Tokyo Advent Calendar」の主催者さんには、どちらのカレンダーにも同じURLを掲載してOKと許可を得ております)

 

現在私は25年ほどのIT業界(主にSE)を経て42Tokyoというところに通っています。

そういえば、去年のアドカレでも書いた。

 

42Tokyoについて知りたい人は、Edaさんの「42Tokyoをプログラミング未経験者が1年で卒業した」に詳しく書かれていますし、Qiita Advent Calendar 「42Tokyo Advent Calendar」の他の方の記事を読んでみてください。

LifeSaverとは

42の受験期間はフランス語でPiscine(ピシン)と呼ばれ、受験生は「ピシナー」と呼ばれています(ピシナーは、Tokyo校だけの造語かな?)。

42TokyoのPiscineでは、他のキャンパスにはない、本科生がピシナーをサポートする「LifeSaver」という仕組み・役割があります。本記事では、LifeSaver任期中に体感したピアラーニングの良きところを、私なりの感想をまじえて紹介します。

なにもわからん!プログラミング未経験ピシナー

私はLifeSaverに志願し、9月のPiscineを4週間の任期で担当することになりました。初日は120人ほどのピシナーがいました。初週で、大半が脱落するといわれているPiscineですが、そこを見守り・支えるのが任務のひとつです。

最初の数日は各クラスター(教室)を見て回りながら、何かお困りごとはないかと、ピシナーに声をかけていました。

あるとき、一人のピシナーから途方に暮れ困り果てた顔で、ご相談いただきました。

「何人にも聞いたんですけど、みんな何を言ってるか全然わからなくて...」

聞けば、数人の「できる人」に質問したけど、詳しく説明されても理解できなかったという。◯◯の操作だったと思う(◯◯: あとから気づいて伏せ字にした)

42TokyoのLifeSaverには厳格なルールがあり、課題の内容はもちろんのこと、◯◯の使い方すらピシナーに教えてはいけないです。自力で調べる、試す、ピシナー同士で解決する...42は、そうやって未知の問題に対し、自走して解決力を身につけられるような仕組みを提供しています。

初心者同士をつないでみた

実は、その相談を受ける前に、私は別のピシナーと話をしていました。その人は、全く同じ問題で躓いていたけど、なんとか解決できたと喜んでいました。

ふと、この二人をつないでみたら解決するのでは?と案が浮かび、お互い別々のクラスターにいましたが、引き合わせてみました。

結果は予想通りで、あとからスッキリした顔で「無事に解決しました!」と報告してくれました。数週間後のPiscine最終日には「あのとき繋いでくれて、本当に助かりました!」と感謝されました。

当時の自分のつぶやきを振り返ると、こんなコメントを残していた。

今日は人繋ぎばかりしてた。◯◯の使い方も教えちゃいけないので、有識者をつかまえて初心者につなげるみたいなことをしてた。とてもデキる人と超初心者をつなげるのは高い確率で良くないとわかってきて、似たようなレベルの人を探してはつなげたりとかしてた。

「できる人」≠「教えられる人」

この体験で気づいたのは、技術的に優れている人が、必ずしも初心者に教えるのが上手いわけではないということ。

できる人には、当たり前のように使っている前提知識があります。その前提知識のギャップが大きすぎると、説明を聞いても「何を言っているのかさっぱりわからない」状態になります。

一方で、つい数時間前に同じところでつまづいていた人は違います。どこが分からなかったか、どう考えて解決したか、その過程が生々しく記憶に残っています。だから同じレベルの人にとっては最高の「教材」になります。

ZPD(最近接発達領域)という概念

この体験を振り返っていて、ある記事を思い出しました。ミミクリデザインの安斎勇樹さんが書いていた、ZPD(Zone of Proximal Development:最近接発達領域)についての話「組織に“できたてホヤホヤの暗黙知”をシェアする仕組みをどうつくるか

ZPDとは、「一人ではできないけれど、適切なサポートがあればできる領域」のこと。学習において最も効果的なのは、この領域で挑戦することだという。

重要なのは、このサポートは必ずしも「専門家」である必要はないということ。むしろ、ほんの少しだけ先を行く人の方が、適切なサポートを提供できることがある。なぜなら、その人自身が最近その領域を通過してきたばかりだから。

Piscine初日・2日目の「人つなぎ」は、まさにこのZPDのマッチングでした。同じところでつまづいた経験を持つ人同士をつなぐことで、お互いのZPD内での学習が起きます。

42の仕組みが生む学び合い

42には教科書がありません。講師もいない。

この仕組みに対して「どうやって学ぶの?」という疑問を持つ人も多いです。でも、実際に現場を見ると、むしろこの制約があるからこそ、生徒同士が自然と教え合う文化が生まれています。

ピアレビューでも同じです。課題を提出すると、他の生徒がレビューする。レビューする側は、他人のコードを読むことで学ぶ。レビューされる側は、フィードバックから学ぶ。マッチング相手によって学びの質は変わるけど、それもまた学習の一部。

私が所属しているSingularitySocietyの強強エンジニアからこんなコメントをもらった。

42は、帰属感、人の交流促進、(有償の)スタッフを増やさない、ということが同時にできる良い仕組みですね。学生がチームになるような仕掛けなのですね。(金銭的な)報酬だけでは十分なインセンティブにならないところ、その仕掛けがよく機能しているのですね。

LifeSaverの役割

LifeSaverの基本的な役割は「見守る」こと。42Tokyoは、自らコミュニケーションを取りに行き、自走できるエンジニアを育てることを目指しています。なので、LifeSaverの過度なサポートはNGです。

だけど、初日・2日目はちょっと違います。まだ環境に慣れていないピシナーたちが、どうコミュニケーションを取ればいいのか、誰に聞けばいいのか、手探りの状態です。この時期のちょっとしたきっかけが、その後の自走力につながることもあります。

私が「人つなぎ」を意識的にやったのも、この最初の2日間だけでした。誰が今どこでつまづいているのか、誰が最近何を乗り越えたのか。その情報をキャッチして、適切な人同士をつなげる。あまりサポートしすぎると、ピシナーの自走を妨げてしまう。だから、本当に初期のきっかけづくりに留めました。

もしこの記事を読んでいる本科生で、もしこれからLifeSaverになる人がいたら、最初の1〜2日は「人つなぎ」を意識してみてほしいと思います。似たようなレベルで、似たようなところでつまづいている人同士をつなげる。ほんの少し先を行く人と、今まさに困っている人をつなげる。

これが、42での学び合いが始まるきっかけのひとつになるのだと思います。

LifeSaverの特典

LifeSaverをやって良かったなと思ったことは、これまで述べてきた通り、改めてピアラーニングの良さを体験できたのが一番ではありますが(本科に入っても体験しておりますが)、知り合いが増えたというのも大きいです。

週次でおこなわれるフィードバック会やランチ会など、他のLifeSaverとの交流機会もたくさんあってとても楽しかったです。

ごはんも美味しかった。

-2025, Advent Calendar, Blog