educational_requirements:課題解決型学習_pbl
目次
課題解決型学習(PBL)
基本情報
| 項目 | 内容 |
|---|---|
| 科目名 | 課題解決型学習(PBL: Project Based Learning) |
| 所要時間 | 66時間(1日3時間×22日間) |
| 対象者 | 新入社員 |
| 前提知識 | プログラミング基礎、データベース基礎 |
教育目的
課題解決型学習を通して社会人基礎力を身につける。チーム開発を経験し、顧客の課題を解決するシステムを企画から実装・発表まで一貫して行う。ペルソナ定義、情報設計、外部設計、内部設計、プロジェクトマネジメント、プロトタイピング、実装、プレゼンテーションの各工程を実践的に学び、ユーザ・お客様に製品をアピールできる力を養成する。
到達目標
| No. | 到達目標 | 評価基準 |
|---|---|---|
| 1 | チーム開発の必要性を理解し、役割分担とコミュニケーション計画を策定できる | チーム計画書を作成し、合意形成ルール・役割分担・コミュニケーション計画が明確に定義されている |
| 2 | ペルソナを定義し、カスタマージャーニーマップを作成できる | ペルソナのプロフィールとカスタマージャーニーマップ(As-Is版・To-Be版)を作成できる |
| 3 | 開発テーマに関する情報を洗い出し、整理・分類して情報モデルを定義できる | 情報定義書・情報モデル定義書を作成できる |
| 4 | 外部設計(画面一覧・機能一覧・画面遷移図・画面仕様書)を作成できる | 情報の状態遷移図から外部設計書を作成できる |
| 5 | 内部設計(テーブル定義書・ER図・CRUD図・機能設計書)を作成できる | DBMSを使用する場合は正規化されたテーブル設計ができる |
| 6 | WBSとかんばんを用いてプロジェクトを管理できる | タスクの洗い出し、WBS、ガントチャート、かんばんを作成できる |
| 7 | プロトタイプを作成し、設計通りに動作する製品を実装できる | 画面遷移図通りに動作するプロトタイプ・製品を作成できる |
| 8 | 効果的なプレゼンテーションで製品をアピールできる | ホールパート法を用いて制限時間内に製品の価値を伝えられる |
スケジュール概要
| 日数 | 内容 | 時間 |
|---|---|---|
| Day 1 | 講義の説明とチーム計画 | 3時間 |
| Day 2-3 | 情報設計(ペルソナの決定) | 6時間 |
| Day 4 | 情報設計(情報定義書) | 3時間 |
| Day 5-6 | 外部設計 | 6時間 |
| Day 7-8 | 内部設計 | 6時間 |
| Day 9 | プロジェクトマネジメント | 3時間 |
| Day 10 | プロトタイプ作成 | 3時間 |
| Day 11-17 | 実装と中間発表 | 21時間 |
| Day 18-19 | 成果発表会準備 | 6時間 |
| Day 20 | 成果発表会リハーサル | 3時間 |
| Day 21 | 成果発表会 | 3時間 |
| Day 22 | 振り返り | 3時間 |
学習内容
第1部:講義の説明とチーム計画(3時間/Day 1)
- 講義の説明
- 目的:課題解決型学習を通して社会人基礎力を身につける
- チーム開発を経験する
- 企画を実際に形にする
- ユーザ・お客様に製品をアピールする
- 本講義でのルール
- 合意した内容に変更が生じる場合には事前に報告して調整する
- 心がけて欲しいこと
- 決められた時間内に終わらせる
- 演習における気づきを共有する
- PDCAを小さく沢山繰り返す
- インターネット上の情報を自ら活用する
- 英語の資料を読むこと
- タスクの関係を常に意識する(前のタスクの成果物を利用しているか、飛躍がないか、漏れがないか)
- チーム開発について
- なぜチームなのか
- 規模が大きな作業への対応
- 個人能力の相互補完によるチーム能力の拡大
- 相互学習による個人能力の拡大
- 相互補完による作業継続性の向上
- 個人の視点からチームの視点へ
- 役割分担(MECE:重複なく・漏れなく)
- コミュニケーション計画(会議体、レビュー、振り返り)
- (演習)チーム計画書の作成
- チーム分け・チーム名決定
- 合意形成ルールの決定
- コミュニケーション計画の作成
- 役割分担の決定(プロジェクトマネージャ、リーダ、サブリーダ、デザイン担当、開発担当等)
- (成果物)「チーム計画書」
第2部:情報設計・ペルソナの決定(6時間/Day 2-3)
- ブレインストーミング
- 情報設計の流れ(前半)
- 取り組む課題を決定する
- 前提条件:世の中でまだ解決されていない「課題」であること
- 開発テーマを決定する
- 前提条件:情報処理をともなうシステムの開発であること
- ペルソナを定義する
- 誰に対して価値を提供するのかを想定し、描き出した象徴的な人物像
- ペルソナの属性例:名前、年齢、性別、居住地、仕事、生活パターン、価値観、課題、家族構成、趣味や興味の対象、インターネットの使用状況等
- カスタマージャーニーマップを2枚作成する
- As-Is版:現在の状況
- To-Be版:顧客が満足するまでの経緯
- (演習)ペルソナとカスタマージャーニーマップの作成
- 取り組む課題を決定する
- 開発テーマを決定する
- ペルソナを定義する
- カスタマージャーニーマップを2枚作成する
- (成果物)
- 「取り組む課題」
- 「開発テーマ」
- 「ペルソナのプロフィール」
- 「カスタマージャーニーマップ」2枚(As-Is版、To-Be版)
第3部:情報設計・情報定義書(3時間/Day 4)
- 情報設計の流れ(後半)
- 開発テーマで登場する情報を全て洗い出して列挙する
- 洗い出した情報を整理・分類する
- 整理:必要な情報を残し、不要な情報を捨てる
- 分類:情報をカテゴリ分けする
- オープン・カードソーティング
- クローズド・カードソーティング
- (演習1)情報定義書の作成
- ペルソナのプロフィールとカスタマージャーニーマップを考慮しながらブレインストーミング
- 挙がった情報を列挙
- 情報を整理・分類
- (演習2)情報モデル定義書の作成
- 情報定義書を元に情報モデルを定義する
- 情報を処理する単位を意識して情報モデルを洗い出す
- (成果物)
- 「情報定義書」
- 「情報モデル定義書」
第4部:外部設計(6時間/Day 5-6)
- 外部設計とは
- 要件定義の次に行われる開発工程
- ユーザ・お客様とチームの共通認識ができるようになる
- 開発対象システムの外側とのやり取りに必要な情報を設計・定義
- 必要な機能と画面を洗い出す方法
- 「情報定義書」からカテゴリ分けした情報がどのように状態遷移するか決定する
- 情報を状態遷移させるのが「機能」であり「画面」になる
- 情報モデルの状態遷移(CRUD: Create Read Update Delete)
- (演習)外部設計書の作成
- 情報モデル定義書から情報の状態遷移図を作成する
- 情報の状態遷移図から画面一覧・機能一覧・画面遷移図・画面仕様書を作成する
- (成果物)
- 「情報の状態遷移図」
- 「外部設計書」(画面一覧、機能一覧、画面遷移図、画面仕様書)
第5部:内部設計(6時間/Day 7-8)
- 内部設計とは
- 外部設計をシステム内部でどのように実現するのかを仕様として定義
- 要件を仕様(設計書)に変換する
- システムの具体的な動作を決める作業
- DBMSについて
- データベース管理システムの役割
- DBMSを使った場合のメリット(アクセスの標準化、クエリによる高速化)
- 内部設計で行うこと
- データベース設計
- 正規化(第一正規化→第二正規化→第三正規化)
- テーブル定義書
- ER図
- CRUD図
- 機能設計
- 項目の入力チェック
- ボタンの動作
- 初期設定
- (演習)内部設計書の作成
- DBMSを使用するチーム:テーブル定義書、ER図、CRUD図、機能設計書
- DBMSを使用しないチーム:正規化したデータ、ファイル設計書、機能設計書
- (成果物)「内部設計書」
第6部:プロジェクトマネジメント(3時間/Day 9)
- スケジューリング手法
- 必要なタスクを洗い出す
- WBS(Work Breakdown Structure)
- かんばんによるタスク管理
- 「Todo」「Doing」「Done」の3つの状態でタスクを管理
- (演習1)疑似プロジェクトのかんばん作成
- 「学校での発表会プロジェクト」「宴会プロジェクト」「海外旅行プロジェクト」のいずれかを選択
- 担当者、所要時間、成果物、タスクの終了条件を決める
- (演習2)開発プロジェクトのかんばん作成
- 開発する製品について全てのタスクを洗い出す
- WBS、ガントチャート、かんばんを作成する
- (成果物)
- 「タスクの洗い出し」
- 「WBS」
- 「ガントチャート」
- 「かんばん」
第7部:プロトタイプ作成(3時間/Day 10)
- モックアップツール
- figma、Atomic、Fluid、NinjaMock、紙(紙芝居)
- 実行環境
- Netlify、Google Cloud Platform
- 開発ツール
- Bubble、Monaca、Unity
- (演習)プロトタイプ作成
- モックアップツールを利用し、外部設計で作成した「画面遷移図」の通りに遷移するプロトタイプを作成する
- (成果物)「画面遷移図通りに遷移するプロトタイプ」
第8部:実装と中間発表(21時間/Day 11-17)
- 実装作業
- 設計書に基づいた実装
- チームでの協力作業
- チームレビュー
- 実装内容の相互レビュー
- 品質向上のためのフィードバック
- 中間発表(Day 14頃)
- 進捗状況の報告
- 課題の共有と解決策の検討
- 日々の進め方
- 朝会(10分):本日の作業予定共有
- 実装作業(2時間30分)
- 終会(20分):進捗報告、課題共有、かんばん更新
第9部:成果発表会準備(6時間/Day 18-19)
- プレゼン手法
- 手順
- 伝えたいことを1〜3つ決める
- 伝えたいことを簡潔な文章(キャッチフレーズ)で書き出す
- 伝えるためのストーリー(プロット)を決める
- プレゼン資料の全体構成(アウトライン)を作成する
- 全体構成に沿ってプレゼン資料の各ページを作成する
- テクニック
- ホールパート法(全体-部分-全体)
- 例え話
- 発問
- 質問への対応方法
- スライド作成テクニック
- 高橋メソッド(短い単語や文章を大きな文字で表示)
- もんたメソッド(肝心な部分を隠し、説明直前に表示)
- プレゼン練習
- 制限時間内で伝えたいことが伝えられるよう練習
- 想定される質問と回答を準備
第10部:成果発表会リハーサル(3時間/Day 20)
- 製品の動作確認
- プレゼン資料の最終確認(プレゼンスライド、パネル、チラシ等)
- 当日役割の最終確認
- 通しリハーサル
- 本番と同じ流れでリハーサルを実施
- 時間配分の確認
- フィードバックと修正
第11部:成果発表会(3時間/Day 21)
- 製品の紹介プレゼン(チームで発表)
- 個人でのライトニングトークプレゼン(個人で発表)
- 質疑応答
- 審査・講評
第12部:振り返り(3時間/Day 22)
- 改善案策定
- 企画・製品の課題を洗い出し、改善策を検討してKPT形式でまとめる
- 企画を実際に形にすることができたか
- ユーザ・お客様に製品をアピールすることができたか
- ペルソナのアップデート
- 分析・KPTを通して今後どういう風に開発を進めるべきか
- 全体のKPT
- 課題解決型学習を通して社会人基礎力を身につけることができたか
- チーム開発を経験できたか
- (成果物)
- 「企画・製品のKPT」
- 「プレゼンスライド」
- 「製品」
- 「全体KPT」
- 成果発表会の感想
- 講師より総評
educational_requirements/課題解決型学習_pbl.txt · 最終更新: by dot
