挫折しない！Railsチュートリアルの進めるポイント

#はじめに
みなさんどうもあちえです。
今回はRailsチュートリアルの進め方について解説します。
記事の前半では進めるときのポイントを。
後半ではポイントの中の**繰り返さない**の理由について書いてあります
では！

[Ruby on Railsチュートリアル](https://railstutorial.jp/)
#ポイント
「Ruby on Railsチュートリアル」(以下チュートリアル)の進める際のポイントは3つあります。

1. 繰り返さない
1. 理解できなくても進む
1. アウトプットしよう

この３つです。
それでは順に解説していきます。
## 繰り返さない
このなかで**一番重要**と言っても過言ではないくらい重要なポイントです。
繰り返してはいけない理由は記事の後半で解説します。

よくネットやTwitterなどで「チュートリアル〇〇周しました！」と言っている人がいますが正直**無意味**です。
すごいとは思いますし、少なからず無意味ではありませんが、無駄であることはかわりありません。
後半でも解説しますがプログラミングは基本「どれがけアウトプットするか」であり別に「暗記」しなくてもいいです。
それよりもアウトプット重視で学習してください。
ここに関しては記事の後半で解説しているのでここでいったん切り上げます。

## 理解できなくても進む
２つ目の「理解できなくても進む」は１つ目と同じくらい重要なことです。
これは実体験もありますが、プログラミングは「暗記ではなくアウトプット(実践)」が鍵になっていきます。
なので理解できなくてもどんどん先に進みましょう。
理解できないところでうずくまっていて動かないよりもどんどん進んでいろんな知識を吸収したほうがいいです。
自分の実体験を話すと正直チュートリアルのログイン機構なんて今はさっぱりわかりません。
エンジニアと名乗っておいてこれはやばいかもしれませんが、正直**動けばいい**のです。
「は？何いってんだこの中学生エンジニアは」と思った方もいらっしゃると思いますが、本当です。
プログラムなんて動けばいいのです。あとはわからなければ調べて動く方法を探します。
これでいいのです。
それに実際に学んだことをアウトプットしながらSNSなどのサービスを作っていけば自然に理解できるようになってきます。
これは本当です。
つまり理解できなくてもすすんで数をこなすことで理解できるようになります。

そこでうずくまっている方が理解できず逆効果だと思います。
正直**その場で理解できないのなら今考えても理解できない**と頭の片隅に入れておいて気軽に進めていきましょう。
## アウトプットしよう
これはチュートリアルの話だけではなくIT全般になりますがこれまた**重要**です。
アウトプットをすると知識はより定着すると言われています。
これは様々な海外の研究結果でもわかっていることです。
アウトプットの方法ですが簡単なのは

- Twitter or Qiitaに投稿する
- 実際に作る

の２つが一番簡単だと思います。
例えばTwitterやQiitaなどで知名度や影響力を上げておくと案件獲得がしやすくなりますし、IT業界では**人脈**も鍵になってきます。
これを継続することで知識も定着しますし、知名度や影響力も上がっていきます。
２つ目の実際に作るは簡単です。
実際に自分でサービスを作るだけです。
例えばチュートリアルを修了した方であれば、少し独自の機能を取り入れた「Sample App」などを作ってみるなどして書いていきます。
他にもQiitaやTikTok、Instagramなどを真似して作ってみるのもいいでしょう。
このようにアウトプットもしていきましょう。
# 繰り返してはいけない理由
では記事の後半です。
## 効率が悪い
受験勉強や資格勉強じゃあるまいし、プログラミング学習において繰り返しはめちゃくちゃ効率が悪いです。
これは実際の実務でも「繰り返し出てくる処理はクラスや関数にまとめる」などと言われています。
プログラミングというのは**暗記**ではなく**どれだけアウトプットしたか**が重要になってきます。
プログラミングはカンニングOKです。
「わからないところがあればすぐに調べる」
「エラーがわからないならコピペで検索」
これはプログラミング学習だけではなく、実務でも同じです。
プログラミング学習の目的は「完璧にすること」ではなく**ざっと技術や知識を浅く学習して必要な時に検索できるようにする**ためです。
それにプログラミング上ではこのような格言も残されています

> DRY(Don’t Repeat Your Self：繰り返しを避けること)原則は、プログラミングに関して守るべきとされている原則の中でも特に重要なものと言っていいでしょう。これは、Andy HuntとDave Thomasが、著書「達人プログラマ」の中で提唱した原則です。よく知られたソフトウェア開発のベストプラクティスやデザインパターンの中にも、基本的にな考え方がこの原則と同じものがたくさんあります。開発者は、アプリケーションの中に何らかの「重複」があれば、また、重複が起きそうであれば、それを察知する必要があります。そして、適切なプラクティスや抽象化によってそれを排除する必要があるのです。そのための方法を学べば、よりきれいなコードを書けるようになるはずです。

参考: [プログラマが知るべき97のこと](https://xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com/)

これは学習にも使えることができる考え方です

それに理解できなかったりわからないとしても実際に作ってアウトプットすることが一番の解決法です。
作り始めてわからないところがあったらチュートリアルを見てみてもいいですし、Google先生にもどんどん頼りましょう。
とにかく**手を動かす**これだけで、技術力や知識はバク上がりします。
## モチベーションが保たれない
実は人間って単調な刺激を脳が受け続けると集中力がキレたり、眠くなったりします。
だから学校では時間ごとに教科を変えています。
それと同じで同じチュートリアルを繰り返したところでただ飽きるだけです。
理解しようとしたり、覚えようとして繰り返すことは気持ちとしてはいいですが、やはり先程述べたとおり、**実践が一番の理解や知識定着の近道**というのを意識する必要があります。

よく考えて見てください。
個人的には「自分が成長していると実感する」ときが一番楽しいです。
チュートリアルも進めるのは難しいですが楽しいです。
しかしチュートリアルを何周もするとしましょう。
正直言って**嫌**じゃないですか？
自分はいやです。
飽きますし、なによりも効率が悪いです。

プログラミング学習以外にもモチベーションって結構響いてきますよね？
本当はモチベーションなど存在せず、しないときのいいわけなのですがここではわかりやすいように使いかました。
しかし実際**飽き**は人間である限りあります。
やはり周回せずに、いろんなサービスを作りながら学ぶのが一番楽しいと思います。
# さいごに
最後まで読んでいただきありがとうございました！
毎日更新しているのでよかったら見てみてください！
では！また明日の記事で！
### 参考文献

[Ruby on Railsチュートリアル](https://railstutorial.jp/)
[DRY原則 | プログラマが知るべき97のこと](https://bit.ly/39w2ctF)