元ネタとか
https://shgam.hatenadiary.jp/entry/2019/09/21/104413
https://twitter.com/Nkzn/status/1177794507741335552

自分はよくJSやCSSについての発信をしていて、「JSが得意です」とか「CSSが得意です」と言うこともあるのですが、その反応として「じゃあフロントエンドエンジニアなんですね」と言われると、「いやあ、うーん、どうなんですかね、、」みたいなぼやっとした返答をすることがよくあります。

その理由として「フロントエンド技術は好きだけど自覚としてはサーバーサイドエンジニアだし、DB設計とかもやりたいし・・・かといってフルスタックで言うのいやだし・・・」となだったのですが、このJSON色付けという話題を見て「実はここに自信が無いからという理由が本質なのでは？」と思えてきました。

ちょうど最近とある若手エンジニアに「フロントエンドエンジニアってキャリアはどう思いますか？」ということを聞かれてそれにも「いやあ、どうなんだろう」と微妙に答えてしまったのもあったので、いい機会なので考えをまとめてみようかなと思います。

いわゆるマークアップ・コンポーネント作成のタスク

マークアップ・コンポーネント作成というのはフロントエンドエンジニアの仕事の一部と言えますが、全てとも言えなくてその前段階とかにも色々あるよねというのは上記の元ネタとした記事にもあることです。

何を今更と言われそうですが、今回それこそが今、世間が最もフロントエンドエンジニアに求めているバリューポイントっぽい、というのは思ったよりも重要な点だと気付かされました。

色付けにおいてデザイナーに勝てないという諦め

なんとなくここまで簡易で軽微な仕事の揶揄として"色付け"という言葉が出てきているのですが、僕はこの部分において全く簡易でも軽微でも無いと感じてます。そしてそれは「デザイナーという本業には勝てない」というある種の諦めでもあります。

2019年現在、CSSやHTML、JSXを直接書くデザイナーも書かないデザイナーもどちらもいるかなと思っておりますが、今後どうなっていくだろうかと予想すると「技術進歩が進んで簡易になるのに合わせてどんどんCSS/JSXを書く人は増える」だと思ってます（僕自身がそういう環境を作るというのも一つの仕事だと認識してるので、これはポジショントークかもしれません）

これはなるほどデザインを読んだときにも感じたことですが、いままで「CSSという仕組みの都合に合わせてデザイン側の理論を捨てていた」という部分が、コンポーネント思考や様々なツールによって「CSSは無茶をさせてコンポーネントに閉じ込めてデザインの理論を優先する」ということがどんどん簡易になってきているというのが大きな理由です。こうなってくると分業は不要なものになってくるのではないかなと感じてます。

またJSXなどについても、デザイナが書くこと、書かせることに抵抗のある人は多いのですが、僕は「エンジニアがデザイナと仲良くして適切に切り出し点を提供さえさえすれば十分に可能、そして今後どんどんその手法は確立していく」と考えています。FramerXのようなJSXを直接吐き出すようなツールも後押しになっていくのではないでしょうか。

当然前提として、デザイナが直接書いたほうが早くて高品質な物が出来る・自分で書けるデザイナの方が良い品質になることが多いという体感があります。
幸いこれまで色々なタイプのデザイナーと仕事出来たことも大きいですが、この感覚はあまりズレたことはありません。自分が実装したものが調整されていくのを見る経験もありますが、プロ野球と高校野球ぐらいには差があるんじゃないかと感じます。

彼ら・彼女らは配置・配色・IA(情報アーキテクチャ）・クリエイティブ・UXなど古きから研究されてきたデザインという部分について専門性を持ち、常日頃研鑽しているのだから当然です。

僕の好きな漫画の一つである左ききのエレンに「デザインは学問。アートという未知の閃きに対抗するための知恵」という台詞があります。これに倣えば自分がデザインを勉強して追いつく事は可能ではあるなのでしょう。ただ片手間ではなくエンジニアとしてのキャリアを一回捨てて本気で行かないと彼らの足元まで辿り着くのは難しいというのも判っており、僕にはその覚悟は無いなと思ってます。

逆にもし読者でデザインをバックグラウンドに持ってフロントエンドへ転身したという方がいれば、むしろここはロールとして強みになっていくのではないでしょうか。

また一方で、例えばデザイナーが起こしたモックアップを再現する、という方面もあります。こちらは個人的にそれも自分には向いてないと感じるのと、自動化・低単価化の波を意識せずにはいられないという部分があり、キャリアとして選択したり他者に勧めるには怖いなと感じています。

それ以外のフロントエンドのお仕事

先の記事にもありますが、フロントエンドの仕事はそれだけではなく、状態管理・ルーター・ビルド整備・デプロイなど様々あると思ってます。
僕自身この部分はとても大好きで、プロとして十分バリューが出るという自負もあります。ただこの周辺の技術は基本的には泥臭く、かつ進展も目覚ましく廃れるものも少なくない、素早いキャッチアップが要求される部分でもあると感じます。

実際、以前のフロントエンドエンジニアはWebpackで一日消耗したり、古いシステムのままなんとか切り崩さずやっていくということは少なくありませんでしたが、最近はWebpackが簡単になったりParcelなどライトに完結するツールも出たり、TypeScriptとbabelの親和性が高くなりあまり悩む必要が減ったりしています。加えて外部で言えばマイクロサービスの盛り上がりでゼロベースで作れる環境が増えたのも後押ししてこの部分は徐々に仕事量は減ってきているように感じます（寂しい。消耗したい）。

また、状態管理やルーターなどの部分は、むしろこれまでサーバーサイドアプリケーションエンジニアが担ってきた部分に体感が近く、自分もそれらの知識経験が活きた部分が豊富にありました。ただこちらもRedux一強の時代がreact hooksが出てきてそこまでの煩雑さが無くなってくれば障壁が減ったり、彼らと肩を並べることが増えたり、ロールとして融合していったりするのかなと感じています。

フロントエンドエンジニアとしてそれでも残りそうな仕事

ここまで、フロントエンドエンジニア周辺にある文字通り前門の虎、後門の狼のような部分を説明してきました。ただ当然それでも残る部分もあると思ってます。

* どうしても細かい部分で要件が深くなる場所（「こんなモーダルでここでこんなアニメーションをこういうタイミングでやりたい」みたいな）
* デザイナーがパフォーマンスを出せることを意識した環境、システム設計作り
* そもそもが複雑さや各プラットフォームへの深い理解が必要とされる業務（noteのエディタなんかは良い例)
* パフォーマンスが重要になる部分の業務
* 複雑にWebAPIを利用する必要がある業務
* etc...

ただ、見るとわかる通り、定常的ではなく突発的だったり、ニッチだったりする仕事無かもしれません。もしかすると敷居が下がったらその分要件の要求が上がリ続ける、なんてこともあるかもしれませんがここはなんとも言えないので期待もしないほうが良いところかなと思っています。

その他：個人的に思う今後

上記「フロントエンドエンジニアとして残りそうなこと」は相変わらず視野に入れていくつもりですが、その他なんとなく自分の目指す方向性としてはNetflixのFull Cycle Developer(原文) というのが一つとしてあったりします。

フルスタックという言葉の言い換えっぽくはあったり、あらゆる分野に知識を求められるという点でさほど差異はありませんが、ここではよりDX（Developer Experience / Designer Experience)についても考えライフサイクルに介入していく、同時並行ではなく切り替えてすべてを視野に入れるという部分などが違うのかなと感じていて、全体的にDevOpsやインフラの流れの強い場所ですが、自分のような嗜好性でも目指したい方向としては面白そうだなと感じている部分です。