概要
2021年1月からWebフロントエンジニアを目指して学習を始めて、2022年4月に企業への内定が取れたので、やったことや就活に対する考え方をまとめました。
Web開発が未経験なだけで、前職ではWindowsのネイティブアプリケーション（C#.NET）での開発経験はあります。
ただ、おそらく未経験者のスタートラインである、HTMLやCSSを覚えるところから始まったのは確かです。
この記事は、めちゃくちゃ主観ですので参考程度にしてください。
目標
2021年は雌伏の期間として力を付けて、2022年から就活を始める。
これを目標（というか制限時間）にしました。
「1月は何を学んで～、2月は～」みたいに細かい計画は立てなかったです。どうせ破綻するし焦るだけなので。
モチベーション
Web開発を始めたきっかけは、主に以下の3つの要因です。
- 多彩な表現力
- 公開のしやすさ
- JavaScriptの汎用性
とくに、.NET環境ではできないような様々な表現を身につけることをモチベーション（軸）として学習を始めました。
この時点で、フロントエンド開発に焦点を絞りました。
公開のしやすさについては、
例えばWindowsネイティブアプリケーションの場合、Windowsのデスクトップ上でしか動作しないですし、ユーザーが使うにもStoreを通すかインストーラーをダウンロードしてインストールする必要があります。
iPhoneアプリの場合は、AppleStoreへの申請が必要で、くそ面倒くさい審査を通す必要があります。
その点、Web開発ではサーバーにアップロードしさえすれば、あとはユーザーがそのサイトのリンクを踏むだけでプラットフォームに関係なく制作物を見る・利用することができます。アウトプットのしやすさ、範囲が段違いです！
汎用性については、
Electronを使えばHTML・CSS・Javascriptでデスクトッププリケーションが作れますし、Expoを使えばiPhone・Androidアプリを作ることもできます。
技術的なリサーチ（1～2月）
最初にHTML・CSS・JavaScriptを参考書を読みながら学習しましたが、くそつまらなかったです。
自分の知識がなさすぎるのもそうですが、参考書自体がテンプレートみたいなデザインしか扱っていないし、モジュール化できないHTMLや、型のないJavaScriptにもいちいちストレスを感じていました。（C#をずっと触っていたからってのもありますが、コード補完が効かないとかありえない）
「世のWebエンジニアたちはこんな環境で開発しているのか？いやそんなわけない」と思って調べました。
そうするとすぐに、TypeScriptに行きつきました。また、HTMLのモジュール化に関しては、フレームワークとしてReact・Vue・Angularが主流になっていることを知りました。
調べ方は、転職サイトのWebフロントエンド開発の募集要項を見るのが手っ取り早かったです。
3つあるフレームワークは、まずReactを学んで、合わなかったらVueやAngularを学ぼうと思っていました。
最初にReactを選んだ理由は、後述するUdemyに講座が豊富にあったことと、Githubのトレンドが一番高かったことです。（それだけコミュニティが活発で、わからないことはググればすぐに情報が出てくると踏んでの選択です）
学習の仕方（3～7月）
学ばなければいけないことがある程度わかりました。ただ、どうも私は参考書で学ぶのが苦手のようで、他にいい学び方ないかなーと探したところ、Udemyという動画形式の学習サイトを見つけました。
動画だと参考書とは違い、一から同じ手順でコーディングすることができますし、本で読むより聞く方が情報が入ってきやすく頭に残りやすいです。
動画は購入しているため、いつでも何回でも見返せます。
わからないところがあれば、直接講師の方に質問することもできます。
ここでTypeScriptであったり、Reactであったり、Firebaseなどの使い方も学びました。
いま思うと、この時が一番アンテナを張っていたと思います。
特に、表現系のライブラリについては結構調べたり使ったりしました。Material UIであったり、Three.js、Framer Motion、emotion/cssなどを実際に使ってみて「これを使うとこんなことができる」、似たライブラリがあれば「あれと比較して、これは使いやすいか使いにくいか」片っ端から試していました。
その中でも使いやすいものは、いまでも使っています。
それもあって、幅広く何かを調べていたのもこの時期が一番で、それらを忘れないためにも
学習したことは逐一Qiitaにまとめていました。
自分のためにもなりますし、就活でのアピールポイントにもなります。超重要だと思います。
ゴミみたいなポートフォリオ（8～9月）
TypeScript、React、Next.js、もちろんHTML、CSSも学んで、もう後は「自分で何か作るだけだ！」となってポートフォリオ作成しました。
結論からいうと、それらしいものはできましたが、ゴミのような出来でした。しかも無駄に時間もかかりました。
ただ、私はバイブルとして宇宙兄弟を何回も読んでいるので、ムッタ（主人公）の
ものづくりには失敗することに使う金と労力が必要なんだよ。
失敗を知って乗り越えたモノなら、それはいいモノだ。
という言葉を心のノートに刻んでいます。
このポートフォリオに足りなかったものは何か、他の優れたサイトと何が違うのか観察して、いくつか足りないものを見つけました。
この課題はかなりピンポイントで、人によっても違います。このような場合の学習には、YouTubeが役に立ちました。
特化（10月）
課題をこなしていく内に、なんとなくWebサイト君の気持ちがわかってきたので、2つ目のポートフォリオ作成しました。
1つ目のポートフォリオに足りなかったものもしっかり盛り込んで、いい出来になりました。
また、課題として、ひたすらCSSでstylingやtransition、animationを実装していたおかげで、この頃にはCSSで作られているものなら見ただけで大まかに構造がわかるようになりました。
ただ、2つ目のポートフォリオでも、世の本当にインパクトを受けるサイトに比べるとチープに感じました。失敗はなかったにせよ、根本的に使っている表現技術が足りていないと感じました。
いままで見たり触ってきたライブラリで、一番面白く表現の奥が深いモノはなんだろう？と考えた時に、Three.jsが上がりました。
ちなみにThree.jsは今でも学習していますが、まだまだ底が見えないです。恐ろしい子。
Three.jsの学習開始（10月～）
私がWeb開発でモチベーション（軸）にしていた多彩な表現力を最も叶えてくれるのが、おそらくThree.jsだと思います。
Three.jsの学習の仕方については、過去に記事を書いたのでそちらを参考にしてください。
就活（2022年 1月～）
Three.jsの表現力にどっぷりはまり、フロントエンド開発の中でもThree.js（WebGL）を使って仕事がしたいと思いました。
いくつか転職サイトを使って就活を始めました。が、要求がシビアすぎてなかなかいい会社が見つかりません。
偶然、見つけた企業も面接までいきお祈りされました。（せめて落とした理由くらいは教えてくれよ。I社）
方針転換（3月～）
その後も、転職サイトで探しましたがなかなか要求に合う会社がなかったり、お祈りされたりで、「あ、これ、時間の無駄だし楽しくない」と思いました。
そこで、方針転換することにしました。
Twitterのアカウント名に「求職中」の文字を入れて、プロフィールには、「クリエイティブコーディングを活かしたWebフロントエンド開発の求職中。ご興味を持って頂けた方はDMまで」みたいな文言と、ポートフォリオのリンクを貼りました。
そう、こっちから探すのではなく企業に見つけてもらう方針に変えました。
そっちの方がミスマッチが少ないし、何よりDMして頂いた企業は自分に興味を持ってくれているので、自分からアプローチするよりも企業からの期待度のスタートラインが各段に違います。そしてもちろん面談から始まります。
ただこの方法には、ひとつ必ずやらなければいけないことがあります。それは、
日常的にアウトプットすることです。
アウトプット
時代は、セルフプロデュース？
GitHub
Read Meを必ず書きましょう。内容は
- どんなことに挑戦したか（アプリケーションの特徴）
- アプリケーションのURL
- どんなアプリケーションかわかるように、gifや画像を貼る
- 使っている技術
- 参考にしたサイト・動画など
を書いています。
例えば、私の最近のリポジトリはこんな感じです。
あと、翻訳でもいいのでなるべく英語で書きましょう。
必ずタグを付けましょう。
私の場合、Three.jsでのアウトプットがほとんどなので、#threejs・#r3f（React Three Fiberの略）を付けています。
特にアプリケーションを作った場合は、アプリケーションとリポジトリのURL、そして動画を貼るようにしています。
例えば
また、リポジトリに登録するようなレベルに達していないちょっとした試作でも、どんどんタグを使ってツイートしましょう。
効果
アウトプットの効果ですが、やり続けていると結構な数の企業からアプローチがきます。
日本の企業からは、特にあることをしたらアプローチが増えました。
それは、サイトの一部でもいいので既存のサイトのクローンを作ることです。
そのサイトのクローンをTwitterでアウトプットするときに、元にしたサイトを制作した会社の企業アカウントを貼ります。そうすると、ありがたいことにツイートを拡散して頂けることがあります。制作会社のフォロワーは必然と他の制作会社のアカウントも多いはずなので、拡散効果はとても大きいです。（決してそのような目的があってリンクを貼っているわけではないですが）
会社がフロントエンドエンジニアに求める能力として、「デザイナーが起こしたデザインをどれだけ忠実に再現できるか」というものがあるみたいです。（私も面談をしているときにそれとなく知りました）
既存のサイトのクローンはまさに見て再現することであり、その人の実装能力の証明になります。
ただし、むやみやたらに企業アカウントのリンクを貼ると、ご迷惑にもなるのでそこは気を付けましょう。
あと、海外の個人や有名な代理店などからもアプローチがきます。
私の場合だと、VercelやSpline等からお話を頂きました。ただ、フロントエンド開発の経験がなさすぎるのと英語がまだまだ未熟なので辞退しました...😭
結局は...
プログラミングは、モノ作りです。
作ってそれをどんな形でもいいので世に出していれば、誰かが興味を持ってくれます。
この記事で紹介した就活の方法でのメリットは、
- アウトプットに集中できる
- よく耳にする「100社エントリーして～」みたいなことをする必要がない（私にとってはこれが一番無駄な労力）
- アプローチがきた企業と、自分がやりたいこととのミスマッチがほぼ起きないので、有意義な就活ができる
企業にとってのメリットは、
- 本当に能力のある人間、必要とする人間をスカウトできる
- エージェントを通さないでいいので、無駄なコストが発生しない
ただし、実力主義な方法だとは思います。
私は、これまでの経歴とかよりも「いまの自分を見てくれ」と思うタイプなので、この方法が正解でした。
必要なスキル
本当に必要なスキルは、
ググる能力と創作意欲、そして諦めないド根性
です。
ナルトはあとググる能力さえあれば、火影ではなくWebエンジニアになっていたかもしれません。
諦めないド根性は、冗談ではなく本当に必要な素養です。
何かを調べる（ググる）ときに自分が欲しい情報が必ずしも手に入るとは限らないです。その場合に「どう調べたら欲しい情報にたどり着けるのか」考えたり、そもそも実装の方法を変えてみたり、諦めないで試行錯誤する必要があります。
おまけ
3つ目のポートフォリオ
いま公開しているポートフォリオは3つ目です。
3つ作って分かったのが、ポートフォリオはシンプルな方が良いということです。
もちろんアニメーションを使ったりオリジナリティがあったほうがいいですが、それとは別に制作事例であったりスキルはわかりやすくまとめられている方が、見る側にとって楽です。
誰にどんな目的で見せるページなのかを考えましょう。
制作事例（Works）のページは自分でもよく見たりします。よく見るページがいちいちアニメーションさせないとすべて見れないのは面倒ですよね？
学習の優先順位
結論から言うと、
自分が作りたいものに必要な技術は、率先して学習するべきです。
その他（周辺知識）は、「それを使うとどんなことができるのか」程度に知っておくくらいでいいと思います。
Webフロントエンド開発だけ見ても様々なフレームワーク、ライブラリ、言語があり、とてもじゃないけどすべてを学習する時間はないですし、使わない技術を頑張って学んでも忘れるだけなので無駄です。
私の場合、以下のように派生して勉強しました。
HTML・CSS・JavaScript
↓
TypeScript
↓
React
↓
Next.js
もちろん、Three.jsなどのライブラリは別に勉強する必要がありますが、軸となる技術はこれだけです。
これだけでも、自分でポートフォリオを制作してそれをデプロイできます。
GitコマンドもDockerもプライベートな開発では使わないので、時間を取って学習はしてないです。（ざっくりどんな技術で何ができるのかは押さえていますが）
概要だけは押さえておいて、実務で必要なツールやライブラリは実務が始まってから覚えればいいと思います。
どうせ日常的に使っていればすぐに覚えます。
独学しているときは、使うかどうかわからない技術よりも、自分のアウトプットに必要な技術だけ身に着けて、あとは制作に専念したほうが有意義です。
あとは、
学ぶべき技術もひとつひとつを完璧にマスターする必要はないです。
重点的に学ぶのは、その技術のコンセプト、どんなことができるのか、そのキーワードです。
これさえ分かっていれば、その技術の特性を活かしながら、わからないことは逐一調べて実装できます。そして何回も調べるうちに自然と覚えます。
例えば、Next.jsだと「SSG（静的サイト生成）：サーバーサイドでAPIなどからデータを取得して、そのデータを埋め込んだHTMLを生成する機能」があります。これを使うと、クライアントサイドからリクエストがあった時にいちいちAPI通信をする必要がなくなるので、サイトが高速に表示されます。
コンセプト：サイトを高速に表示する
キーワード：SSG（静的サイト生成）
できること：サーバーサイドでAPIなどからデータを取得して、そのデータを埋め込んだHTMLを生成する
これをわかっていれば、SSGの具体的な書き方がわからなくても、いつSSGを使うのか、そのキーワードは何かがわかっているので、調べればすぐに実装できます。コンセプト（使いどころ）もわかっているので、その実装は正しいです。