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
kintoneフロントエンド刷新によるモノリスからの脱却とその先に目指す未来
Search
koba04
October 20, 2021
Technology
3
15k
kintoneフロントエンド刷新によるモノリスからの脱却とその先に目指す未来
https://cybozu.connpass.com/event/227770/
の発表資料です。
koba04
October 20, 2021
Tweet
Share
More Decks by koba04
See All by koba04
フロントエンドの現在地とこれから
koba04
10
5k
Standing on the shoulders of giants
koba04
0
2.7k
React/Next によるアプリケーション開発のこれから
koba04
61
17k
フロントエンド刷新をプロジェクトとして進める際に気をつけていること
koba04
3
1.8k
How useEvent would change our applications
koba04
1
3k
Make it Declarative with React
koba04
0
1.6k
Ready for React in 2019
koba04
2
1.6k
Algorithms in React
koba04
14
16k
Suspense and TimeSlicing
koba04
0
250
Other Decks in Technology
See All in Technology
Agentic RAG with LangGraph
atsushii
0
120
サイボウズフロントエンドエキスパートチームについて / FrontendExpert Team
cybozuinsideout
PRO
5
39k
2024年にチャレンジしたことを振り返るぞ
mitchan
0
170
[トレノケ雲の会 mod.13] 3回目のre:Inventで気づいたこと -CloudOperationsを添えて-
shintaro_fukatsu
0
120
能動的ドメイン名ライフサイクル管理のすゝめ / Practice on Active Domain Name Lifecycle Management
nttcom
0
310
UI State設計とテスト方針
rmakiyama
4
940
スケールし続ける事業とサービスを支える組織とアーキテクチャの生き残り戦略 / The survival strategy for Money Forward’s engineering.
moneyforward
0
220
Zero Data Loss Autonomous Recovery Service サービス概要
oracle4engineer
PRO
1
4.9k
開発生産性向上! 育成を「改善」と捉えるエンジニア育成戦略
shoota
2
820
20240522 - 躍遷創作理念 @ PicCollage Workshop
dpys
0
300
MasterMemory v3 最速確認会
yucchiy
0
300
PHPerのための計算量入門/Complexity101 for PHPer
hanhan1978
6
1.5k
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
29
940
It's Worth the Effort
3n
183
28k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Rails Girls Zürich Keynote
gr2m
94
13k
Adopting Sorbet at Scale
ufuk
74
9.1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
365
25k
Building Better People: How to give real-time feedback that sticks.
wjessup
366
19k
RailsConf 2023
tenderlove
29
960
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
44
9.3k
Fireside Chat
paigeccino
34
3.1k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
The Cost Of JavaScript in 2023
addyosmani
46
7.1k
Transcript
kintone フロントエンド刷新による モノリスからの脱却とその先に⽬指す未来 kintone 開発チーム @koba04
📝Agenda ▌フロントエンド刷新プロジェクトについて ▌なぜ刷新を⾏うのか ▌⽬指している姿 ▌現状、今後について
✋⼩林 徹 (@koba04) 2017/10~ サイボウズに中途⼊社。フロントエンドエキスパートチーム⽴ち上げ のメンバーとしてプロダクト横断でフロントエンドの改善活動を⾏う 2021/09~ 刷新プロジェクトを成功させるため、フロントエンドエキスパートチー ムを離れ、kintone チームに所属
kintone
kintone サイボウズ エンジニア採⽤ピッチ: https://speakerdeck.com/cybozuinsideout/cybozu-engineer-recruit?slide=7
kintone サイボウズ エンジニア採⽤ピッチ: https://speakerdeck.com/cybozuinsideout/cybozu-engineer-recruit?slide=12
kintone サイボウズ エンジニア採⽤ピッチ: https://speakerdeck.com/cybozuinsideout/cybozu-engineer-recruit?slide=13
🚀フロントエンド刷新プロジェクトについて
🚀フロントエンド刷新プロジェクトについて ▌詳しくは下記の Cybozu Meetup の発表をご覧ください🙏 https://www.youtube.com/watch?v=Zx8ejZJ-U9c https://speakerdeck.com/kuroppe1819/kintonefalsehurontoendoshua-xin-nixiang-ketaqu-rizu-mi
🤔なぜ刷新を⾏うのか
🤔なぜ刷新を⾏うのか ▌Closure やめて React などのモダンな技術で開発できるようにすること で開発速度を加速させるため︖ n → Yes であり
No。ただ置き換えるだけでは将来的に同じ問題が発 ⽣し、脱 React をやることになる ▌メンテナンスが難しいコードを1から書き直すことでスッキリさせたい︖ n → No。これだけであれば、⼤規模にやっていく必要はない ▌最⾼のアーキテクチャを作りあげる n → No。銀の弾丸はない
🏹⽬指している姿
✨フロントエンドに Autonomy をもたらす Autonomy: ⾃治(権)、⾃主性、⾃治団体 weblioより引⽤: https://ejje.weblio.jp/content/autonomy
✨Autonomy ▌⾃律可能なチーム、オーナーシップ ▌変化・挑戦を可能に
🐥⾃律可能なチーム、オーナーシップ ▌現状はアプリケーションに境界がなく、判断が全体に及ぶ n コストやリスクが⾼く、誰もそんな判断はやりたくない ▌チーム、アプリケーション単位で分割し影響範囲で明確に n チームの中で意思決定可能な状態にする n チームの中に決断するために必要な⼈がいる状態を⽬指す
🐥⾃律可能なチーム、オーナーシップ ▌チームを超えた Contribution n ⾃律 ≠ サイロ化 n チームは Contribution
を受け⼊れられる体制を整備する必要があ る n チームを超えたコミュニケーションを推奨する⽂化づくり n 社内だけでなく社外に対してもオープンに 今回で最もチャレンジングな部分の⼀つ
🏋変化・挑戦を可能に ▌挑戦のハードルを下げる、リカバリ可能な失敗を増やす ▌我々は失敗する、挑戦しないと失敗しない ▌Web は変化を続けるプラットフォーム ▌最適解は常に変化する
🏋挑戦のハードルを下げる、リカバリ可能な失敗を増やす ▌決定に対するスコープを⼩さくし、チームで完結できる体制にすることで挑 戦するためのハードルを下げる ▌決断する機会は増える。ADR (Architecture Desicion Records) により決断を記録・共有する
🤸我々は失敗する、挑戦しないと失敗しない ▌影響範囲を⼩さくすることで、失敗した場合の影響範囲も⼩さくなり、リ カバリも可能になる n ⻑期にわたって正しいと⾔える選択をすることは難しい n 短期的には正しかった選択が後々の状況の変化で最適ではなかった ということも起こる ▌失敗という経験はチームにとって貴重な経験であり、多くの⼈の糧になる n
参考: 我々はいかにして技術選択を間違えたのか︖ 2016 - Cybozu Inside Out | サイボウ ズエンジニアのブログ
🌏Web は変化を続けるプラットフォーム ▌⾃分たちは変わらなくても、周りの状況は変化し続ける n Cookie の SameSite=Lax, UserAgent, Referrer-Policy n
Service Workers, Web Components n SPA, SSR, Dark Theme ▌それに伴いユーザーの体験は変化を続けており、変化に対応できる状態 にすることは必須 n 変わらない ≠ 利⽤者のユーザー体験が変わらない
⏳最適解は常に変化する ▌プロダクトやチームも変化していく。そのため、最適な状態も変化していく ▌最適なチームの単位や責務も変化していく n チームの単位や責任範囲も柔軟に定義できることで常に最適な状態 を⽬指せるようにする n → チーム単位での Monorepo
構成
❓FAQ
各チームが⾃由に作るということで、プロダクトにおいて ⼀貫性を保つことが難しくなりませんか︖
🥷横断的な関⼼毎に対してオーナーシップを持つチーム ▌チーム・アプリケーション横断の関⼼毎は存在するため、そのためのチーム を作る n ユーザー体験を最⾼にするチーム n ⾃律的な開発を実現するためのプラットフォームを作るチーム ▌これらのチームとアプリケーション開発チームは、相互に Contribution を⾏う必要がある
各チームが⾃由に作るということで、同じようなことを各 チームが実装することになりませんか︖
🔨本質的に必要のない DRY は避ける ▌コードの共有は結合度を⾼め凝集度を下げる ▌オーナーシップのないコード共有はメリットよりデメリットを上回る。実装が 同じだからとなんでも共有せずに慎重に検討する
各チームは React を使わないとダメなのですか︖
🏆ベストプラクティスの提供 ▌技術選択に制限を加えることは⾃律的な技術選択を阻害しているが、 これはコストや品質に対するトレードオフであると考えている ▌現時点での判断として React をベースにすることは上記のトレードオフを 踏まえて妥当であると考えている ▌ただし、⾃分たちで全てやるということで特定部分のみ React を使わな
いという判断をすることは可能
作り直しって避けたほうがいいのでは︖
🍱段階的な置き換え ▌作り直しは可能な限り避けるべき ▌プロジェクトとしては全体を置き換えることを⽬的にしているが、プロセスと しては可能な限り⼩さく取り組み、初回以降のリリースは可能な限り⼩さ な単位にする予定 ▌Closure → React はパラダイムの変化が⼤きいため再利⽤できる部 分が少ない
n 参考: Google Closure Toolsで作った⼤規模サービスにReactを導⼊した話
🌱現状、今後について
🏃現状
🏃現状 ▌刷新プロジェクトの前⾝として取り組んでいた部分のリリースを⽬指す ▌React に向けた技術的な調査 ▌アプリケーション分割のための基盤作り ▌刷新プロジェクトのスコープ、スケジュールの作成 ▌横断チームを作るための準備
⛰課題
⛰課題 ▌複数チームが効率的に開発するための基盤 ▌チーム間での Contribution を促す仕組み、⽂化づくり ▌カスタマイズに対する対応 ▌刷新後のチーム体制 ▌and more...
🤔なぜ刷新を⾏うのか
🤝Autonomy ▌メンバー、チームがオーナーシップをもってプロダクトに取り組む⼟壌 ▌ベストな形を求めて変化を恐れないチーム ▌社内外に対してオープンであり、必要な⼈を巻き込める
🎬最後に⼤事なこと
🙇この挑戦を⼀緒にやりたい⼈を募集しています︕︕︕ ▌絶賛募集中です︕ n フロントエンドエンジニア(kintoneアーキテクチャ刷新PJ) ▌もう少し話を聞いてみたいという場合は Meety で ✋ n サイボウズのフロントエンド、チーム、働き⽅についてなどなんでも