どうやって教えるか

Agile開発 Ruby on Rails

JavaBlackさんのオブジェクト指向プログラミングの学習法(初心者向け)を興味深く読む。

  • 自分が初心者と思っていて
  • 言語から極めて行こうという向上心をもっていて
  • 自習でいく

という人はこれが定石かな、と思った。

自分の所ではOOP云々よりは、RailsでAgile開発をする人をどうやったら早く育てられるだろうか、という取り組みをやっている。

  • まずは単一クラス・単一フォームでの簡単なアプリを解説
  • その応用で、単一クラス・単一フォームの簡単なアプリを書かせる
  • 次にリレーションのあるクラスとそれを使ったアプリを解説
  • その応用で、リレーションのあるクラスを使ったアプリを書かせる
  • テスト自動化についての説明
  • テスト自動化を自分達が書いたアプリに適用させる
  • Agileのプロジェクト計画管理を説明
  • 自分達のプロジェクトの計画をたてさせる
  • その計画にそって開発開始
  • 途中、テストが膨らんだり実装が汚くなってきているのを見つけたらリファクタリングを教える
  • リファクタリングの規模に応じて、継承などのOOP技やRuby独自の文化（モジュール化など）を教える

とりあえず今の所は、「インスタンス変数と局所変数の違いとは？」　みたいなことを一切教えなくても、にRailsでコードを書けて、リファクタリングもなんとなくできる、という人が育ちつつある。もちろん、RubyやRailsの持つポテンシャルのほんのちょっとしか使いこなせてはいないのだろうけれど、それでもなんとかなるのはRuby/Railsのすごいところか。あと、最初から雑多な知識を詰め込もうとすると、聞く側は疲れちゃう。こういうのって、必要なタイミングで教えればいいのではなかろうか。

本は対話が成り立たないから読み手に対してある程度の仮定をたてざるを得ない。だから細かい前提をいろいろ書いたり、そこを端折ろうとして無茶な例え[*1]を持ってきたり、総合解説書的な分厚いものになったりして、読み手が苦痛を覚えることになってしまうのではなかろうか。本も（自分が嫌いな）ドキュメントの一種なのである。

対話的に教える場合は、相手がわからないという部分に関して重点を置けばいいから、本が持つような冗長性はなくせる可能性は高い。まあ、本みたいにレバレッジはきかなくなるけど。

*1:犬がワンで猫がにゃー