- 作者: 宇田光
- 出版社/メーカー: 北大路書房
- 発売日: 2005/06/01
- メディア: 単行本
- 購入: 2人 クリック: 3回
- この商品を含むブログ (7件) を見る
BRDとはBrief Report of the Dayの略で，「当日ブリーフレポート方式」のこと．
学生に授業をより深く理解してもらうために，著者が考案したもので，「ブリーフカウンセリング」や「動機付け理論」が背景になっています．また他の授業改善方法の紹介と比較がなされています．
講義当日の基本手順は次のとおり(図2-1，p.31)．
- テーマ確認: 教員がBRDの実施を宣言し，テーマと執筆時間を板書する．
- 構想段階: 用紙を配布．10〜20分，学生が構想する．
- 情報収集段階: 受講生が互いの構想を知る．あるいは教員が講義する．
- 執筆段階: レポートを書き終えた人から教員に提出し，退出する．
プログラミング授業で取り入れてみるなら，こうでしょうか：
- テーマ確認: 教員が課題・解答用紙を配布する．スケジュール（時間配分）を提示する．
- タイピング・構想: 学生は，課題に書かれているプログラムを打ち込み，正しく動作することを確認して，所要時間を記入する．打ち間違いがあれば，コンパイル時のエラーメッセージや，実行結果をもとに，デバッグする．早く済めば，プログラムを読んで内容の理解に努める．友人のデバッグを手伝うのもよい．
- 講義: 教員が，プログラムの内容や，使用されている技法などを解説する．
- 執筆: 学生は，与えられたプログラムについて論述する．書き終えた人から教員に提出し，退出する．
上の構想は，後期授業が始まる前のものでして，実際に昨日の授業で，やってみました．ついでに自分なりに工夫してみました．というか苦労しました．あるいは苦労させてしまいました．
- 時間配分は…
- 予定：テーマ確認10分，タイピングと構想20分，講義20分，執筆40分の合計90分
- 現実：テーマ確認10分，タイピングと構想30分，講義30分，執筆30分の合計100分
- 課題・解答用紙はA4の両面で1枚です．表がプログラムコード（と時間記録欄），裏が論述のスペースです．表のプログラムコードに書き込むと，論述のとき見返すという手間が発生しますから，自分のノートで検討するといいですよ…なのですが，そうする人はあまりいなかったような*1．
- 「書いてね」と指示して，すらすら書けるわけでもないので，参考にしてもらおうと，例題プログラムとその論述例を作っておきました．ある程度真似をしてもいいけど，単純なコピーでは間違いになるよう配慮しました．例えば，例題ではコマンドライン引数を順に（forループで取得して）処理させていますが，授業での課題は，argv[1]しか参照していません．
- 答案は赤入れをして，次回授業の開始時に，配布資料と引き替えの形で，返却します．教員側ではこれから，赤入れをして，個別に見ていくとともに，間違いの傾向を知ることにします．
- 裏にはアンケートも入れています．いける学生・あかん学生（プログラミング） - わさっきから4項目に，「ストレスを感じた」「楽しかった」を加えて，それぞれチェックしてもらいました．
来年1月末にも実施し*2，タイピング速度向上*3，論述の質の向上や，アンケートでのプログラミング意識向上を確認できるといいのですが，どうなるでしょうか．
ただこの形式の実施，継続するには…極端な話，来年度から私の授業を完全に演習室に移行して，この形式で行うのがいいか，検討してみると…厄介な点があります．
1回の授業で一つのプログラムしか取り上げられないことです．2つは時間的に無理です．
半年でCのプログラミングで学ぶべきことは多岐にわたり，毎回1個×15週とするのでは，伝えきれないでしょう．
一つのプログラムに，永字八法のようにいろいろな要素を取り込めるといいのですが（実際それを試みたのですが），そうすると今度は，「このプログラムの中心となる処理は何か？」が問いにくくなります．
中心となる処理を読み取（らせ）ることは，決して難しくありませんが，論述に際して，中心となる処理の説明が，相対的に小さくなってしまうことを，危惧するのです．
