銀行員からのRailsエンジニア

銀行員からのRailsエンジニア

銀行員から転身したサービス作りが大好きなRailsエンジニアのブログです。個人で開発したサービスをいくつか運営しており、今も新しいサービスを開発しています。転職して日々感じていること、個人開発サービス運営のことなどを等身大で書いていきます。

「プリンシプル オブ プログラミング」を読んで思ったこと、実践していくこと

1. はじめに

こんにちは。ゆうすけです。
実はRailsエンジニアとして7月から働くことが決まり(やったー!)、ブログのタイトルもちゃっかりRailsエンジニアに変えてます。
 
Railsエンジニアへの転職活動についてはこちらのnoteに詳細書きました。
 
現在は1ヶ月の休職期間(!)を満喫するとともに、7月から働く会社のエンジニア兼マネージャーの方からいただいたおすすめの本リストに従って絶賛読書中です。
 
ただ読んだだけでは忘れてしまうので、ブログに「思ったこと、実践していくこと」としてアウトプットしていこうと思います。
 
アウトプットの仕方については何がベストか分からないので試行錯誤していきます。
 
第一弾は、「プリンシプル オブ プログラミング 3年目までに身につけたい一生役立つ101の原理原則」という本です。
タイトルからして、これからエンジニアになる今の僕にめっちゃ必要そうな本ですね〜。
 

2. 本の概要

プログラミングの原理原則という名前の通り、質の高いプログラミングをするための先人たちの経験・知恵を具体例を用いて分かりやすく解説してあります。

 

3. 思ったこと・実践していくこと

各項目についてまず自分が思ったこと、実践していくことを書き、四角の枠内に本からの引用を記載しています。

 

コードを書くときは「コードの読みやすさ」を最重要視する
SIerで働いていた時、既存コードの解読にめちゃくちゃ時間がかかっていました。
(とてもとても分かりにくくてストレスだった、、、)
 
今後コードを読む人たちの時間・ストレスを考慮すると、コードを書くのに多少時間がかかったとしても読みやすいコードを書くべき、という考え方はとても共感できるので早く身に付けます。
プログラミングにおける1つ1つの判断は、「そのコードが変更される」という前提で行うようにしましょう。つまり、「変更に強いコードを書く」ということです。 そして、そのためには「コードが読みやすい」ということが、もっとも大切です。結局コードというものは、書いている時間より、読んでいる時間の方が、はるかに長くなります。変更されるという前提に立つと、書くのにどれだけ時間がかかっても、読む時間を短縮できるなら、十分に元を取ることが可能です。
 
コードは必要最低限のものだけ書く
「あの機能追加するかもなー、一応このコード書いておこう」とコードを書いて結局使われずに放置、、、というのは僕も心当たりがあるので気をつけます。
コードは「たぶん必要になるだろう」「必要になるかもしれない」で書いてはいけません。本当に必要になった時、必要なものだけを書く、という方針で臨みます。 ソフトウェアの変化を完全に予測して、先回りしたコードを書くのは不可能です。そこは割り切って、今必要なコードだけを書くようにします。
 
変数やメソッド名の命名のチェック法

分かりやすい変数名・メソッド名はコードの分かりやすさに大きく影響します。

変数名・メソッド名を見ただけで何のための変数・メソッドか分かったらすごく楽ですよね。

 

今までは何となく分かりやすいかなー、くらいの感覚で命名していて、チェックはしていませんでしたが、今後はこの方法でチェックします。
命名について、「名前可逆性」という考え方があります。これは、「名前は、その元となった内容の説明文を復元できなければならない」という命名指針のことです。 この条件を満たすために、「ループバックチェック」を行います。内容の説明文から名前を考えたら、今度は逆に名前から推測できる説明文を考えるようにするのです。説明→名前→説明の順で、1周回って元に戻る(ループバックする)ように説明が一致すればよい名前で、一致しなければ要注意となります。
 
技術はきちんと理解してから使う
当然と言えば当然ですよね。
きちんと理解していないと仕事で聞かれた時に答えられませんもんね。
 
ググって一番上に出てきたやつをコードだけ見てコピペで動いたからとりあえずOKはやめます。。。

技術を学ぶ時は、動作原理や進化の過程、設計の背景にあるものも同時に知るようにします。これで照準が合い、目的が達成されやすくなります。 よいプログラマは、時間がかかっても、言語・ツール・技術・問題領域など、分野を問わず、きちんと理解してから作業に取りかかる傾向があります。特に、プログラミングにおいては、「よくわからないけど、動いたから、これでよし」「よくわからないけど、直ったから、これでよし」とすると、後から必ず品質的な問題が発生します。きちんと理由を説明できるまで、粘り強く理解してから、コードを確定するようにしましょう。

 
コード内のコメントは「そのコードを書いた理由」を書く
今までは何となく分かりにくいかな、と思ったところにコメントを書いていましたが、コードだけでは表現できない、このコードを書いた理由を書くようにします。
 
何をしているかについては、きちんとコード書いていればコードを読めば分かるので極力コメントには書きません。
コメントがなくても読めるような、わかりやすいコードを書くのが理想です。 ただし、コードはどこまで行っても「What」と「How」、つまり「何をしているか」「どのようにやっているか」までしか表現できません。「Why」、つまり「なぜそれをしているか」を表現するには、コメントを使用する必要があります。 コードという文書は、読む人とのコミュニケーションに使用するものです。コミュニケーションを円滑にするのに役立つなら、Whyだけにとどまらず、進んでコメントを手段として使用するべきです。コメントで説明しなくてもよい、わかりやすいコードを目指しつつ、それでも表現できない部分にはコメントを書く、というバランスを持ったコードを書くようにしましょう。
 
技術的負債も借金の利子のように雪だるま式に増えていってしまう
技術的負債の話は利子の例えがすごい分かりやすかったです。
(元銀行員だからですかね 笑)
 
利子が雪だるま式に増えていくように技術的負債も開発を続けると雪だるま式にどんどん増えてしまいます。
返済不能になる前に、お金も技術的負債も極力早く借金は返すべきです。
実務経験がない中で技術的負債は正直ピンとは来ませんがしっかり覚えておきます。
すぐに返済できなかった場合、「利子」が発生します。汚いコードがソフトウェアに残り続けると、問題が大きくなるのです。負債コードを読むには時間がかかります。そこに修正を加えるとなると、さらに汚いコードになり、ソフトウェアの動作も不安定になってきます。利子は複利となり、指数関数的に膨らんでいくのです。 そして、利子が膨らみすぎたり、多数の負債を許容することによって、負債を抱えすぎてしまった場合、返済不能に陥ります。つまり、「機能追加」も「保守」もできない、不安定でアンタッチャブルなコードと化してしまうのです。
 
人に優しく、コードに厳しく
自分が言われる時のために覚えておきます。
7月から入社して自分のコードをズタボロに言われるだろうけど、これはイケてないコードを恨んで言っているのであって、自分に言われてる訳ではない、はず…
「人に優しく、コードに厳しく」して、人ではなくコードを批評します。
 
人に聞く前にまずアヒルに説明してみる
わからないことを教えてもらうために、わからない点を説明してる時に「あ!ちょっと待って…!こうかも…なんか分かっちゃっいました、すみません」てのはよくあります。
 
人に聞く前にヒルに説明してみることを習慣にしよう。
「説明する」というデバッグ 「ラバーダッキング」は、ある種のデバッグ手法です。 プログラミングにおいて、発生している問題や、問題を抱えているコードを「誰か」に説明します。すると、問題の原因に自ずから気付き、自己解決できることがあります。 この場合の「誰か」は、バスタブに置いたゴムのアヒル(ラバーダック)のように、話を聞きながら定期的にうなずくだけでよいのです。何かを言う必要はありません。 実際にやってみると、効果はてきめんです。場合によっては、説明し始めた途端に気付いて「あ、もういいや、変なところがわかったよ。ごめん、ごめん」ということになり、照れくさい思いをすることもあります。 「簡単で」「安い」のに、効果の高いデバッグ方法です。
 
解決が停滞した場合、「誰か」にそれを説明しましょう。 話しかける「誰か」は、それこそ「ゴムのアヒル」のように、無機物でも構いません。「説明する」という行為が重要です。 例えば、ある大学の情報系の学部では、ヘルプデスクのそばに「テディベアのぬいぐるみ」が常備されています。そして、不思議な障害に悩む学生は、人間のスタッフに相談する前に、ぬいぐるみに向かって説明しなければならないルールにして、一定の効果を上げています。
 

4. 余談(読書法について)

本についてのブログ一発目なので、僕の読書法についても紹介します。
 
僕は技術書、それ以外の書籍かに関わらず、レバレッジリーディング」という方法で読書しています。
レバレッジ・リーディング

レバレッジ・リーディング

 
この本は僕のバイブルです。
 
レバレッジリーディングとはこの本で紹介されている読書法で、
 
本の中で重要なこと(自分が覚えておくべきこと)はその本の中の一部であり、その一部をメモ(レバレッジメモ)に取り、そのメモを繰り返し読むことで本の内容を自分の中に落とし込むことができる
 
という読書法です。
 
大学生の頃はレバレッジメモを作るために、読書しながらメモをする箇所のページのかどを折り、該当箇所に線を引いて、読み終わった後にその箇所を全てワードへ入力していました。(結構面倒で大変でした)
 
しかし、kindleを購入してからそのプロセスがめちゃくちゃ楽になりました。
kindleでは本文を長押しすると好きな箇所に「マーカー」することができるのですが、そのマーカーした部分をwebサイトで見ることができるのです。
 
つまり、本を読んで、画面を長押ししてマーカーを引いていくだけでレバレッジメモが出来てしまうのです、、、!神!
 
しかも本体は驚くほど軽くてたくさんの本が入る!kindleすげー!
Kindle Paperwhite、電子書籍リーダー、Wi-Fi 、ホワイト

Kindle Paperwhite、電子書籍リーダー、Wi-Fi 、ホワイト

 
kindleのおすすめ記事みたいになってしまいましたが、個人的にはkindleは神ツールだと思っているので、まだお持ちでない方は是非購入を検討すべきだと思っています。
 

5. おわりに

後半は話がそれてしまいましたが、初めて書いた本の感想記事をお読みいただきありがとうございました。
 
「プリンシプル オブ プログラミング」はプログラミングの原理原則を網羅的に学ぶことができ、自分の状況によって刺さる原理原則は違うと思うので、定期的に読み返そうと思っています。
読み返した時にこの記事を見て成長を実感できたら嬉しいな〜。
 
この記事では今の僕に刺さった箇所のみの、本のほんの一部を紹介しているに過ぎないので、他の原理原則も知りたいという方は是非読んでみてください!
 
1章1章は長くなくて飽きないので、僕は2日でサクッと読み終えることができました。
プログラミングの原理原則について網羅的に学びたいという方におすすめです。
読んだ本についてのブログが今回だけで終わってしまわないように頑張ります!
ご意見・ご感想等いただけるととても嬉しいです。
 
皆さんプログラミング学習頑張りましょう!!

 

12時間でwebサービスを作り、更にnoteで技術チュートリアルを作ってみて思ったこと

12時間でサクッとサービスを作ってみました!また流行りの技術チュートリアルを作りました。

サービスの紹介と、技術チュートリアルを作ってみて思ったことを書いてみます。

 

 

1. 作ったサービスについて

1-1. サービスの紹介

文字入りのOGP(※)を簡単に作成し、ツイートできるシンプルなサービスを作りました。

OGPとはOpen Graph Protcolの略称で、 FacebookTwittermixiなどのSNSでシェアされた際に、そのページの タイトル・ URL・概要・アイキャッチ画像( サムネイル)を意図した通りに正しく表示させる仕組みです。

Ferretさんの記事の引用です)

 

こんなツイートが簡単にできちゃうサービスです。

 

12時間でまず「POWERTWEET」というサービスを作ってリリースしたのですが、

・ツイート前にプレビューが見たい

Twitterログインせずに投稿できた方がいい

という意見を反映し、そこから10時間ほどで、進化系の「BigTweet」を作ってリリースしました。

f:id:ysk_pro:20180519200600p:plain

 

BigTweetの特徴はこちらです。

・簡単3Stepでツイートできる!(Step1. 背景画像を選ぶ、Step2. 画像内に表示する文字入力、Step3. プレビューを確認して投稿)

Twitterログイン不要で安心・気軽!

・ツイート前にプレビューが見れる!気に入らなければツイートしなくてもいいので、とりあえず画像作成を試せる!

・背景画像は32種類(2018/5/19時点)から選べる!

bigtweet.herokuapp.com

Ruby on Railsで作りました。

 

1-2. このサービスを作った背景

僕は2017/11にプログラミングをはじめて、2018/3に2ヶ月かけて作成した初めての個人開発サービス「Jobmiru」をリリースしました。

自分の原体験からこんなサービスあったらいいなー、と思い作ってみました。

一言で言えば、その会社で身につくことに特化した転職口コミサイトです。

www.jobmiru.com

ご参考としてサービス紹介のブログです。

ysk-pro.hatenablog.com

使ってくださる方もおり、はじめて作ったサービスとしてはよかったものの、「自分の働いていた会社の口コミを投稿する」というのは投稿のハードルが相応に高く、気軽に投稿できて誰でも使ってもらえるようなサービスではありませんでした。

僕としては、サービスを作るからには出来るだけたくさんの人に使ってもらいたいという思いがあり、Jobmiruでの経験から投稿・利用のハードルが低く、誰でも気軽に使えるようなサービスを作りたいと思っていました。

また、2018/1末にはじめたTwitterにハマっており、Twitterを絡めたサービスが作りたいという思いもありました。

OGPは今ではどんなサービスにも実装されていますが、OGPを生成するだけのサービスは意外とないのでは?と思い、JobmiruにもOGPを実装していたので簡単に作れそうだな〜と思い、このサービスを作るに至りました。

 

1-3. 12時間でサービスを作れた理由

Jobmiruを2ヶ月かかってガッツリ開発していたからです。

POWERTWEET、BigTweetについてはJobmiruのパーツを組み合わせることでほとんど実装できました。

たくさんサービスを作っていけば、「あのサービスのあの部分と、あのサービスのあれを組み合わせればいけるな〜」みたいな感じで開発スピードはガンガン上がっていく、みたいな感覚が少し体験できました。

 

1-4. サクッとサービスを作ってみて思ったこと

やっぱり人に使ってもらえるのはめちゃくちゃ嬉しいです。

使って下さい、とお願いした訳ではなく、タイムラインに流れてきて面白そうだと思って使ってみました、という声を聞くとサービス作って良かったな〜と思います。

(Jobmiruは大半がお願いをして投稿してもらった形でした…)

ハッシュタグ #BigTweet で検索して、使ってくれた人に絡むのが最近の楽しみになっています。

#BigTweet - Twitter Search

BigTweetしていただければ、僕が必ずビッグリプ(BigTweetでリプすること)します! 

 

2. 技術チュートリアルについて

2-1. 概要

手順通りに作って行けば誰でもBigTweetが作れる「BigTweetチュートリアルを作りました。

Ruby on Railsの基礎を学んで、自分のサービスを作ってみたいという初学者の方向けに書いており、コードの細かい部分や、HerokuやAmazon S3の設定の仕方等々まで触れているのでかなりのボリュームになりました。

note.mu

 

2-2. チュートリアルを作った背景

noteでの技術チュートリアルが流行っているなーと思っていて、またRuby on Railsを一通り勉強して自分で何か作ってみたいけど何作ればいいか分からないという声をよく聞いていたので、Twitterでアンケートを取ってみました。

(脱線しますが、Twitterのアンケートは気軽にユーザーの声が聞けて有益なので仮説検証によく使っています)

 有料でも欲しいという方が33名もいたので作ることに決めました!

 

2-3. チュートリアルを作ってみて思ったこと

めちゃくちゃ勉強になりました。

自分で少し分かりにくいな、と思うところは極力一行一行コメントをしているのですが、その過程で「このコードはいるんだっけ?」「もっと綺麗に書けそうだな…」という気づきが多くあり、改めて考えて実装し直すことを繰り返し、かなり理解が深まりました。

また想定以上に読んでくださる方もおり(本当にありがとうございます!!)、とても嬉しいです。

 

3. まとめ

気軽に使ってもらえるサービスを作り、他の人に使ってもらえるととても嬉しいです。

技術チュートリアルを書くことはハードルが高いと感じるかもしれませんが、仮に読んでくださる方がいなかったとしても自分自身の勉強にもなるのでオススメします!

気軽に使ってもらえるサービスを作りたいけど、作るものがないなぁ、、という方は是非「BigTweetチュートリアル」で作ってみてください!^^

簡単に作れると思うので、BigTweetと全く同じでも構いませんし、多少アレンジしたりしてガンガンリリースしてみてください!

BigTweet系サービスがたくさん生まれたらめっちゃ嬉しいです。

(僕も明日くらいに一つ作る予定です)

 BigTweetチュートリアルはこちらです↓

note.mu

 

チュートリアルはいいかなー、という方も簡単に画像作成がお試しできるので、BigTweetを使ってみていただけると嬉しいです!

BigTweetはこちらです↓

bigtweet.herokuapp.com

お読みいただきありがとうございました!

未経験からプログラミングスクール/DIVE INTO CODEに実際に6ヶ月通って出来るようになったことと感想

1. はじめに

2017/11から通っているプログラミングスクール/DIVE INTO CODEをこの4月で卒業します!やったー!(通えば全員が卒業出来る訳ではないのです)

(プログラミング全くの未経験から入りました)

f:id:ysk_pro:20180421174743j:plain

 

思い返せば、11月はまだ銀行で働いていて退職交渉が難航していた頃だなぁ、、、

(11月はDIVE INTO CODEの初回の授業を休んで、グアムで結婚式・パラオに新婚旅行に行ったなぁ、、)

気づけばあれから6ヶ月経って銀行も無事卒業し、現在プログラマーとしてなんとか働けています。

 

11月以降、仕事以外の時間はずっとプログラミングに熱中しており、時間が経つのはめちゃくちゃ早かったと感じています。

きっとこれからもそんな状況が続くと思っており、DIVE INTO CODEを卒業出来ることが決まったこのタイミングで今の自分の状況を忘れないようにブログに記しておこうと思いました。

 

DIVE INTO CODEにしか通ったことがなく他のスクールとの比較はできませんが、未経験から6ヶ月通って卒業出来ることに決まった今「出来るようになったこと」「得たもの」「DIVE INTO CODEに関して思うこと」を本音ベースで書くので、

・プログラミングスクールを検討中の方

・これからプログラミングを勉強される予定の方

・勉強し始めて日の浅い方

の参考になれば嬉しいです。

 

2. DIVE INTO CODEとは

プログラミングスクールです!!

簡単に説明すると、

・期間は6ヶ月

・渋谷に教室があり、講義は10回(オンラインコースもあります)

・言語は主にRubyを学びます。(html、cssJavascriptも学びます)

・オリジナルのテキストベースで学び、質問はオンライン・オフライン(自習室)で随時可能

・自習室はとても綺麗で、メンター(教えてくれる方)常駐

・DEMODAYという受講生のオリジナルアプリケーションの大きめの発表会がある(任意参加、後述)

 

詳細はこちらの公式HPをご覧ください。

DIVE INTO CODE 公式HP

 

3. どれくらい勉強したか

どれくらい勉強したかをざっくりと振り返ってみます。

<2017/11〜12>

銀行の仕事が忙しく平日は時間が取れなかったが土日はほぼフルで勉強(1週間は結婚式・新婚旅行)

→ 7週間 × 土日2日 × 8時間(h)/日 = 112h

<2018/1>

有給が1ヶ月取れたので自宅 or DIVE INTO CODEの自習室にこもって勉強

→ 30日 × 7h/日 = 210h

<2018/2〜2018/3>

新しい職場は大体18時には終わるので、仕事終わりにも2時間程度勉強時間を確保

→ 8週間 × ( (平日 5日 × 2h/日) + (土日2日 × 8h/日) ) = 208h

合計すると、2018/3までで 530時間/5ヶ月 程度の勉強時間を確保してなんとか卒業できました。

 

妻も一緒にDIVE INTO CODEに通っていたので土日もフルで勉強できました。

(最高です)

 

4. 出来るようになったこと

4-1. Ruby on Railsでの簡単なwebアプリケーションの作成

webアプリケーションが自分1人で作れるようになりました!!!

DIVE INTO CODEのカリキュラムの中で、TwitterクローンTwitterみたいなアプリケーション)、インスタグラムクローンオリジナルアプリケーション3つアプリケーションを一から作成するので(作成しないと卒業できません!)、基本的な操作は楽しく作成しながら身につきました。

 

僕が作成したオリジナルアプリケーションがこちらです!!!!!

www.jobmiru.com

一般的なサイトと比較するとやはりもの足りなさはあるものの、なんとか形になっていると思います(そう信じています)。

 

作成する過程で思ったことなどはこちらの記事に記載しています。

ysk-pro.hatenablog.com

 

自分1人で サービスが作れてしまうってすごくないですか!!

イデアさえあれば、自分1人で第2のfacebookを作るのだって夢ではないのですよ!!

ワクワクしませんか!!

(と思って最近はもっぱら新しいサービスのことを考え続けてます。めっちゃ楽しい、、!)

 

5. 得たもの

まとめるとこちらです。

 

5-1. オリジナルwebアプリケーション

エンジニアの就職活動転職活動では自分で書いたコード、自分で作ったアプリケーションを見せることが多いです。

(それが一番実力が伝わります)

その際に使うことができます!!!

代表の野呂さんがコードレビューをみっちりしてくれるため、自信を持って提出することができます。

 

5-2. エンジニア仲間

授業料は安くないので、本気でエンジニアになりたい方が集まります。

未経験からエンジニア目指している方が多く、自分と状況が似ており励ましながら学習をしていくことができました。

信頼できるエンジニア仲間ができました。

 

5-3. 自分で学習していくためのベースの知識

正直、6ヶ月間必死に勉強しましたが、実務で通用するレベルにはまだ遠いと感じています。

しかし、集中して基礎の知識を身につけることができたので、何をしていいか分からなかった未経験の状態からは脱却でき、ここからは自分で学習をしていけるようになったと思います。

 

6. DIVE INTO CODEに関して思うこと

6-1. テキストがめちゃ良い

丁寧で分かりやすく、学ぶべきことが網羅されていてとても勉強しやすかったです。

(後からあれなんだっけ?と調べるときに、テキストに載っていないことがほぼなかったと思う、、、)

更に、応用的な内容が随時追加されていき、卒業すればずっと見ることができる、というのも嬉しいです。

テキストがどんどん追加されているので、卒業しましたがまだ学習できていない部分もあります(汗)

 

6-2. 質問対応が早い

オンライン、オフライン(自習室)ともに可能です。

オンラインでは質問投稿して30分くらいで大体リアクションがいただけるイメージで、とてもありがたかったです。

普段の小さな質問はオンラインでの質問で解決して、オンラインで質問するのはしんどいな、という大きな(?)質問は授業の日に自習室でガッツリ質問していました。

 

6-3. DEMODAYは絶対に登壇すべき

DEMODAYとは、スクール受講生が起業家、CTO、一般の方々の前で自分の作ったwebサービスをプレゼンし、その場で実際に使ってもらうイベントです。

僕が参加した4/1の第4回には80人の方が来場し、渋谷ヒカリエで開催されました。

これはめちゃくちゃいい経験になり、必死にオリジナルサービスを作り込むモチベーションにもなったし、一緒に登壇する人と苦労を共にすることでとても仲良くなることが出来たので絶対に参加すべきだと思っています。

DEMODAY当日に勢いで書いた記事がこちらです。

ysk-pro.hatenablog.com

 

6-4. 最低土日はフルコミットする覚悟・時間の余裕がなければ厳しい

僕は1月が丸々有給でガッツリ勉強出来たのでなんとか卒業出来ましたが、全くの未経験からだと最低土日はフルコミットしなければ卒業は厳しいと感じました。

2017/11入校組のクラスで毎回授業を受けていくのですが、途中から徐々に人数が減っていきました、、、

 

7. 良くなかったこと

いいことばかり書いているとフェアじゃないと思ったので良くなかったことも書きます。

7-1. 駅から遠い

すみません。これくらいしか思いつかなかったです、、、笑

渋谷駅から10分くらいは歩くのでもうちょっと近かったら嬉しかったなーと思います。

 

8. 僕のクラスの方々の転職実績(2018/6/10追記)

クラスの転職を目指していた方々の転職活動がひと段落したので実績を簡単に紹介します。

僕含めクラスの卒業生の半分以上がRuby on Railsを使う企業への転職を目指していたのですが、なんと、、、転職を目指していた全員がRuby on Rails自社開発の企業への転職が決まりました!!!!

皆さん優秀だったので順当な結果だと思いますが、とっても嬉しいです。(もうすぐ開かれる飲み会が楽しみ 笑)

Ruby on Railsのエンジニアの界隈はそう大きくない世界なので、その中に共に切磋琢磨してきた仲間がいるのはとても心強く、いずれ来るであろう一緒に働ける機会が楽しみという気持ちです。。

僕の転職活動についてnoteにまとめましたので、よろしければ参考にしてみてください。

note.mu

 

9. もし自分が今からプログラミングを学び始めるとしたらどうするか

DIVE INTO CODEに通うと思いますが、最近Twitter「ポテパンキャンプ」というスクールがすごいというのをやたらと目にし評判が良いので、DIVE INTO CODEと、ポテパンキャンプの無料説明会に参加してみて良かった方に通うかなーと思います。

スクールは独学に比べて高いですが、独学でプログラミングの面白さに気づけないまま挫折してしまったり、勉強の道筋が立てられずにやたら時間がかかってしまうリスクを減らすことができ、エンジニア仲間も出来るので通った方がいいのかなーと個人的には思っています。

(僕はスクールに通って本当に良かったと思っています)

 

どちらのスクールも下記の公式ページからオンラインで無料説明会(ポテパンキャンプだと無料カウンセリング)を予約できるので、迷っている方は一度こちらに参加されてみることをおすすめします!

DIVE INTO CODE 公式HP

ポテパンキャンプ 公式HP

是非一緒に頑張りましょう!!!

質問等あればTwitter DM、もしくこちらのコメント欄にいただければお答えしますのでお気軽にどうぞ!

ユーザー投稿型webサービス(口コミサイト)の投稿インセンティブ研究

ユーザー投稿型のサービスを作った際に一番の課題になるであろう「投稿のインセンティブ」について、頭の中の整理、今後の戦略検討を含めてまとめてみました。

目的

個人開発サービス「Jobmiru」の口コミ投稿インセンティブを強化するためです。

まず、『Jobmiru』とは、「何のスキルが身につくのか」「具体的に何をするのか」に特化した、転職口コミサイトです。

サービス詳細についてはこちらのサービス紹介記事をご覧ください。

ysk-pro.hatenablog.com

2週間前にリリースして現在口コミの投稿数は24件という状況です。

現在の最大の課題は「口コミ投稿のインセンティブ」であり、先週行われたDEMODAY(通っているプログラミングスクール主催のオリジナルwebアプリ発表会)のフィードバックにおいても、改善点として投稿のインセンティブをあげる方が一番多かったです。

フィードバック集計結果(全53件)

f:id:ysk_pro:20180408214908p:plain

また、DEMODAYについてはこちらの記事をご覧ください。

ysk-pro.hatenablog.com

「身につくスキル」や「具体的な仕事内容」というのは自分や知り合いがしている仕事以外ではなかなか知ることができないことであり、それを見ることができるこのサービスは投稿が集まれば絶対面白いサービスになると信じています!

いくつか、サービスとして回っている口コミサイトの投稿インセンティブについて素人なりに研究して、Jobmiruに応用できることはないか考えてみます。

Jobmiruの現状の投稿インセンティブ

サービスに共感していただいた方に面白いなーと思って投稿していただいています!

弱い!!!

転職会議

まずは、Jobmiruと同じ「転職」の領域から転職会議を選びました。

【転職会議】企業の評判から求人までわかる転職クチコミサイト

投稿のインセンティブ

自分の投稿をしないと他人の投稿が見れない仕組みであり、他人の投稿を見たい、というのが投稿のインセンティブとなっています。

メリット

価値のある投稿を抱えていれば、その投稿を見るために投稿が多く集まりやすいです。

デメリット

投稿の質が落ちる可能性があります。最低文字数の設定はあるものの、投稿をすれば何でも良いので、極論を言えば他人の投稿を見るために適当に投稿をしているケースもあるみたいです。

Jobmiruに応用できそうな点

投稿が集まってくれば同じ手法が使える可能性があるものの、現段階では投稿数が少なくコンテンツの魅力が弱いため、使うのは難しそうです。

Retty

次は参考になる記事が見つかったのでグルメサービスのRettyを選びました。

Rettyの口コミ投稿数が220%増! 成功の裏にはユーザーとの対話を重視するUXデザインチームがあった | インタビュー | Web担当者Forum

Rettyグルメ[レッティ]

投稿のインセンティブ

投稿をすると他の人からリアクションがあることです。

Rettyにおいて、投稿してくれるユーザーさんを「Rettyを一番楽しんでくれているユーザーさん」と定義しています。投稿してもらうと、他のユーザーさんからいいねが付いたり、共感してくれる人がたくさんいたりするので、「楽しいやうれしい」といった感情が起こりやすい設計にしています。

また、サービスのなかでユーザーさん同士のコミュニケーションが取りやすい設計をしています。たとえば、いいねの他に、行きたいといったボタンがあります。

(上記リンクより)

メリット

楽しんで投稿をしてくれるので、良質な投稿が増えやすいです。

デメリット

多くの閲覧者が存在しないとリアクションが付かず機能しません。

Jobmiruに応用できそうな点

この形が理想です。

現状、いいね!と働いてみたい!ボタンが設置してあるだけですが、今後実装予定の機能として、Twitterカード(Twitterに投稿した時に表示される画像)に投稿画面のグラフを面白い感じに加工して表示させる機能、投稿者に相談できる機能を考えており、どちらも見た人からのリアクションをもらう方法を増やすことができます。

マンションノート

マンションの購入等を検討したことがない方には馴染みがないかもしれませんが、マンションの口コミサイトです。(私も知りませんでしたが自分の住んでいる賃貸マンションを調べると何件も口コミがあり面白かったです)

日本最大級のマンション口コミサイト【マンションノート】

投稿のインセンティブ

自分の投稿1文字につき1ポイント獲得し、100ポイントで1物件の口コミを全て見れる仕組みなので、他人の投稿を見たいというのがインセンティブとなっており、転職会議と同じ仕組みです。

メリット以下は転職会議と同様です。

4travel

旅行の口コミサイトです。(こちらのサイトも知りませんでした)

かなり古いですが参考になる記事がありました。

“稼げる”口コミサイトの作り方 「4travel」に聞く - ITmedia NEWS

旅行のクチコミとホテル・ツアー・航空券の料金比較【フォートラベル】

投稿のインセンティブ

自分の旅行記録、ライフログを残せることです。

コンテンツを数多く集めるために、ユーザーに「発信したい」と思ってもらえる仕組みも必要だ。ただ旅行記を書いてくださいと“丸投げ”するのではなく、投稿フォームを工夫したり、旅行記を書いた地域を塗りつぶせる「渡航地図」を提供するなど、発信の意欲を高める仕組みも用意した。

 (上記リンクより)

メリット

楽しんで投稿するので、良質な口コミが増えやすいです。

デメリット

投稿をしてもらえるような機能を工夫する必要があります。

Jobmiruに応用できそうな点

Jobmiruが投稿者の職務経験のポートフォリオになる、というのも面白いと思いました。

また、発信したいと思ってもらえる仕組み作りはこちらのサービスも参考に今後更に工夫、強化していきます。

まとめ

口コミサイトの投稿のインセンティブとしては、

① 他人の投稿を見たい!型(転職会議、マンションノート)

② 他人からのリアクションがもらえるかも!型(Retty)

ライフログを残せる!型(4travel)

に大きく分類できると思います。

Jobmiruでは、まずは②に注力し、ユーザーが増えてきた段階で①と③も組み合わせていきたいと考えています!

頑張ってTwitterカード、相談機能を実装します!

素人が自分のサービスのためにまとめてみたものなので、認識が間違っている箇所や考察が浅い箇所も多々あると思うのでご指摘、ご意見いただければ嬉しいです。

最後に

まだ投稿のインセンティブが弱いですが、、、Jobmiruが少しでも面白い、もしくは面白くなるかも、と思われた方は口コミ投稿を是非お願いします!

www.jobmiru.com

オリジナルwebサービスを発表するDIVE INTO CODEのイベント、DEMODAYで登壇してきました!

本日、個人で開発した「Jobmiru」をDEMODAYで発表してきました!

開発したJobmiruについてはこちらの記事で紹介しています。

ysk-pro.hatenablog.com

 80人の前で自分の開発したサービスを発表する機会なんて滅多にないと思うので全力で楽しんできました。

DEMODAYとは?

DEMODAYとは、私が通っているプログラミングスクール「DIVE INTO CODE」が主催する、スクール受講生が起業家、CTO、一般の方々の前で自分の作ったwebサービスをプレゼンし、その場で実際に使ってもらうイベントです。

80人の方が来場し、渋谷ヒカリエのレバテックのおしゃれなオフィスで開催されました。

diveintocode.doorkeeper.jp

会場の雰囲気はこんな感じでした。(開始直前の様子です)

f:id:ysk_pro:20180401220431j:plain


発表内容

本番で使用したプレゼン資料です。

プレゼンで意識したのは、
① ゆっくり話すこと
② 抑揚をつけること
③ 堂々とすること
④ 話しながらフラフラしないこと
⑤ 全文暗記すること
で、練習も十分していたので、なんとか納得のいくプレゼンが出来ました!

カメラマンも何人かいらっしゃったので、後日DIVE INTO CODEのHPとかに載るかもしれません、、、!


発表内容については冒頭でも触れたサービス紹介記事の中で説明している内容と同様です。

プログラミングを学び始めて4ヶ月、初めてのwebサービスリリース!!サービス紹介とサービスを作ってみて思ったこと - 銀行員からプログラマーへの転職記

今回のDEMODAYから、プレゼンだけではなく、ユーザーにその場でサービスを使ってもらう時間もつくられ、80人の方からたっぷりフィードバックをいただくことができました。

結果

最優秀賞と審査員4名の審査員賞があるのですが、ジャクール株式会社取締役の神尾さんの審査員賞を受賞することができました!!!!

やったーーー!

f:id:ysk_pro:20180401221442j:plain

(名前の漢字は間違っているので本名ではありません 笑)

DEMODAYで登壇して良かったこと

いいことずくめでした!


フィードバックが一気にたくさんもらえた

80人にサービスについて丁寧に説明して、一斉に触ってもらえてフィードバックがもらえる機会なんてなかなかないと思います。

その場でもたくさんのフィードバックを頂きましたが、全員がGoogleフォームでフィードバックを送信しており、それを後日いただけるのでとても楽しみです。

 

開発のモチベーションアップ

「このサービス好き!」や「Jobmiruが一番好きで、就職の時に欲しかった」との声を頂戴し、開発のモチベーションがめちゃめちゃ上がりました。

 

DEMODAYに登壇すために開発を一気に進められた

DEMODAYに登壇する、と決まっていなかったらこんなに早く開発が進んでいなかったと思います。

DEMODAYという締め切りがあり、それまでに納得するサービスに仕上げよう、と思ったことで開発のスピードが一気に上がりました。


仲間が出来た

今回のDEMODAYでは私を含め5名が登壇したのですが、まだ全然サービスが形になっていないところから何度も打ち合わせで集まり、悩みを共有してきたことで、切磋琢磨しあえる仲間が出来ました。


DIVE INTO CODEはとても好きですが、ほんとにこのイベントのためにだけでも受講することをおすすめできます。

今後のこと

新しいサービスの構想もあり、新しいサービス作りたいなー、という気持ちがあったのですが、今日発表してポジティブな意見がたくさん聞けたことで、これはもしかして頑張ればいけるのかも、、、と思っちゃっているので、機能改善、新機能実装頑張ってみます。

実装したい機能もたくさんあって、手が回りません、、DEMODAY前と変わらずこれからも全力で頑張ります!

 

宜しければ、僕が作ったサービス見てみてください!

身につくスキルに特化した転職口コミサイトを作りました。

www.jobmiru.com

みなさんのご経験をサービス内で投稿をしていただけるととても嬉しいです!!

プログラミングを学び始めて4ヶ月、初めてのwebサービスリリース!!サービス紹介とサービスを作ってみて思ったこと

2017/11からRuby on Railsの学習を始めて、初めてのwebサービスが出来ました!(作成期間は2ヶ月くらいです)

全力で作り、満足するものが出来たので、サービスの紹介とサービスを作ってみて思ったことなどを書いてみます。

同じようにサービス作りをしている方の参考になれば嬉しいです。

共感していただけたら是非サービスを使ってみて下さい!!!

 

 

1. 作ったサービスについて

1-1 概要

『Jobmiru』という、「何のスキルが身につくのか」「具体的に何をするのか」に特化した、転職口コミサイトを作りました。

f:id:ysk_pro:20180324224238p:plain

www.jobmiru.com

サービスの一番のターゲットは、スキルを身につけることを重視して就職先、転職先を探している人です。

様々な仕事でその人が身についたスキル、具体的な仕事内容といった普段なかなか知ることが出来ないことを知れるので、転職を考えていない人でも楽しめるサービスになりました。

1-2 このサービスを作った背景

私自身の就職・転職活動時に、「スキルを身につけたい」という会社を選ぶ軸があったものの、それぞれの会社で働くことによって得られるスキルについて分からず、その情報についても集めることができなかった、という原体験がありました。

同じように感じている人はいるのか、Twitterでアンケートを取ってみた結果がこちらです。

→半分の方がスキルを最重要視している!

→有益な情報が得られなかった人は多い!

この結果より、私と同じように会社を選ぶ際にスキルが身につくことを重視していたものの、その情報を得ることが出来ない人が多くいることがわかりました。

この課題を解決したい!!という思いからこのサービスを作り始めました。

1-3 ミッション

誰もが「出来るようになること」で会社を選べる社会にすること

それによって就業のミスマッチを極少化させること

1-4 機能

実際に働いたことがある人が口コミを投稿できるシンプルなものです。

身についたスキル、具体的な仕事内容をビジュアル化し、一目で分かりやすいように工夫しました。

「スキル」に関してはコミュニケーション力、営業力といった曖昧なものではなく、極力具体的なものを書いてもらう形にしています。

f:id:ysk_pro:20180325225159p:plain

f:id:ysk_pro:20180324221414p:plain

(投稿のグラフ部分の抜粋です)

投稿へのいいね!、コメント、投稿のランキング等、投稿サイトにある一般的な機能は実装しています。

1-5 既存のサービスとの違い

類似(競合)サービスとして想定しているのは、転職会議等の転職口コミサイト、転職エージェント、Wantedlyです。

下図のように、スキルについての情報の濃さと、投稿者の属性の2軸でマッピングすると、「スキルについての情報に特化+実際に働いた人が投稿」というのは他のサービスと被っておらず、独自の立ち位置が確保出来ていると考えています。

f:id:ysk_pro:20180324222247p:plain

1-6 ビジネスモデル・今後の展開

社会の課題を解決するには、持続性のあるサービスになる必要があり(すぐ無くなってしまったら解決できない)、そのためにはマネタイズの仕組みが必須です。

しかしながら、すぐにマネタイズするのは難しいと思っています。

Phase1〜3に分けました。 

f:id:ysk_pro:20180324223357p:plain

Phase1として利用者の拡大を頑張ります。

利用は全て無料でマネタイズはまだ行いません。

利用者が増加したところで、Phase2として投稿に関連する求人の広告を掲載し求人媒体へ送客しその送客フィーを得るのが一番現実的であると考えています。

更に、投稿者に有料で相談出来る機能を実装し、マッチングフィーを発生させることを考えています。(社会人のオンラインOB訪問サービスのイメージです。)

そしてPhase3として、企業が投稿者をスカウト出来る機能、国家資格のキャリアコンサルタントへの有料相談機能を考えています。

なんとか3ヶ月くらいでマネタイズし始めたい、、、!

1-7 課題

お察しの通り、投稿のインセンティブ設計がとても難しいです。

現状はTwitter、ブログを通じて多くの人に見てもらい、共感をいただいた方、キャリアに悩む人のためになりたい方(、個別に依頼させていただいた方)に投稿をいただくしかないかな、と思っております。

投稿内容は極力シンプルにしておりますので、是非、、投稿をお願いいたします!

投稿内容のサマリーをTwitterに画像付きで投稿できる機能(診断メーカーのイメージ)は早急に実装しようと思っております。

その他にも、投稿のリクエスト機能、1-6にも書いた相談機能、スカウト機能など投稿インセンティブになる機能は随時検討・追加していく予定です。

 2. サービスを作ってみて思ったこと

 2-1 サービスを作るのはめちゃくちゃ楽しい

本当にめちゃくちゃ楽しいです。1月から作り始めて2ヶ月かかりましたが、平日は仕事から帰ってきてから約2時間、土日はほとんど終日没頭してました。

自分が感じている課題をどうやったら解決できるのかを考えること、新しい機能の実装の仕方を考えること、デザインを工夫すること、全てが楽しかったです。

社会の課題を解決出来るものを1人であっても作り出すことが出来るプログラマーってやっぱりすごいです。

2-2 フィードバックをもらうのもめちゃ楽しい・勉強になる

後述しますが、Twitterを通じて多くの人にフィードバックをもらうことができました。

自分では全く気づかなかった部分に気づくことができてとても面白く、褒めて下さる方も多くモチベーションがかなり上がりました。(承認欲求がよく理解できました 笑)

いただいたフィードバックは全てGithubのissueに登録して一つずつ改善させていただきました。

2-3 Twitterの無限の可能性

妻(プログラマーです)が始めたのと同時に、1月末に軽い気持ちで始めてみました。

いいことずくめでびっくりしました。

なんと作成中のこのサービスのフィードバック、コードレビューに17人の方が快く協力してくれました。衝撃的でした!!!

更にwebサービス運営者のslackに参加することができ、多くの知見を得ることができました。来週飲み会が開催される予定でそれも楽しみ。

Twitterすごい!!!

Twitterを通じて仕事を探したり、求人募集している方もおられ、本当に無限の可能性があると感じました。

3. DEMODAY

4/1(日)に通っているプログラミングスクール「DIVE INTO CODE」主催のDEMODAYに登壇します!!

DIVE INTO CODEの受講生が起業家、CTO、一般の方々の前で自分の作ったwebサービスをプレゼンし、実際に使ってもらうイベントです。

70人以上(!)来場予定と聞いており、誰でも参加可能なのでご興味ある方は参加ご検討ください。

diveintocode.doorkeeper.jp

当日使用予定のプレゼン資料です。(ほとんどサービス紹介の図と重複しています)

70人以上の前で話すことなど滅多にないので緊張していますが、70人以上に自分の作ったサービスを同時に紹介できる機会も滅多にないのでとてもワクワクしています!

4. 今後について

Jobmiruの新機能実装、既存コードのリファクタリング、利用者拡大のためのマーケティング、新しいアプリの開発(10個くらいアイデアメモためてます)、Reactの学習などなどやりたいことずくめですが、やりたいこと全部やってみようと思います!
 
もしサービスにご興味を持っていただけたら使ってみてくださるととても、とても嬉しいです!
また皆さまのご経験を投稿をいただけるともっと嬉しいです!!!
フィードバックも大募集しています。

www.jobmiru.com

5. 追記

5-1 Qiitaにも投稿してみました

より多くの方に知ってもらうためにやれることは色々やってみようと思い、この記事に技術的な内容をプラスしてQiitaにも投稿してみました。

結果、トレンドランキングで一番上に掲載されるなど多くの方に見てもらうことができました!

Qiita記事はこちらです。

qiita.com

DEMODAY本番頑張ってきました!

ジャクール株式会社取締役の神尾さんの審査員賞を受賞することができました!

こちらはDEMODAY直後に勢いで書いた記事です。

ysk-pro.hatenablog.com

「localhost でリダイレクトが繰り返し行われました。」はルーティングのせいだった、Ruby on Rails エラーの分析

1. はじめに

謎のエラーに苦しめられました。
結論から言うと原因は「routes.rb」への記載の順番でした。(なにそれ?って感じですよね)


(失敗ナレッジの共有をして欲しいとのご要望をいただいたので書いてみます。ありがとうございます。)

※バージョンは、Ruby:2.3.0、Rails:5.1.4です。

2. 事実

本件に関係のある箇所を抜粋しています。

routes.rb

  resources :users, only: [:show]
  devise_for :users, controllers: { :omniauth_callbacks => "omniauth_callbacks", registrations: 'registrations'}

devise gemを利用してログイン機能を実装しています。
ユーザー詳細ページをつけるために、resources :users, only: [:show] で users#show のためのルーティングを設定しています。

users_controller.rb

  before_action :sign_in_required, only: [:show]
  def show
  # 以下略

application_controller.rb

  private
    def sign_in_required
      redirect_to new_user_session_url unless user_signed_in?
    end

発生したエラー

f:id:ysk_pro:20180219222407p:plain
(言われた通り大人しくCookieを消しましたが効果ありませんでした)

ログ

Started GET "/users/sign_in" for 127.0.0.1 at 2018-02-19 21:58:38 +0900
Processing by UsersController#show as HTML
  Parameters: {"id"=>"sign_in"}
Redirected to http://localhost:3000/users/sign_in
Filter chain halted as :sign_in_required rendered or redirected
Completed 302 Found in 1ms (ActiveRecord: 0.0ms)


Started GET "/users/sign_in" for 127.0.0.1 at 2018-02-19 21:58:38 +0900
Processing by UsersController#show as HTML
  Parameters: {"id"=>"sign_in"}
Redirected to http://localhost:3000/users/sign_in
Filter chain halted as :sign_in_required rendered or redirected
Completed 302 Found in 1ms (ActiveRecord: 0.0ms)

これの無限ループ

3. 解決法

routes.rb

  devise_for :users, controllers: { :omniauth_callbacks => "omniauth_callbacks", registrations: 'registrations'}
  resources :users, only: [:show]

順番を入れ替えただけで直りました。マジか、、

4. 分析

エラーしている状態のrails routesのログ

                           user GET      /users/:id(.:format)                   users#show
               new_user_session GET      /users/sign_in(.:format)               devise/sessions#new
                   user_session POST     /users/sign_in(.:format)               devise/sessions#create
           destroy_user_session DELETE   /users/sign_out(.:format)              devise/sessions#destroy
              new_user_password GET      /users/password/new(.:format)          devise/passwords#new
             edit_user_password GET      /users/password/edit(.:format)         devise/passwords#edit
                  user_password PATCH    /users/password(.:format)              devise/passwords#update
                                PUT      /users/password(.:format)              devise/passwords#update
                                POST     /users/password(.:format)              devise/passwords#create
       cancel_user_registration GET      /users/cancel(.:format)                registrations#cancel
          new_user_registration GET      /users/sign_up(.:format)               registrations#new
         edit_user_registration GET      /users/edit(.:format)                  registrations#edit
              user_registration PATCH    /users(.:format)                       registrations#update
                                PUT      /users(.:format)                       registrations#update
                                DELETE   /users(.:format)                       registrations#destroy
                                POST     /users(.:format)                       registrations#create
user_twitter_omniauth_authorize GET|POST /users/auth/twitter(.:format)          omniauth_callbacks#passthru
 user_twitter_omniauth_callback GET|POST /users/auth/twitter/callback(.:format) omniauth_callbacks#twitter
          new_user_confirmation GET      /users/confirmation/new(.:format)      devise/confirmations#new
              user_confirmation GET      /users/confirmation(.:format)          devise/confirmations#show
                                POST     /users/confirmation(.:format)          devise/confirmations#create

エラー解決した状態のrails routesのログ

                         Prefix Verb     URI Pattern                            Controller#Action
               new_user_session GET      /users/sign_in(.:format)               devise/sessions#new
                   user_session POST     /users/sign_in(.:format)               devise/sessions#create
           destroy_user_session DELETE   /users/sign_out(.:format)              devise/sessions#destroy
              new_user_password GET      /users/password/new(.:format)          devise/passwords#new
             edit_user_password GET      /users/password/edit(.:format)         devise/passwords#edit
                  user_password PATCH    /users/password(.:format)              devise/passwords#update
                                PUT      /users/password(.:format)              devise/passwords#update
                                POST     /users/password(.:format)              devise/passwords#create
       cancel_user_registration GET      /users/cancel(.:format)                registrations#cancel
          new_user_registration GET      /users/sign_up(.:format)               registrations#new
         edit_user_registration GET      /users/edit(.:format)                  registrations#edit
              user_registration PATCH    /users(.:format)                       registrations#update
                                PUT      /users(.:format)                       registrations#update
                                DELETE   /users(.:format)                       registrations#destroy
                                POST     /users(.:format)                       registrations#create
user_twitter_omniauth_authorize GET|POST /users/auth/twitter(.:format)          omniauth_callbacks#passthru
 user_twitter_omniauth_callback GET|POST /users/auth/twitter/callback(.:format) omniauth_callbacks#twitter
          new_user_confirmation GET      /users/confirmation/new(.:format)      devise/confirmations#new
              user_confirmation GET      /users/confirmation(.:format)          devise/confirmations#show
                                POST     /users/confirmation(.:format)          devise/confirmations#create
                           user GET      /users/:id(.:format)                   users#show

当然、

user GET      /users/:id(.:format)     users#show

の行の場所が変わるだけです。

ログをよく見てみると、

Started GET "/users/sign_in" for 127.0.0.1 at 2018-02-19 21:58:38 +0900
Processing by UsersController#show as HTML
  Parameters: {"id"=>"sign_in"}
Redirected to http://localhost:3000/users/sign_in

GET "/users/sign_in" にアクセスしようとしてるけど、GET "/users/:id" に "id" = "sign_in" としてアクセスしちゃってる・・・
そして、 users#show はログインしていないとログインページに強制リダイレクトする設定になっているので、 GET "/users/sign_in" にアクセスして以下、無限ループです。


更に、routes.rbの記載の順番によって、エラー発生の有無が決まるのは、

Railsのルーティングは、ルーティングファイルの「上からの記載順に」マッチします。

のためでした。
Rails のルーティング | Rails ガイド


つまり、解決した時には、GET "/users/sign_in" にアクセスしようとした時に、GET "/users/:id" が一番上になかったために引っかからず、正しいルーティングを選択できたからでした。


ルーティングも奥が深いですね。
まだ知らないことばっかりで楽しいな〜(エラー最中はイライラが止まらないけど、解決して分析してスッキリするの好き)

ご指摘・ご感想等いただけますと大変嬉しいです!