新年度は，例年通りの4年ゼミ*1をしないかもしれないので，自分の研究室の学生だけで4年ゼミをするならどうするか，妄想してみました．
方針
- 以下の情報を参考にし，チームワークで一つのアプリケーションを構築してもらいます．
- JABEEにおけるエンジニアリング・デザイン教育への対応 基本方針(PDF)
- 『ずっと受けたかったソフトウェアエンジニアリングの授業(1)』，『ずっと受けたかったソフトウェアエンジニアリングの授業(2)』．これらの本を以下，著者のイニシャルをとって「TK1」「TK2」と書きます*2．
- 研究室内で実施し，大学院生にも参加してもらいます．当研究室は毎年おおよそ，修士2名，卒研4名という人数構成です．これを後述の通り2班に分けると，1班あたり修士1名と卒研2名の合計3名ですが，足りなければ，他の研究室の学生や下級生の参加もOKとします．下級生は，自主演習として実施するものとします．すなわち十分に活動し，所定の書類を提出すれば1単位になります．
- 4年生にとっては卒業研究活動の一環ではありますが，卒業論文には盛り込まれません．この4年ゼミをしながらも，研究テーマを持ち，調査やシステム構築をしてもらいます．
- 4月中旬に開始し，7月中旬に終えます．7月下旬は試験で，何人かの学生さんも，そして私も忙しいので，外します．残念ながらもし，期間までに終わらなければ，8月にしますかね．
- 参加者に均等の努力量を求めません．授業が多ければそれを優先しましょう．各人の授業や就職活動などを考慮して，期間内に十分に活動できることを，最初に班の中でよく考えさせます．
- 動くものができ，お披露目してその活動はおしまい，というのはもったいないので，途中と完成後の相互評価を取り入れます．また，完成品はプロジェクト後も維持管理するものとします．できれば友情も．
以下しばらく時系列で．それと「教員」は，私のことです．
春休み：2つのプロジェクト
この時期の作業，というか検討は，教員一人で行います．
研究室内の学生を2つの班に分けて，班ごとに一つのプロジェクトを実施してもらいます．
一つのプロジェクトは，教員が設定します（教員提案型）．
もう一つは，上の教員提案型プロジェクトのゴールをもとに，それと同じくらいの努力量ででき，有用なプロジェクトを，その班のメンバが話し合って決めてもらいます（学生提案型）．
教員による選定や，学生による決定について，要件などは以下のとおりです．
- 何らかの実用的なデータベースを作るものとします．研究室活動に役に立つものを原則とします．「データベース」は，伝統的なDBMSを用いたものでなくてもよく，多数のデータをサーバに格納し，他のPCから効率よく取得できればかまわないとします．
- 「作っておしまい」防止のため，検討・試作期間を含めて2年間は維持管理することとします．2009年4月にこの4年ゼミをするなら，2011年3月までは動かすということです．管理するのは開発したメンバでなくてもかまわないとし，他の人でもスムーズに使用・管理できるよう，ドキュメントを整備してもらいます．
- データベース設計やコーディングよりも，適切な計画を立て，達成を確認していくことと，情報（コンテンツ）の収集・整備を重視します．
- 教員提案型プロジェクトは，目標（WhatとWhy）を伝えますが，それを実現するための手段（How）については，学生に考えてもらいます．
4月：検討・計画
初回ミーティングで，教員から「4年ゼミ実施の流れ」「エンジニアリングデザイン」「チームワークによる開発」「プロジェクト運用を支援する様々な書類」について説明し，班分けします．班の中に1名以上，大学院生を入れます*3．
班ごとに，リーダを決めます．といっても，大学院生でいいでしょう．4年生が務める場合には理由書を作ります．
あとは各班で自主的にミーティングを行い*4，方針を決めます．
教員提案型，学生提案型のいずれも，「チームシート」と「企画書」を作ります．チームシートは後述．企画書に書くべきことは：
- プロジェクト名とコンセプト
- 何を対象として，何を用いて，何をする（開発・構築する）のか
- なぜそれを手がけるのか
- 完成すれば，誰にとってどのようなメリットがあるか
- 誰がどんな役割で参加するのか（研究室外の参加者を含む）
- どんなスケジュールで実現し，完成後はどのように維持するのか*5
研究室外の学生に参加してもらうときは，その都度，教員の承認を経ます．
5月：方針確定
ゴールデンウィーク明けに1コマ，その次の週に1コマとって，ゼミを開催します．当然，全員参加できる時間を選びます．
班ごとに，リーダが企画を説明してから，質疑です．質問は主に教員がしますが，時間をとって，説明しない班のメンバにも出してもらいましょう．
1週目はあら探し*6で，2週目で確定させます．
その後*7，計画書の作成，プロトタイプ構築やコンテンツ収集を行っていきます．
6月：中間報告
方針確定から3週間後に1コマ，その1週間後に1コマとってゼミを開催します．ここでもやはり，全員参加できる時間を選びます．
班ごとに，リーダおよび各メンバが進捗を報告します．ここでも1週目はあら探し，2週目は修正の確認と，残りの期間で各人そしてプロジェクトとして何をすべきかの見極めです．
6月に試作品，7月に最終版というのでもかまいません．
動くものが見えない場合にも，収集しているコンテンツの例は，ほしいところです．
7月：完成
7月中旬に1コマとってゼミを開催します．言うまでもなく全員参加です．
デモンストレーションのほか，このプロジェクトを通じて作った成果物（コード，仕様書，障害処理票，登録レコードなど）の数量を報告します．
リーダは各メンバの貢献を述べ，班外の協力者を挙げて感謝します．
教員は講評をします．
作成すべき書類
- チームシート：TK1 pp.170-171の情報をもとに拡充します．最初のページはプロジェクト情報（全体の目標など）ですが，プロジェクト各メンバが，一人1枚でめいめい自己紹介し，プロジェクトでの役割を書きます．
- 企画書：5月の方針確定までに注力する文書です．TK1 pp.158-169の「システム提案書」「開発計画書」を参考にしつつ，ビジネス書でよく説かれる企画書の作り方も取り入れます．小さい分量に凝縮するのが特徴で，具体的には，プロジェクト名とコンセプト説明で1枚，残りの情報は2〜3枚くらい．
- 仕様書：企画書に呼応して，システム実現のための外部仕様書を作ります．TK1 pp.176-192の「外部設計書」が有用でしょう．6月の中間報告までに，確認します（できれば，6月ゼミ発表よりも前，例えば5月末に教員がチェックすべきなのですが）．枚数は問いません．
- 不具合発見・改善シート：システム構築だけでなく，文書作成の段階でも，あらかじめチームの個々人による批判的な目により，その完成度を高めることができます．単に書き換えるだけでなく，どのような問題を発見し，誰がどのように修正したかを記録することは，批判的な目の「見える化」になります．文書についてはTK1 pp.174-175の「レビュ記録表」，システムについてはTK2 pp.190-191の「障害処理票」ですが，個人的にはなんとか一元化したいものです．不具合発見フェーズと，不具合改善フェーズは別（の日）とし，日付を明記します．
- 自己評価票：プロジェクトにおいて自分が十分に貢献したか，当初予定の役割を果たしたかを振り返ります．5月，6月，7月のそれぞれ始めに目標設定を行い，月末（7月はプロジェクト終了時）に評価を書きます．5段階評価と自由記述からなります．作成後，リーダと教員が見ます．
- 相互評価票：プロジェクトにおいて自分以外の各メンバが十分に貢献したか，当初予定の役割を果たしていたかを振り返ります．これが書けないようでは，チームワークのプロジェクトとは言えません．5月，6月，7月のそれぞれ月末（7月はプロジェクト終了時）に書きます．5段階評価と自由記述からなります．なお，5段階評価で全員同じ値にするとき，2人以上に5をつけるとき，（一人にでも）2以下をつけるときには理由書を作ります．全員が記入後，リーダが各メンバの分を振り分けて配り，各人，今後の活動に役立てます．自己評価票・相互評価票は，TK2 pp.192-193の「相互評価シート」に対応します．
書類はすべてWord/Excel/PowerPointのいずれかで作成し*8，Subversionでバージョン管理します．ただし，Subversion管理とは別に，すべての書類に日付をつけ，加えて企画書と仕様書には，改訂日と改訂履歴をつけます．
実施にあたっての課題
学生の離脱や，プロジェクトが立ち行かなくなったとき，ですね．
教員とリーダのみによる，リーダ会議を別途行うべきかもしれません．
*1:http://d.hatena.ne.jp/takehikom/20080429/1209418401，http://d.hatena.ne.jp/takehikom/20070401/1175375412
*2:TK1 pp.7-9に「TKメソッドについて」というコラムがあります．
*3:大学院生が足りなければ，教員が周囲の研究室の学生（と指導教員）に頭を下げてでも確保します．同一の学習背景を持たない学生同士のチームワークを取り入れ，3年ゼミの区別を試みます．
*4:インスタントメッセンジャーなどで議論するのも，いいと思います．
*5:コンテンツの数が成否において重要なら，7月まで，1年目終了時，2年目終了時のそれぞれで，何を何件格納する予定か，も．
*6:班内でどんなに議論しても，発表してみると課題山積というのは，3年ゼミでみな体験済みですので．
*7:確定させるより前からでもかまいませんが，軌道修正があり得る点には注意です．
