モノサスアクセシビリティアドボケイトとかWeb開発者とかマネージャーとか色々やらせていただいている原田です！最近は「あれ？もしかして私ってデザイナー！？」とか、まだまだ肩書きが増えそうです！！

昨年、探究型予算としてウェブコンポーネントを中心としたモダンWeb開発の教材を購入しました。

Modern UI Engineering Through the Lens of Web Components

ここ数年、毎朝私のメールアドレスにmediumという文章投稿サイトから興味がありそうな内容の記事がいくつか送られてくるのですが、昨年の1月に「Using Global Styles in Shadow DOM」という記事を読みました。そのなかで筆者であるRob Eisenbergさんが作られた学習教材「Web Component Engineering - by Rob Eisenberg」というものの存在を知り、内容をの深さに強い興味をもち、これはやらねばと購入しました。

教材自体かなりボリュームが有り、それなりの値段がしたのですが、探究型予算という枠組みで購入できたことは会社に本当に感謝です！

中身を簡単に紹介するために教材紹介ページのキャッチコピーをブラウザで日本語に翻訳してみます。

フレームワークがなくても、Web プラットフォームのパワーとパフォーマンスを活用する方法を学べるとしたらどうでしょうか?

---

Rob Eisenberg が、幅広い最新の Web 標準の適用を通じて UI エンジニアリングを探求します。Web コンポーネントを基盤として、このコースではプロの UI エンジニアやデザイナーが日常的に使用できる数十のトピックを取り上げます。DOM API や Web コンポーネントから、最新の CSS、アクセシビリティ、フォーム、デザイン システム、アプリケーション、ツールなどまで、さまざまなトピックを扱います。経験レベルに関係なく、このコースはあなたが探していた Web プラットフォーム リソースです。

この学習教材を選択した背景として、このキャッチコピーにある「フレームワークがなくても」がいかに重要であるかを説明させてください。

ここ数年のＷｅｂ開発ではフレームワークや第三者ライブラリを用いて開発することがデフォルトの選択肢となっています。「どのフレームワークやライブラリを使用するプロジェクトなのか」がエンジニアの開発体験やキャリア形成にとって重要な観点になりすぎているのが現状です。

フレームワークを用いた開発はそれなりに楽しく、知見もネット上から拾いやすいため、開発という断面だけで見ると、非常に完成度が高い手法になっています。

その反面、作るプロダクトがどのようなもの、どのようなものになっていくのかをよく考えずに、フレームワークやライブラリ、プラットフォームを安易に選定してしまうと、ローンチ後の運用や改修で大きな問題が出てしまうこともありえます。

例えば選定したフレームワークやライブラリ自体の開発が止まってしまい、代替手段への移行に多大なコストが発生する。頻繁なアップデートを盛り込まないとプロダクトを抱える企業のガバナンスを逸脱するため、サービスにあまり関係のないメンテナンスコストが増大する。運用チームにその技術スタックへの知見が足りずうまく利用できない。などなど。

この問題は開発時点で「開発することだけ」を「エンジニアだけ」が考えている現状によるものだと思います。エンジニアが悪いというよりも、「プロダクトに関わる人々の想像力」がその後の運用フェーズなど将来的に起こり得ることに対して、どうやっても限界があることに大きな原因があると個人的には考えています。

また、フレームワークにインクルードされているものがどんどん幅広くなっていて、ブラックボックス（フレームワークが提供する機能）をブラックボックスのまま扱うには、あまりにもいろいろなことが出来てしまうことも懸念点として覚えておくことが必要です。同じエンジニアが関わっているのに、選択されたフレームワークやライブラリの違いで、アクセシビリティやパフォーマンスに大きく揺れ幅が出てしまうのであれば、エンジニア自身が自分の能力をブラックボックス化することになってしまうかもしれません。

ご多分に漏れず、私も同じような失敗を何度かしてきています。誰もがモダンフロントエンドフレームワーク、、どころかWebプラットフォーム上でどの様にビジネスを行えるかについての探求や想像をしているわけではありません。そのため、私がさまざまなことを考慮してつくったものに対して、「思ってたんと違う（思ってない）」みたいなことでがっかりさせてしまったり、多大に修正に時間を消費したり。

これは、シンプルとイージーを混同しているというか、イージーに倒れてしまっていることが原因だと考えます。

であれば、イージーよりもシンプルを目指すことが一つの解決策になりえるのではないか。それがこの教材には詰め込まれています。

ウェブコンポーネントを用いてWeb標準に即した低依存なWeb開発であれば、例えばフレームワークやライブラリのバージョンアップによる使用技術のレガシー化。より多機能なフレームワークにお引越しするための多大なリファクタリング工数と決別できます。低依存な開発環境は新たなプロジェクトを始める際にも技術選定を考える工数が削減できます。そしてなにより、低依存であればあとから最適なフレームワークを導入することも柔軟に対応できます。

確かに自分自身で手を動かしたり、設計をしなければならない部分はフレームワークよりも増えます。それでも、そもそも何が必要なのか、どの程度汎用化させるのか、ブラウザが提供しているアクセシビリティをどの様にプロダクトに落とし込むかなど、本来開発者が考える領域を開発者自身が掌握するのは、生成AIを用いたコーディングが当たり前になった現在にこそ必要なスキルであり、開発者としてのキャリアパスに必要なことです。

低依存厨の私としてはハイレベルにウェブコンポーネントとその周辺のモダンWeb開発の知識を得られるこの教材は、まさに渡りに船でマストバイな教材でした。

教材の進め方、難しかった点

1コマ5~20分程度の動画とデモコードが中心の教材なのですが、とにかくボリュームが多く、また内容はすべて英語であるためネイティブではない私に取ってはWisperやChatGPTの力を借りながら講座内容を一つずつ理解していく事となりました。

そして最大の問題はそれなりに忙しい私にとってこのカリキュラムを進めていく時間を捻出すること。タスク管理ツールなどを使用して毎日どのくらいやるかタスク化したとしても、「今日はいいか」「今日はべつのことが重要だから仕方ない」という感じで教材を進める習慣が薄くなり1ヶ月以上進捗が出ないこともありました。

それでもなんとか進められたのは学習意欲と合わせて探究型予算として宣言していた手前、やらないわけにはいかないという精神面でのプレッシャーをうまく活用したからだと思います。もう一つ、中だるみからうまく習慣化に転換できたコツとしては「ペースを落とす」ことが重要でした。一コマで良いから必ず毎日やる。調子が出てきてもぐっとこらえてペースを守る。タスク管理ツールにも講座のURLを入力しておいて「今日はこれをやる」というある程度具体的な状態を作っておくようにしました。ちなみにやる気というのは起床とともに下がり続けて睡眠まで回復させるのは難しいということを何処かで聞いていたので、学習時間は基本的に朝にしていました。

どの様に活かしていくのか

一口にWeb標準に即したウェブコンポーネントと言っても、アプリケーションやサイト全体で必要なものを構築しようとするとかなり大変です。そして、作成されるコンポーネントが将来どの様に拡張されていくのかなどを見越した機能や汎用性を持たせておかないと後々似たようなコンポーネントが乱立してしまう状況を招いてしまいます。

この教材には、

• ウェブコンポーネント間でのCSS共通化
• 基本的なForm要素の属性値の呼び出しや伝搬
• 設定したオリジナルの属性値を簡単にコンポーネント内で定義する

といったかなり便利なものが提供されていて、実務でもかなり高度で拡張性の高いウェブコンポーネントを開発する手助けになりそうです。

現在社内の有志で制作会社としてのコーディングガイドラインを新たに作っています。そのなかで汎用性をもったウェブコンポーネントを基本キットとして提供できないか考えています。

どのプロジェクトでも一定以上の質のアウトプットを提供することが自分たちの責務であり、その質というのは時間とともに時流に合わせて向上していく必要があります。質を上げていくことをテーマにしてしまうと、それを簡単に実現することにフォーカスしてしまい、結局依存性が高い状態の開発環境が出来上がってしまうのではないか。それであれば自分が率先して低依存の機能を開発し社内（外？）に提供していくことが必要なのではないかと考えています。

今回の長い学習の日々を通して、やはり私は開発基盤を作ったり理想の開発環境を考えたりするのが大好きだなと感じました。2024年の後半くらいから、よりデザインや体験の領域でものを考えたり仕事を始めたりすることが多くなってきているのですが、その頭の片隅では「このデザインからおこされたコンポーネントをデザインの意図通りブラウザへ配信するためのマークアップと、アクセシビリティとスタイリングを爆速で開発できる低依存環境は…」と考えを巡らせています。Web制作周りの技術進歩は目を見張るほど早いです。目立つのは第三者ライブラリやフロントエンドフレームワークのように見えますが、ブラウザとWeb標準でできることもどんどん増えています。もし、本当にイケてる開発者を目指すならまずはWeb標準で実装出来ないか一緒に考えていきましょう！