Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
フロントエンド刷新 4年間の軌跡
Search
nus3
March 16, 2026
Technology
0
140
フロントエンド刷新 4年間の軌跡
Retrospective Decision - LayerX Web Frontend Night
https://layerx.connpass.com/event/383492/
nus3
March 16, 2026
Tweet
Share
More Decks by nus3
See All by nus3
WebDriver BiDi 2025年のふりかえり
yotahada3
1
660
Playwrightはどのようにクロスブラウザをサポートしているのか
yotahada3
8
2.8k
DenoでOpenTelemetryに入門する
yotahada3
2
600
WebDriver BiDiとは何なのか
yotahada3
1
950
コンポーネントテストの手法と その効果を考える
yotahada3
8
1.9k
フロントエンドクイズ大会
yotahada3
0
150
Node.jsのWorker threadsの話
yotahada3
1
1.5k
ワタシとPodcast
yotahada3
2
2k
Do you like Storybook?
yotahada3
2
4.6k
Other Decks in Technology
See All in Technology
OSC仙台プレ勉強会 AlmaLinuxとは
koedoyoshida
0
160
DevOpsエージェントで実現する!! AWS Well-Architected(W-A) を実現するシステム設計 / 20260307 Masaki Okuda
shift_evolve
PRO
3
750
[JAWS DAYS 2026]私の AWS DevOps Agent 推しポイント
furuton
0
150
脳内メモリ、思ったより揮発性だった
koutorino
0
350
[JAWSDAYS2026][D8]その起票、愛が足りてますか?AWSサポートを味方につける、技術的「ラブレター」の書き方
hirosys_
3
180
Shifting from MCP to Skills / ベストプラクティスの変遷を辿る
yamanoku
4
840
プラットフォームエンジニアリングはAI時代の開発者をどう救うのか
jacopen
1
280
JAWS DAYS 2026 ExaWizards_20260307
exawizards
0
430
わからなくて良いなら、わからなきゃだめなの?
kotaoue
1
340
AI時代の「本当の」ハイブリッドクラウド — エージェントが実現した、あの頃の夢
ebibibi
0
120
社内レビューは機能しているのか
matsuba
0
120
Scrumは歪む — 組織設計の原理原則
dashi
0
170
Featured
See All Featured
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.6k
Neural Spatial Audio Processing for Sound Field Analysis and Control
skoyamalab
0
210
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8.9k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
240
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
How Software Deployment tools have changed in the past 20 years
geshan
0
32k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
0
230
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
10
1.1k
Balancing Empowerment & Direction
lara
5
940
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
118
110k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
199
73k
Transcript
フロントエンド刷新 4年間の軌跡 2026/03/17 LayerX Web Frontend Night
nus3(なすさん)
今日のテーマは Retrospective Decision 技術的な意思決定が今どうなってるのかを、ふりかえる会
ヘイシャ、kintoneでは 2021年末から本格的に フロントエンドの刷新に 取組んでいる
フロントエンド刷新を始めて ぼちぼち4年 はやい..はやいでヤンス
この取組に参加していた ひとりとして
kintoneの フロントエンド刷新 をふりかえる
フロントエンド刷新 について
フロントエンド刷新について 1チームのみで局所的に行なっていたフロントエンド 刷新を2021年末にプロジェクト化 フロントエンドリアーキテクトプロジェクト 通称フロリア プロジェクト初期は20人ぐらいが選任で 本格的にフロントエンド刷新を進める 合わせてデザインシステムの構築も始まる 時を同じくしてnus3がサイボウズに入社
フロリアについて プロジェクトメンバーの有志によって作られたフロリアのロゴ
フロリアが目指したもの kintoneのフロントエンドを持続可能な状態 品質を保ったまま開発を加速し、スケールしやすい フロントエンド基盤を作る
具体的には 全てのページをClosureからReact へ フロントエンドを巨大なモノリスから 領域(チーム)ごとに分割
巨大なコードベースを領域ごとに分割 同一リポジトリ内のfrontendディレクトリ配下に 領域(チーム)単位ごとのディレクトリ それぞれの単位でmonorepoを構成
フロリアで取り組んだことが どうなったかを れとろすぺくてぃぶ していく カットしていくぅ
いくつかの領域で刷新が進む https://jp.kintone.help/k/ja/update/main/2023-02 https://jp.kintone.help/k/ja/update/main/2023-02 https://jp.kintone.help/k/ja/update/main/2023-05 既存仕様を変えないことで、リリースノートに載せずにClosure→Reactに刷新した領域もある
フロントエンド刷新の進捗は 画面数ベースでいうと リリースしたものが50% 進行中のものが20% 未着手のものが30% 進行中、未着手の画面に関しては刷新後の移行難易度も 踏まえると、いくつか壁は残っている
フロリアはどうなったのか
プロジェクトからkintone開発全体へ 現在では、フロリアでの事例をkintone開発全体へ広げ、 残りの領域の刷新を完了させることを目指している フロリアに参加していたメンバーが、各開発チームに入り そのチームの一員となって、フロントエンド刷新を進める この体制になったことで、フロリアプロジェクトは終了
フロントエンド刷新の nus3のふりかえり 主観でヤンス
スケールしやすいフロントエンド基盤に 領域(チーム)ごとにフロントエンドを分割することで 影響範囲が明確になった 認知不可、学習コストは下がった チームに入ってからすぐ開発できるように 横断的な支援もやりやすくなった チームごとにオーナーシップを持った技術選定 ライブラリのアップデートが可能に 最初は3つだったチームのディレクトリは9つに
チーム間のフロントエンド連携 良い点 privateなnpmパッケージ iframeでの提供 例) ダッシュボード画面で、別領域のウィジェット表示 チームの資産(ロジックやUIコンポーネント)は 自チームで管理 課題点 要件によっては、チーム内のディレクトリに
別チームが実装を追加するケースも
現状のmonorepo構成の良い点 チーム間で共通で使いたいものを、 npmパッケージとして切りやすい monorepo自体はチーム単位で独立 しているので、他チームの影響を受けない
現状のmonorepo構成のこれから npmパッケージとして切りやすいが故に 明確なオーナー決めないまま、npmパッケージとして 共通化することで、うまく運用できていないケースも 安易な共通化を生みやすい そもそも共通化をするかどうかは各チームの判断に 委ねられている 横断で重複を許容すべきか、共通化すべきかの 基準を決めきれてはいない
現状のmonorepo構成のこれから チーム体制の変更に合わせた仕組みが整えられていない team-bがteam-xとteam-yに分裂 した時どうする?
現状のmonorepo構成のこれから 個々のチームでの開発には問題ないが、全チームの 依存関係の解決とビルドを一気にやると時間がかかる
現状のmonorepo構成のこれから ディレクトリ名はチーム名でよかったのか? オーナーはコード上ではっきりとわかるが 領域名の方が変更頻度は低くないか?
フロントエンド刷新 全体を通して
フロントエンド刷新 全体を通して プロジェクトとして覚悟を持って進めることで、 結果としてkintone開発全体で進める体制に広がった 社内全体が刷新するという同じ方向を向けた デザインシステムの成長によって、kintoneに求められる デザインやアクセシビリティの品質を保った上で 新しい画面の開発速度はぐんと上がった フロントエンドが好きな新しいメンバー、既存のメンバー の両方がイキイキと活躍できる場が増えた
フロントエンド刷新 全体を通して 刷新をプロジェクトとして本格的にはじめて、 4年というのは長い ただ、kintoneの規模で、新機能開発と共に着実に 進められているとも思ってる 完了するために、もう一踏ん張りする必要がある フロントエンド刷新が終わって、ようやくスタートラインよ って最近Bossにも言われたらしいでヤンス
さいごに
このフロントエンド刷新は、尊敬する先人たちが作り、 切り拓いてきたことです 自分は、その内容に共感し、乗っかり、 ただ踊り続けてただけの人です フロントエンド刷新完了まで、 いいところまできたと思っているので もうちっとだけ続くんじゃ、してます
付録 当時の資料や、聞いた話を興じてまとめてしまったスライドたち フロントエンド刷新に至るまでをnus3視点でまとめてるでヤンス
kintoneについて
kintoneについて 2011年11月に提供開始 https://cybozu.co.jp/company/history/ nus3は、まだ1x歳の時の話だったらしいでヤンス
kintoneについて 国内外40,000社以上に導入 オフィシャルパートナーは500社以上 連携サービスは400以上 https://www.docswell.com/s/cybozu-tech/5LV7G7-kintone-product-engineer-information#p11 https://cybozu.dev/ja/kintone/getting-started/what-is-kintone-customize/
kintoneの フロントエンドについて ここら辺の話は社内の伝聞の伝聞の伝聞でヤンス。もはや言い伝え
※kintone開発初期の2010年頃、会場にいる人たちは何をしていたのか聞こうとしていたスライド 2010年って、みなさんは 何してました? nus3は北海道という最北の地で農業・畜産・キノコの勉強してたらしいでヤンス
https://website-archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-us/firefox/3.6/releasenotes/ Firefoxはv3.6 (今はv148) kintoneを開発当初 おそらく2010年には開発を開始していたはず.. 2010年の主要ブラウザのバージョンは https://en.wikipedia.org/wiki/Internet_Explorer_version_history IEは2009年にv8(今はサポート終了) https://chromereleases.googleblog.com/2010/01/stable-channel-update_25.html Chromeはv4
(今はv145) Safariはv5(今はv26、v26の前はv18) https://www.apple.com/jp/newsroom/2010/06/07Apple-Releases-Safari-5/
kintoneのフロントエンドについて 現在の主要なブラウザのバージョンが軒並み1桁台だった 2010年 kintoneでは大規模になるフロントエンドを見据えて Google Closure Tools を採用
Google Closure Toolsとは Googleが提供するJavaScriptツール群 Closure Library(UIライブラリ)は 当時、Googleが開発する大規模プロダクトに採用 https://www.slideshare.net/slideshow/latest-closurecompiler/35613158
Google Closure Toolsとは Closure Compiler: コンパイラー(minify) Closure Library : UIライブラリ
IEなどブラウザ間の挙動の差異をカバー モジュールシステム Closure Linter JSDocによる型チェック Closure Templates: テンプレートエンジン Closure Stylesheets SassのようなCSSの拡張
おそらく順調に続いていた フロントエンド開発だったが、 2015年あたりから 徐々に変化が...
2015年あたりのフロントエンド UIライブラリとしてReactやVue altJSとしてTypeScript バンドラーとしてwebpack などが徐々に台頭するように 2010年と比べ、npmを中心とするエコシステムが発達 nus3が社会人1年目で畑で土掘ってた時代らしいでヤンス
kintone内で高まる刷新の機運 2010年当初は画期的だったClosure Toolsも フロントエンドの大きな変化に合わせて、 フロントエンド刷新の機運がkintone内で高まる コンポーネントを用いた宣言的UI開発との乖離 Closure Toolsの採用事例の少なさ Closure Toolsのアップデートコストの増加
kintone内で高まる刷新の機運 このままClosure Toolsを使い続けることが 人材の採用、学習コスト、メンテナンス性からも 継続したプロダクト開発を妨げそう
Closure→Reactの草の根活動も https://www.slideshare.net/slideshow/google-closure-toolsreact/52541839
2019年に1チームが特定領域を Closure → Reactへ フロントエンド刷新が開始
フロントエンド刷新は 始まったんだけども...
苦戦するフロントエンド刷新 2021年にはJSはおよそ50万行程度あるぐらいの規模 長年続いた開発で、既存実装を把握しつつ行う刷新は 1チームではなかなか進まず Closure→Reactへは、並行して 影響範囲が大きい、技術的に難易度が高いものの 検討も必要 https://cybozu.dev/ja/kintone/getting-started/what-is-kintone-customize/
どげんかせんといかん 明星 チャルメラ 宮崎辛麺、辛いけど美味しいでヤンス
2021年末に 局所的に行なっていた フロントエンド刷新を プロジェクト化 ここから冒頭のフロントエンド刷新のスライドに話がつながるでヤンス
フロリアについて フロリアがどのような思いで作られたかは、 こちらのスライドもぜひ見てください https://speakerdeck.com/koba04/kintonehurontoentoshua-xin-niyorumofalserisukarafalsetuo-que-tosofalsexian-nimu-zhi-suwei-lai
Closure Libraryはメンテナンスモードに 以下内容を抜粋 Closure Libraryが公開されて14年 当初はIE8が登場したばかりで 多くのブラウザ間の挙動の際を Closure Libraryが吸収していた 当時は画期的だったが今では時代遅れに
依存関係にはCJS・ESM TypeScriptによる型システム ブラウザ間の挙動差異も大幅に抑制 the world has moved on and we believe it no longer needs Closure Library. https://github.com/google/closure-library/issues/1214