島までは遠い

佐藤正志@サークルアラウンドのことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる予定。しばらくは工事中。

Railsチュートリアルが悪い?違いますよ。Railsチュートリアルから入ってRailsの事「だけ」しか学んでないのが悪いんですよ。

f:id:ms2sato:20171229205308j:plain

qiita.com

これに関連して私の言いたい事は下記です。

  • Railsチュートリアルは単なる文書なんだから間違いが書かれていないなら善悪など無く、悪いのは使う側の人間です。
  • たとえRailsチュートリアル「だけ」マスターしても、自分のサービスなど作れないしシステム開発者になどなれなくて当たり前です。
  • 必要なのは「教本にないことを実現しようとした時に起こる問題を解決する能力」それにはもっと低レベルの知識がないとできないです。
  • 最も悪いのは「そういうこと」を教えてあげないこと(だからこのエントリを書いた)

Railsチュートリアルが悪いのか

チュートリアルはただの技術文書で内容自体に誤りがそんなに無いと思うので、「チュートリアルが悪い」という話はすでに何かおかしいですよ。道具が悪いなんてことは殆どなくて、悪いのは使う側の人間ですから。

文書というのは対象の読者がいて、それに対して適切な粒度で情報が提供されるものです。私の見解ではRailsチュートリアルは「ある程度システム開発がわかっている人向け」に書かれています。実際、文書の方にも下記のように書かれているんです。

本チュートリアルでは少なくともHTMLの知識と何らかのプログラミング経験があることが望まれます。ソフトウェア開発がまったく初めての方には、拙著「Learn Enough to Be Dangerous(英語)」のチュートリアルを先にやっておくことをおすすめします

初めてのシステム開発で初めてのプログラミングという人に向けてはいないと思います。ですから初学者が最初にあれをやろうとすれば「わけもわからずとりあえず書き写して、書いた通りにすればなんとなく動いて、うまく動かなければエラーなど読まずに文書とニラメッコして書き間違いを探し、分からなければ誰かに答えを聞く」という手段になりがちです。チュートリアルをやるための前提知識を全く持っていなければ理解不能であるのは当たり前でしょう(もちろんこの進み方でもある程度の理解を獲得できるすごい人はいます)。

ただ(これはなにがしかの文化のようなものだと思っているのですが)「過酷なRailsチュートリアルを乗り越えた」という共通体験を持って繋がりを作っている人達はいるような気がしています。部活や仕事の体験を、酒の肴に「あれはキツかったよなぁ」ということを話して共感し合う人達っているじゃないですか。あんな感じではないかと思います。それはそれで文化という大事なものかもしれないと感じています。

とにかく、悪いのは誰でも彼でも「とりあえずRailsチュートリアル」という形に押し込めてしまうやり方だと思っています。Railsはベストプラクティスがギッシリ詰まった凄い道具です。そういうハイスペックな道具を使うには前提となる知識もたくさん必要ですし、それなりの経験を積んでからでなければ、なかなか使いこなせないと思った方がいいです。

Railsチュートリアル「だけ」ではダメなことが明らかになる瞬間

おそらく多くの先人がぶち当たったのは下記の二つのタイミングだと思います。

  • 書いてある通りにやっても動かない
  • 自分で機能を追加しようと思ったけれども、できない

「エラーメッセージが表示されるが、その先をどう対応して良いのか分からない」という形で現れることが多いと思います。エラーメッセージすら認識せずにただ「リロードしたけど表示されない」とか「赤い画面が出てそっ閉じしている」のような認識の人もいるでしょう。

エラーメッセージを読んだり、メッセージをコピペして検索すれば答えがあるようなものの場合にはそれだけでも解決できます。 実際に多く必要なのは「あるべき姿」への理解です。例を挙げましょう。

例: 画面のformから情報を登録しようとしたら、エラー画面になってしまう

表示された画面のHTMLのformタグのactionに書かれているパスが、サーバー側で受け取り可能になっていなければ、情報は受信できません(もちろんこれ以外にもエラーが発生する可能性がありますが、あくまで例として)。

そして下記のような具体的な行動をして確認していく必要があります。

  1. form_for で生成された HTMLのformのactionを見なければいけない
  2. rake routes で対象のURLが作成されているか確認しなければいけない
  3. 思った通りの通信をサーバーが受け取っているか、ターミナルのログを見なければいけない

もちろんRailsチュートリアルでも、似たような対応 は載せてくれています。ただ、初学者の人がこの説明だけで把握することは難しいと思いますし、説明の内容があくまでも「Railsでどう考えるか」までになっています(これは対象読者を考えれば当然だと思います)。

私が先に挙げたような例の場合ですと、1の部分の誤りを見つけたら、HTMLのformで起きていることから Railsの form_for の記述へ逆算が必要になるんですね。「自分の望んでいるHTMLのformを作成するには、Railsでどう書いたら良いのか」というような思考になります。これは文書と逆の思考だと思うので、ある程度WEBシステム開発に関しての慣れがなければなかなか辿り着けないと思います。

とても簡易な体験で良いので、HTMLのformとサーバーの関係が腹落ちしている方がこういったトラブルシュートは遥かに早くなります。それがない人は闇雲にトライアンドエラーを繰り返すだけなので、ここでずっと足踏みしてしまうんですね。「Railsを学んだけれどシステムを作れない人」は、こういった部分の腹落ちが足りていないようです(これは私のところの勉強会に来ていただいている初学者の方を見て確認しています)。

同様のことはActiveRecordとSQLのようなところにもあります。

というわけで、RailsチュートリアルでRailsを繰り返す「だけ」では自力で開発するのは難しいです。HTMLやHTTP通信がどのように情報を交換し合っているかの理解や、DBからSQLでどのように情報を出し入れするのかというところの理解が必要になってきます(DBに関しては、効率が悪くなっても構わないのであれば最初の頃はある程度踏み込まずに進めることもできるでしょうが、最終的にはSQLが分からないとダメですね)。

悪いのは、誘導している側ですよね?

最初に相手の初学者の持っている性質や力量を考えずに「Railsチュートリアルをやれ」と押し付けてしまう人や、Railsチュートリアルを真似たようなカリキュラムを提供して適切なフォローをしないスクールや、「俺が苦労したんだから同じ道を歩め」と考えることを放棄する先輩など、そこに誘導する側に問題があると私は思います。

そして、チュートリアルで腹落ちできなければ初学者は「自分にセンスがないからだ」と去っていってしまう。こんなに悲しいことは無いですよ。ちょっと最後感情的になりましたが、日々少しずつ不満を抱えているところに件の記事があって言いたいことを吐き出してしまいました。

ちなみに私はRailsチュートリアルに達するまでのステップが不足していると思っているので、そういうところを埋めることをやったりしてます。吠えているだけで何もしてないんじゃ無いですよ、ってことで。