目次
■キャリアとスキルアップ
2022.06.14 2023.12.14 約5分
Front-End Lounge 「フロントエンドエンジニアのキャリア」より lacolaco氏の基調講演をレポート。
現在フロンドエンドエンジニアとして活躍しているエンジニアが、さらにキャリアアップしていくための方法を紹介します。
「ユーザーに価値を届け続けるためにアプリケーションの大きな不確実性を引き受ける」
「その重さから価値が生まれる」と語るlacolaco氏。
これからのキャリアに悩みを抱くフロントエンドエンジニアの方は必見です。
フロントエンドエンジニアのキャリアについて考えるにあたって、そもそもフロントエンドエンジニアとはどのような仕事なのか、フロントエンドエンジニアが生み出す価値とはいったい何なのか、そうした前提となる部分についてのひとつの考え方をお話させていただきます。
lacolacoと申します。Google Developer Expert (GDE) で Angular の専門家としてコントリビュータなどの活動をしています。Classi株式会社ではフロントエンドエキスパートチームで仕事をしています。
皆さんにとってフロントエンドとは何でしょうか？
アプリケーションを立体として考えたときに、ユーザーに対して前側にあるものがフロントエンドです。そして、ユーザーが触れる界面をユーザーインターフェースと呼びます。
フロントエンドの責任範囲は明確に決まっておらず、とてもざっくりしています。どこからが前でどこからが後ろかについては触れられず、いかなる技術的な条件も含まれていません。フロントエンドは人によってやっていることが全然違います。
フロントエンドは、アプリケーションにユーザーがアクセスできる経路の数だけ存在します。
他にも未来にかけていろいろなフロントエンドが生まれる可能性があります。私たちが今使っているのは Webブラウザを使ったフロントエンドです。
Webフロントエンドは Webブラウザを通して、どうやってユーザーがアプリケーションと対話するかに縛られています。つまり、Webフロントエンドはブラウザ自体の技術的制約を超えることはできません。
Webアプリケーションは、ユーザーがアプリケーションに対して “Web” を通してアクセスしてきます。つまり、ユーザーとアプリケーションの間に Webブラウザがあります。
また UI とアプリケーションがありますが、このとき実際にはブラウザの上に UI があります。アプリケーションにアクセスする手段としてユーザーはブラウザを利用します。ブラウザ上で UI が作られ、それを通してアプリケーションと対話をする関係が Webアプリケーションです。
どれだけやりたいことがあってもブラウザに実装されてないことはできないというのは多くの人が経験しているのではないでしょうか？
一つの限界値を決めるのが Webブラウザ自体の Capability（技術的制約）です。
Webフロントエンドエンジニアにとってブラウザについての知識や経験は、その範囲内でどれだけの引き出しを持っているかに直結します。
限られた領域の知識だけで成立する仕事やアプリケーションもあると思いますが、発展的なことをする場合、引き出しの多さが重要です。
Webフロントエンドエンジニアは、どのような責任や専門性を持っている人なのでしょうか？
フロントエンドエンジニアは、アプリケーション開発をフロントエンドとバックエンドに分業することで生まれる役割です。
2つの領域をどのように境界付けるかが、フロントエンドエンジニアの責任範囲や専門性の範囲に大きく関わります。
フロントエンドとバックエンドの境界は人の手で都合のいいように作られています。
どのアプリケーションのフロントエンドとバックエンドの境界も、そのアプリケーションにとって都合がいいように切っているのです。
経験則によって典型的な切り方のパターンがある場合もあります。
クライアントとサーバーの境界をそのままフロントエンドとバックエンドの境界にするパターンは一般的ですが、そうでなくても問題はありません。前側から始まり、どこかで終わればフロントエンドです。
同一システム内で分割すれば、MVC（Model-View-Controller） のアーキテクチャのようなビューレイヤーとモデルを分ける話になったり、システムごと分ける場合は、フロントエンドとバックエンドのデプロイをして別々のサーバーでおこなう構成になると思います。つまり境界は人間が決めています。
バックエンドとフロントエンドの2層にアプリケーションを分割した瞬間に、レイヤードアーキテクチャのような構造になります。
レイヤードアーキテクチャは、依存関係が一方向になるように下位レイヤーが上位レイヤーから独立する構造です。下位レイヤーは上位レイヤーのことを気にしなくてよくなるのがレイヤードアーキテクチャですが、逆の構造・依存が発生します。上位レイヤーは下位レイヤーを気にする必要があります。
つまり、層を切った瞬間に必ずどちらかに依存します。片方は独立できますが、もう片方は独立できません。
どちらが独立した側か考えた場合、多くの方はフロントエンドがバックエンドに依存していると考えるでしょう。
上下関係を考えるときに、バックエンドを下位レイヤーとするのではないでしょうか？
先ほどはブラウザがフロントエンドに技術的条件を加えましたが、バックエンドもまたフロントエンドに技術的条件を加えます。
フロントエンドがバックエンドに依存しているということは、バックエンドの技術的な制約、アプリケーションの上のフロントエンドにできることの限界をバックエンドも条件を加えてきます。
つまりフロントエンドをよくしたいときに、バックエンドがリミットをかけているのであればバックエンドに手を加えることも発生しうることを意味しています。フロントエンドのために手を付ける部分がバックエンドにあるということです。ここに責任範囲が及ぶこともあり得るだろうということです。
責任範囲はどこで境界付けるかによって変わるので、フロントエンドエンジニアの責任範囲はアプリケーションごとに決まります。
アーキテクチャが会社や組織で決まっていれば、その組織単位でしか決まらないので、どこまでをフロントエンドエンジニアの責任範囲にしていますか？という決定の問題です。
責任範囲はどこか？= 責任範囲をどこにしているか？です。
Webフロントエンドエンジニアに求められる技術や知識は、以下2つの技術的条件があります。
そのうえでWebフロントエンドは、ユーザーとアプリケーションをつなぐ前側にいることが本質です。
フロントエンドエンジニアの責任は、フロントエンドとバックエンドを1つのアプリケーションとして整合するようにつなぎ合わせ、ユーザーと対話できるようにすることです。Web であれば上記に加え、 Web上でという条件がつきます。そこから各フロントエンドの場所によってそれぞれ条件が増えていきます。
フロントエンドエンジニアのキャリアがどこに向かうのかを解説します。
フロントエンドの細分化が続いていくと思います。アプリケーションがフロントエンドとバックエンドにわかれただけでは終わらず、さらに分業が進んでいます。
例えば以下の専門領域が生まれていると思います。
分業は生産性を増大させます。理由は考えなくてよい部分やブラックボックスでよい部分を作ることができるからです。
関心にフォーカスできると技能が熟練したり簡略化できたりなど、最適化する技術や発明が生まれます。これは責任範囲を限定することが大きな要因です。
フロントエンドは責任範囲を固めて分業していけばよくなると思いたいですが、条件がもう1つあります。アプリケーションが果たす責任は常に流動的で不確実です。
分業によって不確実性が集中します。不確実性を含む責任範囲があるときに分業しますが、一方の責任範囲を明確にすると、もう片方に不確実性が集中します。
フロントエンドは不確実性の塊です。アプリケーションにとって最も不確実であり、流動的なものはユーザーのニーズとユーザー自身です。
これは一つの考え方ですが、アプリケーションの中からバックエンドを取り除いて、残りをフロントエンドだと考えてみます。バックエンドはサーバーやデータベースの堅牢性、システムの安定性を重視するためにユーザーから距離を取り、不確実性を限定したときに残った部分がフロントエンドなのではないかという見方です。
フロントエンドの「変更容易性や捨てやすさが大事だ」という話は、これを裏付けているといえます。不確実で流動的な部分を扱っているため、より簡単に変えられる、いらなくなった部分をすぐに捨てられる部分が必要になります。
この考え方から「フロントエンドは変化が早く複雑で難しい」という印象を受けるのも当然です。
フロントエンドの領域でどれだけ分業を進めても、本質的に不確実性の高いユーザーに向き合っている時点で不確実性はなくなりません。
私は以下2つの道が残されていると考えます。
先鋭化するフロントエンドエンジニアは生産性を増大させ、技術の進歩を生み出す道を意味しています。つまり明確な責任範囲を区切ったなかで、技術的な革新や生産性増大に貢献する道です。
しかし、それだけだとアプリケーションとして成立しません。アプリケーションとして価値を生み出すためには、それ以外を引き受けてくれる仲間が必要です。
不確実性を引き受けるフロントエンドエンジニアは、フロントエンドとバックエンドが一つとなり、ユーザーと対話し続ける、その価値を生み出し続けることに価値や責任があります。
しかし細分化した責任を仲間に任せていかなければ、増え続ける要求に追いつかなくなります。つまりフロントエンドとバックエンドは、お互いが支え合わないと成立しません。
これからの Webフロントエンドエンジニアについて解説します。
不確実性が減ることはないと思います。多様性を重視する世の中になっているので今後もユーザーの要求は多様化し続けていくでしょう。
社会全体のソフトウェア化が進んでいくなかで、ユーザー個人からではなく、社会からの要求もアプリケーションに対して向けられていきます。アプリケーション開発は流動的かつ、いろいろなことに備えていく必要があります。特にユーザーに近いフロントエンド領域において顕著でしょう。
ただし専門性の本質は変わらないでしょう。フロントエンドとバックエンドをアプリケーションとして整合するようにつなぎ合わせ、ユーザーと対話するという価値を見出すことがフロントエンドエンジニアの専門性の本質です。
そこに Web やプラットフォームの知識があると技術的な選択肢を増やすことができます。これが技術や知識を身につける理由です。
不確実性を引き受ける役割は今後ますます重要になると思います。全員が自分の専門領域に閉じて仕事をしていてもアプリケーションは完成しないので、誰かが増大する不確実性を引き受ける必要があります。
「不確実性請負人」と名付けましたが、これからのフロントエンドはここに目を向ける必要があるでしょう。
特定の領域のスペシャリストは輝いて見えることもありますが、不確実性を引き受け続けるのは土台として必要な役割であり、そこがないと技術がただの技術で終わってしまいます。
アプリケーションを価値に変えるために必要な役割だと思うので、不確実性請負人としてのフロントエンドエンジニアの道も大きな価値を生み出すキャリアであり、そのように評価できているだろうか？を考えていきたいですね。
私は「ユーザーに価値を届け続けるためにアプリケーションの大きな不確実性を引き受ける、その重さから生まれる価値ではないか」と思います。
Node.js の古川陽介さんが発表した「フロントエンドエンジニアになる覚悟」の中にも1つの答えがあります。フロントエンドエンジニアの価値については一人ひとりに答えがあるので、皆さんも自分の答えを考えてみてください。
Q&A
ここからは、lacolaco 氏 / potato4d 氏による視聴者からのQにお答えします。
lacolaco：やらなければいけないことが生まれて、それをただやっていくだけでは場当たり的に対処しているという評価になりえます。そうならないように不確実性を請け負いつつ、持続的であるように保ち続けることが重要です。
「不確実性を引き受け続ける」ことが重要です。持続可能性を保ち続けることは、そもそもの価値に含まれています。
どんどん不確実性が増えていくとわかっているのに何も対策を打たないのは、不確実性を引き受け続けることを放棄していることになります。
例えば
このあたりが実現できるか？それを評価できるか？の両面が必要です。持続可能性や継続性が答えになると思います。
potato4d：評価者は「スケールする組織に頼れる人材であるか？」を常に見ていると思います。アプリケーションやシステムがスケールしたとして、今のあなたのやり方でよいのですか？という点を見られていると思います。
lacolaco：スケーラビリティの思考が見れるようなアウトプットになっているか？スケーラビリティへの関心を評価できているか？だと思います。次に同じことをやる際、今より少しでも楽になっているように改善する意識の部分だと思います。
potato4d：不確実性の観点ではフロントエンドと真逆ですが、インフラの人の考えを聞けると面白そうですね。必要な事項に応じて目の前の課題に対応する必要がある一方で、スケールに対する要求もあると思うので、近しいものがあるかもしれないですね。
Google Developers Expert
オープンコミュニティを愛する Web Developer。2016年より Angular 日本ユーザー会の代表を務める。 仕事の傍ら、Google Developers Expert for Angular として Angular エコシステムへのコントリビューションや翻訳、登壇、イベントの主催などの活動を続けている。
