オリエンテーション〜PBLの全体像とWhy

• 日程: Day 1 / セッション 1
• 時間: 09:30-10:00（30分）
• 形式: 座学（対話型解説）
• ゴール: 22日間の研修の5フェーズ（企画→設計→実装→発表→振り返り）を順番に挙げ、PBLで何が身につくかを1分以内に自分の言葉で説明できる
• 学習形式: 対話型解説

ようこそ。今日から22日間、皆さんは「課題解決型学習（PBL: Project Based Learning）」という旅に出ます。教科書を順に読むのでもなく、講師の話を一方的に聞くのでもありません。チームで本物の製品をつくり、最後に発表するという具体的なゴールに向かって、必要なことを順番に学んでいきます。

少しだけ問いかけてみます。皆さんが「学校で習ったプログラミング」と、「会社で求められるプログラミング」、何が違うと思いますか？
答えはたくさんありますが、最大の違いの1つは「誰のために、何を、なぜ作るのか」を自分たちで決めなくてはいけないことです。仕様書が降ってくるのを待つ受け身では、何も始まりません。

このセッションでは、22日間でやることの全体地図と、進めるときの3つの大切な心がけを共有します。地図を持っていれば、明日以降「今日はこの位置にいる」とわかります。これが安心と集中につながります。

PBL（Project Based Learning）とは、文字通り「プロジェクトに取り組むことで学ぶ」学習法です。先に知識を全部詰め込んでから応用するのではなく、先にやってみて、必要になった知識をその場で学ぶスタイルです。

身近なたとえで言えば、自転車の練習に似ています。自転車の物理学を100時間勉強してから乗り始める人はいません。ふらつきながら乗ってみて、「もう少しペダルを強く踏もう」「ハンドルを固めよう」と試行錯誤します。PBLも同じで、まず作り始めて、つまずいた箇所で必要な技術を学びます。

なぜこの形が新人研修で採用されているのでしょうか。答えは、実際の仕事がそうだからです。会社の業務には決まった「教科書の章立て」はなく、目の前の課題から逆算して必要なことを学んでいく。その動き方そのものを、22日間で体に染み込ませます。

たとえば「ペルソナを定義する」というタスクがDay 3 にあります。これを座学だけで学んだら、「ペルソナとはターゲットユーザーの代表像のこと」という1行で終わってしまいます。本研修では、実際に自分のチームの開発テーマに対してペルソナを書いてみて、AIにインタビューしてもらい、矛盾を指摘されるところまで体験します。1行で覚えた知識と、汗をかいて作った知識は、定着の深さが桁違いです。

「全部理解してから進みたい」と感じる人ほど、PBLでは最初に苦労します。6割わかったら次に進むくらいの勇気が必要です。残りの4割は、次のタスクをやるうちに自然と埋まります。

「Project Based Learning」という言葉は20世紀初頭の教育哲学者ジョン・デューイの「Learning by Doing（為すことによって学ぶ）」に源流を持ちます。デューイは「教育は生活の準備ではなく、生活そのものである」と言いました。
皮肉なことに、デューイの理論は100年以上前のものなのに、いまだに多くの教室は「先生が話す→生徒が聞く」スタイルのままです。皆さんはこれから22日間、デューイの夢を実践することになります。

22日間は次の5つのフェーズで構成されます。順番には意味があり、前のフェーズの成果物が次の入力になります。

ここで覚えてほしいのは、**「企画→設計→実装→発表→振り返り」**の順番です。実は皆さんが将来関わるどんなシステム開発も、この骨組みでできています。これを「ソフトウェアライフサイクル」と呼びます。

質問してみます。「設計」をすっ飛ばして「実装」から始めたら何が起きるでしょうか？
たとえば家を建てるときに、設計図なしでいきなり柱を立て始めたら——途中で「あ、ここに窓が必要だった」「キッチンの配管が通せない」と何度もやり直すことになります。プログラムも同じで、設計のないコードはすぐに行き詰まります。

22日間で大切にしてほしい心がけが3つあります。

心がけ1: PDCAを小さく沢山繰り返す

PDCAとはPlan（計画）→Do（実行）→Check（確認）→Act（改善）のサイクルです。1ヶ月かけて1周するのではなく、1日のなかで何周も回します。たとえば「30分で画面1つを試作→チームに見せて意見をもらう→直す」を1サイクルとして繰り返します。小さく失敗すれば、ダメージは小さくて済みます。

心がけ2: タスクの関係を常に意識する

毎日新しいタスクをやりますが、すべて前のタスクとつながっています。「前のタスクの成果物を本当に使っているか？」「飛躍はないか？」「漏れはないか？」を自問してください。たとえばDay 3で作ったペルソナを、Day 5の画面設計で全く参照していなかったら、何のためにペルソナを作ったのかわかりません。

心がけ3: 決められた時間内に終わらせる

PBLではすべての演習に「制限時間」があります。完璧を目指して時間オーバーするより、6割の出来でも時間内に出す方が価値があります。なぜなら、6割の成果物があれば次のタスクが始められますが、未完成のまま時間切れになると、次のタスクが何も始められないからです。

3つの心がけはどれも、**「完璧主義の罠」**から抜け出すための言葉です。新人ほど「全部わかってから・きれいに作ってから」と思いがちですが、それは多くの場合、進まない言い訳になります。

本研修はAI協働型です。生成AI（ChatGPT、Claudeなど）を「もう一人のチームメンバー」として常時活用します。AIは次のような場面で活躍します。

• 壁打ち相手: アイデアを話す相手として
• 質問の整理: モヤモヤを言語化する手伝い
• 深掘り役: 「もっと具体的に」「別の例は？」と聞く
• レビュア: 自分が作ったものに弱点がないか指摘してもらう

ただし大切なルールが1つあります。AIに「答えを書かせる」のではなく、AIと「対話して自分が理解する」。たとえばコードを書くとき、丸ごとAIに書かせると、自分は何も理解できないままになります。それでは22日間の意味がありません。

AIにわからないことを聞くときは、こういう聞き方を試してみてください。

• 「〜の概念を、料理にたとえて説明して」
• 「〜と〜の違いを、具体例を3つずつ挙げて教えて」
• 「私はこう理解したけど、間違っていない？」（自分の理解をぶつける）

最後に、22日間で1つだけ絶対に守ってほしいルールを共有します。

合意した内容に変更が生じる場合には、事前に報告して調整する

これは本研修の根幹ルールです。チームで決めたことを誰かが勝手に変えると、信頼が壊れ、他のメンバーの作業が無駄になります。「変えたい」と思ったら、必ず事前にチームに伝えて、合意してから変えます。

これは社会人として最も大切な約束事の1つでもあります。締切を変えたい、設計を変えたい、担当を変えたい——すべてに当てはまります。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「PBL（Project Based Learning）と一般的な研修の違いは何ですか？具体例を交えて教えて」
• 「『PDCAを小さく沢山』と『大きく1回』の違いを、開発の例で説明して」
• 「AIを学習パートナーにするとき、やってはいけない使い方は何ですか？」

このセッションでは、3つのことを共有しました。

1. PBLとは「やりながら学ぶ」スタイル。実際の仕事の進め方そのもの
2. 22日間の地図は「企画→設計→実装→発表→振り返り」の5フェーズ
3. 心がけ3つ: PDCAを小さく沢山、タスクの関係を意識、時間内に終わらせる
4. AI協働型: AIを答えの出力装置ではなく、対話相手として使う
5. 根幹ルール: 合意の変更は事前に報告

次のセッションでは、いきなりAIとの対話を始めます。「身近な課題」を1つ選んで、AIと一緒に解決アイデアを3つ以上出してもらいます。今日学んだ「AIとの対話の作法」をさっそく試す場です。

• 22日間の5フェーズを順番に言えますか？
• 「PDCAを小さく沢山」とは、具体的にどんな進め方ですか？
• AIに「答えを書かせる」のと「対話する」の違いは何ですか？
• 根幹ルール「合意の変更は事前に報告」を破るとチームに何が起きますか？

• 参考リンク

  • ジョン・デューイ『学校と社会』（教育哲学の古典）
  • PMI『PMBOKガイド』（プロジェクトマネジメントの世界標準）
• 発展課題

  • 自分が過去に「設計せずに作って失敗した」経験を1つ思い出し、ノートに書く
  • AIに「ソフトウェアライフサイクルとPBLの関係」を3つの例で説明してもらう