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
4.9k
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
pmconf2024_UPSIDER
upsider_tech
0
8k
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
0
15k
実務につなげる数理最適化
recruitengineers
PRO
4
440
Tailwind CSSとAtomic Designで実現する効率的な Web 開発の事例
toranoana
1
270
AI時代のデータセンターネットワーク
lycorptech_jp
PRO
1
200
Amazon Bedrock Knowledge BasesがGraphRAGに対応!! ・・・それってつまりどういうコト!? をチョット深堀ってみる
tokushun
0
150
Will Positron accelerate us?
lycorptech_jp
PRO
1
130
Kubernetes環境のオブザーバビリティの次の一歩をOpenTelemetryで実現すると何がどうなるの? - CloudNative Days Winter 2024
katzchang
0
120
KubeCon NA 2024 Recap: Managing and Distributing AI Models Using OCI Standards and Harbor / Kubernetes Meetup Tokyo #68
pfn
PRO
0
120
Explain EXPLAIN
keiko713
10
2.9k
2000年てづくりキーボードの旅
tagomoris
1
170
WernerVogelsのKeynoteで語られた6つの教訓とOps
hatahata021
1
200
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.8k
Faster Mobile Websites
deanohume
305
30k
How To Stay Up To Date on Web Technology
chriscoyier
789
250k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building Better People: How to give real-time feedback that sticks.
wjessup
365
19k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
Fantastic passwords and where to find them - at NoRuKo
philnash
50
2.9k
BBQ
matthewcrist
85
9.3k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
1
140
Automating Front-end Workflow
addyosmani
1366
200k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Practical Orchestrator
shlominoach
186
10k
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 サイボウズのフロントエンド、チーム、働き⽅についてなどなんでも