はじめに
タイトルはプログラミングスクールさんに、面倒ごとを増やしたらごめんなさいという謝罪の意図です。
未経験からDWCというプログラミングスクールを卒業してWebエンジニアになりましたyukiです。
もう4ヶ月が経ちました。支えてくださった皆様のおかげで、楽しい日々を送っています。
今回は、未経験転職の際におそらく作るポートフォリオに関しての記事です。
ただ、はじめに声を大にして伝えたいことを次に記します。
記事の対象者
この記事の対象者は、プログラミングスクール（以下PGS）に通っており、
- PGSの課題が入学前に終わってるレベル
- 完全に理解して人に説明できるレベル
- 余裕があって何やっていいか分からないレベル
の人向けです。
また、こんな記事を書いておいてなんですが、マインドの部分で言うと
- フロントとバックを分けた開発に挑戦したい理由が明確
- 最悪、自分一人で調べて周りの人に迷惑をかけない覚悟がある
- さらに間に合わなかった場合のリスク回避策を持っている
方向けです。
なぜそれを実装すると良いのか分からないまま挑戦すると失敗しますし、きっと受ける企業からも「あんまわかってないな」と思われるはずです。
ここまで読んだ上で、もし自分が対象者だ！と思う方はお進みください。
※ 初学者向けに表現を崩している部分があるため、厳密に見るとグレーな部分もあるかと思います。その際は、こういう考えもあるよとご指摘ください。
最後に、自分が挑戦したから天狗になって「みんなもやろうね！」的な記事ではありません。こういうポートフォリオ作る人もいるんだな〜やってみようかなぁ程度の参考になれば幸いです。
フロントとバックを分けるとは？
１つのフレームワークでWebアプリケーションを開発することは、できます。
例えば、PGSでよく利用されるRailsでは、Controller側で定義したActionに対し、viewファイルという画面を構成するファイルが対応して存在します。基本的にはRailsだけあれば、Webアプリケーションのポートフォリオを作ることはできるのです。
ただここで、冒頭のフロントとバックを分ける開発という概念を考えてみたいと思います。
フロントエンドとバックエンドで違うフレームワークを用いる
入社してからも実感したのですが、実務ではWebアプリケーションの設計においてフロントエンド（人の見る部分）とバックエンド（処理を書く部分）に、それぞれ違うフレームワークを使っている場合があります。
イメージがつきやすいと思うので、今回はそのように開発することを「フロントとバックを分ける」というコトバの定義とします。
２つのフレームワークを使うと（皮肉ではなく）Railsのみで開発をしている人にはちょっと想像が難しいと思いますが、Railsの業務をコントローラーとモデルの処理のみに絞らせて、フロントのフレームワークには画面の書き換えのみに専念してもらうことができるのです。
※ メリットに関しては、ここでは言及しませんので各自調べてみてください。
具体的な説明：バックの役割
具体的には、Railsなどバックエンドを担当するフレームワークにはAPIとして動いてもらいます。今回開発する想定のAPIは、フロント側のリクエストが来た際に値を返すだけのものになります。
調べる際は、こちらの記事がとても参考になったので、ご覧ください。
通常ならコントローラーのアクションでは最後にredirect_toなどで画面遷移をさせますが、こちらの記事を見るとjsonというデータを最後に返して処理を終えています。
フロント側では、こちらのjsonを受け取って、それで画面を書き換えます。
具体的な説明：フロントの役割
受け取ったjsonで画面の書き換えをしようとすると、非同期で素早く書き換えるなんてことも、簡単にできるようになります。
フロント側を作成するフレームワークとしては、Vue.jsやNuxt.js、React.jsやAngularなどが挙げられるのではないでしょうか。フロントとバックを分けたポートフォリオ作成に挑戦するにあたり、これらを勉強するのはいいことだと思います。
いろいろな成長につながるため、ぜひ挑戦してみてください！
以上です。以下、個人の見解なので読まなくていただいても大丈夫です。
挑戦した方がいいと思った理由
私がフロントエンドとバックエンドを分けたポートフォリオに挑戦すると良いと思った理由は、２つあります。
一つは、転職市場の戦略としてきっと有効だから
大前提として、他の転職希望者と差別化するためにフロントのフレームワークに挑戦することは、私はあまり好ましく思っていません。なぜなら、目的を間違っているような気がするからです。
冒頭で「フロントとバックを分けた開発に挑戦したい理由が明確」の人が本記事の対象と述べましたが、何でフロントとバックを分けたのか？という問いに対する回答が「就活のため」であっては欲しくないのです。
具体的に述べますと、プログラミングは何か解決したい課題があって、技術の選定はそれに対して最適なものを選ぶ（もしくは、社内のナレッジを蓄積するためにor知見を広げるために挑戦してみる）ものだと思っています。フロントバックを分ける必要がないなら、無理して分けなくてもいいと思います。
それに対し、ただ漠然とした理由でやってみたいから、転職活動に有利そうだからという理由で挑戦すると、エンジニアを目指す上で大切なその根本の概念を否定しているように思えてしまうのです。
とは言え、昨今の転職市場を見るにコロナウイルスの影響などで非常に厳しい風が吹いているように思えます。そんな中で、「なぜやりたいのか」が明確になっている人には、ぜひアピールポイントを増やすという意味で挑戦していただけたら、会社選びの際に、より良い結果を生むのではないかなと思い、この記事を書きました。
実務にスムーズに合流する手段としてきっと有効だから
私の例になってしまいますが、実務に入って自分でAPIを作成し、フロントとバックを分けて開発するという業務に取り組んでおります。PGSではGoogleのAPIを使うなど簡単な開発は学習しましたが、フロントエンドを別フレームワークで開発するところまで指導してくれるPGSは少ないのではないでしょうか。
たまたま私はポートフォリオでそのような開発経験があったため、応用して活かすことができました。ただ、これを経験しないまま実務に入って行ったら相当苦労しただろうなぁと思うわけです。
全ての会社がフロントバックを分けた開発をしているわけではもちろんないですが、一定量現在の流行だったり、今後目指すべき場所として「フロントバックを分けたい」という声も周囲で耳にします。
可能性があるならば、挑戦してみるのも良いかと思った次第です。もしかしたら、今分けていない会社でも、あなたがフロントバック分離のプロジェクトを担当できるかもしれません。
参考記事
頑張って作った過去のポートフォリオ
https://github.com/yuki-snow1823/DTODO
何かあればDMまでどうぞ！