教育の質保証への関心
「社会人基礎力」導入をきっかけに、課題を感じていた目の前の授業の改善を試みた教員がいます。宮城大学事業構想学部の富樫敦教授です。デザイン情報学科情報システムコースに在籍し、ITエンジニアを育成する教育の一端を担っています。
富樫先生は、日本の大学教育、特に自分の専門であるIT教育が、産業界の人材ニーズに応えられていないということに対して、どうにかできないものかとかねがね考えていました。そこで、各専門の学会が中心となり、業界の意見を聞きつつ、その学科の専門領域の技術者教育の質が保証されているかを評価、認定し、そのことでその卒業生が業界から専門家としての評価を受けることになる制度(JABEE<日本技術者教育認定機構>による認定制度)に強い関心を持ち、前任の静岡大学情報学部情報科学科では、学科長として、同校を平成15年度にIT系学科で日本最初の認定校にさせたほどでした。このJABEEの制度は、教育の質保証を知識の観点から見る傾向の強いものでしたが、IT系学科としては、大学教育が産業界から遊離している状況を打開する一つの切り札と考えられていたのです。
その後、宮城大学に移籍し、そこでも、産業界に応えられる教育をしたいと、JABEEの考え方に基づいた最低限の知識が保証されるような教育をしようと教育改革に取り組み、自らの授業にも工夫を重ねてきました。
アイルランド、フィンランドの教育のあり方に感銘を受ける
富樫先生は、JABEEが大学教育で教えるべきとした、ITに関する専門知識を、学生に習得してほしいと思って教育実践してきました。しかし、知識量が多い上に、「学生は、10の内容をレクチャーしたら、10の全てを理解してくれる」と考えてきたものの、実は「10のうち、2〜3割しか届いていないのではないか」「学生にとっては、知識の定着もなく、魅力もないのでは」と感じてもいました。さらに、実際の現場には、実践を重ねて活躍している文系出身のエンジニアもいます。実践のない知識習得は、情報系学科出身としての強みがうまく出ていないと思っていました。
また産業界が大学教育に求めているものが、基礎知識に加えてシステム設計の実践力やリーダーシップ、プロジェクトマネジメント、コミュニケーションなどの「社会人基礎力」にあり、大学教育とズレていることも報告されていました。
そのようなときに、富樫先生は平成17年度に河合塾が行った、産業技術調査=大学と産業界との連携による産業技術人材育成の海外実態調査に参加することになりました。IT先進国であるアイルランドとフィンランドの情報教育のあり方や、カリキュラムの構成などを現地調査するためです。そこでは、知識を体系的に教えるよりも、実践的教育で必要なことを集中的に学び、それで十分産業界で活躍できるITエンジニアを輩出でき、結果としてIT先進国と呼ばれるに至る教育を行っていることを目の当たりにして、感銘を受けました。
そのような背景もあり、富樫先生はまず産学連携で平成19年度から「社会人基礎力」を育成する課題解決型授業も行ったのです。「社会人基礎力」に加え、実践力を育成できる点では十分手応えがありましたが、産学連携で授業を行うのは、大変な労力がかかります。そこで、平成21年度は産業界に頼らず、自分の授業の枠組みの中で、アイルランドやフィンランドのように、実践の中で知識を集中的に学び、かつ「社会人基礎力」を育成する授業を検討したのです。
産業界に頼らない課題解決型授業
デザイン情報学科3年生の必修科目「コンピュータソフトウェア」は、そもそもはソフトウェアの考え方と、それをもとにしたシステムの作り方など、理論面を学ぶことを基本とした授業でした。富樫先生はこの授業を、いきなりシステム開発の上流から下流までの工程を体験するものに変えました。実際のシステム開発を学ぶ形を取ることで、顧客や課題提供者のニーズに合致したシステム作りを行う、課題解決型授業に転換することにしたのです。
これは、IT分野では産学連携の形でしばしば行われる教育方法です。しかし、産業界の協力を得るのには、時間も手間もかかります。また、産業界と連携した授業を行う場合、知識については、事前にある程度習得しておく必要がありますが、一方で十分な知識習得を待っていては、なかなか実践教育までにはたどり着きません。知識習得の途中段階での実践は、学生のフォローや別の教育も必要となります。一方、そもそもこの授業は知識を習得するための授業でした。そこに実践場面があるからこそ、知識の習得もより高いものになると実践教育にした経緯があります。一人だけで実践教育をした経験も十分ではないのに実践教育を行うのは、実践につながる知識を習得してほしかったからです。そこで、実践と知識習得をどうバランスを取って行うかは、大きな課題でした。
その際参考にしたのが、平成20年度に「社会人基礎力育成グランプリ」の決勝まで進出した、東京女子大学の今村楯夫教授の授業方法でした。今村先生の授業は、英語講読の授業ですが、「社会人基礎力」を育成しつつ、グループディスカッション中心の授業とするために、知識習得については、学生自身の予習で対応させていました。富樫先生の授業でもこれと同様に、知識については学生の自学自習で対応させると考え、「社会人基礎力」、実践力、知識の3つを習得する授業を行うことにしたのです。
20分の講義+70分の発表
富樫先生は、授業の枠組みを大きく変えました。今までの講義中心、知識伝達中心のスタイルをやめて、グループでの協働によるPBL型の実践授業に組み換えました。90分の授業のうち、知識伝達は20〜30分で、残りの60〜70分は学生の活動報告や提案プレゼンなど、発表に当てます。知識習得と開発作業は全て課外です。課外の開発で、「前に踏み出す力」「チームで働く力」を発揮させ、授業にも「社会人基礎力」の発揮場面を盛り込みました。
グループに与えられた課題は、富樫先生がこれまで研究や教育のために揃えてきた研究室の蔵書を、研究室のメンバーが簡単に検索したり、新たに登録したりすることができるシステムを、データベースを利用したWebシステムとして提案し、作ることとしました。つまり、クライアント(顧客)として富樫研究室(富樫先生)が立ち、そこで使う際の課題を要件としたのです。
開発は、チーム制で、4〜5人の6チームをくじ引きで編成しました。毎回の授業は、発表が中心です。毎回全てのチームが自分達の提案を発表します。グループごとに、司会班、書記班、コメンテーター班を設け、持ち回りとしました。1チームが、7分ずつ発表し、続いて学生によるコメント、さらに先生やオブザーバーとして時々参加するIT企業の講師がコメントして、各チーム10分をかけました。
発表では、自分の活動や考えを言語化し、相手に説明することで、「課題発見力」「働きかけ力」「発信力」などを高められるようにしました。一方、他の学生は、コメンテーター班はもちろんのこと、急に指名されても、各チームの発表に必ずコメントしなければならないとされ、専門知識を駆使する力、「課題発見力」や「傾聴力」「発信力」を高める場面が作られました。さらに、チーム評価として「社会人基礎力」に関する項目でプレゼンを評価することになっていました。つまり全員が、自分の発表に加えて、他の人の発表内容を理解しつつ、発表者を観察するという3つを同時に求められるようにしたのです。このような工夫を加えたことで、発表活動はより多くの「社会人基礎力」を発揮する場となりました。
課外の活動で、知識と「前に踏み出す力」「チームで働く力」を高める
授業全体の流れは、第4回までの「システム企画・提案」では、どのようなシステム(Webシステム)を構築するかの検討を行います。この場合のクライアントである富樫先生へのヒアリングも、秘書を通してチームでアポを取ることが求められました。さらに、ヒアリングの場面は、学生から質問しなければ答えない、という形で進められたので、仕様を決める際の学生達の知識やインタビュー力、さらにチーム力が問われることとなりました。第5〜7回の「基本設計」では、画面設計、画面遷移の設計、データベースの仕様設計などを行います。第8回以降で、7回までに企画した設計を実際に構築、実装、テストを経て、実現させます。
「コンピュータソフトウェア」の授業スケジュール
第1回 |
10/5 |
ガイダンス |
|
第2回 |
10/19 |
システム企画・提案 |
発表(進捗状況) |
第3回 |
10/26 |
発表(進捗状況) |
|
第4回 |
11/2 |
発表(プレゼン) |
|
第5回 |
11/9 |
基本設計 |
※講義のみ |
第6回 |
11/16 |
発表(進捗状況) |
|
第7回 |
11/30 |
発表(プレゼン) |
|
第8回 |
12/7 |
構築・実装・テスト |
※講義のみ |
第9回 |
12/14 |
発表(進捗状況) |
|
第10回 |
12/21 |
発表(進捗状況) |
|
第11回 |
1/18 |
発表(進捗状況) |
|
第12回 |
1/21 |
発表(進捗状況) |
|
第13回 |
1/25 |
発表(進捗状況) |
|
第14回 |
1/29 |
最終成果発表会(プレゼン) |
|
第15回 |
2/1 |
※第5回と第8回は集中講義
資料提供 宮城大学
工程に必要な知識は、そのつど20分の講義で伝え、伝えきれないところは自分で学ぶようにしました。実装にどうしても必要な知識なので、学生達は自学自習して知識とスキルを身に付けていきました。
一方、実際の開発作業は、全て課外での活動となります。課外でチームとしていかに活動するかが、成功の鍵になります。
試行錯誤でスタートしたチーム活動でしたが、だんだんチームができあがってきました。あるチームは、「各メンバーの力量と時間を考え、実装可能な範囲を絞り、実装部分の分担を細かく分けることで、それぞれの作業効率が上がるように努力した」と述べています。また「週2回ずつミーティングを行い、各メンバーの1週間の役割分担と、行った作業の反省を聞き、その後の作業の役割分担をどう振り分けるかを考えた」という班もありました。
彼らの毎週の課外活動時間は、10時間を超えるほどになり、学生は、大変だと言いながらも、開発作業に没頭しました。他の演習などの授業よりも力を入れることになったと言います。
課外の活動は、教員の目が届かないため、「週報」が大事な役割を担うことになります(→詳しくはこちら )。「週報」は、毎週の活動を「社会人基礎力」の観点で、チーム貢献度として評価し提出するものですが、富樫先生はこの週報を活動エビデンスとし、同時に成績の評価に活用したのです。そこでは、自分のチーム貢献度と、チーム相互評価としてメンバーのチーム貢献度を100点満点で記入するようになっています。
知識を教えるのでなく、学生が自分で学ぶ
富樫先生は、知識伝達の時間を20分に絞ることにしました。発表後の講義については、どの回に何を説明するかは事前に固めず、学生の状況を見て、知識として抜けていると思われる部分を説明するようにしました。当然、必要な知識を全部教えることはできないので、重要なポイントのみを伝え、後は学生に自分で勉強するようにと指導したのです。そのため、どこに必要な情報があるか、Webサイトや参考図書の情報提供をして、どこのページを読めばいいかまでは教えました。教科書についても、500ページあるうち、どの部分が重要で、どこの部分は飛ばしてもいいかなど、ヒントは出しておきました。
この授業では、ServletやJSPといったサーバーサイドシステム開発に必要な知識が十分ではないのに、いきなり開発をさせようとしました。知識を習得しながら、同時に実践させてしまうのです。学生には開発工程で必要になったら、そのとき必要な知識を習得させることとしました。
体系的知識より「使える知識」を習得させる、頭で理解するのではなく実際に手を動かして定着させる、提供されるのではなく自分で判断して学ぶ(学び方を学び、自分で学べるようにする)という3つの考え方を採用したのです。
社会人基礎力でチーム貢献度を表す
富樫先生が、この他に行った「社会人基礎力」育成のための活動には、次のようなものがあります。
■ まず、「社会人基礎力」についてガイダンスを行い、「社会人基礎力」の必要性と意味を説明しました。特に、IT業界には多くの職種があり、それぞれの職種で「社会人基礎力」は不可欠であることを強調しました。また、授業の講義の際にも、必要に応じて基礎力について説明しています。
■ 毎週、チーム活動を振り返り書かせている「週報」では、「チームへの貢献度(100点満点)」を、「自己評価」と「他者評価(メンバー評価)」の両面で行っています。チームへの貢献度は、「社会人基礎力」の視点を当てはめ、チーム活動のためにどのような「社会人基礎力」を発揮してチームに貢献したのかを点数化します。点数は、評価基準表をもとにつけます(→週報と評価基準表はこちら)。
「社会人基礎力」でチーム内での活動を評価させることで、ITの業務には「社会人基礎力」が必要なのだということに気付かせます。学生は、システム開発の活動を自らの「社会人基礎力」の発揮も踏まえて語ることができるようになっていくのです。ある学生は「システムを設計し実装するという抽象的で大きな課題に対して、週ごとに具体的で小さな目標を提案した。結果、大きくスケジュールが乱れることなく、皆が各々の役割をきちんと果たしながら発表会を迎えることができた(「課題発見力」→「実行力」→「計画力」)。チーム内で求められる自分の役割を認識し、主体的に貢献できるように意見を発信し、実行すると発言した行動を確実に期限までに実行した(「情況把握力」→「主体性」→「発信力」→「実行力」)」と振り返っています。
■ 発表場面では、他チームの評価をさせます。「社会人基礎力」の項目(下図参照)で100点満点をつけ、「今回のプレゼンテーションを聞いての感想(よかった点、改善すべきと思う点)」を記述します。
【前に踏み出す力】
1)課題への取り組み熱意や実行力に関して、発表を通じて感じられたか? 点
【考え抜く力】
2)課題への解決策に関して、現状認識やアプローチが適切と思われるか? 点
3)取り組み結果に関して工夫行動やしっかりした成果がみられるか? 点
【チームで働く力】
4)プレゼンテーションの資料やその仕方は意図やポイントが伝わるものだったか? 点
5)講義で学習した内容や周囲からのアドバイスなどを適切に取り入れていたか? 点
【総合評価】
6)今回のプレゼンテーションの総合評価に関して、取り組み成果とプレゼン内容の両側面
から評価してください。 点
資料提供 宮城大学
社会人基礎力を成績評価に反映
これらを「社会人基礎力」の育成に効果的に活用するだけでなく、成績評価に入れた点は注目に値します。「社会人基礎力」を育成すると学生に宣言した以上、成績評価に入れることは教育の説明責任や質保証の観点からは大事なことであるからです。
成績点数配分
総合評価 100点 満点 |
チーム評価 (成果物) 50点 ※チームで同一点となる |
成果物 30点 |
要件に合っているか5割、技術面3割、デザイン2割 |
仕様書、設計書など途中段階のものも成果物とする |
チームでの発表 10点 |
教員評価5割、他チームによる学生評価5割 |
要求仕様、設計、構築の各工程の最後のプレゼン3回分 |
||
発表資料10点 |
プレゼン用として成立しているか |
|||
個人評価 (社会人基礎力) 50点 |
チーム貢献度 |
自己評価+メンバー評価 |
「週報」の「チーム貢献度(100点満点)」 |
|
教員による最終評価 |
※微調整として |
|||
発表での個人のプレゼン技法 |
学生による他者評価 |
最終発表のプレゼンの話し方と態度を評価 |
資料提供 宮城大学
成績評価は、チーム評価として、授業で作り出された成果物(提出物)で50点分を評価し、個人の評価50点分を「社会人基礎力」で行い、計100点としました。
このうち成果物は、チームで作ったものなので、同一チームは全員同じ点になります。これは成果物と、発表と、発表の際の資料の3つから構成されます。50点のうち、成果物が30点、チーム発表点が10点、発表資料が10点という配分です
一方、個人の評価は、活動を「社会人基礎力」の視点で振り返ります。活動はチームで行うため、チーム活動の中で、どれだけ「社会人基礎力」を発揮してチームに貢献したのかを、自己評価とメンバーによる相互評価で評価します。この評価は、毎週提出する「週報」の中で、チーム貢献度(100点満点)として行っているので、その得点を提出分全て集計して、そこに富樫先生の採点した評価点を加味し、個人の最終評価とします。また今回は、個人の発表での頑張りを見るために最終プレゼンを学生に相互評価させたので、その点も加味しました。
◇
ある学生は、「今まで大事なのは技術だと思っていたので、この授業の進め方は大変だったが、ITの仕事ではチームで働く力が大事だと知った。自信を持って就職活動ができ、東京の大手に内定をもらうことができた」と言います。他の学生も就職にはとても役に立ったとのことで、システム開発やコンテンツ制作の会社に内定が出たそうです。
◇
このように、授業自体も評価の方法も全く新しい観点から作り直した授業でしたが、課題もあると言います。まず、「社会人基礎力」の評価を成績に反映する際に、自己評価と学生同士の相互評価(チーム評価)のウエイトが高いので、成績の客観性、公平性としては問題が残りました。また、評価するポイントが細かすぎたため、学習活動にしわ寄せが出た、という印象もあったそうです。チーム貢献度を「社会人基礎力」で評価したのは、社会人になってから必要になる観点でチームメイトなど他人を見るという意味で、重要であったと考えているそうですが、その反面、他者評価のフィードバックが十分できず、評価結果を「社会人基礎力」の育成に生かせなかったことは、教育的には反省点でした。
また、課外活動に多くの時間を取らせすぎたかもしれない、とも考えているそうです。学生は他の授業も履修していて、それらの準備やサークル活動、私的・公的な対外活動の予定にまであまり影響を与えてしまうのは好ましくないからです。富樫先生は、こうした課題に対して修正を重ねながら、新たな授業展開を行っています。
これまでの大学のIT教育は、産業界の人材ニーズに十分応えられていない、との指摘を受けていました。その打開策として、大学教員が中心になってコア知識・技術を習得させるという、JABEEなどを軸とする考え方と、産業界の協力を得て実際にシステム設計を行いながら、経験的に知識や技術を学んでいくという考え方が、それぞれ学会と産業界という別個の背景を持ちつつ、存在してきました。そのような中で、教員自らが産業界の協力を得ることなく、「社会人基礎力」を育成しながら、知識教育の質を検討することも重視し、実践教育を取り入れていったのは、どのような専門知識を教えるかを再検討するためにも、実践的場面を教育の中に作ることの意味を問い直すためにも、そしてこれまでとは質の異なる大学としての教育の方法やその効果・可能性を試し、検証していくためにも、大きな示唆を与えると言えましょう。
週報(チーム内・相互評価シート)
レベル評価基準(一部抜粋)