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

• 日程: Day 1 / セッション 1
• 時間: [9:30-10:00]
• 形式: 座学
• ゴール: 22日間の研修の流れ（企画→設計→実装→発表→振り返り）を、自分の言葉で1分以内に説明できる
• 学習形式: 対話型解説

いよいよ今日から22日間のPBL（Project Based Learning: 課題解決型学習）が始まります。

ここで最初の問いかけです。
「学校の勉強と、会社の仕事。一番大きな違いは何だと思いますか？」

少し考えてみてください。いろいろな答えがあると思いますが、大きな違いの1つは「正解が用意されていない」ことです。

• 学校のテスト: 問題が与えられ、正解が決まっている
• 会社の仕事: 課題を自分で見つけ、解決策も自分たちで作る

PBLは、この「正解のない課題」に取り組む練習です。22日間でみなさんはチームを組み、世の中の課題を見つけ、それを解決するシステムを企画から実装・発表まで一貫してやり遂げます。

このセッションでは、22日間の「地図」を手に入れます。地図があれば、いま自分がどこにいて、次にどこへ向かうのかを予想しながら学べます。

この研修の目的は、ずばり**「課題解決型学習を通して社会人基礎力を身につける」**ことです。

具体的には次の4つを経験します。

• チーム開発を経験する
• 企画を実際に形にする
• ユーザ・お客様に製品をアピールする
• 上記を通して社会人基礎力を身につける

「社会人基礎力」とは何でしょうか。たとえるなら、スポーツ選手の基礎体力のようなものです。野球でもサッカーでも、走る・跳ぶ・体幹を支える力はすべての土台になります。同じように、どんな職種でも必要になる「前に踏み出す力」「考え抜く力」「チームで働く力」が社会人基礎力です。

ここで考えてみてください。
「プログラミングの文法を覚えること」は社会人基礎力に該当するでしょうか？

該当しません。文法の知識は特定の技術スキルです。一方、「エラーで詰まったときに自分から調べて質問する」「チームの遅れに気づいて声をかける」といった行動は社会人基礎力に該当します。なぜなら、技術が変わっても通用する、仕事の進め方そのものの力だからです。

PBLでは、講義を聞くだけでは身につかないこれらの力を、実際にプロジェクトをやってみることで鍛えます。

• この研修の主役は講師ではなくみなさん自身。AIを学習パートナーにして、自分たちで進める
• 知識のインプットが目的ではなく、「やってみて、できるようになる」ことが目的
• よくある間違い: 「きれいな成果物を作ること」が目的だと思ってしまう。正しくは「成果物を作る過程で力をつける」ことが目的

PBLの源流は、1960年代のカナダ・マクマスター大学の医学部にあります。「講義で解剖学を暗記した学生が、実際の患者を前にすると何もできない」という問題意識から、「最初から患者の症例（課題）を与えて、必要な知識を自分で調べさせる」教育法が生まれました。いまではエンジニア教育の定番ですが、もともとは「お医者さんを実戦で使える人にする」ための方法だったのです。みなさんも22日後には「実戦で使えるエンジニアの卵」になっているはずです。

22日間の全体像を見てみましょう。

各フェーズでやることは次の通りです。

これは料理に例えると分かりやすいです。

• 企画 = 「誰に何を食べてもらうか」を決める（献立決め）
• 設計 = レシピを書く
• 実装 = 実際に調理する
• 発表 = 盛り付けて、お客様に提供する
• 振り返り = 食べた人の感想を聞いて、次に活かす

ここで少し考えてみてください。
「レシピを書かずに、いきなり調理を始めたらどうなるでしょうか？」

材料が足りない、手順が前後する、味がバラバラ……といった失敗が起きます。システム開発も同じで、設計を飛ばして実装すると、あとで大きな手戻りが発生します。だからこの研修では、Day 10まで一切コードを書きません。じれったく感じるかもしれませんが、それには理由があるのです。

• 全体の流れを先に知っておくと、「いまの作業が次のどこで使われるか」を予想しながら学べる
• 各日の成果物は、次の日の入力になる（例: ペルソナ→CJM→情報定義書→設計書）
• つまずきやすい点: フェーズの名前を暗記しようとすること。大事なのは順番と「なぜその順番か」

「企画→設計→実装」の流れは、建築の世界では何千年も前から行われてきました。古代ローマの建築家ウィトルウィウスは紀元前1世紀に「建築書」で設計の重要性を説いています。一方、ソフトウェア開発でこの流れが整理されたのは1970年頃、「ウォーターフォールモデル」としてです。建築に比べるとソフトウェア工学はまだ50年ちょっとの若い分野。だからこそ、いまもみなさんのような新しい世代が開発のやり方を進化させ続けています。

この研修で特に心がけてほしいことを3つに絞って紹介します。

その1: PDCAを小さく沢山繰り返す

PDCAとは Plan（計画）→ Do（実行）→ Check（確認）→ Act（改善）のサイクルです。

ポイントは「小さく」「沢山」です。たとえば自転車の練習を思い出してください。1時間かけて完璧な理論を学んでから乗るより、「ちょっと乗る→転ぶ→直す→また乗る」を繰り返した方が早く上達しますよね。

• 良い例: 30分作業したら一度チームで見せ合い、方向を確認する
• 悪い例: 3時間黙々と作り込んでから見せたら、方向が違っていて全部やり直し

その2: タスクの関係を常に意識する

各タスクで、次の3つを自問してください。

• 前のタスクの成果物を利用しているか？
• 飛躍がないか？
• 漏れがないか？

この研修の成果物はすべて鎖のようにつながっています。前の成果物を見ずに作ると、鎖が切れて品質が一気に落ちます。

その3: 時間内に終わらせる＆気づきを共有する

• 決められた時間内に終わらせる（完璧より完了）
• 演習での気づきをチームに共有する
• インターネット上の情報やAIを自ら活用する（英語の資料にも挑戦）

そして本講義で最も大事なルールがこれです。

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

このルールの意味は、今日のセッション4（チーム計画書の作成）で実感することになります。

• 「完璧な成果物を時間オーバーで出す」より「80点の成果物を時間内に出す」が正解
• 困ったら1人で抱え込まない。チームとAIに相談するのが正しい姿
• ルール「事前に報告して調整」は、仕事における信頼の基本動作

PDCAサイクルの考え方を日本に広めたのは、アメリカの統計学者デミング博士です。戦後の1950年に来日して品質管理を講義し、日本の製造業はこれを徹底的に実践して世界一の品質を実現しました。面白いのは、本家アメリカでは長く忘れられていて、1980年代に「日本の品質はなぜ高いのか」を逆輸入で学び直したこと。「小さく沢山回す」は、日本のものづくりが世界に誇る知恵なのです。

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

• 「社会人基礎力の『前に踏み出す力・考え抜く力・チームで働く力』を、新入社員の1日の行動の例で説明して」
• 「PDCAを小さく回す具体例を、システム開発の場面で3つ挙げて」
• 「ウォーターフォールモデルとアジャイル開発の違いを、料理に例えて説明して」

今回学んだことを一言でまとめると、**「PBLは正解のない課題に挑む22日間の旅であり、企画→設計→実装→発表→振り返りという地図を持って進む」**です。

• 目的は社会人基礎力を身につけること。成果物はそのための手段
• 各フェーズの成果物は鎖のようにつながっている
• PDCAを小さく沢山、時間内に、チームとAIと一緒に

確認です。22日間の流れを、隣の人に1分で説明できますか？ 説明できたらこのセッションのゴール達成です。

次回（セッション2）は、いよいよ生成AIとのブレインストーミングを初体験します。この研修の学習スタイルの土台になる時間です。

以下の問いに答えられるか確認してみましょう：

• 22日間の5つのフェーズを順番に言えますか？
• この研修の目的（何を身につけるのか）を自分の言葉で言えますか？
• 「PDCAを小さく沢山繰り返す」とは、具体的にどんな行動ですか？
• 本講義で最も大事なルール（合意内容の変更時のルール）は何ですか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: 経済産業省「社会人基礎力」の解説ページ（「社会人基礎力 経済産業省」で検索）
• 発展課題: 自分が今いちばん伸ばしたい社会人基礎力を1つ選び、22日間でどう行動するかをAIと相談してメモに残してみましょう

このセクションは、受講者が理解を深めることをサポートする参考情報です。