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

https://cybozu.connpass.com/event/227770/
の発表資料です。

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. kintone
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

10. 🤔なぜ刷新を⾏うのか
    

    View Slide

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

    View Slide

12. 🏹⽬指している姿
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

22. ❓FAQ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

31. 🌱現状、今後について
    

    View Slide

32. 🏃現状
    

    View Slide

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

    View Slide

34. ⛰課題
    

    View Slide

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

    View Slide

36. 🤔なぜ刷新を⾏うのか
    

    View Slide

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

    View Slide

38. 🎬最後に⼤事なこと
    

    View Slide

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

    View Slide