AIIT(産業技術大学院大学)PBL活動の前期成果発表会で使うスライドの構成と原稿の作り方をまとめました。
PBL活動では、研究室単位で3名~7名のチームを組みプロジェクトを遂行します。
成果発表会は、年に2回(夏/冬)に行う活動内容と成果物を報告する会です。今回はそのPart2として前半学期(1Q/2Q)を報告する前期成果発表会で使うスライド構成の例と発表原稿の作り方をまとめました。
注：原稿の作り方については卒業後に身につけたテクニックが含まれます
所属PBL
私が参加したPBL(研究室)は以下です。 まとめた内容は私が在籍していた当時に得た知見です。全体的なルール、状況は年度や専攻、所属するPBLにより異なります。
- 年度：2019年度
- 専攻：情報アーキテクチャ
- 科目：情報セキュリティ
- 人数：6名
スライド構成
スライド構成の概要
Part1記事でも説明しましたが、前期成果発表会では、春学期(1Q/2Q)における各PBLの活動内容と成果物および後半学期の予定をプレゼンテーション形式で発表します。おおよその構成は以下の図のようになります。
構成をリストとして書き出しました。
マンスリーレビューで使ったスライドの流用も可能ですが、タスクの説明や年間スケジュール/成果物リストなどは新規に作成する必要があります。
また、調査内容や開発内容の説明は、発表会直前まで作業したりすると、まとめるのがギリギリになります。
- 表紙
- プロジェクトについて
- チーム構成とメンバーの紹介
- プロジェクトの背景と目的
- 前期タスクの説明
- 前期スケジュール
- 年間スケジュール
- 調査内容の説明
- 専門書の購読など
- 調査し分析した内容の説明
- 開発内容の説明
- 開発手法、開発の結果など
- 後半学期の展望
- スケジュールや開発予定の成果物など
- まとめ
- 成果物リスト
- 前半学期の目標と学んだことの説明
- メンバーのKPT(反省と改善点をメンバーがそれぞれ説明)
- 裏表紙
- 「最後までご静聴ありがとうございます」「質疑応答」と記載する
- 付録
- 必要に応じて図表やリストなどを用意します
- 発表では使用ません、質疑応答に対応する際に表示する場合があります
- 実際、用意したものの関連する質問がなかっため発表会では使いませんでした
発表会用スライド
スライド作成の方針と注意事項です。
スライドのデザインは、チームにより異なります。
2019年度の発表会ではパワーポイントではなくPreziを使っているところもありました(そして途中でクラッシュしてた)。
スライドに記載の各内容については、以降で詳しく説明します。
プロジェクトについて
最初にプロジェクト紹介のスライドを用意し、どのようなメンバーでどのようなプロジェクトを行っているのかを説明します。
主な内容は以下の通りです。
- チーム構成とメンバーの紹介
- 教員/メンバーのリストを用意します
- マンスリーレビューのスライドを流用します
- プロジェクトの背景と目的
- 前期タスクの説明
- 発表会前日までのタスクとその進捗を説明します
- 作業スケジュール上マンスリーレビューのスライドには含まれません
- 新規に作成する必要があります(同時にタスクの洗い出しが発生します)
- 年間スケジュール
- 前期スケジュールをWBSその他の方法で図示します
- この部分はプロジェクト計画書もしくはマンスリーレビューのスライドを流用します
- 年間スケジュールアウトライン
- スケジュールを単純化した図を用意します
- 成果発表会でのみ使用する図のため新規に作成する必要があります。
以下スライドのサンプルです。
■チーム構成とメンバーの紹介
■プロジェクトの背景と目的
■年間スケジュール
■年間スケジュールのアウトライン
調査内容の説明
PBL活動は、学習・開発と2つのパートに分かれます。
学習とは、PBLのテーマについて調査し分析し報告することを意味します。
ここでは、調査の方法と分析結果および成果物を説明します。主な内容は以下です。
- 調査すべき課題
- どのような理由で何を調査するのかを説明します
- 研究が中心のチームでは調査の対象が「専門書購読」「公式文書の収集」などです
- 開発が中心のチームでは「開発手法の選択」「実際に開発しての軌道修正」などです
- 調査分析の結果と課題への対応
- 調査し分析した結果と、その結果が課題にどのように対応できたかを説明します
- 成果物
- 調査分析の成果物を説明します
- 「調査報告書」「開発効率の分析結果」「各種エビデンス」などが対象になります
以下は、研究が中心のチームで作成したスライドの例です。
開発内容の説明
PBL活動の開発パートについて説明します。
開発の内容は、ビジネスモデル、プログラム、Webサービス、ハードウェアなど様々です。
そのため説明方法に決まったパターンはありません、成果物にあわせた紹介をします。以下はサンプルの一つです。
- 開発内容の選び方
- どのような経緯で開発内容を決めたのかを説明します
- コンテストを行った、調査を行った、アンケートをとったなどです
- 開発の方針
- 開発の方針とその背景を説明します
- 「プロジェクトの背景と目的」と重複する部分がありますが、ここで改めて強調します
- 開発内容
- 開発内容とその結果を説明します
- PBL活動の中心とも言える部分です。デモ動画/ハードウェアの実物/PVなど最も印象に残るよう配慮します。
以下は、開発の方針を説明したスライドの例です。
後半学期の展望
前半学期の活動内容を踏まえて、後半学期では何をするかを説明します。
スライドの枚数が超過する場合は、「開発内容の説明」に合わせても問題はありません。
まとめ
発表の最後に「まとめ」として前半学期の成果物と、チームとして学んだ内容、メンバーの感想(KPT)を説明します。
「学んだ内容」は、PBLが大学院の授業でありプロジェクト駆動形教育の形式をとっているため、成果物の他メンバーの学習についても触れる必要があるため追加しています。
このスライドは必須であるため省略できません。
- 成果物リスト
- 前半学期の成果物をまとめた表を示し簡単に説明します
- マンスリーレビューとは異なり、担当者名を記載する必要はありません
- 前半学期の目標と学んだこと
- メンバーのKPT(反省と改善点をメンバーがそれぞれ説明)
- メンバー個人もしくはチーム全体の振り返りと感想を説明します
- K=継続ししたい取り組み、P=問題点、T=次回以降チャレンジしたいこと に分けて書きます
- 私の時はメンバー一人ひとりが内容を読み上げる形式で発表しました
以下はスライドのサンプルです。
■成果物リスト
■前半学期学んだことの説明
■メンバーのKPT
発表原稿(任意)
時間的余裕があれば、発表会用のスライドに対応した原稿を作成します。
1分間=300文字を基準に作成し、文字数から発表時間を調整します。スライドの改定は原稿の作成中も発生します。
編集を考えますと、書式設定のあるMS WORDではなく、テキストエディタにマークダウン書式で書くことを推奨します。
テキストエディタの例とマークダウン書式については以下のリンクを参照してください。
code.visualstudio.com www.markdown.jp
原稿サンプル
以下は実際の原稿をブログ用に書き換えたサンプルのテキストです。
## 1.目次と表紙 ### 1.1 表紙 皆さんこんにちは。これからXXPBLの前期活動内容と成果について発表いたします。 発表者は産業技術大学院大学 情報アーキテクチャ専攻 写字生1号です。 どうぞよろしくお願いします。 ### 1.2 目次 発表内容はごらんの通りです。 最初にプロジェクトの概要を紹介し、次に前半学期の調査内容と分析結果について。 3番目に開発内容と結果について、最後に内容をまとめます。 ## 2 プロジェクト紹介 ### 2.1 体制 プロジェクトの概要はご覧の通りです。 メンバーはXXさん、XXさん、XXさん、指導教員は主担当がXX教授、副担当がXX教授とXX教授、外部評価者がXXさんです。 ### 2.2 背景・目的 XX年XX月にXXのようなことがありました。 現在、XXが社会的な問題であり、公的機関XXがXXという対処をしていますが不十分です。 そこで私達はXXというアプローチをとることにしました。 当PBLの目的は問題の本質を明らかにし、解決に役立つXXを開発、それを外部に提案することで対策に役立てることです。 以下省略
原稿の作成とスライドの改定
原稿の作成には、発表内容の正確な理解とかなりの根気が必要です。
この作業はスライドの自己チェックを兼ねているため、スライド側の修正や分量の変更が頻発します。
原稿作成時のみでスケジュールを組むと時間を超過します、計画時は原稿の作成と同時にスライドのブラッシュアップを行うことを前提に時間を確保することをおすすめします。
原稿作成の手順は以下の通りです。
- スライドを元に原稿を書く
- スライドを見ながら原稿を読み上げブラッシュアップを行う
- ここで発表時間オーバーや原稿の大幅改訂などが発生します
- スライドと原稿を改訂しメンバーに報告する
- PBL定例会で発表練習を行う/教員にスライドのレビューを依頼するなどします
- 再度原稿の読み上げとブラッシュアップを行う
- デスクトップを録画しながら原稿を読み上げる
- パソコンにマイクを接続しスライドを操作しながら録画します
- これは発表の予行演習を兼ねた作業です
- 録画を見ながらスライドと原稿を改定する
- 単に原稿を読み上げるだけではわからないミスが多数見つかります
- 同時に発表時間が足りるかどうかを動画の長さから判断します
- PBL定例会で教員立ち会いのもと発表の予行練習を行う
- ここで教員から激しい指摘が入ります
- 指摘をスライドと原稿に反映します(おそらくこの時点で発表までの時間はほぼありません)
- 改訂を反映した原稿とスライドをメンバーに共有する
- メンバーの最終チェックを経て原稿とスライドを完成させる
補足
スライド構成について
スライド作成時に、前半学期の活動内容と成果物をすべて盛り込むとスライドの枚数が極端に多くなります。
強調する内容と、簡単に触れるだけで説明を省略する内容をどのように分けるかがポイントになります。
私の時は21分間の発表で、スライド枚数が46枚でした。
発表内容を絞らず、図表を多用した結果です。これは悪い例です、真似しないでください。
スライドのレビューと改訂について
発表の資料は、メンバーによるレビューと教員によるレビュー、発表者による自己レビューを行い品質を確保します。
ですが、実際は自己レビューやメンバーによるレビューでは問題の検出が困難です。
恐らくは、発表者とメンバーは自分たちの活動内容を把握しているためスライドに問題があっても違和感を感じないのだと思われます。
対処として有効と思われる内容を以下にリストアップします(注：実際にやっていないものも含まれています)。
- 原稿を作成する：文字に起こすと説明に無理のある箇所がわかる
- WORDの読み上げ機能で原稿をチェック：合成音声の読み上げでも問題箇所を検出できた
- 原稿/スライドの音読：不思議と効率よく問題箇所を検出できる
- 他のPBLメンバーに発表練習を見てもらう：非常に効果的でした(通りすがりの顔見知りを捕獲してお願いした)
- 発表練習を録画して自己チェック：原稿作成手順で紹介した方法、動画にすると問題箇所がわかりやすくなる
メンバーのKPTについて
KPTを取りまとめたところ、教員から「KPTが甘いもっとあるはずだ」と厳しく指摘されたのは良い思い出です。
私のKPTを読み上げた際、「K=継続したい取り組み」について、「1日/3時間は作業できた、後半学期も続けたい」と言ったところ聴衆がざわついた気がしたのはきっと気のせいです。
AIIT(産業技術大学院大学)について
AIIT(産業技術大学院大学)について詳しくは、大学ホームページをご参照ください。
