Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
20260819_PBL Pub
Search
hikari
August 18, 2026
Technology
130
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
20260819_PBL Pub
20260819のPBL Pubでの登壇資料です。
hikari
August 18, 2026
More Decks by hikari
See All by hikari
20260912_スクフェス三河
kgnkhkr
0
250
20260801_スクフェス大阪
kgnkhkr
2
2.1k
20260711_スクフェス仙台
kgnkhkr
1
360
NakiNaviの紹介
kgnkhkr
0
48
手順書を作るときに意識していること
kgnkhkr
0
170
セキュリティ対策はじめました。 ~やったこと紹介~
kgnkhkr
0
320
Webサービスのためにクラウドにしていること(20230723CodePolaris)
kgnkhkr
0
280
Other Decks in Technology
See All in Technology
AI時代に顧客へ最速で価値を 届けるための試行錯誤 〜「AI × マネジメント」領域におけるmentoのケース〜
posterkeisuke
0
110
enechainの内製セルフサービスプラットフォーム
hiyosi
0
150
Reactの設計論
uhyo
14
7.4k
AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する
nwiizo
7
7.7k
20260906 「AWS運用入門」著者が教える、運用業務への生成AI活用入門
masaruogura
0
260
2026-09-09 【sigma_ucj#1】Sigma を IaC 管理したい! / IaC for Sigma
civitaspo
0
110
AI-DLCって実際どう? 〜聞きたいこと全部聞いてみる〜
news_it_enj
0
250
#jawssonic2026 あの時代が悪かった ~動かなかったSageMakerと共に迎えたイベント当日~
ktkn1129
0
140
AIとペアプロを始める。人とのペアプロをやめる。ペアプロの良さを改めて知る。もっと好きになった。 / Rediscovering Pair Programming
honyanya
1
330
深夜のクラウド懺悔室 1:29:300 or 1:0:0
kazzpapa3
1
230
作り直せるコードは迅速に 作り直せないDBは慎重に - AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話
kinosuke01
0
290
WAF 運用改善の承認サイクル/SRE_BizReach_MIXI_1
visional_engineering_and_design
2
410
Featured
See All Featured
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
560
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
Fashionably flexible responsive web design (full day workshop)
malarkey
408
67k
Embracing the Ebb and Flow
colly
88
5.2k
Pawsitive SEO: Lessons from My Dog (and Many Mistakes) on Thriving as a Consultant in the Age of AI
davidcarrasco
0
240
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
370
A Tale of Four Properties
chriscoyier
163
24k
Rebuilding a faster, lazier Slack
samanthasiow
85
9.6k
Highjacked: Video Game Concept Design
rkendrick25
PRO
1
450
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
270
The Mindset for Success: Future Career Progression
greggifford
PRO
0
490
Transcript
20260819 PBL Pub / 影中 光 体験型インターンシップをゼロから設計・改善した実践 ※本事例では市販のブロック玩具(LEGO®)を教材として使用しています。LEGO®はレゴグループの商標であり、本発表はレゴグループが後援・認可・提携するものではありません。
自己紹介 影中 光(かげなか ひかり) 横河レンタ・リース株式会社 / PMO・スクラムマスター • 計測器・PCレンタルを主軸に、社内でソフトウェア開発も展開 •
自社製品を開発するチームで PMO・スクラムマスターを担当 • 本インターンシップの企画から運営までを担当 2
本日の流れ 1 2 3 4 5 背景と概要 設計とリハーサル 実施と気づき 参加者の声
これからの課題 制約の中で何を目指したか 手探りで体験へ翻訳した 予想と現実のギャップ 入社したメンバーの声で検 証 改善とファシリテーター育 成 この発表の主題は 「インターン紹介」ではなく「どう設計・評価・改善するか」 です。 3
01 背景とインターンシップの概要 なぜ開発部がインターンを企画したのか。制約の中で描いたゴール。
インターンシップの背景と目的 ① 背景 人事の依頼を受け、開発部としてインターンを企画。 アジャイル開発を始めたばかりで、運営ノウハウはゼロからのスタート。 ② 目的 人事側:会社を知ってもらい、優秀な学生に出会うこと。 アジャイル開発の本質を、 現場側:働き方と社風を知ってもらい、入社後のギャップをできるだけ減らすこと。
体験として学べる場をつくる 5
制約とコンセプト ③ 4つの制約 期間が短い(2〜5日間) 座学で寝てしまうような時間は無しにしたい 実コード・社内環境に触れられない 機材貸与も避けたい ④ コンセプト ブロック教材で「2日間の体験型スクラム」のワークショップを設計
開催実績 過去3年 継続して開催 年2回 のペースで実施 今年で4回目 今年も実施 5
2日間のタイムライン DAY 1 | 導入・座学・スクラム体験 10:00 STEP 1 導入・座学 会社概要・事業紹介
DAY 2 | スクラム体験・振り返り・発表 90分 10:00 前日の振り返り・予定共有 10分 10:10 STEP 2 スクラム体験 スプリント準備(地図づくり) 60分 11:10 スプリント① 45分 11:55 昼食 60分 13:00 スプリント②③ 90分 14:30 STEP 3 振り返り 2日間の振り返り 45分 15:15 STEP 4 社員向け発表 発表準備 45分 16:00 社員向けプレゼン・レビュー 30分 16:30 クローズ 11:30 部や課の紹介 30分 12:00 昼食 60分 13:00 日程説明・チームビルディング 60分 14:00 アジャイル/スクラム入門(考え方の 紹介) 14:15 ブロック・スクラム説明 14:20 STEP 2 スクラム体験 計画準備・ユーザーストーリー作成 16:00 15分 5分 100分 クロージング 6
スクラム体験の概要 ① 題材とチームの役割 役割の割りふり 題材 ある家族が引っ越したいと思える街を作る 家族構成 祖父・祖母・父・母・息子(小学生)・娘(未就学児)・ペット (小型犬) 必須項目
役割 シミュレーションでの役割 担当 プロダクトオーナー ファシリテーター タイムキーパー 市長さん 社員一人 開発者 街づくりをする人 学生さん スクラムマスター 街づくりが円滑にできるように 手伝う人 社員1~2人 中堅+新卒社員 家族が住む家 / 駅 ② 開発サイクル前の準備 ― 5ステップ 1 › 2 › 3 › 4 › 5 要求を聞く ユーザーストーリー (要望メモ) 街の地図を描く 優先順位と見積り スプリントに入る 市長に質問し、 街のイメージを固める。 誰が・何のために・ 何を求めるかを書く。 施設の配置と 完成イメージをそろえる。 つくる順番と 作業量を決める。 リストの上から 実際につくり始める。 7
開発工程(1スプリント35分 × 3回) 「考える → 作る → 振り返る」を繰り返しながら学ぶ 何を作るか決める 5分
チームで相談し、今回作るもの を決める 作ってみる → 10分 完成品を見てもらう → 5分 振り返る → 次の挑戦を決める → 10分 5分 ブロック教材を使って形にする 市長役の社員から意見をもらう 良かったこと・改善したいこと を話す 次のサイクルで試すことを決め る 手を動かしながら考える フィードバックを受ける 学びを言葉にする 改善を体験する 設計意図(なぜこの順番か) 目的を共有する このサイクルを3回繰り返します。 (スクラムでは Planning / Development / Review / Retrospective に相当します)
02 インターンシップの設計 公開事例を手がかりに、大切な考え方を「体験」へ翻訳していく。
机上では分からない。だからリハーサル 1 2 公開事例を参考に › ブロック×スクラムの先行事例を下敷き に 4 5 体験へ翻訳
› 大切にする考え方を体験に落とし込む 6 課題発見 › スクラム未経験の社内メンバーで試走 3 社内に経験者はゼロ。手探りでスタート リハーサル実施 › スクラムマスター2名 で設計開始 改善して本番へ › ブロック不足・時間配分など机上で見え ない穴 柔軟性を持って当日に臨む 参考:スクラムワークショップ -Vol.01 レゴ®編 / 開発者向けブログ・イベント | GMO Developers 9
03 実際に起きたこと 「予想」と「実際」のギャップにこそ、PBL設計の学びがある。
学生とのコミュニケーション 設計時の予想 実際に起きたこと どんな学生が来るのだろう? 想像以上に素直で積極的 盛り上がらなかったらどうしよう… こちらの心配は、まったくの杞憂だった →
ブロック教材への慣れ 設計時の予想 実際に起きたこと 使いこなすまで時間がかかりそう すぐに慣れ、想像を超える作品を つくり始めた →
本当の山場はどこだったか 設計時の予想 実際に起きたこと 開発サイクル(スプリント)が一番盛り上がる はず 設計(街づくり)が一番盛り上がった 時間管理が難しかった → 止めるタイミングに悩んだ この経験から得た学び
「盛り上がっているけど、全体のために止める」という判断も、ファシリテーションの重要な仕事
引き出すより、整理する 設計時の予想 実際に起きたこと 意見が出ないかもしれない 意見がどんどん出る 沈黙したらどうしよう 整理するほうが難しかった → この経験から得た学び ファシリテーターは意見の引き出しから、収束までを設計する
学生と一緒に考える ① 想定外 ② 学生に相談 ③ 学生の反応 「20分でやります」 60分 →
20分 発表時間を遅らせる? それとも20分で準備する? → → 20分で準備するのと、 発表を遅らせるの、 どっちがいい? 本当に20分で学びをまとめ、 社員へプレゼンしてくれた。 この経験から得た学び 想定外が起きたら、全部運営側で解決しなくてもいい。状況を共有して、学生にも一緒に考えてもらう。
プレッシャーが、一番楽しい仕事になった 設計時の予想 実際に起きたこと 最初 現在 「ちゃんと進行できるだろうか」 → 開発部で一番好きな仕事 気持ちが変わったきっかけ 学生が、こちらの言葉でひらめく瞬間
説明と体験がつながり、理解が深まる瞬間 「もっと、こうした学びの場をつくりたい」
04 参加者の声から振り返るPBLの効果 設計の良し悪しは、参加者のその後が教えてくれる。
入社したメンバーへのアンケート(n=3) Q. 採用選考を受けるうえでの影響 Q. 入社を決めるうえでの影響 選考を受ける後押しになった 2名 入社を決める後押しになった 2名 選考を受ける大きなきっかけになった
1名 入社の決め手になるほど大きな影響があった 1名 「一緒に働くであろう先輩社員の雰囲気がわかり、就職後の働き方がイメージできたため、他社と比較したときに後押しになったと思う。」 「実際に働いている方の雰囲気を感じ取ることができ、web等で会社について調査するだけではわからないことが知ることができたから。」 Q.当時、一番学んだと感じたことは何でしたか? 「アジャイル開発について一番学べたと感じた。アジャイル開発についてはほとんど知らない状態であったため、レゴというわかりやすい題材を用いて体験出来て理解が深まっ た。」 「要件定義は都度変わるものだなと学びました。」 「レゴスクラムを通じて初対面のメンバーとチームをつくり上げていくこと」 Q.インターンで体験した内容と、実際の現場で共通していたこと・異なっていたことは何ですか? 共通していたこと 異なっていたこと 「インターン時には、働いている方の雰囲気が堅すぎないという印象を受けたが、 実際に入社しても同様の印象を受けた。」 「チームの雰囲気。大まかな仕事の進め方や流れ」 「配属先はアジャイル開発の部署ではなかったため、手を動かして学んだアジャイ ル開発は用いていなかった。」 「現場は、教科書通りにはやはりうまくいかない」 Q.今振り返って、インターンシップそのものに対して、「もっとこうだったら良かった」と思う点はありますか? 「特になし」 「当時はスクラムを実際する時間がかなり短く感じたと思う。一方で開催側になるとそこそこタイトでインターンシップに時間が取れるかといわれると泡しいので悩ましい ところである。」 18
設計者の仮説は正しかったのか? 設計時の仮説 ① 会社を知ってもらいたい → 参加者の声 → 考察 「Webだけでは分からない雰囲気が分かった」 会社理解は達成できた
「ブロック教材だから理解しやすかった」 体験重視の設計は伝わった 「実際の開発でも似た雰囲気だった」 仕事のイメージ形成に役立っ 入社後のギャップを減らしたい ② 体験から学んでもらいたい 体験でチーム開発を理解してほしい ③ 実際の仕事をイメージしてほしい 本質から仕事をイメージしてほしい ④ 次の改善につなげたい 参加者の声から改善点を見つけたい た 「配属された部署がアジャイル開発ではなかった。」 体験はあくまで一例。 部署によって働き方が異なることも伝える 必要がある。 分かったこと 参加者の声は、設計した学びが本当に届いていたかを確かめる材料になる。
05 これからの課題 続けているからこそ見えてきた、次の設計テーマ。
毎回価値がある。でも、毎年同じでいいのか ◎ 参加者にとって 毎回、新鮮で価値のある体験になってい る ! 運営者にとって 毎年ほぼ同じ内容の繰り返しになりがち 改善を積み重ねるべきか? それとも、大きく作り変えるべきか?
20
ファシリテーター育成で難しかったこと ― スキルトランスファーできること・できないこと ― 進行は教えられる。でも“場づくり”は難しい。 形式知化できたこと まだ暗黙知が多いこと 運営マニュアルとして共有可能 “判断”や“空気づくり”は言語化が難しい ✓
当日の流れ いつ介入するか ✓ 各サイクル(スプリント)の進め方 いつ見守るか ✓ レビューの進行方法 学生の強みをどう見つけるか ✓ 追加要求・変更要求の入れ方 場の盛り上がりをどう作るか ✓ 時間管理の考え方 学生が安心して発言できる空気をどう作るか ✓ グラウンドルール 声掛け・場づくりの工夫(マニュアル化した例) 無意識に行っていた判断の例 まず肯定を返す ―「いいですね!」「なるほどね!」 静かなときは音楽を流す 「議論が止まりそう→介入」「この学生は見守ろう」「今は時間を優先」
つくって、学んで、また設計する 01 制約から、体験を設計する 02 予想は外れる。試して直す 03 届いたかは、参加者の声で確かめる 04 難しいのは"場づくり"の継承 ご清聴ありがとうございました
※本事例では市販のブロック玩具(LEGO®)を教材として使用しています。LEGO®はレゴグループの商標であり、本発表はレゴグループが後援・認可・提携するものではありません。