フロントエンド開発の勘所 -複数事業を経験して見えた判断軸の違い-

burikaigi 2026 のスポンサー LT 発表の資料です

Transcript

1. フロントエンド開発の勘所 複数事業を経験して 見 えた判断軸の違い
2. 久保 陽 一 郎 (Yoichiro KUBO) • 株式会社サイバーエージェント所属 2016年新卒 入 社 現在は株式会社AI Shift (CA 子 会社) に在籍 • フロントエンドエンジニア 最近は何でも屋 • 福井 大 学 大 学院修了 @heimusu_me @heimusu
3. 1 .会社紹介とイントロダクション 2 .各事業部の紹介とフロントエンドの関わり 方 3 .まとめ
4. 会社紹介とイントロダクション
5. 会社紹介 • 社名：株式会社サイバーエージェント （CyberAgent, Inc.） • 設 立 ：1998年3 月 18 日 • 代表者 代表取締役会 長 ：藤 田 晋（創業者） 代表取締役社 長 ： 山 内 隆裕（2025年12 月 就任） • 本社所在地: 東京都渋 谷 区宇 田 川町40番1号 Abema Towers • 従業員数: 連結 8,150名（2025年9 月 末時点)
6. 会社紹介 サイバーエージェントには 大 きく3つの事業部があり、その中には 100 以上の 子 会社 ・ 事業が toC / toB 関わらず多数のプロダクトを展開しています
7. イントロダクション • フロントエンドエンジニアはプロダクトの価値をユーザーに届ける にあたって、最もユーザーに近い場所に 立 つ • 一方 でその「価値」が何を指すのかは、プロダクトの性質によって 大 きく 異なる
8. イントロダクション • サイバーエージェントの各事業部を例にしながら事業の性質によって フロントエンドの技術戦略や勘所の変化や違いを 見 る 特定の技術の解説はしませんが、それに 至 った背景や考え 方 をお伝えします
9. 各事業部の紹介とフロントエンドの 関わり 方
10. ゲーム事業
12. フロントエンドの使われどころ • ゲーム中のお知らせ画 面 • ゲームの公式サイトや LP • Webベースのサービス ・ DX事業など 今回の発表では割愛します
13. 技術選定の 方 向性 ・ 勘所 平易かつ枯れた技術、最悪エンジニアがいなくてもメンテナンス出来る
14. 技術選定の 方 向性 ・ 勘所 • ゲームは UI の装飾表現やインタラクションが web に 比 べてリッチ • ゲーム中の表現をwebに落とし込むことが難しいケースが多い ビジュアル表現を重視する
15. 技術選定の 方 向性 ・ 勘所 • お知らせを急いで公開するなど、最新の状態を反映させたい場合がある • CDNや端末内のブラウザキャッシュに注意 webview のキャッシュがなかなか消えないケースがある キャッシュに注意
16. 技術選定の 方 向性 ・ 勘所 • フロントエンドはシンプルな設計になることが多い • その分短期間でのリリースやゲームに寄せた表現、 非 エンジニアによる変更余地 など技術的な正解よりもチームやプロダクトへのフィットを優先する瞬間が多い • もし他事業部の観点でお知らせ画 面 を作ると… •しっかりした設計 ・ 実装になるが、リリーススピードが落ちたり 非 エンジニアが安全に コンテンツを編集できるようにする 工 夫が必要になる •フロントエンドとゲームでは UI デザインの取り扱い 方 が違うため綿密なすり合わせが必要 まとめ
17. メディア事業
18. メディア事業
19. フロントエンドの使われどころ • ちょっとした実装 ・ 設計ミスがパフォーマンスや UX の悪化を招く • 🙅作って終わり 🙆 長 く育て続ける ブラウザ版を提供しているプロダクトが多い
20. 技術選定の 方 向性 ・ 勘所 • 各種ライブラリ ・ フレームワーク • a 1 1 y • パフォーマンスチューニング • SEO • デザインシステム • キャッシュ戦略 • etc... フロントエンドらしい技術に 力 を 入 れる
21. 技術選定の 方 向性 ・ 勘所 • バックエンド、インフラ、モバイルアプリの知 見 これらをベースに仕様や設計の議論 ・ すり合わせを 行 う。モバイルアプリは プラットフォームによる制約や決済周りも知っておくと吉 • 動画配信 動画配信を 行 っているプロダクトが複数あり、シンプルな動画再 生 だけでなく 映像プロトコル、配信現場のオペレーションなども考慮してプロダクトや管理画 面 を作成する。 また、chromecast 等再 生 機器に携わるケースもある フロントエンド以外の知識も必要
22. 技術選定の 方 向性 ・ 勘所 • 数多くのエンドユーザーにプロダクトをお届けするため、 モダン技術を積極的に取り 入 れつつも堅牢な作りを 目 指す必要がある • フロントエンドだけでなく様々なドメインの知識が必要になる • もし他事業部の観点でプロダクトを作ると… 枯れた技術でシンプルな設計にすると、 長 期的な運 用 や拡張に耐えられない可能性がある パフォーマンス、a 11 y、SEO などにもこだわり切れないかも まとめ
23. インターネット広告事業
24. インターネット広告事業
25. フロントエンドの使われどころ • 忙しいビジネスマンが業務で利 用 するため、ドメイン理解に 基づく設計や UX へのこだわりが求められる 🙅「正しく動く」 🙆「迷わず使える」 • 1 日 に何時間も使われるケースが多く、操作回数や遷移の多さがそのまま 業務コストになる ツールを導 入 しているけど 面 倒で使われない → 契約解除 😱 フロントエンドが関わる領域は toB 向けプロダクトが中 心
26. 技術選定の 方 向性 ・ 勘所 • 技術スタック 自 体は React / TypeScript などモダンな構成 • モノレポ構成になることもある サーバー ・ インフラやプラットフォームをまたいで配置するもの など、プロダクトに関するコード類全般 • DDD / Clean Architecture などを下敷きに全体を設計する 特にモノレポになるとコードベースが巨 大 になるので、 どこに何があるかを把握しやすく ・ 設計や実装パターンを ある程度共通化したい 設計思想が重視される
27. 技術選定の 方 向性 ・ 勘所 • 「業務 ・ 作業時間を短くすること」に価値が出る • フロントエンドならではの視点 ・ 問いかけ デザイナーや営業も答えを持っていないケースが多々ある • もし他事業部の観点でプロダクトを作ると… ビジュアライゼーションにこだわったり、ドメインをそのまま表現した冗 長 な UI になったり まとめ
28. まとめ
29. まとめ • toC と toB のフロントエンドで求められることが違う toC: 「ユーザーにどう魅 力 を届けるか」「ユーザーにどう習慣的に使ってもらうか」 表現 力 、UX が価値になりやすい。フロントエンドが中 心 のプロダクトではパフォーマンスや SEO なども重視される。 toB: 「ユーザーの仕事をどう短くするか」「ユーザーにとっての使いやすさの追求」 エンジニアからの提案も 大 事。パフォーマンスチューニングや SEO は toC に 比 べて価値がいくらか落ちる傾向
30. キャリアエージェント ・ キャリチャレ • toBとtoCサービスのはどちらが 優れているということはなく 一長一 短 キャリアのフェイズやタイミングによって 個 人 にも向き不向きがある • 社内求 人 情報を全社公開しオープンな 応募を推奨する「キャリチャレ」や 相談に乗る「キャリアエージェント」 などの制度があります
31. We are hiring!!! インターンシップ 中途採 用 Re:Career採 用
32. ありがとうございました