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

https://docs.google.com/presentation/d/1gLr0LkStk59UJaPxPdv-Gl6Eyr3sQab5z-5RxEZQMxU/edit?usp=sharing

#fec_nagoya #room_a

1. いつか誰かが、と思っていた フロントエンド刷新 5年間の実践知 kii/@kiichi_sugihara 2026-05-09 フロントエンドカンファレンス名古屋 2026
2. kii • 株式会社 ツクルバ Web Frontend Tech Lead • 新卒入社6年目 • ずっとWeb Frontendメイン x: @kiichi_sugihara GitHub: @KiichiSugihara 自己紹介
3. • こんな方に向いています ◦ 一人 / 少人数フロントエンドで、改善 /課題が無限にある環境にいる方 ◦ アーキテクチャ刷新など、大きいシステム改善やりたい方 • 今日は、こういう話はしません ◦ 細かい技術、codeの話 ◦ AIの話 • 聞き方のお願い ◦ 気になったことはぜひ後で声かけてくださいね！懇親会・廊下・ SNSで。 ◦ この発表をネタに、他の方と話してみて このセッションについて
4. ２つの学び 1. 時間の使い方が、未来を決める 2. 理想を描いて、ついでに仕込む 5年でいろんな学びがあった、その中でとくにこの２つ 今日お話すること
5. まず、会社・組織・入社時の状態を 共有させてください
6. 設立　　：2011年8月（15年目） 社員：約300人 会社フェーズ : 東証グロース上場 会社概要
7. | 2026
8. | 2026 | 2026 買う 替える 売る ストーリー仕立てで物件情報掲載で 新しい物件探し体験をつくる 顧客体験を重視した 既存の不動産サービスの評価軸は、 間取りや広さ、築年数などのスペックメイン。 物件の個性や、本当の価値 を伝え、 適切なマッチングを早期に実現 しています 出会う ｜ 　ツクルバの事業　 ｜
9. | 2026 | 2026 出会う 替える 売る 買う ｜ 　ツクルバの事業　 ｜ カウカモエージェントによる 最適な暮らしの提案 不動産の知識と、ライフスタイルへの こだわりを持つプロフェッショナルとしてお客様に寄り添い、 欲しい暮らしへとエスコートします。 独自開発システムを用い、お客さまにとって最適な物件を提供するのはもちろん、 リノベーションコーディネート、不動産売買取引等、 住宅購入における最適な体験を提供しています。
10. | 2026 | 2026 出会う 買う 売る 替える ｜ 　ツクルバの事業　 ｜ 誰もが理想の暮らしを手軽に手に入れるための リノベーションデザイン・カウカモ工務店 デザインはリノベーションチームが、専門知識を持って丁寧にサポート。 パッケージ商品からオーダーメイドまで、お客様が欲しい暮らしを叶えるために、 多様なリノベーションの選択肢を揃えています。 その後の施工フェーズはカウカモ工務店が担当。 より詳細な設計〜施工を、お客様に伴走しながらエスコート。 叶えたい暮らしを実現するまで、顧客体験を一気通貫で提供しています。
11. | 2026 | 2026 出会う 買う 替える 売る ｜ 　ツクルバの事業　 ｜ 売り出す前に買い手が見える CtoCプラットフォーム 売り出す前に買い手が見える、 売り出し前の住まいに出会える、 売主・買主がダイレクトにコミュニケーション 可能なプラットフォームを通じて、 物件の流通のさらに促進
12. | 2026 | 2026 出会う 買う 替える 売る つくる ｜ 　ツクルバの事業　 ｜ 顧客データをもとに 求められる物件を生み出す カウカモプラットフォームに集まったデータを活用し、 中古物件を自社で買い取り、世の中に求められる物件を生み出す。 カウカモユーザーにマッチした素敵な物件を供給し、 中古住宅の流通を促進。
13. 顧客ライフタイムに沿ったサービス展開 顧客ライフタイムに沿ったサービス展開イメージ リペア、リフォーム、生活サービス … 住替え 居住中～住替え検討 一次購入 ライフタイムでの顧客関係管理 流通データの統合管理 インターネット サービス リアル サービス デジタル 事業基盤 情報収集 リノベ カウカモ カウカモマガジン 家具・雑貨等 ウルカモ (売却検討者) ステージング 仲介(買) 仲介(買) (住替え支援) カウカモ (住替え⽀援) 共通ID / マイページ 仲介(売) ウルカモ (購⼊検討者) 金融関連サービス 現在の主なサービス 開発中のサービス 将来構想 ライフタイムに沿った拡張⽅向性 凡例：
14. エンジニア組織 (直近)
15. 購入側のWeb Frontend
16. • Rendering: RailsでSSR ◦ 型が存在しなくミスると、500エラーでページごと見れなくなる • Script: Reactなどのフレームワークなし ◦ erbに直書きor 一部のjQueryモジュール • Styling: SCSSで、Component分割もイマイチ ◦ 親が持つべきgapは、子のmarginやpaddingでLayout 入社時のWeb FE環境: ユーザー側
17. • Rendering: RailsでSSR • Script: Railsの上から重ねる ◦ ReactやReduxがあったり無かったり • Styling: 3つのオレオレデザインシステムが混合 • 自動テスト、Linterなどはほぼ機能していない。型無し。仕様は code 入社時のWeb FE環境: 管理画面側
18. • 入社前の業務経験 : 休学して1年エンジニア修行 してた(2020年頃) ◦ Vue.js + TypeScript + VRT(reg-suit) etc • モダン開発環境と比較すると、 あれもない、これもない。。。 • 研修終わって まもなく、WebFE正社員の先輩が退職 (11月) こういう状態のところに、新卒で入った
19. • 課題いっぱい だけど、WebFEの開発を自分で回さないと。。。 • この開発環境を変えてやりたい。。。 だけど、力が足りない。。。 ◦ 実行出来る専門性も経験も足りない。 • いつか経験豊富なエンジニアが来て、一緒 に刷新を進めてくれるだろう。 • そう思いながら、目の前の開発で精一杯 アーキテクチャ 変えたいけど。。。
20. • ユーザー側 ◦ Next.js/AppRouter、Panda CSS ◦ TS/Linter/Formatter/Test(Unit,Component,VRT,E2E) • 管理画面側 ◦ デザイントークンベースのデザインシステムで、 3種混在を統一する土台 ◦ etc 5年で、こう変わった ref: シニアフロントエンド採用要件
21. では、5年の中で、 何が起きたか
22. 入社してから、 リアーキテクトの壁にぶつかるまで
23. 研修で育ててもらい、出来る事が増えていった • いくつかの研修題材をもとに、進めながら Reviewを受ける日々 (2021/04~2021/11) ◦ 新卒エンジニアは3人目。WebFE初だったので、専用に作られた ◦ 可読性・パフォーマンス、技術的ないろんな意思決定など色々 • ユーザー側の機能開発 をこなし、社内の管理画面も 行っていく ※研修の詳細は今回は省略 🙏
24. 研修で育ててもらい、出来る事が増えていった
25. • ユーザー側も、管理画面側にも、課題や改善ネタは大量 ◦ ユーザー側: SEO、パフォーマンス、a11y ◦ 管理画面: 社内のユーザー に、直接ヒアリングして要望応える • やれることがいっぱい あって、楽しい。 ◦ 喜ばれるし、表彰もされる。 できることが増えると、改善ネタが無限に出てくる
26. • 自分のできることが増えると、改善ネタは増え続ける • 時間がいくらあっても足りない 少人数のチームに馴染んでくる とよくあるケース ……ただ、やれることが増えすぎて、困ってきた
27. • 細かい課題をこなす中で、ずっと頭の片隅にあったのが フロントエンドのリアー キテクチャ • これに取り組む中で、自分の 「時間の使い方」 を見直すきっかけに 頭の片隅にあったのは ...
28. リアーキテクチャ検証で 「時間の使い方」を変えた話 時間の使い方が、未来を決める
29. • ワークショップをやって、方向性は決定済み (with CTO,me,技術顧問) • 簡単に置き換えられそうなページで検証 →うまくいけば本番転用 • 自由に使える10%使える、「システム健全化枠」 を使ってちょっとずつ 次の壁 = リアーキ検証プロジェクト (2年目~) ref: 事業開発もシステム改善も諦めないために考えてきたこと by CTO
31. 中々進捗でず、はや 1年... やりたかったはずなのに、進まない。。。 • 新卒2~3年目、業務と並行 • Next.js未経験、React経験薄い etc • 技術顧問の手伝いもあるけど、主担当は自分
32. • 「システム健全化枠 」(10%)を使えていない。 ◦ 普段の事業開発遅れ調整などで消費 • 普段業務で、ついでに改善したくなる 、残業も常態化（10時間が普通に） ◦ 無理じゃなく、「ついでに改善 → 喜ばれる → やめられない」ループ に入っ ていた なぜ進まなかったか - 気がつくと、目の前の改善に時間を吸われていた
33. 学び 時間の使い方が、 未来を決める 自分しかいない専門性の場では、なおさら（ジュニア・ミドル・シニア関係なく )
34. • 1スプリント 10日のうち1日を「システム健全化デー」と決める • 細かいタスクで集中が壊れること減った アクション ① 丸1日、システム改善しかやらない日
35. • アーキ改善・自分の能力向上 の方が、組織・システムへの良い投資 • 業務外で集中して勉強・検証する余白 が出来る アクション ② あえて、残業を減らした
36. アクション ③ 週1の相談時間で「否応なく進める」 FE技術顧問と週1・30分のFE相談会 を設定 • 検証の 進捗を共有 → 否応なく前進せざるを得ない 構造 • 一人だと曖昧になりやすい部分が、説明する過程で言語化 されてクリ アに
37. 学び 時間の使い方が、 未来を決める
38. リアーキテクチャを、 本番に乗せていった話 理想を描いて、ついでに仕込む
39. ここからが、本当の山 本番アプリケーションに どう適用していくか
40. • PdM: 最初に乗せるPJ に初期 / 不確実工数が乗る。 • デザイナー : デザイントークン /システムを一緒に 作っていく必要性 • BE: Rails MVC → API 分離 + RSC向けにリソース指向 API必要 • インフラ: FEだけじゃカバーできない、BE協力依頼 大きい山 — 関係者ごとに、違う壁
41. 大きい山 — FEの開発にも、潰すべき不確実性
42. • 一人で全部はやれない。。。→ 関係者を巻き込もう • 余白では、限界 → 事業PJに載せよう • 事業ロードマップを見据えて、ピースを埋め込もう 一人じゃ崩せない。でも —
43. 学び 理想を描いて、 ついでに仕込む 関係者の課題と、自分の理想がマッチする場所に、ピースを段階的に埋め込む
44. 1. 管理画面 大規模 改修（2024春〜夏） — FE/Design課題解消 2. カウカモ JOURNAL（2024秋〜冬） — 新アーキProd検証 3. 新 cowcamo 基盤 PJ（2025年1月） — システム改善の年次起案 4. ユーザーレビューページ （2025年2-3月） — 新基盤を使って実装 4つの事例を時系列で
45. • デザインと FE 間に課題 が見えていた ◦ ユーザー側: iOS 先行で ネイティブ DesignToken が Web にコピペで混入 ◦ 管理画面側: 3つのオレオレ DesignSystem を跨ぐ大改修 が控えていた • 見立て: デザイントークンベース で整えれば、両方ハマりそう 事例 1 / 管理画面 大規模 改修（2024春〜夏） — 課題 ref: 別のプロジェクトのDesign Tokensが交じることで、開発メンバーに混乱とコストをもたらす by me
46. 事例 1 / 認識合わせ — Slack / 隔週MTG etc ref: 別のプロジェクトのDesign Tokensが交じることで、開発メンバーに混乱とコストをもたらす by me • ユーザー側の開発で起きていた課題感を共有 ◦ DesignToken の認識すり合わせ を開始 • Design System Slack ch を新設: 記事や本を流して相互学習 • 2週間に 1回 MTG: 自分たちが作りたいものを 言語化
47. 事例 1 / 認識合わせ — Slack / 隔週MTG etc
48. 事例 1 / 提案 → 合意 → ついでに仕込む • 3DesignSystem を無理改修 vs 1つの新 DesignTokenを各 DS から利用 ◦ 見積もりに Design Token揃える分を込みで入れる • デザイナー: 管理画面の新 DT を使ったデザイン作成 • その流れで: Web FE 全体の DT 定義も ついでに仕込む（意図的） ref: 社内管理ツールのカオスなデザインシステムをデザイントークンで統一by me
49. Adminデザインシステム COUCHのStyling
51. • カウカモの新メディア `/journal` プロジェクトが立ち上がる ◦ このパス以下は 新しいアプリケーションで立ち上げ可能 な独立性 • リアーキ検証は 一定試せていた（途中） ◦ 新アーキで完成させていくのに、ちょうどいい場所 事例 2 / カウカモ JOURNAL（2024秋〜冬）
52. • 古いアーキ vs 新アーキの見積もりとメリデメを PDMに提案 ◦ 工数を並べた上で、新アーキで行きたい意思を明示 → 合意取得 • ついでにBEに仕込んだもの: ◦ RSC / リソース指向 API の説明、お願い ◦ インフラ面の協力依頼 （新アプリ用のホスティング・デプロイ） 事例 2 / 見積もり比較で新アーキで進める方向に
53. 事例 2 / 見積もり比較で新アーキで進める方向に
54. 事例 2 / 見積もり比較で新アーキで進める方向に
55. • 年次起案で FY25 予算を事前確保 • JOURNAL とcowcamo を モノレポ化 • ついでにTestも基盤に組み込み (Unit,component,VRT) 事例 3 / 新 cowcamo 基盤 PJ（2025年1月） — 年次起案で事前に仕込む
56. • 事例3 の新基盤を使った最初の実装が ユーザーレビューページ • cowcamoにおいて、一部の pathから段階的に置き換えられる事例作成 • ここからは、新基盤に乗せながら、次の機能を作っていくサイクルへ 事例 4 / 新基盤で実装（ 2025年2-3月）
57. 山が崩れた — 4つの事例で、ピースが揃う • 検証で不確実性が減り、ピースが見え てきた • 大きい事業 PJ の中に、ちょうどいい仕込み場所 があった • 関係者を巻き込 めばピースは動く
58. なぜ、ピースに気づけたか
59. 学び 理想を描いて、 ついでに仕込む 理想を言語化して、みんなの課題と紐づけて巻き込んで進める
60. まとめ
61. ２つの学び 1. 時間の使い方が、未来を決める 2. 理想を描いて、ついでに仕込む 2つのコアコンセプトを、もう一度
62. • React Tokyoフェスのフィッシュボウル ◦ 雑談: フロントエンドの大きい課題にどう向き合うか？ • 自分でやっていく覚悟 ◦ 自分の時間の使い方を選ぶ ◦ 理想を描いて、仕込んで、実行する 振り返ると、これは「覚悟」の話だった
63. 「いつか誰かが」と思っている、あなたへ あなた自身が、 その「誰かに」になれる 一人 / 少人数フロントエンドの仲間として
64. いつか誰かが、と思っていた フロントエンド刷新 5年間の実践知 kii/@kiichi_sugihara 2026-05-09 フロントエンドカンファレンス名古屋 2026