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