Upgrade to Pro — share decks privately, control downloads, hide ads and more …

いつか誰かが、と思っていた フロントエンド刷新5年間の実践知

Sponsored · SiteGround - Reliable hosting with speed, security, and support you can count on.

いつか誰かが、と思っていた フロントエンド刷新5年間の実践知

Avatar for Kiichi Sugihara

Kiichi Sugihara

May 09, 2026

More Decks by Kiichi Sugihara

Other Decks in Programming

Transcript

  1. kii • 株式会社 ツクルバ Web Frontend Tech Lead • 新卒入社6年目

    • ずっとWeb Frontendメイン x: @kiichi_sugihara GitHub: @KiichiSugihara 自己紹介
  2. • こんな方に向いています ◦ 一人 / 少人数フロントエンドで、改善 /課題が無限にある環境にいる方 ◦ アーキテクチャ刷新など、大きいシステム改善やりたい方 •

    今日は、こういう話はしません ◦ 細かい技術、codeの話 ◦ AIの話 • 聞き方のお願い ◦ 気になったことはぜひ後で声かけてくださいね!懇親会・廊下・ SNSで。 ◦ この発表をネタに、他の方と話してみて このセッションについて
  3. | 2026 | 2026 買う 替える 売る ストーリー仕立てで物件情報掲載で 新しい物件探し体験をつくる 顧客体験を重視した

    既存の不動産サービスの評価軸は、 間取りや広さ、築年数などのスペックメイン。 物件の個性や、本当の価値 を伝え、 適切なマッチングを早期に実現 しています 出会う |  ツクルバの事業  |
  4. | 2026 | 2026 出会う 替える 売る 買う |  ツクルバの事業 

    | カウカモエージェントによる 最適な暮らしの提案 不動産の知識と、ライフスタイルへの こだわりを持つプロフェッショナルとしてお客様に寄り添い、 欲しい暮らしへとエスコートします。 独自開発システムを用い、お客さまにとって最適な物件を提供するのはもちろん、 リノベーションコーディネート、不動産売買取引等、 住宅購入における最適な体験を提供しています。
  5. | 2026 | 2026 出会う 買う 売る 替える |  ツクルバの事業 

    | 誰もが理想の暮らしを手軽に手に入れるための リノベーションデザイン・カウカモ工務店 デザインはリノベーションチームが、専門知識を持って丁寧にサポート。 パッケージ商品からオーダーメイドまで、お客様が欲しい暮らしを叶えるために、 多様なリノベーションの選択肢を揃えています。 その後の施工フェーズはカウカモ工務店が担当。 より詳細な設計〜施工を、お客様に伴走しながらエスコート。 叶えたい暮らしを実現するまで、顧客体験を一気通貫で提供しています。
  6. | 2026 | 2026 出会う 買う 替える 売る |  ツクルバの事業 

    | 売り出す前に買い手が見える CtoCプラットフォーム 売り出す前に買い手が見える、 売り出し前の住まいに出会える、 売主・買主がダイレクトにコミュニケーション 可能なプラットフォームを通じて、 物件の流通のさらに促進
  7. | 2026 | 2026 出会う 買う 替える 売る つくる |

     ツクルバの事業  | 顧客データをもとに 求められる物件を生み出す カウカモプラットフォームに集まったデータを活用し、 中古物件を自社で買い取り、世の中に求められる物件を生み出す。 カウカモユーザーにマッチした素敵な物件を供給し、 中古住宅の流通を促進。
  8. 顧客ライフタイムに沿ったサービス展開 顧客ライフタイムに沿ったサービス展開イメージ リペア、リフォーム、生活サービス … 住替え 居住中~住替え検討 一次購入 ライフタイムでの顧客関係管理 流通データの統合管理 インターネット

    サービス リアル サービス デジタル 事業基盤 情報収集 リノベ カウカモ カウカモマガジン 家具・雑貨等 ウルカモ (売却検討者) ステージング 仲介(買) 仲介(買) (住替え支援) カウカモ (住替え⽀援) 共通ID / マイページ 仲介(売) ウルカモ (購⼊検討者) 金融関連サービス 現在の主なサービス 開発中のサービス 将来構想 ライフタイムに沿った拡張⽅向性 凡例:
  9. • Rendering: RailsでSSR ◦ 型が存在しなくミスると、500エラーでページごと見れなくなる • Script: Reactなどのフレームワークなし ◦ erbに直書きor

    一部のjQueryモジュール • Styling: SCSSで、Component分割もイマイチ ◦ 親が持つべきgapは、子のmarginやpaddingでLayout 入社時のWeb FE環境: ユーザー側
  10. • Rendering: RailsでSSR • Script: Railsの上から重ねる ◦ ReactやReduxがあったり無かったり • Styling:

    3つのオレオレデザインシステムが混合 • 自動テスト、Linterなどはほぼ機能していない。型無し。仕様は code 入社時のWeb FE環境: 管理画面側
  11. • 入社前の業務経験 : 休学して1年エンジニア修行 してた(2020年頃) ◦ Vue.js + TypeScript +

    VRT(reg-suit) etc • モダン開発環境と比較すると、 あれもない、これもない。。。 • 研修終わって まもなく、WebFE正社員の先輩が退職 (11月) こういう状態のところに、新卒で入った
  12. • ユーザー側 ◦ Next.js/AppRouter、Panda CSS ◦ TS/Linter/Formatter/Test(Unit,Component,VRT,E2E) • 管理画面側 ◦

    デザイントークンベースのデザインシステムで、 3種混在を統一する土台 ◦ etc 5年で、こう変わった ref: シニアフロントエンド採用要件
  13. • ユーザー側も、管理画面側にも、課題や改善ネタは大量 ◦ ユーザー側: SEO、パフォーマンス、a11y ◦ 管理画面: 社内のユーザー に、直接ヒアリングして要望応える •

    やれることがいっぱい あって、楽しい。 ◦ 喜ばれるし、表彰もされる。 できることが増えると、改善ネタが無限に出てくる
  14. • PdM: 最初に乗せるPJ に初期 / 不確実工数が乗る。 • デザイナー : デザイントークン

    /システムを一緒に 作っていく必要性 • BE: Rails MVC → API 分離 + RSC向けにリソース指向 API必要 • インフラ: FEだけじゃカバーできない、BE協力依頼 大きい山 — 関係者ごとに、違う壁
  15. 1. 管理画面 大規模 改修(2024春〜夏) — FE/Design課題解消 2. カウカモ JOURNAL(2024秋〜冬) —

    新アーキProd検証 3. 新 cowcamo 基盤 PJ(2025年1月) — システム改善の年次起案 4. ユーザーレビューページ (2025年2-3月) — 新基盤を使って実装 4つの事例を時系列で
  16. • デザインと FE 間に課題 が見えていた ◦ ユーザー側: iOS 先行で ネイティブ

    DesignToken が Web にコピペで混入 ◦ 管理画面側: 3つのオレオレ DesignSystem を跨ぐ大改修 が控えていた • 見立て: デザイントークンベース で整えれば、両方ハマりそう 事例 1 / 管理画面 大規模 改修(2024春〜夏) — 課題 ref: 別のプロジェクトのDesign Tokensが交じることで、開発メンバーに混乱とコストをもたらす by me
  17. 事例 1 / 認識合わせ — Slack / 隔週MTG etc ref:

    別のプロジェクトのDesign Tokensが交じることで、開発メンバーに混乱とコストをもたらす by me • ユーザー側の開発で起きていた課題感を共有 ◦ DesignToken の認識すり合わせ を開始 • Design System Slack ch を新設: 記事や本を流して相互学習 • 2週間に 1回 MTG: 自分たちが作りたいものを 言語化
  18. 事例 1 / 提案 → 合意 → ついでに仕込む • 3DesignSystem

    を無理改修 vs 1つの新 DesignTokenを各 DS から利用 ◦ 見積もりに Design Token揃える分を込みで入れる • デザイナー: 管理画面の新 DT を使ったデザイン作成 • その流れで: Web FE 全体の DT 定義も ついでに仕込む(意図的) ref: 社内管理ツールのカオスなデザインシステムをデザイントークンで統一by me
  19. • カウカモの新メディア `/journal` プロジェクトが立ち上がる ◦ このパス以下は 新しいアプリケーションで立ち上げ可能 な独立性 • リアーキ検証は

    一定試せていた(途中) ◦ 新アーキで完成させていくのに、ちょうどいい場所 事例 2 / カウカモ JOURNAL(2024秋〜冬)
  20. • 古いアーキ vs 新アーキの見積もりとメリデメを PDMに提案 ◦ 工数を並べた上で、新アーキで行きたい意思を明示 → 合意取得 •

    ついでにBEに仕込んだもの: ◦ RSC / リソース指向 API の説明、お願い ◦ インフラ面の協力依頼 (新アプリ用のホスティング・デプロイ) 事例 2 / 見積もり比較で新アーキで進める方向に
  21. • 年次起案で FY25 予算を事前確保 • JOURNAL とcowcamo を モノレポ化 •

    ついでにTestも基盤に組み込み (Unit,component,VRT) 事例 3 / 新 cowcamo 基盤 PJ(2025年1月) — 年次起案で事前に仕込む