9時間スプリントで仮説検証が回る！？学生のアジャイルは社会人への挑戦状だった

【IIJ 2025 TECHアドベントカレンダー 12/18の記事です】

はじめに

三河からこんにちは。名古屋支社の北河です。

2025年10月より、豊橋技術科学大学のPBL (Project Based Learning) 形式の授業「高度専門人材育成訓練演習」に、非常勤講師として関わることになりました。

大学のPBLは、講義で知識を受け取るだけでなく、現実の課題 (またはプロジェクト) を題材に、学生がチームで調査・設計・実行しながら学ぶ授業形式です。
出典：ChatGPT (OpenAI) との対話、2025年12月15日

この授業に関わることになったきっかけは、実行委員として参加しているスクラムフェス三河でした。地元の大学生にもフェスに来てもらい、リアルな開発現場の声を聞いて雰囲気に触れてほしい。そんな想いからスクラムフェス三河初代代表のまつしゅーさんが豊橋技科大に声をかけたご縁から、「大学でPBLをやってみよう」という流れになりました。東三河に生まれ東三河で育った自分に、豊橋技科大でのPBLをやらない選択肢はないですよね！

で、このブログでは授業内容の話そのものではなく、学生たちの成長や可能性を直に感じて思ったことを書きたいと思います。 特に今回は、何より強調したいこれを中心に書きたいと思います！

９時間で仮説検証が回るんです！

そもそもどんな授業をしているの？

授業の全体像や詳しい話は、同じ非常勤講師をしている オバマさん、@usk0513さん の記事がとても詳しいので、是非そちらを見てみてください！

教室を“学習する組織”にする：大学での授業をアジャイルコーチとして設計した話

Gitを教えることになったのでWebアプリ作ってみた

ここではざっくりだけ概要を説明します。

• 100名超の学生が22チームに分かれて、学生の課題を解決するプロダクトを開発
• 開発技術そのものを学ぶのではなく、仮説検証のフィードバックサイクルの大切さを学ぶ
• 「チーム間で最も優れたプロダクトを争う」授業ではなく、クラス全体の成功を目指す
• 作ったプロダクトは学内環境から触れる場所にリリースし、レビューで実際に触ってフィードバックを得る

日時	テーマ	授業内容
10/06(Mon) 14:40-17:50	開発準備	オリエンテーションとチーム決め
10/20(Mon) 14:40-17:50		チームで開発を進める上での講義と演習
10/27(Mon) 14:40-17:50		課題説明とプロダクト決め
11/10(Mon) 14:40-17:50	開発サイクル①	チームに分かれて開発
11/17(Mon) 14:40-17:50		チームに分かれて開発
11/26(Wed) 14:40-17:50		ユーザレビューとふりかえり
12/01(Mon) 14:40-17:50	ビッグ・リプランニング	開発環境や開発計画の見直し
12/08(Mon) 14:40-17:50	開発サイクル②	チームに分かれて開発
12/15(Mon) 14:40-17:50		チームに分かれて開発
12/22(Mon) 14:40-17:50		ユーザレビューとふりかえり
1/5(Mon) 14:40-17:50	開発サイクル③	チームに分かれて開発
1/19(Mon) 14:40-17:50		チームに分かれて開発
1/26(Mon) 14:40-17:50		プロダクト発表会
2/2(Mon) 14:40-17:50	ふりかえりと現場での実践	講座全体のふりかえり
2/9(Mon) 14:40-17:50		OST, 社会人との座談会, LT大会

…という前提の上で、ここから本題です。

ユーザレビューの日、学生が尊すぎて無理

教室が市場になる日。それがユーザレビューの日。

ユーザレビューは、動くプロダクトを実際に触ってもらうのが大前提です。
しかも、いわゆる発表会ではなく、バザール方式で行いました。各チームがブースを用意し、呼び込みの宣伝文を作り、来場者が自由に見て回り、触ってもらい、コメントや観察を記録していきます。

今回の授業で特に強調しているのはこれです。

• 「発表」ではなく「対話」が主役
• 完璧でなくてOK。使ってもらってフィードバックを得ることが目的

だから、教室が “市場” になるんです。「おおー便利！」「ここの操作迷った？」などの活発な対話がそこら中で起きるんです。

でも、初回のユーザレビューで22チームもいれば、動くプロダクトが間に合ったチーム、間に合わなかったチームが出てきます。

間に合わなかったチームは、「このままだと間に合わない」と判断して実装はいったん止め、プロダクトの仮説検証に必要なフィードバックをもらうためのやり方をチームで考えたうえで当日に臨んでいました。

スライドでイメージをつかんでもらう工夫をしたり、FigmaでUIだけでも再現してみたり…。そして、その工夫が功を奏して、ちゃんとフィードバックを拾って新しい価値に気づいていくんです。もうー苦しい。尊すぎる・・・。

そして、なぜ学生たちだけのユーザレビューでも必要なフィードバックをもらうことができたのか？そこにはちょっとした工夫があります。最初のテーマ決めの際に、最低限、次のルールを設けました。

• 学内で起こる困りごとを解決するプロダクトを作ってください。
  ターゲットとなるユーザはこの教室にいる人
• 教室の中だけでユーザテストができることが重要です

そうなんです、ターゲットユーザは自分たちなんです。自分たちが困っていることだからこそ、生きたフィードバックがもらえるのです。

なぜ「動くモノ」にこだわるのか

プロダクトが本当に受け入れられるのか、課題を解決できるのかは、机上で議論していても分かりません。見えない敵にワーワー言っているだけです。
実際に触ってもらって、迷ったり、止まったり、戻ったりするリアルな挙動を見て、そこで初めてズレに気づけます。

ユーザレビューは、インタビューだけでなく利用時の行動を観察するところまで含めています。
言葉の感想だけでなく、「そこで迷った」という事実の方が、次の改善に直結しますからね。

全員が開発できるわけじゃない。それでも「ゴールに向けて進む」もう尊すぎて無理。

ここは、授業の現実としてちゃんと書いておきたいです。

学生は全員が開発が得意なわけではなく、チームによって“強いところ”と“弱いところ”があります。でも、それでも前に進みます。止まらず進みます。

なぜかというと、このPBLは個人の開発力だけで勝負する授業ではなく、チームで考えて悩んで自分たちの答えを見つけて前に進むことが、そもそも求められているからです。

チーム構成も様々です。今回のチーム決めは学生たちに任せています。シンプルなルールだけ設けています。

「クラス全体の成功を目指せるようにチーム編成する」 これだけです。

仲の良いメンバーで集まる、研究室で固まる、問題ないです。スキルの高いメンバーで構成する、これも問題ないです。クラス全体の成功が出来れば良いです。

例えば、こんな考え方もできます。

• スキルの高いチームが良いやり方を見つける → 他のチームに教える → 全チームが底上げされる → クラス全体の成功につながる
• スキルの高いメンバーを分散させる → 各チームが自律して開発できる → クラス全体の成功につながる

今のチーム構成は、そうした考え方で学生たちがチーム決めをした結果です。ドラマがあるに決まってるじゃないですか。毎週レポートを読むたびに成長を感じて悶絶しています。尊すぎて無理。

9時間で仮説検証が回るんです！

さて、やっとここが今回のブログの主役です。ここまで何回悶絶したのやら…。

この授業は、開発2回→ユーザレビュー1回の3回の授業で1サイクルが回ります。

世の中では1週間スプリントだ、2週間スプリントだと言いますが、ここでは 「9時間スプリント」 です。

つまり、この9時間で何が起きるかというと、

• 授業2回(6時間)で 価値を検証できる“動くモノ”を用意する
• ユーザレビューで 触ってもらう、ふりかえりを行う
• そこで得たフィードバックから 仮説のズレを見つける
• 次の2回で 新しい仮説を実装して、また検査する

が、当たり前にできているんです。それも 9時間 ですよ！？

社会人の稼働感で言えば2日、もしくは1日で仮説検証まで回すスピード感です。

これ、胸に手を当てて考えてみてください。私たちの現場でも「スピード感を持って」なんて掲げがちですが、実際にはなかなか難しいやつですよね。
でも学生たちは、もちろん完璧じゃないし、詰まるし、思ったより開発が進まない日もあるのに、レビュー日に間に合わせて、ちゃんと「検証できる形」まで持ってくるんです。

だから、レビューの後にチームにさまざまな判断が迫られます。

• 「このまま行けそうだ」と確信を深めるチーム  
• 「このままだと使われない」と気づき、重点を変えるチーム
• そもそもニーズが薄く、ピボットを決断するチーム

そして重要なのは、どの判断にも 「早く分かった」 という価値があること。
時間をかけて作り込んだ後で「いやー、ちょっと受け入れられませんでした…」となるより、短い時間で「ズレてましたわー」を拾えた方が、次の一手は強くなります。

学生たちがこのサイクルを、9時間で回している。
もうね、この事実を気付いたときの自分には衝撃で、感動ポイントでもあります。さらに、自分にもブーメランのように刺さっています。何やってんの！学生ができてるんやで！って。

学生のアジャイルは、社会人の私たちへの「挑戦状」でもある

こう書くと、「所詮、まだ世の中に出せる品質じゃないでしょ？」とか「コードはめちゃくちゃなんでしょ？」とか、言いたくなる人がいるのも分かります。

もちろん、アーキテクチャやコード品質は大事です。エンジニアとしての矜持ですからね。
でも、時間をかけて丁寧に作った結果「ニーズがなかった」「使われなかった」になったら、ビジネス的には目も当てられません。

学生たちは、動くモノを出し、フィードバックをもらい、仮説を立て直して、また作る。
そのサイクルで価値を上げていく姿は、私たち社会人にとっても、かなり刺さる「挑戦状」だと思っています。「素人のうちらでもできてるで。百戦錬磨のプロの皆さん、どうですか？」って感じ。（学生はそんなこと言っていない）

そして豊橋技科大の学生は、技術だけではなく、考え方や行動もすごい。
わからないことを放置せず、試して、学んで、次に進む。その姿勢があるから、短いサイクルでもゴールに向かって前に進めているんだなぁ、と思っています。

そんなことを思いながら毎週食堂でカレー(大盛)を食しています。

おわりに

学生たちは尊いなぁ…なんてニコニコしていたら、思いっきり後ろからハンマーでぶん殴られることになりました。

私が所属している名古屋支社開発チームは、開発ベンダーでありながらアジャイルでお客様のビジネス拡大に貢献したい！と活動しています。が、このままでは学生たちに舐められっぱなしです！（学生たちはそんなこと言っていない）

「プロの本気を見せてやるよ！」ということで、私たちは常にガチンコでプロダクトやチームに向き合っています。

最近はアジャイルに関する相談や意見交換をする機会が増えています。リアルな話ができますので、興味がありましたら個人のXでも、IIJのXでもいいので、ぜひご連絡ください！

（写真の顔をバリーくんにする加工は、NanoBananaProさんにお願いしました）

---

執筆者X	@nk_tamago ※意見は個人のものです