教室を“学習する組織”にする：大学での授業をアジャイルコーチとして設計した話
はじめに
自己紹介
初めまして、オバマです。
2025年10月にクリエーションラインへ入社し、今回が初めてのブログ投稿になります。アジャイルコーチとして、チームが学習し続けられる土台づくり（対話、意思決定、ふりかえり、改善サイクルの設計など）を支援する仕事をしています。
入社と同じ10月から、豊橋技術科学大学で非常勤講師として授業を担当しています。
このブログでは、その授業で大切にしていることを整理して紹介します。新入社員研修などの一助になれば幸いです。
授業概要
この授業は「高度専門人材育成訓練演習」という科目で、プロダクトをアジャイルに開発するPBL（Project Based Learning）形式の実践科目です。
講師は、スクラムフェス三河実行委員の仲間と一緒に運営しています。
修士1年向け必修として10月に始まり、現在は第7週まで終えて折り返したところです。
100名超・22チームでチーム開発を進めています。
評価はテストではなく、毎回のチーム日報（レポート）をもとに、ルーブリック（達成目標）に沿って行います。
授業設計では、特に次の2点を意識しました。
- 開発現場でもありがちな失速パターンにハマりにくくする
- 開発現場と教育現場のギャップ（評価や協働の前提）をできるだけ小さくする
このブログでは、これらを具体化した「授業で大切にしていること」を5つ紹介します。
授業で大切にしていること
1. スクラムの「型」より、経験主義（観測→適応）が回ることを優先する
この授業で狙っているのは、型の暗記よりも 経験主義（Empiricism：観測して適応する） と 自己組織化（Self-Organization：自分たちで最適化していく） が、学生の中に育つことです。
たとえば授業では、スクラム用語をそのまま解説することはほとんどしません。スプリントは「開発サイクル」と呼び、デイリースクラムも「開発サイクルのゴールやユーザーレビューに向けて、今日何をするか決める作戦会議の場」と伝えています。
すると学生の関心が「用語を使えるか」ではなく、「ゴールに近づくために、今日は何を変える？」に寄っていきます。私たちが狙っているのは、まさにこの“会話の重心移動”です。
実際にユーザーレビューの前週、あるチームが「レビューでどんなフィードバックをもらいたいか」をデイリースクラムで話し合っていました。そこから、機能について優先順位を付け直し、既存アプリとの差別化まで、議論がどんどん深まっていきました。
結果としてそのチームは、“作り続ける”選択ではなく、アプリの方向性を変える ピボット（方向転換） を自分たちで決断しました。
デイリースクラムの場が「進捗の報告」ではなく、「ゴールに近づくために何を変えるか」の作戦会議になった結果だと思っています。問いが変わると会話が変わり、会話が変わると意思決定が変わる。そうやって学習のサイクルが回り始めるのを、この授業では一番大切にしています。
2. チーム間の競争はしない。クラス全体を“ひとつの組織”として扱う
複数チームでのPBLは、放っておくとチーム対抗戦になりがちです。でもこの講義では、チーム間の競争をゴールにしません。最初から「クラス全体の成功」を目指す前提を置きます。
理由はシンプルで、企業の中のチームが本来そうだからです。
個々のチームとして成果を出しても、全体として価値提供が遅れたり、チーム間の分断（サイロ化）が進んだりしたら、組織としては負けてしまいます。なので授業でも、学習環境を“システム”として設計します。
詳細は次章でも触れますが、この講義では、クラス全体や別チームへの貢献につながる行動が、より高い評価にもつながるようにしています。
- 詰まっているチームがいたら、助けに行く
- うまくいった工夫は「勝ち札」にせず、共有する
- わからないことがあれば、抱え込まずに助けを求める
最初に「クラス全体の成功」が授業のゴールだと認識を揃えるだけで、情報の流れが良くなり、結果的に各チームの学習速度も上がっていきます。
コーチ陣の中で印象に残っているのが、4週目の開発日に起きた出来事です。
学生の1人が「静的画像の挿入方法を知っている方はいませんかー！？」と大きな声を出して、クラス全体に助けを求めてくれました。学生の皆さんは研究室が異なると面識がほとんどないそうです。そんな状況にもかかわらず、授業の趣旨を理解して助けを求めるという勇気ある行動を取ってくれました。
その一歩がきっかけになって、以降はチーム間の交流が目に見えて活発になりました。
「助けを求める」が許される空気ができると、クラス全体のボトルネックが一気に減ります。
そしてこの講義では、こうした“助け合い”や“知識の共有”も含めたチーム開発の実践を、ルーブリックで評価対象として明確にしています。
3. 評価はプロダクトの出来ではなく、チーム開発の実践をルーブリックで見る
この授業では、テストは実施しませんし、プロダクトの出来栄えだけで評価を決めません。
代わりに、チーム開発に必要なふるまいを段階的に整理したルーブリック（達成目標）を用意し、学生がどこまで到達できているかを見ています。
ここで私たちが意識しているのは、企業の開発現場で求められる “チームとして価値を出し続ける力” を育てることです。
Lv4は「高度専門人材」の定義（＝企業でも“できるエンジニア”のふるまい）
ルーブリックのLv4は、私たちコーチ陣が考える「高度専門人材」を言語化したものです。
一言で言うと、自分の担当だけを進める人ではなく、チームや周囲の状況を観測し、必要なら働きかけて全体の成果を前に進められる人。企業の中でも「できるエンジニア」と呼ばれる人たちのふるまいを目指してほしい、という背景があります。
単位認定の条件はシンプルにしている
この授業では、ルーブリックの中でも特に重視している項目があります。
それが 「他チームやクラス全体の成功に向けた貢献」 です。
そして運用としては、この項目のLv1を達成すれば単位を出す、という設計にしています。
（逆に言うと）他の項目は、授業の中で伸ばしていくための努力目標（ストレッチ）という位置づけです。
この設計にしているのは、「まずは最低限、チーム開発に参加し、クラスという学習環境にコミットする」という土台をはっきりさせたいからです。
どう評価しているか：毎回のレポート（日報）で“事実”を拾う
評価は、毎回チームに書いてもらっているレポート（日報）を中心に、コーチ陣が確認して行っています。
狙いは、成果物の出来だけを見て判断するのではなく、授業の中で起きている
- 何に困って、どう動いたか
- 何を観測して、何を判断したか
- どんな学びがあり、次に何を変えるのか
- チームやクラスにどんな貢献があったか
といった“プロセスの事実”を拾うことです。
ルーブリックがあることで、学生側も「次はここを伸ばせばいい」と自己調整しやすくなり、評価が単なる採点ではなく、学習の道しるべになっていきます。
4. “動くソフトウェア”を必ずリリースする。学びを前に進めるため
この授業では、検証可能なインクリメント（動くソフトウェア）を必ず出します。
動くものがなければ、仮説の検証も計測もできません。
計測できなければ「何が良かった／悪かったか」が分からない。分からなければ、次に何を変えるべきか判断できません。だからこの授業では、「まず出す」を仕様にしています。
- 価値を小さく分割して出す
- 早く見せて、早く確かめる
- 「作った」より「確かめた」を増やす
ここで学生が最初につまずきやすいのは、「ちゃんと作り込んでから見せたい」という気持ちです。気持ちはよく分かります。でも、完成を待つほどフィードバックは遅れ、手戻りも大きくなります。授業では、完成度を上げる前に“学べる形”を優先します。
「全部入りを目指す」のではなく、“今回は何を確かめたいか”を先に決めて、その検証に必要な最小限だけを実装してリリースする。この切り替えができたチームほど、レビューで得られるフィードバックの質が上がり、次の開発サイクルの意思決定も速くなります。
実際、初めてのユーザーレビューを終えた学生からは、こんな振り返りがありました。
「今までターゲットユーザーを幅広く取ってしまいやるべきことがぼやっとしていたが、ターゲットユーザーを絞ることでやるべきことが明確になった。」
「受けたフェードバックから、必要とされている機能やアプリの現在の課題について考えることができた。また、アプリの方向性についてチーム内での解像度を高めて共有し、実装機能の計画を立て直すことができた。」
未完成を見せるのは勇気が要ります。でもそこを越えたチームほど、伸びが速いです。リリースはゴールではなく、学びのスタート地点です。
5. 意識的に立ち止まる：ふりかえりとリプランニングを“授業の仕様”にする
アジャイル開発は速く回すことが注目されがちですが、実は同じくらい大事なのが「立ち止まる」ことです。闇雲に走り続けるのではなく、現在地を確認して学びを積み上げることが、次の確実な一歩につながります。
だからこの授業では、立ち止まる時間を“気分”ではなく、予定の中に組み込むようにしています。
ふりかえりは2種類：1日のふりかえりと開発サイクルのふりかえり
この講義でのふりかえりは、大きく2つあります。
1つ目は、授業の終わりに行う「1日のふりかえり」です。
今日うまくいったこと・発生した問題・改善することを言語化し、次回の授業でどう動くかを軽く整えます。短い時間でもここで一度立ち止まるだけで、次回のスタートが変わります。
2つ目は、開発サイクルの終わりに行う「レトロスペクティブ（※）」です。
こちらはチームの働き方そのものを見直す場で、開発サイクルでの経験を振り返り、次に生かすために「何を変えるか」を決めます。
※「ふりかえり」だけだと日次とサイクルの区別がつきにくいため、授業では呼び分けています。
ポイントは、どちらも「気をつける」で終わらせず、行動に落とすこと。ふりかえりが“会話”で終わるか、“改善の実装”までつながるかで、学習速度は大きく変わります。
最初のサイクル直後にビッグ・リプランニング
もう一つ、この授業ならではの止まり方が ビッグ・リプランニングです（ちょっとした言葉遊びも込めています）。
これは、最初の開発サイクルが終わった直後に、あえて一度大きく立ち止まり「計画そのもの」を見直す時間として入れています。15回の授業のうち1回分をまるごと使うので、しっかり時間を取って考え直せます。
狙いは、初回の仮説検証（初回のユーザーレビュー）を終えた段階では、前提が大きく揺らぐことが多いからです。実際、チームによっては「作り続ける」より「方向転換（ピボット）」が必要になることもありました。
ビッグ・リプライニング後のレポートには以下の記述もありました。
「開発の進みが悪いことに焦っていたが、いったん立ち止まって見直したことで、アプリの方向性自体を変えるという思い切った決断ができた。」
立ち止まることは、遅くなることではない
チームによっては、ビッグ・リプランニングで残った時間を使い、スキル不足を補うための勉強会を開いていました。早い段階で“つまずき”を解消しておくことが、その後の開発速度向上につながります。
ふりかえりやリプランニング、勉強会を入れると、一見“開発時間が減る”ように見えます。でも実際は逆で、ここで前提を揃え、学びを言語化しておくほど、次に「何を作るか」「どう進めるか」で迷いにくくなり、結果として前に進むスピードが上がります。
この授業で「立ち止まること」を大事にしているのは、スピードを落とすためではなく、学びを前に進めるためです。
おわりに
この授業で私たちが大切にしているのは、スクラムの型を覚えることよりも、観測して適応する（経験主義）ことと、チームが自分たちで最適化していく自己組織化が育つことです。
そのために、授業は「チーム対抗戦」ではなく「クラス全体の成功」をゴールに置き、ルーブリックでも貢献や協働を評価の中心に据えました。さらに、動くソフトウェアを必ずリリースして学びを前に進め、ふりかえりやリプランニングで意図的に立ち止まる時間も予定に組み込んでいます。
なお、授業はまだ折り返し地点。
残り半分で起きる変化や学びも含めて、続編としてまたブログにまとめる予定です。
