日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

PBL 活動を行う学生チームへの実装と支援の留意点
山戸 昭三, 鷲崎 弘宜

現実社会で活動している企業の課題に対して，IT システムを提供し活用することによって，解決しようとする PBL手法は，学生にとって多くの学びが期待される．教員は，学生チームの自律的な活動だけに任せるのではなく，より多くの教育効果が得られるように，顧客役の選定段階から IT ソリューションの顧客役への引継ぎまで，適時，適切な教育と支援が求められる．本論文では，筆者の経験と知識をもとに，学生チームへの教育と支援の留意点を論述する．

The PBL by which the students team providing IT services solution to a real world company helps theparticipating students to develop their problem solving skills. It is regarded as a highly eﬀective leaning
tool. The teachers’ role in the PBL is to provide adequate educational support from a beginning stage oftarget customer selection to transfer of the end results to the costumer. The teacher is expected in engaging
in the support activities as required in order to achieve its learning objectives. This paper, based on theauthor’s experiences, some of considerations to be made on types and level of educational support to thestudent team’s PBL activities.

個人である．本論文では，PBL の実施前に，教員が1 はじめに実顧客を選定する場面からプロジェクトの開始段階，はじめに，対象とする PBL の定義，PBL の対象実行段階，終結段階で，学生チームが PBL を学びのとなる顧客役，学生チームが持つ制約条件を述べる．

場として活用できるように教員として支援する要件について論ずる．

1. 1 PBL の定義
本論文で扱う Project Based Learning （以下，PBL

1. 2 実社会の企業と PBL の対象となる顧客役と呼ぶ）[1-7] は，現実社会で活動している顧客（実現実社会の企業は，ビジネスの世界で活動してお顧客と呼ぶ）を対象とし，学生が 4 人前後のチーム

り，IT ベンダとは契約や契約金によって制約され，原編成で，顧客の業務課題をヒアリングし，IT を使っ則的には自社の営利の極大化を図ろうとする，この認た解決策（以下，IT ソリューションと呼ぶ）を提示

識の相違を無視して，PBL を進めた場合，顧客と学し，プロジェクトとして顧客と合意したシステム開発

生チームの認識のギャップ，コンフリクトが生じるこを行い，成果物を顧客業務に適合させることを目的ととが想定される．教員は，PBL 活動を教育の場としした教育プログラムである．実顧客とは，営利・非営て提供する責任がある．PBL 活動に業務課題 (PBL

利および企業・団体・個人を問わず，その目的・目標テーマ) を提示し，IT ソリューションにより業務改の実現に向けて統合された業務を遂行している組織・

革を図ろうとする顧客には，教育プログラムとして推∗Consideration upon Implementation and Supportfor Student Team Performing the PBL Activities.
This is an unrefereed paper. Copyrights belong tothe Author(s).
Shoso Yamato,Hironori Washizaki, 愛媛大学, 早稲田大学, Ehime University, Waseda University.

進しようとしていることへの理解と合意が必要である．実顧客を対象として，学生チームに教育プログラ
ムとして提供したい教員とビジネス活動として学生に自社の課題を提示し解決させたい顧客とが，事前に双方の認識を調整し合意しておくことで無用なトラブルを防ぐことができる．PBL 活動を教育プログラ

その要件について述べる．

ムとして理解し，協力・支援してくれることに合意してくれた顧客をあえて「顧客役」と呼ぶ．

2. 1 教育プログラムとしての認識の共有と合意
教員は，顧客役として依頼する際に，学生チームの1. 3 学生チームが持つ制約条件ための教育プログラムであることを納得してもらう

学生チームが PBL 活動を推進する場合に，IT ベことが必要である．教育プログラムの実現のためにンダと同じような活動はできない．顧客との開発要件

は，学生チームが自律的に成長することが第一要件を合意する場合には，次のような学生チームが持つ制であり，顧客対 IT ベンダの関係，すなわち顧客は金約条件に留意しなければならない．

を支払っているのでわがままを言えるような関係が，1. 3. 1 顧客情報は少ない

学生チームにとって良い関係ではないことを理解してIT ベンダは，ビジネスの世界で，日頃から営業活もらうことが必要である．この年代の学生チームの自動を行っており，対象とする顧客の業務や推進体制に律性や学びを高めるためには，SL 理論（Situationalついての理解を深めている．しかし，学生チームは，Leadership theory）[8,9] に基づく S2：説得的リー

プロジェクト開始時点で，顧客について，顧客の特性ダーシップや S3：参加的リーダーシップで接し，主や思考傾向，価値基準など何も判断材料がない．した

張を傾聴し寄り添う関係を維持して合意形成するこがって対応を辞退するような判断材料もない．とが必要であると考える．

1. 3. 2 活動期間が限られている
IT ベンダであれば，組織としての活動は定常業務

2. 2 顧客役自身の改革シナリオであり基本的に永続する．しかし，学生チームの場合顧客役には自らの業務について何をどのように変には，PBL 科目としての期間に対応することであり，革し，その変革を支援するシステムをどのように構築

長くて 2 年間，短ければ 3〜6 か月程度である．

すれば，改革を実現でき，どのような効果が期待して

1. 3. 3 開発リソースが限られている

いるかというシナリオとそれによる期待効果の計測

IT ベンダでは，組織としての体制を柔軟にとる方法を示すことができなければならない．もちろん，ことができ，自由度は高い．技術力は高く開発工数が学生チームの提案を受け入れ検討する姿勢は重要で足りなければ外注化することもできる．しかし，学生あるが，顧客役は，企業の進むべき方向性を示し改革チームの場合は，見積もり経験も少なく，開発者数，の先導をしなければならない．顧客役は，本気で改革開発工数は限られており，外注費がなく外注することをしようとしている姿を見せ，学生チームはそれに共はできない．また，開発設備，開発費なども限定され感して改革にふさわしい IT ソリューションを提案している．

構築する．このシナリオの中で，学生チームは自律的

1. 3. 4 知識と経験が少ない
IT ベンダの場合，ビジネス活動をしており，組織にはプロジェクトを遂行するに必要な知識と経験のに成長するのであり，どうでもよいような要求の仕方やそれほど期待されていない要求では学生チームも熱意が生まれにくい．

蓄積がある．一方，学生チームの場合には，システム開発の経験が少なく，IT サービスを活用させるため

2. 3 学生チームとの接し方の知識も少ない．

現実社会の顧客は，契約と契約金を盾に，IT ベンダに対して，かなり高圧的な対応をする場合がある．

2 教員による顧客役の選定段階

しかしそのような対応が学生チームにとって教育的に学生チームに PBL 活動を推進させようとする教良い効果をもたらすとは考えにくい．このような対応員は，最初に，顧客役を選定し，その進め方や体制，は，学生チームにとって IT 業界へのネガティブな印

PBL の意義などについて合意しなければならない．

象を持つこともあり，PBL 活動へのモチベーションを低下させることもある．顧客が上位にあり IT ベン

生チームと合意しなければならない．顧客役が納得すダがそれに従うという立ち位置ではなく，顧客企業のるまでという曖昧な受け入れ基準では，学生チームはあるべき姿の実現に向けて学生チームと一緒に構築どこまでやればよいのか理解できない．

していくという姿勢を持たせることが顧客役には求められる．学生チームと信頼関係を築き，学生チーム

2. 6 覚書の交換の発想力や良かれと思って行動する自律性を期待する

上記のような顧客役に求められる要件や PBL が教ことが自らの利益にもつながるはずである．PBL 活育プログラムの一環であること，学生チームが持つ制動を顧客役と学生チームとが対等で WIN-WIN の関約条件への理解などをまとめた覚書を PBL 開始前に係を築ける場とするためには，顧客役の協力と支援に取り交わしておくことが重要である．

対して無償で IT ソリューションを提供するという関係であることを納得させることが必要である．

3 顧客役と学生チームとのファーストコンタ
クト段階

2. 4 顧客役の適時な意思決定と適切な活動

教員は，顧客役の選定を行い双方合意して覚書を交

顧客役は，学生チームが持つ制約条件を理解し，開換したのちに，学生チームと顧客役を引き合わせる

発期間や成果物品質の確保のために，マイルストーン（ファーストコンタクトさせる）．この段階での留意までには要求の提示や開発要件の合意という意思決事項を以下に示し，教員はファーストコンタクトの前定やテストデータの提示，学生チームからの交渉へのに学生チームに顧客役と接するための知識と留意点

柔軟な対応，IT サービスや教育の受け入れ，保守体を教育しておくことが求められる．

制の構築などの具体的な活動が必要である．筆者は，若い時代のプロジェクトの失敗はトラウマとなることが多く，学生チームにとってプロジェクトを何とか成3. 1 責任が負えないことを引き受けないこと，請負作業などを安請負しないこと功させて初めて教育効果があると考える．PBL 活動

学生チームの制約条件を理解させ，責任が負えないが高度 IT 技術者の育成を目標とするならば，顧客役ことを引き受けさせない．例えば，このシステムを導と学生チームが双方の責任を果たし協力してプロジェ入すれば業務が改善するという約束をする，一年以内クトを遂行しなければ実現できないことを理解するにシステムの開発を完了する，といったことを言わせことが必要である．

ない．顧客の誘導にも乗せられないように注意する．

2. 5 IT ソリューションに対する定量的評価指標
顧客役は，自らの業務改革の方向性を提示すること

3. 2 顧客役が完全に主導権を持つような受入基準に合意しないことが必要である．そして，あるべき姿の達成度を客観的受け入れ条件について，軽率な合意をしないことに把握できなければならない．たとえば，サービス提が必要である．たとえば，「顧客役が満足するまで」，供に対する利用者からの満足度向上，「いいね」の件数「新規利用者が一割アップするまで」といった曖昧な向上などである．現状の観測値を提示し，何を，どう内容や顧客の活動なしには実現できないような条件やって，どのように変革したいのかという変革のシナに合意することはできない．システム開発すれば成果リオ，期待する観測値の KGI(Key Goal Indicator) や物ができるが，かなりの確度で作り上げることが可能

途中段階での KPI(Key Performance Indicator)[10]

なもの以外は，早い段階で受け入れ基準について合意といった客観的な評価の指標を示すことが求められすることはリスクが高い．少なくとも請負開発では無る．顧客役が頭の中で考えている評価基準を学生チーいことを理解させ，当面はベストエフォートの成果物ムが理解できる形で提示しなければ，ゴールが見えなとすることにしておくべきである．

い．システム開発段階の完了基準を判断可能な形で学3. 3 顧客役とは対等の立場という認識でマナーを持って対応すること方を合意

IT ベンダの場合，ファーストコンタクトが終わっ初めて実企業とコンタクトする学生チームは，顧客たら，ただちに，顧客要求の分析作業を始めるが，経役の言うことを絶対的な指示と認識しがちである．顧験のない学生チームは，指示されない限り勝手に動い

客役と学生チームは対等の関係である．顧客役の言うてはならないと考え，顧客役や教員からの働きかけなことと認識の相違がある場合には，納得するまで回答しには，自発的に行動しないことがある．学生チームを保留し，持ち帰って検討し改めて回答するという用自身が顧客役とプロジェクトの進め方について，段取心深さが必要である．ただし，社会人としてのマナーりを決めていく，すなわち，活動プロセスを合意しては，必ず守ることもいかなる場面でも重要である．

自律的に行動するように仕向けなければならない．

3. 4 顧客役の無料アルバイトとして使われないこと

4 要求分析段階
顧客役とのファーストコンタクトが終了するとプロ学生チームにとって貴重な時間を PBL 活動とシスジェクト計画を立案し，計画に基づいて顧客の要求分テム開発に投資するのであるから，貴重な学びを獲得

析を行う段階となる．どのような要求に応えようとすすべきである．あまりにも単純作業を求められているのかを分析する重要な段階である．顧客役の要求おるならば，きちんと断らなくてはならない．例えば，よび優先順位を正しく認識できないと顧客役からは該当企業の業務に関する利用者の満足か否かのアン信頼されないことが多い．この段階の留意点についてケートや本来，顧客が主体的に行わなければならない述べる．

ような作業はきちんと断ることが必要である．礼節を持ってお断りする技術も学びの一つである．顧客役も

4. 1 顧客役が要望を整理して話してくれるとは限制約条件が多い PBL 活動では，簡単な作業の依頼しかできないと考えがちだがテーマ設定には工夫が必要である．

らない
顧客役には，業務改革案があるという前提で話をしてもらっても必ずしも要望が整理されていないことが多い．要望には勘違いもあり，相矛盾する要望もあ3. 5 議事録を後で活かして使うことり，整理されていない要望や近未来の要望や遠い将来プロジェクトは，開始直後にリスクが最大となる．の理想とする要望もある．本質的な要望や思い付きの

それは，この段階での認識の違いや合意のずれでプロ要望も混在する．レベル感が異なる要望など混沌としジェクトの成果物やその成果物の妥当性が大きく変わた話が多い．この要望の整理整頓を行い，レベル感をるからである．毎回，議事録を取り，顧客の主張や合合わせた要求として整理することが学生チームには意事項のぶれを減少させ収束させていかなければな求められる．

らない．そのためのツールが議事録であり，両者に公平な議事録を使って軌道修正や交渉に活用しなけれ

4. 2 顧客役の業務シーンの中にニーズがあるばならない．学生チームは，自己満足的に，ただ記録顧客役の業務改革案の発想は，そのアイデア（ITしているだけの議事録を作っていることが多いので，ソリューション）を業務シーンの中で活用している場

議事録の作り方，承認プロセス，活用の仕方などを教面が語られる．いくつかの業務シーンの中に存在すえておくことが大切である．

るニーズ（これを顧客ニーズと呼ぶ）をヒアリングする．

3. 6 学生と顧客役とのコミュニケーションの取り4. 3 顧客ニーズの優先順位を確認する持つ制約条件を考慮しなければならない．すべての顧複数の顧客ニーズをヒアリングしながら，顧客が重客要求を満たすことができれば問題無いが，満たせな要と思っている価値を正しく掴むことが必要である．

い場合には，優先順位の低い顧客要求を取り下げる，仮説と検証を繰り返しながら顧客役のニーズの優先

翌年度 PBL 活動と合わせた二段階開発とする，など順位や価値観の本質を把握する．学生チームがこの優の調整も必要である．一部の要求を取り下げた実現方

先順位を正しく表現してくれるとよく理解してくれ

法で顧客役に IT ソリューション提供の意味があるのていると認識し顧客役の信頼感が増す．誤った優先順かを調整し，顧客役と合意する必要がある．

位で解決策を理解されると顧客役は不安になり信頼感は低下する可能性がある．

5. 2 具体的な IT ソリューション案
学生チームが陥りやすい傾向として，顧客要求の文

4. 4 顧客ニーズは非機能要求も考慮して，要求分析として顧客と合意する言を言い換えたに過ぎない要件を要件定義とすることがある．たとえば「入力しやすいこと」という要求

顧客ニーズを把握する場合に，学生チームが陥りに対して「入力しやすい方法で実現すること」を要件やすい傾向として，「〜のように動く」といった機能としたのでは何も考えていないことに等しい．どのよ

面の確認だけで終わることがある．顧客役は，業務うな方法で入力しやすくするかを要件としてまとめシーンを話しているので学生チームは理解してくれなければ不十分である．また，機能要求の実現だけでていると思い，機能面だけを話しがちであるが，実はなく，非機能要求への具体的な非機能要件として実は，非機能要求について語っていないことが多い．す現水準を設定しなければならない．たとえば，入力時なわち，機能性に目を奪われて，信頼性，使用性，効間については，「1 分間の文字入力数を 20 字以上とす率性，保守性，移植性，セキュリティ，デザインなどる」といった実現水準とする．

について，検討し合意することを忘れがちである．また，それぞれの特性の具体的な実現レベル（サービスレベル）を決めておかなければならない．最終的に顧5. 3 IT ソリューション案と他のソリューションとの比較，開発の妥当性評価

客の要求は，要求分析として顧客に提示する．実企

顧客の価値分析とそれに応えるさまざまな解決方

業の場合には，RFP(Request For Proposal) として，法 (ソリューション) について，すでに実在している提案説明会で公開するが，学生チームとの PBL 活動ものがあればその調査を行い，なければ解決方法を考の場合には，顧客要求として合意するにとどめる．

案する．そして，これらすべての解決案と比較する．
この中でこれから開発しようとする IT ソリューショ

5 要件定義段階

ン案が顧客役にとって最も価値が高いものでなけれPBL 活動として，推進していくためには，学生チーば開発させる意味がない．学生チームにとってどれだ

ムは，要求分析段階から具体的な要件定義段階に進け労力をかけて一生懸命作ったとしても顧客役にとっまなければならない．この段階では，学生チームは，て最も価値が高いものでなければ使われない可能性自らが持っている制約条件を考慮しながら，顧客要求が高い．すなわち，この IT ソリューションを開発すを実現するための要件（具体的な IT ソリューションることが妥当であると評価されなければならない．

案）を提示しなければならない．この段階での留意事項を述べる．

5. 4 改革シナリオと IT ソリューションへの期待効果の共有

5. 1 学生チームが持つ制約条件

学生チームは，顧客役とともに，顧客の業務改革に顧客の要求分析の結果，全て実現したいところであ自分たちが開発しようとする IT ソリューションがどるが，PBL の場合，現実問題として，学生チームがのような効果をもたらすのか，を話し合うことが必要

である．IT ソリューションが具体的な顧客業務の改革につながるという思いがあれば，学生チームの使7 プロジェクトの実行段階命感は大きくなる．実企業を対象とする意義がここ

プロジェクトの実行段階では，プロジェクト要員ににある．学生チームにシステム開発とは，目標を設定統制された規律ある行動をさせなければならない．自し，制約条件に配慮しながら，その目標に向けて設計

由な学生生活に慣れた学生チームには，慣れないこし製造しその観点でテストする必要がある，ことを理とではあるが，PBL では，使命感に支えられながら解させる．ここに PBL における学びがある．現実の計画に基づいて自律的に行動できる人材になって欲社会では，要求分析をせず，また顧客と合意した要件

しい．

定義も無く，具体的な目標値なしに設計することやものを作ると言うことはあり得ない．作りっぱなしの発想になりがちな学生チームに，この点が PBL として大切な点であることを理解させることが重要である．

7. 1 ステークホルダーにわかりやすい説明をする
技術
学生チームは，計画に基づいてプロジェクトとして行動することに慣れていない．プロジェクトの状

6 プロジェクト計画立案段階

況報告をさせると近視眼的な報告をすることが多い．

顧客役と要件定義について合意がとれると，その実プロジェクト状況報告を受ける関係者としては，プロ現に向けて学生チームは，プロジェクト計画を立案す

ジェクトの全体状況，開発スコープ（開発範囲），そる．この段階で留意すべき点について述べる．の実現のための計画（計画線表，開発規模，開発体制，工数見積り），計画に対するプロジェクトの実行

6. 1 根拠ある計画

状況（進捗状況，想定されるリスク），計画と実行のプロジェクト計画は，学生チームの行動を規定する

差異分析，今後の見込みと対応策，関係者への対応依ものであり，根拠ある計画でなければならない．しか頼事項などをトップダウン的に説明することを求めし，学生チームは，開発スコープを WBS にすることる．教員は，プロジェクト状況報告の仕方を教えなけもなく，ガントチャートに希望レベルの計画線を引いればならない．

た程度のものを計画と考えていることがある．プロ
ジェクト計画とは，WBS をベースにして，要素成果物，実現のための作業を抽出し，可能な限り正確な見7. 2 計画と実績のかい離を監視しコントロールするマネジメント

積もりを行い，各要員の日々の作業レベルまで分解しプロジェクトは，計画通り進めたいが，実際には，て実現可能な計画とすべきである．現実社会におい進捗，品質，コスト（学生にとっては作業時間）など，て計画なしに実現できることは，ほとんどない．あっ

さまざまな局面で計画と実績のかい離が出てくる．こたとしてもその成果物は誰でも作れるようなものでの計画と実績のモニタリングができる仕組みを作り，あり，さして価値の高いものとは言えない．

早期に適切なコントロールを行うことが，PBL 活動における学びでもある．学生チームは，計画は作るが6. 2 キックオフミーティングで説明責任を果たす

プロジェクト実行の状況把握をする仕組みを作らず，教員は，学生チームが作ったプロジェクト計画の実したがってリスクマネジメントも行っていないことが現性を検証し，キックオフミーティングをさせなけれ多い．教員は，マネジメントの必要性を教え，適切にばならない．キックオフミーティングは，単なる親睦活用できるよう支援しなければならない．

会ではない．プロジェクトマネージャがプロジェクト計画とプロジェクトルールの説明責任の場である．プ
ロジェクトとは緊張感のあるものであり，規律ある対応をしなければ実現できないようなものである．

8 プロジェクト終結段階
プロジェクトの終結段階では，プロジェクト目標を達成するために，顧客役と交渉をし，両者が納得できるレベルの着地点に合意するようにコミュニケーションを実施しなければならない．

9. 2 教員の関与が特に重要な上流工程
プロジェクトの開始段階での仕込みが効果的な「学びの場」の構築には重要である．顧客役の選定，学生

8. 1 IT サービス活用のための支援チームが顧客役とファーストコンタクトする段階，顧学生チームは，IT システムを作ることに集中し，客役の要望から要求分析する段階，制約条件を考え顧客役にとって重要な開発した IT システムを顧客業要件定義にまとめる段階，などの上流工程について，務に組み込み，顧客企業において活用できるようにし教員の関与が，有意義な成果物の構築と学生の自律的なければならない．それは，顧客役への教育であり，な学びに重要である．

時間をかけた引き継ぎである．納期ぎりぎりに納品して間に合わせるという発想は厳禁である．これらの9. 3 使命感を持って仕事に取組むことの重要性

IT サービス活用のための支援を確実に行わなければ，顧客役は，何かを解決したいために解決策が欲しい

学生チームにより，PBL 活動に対する評価は低いものであり，彼らにとって IT システムは道具である．のとなる．

学生チームは，PBL という科目の単位を獲得することは必要であるが，PBL を単に「単位獲得の場」と

8. 2 反省と教訓の蓄積するのは，意味がない．
「学びの場」としての PBL に社会において活動する IT ベンダは，プロジェクトするために，実顧客の参画を得て現実問題を考え活の成功と失敗を繰り返しながら，日々反省と教訓の蓄動することが必要である．そのためには，何を作り積を行って組織の成熟度を高めている．社会において提供するというプロダクトアウト発想からではなく，競争力の源泉は，組織成熟度である．失敗したこと，顧客ニーズを解決するために提供するというマーケッ

失敗を未然に防いだことなど，貴重な時間を投資してトイン発想が優先されなければならないと考える．

獲得した体験を冷静な視点で反省し，教訓化する習慣を身に着けさせることは，学生チームの大きな学びと

参 考 文 献なる．教員は，その学びの支援を最後まで行うべきで[ 1 ] 山 戸 昭 三,
筑 波 大 学 の PBL ,PMI 日 本 支 部
2012PMI フォーラム，東京,2012.
[ 2 ] 山戸昭三, 大学院 PBL のマネジメントシステム構
築構想について , プロジェクトマネジメント学会 2011年度秋季研究論文発表大会，東京,2011.
[ 3 ] 山戸昭三, 大学院における Project Based Learning の実施事例 , 日本技術士会， IPEJ Journal(2011 年 5 月),No532 pp.8-11,2011.
[ 4 ] 山戸昭三, 大学院 PBL におけるプロジェクトマネ
ジメント教育の実施 , プロジェクトマネジメント学会
2011 年度春季研究論文発表大会，東京,2011.
[ 5 ] 山戸昭三, 北川博之, 田中二郎, 筑波大学大学院における PBL の実施と評価 , 日本工学教育協会, 工学教
育 Vol.61 No.5, pp.94-99,2013.
[ 6 ] 山戸昭三, 実顧客向け PBL を行う学生チームへの教育支援 , プロジェクトマネジメント学会 2015 年度春季研究論文発表大会，東京,2015.
[ 7 ] 山戸昭三, 北川博之, 田中二郎, 筑波大学大学院
における IT 実践力育成の施策と評価 , 日本ソフト
ウェア科学会，コンピュータソフトウェア Vol.32 No.3,pp.29-38,2015.
[ 8 ] Hersey，P，and Blanchard，K ，H ．Management of Organizationa1 Behavior，Utilizing humanresources Third Edition，Englewood Cliﬀs，NJ：
Prentice Hall,1977. 邦訳 山本成二 水野基 成田攻（訳）入門から応用へ 行動科学の展開 人的資源 の活用, 日本ある．

9 おわりにおわりに，本論文で主張する要点をまとめる．

9. 1 PBL を実施する学生チームへの教員の関与の重要性

PBL 活動を学生チームの自律的な活動と認識し，自由に活動させる考え方があるかもしれない．しかし，筆者は，学生だから失敗しても良いので無手勝流に取り組み，最後までやり抜けというような考えはしない．学生チームに対して，PBL という教育の場を有効に活用し，多くの学びを獲得させるためには，「学びの場」としての準備，PBL 活動中の学生チームへの適時なアドバイスや知識の教授など教員の関与は，非常に重要である．

生産性本部,1978.
[ 9 ] プロジェクトマネジメントハンドブック編集委員会
編, プロジェクトマネジメントハンドブック, オーム社，
2009.

[10] Robert S. Kaplan and David P. Norton, Strategy
Maps : Converting Intangible Assets into Tangible
Outcomes , Harvard Business School Press,2004.