フロントエンドでより高い年収とより良いポジションを目指すなら、単にUIをより速く実装する能力だけでは不十分です。
多くのフロントエンド開発者が成長のある時点で壁にぶつかる理由は、実力がないからではありません。
会社や面接官にとって、依然として「画面を実装する人」としか見られていないからです。
AIがコンポーネント、フォーム、カードUI、API連携コードを素早く生成する時代において、この評価はより危険なものとなります。
単純な実装能力だけでは、ますます容易に比較され、より低単価な役割へと追いやられる可能性があります。
より高いレベルのフロントエンドエンジニアは、画面を作る人ではなく、複雑な要求事項を構造化する人です。
どんな状態が存在するのか、データのソースはどこなのか、どの画面にSSRが必要で、どの画面をCSRとして切り離すべきか、レースコンディションはどこで発生するのか、デプロイ後の問題はどのようなテレメトリで追跡するのかまで設計できなければなりません。
この講義は、まさにその評価基準に合わせて作られました。
フロントエンドの知識をより多く暗記する講義ではなく、受講生が製品とシステム全体を理解し、設計できるフロントエンドエンジニアとして評価されるよう、思考プロセスを変える講義です。
フロントエンドのシステムデザインにおいて重要なのは、用語をたくさん知っていることではありません。
重要なのは、複雑な画面を見た時に問いが変わることです。
講義の前には、このように考えるかもしれません。
「この画面はどんなコンポーネントに分けようか？」
しかし、講義の後には質問が変わります。
「この画面の核心的なユーザー体験は何だろう？」
「どのデータが必ず正確でなければならないか？」
「どの状態は一時的にstale（古く）なってもいいのか？」
「状態のソース（原本）はサーバーなのか、クライアントなのか？」
「遅いレスポンスが最新のUIを上書きしないようにするにはどうすればいいか？」
「パフォーマンスはどのような数値で定義すべきか？」
「運用中に問題が発生した場合、どのデータで原因を追跡するのか？」
この講義は、難しい理論を先に暗記させることはしません。
Threadsのフィード、Amazonのショッピングカート、NetflixのストリーミングUI、Googleドキュメントの共同編集、Micro Frontend、Observabilityといった、実際のサービス事例から出発します。
まずユーザーが目にする製品体験を分析し、その体験を安定させるために、なぜ状態管理、データフロー、レンダリング戦略、パフォーマンス最適化、オブザーバビリティ（観測性）が必要なのかを逆方向に説明します。
そのため、受講生は単に「どのように実装するか」を超えて、なぜそのような構造が必要なのかを説明できる力を養うことができます。
AIはすでに多くのフロントエンドコードを作成することができます。
ボタン、フォーム、カードUI、CRUD画面、API呼び出しコード、基本スタイリングは、ますます速く作られるようになっています。
そのため、単純な実装能力だけではフロントエンド開発者の差別化ポイントが弱くなる可能性があります。
しかし、さらに大きな変化は別にあります。
AIは開発手法を変えるだけでなく、製品のUI構造そのものを変えています。
従来のUIでは、ユーザーがすべての段階を直接実行していました。
検索ワードを入力し、フィルターを選び、結果を確認し、ボタンを押し、次の画面へと移動していました。
しかし、Agentic UIでは、ユーザーがまず目標を伝えます。
「この問題を分析して。」
「このデータを比較して。」
「この作業を自動で処理して。」
「この結果を見て次のアクションを提案して。」
すると、AIが目標を解釈し、必要なデータとツールを選択し、複数のステップを実行します。
フロントエンドの役割は、ここでさらに重要になります。
AIが何をしているのかを見せる必要があります。
中間結果をユーザーが理解できるように表現しなければなりません。
危険なアクションはユーザーの承認を得る必要があります。
失敗したツール呼び出しは復旧可能でなければなりません。
AIの結果が不確実なときは、そのまま確定させずに検討可能な状態で表示する必要があります。
この講義では、このようなAIネイティブな製品体験のためのAgentic UI設計も扱います。
Agentの実行状態をどのようにモデリングするか、tool-calling UIをどのように見せるか、streaming responseをどのように扱うか、ユーザーの承認フローをどのように設計するか、そしてAIが生成した結果をどのように検証可能なUIで表現するかまで、共に見ていきます。
AI時代にフロントエンドエンジニアがすべきことは、減っているのではなく、変化しています。
単純な実装はより自動化される可能性がありますが、
AIとユーザーが共に作業する複雑な製品体験を設計する能力は、より重要になっています。
この講義はその変化に合わせて、フロントエンドエンジニアが単なるUI実装者を超えて、AIネイティブな製品体験を設計するエンジニアへと成長できるようサポートします。
この講義は、抽象的な概念だけを説明するものではありません。
実際のサービスで頻繁に遭遇する複雑なUI問題を基に、フロントエンドシステムデザインを訓練します。
Threadsスタイルのフィードでは、単に投稿リストをレンダリングするだけでなく、無限スクロール、重複排除、optimistic reaction、stale response、リアルタイムアップデート、閲覧位置の保持を扱います。
Amazonスタイルのコマースでは、商品リストとカートを作るだけでは終わりません。
非会員のカート統合、価格変更、在庫検証、決済のunknown状態、idempotencyKey、hydration mismatchまで扱います。
Netflix/YouTubeスタイルのストリーミングUIでは、<video>タグを使用するレベルでは終わりません。
バッファリング、再生状態、ネットワーク品質、画質切り替え、障害復旧を状態モデルとして扱います。
Google Docsスタイルの共同編集UIでは、単に入力欄を作るのではなく、ローカルの編集状態とサーバーの同期状態、競合処理、リアルタイム反映、そしてレイテンシと一貫性のバランスを扱います。
Micro Frontendでは、アプリを分割する方法だけを学ぶのではありません。
組織のデプロイ単位、チームの責任、shellとremoteの境界、shared dependency、design system consistencyまでを共に見ていきます。
これらの事例を通じて、受講生はフロントエンドシステムデザインを単なる理論ではなく、実際のサービスの問題を解決する思考プロセスとして身につけることができます。
この講義では、booleanの状態の組み合わせという限界を超えて、複雑なUI状態をX-M方式でモデリングする方法を扱います。
X-M（「X-」はここでは公開しないことにします）方式は、私が特別にUC大学の1つで知人を通じて聴講し、そしてビッグテック・フェローシップの過程でインド系の友人たちと議論した手法の1つです。会社でドキュメントを作成したり、協業したり、設計したりする際に有用な方法になると思い、カリキュラムに追加することにしました
しかし、より重要なのは「何を状態と見なすか」です。
いいねボタンは単にisLiked一つで終わらないかもしれません。
ショッピングカートの数量は単にquantity一つで終わらないかもしれません。
決済ステータスは単にloading、success、errorで終わらないかもしれません。
実際のサービスでは、状態はより複雑です。
ユーザーがまず目にした状態があり、クライアントが楽観的（optimistic）に表示する状態があり、サーバーが確定した状態があり、失敗した時に戻すべき状態があり、結果がまだ分からない不明（unknown）な状態があります。
受講生は単に「状態管理ライブラリの使い方」を学ぶのではなく、複雑なプロダクト体験を予測可能な状態フローとして設計する方法を学ぶことになります。
フロントエンドのパフォーマンス最適化は、単に画像をlazy loadingしたり、コードをsplitしたりするだけの問題ではありません。
実際のサービスでは、まずどのようなユーザー体験をどのような数値で保証するかを定義する必要があります。
商品詳細ページではLCPが重要になる場合があります。
オートコンプリート検索窓ではTime to First Suggestionが重要になる場合があります。
リアルタイムフィードではスクロールの安定性と重複排除が重要になる場合があります。
ビデオUIではbuffering rateとplayback recovery timeが重要になる場合があります。
共同編集UIでは入力latencyと同期遅延が重要になる場合があります。
この講義では、パフォーマンスを漠然と「速くしよう」という形では扱いません。
どの画面でどの性能指標が重要なのか、どのレンダリング戦略を選択すべきか、どのような状態とデータフローがパフォーマンスのボトルネックを生むのか、そしてデプロイ後に実際のユーザーのパフォーマンスをどのように観測するのかまで、共に見ていきます。
したがって、受講生は単なる最適化のヒントではなく、製品の要件に合わせた性能設計能力を養うことができます。
実務で重要なフロントエンドの問題は、デプロイ前にだけ発生するわけではありません。
むしろ本当の問題は配布後に発生します。
特定のブラウザでだけボタンが動作しないことがあります。
特定のネットワーク環境で決済ステータスがunknownに陥ることがあります。
カートのrollback率が特定のバージョンで急上昇することがあります。
検索レスポンスが遅くなり、stale responseが増えることがあります。
hydration mismatchが特定のページでだけ発生することがあります。
この時、単に「エラー追跡ツールを導入しました」だけでは不十分です。
フロントエンドエンジニアは、どのようなイベントを収集すべきか、どのような状態遷移を記録すべきか、どの指標がユーザー体験の問題を示しているのかを設計できなければなりません。
この講義では、ObservabilityをSentryの設置のような単純な実装とは見なしません。
RUM、error tracking、telemetry contract、状態遷移ログ、rollback rate、stale response ignored count、payment unknown rateといった指標を通じて、フロントエンドシステムを運用可能な構造として捉えます。
この視点があってこそ、フロントエンド開発者は単なる実装者にとどまらず、デプロイ後の品質まで責任を持つエンジニアへと成長することができます。
講義にミッションがありますが、ぜひやってみることをお勧めします。
最高です。 5年目のフロントエンドエンジニアとして、これまで不足していたり、漠然としていた部分が、この講義を通じて解消された気がします。 合間にあるミッションは、本当に苦労して頭を抱えながら進めることをおすすめします。講師の方から詳細なフィードバックをいただけるからです！ 講義を公開してくださり、本当にありがとうございます！もし他の講義も計画されているのであれば、ぜひよろしくお願いいたします。 ありがとうございました！
直前に続けて受けた講義は、講師の知識は豊富かもしれませんが、内容の構成や話の意図を理解するのが難しく、本当に苦労して受講しながら受講料がもったいないと思っていたところだったのですが…本当に宝石のような講義に出会えました。これまでフロントエンドの講義は多くても、システムデザインに関する部分は漠然としたままでしたが、こんなに素晴らしい講義に出会えて良かったです。説明も頭にスッと入ってきますし、多くのことを学んでいます。
良いインサイトを得ることができました！ 公開予定の講義が本当に楽しみです！
多くのインサイトを得ることができました。 セクション3にアップロードされる内容が楽しみです。
![[統合] Vibeコーディング入門 + アプリ実践制作完成講義サムネイル](https://cdn.inflearn.com/public/files/courses/342986/cover/01kwkcfpxw9bwfvp6018ap5w1n?w=420)
![[Rookiss] Claude Code開発のためのCS入門（インタラクティブ教材）講義サムネイル](https://cdn.inflearn.com/public/files/courses/343039/cover/01kwv3b2cb7kbbtt4ystj4bnsf?w=420)
