Track Anatomyプロジェクト

昨年9月、ExercismのTrack Anatomy Projectをひっそりと始めました。それ以来、この取り組みについて少しずつ多くの人に伝えてきましたが、そろそろ、Exercismのトラックと演習を改善するために進めている正式な取り組みを広く公開する時期だと判断しました。

Track Anatomy Projectの目的と必要性を理解するには、Exercismの原点にさかのぼる必要があります。Exercismは、それぞれが重複する内容の演習をいくつか備えた、さまざまな言語トラックとして始まりました。決まった順序や構造があったわけではなく、興味をひかれそうな演習を誰でも自由に選び、解いて、コードをアップロードし、誰かが見つけてコメントしてくれるのを待つ、という形でした。2018年のリニューアルでは、トラックそのものと、それに伴う学習の両方に、より構造化されたアプローチを導入することをExercismの中心に据えました。そこで言語トラックを、必須の「コア演習」からなる固定の背骨で構成し、コア演習を終えるたびに任意の「サイド演習」が解放される形に改革することにしました。メンテナーには、コアの背骨を難易度が上がるように組み立てることと、練習するテクニックに見合った解放の順序を設計することをお願いしました。これに対する取り組み方はメンテナーごとに異なり、成果もさまざまでした。なかには時間が取れないメンテナーもいて、その場合は比較的ランダムに選んだ10個の演習で最初のコアを構成しました。

トラックの設計が、そのトラックの成功を大きく左右することは、すぐに明らかになりました。公開から最初の数か月のあいだに、いくつか重要なことに気づきました。

• 難しすぎる演習から始まる言語では、学習者がいら立ってしまい、すぐに離れてしまいます。
• 演習をメンタリングする大変さは、演習の難易度ではなく、その複雑さに直接比例していました。
• 典型的な一つのやり方で解ける演習（たとえば「acronym」）や、学習目標がはっきりしている演習は、解き方に幅がある演習（たとえば「bob」）よりもずっと早くメンタリングできました。
• 概念を導入する順序も重要です。最初のいくつかの演習で必須のイディオムを扱っておくと、そのあとの演習が学習者にもメンターにも楽になります。

こうしたことから、Exercismでのメンタリングの成功の多くは、トラックの「カリキュラム」の質にかかっていると気づきました。適切なトピックを、適切な演習で明示的に、適した順序で扱うことです。そこで、メンテナーを導く正式なフレームワークを開発し、他のトラックの模範となるトラックを一つ作る必要があると考えるようになりました。

こうした動きと並行して、20年間プロのコーチを続けてきたメンターの一人、Maud de Vriesが、Rubyトラックを改善する方法についての提案を定期的に投稿し始めていました。彼女のアイデアは、同じ時期に得ていた気づきと驚くほど一致していました。Maudは表に出ないところで、Rubyの演習を一つひとつ分析し、演習同士のつながりや、それぞれに含まれる概念、そして学習者にとってわかりやすく、メンターが楽しく取り組めるトラック構造にするためのよりよい並べ方を示す地図を作り上げていました。彼女がその成果の一部を見せてくれたとき、トラックのフレームワークを開発するのにふさわしいのは彼女だ、そしてRubyトラックを手がけて模範を作ってくれるだろうと判断しました。それ以来、MaudはExercismでパートタイムで働きながら、Rubyトラックを作り直し、メンテナーが彼女の知見を他の言語ですばやく再現できるように、複数の段階を踏むフレームワークを開発してきました。10月からは、Erik Schierboomが空き時間にMaudのモルモット役を務め、フレームワークを試しながらC#トラックの改善に取り組んでおり、それが今度はフレームワーク自体の開発にも大きな影響を与えています。

現在、次のメンテナーのグループにフレームワークを一通り体験してもらい、より厳密に検証して洗練させる段階に近づいています。この次のラウンドが終わったら、より広いコミュニティからさらに厳しい目で検証してもらえるよう、フレームワークの最初のバージョンを公開したいと考えています。その段階に到達し、舞台裏で進めてきたすべての仕事を披露できることを本当に楽しみにしています。これはExercismにとって大きな前進であり、学習体験とメンターの体験の両方を大きく改善すると感じています。

最後に、私はこのプロジェクトをたゆみなく先頭に立って進めてきたMaudと、多くの自由時間を割いて手伝ってくれたErikに、心から感謝を伝えたいと思います。