フロントエンド刷新 4年間の軌跡

Retrospective Decision - LayerX Web Frontend Night
https://layerx.connpass.com/event/383492/

Transcript

1. フロントエンド刷新 4年間の軌跡 2026/03/17 LayerX Web Frontend Night
2. nus3（なすさん）
3. 今日のテーマは Retrospective Decision 技術的な意思決定が今どうなってるのかを、ふりかえる会
4. ヘイシャ、kintoneでは 2021年末から本格的に フロントエンドの刷新に
 取組んでいる
5. フロントエンド刷新を始めて ぼちぼち4年 はやい..はやいでヤンス
6. この取組に参加していた
 ひとりとして
7. kintoneの フロントエンド刷新 をふりかえる
8. フロントエンド刷新 について
9. フロントエンド刷新について 1チームのみで局所的に行なっていたフロントエンド
 刷新を2021年末にプロジェクト化 フロントエンドリアーキテクトプロジェクト 通称フロリア プロジェクト初期は20人ぐらいが選任で
 本格的にフロントエンド刷新を進める 合わせてデザインシステムの構築も始まる 時を同じくしてnus3がサイボウズに入社
10. フロリアについて プロジェクトメンバーの有志によって作られたフロリアのロゴ
11. フロリアが目指したもの kintoneのフロントエンドを持続可能な状態 品質を保ったまま開発を加速し、スケールしやすい
 フロントエンド基盤を作る
12. 具体的には 全てのページをClosureからReact へ フロントエンドを巨大なモノリスから
 領域（チーム）ごとに分割
13. 巨大なコードベースを領域ごとに分割 同一リポジトリ内のfrontendディレクトリ配下に
 領域（チーム）単位ごとのディレクトリ それぞれの単位でmonorepoを構成
14. フロリアで取り組んだことが どうなったかを れとろすぺくてぃぶ していく カットしていくぅ
15. いくつかの領域で刷新が進む 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に刷新した領域もある
16. フロントエンド刷新の進捗は 画面数ベースでいうと リリースしたものが50% 進行中のものが20% 未着手のものが30% 進行中、未着手の画面に関しては刷新後の移行難易度も
 踏まえると、いくつか壁は残っている
17. フロリアはどうなったのか
18. プロジェクトからkintone開発全体へ 現在では、フロリアでの事例をkintone開発全体へ広げ、
 残りの領域の刷新を完了させることを目指している フロリアに参加していたメンバーが、各開発チームに入り
 そのチームの一員となって、フロントエンド刷新を進める この体制になったことで、フロリアプロジェクトは終了
19. フロントエンド刷新の nus3のふりかえり 主観でヤンス
20. スケールしやすいフロントエンド基盤に 領域（チーム）ごとにフロントエンドを分割することで
 影響範囲が明確になった 認知不可、学習コストは下がった チームに入ってからすぐ開発できるように 横断的な支援もやりやすくなった チームごとにオーナーシップを持った技術選定
 ライブラリのアップデートが可能に 最初は3つだったチームのディレクトリは9つに
21. チーム間のフロントエンド連携 良い点 privateなnpmパッケージ iframeでの提供 例) ダッシュボード画面で、別領域のウィジェット表示 チームの資産（ロジックやUIコンポーネント）は
 自チームで管理 課題点 要件によっては、チーム内のディレクトリに
 別チームが実装を追加するケースも
22. 現状のmonorepo構成の良い点 チーム間で共通で使いたいものを、
 npmパッケージとして切りやすい monorepo自体はチーム単位で独立
 しているので、他チームの影響を受けない
23. 現状のmonorepo構成のこれから npmパッケージとして切りやすいが故に 明確なオーナー決めないまま、npmパッケージとして
 共通化することで、うまく運用できていないケースも 安易な共通化を生みやすい そもそも共通化をするかどうかは各チームの判断に
 委ねられている 横断で重複を許容すべきか、共通化すべきかの
 基準を決めきれてはいない
24. 現状のmonorepo構成のこれから チーム体制の変更に合わせた仕組みが整えられていない team-bがteam-xとteam-yに分裂
 した時どうする？
25. 現状のmonorepo構成のこれから 個々のチームでの開発には問題ないが、全チームの
 依存関係の解決とビルドを一気にやると時間がかかる
26. 現状のmonorepo構成のこれから ディレクトリ名はチーム名でよかったのか？ オーナーはコード上ではっきりとわかるが 領域名の方が変更頻度は低くないか？
27. フロントエンド刷新 全体を通して
28. フロントエンド刷新 全体を通して プロジェクトとして覚悟を持って進めることで、
 結果としてkintone開発全体で進める体制に広がった 社内全体が刷新するという同じ方向を向けた デザインシステムの成長によって、kintoneに求められる
 デザインやアクセシビリティの品質を保った上で
 新しい画面の開発速度はぐんと上がった フロントエンドが好きな新しいメンバー、既存のメンバー の両方がイキイキと活躍できる場が増えた

29. フロントエンド刷新 全体を通して 刷新をプロジェクトとして本格的にはじめて、
 4年というのは長い ただ、kintoneの規模で、新機能開発と共に着実に
 進められているとも思ってる 完了するために、もう一踏ん張りする必要がある フロントエンド刷新が終わって、ようやくスタートラインよ
 って最近Bossにも言われたらしいでヤンス
30. さいごに
31. このフロントエンド刷新は、尊敬する先人たちが作り、
 切り拓いてきたことです 自分は、その内容に共感し、乗っかり、
 ただ踊り続けてただけの人です フロントエンド刷新完了まで、 いいところまできたと思っているので もうちっとだけ続くんじゃ、してます
32. 付録 当時の資料や、聞いた話を興じてまとめてしまったスライドたち フロントエンド刷新に至るまでをnus3視点でまとめてるでヤンス
33. kintoneについて
34. kintoneについて 2011年11月に提供開始 https://cybozu.co.jp/company/history/ nus3は、まだ1x歳の時の話だったらしいでヤンス
35. 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/
36. kintoneの フロントエンドについて ここら辺の話は社内の伝聞の伝聞の伝聞でヤンス。もはや言い伝え
37. ※kintone開発初期の2010年頃、会場にいる人たちは何をしていたのか聞こうとしていたスライド 2010年って、みなさんは 何してました？ nus3は北海道という最北の地で農業・畜産・キノコの勉強してたらしいでヤンス
38. 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/
39. kintoneのフロントエンドについて 現在の主要なブラウザのバージョンが軒並み1桁台だった
 2010年 kintoneでは大規模になるフロントエンドを見据えて
 Google Closure Tools を採用
40. Google Closure Toolsとは Googleが提供するJavaScriptツール群 Closure Library（UIライブラリ）は
 当時、Googleが開発する大規模プロダクトに採用 https://www.slideshare.net/slideshow/latest-closurecompiler/35613158
41. Google Closure Toolsとは Closure Compiler: コンパイラー（minify） Closure Library : UIライブラリ IEなどブラウザ間の挙動の差異をカバー モジュールシステム Closure Linter JSDocによる型チェック Closure Templates: テンプレートエンジン Closure Stylesheets SassのようなCSSの拡張
42. おそらく順調に続いていた フロントエンド開発だったが、 2015年あたりから 徐々に変化が...
43. 2015年あたりのフロントエンド UIライブラリとしてReactやVue altJSとしてTypeScript バンドラーとしてwebpack などが徐々に台頭するように 2010年と比べ、npmを中心とするエコシステムが発達 nus3が社会人1年目で畑で土掘ってた時代らしいでヤンス
44. kintone内で高まる刷新の機運 2010年当初は画期的だったClosure Toolsも フロントエンドの大きな変化に合わせて、
 フロントエンド刷新の機運がkintone内で高まる コンポーネントを用いた宣言的UI開発との乖離 Closure Toolsの採用事例の少なさ Closure Toolsのアップデートコストの増加
45. kintone内で高まる刷新の機運 このままClosure Toolsを使い続けることが
 人材の採用、学習コスト、メンテナンス性からも
 継続したプロダクト開発を妨げそう
46. Closure→Reactの草の根活動も https://www.slideshare.net/slideshow/google-closure-toolsreact/52541839
47. 2019年に1チームが特定領域を Closure → Reactへ フロントエンド刷新が開始
48. フロントエンド刷新は 始まったんだけども...
49. 苦戦するフロントエンド刷新 2021年にはJSはおよそ50万行程度あるぐらいの規模 長年続いた開発で、既存実装を把握しつつ行う刷新は
 1チームではなかなか進まず Closure→Reactへは、並行して
 影響範囲が大きい、技術的に難易度が高いものの
 検討も必要 https://cybozu.dev/ja/kintone/getting-started/what-is-kintone-customize/
50. どげんかせんといかん 明星 チャルメラ 宮崎辛麺、辛いけど美味しいでヤンス
51. 2021年末に 局所的に行なっていた フロントエンド刷新を プロジェクト化 ここから冒頭のフロントエンド刷新のスライドに話がつながるでヤンス
52. フロリアについて フロリアがどのような思いで作られたかは、 こちらのスライドもぜひ見てください https://speakerdeck.com/koba04/kintonehurontoentoshua-xin-niyorumofalserisukarafalsetuo-que-tosofalsexian-nimu-zhi-suwei-lai
53. 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