kintoneフロントエンド刷新によるモノリスからの脱却とその先に目指す未来

by koba04

Slide 1

Slide 1 text

kintone フロントエンド刷新によるモノリスからの脱却とその先に⽬指す未来 kintone 開発チーム @koba04

Slide 2

Slide 2 text

📝Agenda ▌フロントエンド刷新プロジェクトについて ▌なぜ刷新を⾏うのか ▌⽬指している姿 ▌現状、今後について

Slide 3

Slide 3 text

✋⼩林徹 (@koba04) 2017/10~ サイボウズに中途⼊社。フロントエンドエキスパートチーム⽴ち上げのメンバーとしてプロダクト横断でフロントエンドの改善活動を⾏う 2021/09~ 刷新プロジェクトを成功させるため、フロントエンドエキスパートチームを離れ、kintone チームに所属

Slide 4

Slide 4 text

kintone

Slide 5

Slide 5 text

kintone サイボウズエンジニア採⽤ピッチ: https://speakerdeck.com/cybozuinsideout/cybozu-engineer-recruit?slide=7

Slide 6

Slide 6 text

kintone サイボウズエンジニア採⽤ピッチ: https://speakerdeck.com/cybozuinsideout/cybozu-engineer-recruit?slide=12

Slide 7

Slide 7 text

kintone サイボウズエンジニア採⽤ピッチ: https://speakerdeck.com/cybozuinsideout/cybozu-engineer-recruit?slide=13

Slide 8

Slide 8 text

🚀フロントエンド刷新プロジェクトについて

Slide 9

Slide 9 text

🚀フロントエンド刷新プロジェクトについて ▌詳しくは下記の Cybozu Meetup の発表をご覧ください🙏 https://www.youtube.com/watch?v=Zx8ejZJ-U9c https://speakerdeck.com/kuroppe1819/kintonefalsehurontoendoshua-xin-nixiang-ketaqu-rizu-mi

Slide 10

Slide 10 text

🤔なぜ刷新を⾏うのか

Slide 11

Slide 11 text

🤔なぜ刷新を⾏うのか ▌Closure やめて React などのモダンな技術で開発できるようにすることで開発速度を加速させるため︖ n → Yes であり No。ただ置き換えるだけでは将来的に同じ問題が発⽣し、脱 React をやることになる ▌メンテナンスが難しいコードを１から書き直すことでスッキリさせたい︖ n → No。これだけであれば、⼤規模にやっていく必要はない ▌最⾼のアーキテクチャを作りあげる n → No。銀の弾丸はない

Slide 12

Slide 12 text

🏹⽬指している姿

Slide 13

Slide 13 text

✨フロントエンドに Autonomy をもたらす Autonomy: ⾃治(権)、⾃主性、⾃治団体 weblioより引⽤: https://ejje.weblio.jp/content/autonomy

Slide 14

Slide 14 text

✨Autonomy ▌⾃律可能なチーム、オーナーシップ ▌変化・挑戦を可能に

Slide 15

Slide 15 text

🐥⾃律可能なチーム、オーナーシップ ▌現状はアプリケーションに境界がなく、判断が全体に及ぶ n コストやリスクが⾼く、誰もそんな判断はやりたくない ▌チーム、アプリケーション単位で分割し影響範囲で明確に n チームの中で意思決定可能な状態にする n チームの中に決断するために必要な⼈がいる状態を⽬指す

Slide 16

Slide 16 text

🐥⾃律可能なチーム、オーナーシップ ▌チームを超えた Contribution n ⾃律 ≠ サイロ化 n チームは Contribution を受け⼊れられる体制を整備する必要がある n チームを超えたコミュニケーションを推奨する⽂化づくり n 社内だけでなく社外に対してもオープンに今回で最もチャレンジングな部分の⼀つ

Slide 17

Slide 17 text

🏋変化・挑戦を可能に ▌挑戦のハードルを下げる、リカバリ可能な失敗を増やす ▌我々は失敗する、挑戦しないと失敗しない ▌Web は変化を続けるプラットフォーム ▌最適解は常に変化する

Slide 18

Slide 18 text

🏋挑戦のハードルを下げる、リカバリ可能な失敗を増やす ▌決定に対するスコープを⼩さくし、チームで完結できる体制にすることで挑戦するためのハードルを下げる ▌決断する機会は増える。ADR (Architecture Desicion Records) により決断を記録・共有する

Slide 19

Slide 19 text

🤸我々は失敗する、挑戦しないと失敗しない ▌影響範囲を⼩さくすることで、失敗した場合の影響範囲も⼩さくなり、リカバリも可能になる n ⻑期にわたって正しいと⾔える選択をすることは難しい n 短期的には正しかった選択が後々の状況の変化で最適ではなかったということも起こる ▌失敗という経験はチームにとって貴重な経験であり、多くの⼈の糧になる n 参考: 我々はいかにして技術選択を間違えたのか︖ 2016 - Cybozu Inside Out | サイボウズエンジニアのブログ

Slide 20

Slide 20 text

🌏Web は変化を続けるプラットフォーム ▌⾃分たちは変わらなくても、周りの状況は変化し続ける n Cookie の SameSite=Lax, UserAgent, Referrer-Policy n Service Workers, Web Components n SPA, SSR, Dark Theme ▌それに伴いユーザーの体験は変化を続けており、変化に対応できる状態にすることは必須 n 変わらない ≠ 利⽤者のユーザー体験が変わらない

Slide 21

Slide 21 text

⏳最適解は常に変化する ▌プロダクトやチームも変化していく。そのため、最適な状態も変化していく ▌最適なチームの単位や責務も変化していく n チームの単位や責任範囲も柔軟に定義できることで常に最適な状態を⽬指せるようにする n → チーム単位での Monorepo 構成

Slide 22

Slide 22 text

❓FAQ

Slide 23

Slide 23 text

各チームが⾃由に作るということで、プロダクトにおいて⼀貫性を保つことが難しくなりませんか︖

Slide 24

Slide 24 text

🥷横断的な関⼼毎に対してオーナーシップを持つチーム ▌チーム・アプリケーション横断の関⼼毎は存在するため、そのためのチームを作る n ユーザー体験を最⾼にするチーム n ⾃律的な開発を実現するためのプラットフォームを作るチーム ▌これらのチームとアプリケーション開発チームは、相互に Contribution を⾏う必要がある

Slide 25

Slide 25 text

各チームが⾃由に作るということで、同じようなことを各チームが実装することになりませんか︖

Slide 26

Slide 26 text

🔨本質的に必要のない DRY は避ける ▌コードの共有は結合度を⾼め凝集度を下げる ▌オーナーシップのないコード共有はメリットよりデメリットを上回る。実装が同じだからとなんでも共有せずに慎重に検討する

Slide 27

Slide 27 text

各チームは React を使わないとダメなのですか︖

Slide 28

Slide 28 text

🏆ベストプラクティスの提供 ▌技術選択に制限を加えることは⾃律的な技術選択を阻害しているが、これはコストや品質に対するトレードオフであると考えている ▌現時点での判断として React をベースにすることは上記のトレードオフを踏まえて妥当であると考えている ▌ただし、⾃分たちで全てやるということで特定部分のみ React を使わないという判断をすることは可能

Slide 29

Slide 29 text

作り直しって避けたほうがいいのでは︖

Slide 30

Slide 30 text

🍱段階的な置き換え ▌作り直しは可能な限り避けるべき ▌プロジェクトとしては全体を置き換えることを⽬的にしているが、プロセスとしては可能な限り⼩さく取り組み、初回以降のリリースは可能な限り⼩さな単位にする予定 ▌Closure → React はパラダイムの変化が⼤きいため再利⽤できる部分が少ない n 参考: Google Closure Toolsで作った⼤規模サービスにReactを導⼊した話

Slide 31

Slide 31 text

🌱現状、今後について

Slide 32

Slide 32 text

🏃現状

Slide 33

Slide 33 text

🏃現状 ▌刷新プロジェクトの前⾝として取り組んでいた部分のリリースを⽬指す ▌React に向けた技術的な調査 ▌アプリケーション分割のための基盤作り ▌刷新プロジェクトのスコープ、スケジュールの作成 ▌横断チームを作るための準備

Slide 34

Slide 34 text

⛰課題

Slide 35

Slide 35 text

⛰課題 ▌複数チームが効率的に開発するための基盤 ▌チーム間での Contribution を促す仕組み、⽂化づくり ▌カスタマイズに対する対応 ▌刷新後のチーム体制 ▌and more...

Slide 36

Slide 36 text

🤔なぜ刷新を⾏うのか

Slide 37

Slide 37 text

🤝Autonomy ▌メンバー、チームがオーナーシップをもってプロダクトに取り組む⼟壌 ▌ベストな形を求めて変化を恐れないチーム ▌社内外に対してオープンであり、必要な⼈を巻き込める

Slide 38

Slide 38 text

🎬最後に⼤事なこと

Slide 39

Slide 39 text

🙇この挑戦を⼀緒にやりたい⼈を募集しています︕︕︕ ▌絶賛募集中です︕ n フロントエンドエンジニア（kintoneアーキテクチャ刷新PJ） ▌もう少し話を聞いてみたいという場合は Meety で ✋ n サイボウズのフロントエンド、チーム、働き⽅についてなどなんでも