スーパーエンジニアとの対話：フロントエンド技術とキャリア戦略について

はじめに

グロースエクスパートナーズ株式会社の中村です。
社内のエンジニアの酒巻さんと対話する機会をいただき、Web技術やフロントエンド開発、エンジニアとしてのキャリア戦略について多くの学びがありました。この記事では、その質疑応答をフロントエンドエンジニアが抱えがちな悩みごとに整理して皆さんと共有していきます。

相談相手の酒巻さん

酒巻さんは、過去にW3Cの活動に参加し、AngularやTypeScriptなどのコミュニティにも貢献されてきた実績をお持ちです。OSやブラウザの開発経験、技術カンファレンスでの登壇もされたことのある業界屈指のエキスパートです。

現在は主に以下のような業務に携わっているそうです：

開発基盤の準備や体制サポート

• モノレポとTBDを主流とした開発体制の導入・教育・サポート
• アジャイル・スクラム導入支援
• 生成AIを導入した場合のモダン開発インフラの準備や提案
• 開発基盤の構築や準備（デプロイメントパイプライン、静的解析や自動テスト体制の構築、分析基盤構築など）
• IaCなどのインフラの自動化や開発基盤の自動化

Webテクノロジ・フロントエンド技術

• プロジェクト立ち上げ時のテックリードエンジニアとしての参加（実際に開発を手伝い、キャリアの浅い人への教育を行う）
• 監査的なテックリード（リードエンジニア）としての技術支援（セキュリティ・パフォーマンス・アクセシビリティなどの品質監査）
• デザインシステムの構築と運用、運用支援
• UIコンポーネントライブラリの構築と運用、運用支援

生成AI

• 生成AIを活用したプロダクト開発の支援（活用の相談や提案作成の補助など）
• 生成AIを活用したプロダクト開発（実開発を行うのも）

目次

1. フロントエンドエンジニアとしての成長戦略
2. 技術をどこまで深く理解し、どのように学べばよいのか
3. アクセシビリティの重要性が分からない

1. フロントエンドエンジニアとしての成長戦略

Q. フロントを強化したいのですが、フロント以外が弱いのも気になっています。どうすれば良いでしょうか？

質問の詳細：

27歳まで別業界で非エンジニア
↓
AI・機械学習の勉強（半年）
↓
ブロックチェーンとフロントエンド開発（一年）
↓
現在の会社でフロントエンド開発（一年弱）

私の経歴は上記の通りでして、方向性が定まらなかった面があります。

まだまだWeb技術全般の知見が弱く、とくにバックエンド・DB・インフラ周りの経験があまりありません。さらにフロントに特化と言えるほどのレベル感でもありません。

フロントの強みをもっと伸ばすためにリソースも割きたいのですが、とはいえフロント以外をちゃんと習得できていないまま経験年数が積み上がっていくのもヤバい気がしており、どうするべきか悩んでいます。

A. Webとフロントエンドのアプローチを分ける

話が難しくなるため、Webとフロントエンドの話を分けましょう。

Web：「標準化された仕様」です。
フロントエンド：Webを主としてビジネスを実現するエンジニアリング技術です。

Web技術というのは、標準仕様があり、Webブラウザなどが実装しているものです。ただ、Webだけを使いビジネスを実現するのは難しいため、フロントエンド技術が必要になります。
ではフロントエンド技術とは何なのかというと、Webを常識として構築されたサードパーティー製の製品やサービスです。例えば、ReactやVue.js、AWSやAzureなどの各種サービスもWebを基盤にして構築された製品です。

「フロントエンド技術」を学ぶ強み

• 学習コストが少なく、より実践的である
• 世の中の問題を抽象化し対処された製品が多いため使いこなしやすい
• 多くの人が使っているため情報が豊富
• 明確な目的に対して効率的に問題解決できる
• ビジネス面での的確な技術判断ができるようになる

「Web技術」を学ぶ強み

• 標準仕様は学習コストが高いが応用が効く
• 情報の更新は学術的なペースで遅い
• アーリー領域での勝負はしづらいが、安定すれば運用コストは低い
• 根本的な問題解決や新しい技術理解の基礎になる

両方学べればベストですが、限られた時間で学ぶ場合はどちらかに意識的に取り組むのが効率的です。

中村：
私の悩みとしては、そのどちらに対して現在重点的にリソースを割くべきなのだろうか？である気がします。
主戦場はフロントエンドで行きたいのですが、Web技術への理解が浅いとシステム全体が見通せないし、クライアントとの会話が成り立たない場面も出てきてしまうという問題が出てきてしまいます。

A. 問題解決型の視点を持つ

とはいえWeb技術への理解が浅ければシステム全体が見通せないし、お客さんとの会話が成り立たない場面も出てきてしまう

ここを問題視しているのなら、一つの技術を深く知るよりもフロントエンド技術の項にあるように「世の中の問題を抽象化し対処された物が多いため、製品の解決したい問題を理解するだけで使いこなせる」といったスキルはクライアントと直接会話する立場であればとても相性が良いと思います。そのためには、まず最初に「世の中のフロントエンド、Webブラウザを使うユーザーやビジネスには今どんな問題があるのか」を調べることをお勧めします。自分のプロジェクトを一度離れた位置から観察して、何か問題点や悪効率なものがないかを探してみるのもよいでしょう。

技術を仮に「基本技術」と「応用技術」に分けたとき、応用技術は何か明確な目的や課題を解決するために生まれたものとします。活動が活発なOSSではその応用技術による製品で似たものがたくさんありますが、それぞれ問題へのアプローチや考え方が異なったりしていろいろ発見や気づきもあります。

OSS製品の目的や課題が記載されているページを読み、以下の観点で見ると面白い発見があります：

• 利用者の課題
• 開発者の課題
• 経営者の都合
  • 開発委託元と開発受注、内製開発それぞれ存在することに注意

中村：
フロントエンドの技術の項目を一つ一つ身につけるというよりも、技術によってどんな課題を解決したいのか？みたいな視点が先にある方が重要というイメージでしょうか。そういう視点は、あまりありませんでした。

A. 技術と課題を抽象的にとらえられるスキルが大切

自分が一人で何かを作り出すなら一つの技術に習熟するのが正解かもしれませんが、ビジネスと技術の橋渡しを行えるエンジニアというプロジェクトの「バランス」を整える役割を担えるようになりたいのであれば、技術と課題を抽象的にとらえられるスキルというのは、これからのキャリアでは活躍できるのではないかなと思っています。
その技術が「誰の課題を解決し、誰にとって都合が良いのか」を抑えることはとても大切です。課題の解決とその利益を享受するのが同一人物とは限りません。

そして一つの技術を詳しく調べたり、使い込んで知識を習熟することはとても大切で有意義ですが、くれぐれも可用性ヒューリスティックなどの認知バイアスにかからないように注意してください。

さらに、一つの製品に詳しくというのは、そのうち生成AIにとってかわられそうという話もあります。課題を的確に捉え、それを言語化できるという意味だと、生成AIを用いた開発方面でもキャリア伸ばせるかなと思います。

Q. フレームワークとの向き合い方

質問の詳細：

昨今のモダンな開発現場ではNext、Nuxtというフロントから派生したフルスタックフレームワークがよく使われていますが、根本的なところが理解できていないのが不安です。フルスタックフレームワークとして内部的にどう成り立っているのかが掴みきれていません。SPAとしてのReactやVue、またバックエンドフレームワークで毎回HTMLを生成するというやり方などはなんとなく理解できるのですが、NextやNuxtへの根本的な技術的理解ができていないので、正直怖いなと感じてしまいます。

A. フレームワークの実態と意外な普及率

面白い話をしましょう。実はReactそのものが世界での利用率10%くらいしかなく、Next.jsやNuxt.jsは世の中のWebサイトの中でたった3%程度の利用率しかありません。

Reactの利用率は10%
https://almanac.httparchive.org/en/2024/javascript

さらに、実際のネットワークトラフィック換算で考えると、仮説ベースになりますが、この数値はさらに低くなる可能性があります。というのも、トラフィック換算だと必然的に「アクセス数の多いサイト」の影響が大きくなります。アクセス数の多い大手サイトの多くがReactやNextなどを使っていないため、実際のトラフィックではさらに低い数値になるのではないかと考えられます。ここから見えてくるのは、「実はビジネスではReactやNext.jsなどのフレームワークをそれほど使っていない」ということなのです。

Webページのトラフィックデータ
https://www.semrush.com/website/top/

なぜみんな使っているように見えるのか？身もふたもないことを言うと「開発ベンダーが楽にお金を儲けられるから」という一面があります。フロントエンドフレームワークは、以下の特徴があります：

• 優秀なエンジニアを雇わなくても開発できる (ローコストのエンジニアで世の中の問題を解決できる開発が可能)
• フロントエンドフレームワークは流行り廃りが多いので、開発ベンダーは「流行のフレームワークを使っている」というだけで「優秀なエンジニアがいる」と思わせることができる

では、フロントエンドフレームワークなどのフロントエンド技術が意味ないのか？というと、そんなことはありません。フロントエンド技術は「明確な問題を解決するためにWeb技術を利用して作られた製品」です、そこにマッチすれば非常に効果的です。問題点は、猫も杓子も同じ技術ですべてを解決しようとすることです。
ここが、上にある中村さんのキャリアの話につながります。
中村さんがこの上の問題にたいしてどう付き合っていきたいかというのが技術者としてWebの技術を正しく使って問題を解決したいなら「Web技術」です。
なによりもビジネスのことを第一に考えて技術はあくまで手段でしかないと割り切って活躍したいなら「フロントエンド技術」です。

ちなみに重要な話ですが「Webトラフィックから見るスクラッチUI開発は減ってる」だけであり、「Web開発案件が減ってる」ということではない点には注意してください。どういうことかというと、「Webトラフィックから見る」というのは、公開されている一般サイトについてです。それ以外、例えば「閉じたネットワークにある企業の管理画面」などはこのデータに含まれていません。当社の受注する案件の多くはこの「企業の管理系アプリ」であることが多く、ここではSPAであることの強みを生かせるケースが多いのです。（ただしSSGである必要がない場合が多いのですが）
今まで企業の開発はWindowsアプリなどのネイティブ系技術を主に開発してきましたが、HTML5の登場以降、この企業の管理系アプリがネイティブからWebへと変わってきています。（もちろん信頼性や制約の関係で、医療や組み込みなどはいまだにネイティブですが）
レガシーといわれているネイティブで作られた企業管理アプリのReact置き換えは、これからもどんどん出てくるでしょう。そのため、仕事がなくなるのでは？という気遣いはしなくて大丈夫ではないかと思います。

中村：
Nextなどがそんなに利用率低いとは驚きました・・一応フロントのデファクトスタンダートとは言われているので。

A. ReactやNextの実際の普及状況と市場での位置づけ

一応フロントのデファクトスタンダートとは言われているので

これを詳しく言語化すると、「SPAなどのフロントエンドフレームワークで新規製造する案件でのデファクトスタンダート」ではあります。
ただ、上記のような案件よりも、CMSを使ってUIを提供する案件や単純なキャンペーンサイトや告知ページなどのほうが流通量が圧倒的に多いという背景があります。

CMSを利用してないサイトは、2025年に30％を切った
https://w3techs.com/technologies/history_overview/content_management/all/y

UIにそれほどお金をかけて開発してリターンをペイできるようなビジネスは、それほど数は無いと言うこともできます。実際、UI/UXに拘って最前線で強豪と戦ってる業界の代表格(A社やR社)はReactを使ってないという事実があります。

歴史的な話をすると、もともとSPAが発生したのは、「スマートフォンのアプリに近い体験をWebブラウザで実現したい」という動機が背景にありました。経営者側の「GoogleやAppleに中間マージンを取られたくない」という意図や「アプリ開発人口の不足」といったビジネス的側面と、Web技術者の「スマートフォン上でアプリ同等の体験を提供したい」という二つの軸があり、急速に発展しました。

デスクトップPCでは潤沢な回線とリソースが確保できますが、スマートフォンでは当時（2009年代）回線速度も処理能力も限られていました。そこで登場したのがSPAという技術で、初回接続時にアプリのように必要なリソースをダウンロードし、最小限の通信でページ全体の体験を提供する仕組みです。

当時、ネイティブアプリの課題としては以下のようなものがありました：

• アプリ開発者が少ないのに、AndroidとiOS両方の開発・保守が必要になる
• 複数のソースコードの管理が必要
• ストアの申請がかなり面倒（当時）
• そもそも見つけてもらうのが大変（ストアの検索機能がしょぼい）
• 開発環境やエミュレーターの品質が低い

これらの課題から、資本力のある企業しか参入できない状況でした。

一方、SPAはHTML5の普及とともに以下のような利点がありました：

• Web開発者の人口が圧倒的に多い
• ブラウザが動作する端末であれば対応可能
• アプリストアを介さずに直接提供できる
• SEOなどの検索最適化や、紹介記事からの誘導がシームレス
• Chrome開発ツールの進化による開発効率の向上
• 開発・配信コストが非常に低い

上記のような様々な追い風を受けて、ネイティブアプリ vs Webアプリという構図の時代でした。実は現在でもこの構図は大きく変わっておらず、React/Next.jsなどの競争相手は実は他のWeb技術ではなく、ネイティブアプリだと言うこともできます。

サービス展開の選択肢は、大まかに次の2種類に分類できます：

1. 開発・運用コストを抑え、情報の展開（見つかりやすさ）を重視し、エッジな技術を必要としない場合はWeb
2. コストをかけてでもブランド認知を高め、エッジな技術で優れたUXを提供して競争する場合はネイティブアプリ

大手ECサイトや主要な動画プラットフォームの例を見ると分かりますが、Webページでも提供されてるにもかかわらずこれらの企業はアプリに力を入れています。これは、ネイティブアプリのコンバージョン率がWebの1.5〜3倍という結果が出ているためです。

モバイルアプリの方がウェブサイトよりもユーザー獲得とエンゲージメントに優れている
https://www.mobiloud.com/blog/mobile-apps-vs-mobile-websites

まとめると、スマートフォンアプリと対抗するためにReact/Next.jsなどは発展してきましたが、ネイティブアプリと比較するとユーザーコミットメント（定着率）が低い反面、運用コストも安いという特徴があります。そのため、大手企業はWebも展開しつつもアプリへの誘導に力を入れる傾向にあり、Webサイトの運用にはコストを抑えてアプリ開発にリソースを集中させています。

一方で、激しい競争環境になければ、Webで完結できるReact/Next.jsなどは非常に有用であり、プラットフォームごとに分かれたアプリの2重管理よりも1つのプロジェクトで管理保守ができるため、ビジネス的に合理的な選択となります。

さらに言えば、ビジネス目標と技術コストを冷静に比較した上で、React/Next.jsが本当に最適な選択肢か、あるいはCMS（コンテンツ管理システム）の方が適しているのか、そもそもNext.jsのようなSSG（静的サイトジェネレーター）が必要なのかといった判断ができ、それを論理的に説明できるようになれば、エンジニアとしての仕事にも納得感が生まれるでしょう。

あと別の観点から言及すると、NextやNuxtなど流行りの技術を使うのは「求人」の問題もあるでしょう。これは企業の都合ですが、有名な技術やトレンド技術は、技術者は興味をもって意欲的に学習してくれます。企業としては何かを作るときに労働力がいるので、そのスキルセットをもった人材を雇いやすくなる（いわゆる買い手市場）ので助かるという側面もあります。

おまけ： Angular、意外と普及している

また、面白いデータを見せましょう

2024年に最も需要のあるフロントエンドフレームワーク
https://www.devjobsscanner.com/blog/the-most-demanded-frontend-frameworks/

フロントエンドフレームワークにおける、欧米の「求人割合」が記載されています。Reactが1位ですが、意外なことに２位にAngularがいます。これは界隈では有名な話で、Angularは業務フレームワークとして確たる地位を築いており、社内システムだとかなり需要が多いのです。
実際Amazonのフロントエンジニア求人でも、経験(BASIC QUALIFICATIONS
)に「React, Angular, Webpack, Babel, and Grunt.」となっていたりします。

Amazonのフロントエンジニア求人
https://www.amazon.jobs/en/jobs/2896007/front-end-engineer

中村の所感

フロントエンド技術orWeb技術全般のどちらのスキルアップに注力すべきか問題については、学習コストの高いWeb技術全般は案件に関係する部分を少しずつ知見つけつつ、基本的には「フロントエンド技術」を伸ばすという方向性が、自分にとって一番現実的だと感じました。
普段目の前のタスクをこなしていると、どうしても技術の理解度・習熟度といった側面にばかり目が行きがちだったのですが、技術の習得は“手段”に過ぎず、まずはユーザーやビジネスが抱える本質的な課題を見極めることが大切だということを理解しました。今後は、様々な技術を「誰の、どんな問題を解決するのか？」という視点で改めて見直し、自分の学びを課題解決につなげていきたいと思います。
また、フロントエンドの世界ではNext.jsやReactを使うのが当たり前だと思っていましたが、実際の利用率が意外と低いことに驚き、これからはデータに基づいた判断を大切にしたいと改めて感じました。

2. 技術をどこまで深く理解し、どのように学べばよいのか

Q. 技術をどこまで深く理解するのが良いのでしょうか？

質問の詳細：
会社の仕事とはあまり関係がない話ではあるのですが、ReactとかViteだとかの内部的な仕組みを深く理解したいという個人的な欲望は実際結構ありまして・・そこまで突き詰めたところでビジネス的な価値はあまり生まれないですし単なるオタクになってしまうので、バランスはとる必要があると思っています。技術をどの深さまで理解するのが良いでしょうか？

A. 「何ができるか」を抽象的に理解する

これからフロントエンド技術者を目指すなら、Next/Nuxtなどは「何ができる子」なのかを抽象的に捉えておく程度にするのがおすすめです。この「何ができる子」といのも技術的な理解ではなく「誰の何の役に立つのか」を理解しておけば、あとは生成AIに「Next.jsで〇〇はできる？」「それをする実例教えて」という世界になってくると思ってます。実際、酒巻のプロジェクト周りでは既にそうなってる面があります。

ライブラリに詳しいだけの技術者はコントリビューターでない限り、エンジニア市場であまり価値が保てなくなると思うので、メンテナーになるほどの覚悟がないのなら、ひとつのライブラリには深くのめりこまず、プロジェクトの課題ややりたいことを言語化できるエンジニアを目指してもらえると、そこまで新しいライブラリやツールに怖さを求めなくてもよいではないかと思っています。

また、突き詰めることが個人的な欲望と理解できてるのなら問題はありません。余暇を使い趣味で深い領域を探索をするのもとても良いことで、酒巻も若い頃は「仕事はビジネスと技術の橋渡し」「趣味でOSS活動」という切り分けで仕事とプライベートを分けていましたし、今でもあまり変わってないかもしれません。この趣味のOSS活動で知識や経験を得て、たまたま成果を出して今の社長の目についた結果GxPに誘われて現在のキャリアがあったりします。
趣味の活動も突き詰めると自分自身のキャリアとなることが多いので、ぜひ続けてください。ただ、上にあるように「一つのことにのめりこみ過ぎてバランス感覚を失わない」ことを忘れないことは大切です。

中村：
酒巻さんはコンピュータの低レイヤーまで理解されており、実務で使う技術に対する理解が相当深いと思います。対して自分は、低レイヤーへの理解が正直全然ないまま実装してしまっており、そこの知見がないことにどうしてもコンプレックスを感じてしまいます。

A. 誰もが巨人の肩の上に乗っている

私も、例えばリーナス・トーバルズ氏などと比べるとLinuxの中身は分かっていないですし、そういう意味では同じくコンプレックスがあるのですよ。IT業界で働く人間は、多かれ少なかれ誰しもが巨人の肩に乗っかっています。コンプレックスだと感じる必要はなくて、知識が足りないという意識は自らの探究心に変えてあげれば良いと思います。
我々ITエンジニアはいかにも技術的に凄いことをやっているように見えてしまったりしますが、電気やインターネットの物理的なインフラを自分たちで構築しているわけでもないですし、ほとんどは他の人が作ったものを利用させてもらっているに過ぎません。例えば「Reactの中身を全部理解した」と言っても、それはめちゃくちゃ狭い領域内の話に過ぎず、実はそれほど価値のあるものでもありません。

中村：
経験年数を重ねたからとて誰もが酒巻さんほどの技術力を身につけられるわけではないと思うのですが、なぜそんなに技術力が高いのでしょうか？

A. OSS活動で実力がついた

社会人になったのが2002年頃で、当時は大企業に所属していましたが、かなり暇だったので会社に置いてある技術書をたくさん読みました。全部読んでしまい、たまたまネットで見つけたOSS活動を私も手伝うことになりました（2006年頃）。その活動で知り合った方に普段何をやっているのかを聞いたところ「Web開発者」だと言われたのですが、よく聞いてみると、普通にイメージするWeb開発者ではなくて、Webそのものを作っているという意味での「Web開発者」でした。そんななかで続けていったOSS活動で、相当自分の実力がついたと思います。

中村：
酒巻さんにとって当社で働き続ける意味を教えていただけますでしょうか。

A. エンタープライズDXを推進する理念への共感

エンタープライズの世界では気軽に現場の技術を刷新するというのが難しいですが、それは現場と企業のコミュニケーションに難があるためとも考えています。
なので、技術者という視点だけやチームマネジメントだけという1点を中心に考えるのではなく、各分野のエキスパートが企業、IT、チーム、それぞれの力を引き出しバランスよく橋渡して体制そのものをモダン化する「ITとチームの力を引き出し、エンタープライズDXを推進する」というグロースエクスパートナーズの社長の理念にとても共感しています。当社は大企業からの一次受けがとても多いという特徴があります。二次、三次受けだとなかなか声を届けたくても届けるのが難しいですが、一次受けだと声が届きやすいということに魅力を感じています。

中村の所感

酒巻さんは非常に高い技術力をお持ちなので、「フレームワークの内部仕組みを徹底的に理解すべき」のようなアドバイスを想像していました。しかし「まずは何ができるかを抽象的に捉えればよい」という想定外のご示唆をいただき、大変驚きました。これまで「中身が複雑そうで怖い…」と思っていたモダン技術にも、もっと気軽に取り組める自信が持てるようになりました。
私がグロースエクスパートナーズへの入社を希望したのも、「ビジネスと技術をつなぐ視点で価値を創りたい」という想いが大きな原動力でした。その気持ちを改めて振り返りつつ、今後は技術の細部に立ち入る前にまず“何ができるか”を明確に把握し、生成AIなどを活用して効率的にキャッチアップしながら、プロジェクト成果に直結するエンジニアリングを実践していきたいと思います。
とはいえ、技術をより深く理解したいという気持ちも強くありますので、将来的には酒巻さんのようにフレームワークの仕組みやコア技術をしっかりと把握できるエンジニアを目指して努力していきたいと思います。

3. アクセシビリティの重要性が分からない

Q. アクセシビリティはなぜ重要なのか

質問の詳細：
セキュリティやパフォーマンスは直感的に重要性が理解できますが、アクセシビリティがなぜ重要なのか、正直腹落ちしていません。

A. アクセシビリティの二つの意義

アクセシビリティそのものは、正直なところしないほうが直接的には儲かります。
しかし、企業が大きくなると、直接的な利益のほかにも社会貢献や還元が求められるようになります。その一つがアクセシビリティであり、アクセシビリティには大きく2つの意味があります：

1. 対法律的な意味合い：
   Webの理念は「すべての人に等しく情報を得られる権利がある」です (目が見えない・文字が読めない人でも等しく利益が得られるべきである)。そのため、WebにはWeb Content Accessibility Guidelinesという万人が平等にWebへアクセスするためのガイドラインなどが策定されています。
   なぜそれが重要視されるかというと、「権利侵害からくる訴訟」という問題があります。多くの国の法律には「公共における障害を持つ人々に対する差別を禁止」しています。そしてpublic Webというのは「公共の場」と法律的には判断されます。（なのでアカウント不要な場所で全裸をリアルタイム公開すると猥褻物陳列罪になる）
   つまり、一般公開してるwebサイトは公共の場であり、障害者に対する差別をしてはいけないという法律があるため、アクセシビリティを無視した場合、有名企業だと訴訟される可能性が高くなってしまうのです。

2. 優良企業アピール：
   もう一つとして、優良企業アピールというものがあります。
   たとえるなら、企業における寄付や慈善事業をイメージしてもらうと近いかもしれませんね。これは公平よりも平等という考えが今のグローバル社会においては重要視されているため、企業のイメージを良くするためにアクセシビリティを意識したページ作りをすることが多いです。
   また、国の仕事を受ける場合、アクセシビリティの監査はすごく厳しくなります。W3CのWCAGにAAAレベルを満たす必要があるため、国のホームページなどはわざわざW3Cの関係者を呼び込んでチェックすることもあります。（ただ、多くの場合はツールでチェックしてOKだったりする）
   近年はチェックツールや専用ライブラリの出現で対応が容易になってきているというのも普及の理由です。

中村の所感

まさか、W3Cの中にいた方から直接お話を伺えるとは・・！Webの根幹にある理念や法的背景の重要性について理解でき、勉強になりました。まだアクセシビリティの知見があまりないので、今後公式ドキュメントなども確認し、実務にも活かしていきたいと思います。