チームプロジェクト型の教育を運営しているものの、「成果物は出るのに、個人が何を学んだのか分からない」という悩みを抱えている方。運営者個人の力量に頼らず、構造で回る授業を求めている方。
サイドプロジェクトやハッカソン、オンボーディングで、メンバーが「できることだけやって終わる」役割の固定化を打ち破りたい方。チームの成長と成果物の間の優先順位を明確にしたい方。
講義を聞いても何も残らないと感じている方。学ぶ前に仮説を立てて壊すやり方で、一人でも勉強会でも学習の密度を高めたい方。
チームプロジェクトは合理的に回るほど、各自がすでに得意な仕事を担うようになります。成果物の質は上がっても、個人の学習曲線は平らなままです。学びは、問題を解くうちに運よく得られる副産物へと追いやられます。
「価値ある問題を解けば、学びは自然についてくる」
「学びは意図されたときにのみ保証される」
HypoLoopは、この前提の置き換えから出発します。偶発的な学びに賭けていた賭け金を回収し、学習を最初から名前のついた目標にします。
問題解決を捨てようという話ではなく、順序を変えようという話です。究極の本物の問題は、今日の実力では解けません。学習だけが、明日もっと難しい問題を解けるようにしてくれるからこそ、HypoLoopは成果物よりも学習を優先します。小さなチャレンジは回り道ではなく、究極の問題へ上っていく唯一の階段なのです。
4つの概念はすべて、同じ一つの例で解説します — 🍞 パンづくり。チームの目標は「地元で愛されるパン屋を開く」、私はまだ発酵を知らないメンバーです。
情報がない状態でまず仮説を立て、検証可能な質問に分解し、探究しながら壊し、デルタを評価します。仮説が壊れる瞬間こそ最大の学習ポイントであり、検証の瞬間がそのまま試験になります。
学ぶ前にまず書きます — 「パンはベーキングパウダーのおかげで膨らむと理解している。イーストを抜いて焼いてみれば分かるはずだ。」焼いてみると平らです。仮説が壊れるこの瞬間、酵母発酵という本当の原理が刻み込まれます。先に検索していたら、素通りしていた知識です。
チームは世界の問題に向けた仮説を回し、個人はその中に自分の学習仮説を入れ子にします。「このチームの問題を解く過程で、私は意図的にXを学ぶ。」層は2つ、サイクルは1つです。
チームは「うちの町の人たちは、朝に焼きたての健康パンを求めているはずだ」という仮説を回します。私はその中に「このパン屋を準備する過程で、私は発酵を学ぶ」という学習仮説を入れ子にします。チームはパン屋を開き、私は発酵を学ぶ — 層は2つ、サイクルは1つ。
究極の本物の問題を、挑戦可能なサイズまで階層的に分解します。どんなに小さなチャレンジも、本物の問題と血統でつながっています。おもちゃか足場かを決めるのは、サイズではなくつながりの可視性です。
地元で愛されるパン屋を開く → 看板となる健康パンの開発 → サワードウを焼く → 天然酵母種をつくる(リーフ)。ガラス瓶で酵母種を育てる1週間の小さな挑戦も、ツリーをたどって上れば、パン屋という本物の問題と血統でつながっています。だからおもちゃではなく、足場なのです。
成否の基準は「問題が解けたか」ではなく「仮説と比べて何が変わったか」です。問題も本物、挑戦も本物ですが、採点されるのは変化量です。だからこそ、成果物の質の低下を公式に受け入れることができます。
今日焼いたサワードウは、平らにつぶれて失敗しました。しかしサイクルの開始時点では、発酵温度が何を変えるのか知らなかった私が、今は「低温発酵が風味をつくり、過発酵が生地を崩す」と説明できます。採点されるのはパンの形ではなく、この距離(Δ)です。
運営者一人の力量ではなく、構造が回すフレームワークです。各ステップのテンプレートをコピーしてそのまま埋めれば、最初のサイクルが始まります。
チームが本当に解決したい、世界に実在する問題を究極チャレンジとして宣言します。不可能ではないが簡単でもなく、メンバーの興味・関連性とつながっている必要があります。この問題の真正性が、ツリー全体の真正性になります。
私たちのチームは[世界の本物の問題P]を解決しようとしている。 この問題は[誰が、どんな状況で]実際に直面している問題だ。 解決されれば[何が変わったか]で確認できる。
究極チャレンジを解決するために前提となる下位チャレンジを展開し、個人が1サイクルの中で挑戦できるサイズのリーフが出てくるまで分解します。各リーフから究極チャレンジまでの経路が常に見えるように、ツリーをチームの共有スペースに掲示します。
[上位チャレンジ]を解決するには [下位チャレンジ A / B / C]が前提となる。 リーフ判定 — 一人が1〜2週間で仮説を 壊してみられるサイズか?(いいえ → もう一段分解)
白紙からチャレンジを立てるのではありません。ツリーのリーフの中から選びますが、ルールはただ一つ — 今できないことを選ぶ。初心者には基礎スキルが、熟練者には専門性を増幅する隣接領域(デザイン、ドメイン、市場)がリーフになります。
私は[リーフL]を選ぶ。 今の私にはこれができない — 根拠: [試みると起きること]。 このリーフは[リーフ → 中間 → 究極]の経路で チームチャレンジとつながっている。
検索する前、講義を聞く前に、何の情報もなしに現在の理解だけで仮説テンプレートを埋めます。ぎこちなく、間違っているほど良いのです。この仮説が、以後に出会うすべての情報が引っかかる認知のフックになります。
私は今[対象X]を[このように理解/予想]している。 [検証行動Y]をやってみれば、この理解が正しいか分かるはずだ。 この仮説が壊れたら、私は[分かるはずのこと]を知ることになる。
仮説を立てた本人ではなく、チームの仲間が尋ねます — 「この仮説が壊れたら、君は何を知ることになる?」答えられなければ、仮説を磨き直して書き直します。このリチュアルによってループキーパーなしでも検証が回り、尋ねる側もメタ認知のトレーニングになります。ループキーパーは介入者ではなく、この構造がうまく回っているかを見守るインフラ管理者です。
質問: 「この仮説が壊れたら、君は何を知ることになる?」
合格 — 答えが具体的な理解を一つ指している。
差し戻し — 検証行動が曖昧だ / 知ることになるものがない
/ すでに知っていることだ。
差し戻されたら、仮説を磨いて書き直す。別枠の勉強時間ではなく、チームの問題を解くまさにその過程が仮説の実験場です。仮説が壊れる瞬間を、その場で記録してください — 予想と現実のギャップが大きいほど、更新される理解も大きくなります。
[探究ログ — 仮説が壊れた瞬間ごとに] 予想: [予想していたこと] 現実: [実際に起きたこと] ギャップから学んだこと: [更新された理解]
サイクルの終わりに、各自が開始時点の仮説をもう一度取り出し、当時の理解と今の理解の距離(デルタ)を測ります。そして、その学びがチームチャレンジをどこまで前進させたかも一緒に記録します — 学習と解決はここで一つに出会います。
始まりの私は[このように理解]していた。 今の私は[このように理解]している。 デルタ(Δ): [何が更新されたか] 解決への貢献: [この学びがチームチャレンジを どこまで前進させたか]
振り返りで更新された理解が、次のサイクルの出発点です。次のリーフはもっと分からないものを選び、チーム層も同じリズムで回ります — チーム仮説の棄却は失敗ではなくピボットの根拠です。ループは止まりません。
次のリーフ: [今回よりもっと分からないもの] 次の仮説: [更新された理解で書き直す] チーム層への反映: [棄却されたチーム仮説があれば → ピボットの方向]
ループキーパー(ファシリテーター)は、知識を伝える人でも、チャレンジを検査する人でもありません。構造がうまく回っているかを見守るインフラ管理者であり、必要な瞬間に質問を一つ投げかける人です — ループが止まらないように守る人、だからキーパーです。答えは与えません — 答えを探す過程こそが学習者のサイクルだからです。以下の質問はループキーパーの専有物ではありません。キーパーがいなくても、チームメンバー同士で投げかけ合うだけでフレームワークは回ります。
サイクルに必要なすべての文章テンプレートを一か所に集めました。形式こそがフィルターです — 空欄を埋められないなら、まだ準備ができていないということです。
私は今 [対象X]を [このように理解/予想]している。 [検証行動Y]をやってみれば この理解が正しいか分かるはずだ。 この仮説が壊れたら、私は [分かるはずのこと]を知ることになる。
最後の行が、ピア検証の質問への答えです。この行をあらかじめ書いておけば「壊れたら何を知ることになる?」にすぐ答えられ、書けなければ仮説はまだ準備ができていないということです。
Notionや文書に貼り付けて、1サイクルの間この1枚だけを埋めます。下の8ステップテンプレートの要約版です。
[サイクルシート — 名前: · 期間: 〜 ] リーフ: [ツリーから選んだ、今できないこと] できない根拠: [試みると起きること] 血統: [リーフ → 中間 → 究極チャレンジ] 仮説: 私は今[対象X]を[このように理解/予想]している。 検証行動: [1〜2週間でやってみられるY] 壊れたら知ること: [具体的な理解を一つ] ピア検証: 通過 / 差し戻し — [仲間の名前 · 日付] 探究ログ(壊れるたびに): - 予想: → 現実: → 学んだこと: - 予想: → 現実: → 学んだこと: デルタ(Δ): [始まりの理解] → [今の理解] 解決への貢献: [チームチャレンジをどこまで前進させたか] 次のリーフ: [今回よりもっと分からないもの]
キックオフでチーム全体が一緒に埋め、声に出して読んで確定します。
私たちのチームは[世界の本物の問題P]を解決しようとしている。 この問題は[誰が、どんな状況で]実際に直面している問題だ。 解決されれば[何が変わったか]で確認できる。
ノードごとにリーフ判定の質問を投げかけ、いいえならもう一段分解します。
[上位チャレンジ]を解決するには [下位チャレンジ A / B / C]が前提となる。 リーフ判定 — 一人が1〜2週間で仮説を 壊してみられるサイズか?(いいえ → もう一段分解)
ルールはただ一つ — 今できないこと。根拠まで書いて完成です。
私は[リーフL]を選ぶ。 今の私にはこれができない — 根拠: [試みると起きること]。 このリーフは[リーフ → 中間 → 究極]の経路で チームチャレンジとつながっている。
検索する前に、15分、今の理解だけで。間違っているほど良いのです。
私は今[対象X]を[このように理解/予想]している。 [検証行動Y]をやってみれば、この理解が正しいか分かるはずだ。 この仮説が壊れたら、私は[分かるはずのこと]を知ることになる。
尋ねる側は質問のみ — アドバイス禁止。往復3分以内に。
質問: 「この仮説が壊れたら、君は何を知ることになる?」
合格 — 答えが具体的な理解を一つ指している。
差し戻し — 検証行動が曖昧だ / 知ることになるものがない
/ すでに知っていることだ。
差し戻されたら、仮説を磨いて書き直す。仮説が壊れたその場で5分以内に。上手に書く必要はありません。
[探究ログ — 仮説が壊れた瞬間ごとに] 予想: [予想していたこと] 現実: [実際に起きたこと] ギャップから学んだこと: [更新された理解]
成果物ではなく変化量。開始時の仮説の原文を横に置いて書きます。
始まりの私は[このように理解]していた。 今の私は[このように理解]している。 デルタ(Δ): [何が更新されたか] 解決への貢献: [この学びがチームチャレンジを どこまで前進させたか]
次のリーフはもっと分からないものを。棄却されたチーム仮説はピボットの方向へ。
次のリーフ: [今回よりもっと分からないもの] 次の仮説: [更新された理解で書き直す] チーム層への反映: [棄却されたチーム仮説があれば → ピボットの方向]
勉強会はサイクルを1週間に圧縮してこのアジェンダで回します。60〜90分。
[週次ミーティングアジェンダ — 60〜90分] 1. デルタ共有(1人3分) 前回の仮説の原文をそのまま読み、今の理解との 距離だけを話す。成果物の自慢は禁止。 2. 壊れた瞬間の自慢 予想と違った瞬間を1つずつ。 誰も壊れなかったら → 全員リーフを一段上げる。 3. 次の仮説作成(15分、その場で) 検索する前に書く。 4. ピア検証(2人1組) 「この仮説が壊れたら、君は何を知ることになる?」 通過するまで。質問のみ、答えは禁止。
チームの規模も、熟練度も、ドメインも異なる5つのサンプルです。最初の事例は、8つのステップの全過程を1日単位でたどる詳細ウォークスルーです — フレームワークが実際にどう回るのかを見るなら、ここから読んでください。(運営シナリオをもとに再構成したサンプルです。)
ここにない質問は leeo [at] kakao.com までお送りください — 良い質問はこのリストに追加されます。
必要なのは、本物の問題が一つ、ツリーが一枚、そして間違う準備のできた仮説が一つです。
試してみたい方、質問のある方は — leeo [at] kakao.com