(cache) チームで学ぶ - 未来のいつか/hyoshiokの日記

2016-06-08

チームで学ぶ

PBL(Project Based Learning)の授業を持っていて、その教員が集まってあーだこーだという会に参加している。PBLという手法は必ずしも教員にとっても経験豊富なものではないので学生の指導方法とかに悩みが多いので、いろいろな立場の人が集まって、あーだこーだ試行錯誤や悩みについて披露し合う。

産業技術大学院大学でのPBLはウェブアプリケーションの作り方を学ぶというもので、モダンなソフトウェア開発手法やクラウドを前提としたツールなどを利用してチームで実際にものを作る。 *1

キーワードとして、Continuous Delivery (CD), Test Automation, Continuous Integration (CI), Version Control System, Test Driven Development (TDD), Platform as a service (PaaS), API, Agile, Scrumとか、ツールとしてgit, github, heroku, Travis CI, VirtualBox, vagrant, linux, Ruby on Rails, chef, Rakuten API, Trello, slackなどを使う。

数名程度のチームが数チームあって、各チームはそれぞれ自分たちが決めたサービスを11週で作っていく。

産業技術大学院大学の学生は社会人が多く授業も夜間に行われる。平日の夜に集まってチームごとに進捗を管理していく。土曜日の午前中に全体で集まって、チームごとに、今週やったこと（実装したこと）、作ったもののデモ、困っていること、来週やることなどを10分強で発表する。それを毎週行う。

ウェブアプリケーションなので、URLを叩けば作ったものが誰でも確認できる。みんなでいじっていると簡単にクラッシュしたりする場合もあるが、それを含めてのデモである。Demo or Die である。インストールしなくてもいいので「自分のローカルの環境では動くんですけど、インストールしたら動かなくなっちゃいました」というような言い訳は通用しない。Continuous Delivery (CD)ってなによというようなことを実際に経験する。

PBLというのは座学と違って、実際に何かをやってみて、経験することによって学ぶという方法論である。ソフトウェア開発などは座学でいくら教えたところで実際にやってみないと身につかないことが多いので、10週程度の時間、期間をかけて学ぶことは多い。

チームで開発することに関しても社会人ですら経験値は高くない。そのような場合に大学の授業という人工的な環境の中でいろいろな実験（試行錯誤）をしながら実際にプロジェクトを回しながら学んでいくことの価値は大きい。

例えば、リポジトリにマージしてビルドを壊しちゃうことなんかよくある。ローカルで試してからpushすればいいだけの話であるが、それができない。理屈ではわかっているが習慣として手に馴染んでいないといきなりpushしたりする。そーゆー瑣末なことから始まって、様々な経験を積んでいく。コミットの塊は小さくするとか、コミットログの書き方がどうだとか、ソースコードの読み方、テストの書き方、デバッグの仕方、トラブルシューティングの方法、バグレポート、イシューの書き方などなど、ちょっとしたことなんだけど、必ずしも明示的に言語化されているとは限らないが、重要なことを経験していく。

同じペースで他のチームもプロジェクトを回していて、週に一度、全部のチームが集まって、報告をする。デモが必須なので、綺麗なパワポを作る暇があったら、デモを完成させろという価値観になる。実際プレゼンにパワポはいらない。Demo or Dieだし、Done is better than perfectを実践する。

進捗が全然はかばかしくないチームもあれば、すごく進んだチームもある。githubのコミットを見れば一目瞭然なので隠しようがない。全然コミットがないチームはなぜ進まなかったか、何に困っているかをテーブルの上に出す。大きな機能の実装中であるとか、マージしたら壊れちゃいましたとか、様々なことがある。

他のチームのデモを見て自分以外のチームから学ぶ。チーム内での経験から学ぶことは多いが、それ以上に他のチームの経験からも学ぶことは多い。11週間で経験できることを１とすると５チームあれば５倍学べる。やってみないとわからないことを学ぶのは時間がかかる。その学びを加速するために、他のチームが経験したことを疑似体験する。実際にやったわけではないのだけど、座学で学ぶことよりもはるかにリアルな経験則を共有する。コンテキストや事情を共有しているので理解が腹落ちする。

githubのログを見ていれば、コミットが多い週、少ない週、その差が激しいチームもあればコンスタントに進んで行くチームもある。その差はなんなのか。学びのヒントがある。いつコミットしたのか、残業や徹夜は禁止して、頑張らないで開発していくにはどうすればいいのか。何かにつまづいて延々悩んでいることに何か価値があるのか。1時間調べたり試してみてうまくいかなかったことは誰かに聞いた方が早いのではないか。チーム内で解決できなければ、毎週のデモの時に困っていることを相談してみるというようなこともできる。