Rubyに感銘を受けたという話に対して以下のコメントをいただいた。
はじめまして，いつも大変興味深くブログエントリ拝見させていただいております．「Rubyに感銘を受けたという話」に強く感銘を受けました！私の研究室でも同じことを試してみたいなと思うのですが，可能な範囲で期間・テーマ設定・指導方法についてお伺いできないでしょうか？
（Twitterより）
ご要望があったので答えられる範囲で。なお、この説明は私個人の考えであり、私の所属研究室および所属組織の統一見解ではないことをお断りしておきます。
研究室の基本的考え方
研究テーマとしては、学術的に面白いことをやるか、実用的に使えるものを作るかどちらかにしなさいというのがボスの考え。このため、修士進学しない学生に対しては多くの場合、「誰か必要としているけど、まだ作られていないソフトウェア」を開発するテーマを提示している。
特にIT企業にSE・PGとして就職予定の学生に対しては、ソフトウェア開発のテーマを勧めている（6個ぐらいテーマを提示してえらんでもらっている）。
期間
基本は1年間。でも、実際のところ就職活動が終わってから学生は本当に手を動かしはじめるので、実際は8月以降。でも、これすら理想で本当にエンジンがかかるのは11月以降。よって、11月〜3月中旬までの4か月強です。
テーマの決定は4月上旬を心がけています。
事前準備
当然、ソフトウェアを作ることにより解決すべき問題に対して、適切な道具を使うことが第一条件です。今回は、開発対象のソフトウェアがWebアプリケーションだったので、Ruby on Railsを使いました。
Ruby on Railsを使ったのは、ここ数年私がRuby on Railsを使っていたからです。教員や先輩学生にRuby on Railsの利用者がいない場合には、Ruby on Railsの使い方だけで1か月〜2か月かかってしまう可能性があります。Webアプリケーション開発フレームワークを使わせる場合は、学習コストにご注意ください。2011年度は、すでにRuby on Railsの利用者の学生がいましたので、その学生に勉強会を開いてもらいました。
学生に開発環境の構築から勉強させると時間がいくらあっても足りないため、環境の設定の仕方はあらかじめマニュアル化しておきます。2011年度は以下のマニュアルを用意しました。
また、2011年度はRuby on Rails が 3.0→3.1→3.2 とグリグリと変わりました。また、今後の保守を考えるとRubyも1.8ベースよりも1.9に移行するのが良いようにも思えました。ですので、ここいらへんの変更については私がチェックし、学生にはどこを変更すればよいかだけを教えました。
また、学生1人につき１つずつTracのプロジェクトとSubversionのリポジトリを用意します。理由は、1) 卒業研究で開発したソースコードの紛失を防ぐため（卒業時に提出し忘れて卒業してしまう学生が結構いたので） 2) 自分のやるべきことをはっきりしてから作業を進める癖（チケット駆動）を学んでもらうため です。同じソースコードに別々の機能を追加するタイプの研究の場合はTracでは同じプロジェクトとし、Subversionのリポジトリは branches以下にそれぞれのテーマ用ブランチを切ります。
Tracの使い方については、以下を読んだうえで好きに使えと言いました。
Subversionの使い方については checkout、commit、update、log、copy、move、 mkdir の使い方だけを教えました。mergeは面倒なので教えていません。trunkのソースコードを破壊されると困る場合は、trunkへのコミット権を私だけが持つように設定しました。
今回は、Tracとの連携のためSubversionはApache経由で使えるようにしました。
指導方法（大まかな流れ）
ソフトウェア開発の定番の道筋で進めさせました。
- 問題認識
- テーマの決定時に問題自体は提示していますので、主にその問題をどういうソフトウェアで解決するのかと、どうしてそれで解決できるのかの説明ができるようにすること
- 要求分析
- 問題を解決 or 緩和できるソフトウェアとはどういうものかの定義
- Whatを列挙するときにHowを列挙すべきでない
- それが実現できないならば何の意味もないじゃないですか！
- 機能定義
- 要求を満たすための機能の定義。
- この段階では自分が実際実現できるかどうかは問わない。
- すべては問題を解決できるかどうかだけで考える。
- 設計（機能の実現方法の決定＆道具選び＆詳細設計）
- 実装
- 「〜を解決・緩和するソフトウェア」と最低限言える（強弁すれば苦笑いで受け入れてくれるレベル）だけの機能の量・質で実現する（これを越えないと卒業させない）。
- 評価
- 「〜を解決・緩和するソフトウェア」であることをどうにか客観的に説明する
- 必要に応じて実験をする
もちろん、上は理想であり、なかなかこのようにうまく進みません。どういう助言をするかについては卒業論文、修士論文関連のエントリーに書き連ねていることを個人や状況に応じて助言しています。
一つ上げるとするならばとにかく質問します。言い方は工夫しますが、基本的に以下のエントリーに挙げた質問のフルコースをふるまいます。卒業・修了する際に研究室の学生に「X年間で何を学べた？」と尋ねると「日本語は難しいということがわかりました」と返してくれるようになります。
指導方法（RubyやRails あるいは他の言語に対して）
RubyとRailsについては以下の本を数冊ずつ用意しました。
あとは1冊Rails3の入門の本を用意した方が良いと思います。Webページも良いのですが断片であることと、バージョン違いの情報もひっかかるので慣れていないと混乱の下です。
あとは、インストールメモや設定メモをとらせるように半強制します（とっていない場合はちょっと威圧する程度で十分だと思います）。
あとは適宜、進捗報告＆質問させます。
今回の件から得た知見
思いつくままに
- やってみないと質問が思いつかないので4月〜7月に一度プログラムを書かせるのが重要
- 相談しあえる人（not 教員）が研究室内にいると心強いらしいので、テーマや道具を被らせるのは案外重要
- TracやSubversionを用意しても使わない人は使わない（一方で、はまる人は非常に喜んで使う）
- 開発系は頻繁にデモをさせた方が良い
おわりに
参考になるのかわからないけどここまで。
内容が低レベルだとしてもそれは next49 のレベルが低いだけで、私の所属研究室や学生、所属大学がそうではないということをご留意願いたい。
