フロントエンドのお仕事

前職のこと

自分は新卒でシステム開発に初めて携わり始めましたが、その会社ではサーバーサイド、フロントエンド、デザイナーという分業はありませんでした。

SE（システムエンジニア）と呼ばれる職種の人が要件定義、設計、デザイン、結合テスト、運用を行っていて、PG（プログラマ）の職種の人が開発と単体テストを行っていました。

部署によってはその境界も曖昧で両方を兼ねている、1人で全てを行っているエンジニアの方もいました。

PCのネイティブアプリ、Webアプリ、VBAフォームと色々なものを作っていましたが、最後の方に作っていたのはWebアプリでした。ここでは上記の役割のほとんどを自分が関わっていました。

その中でも好きだったのはアーキテクチャ設計と技術検証、パフォーマンスの出るSQLを書くことでした。1つの入力に対して、1つの出力が決まる完全性がとても好きでした。

フロントは技術検証ではたくさん触りましたが、デザイン、今でいうところのUI / UXにはほとんど関わっていませんでした。

そのプロジェクトの途中で、こんなに色々やっていて大丈夫かなという不安がありました。その頃の界隈を見ていると、デザイナー、バックエンド、フロントエンド、QA（品質保証）、PM（プロダクトマネージャー）と分業をしていて、圧倒的に専門性があるように見えました。

何でも屋でいると仕事がなくなるかもなぁという感じたところもあり、一度技術力で勝負してみるのもいいかもしれない、そうすれば不安がなくなるだろうと思って、転職しました。

半人前のフロントエンド

募集要項を眺めていてVBAフォーム、Windowのネイティブアプリを評価してくれる会社は少なく、C#のWeb APIを作っている会社も少ないし、引っかかるとすればフロントエンドしかないよなぁと思って、フロントエンドで仕事を探しました。

なんだかんだSPA、TypeScript、Sass、UIコンポーネント、認証認可、パフォーマンス改善、多言語、単体テストは全部触ってたし、いざとなればバックエンドの方が自信あるし、なんとかなるかなぁという目論見でした。

そんなこんなで無事フロントエンド専門になりました。技術力で勝負すると言いつつ、結局設計〜運用まで全部やっているという話はひとまず置いておきます。

1年目は共通コンポーネントの環境を作ったり、ユニットテスト環境を作ったり、リプレースをしたりして、なんだかんだバックエンド時代みたいな仕事が多かったです。

プログラムの全体像を把握して、理想の出力を作っているだけなので、バックエンドのAPIを作ったり、技術検証している時の感覚に似てますね。期待値ぐらいには働いたと思います。

フロントエンドとデザイナー

バックエンドの感覚を引きずったまま、フロントエンドの仕事をしていたわけですが、当然デザイナーと関わります。仕様を頂いたり、そこに対して工数を答えたり、成果物をレビューしてもらったり。

当然デザイナーの方がビジュアルやその裏にある論理には詳しいです。うちのデザイナーはマークアップは書けますし、JSの振る舞いも書ける人もいます。

それを見るとデザイナーがフロントエンドの仕事を兼ねた方が早いのでは、と考えたことも多いです

分業は組織の人数構成と開発体制に寄るよねという元も子もない話になるとは思いますが、少なくとも幾らかはフロントエンド専業の方が強いことがわかってきました。

• 開発環境の整備
• 全体のデータ設計
• パフォーマンス改善
• ブラウザ対応・網羅的なテスト
• 成果計測
• コンポーネント技術を使った設計（フロント技術から見たデザインシステム）
• コンポーネントの状態の表現
• アクセシビリティ
• インタラクションの設計
• どこまで実現可能かという判断と工数の見積もり
• 新しい技術を使った新しいUI
• システム開発でよく使われるUI

上3つは半人前のフロントエンドで書いたようなことですが、その下はフロントエンド専業だからこそできる、やるべきことなのかなと思ったりします。

上でも少し触れましたが共通コンポーネントを作ったのはエンジニアの発案で、これはコードの重複が嫌だったというのが大きな理由でした。

デザイナー的にはそこまで気になっていなかったようですが、コンポーネントの洗い出しをするとやっぱり似たUIが多くてわかりにくいよねという話になって、統一化が始まりました。

あとはインタラクションや状態などは静的なデザインを作ることが多いデザイナーのイメージが掴みにくく、フロントエンドエンジニアの方が提案しやすいように感じました。

また、前職は業務システムを作っていたので大量のデータを一括で扱うUIだったり、業務で使う以上安全に寄せたデザインだったりはよく使っていました。

ここら辺の経験を積めるデザイナーは少ないので、そこも優位性を感じたりします。

フロントエンドと他の開発者

うちの会社であれば、インフラを含めた開発環境の整備するチーム、バックエンドの環境を担当するチームが他にいます。

インフラ系の仕事については全く知識で太刀打ちできていないので、専業したらここまですごいのかと驚かされてばかりです。

アクセス数が増加した時の対応が限りなく俊敏で、あっという間にインフラをスケールさせますし、障害が起きそうな時間を予測して当てたりします。

その他、デプロイの仕組み、セキュリティ対策、権限管理、予算管理、などを全て高いレベルで行っていてとても勉強させてもらっています。

バックエンドチームの中でも、リファクタリング、言語・ライブラリのバージョンアップを専門にするチームもいてここも専門性が高いです。

言語の仕組みをハックして影響調査をしたり、大規模なリファクタリングを広い視点で行ったり、コードのメトリクスを集計したり、専業ではないと厳しいところを感じます。

こうやって仕事を眺めると、全部やる兼業よりもより高いパフォーマンスを出している組織は多いのかなと感じます。

どちらがいいというよりも、そもそも前職では3人とかで開発をすることが多いので、この選択肢をとるのは厳しいということでもあります。

フロントエンドのお仕事

改めてこの分業化でのフロントエンドのお仕事は何かを考えます。

あえて分業しているわけですから、デザイナーやバックエンド、その他のチームがフロントエンドを兼ねた方が効率がいいと思われているようなチームでは存在意義がないことは確かです。

月並みな結論ですが、まず技術を使ったデザイン、ユーザーへの体験への貢献が一番できるのがフロントエンドエンジニアであるべきだと思います。

デザイナーがユーザーへの理想の体験を考えているときに、今できる技術で一番わかりやすいUIは何か、考慮しないといけないことは何か、UI以外の技術でそこを助けることができないか。

マークアップ、JavaScript、CSS、ABテストツール、パフォーマンス計測ツールなどを駆使して、本当に最適な体験が提供できるかどうかを考えるのがフロントエンド専業である意味の1つなのではと思ったりします。

技術で何ができるのかがわかっているのは当然エンジニアなわけですから、そこの想像力はとても大事です。

また振る舞いを書くだけでなく、どこまで体験を許容するのかの判断もフロントの責務だと自分は思います。

どれほどのパフォーマンスなら許容されて、どれぐらいデザインが整合されていれれば良いか、時間内にできるのはどこまでかというのは技術者しか判断できません。

フロントエンドチームでもさらに分業が進めばまた変わると思いますが、専業エンジニアとしての強さというのは考えていきたいところです。

後書き

ずっと半人前のフロントエンドの人間で、最近も組織体制とかマネジメントとかばかり口を突っ込んでいる身ではあるのですが、その中でフロントとしてどう判断すべきかを考えたくて書きました。

世の中に素晴らしいフロントやデザインは溢れているので、それを見て感動しながら、プロダクトをよくするためにその感動を表現できるような専業者でいたいなと思いました。

もちろん、専業であるか、兼業であるかは組織が決めることなので、与えられた場所で与えられた役目を考えて動きたいです。どちらにせよ、どうして今この場所にいるかを忘れずに仕事をしたいです。