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
5.2k
Standing on the shoulders of giants
koba04
0
2.8k
React/Next によるアプリケーション開発のこれから
koba04
61
17k
フロントエンド刷新をプロジェクトとして進める際に気をつけていること
koba04
3
1.9k
How useEvent would change our applications
koba04
1
3k
Make it Declarative with React
koba04
0
1.7k
Ready for React in 2019
koba04
2
1.7k
Algorithms in React
koba04
14
17k
Suspense and TimeSlicing
koba04
0
270
Other Decks in Technology
See All in Technology
クラウドネイティブ環境の脅威モデリング
kyohmizu
2
400
Azure × MCP 入門
ry0y4n
8
1.6k
Next.jsと状態管理のプラクティス
uhyo
3
1.4k
データベース04: SQL (1/3) 単純質問 & 集約演算
trycycle
PRO
0
730
コードや知識を組み込む / Incorporating Codes and Knowledge
ks91
PRO
0
170
本当に必要なのは「QAという技術」だった!試行錯誤から生まれた、品質とデリバリーの両取りアプローチ / Turns Out, "QA as a Discipline" Was the Key!
ar_tama
9
4.1k
Part2 GitHub Copilotってなんだろう
tomokusaba
2
750
10分で学ぶ、RAGの仕組みと実践
supermarimobros
0
910
LLMの開発と社会実装の今と未来 / AI Builders' Community (ABC) vol.2
pfn
PRO
1
120
時間がないなら、つくればいい 〜数十人規模のチームが自律性を発揮するために試しているいくつかのこと〜
kakehashi
PRO
23
5.2k
Google Cloud Next 2025 Recap マーケティング施策の運用及び開発を支援するAIの活用 / Use of AI to support operation and development of marketing campaign
atsushiyoshikawa
0
110
AI 코딩 에이전트 더 똑똑하게 쓰기
nacyot
0
540
Featured
See All Featured
Stop Working from a Prison Cell
hatefulcrawdad
268
20k
Making Projects Easy
brettharned
116
6.2k
Product Roadmaps are Hard
iamctodd
PRO
53
11k
The Cult of Friendly URLs
andyhume
78
6.3k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
420
The Illustrated Children's Guide to Kubernetes
chrisshort
48
49k
Embracing the Ebb and Flow
colly
85
4.7k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Producing Creativity
orderedlist
PRO
344
40k
How STYLIGHT went responsive
nonsquared
100
5.5k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
5
600
Raft: Consensus for Rubyists
vanstee
137
6.9k
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 サイボウズのフロントエンド、チーム、働き⽅についてなどなんでも