事業スピードを落とさずにPHP→Kotlinリプレイスに挑戦している話

Transcript

1. 事業スピードを落とさず
   PHP→Kotlinリプレイスに
   挑戦している話
   Cake.jp Co.Ltd.
   @Server-Side Kotlin Meetup vol.1
   

   View Slide

2. アジェンダ
   - 自己紹介
   - Cake.jp システムの
   - これまで
   - これから
   - Kotlinリプレイスの感触
   - おわりに
   2
   

   View Slide

3. 🙇
   コード1行も出てきません🥺
   3
   

   View Slide

4. 自己紹介
   あらたま／@ar_tama
   - 株式会社Cake.jp CTO
   - ex ロコガイド, セオ商事, DeNA
   - 日本もちもち協会 代表
   - サウナ好き
   4
   

   View Slide

5. Cake.jpについて
   会員数100万人突破！
   国内最大級のケーキ・スイーツ総合通販サイト
   5
   

   View Slide

6. Cake.jp システムのこれまで
   ※入社当初のあらたまさん
   6
   

   View Slide

7. Cake.jp システムのこれまで
   - 2回のピボット
   - 足掛け10年ほどのコードベース
   - 定着しないメンテナ
   - どんどん生まれる関連事業＆機能
   - 目まぐるしく変わる業務フロー
   そして九龍城へ…
   7
   

   View Slide

8. - 2回のピボット
   - 足掛け10年ほどのコードベース
   - 定着しないメンテナ
   - どんどん生まれる関連事業＆機能
   - 目まぐるしく変わる業務フロー
   そして九龍城へ…
   Cake.jp システムのこれまで
   8
   あるある
   

   View Slide

9. Cake.jp システムのこれまで
   ＝技術的投資がされてこなかった？
   9
   

   View Slide

10. Cake.jp システムのこれまで
    ＝技術的投資がされてこなかった？
    No! 結果として、技術的投資以外の判断が優先されてきただけ
    10
    

    View Slide

11. PMFは見えてきた🎂
    Cake.jp システムのこれから
    11
    

    View Slide

12. 技術的投資に（も）力を入れよう
    → 九龍城を解きほぐして、新しいアプリケーションに載せ替えよう
    - 事業成長のボトルネックをなくすため
    - システムの寿命を延ばすため
    - 開発者生産性と楽しさを増幅させるため
    Cake.jp システムのこれから
    12
    

    View Slide

13. 3年先の開発組織を考える
    - 組織規模をどの程度拡大させるか？
    - メインシステムに殆ど絡まない新規事業が乱立するか？
    - 既存事業を5以上のチームに分割する可能性はあるか？
    Cake.jp システムのこれから
    13
    

    View Slide

14. コンウェイの法則※ に従う
    先の問いに…
    - YES→チームを細かく分割し、マイクロサービスアーキテクチャで
    - NO→チームを分割しすぎず、モジュラーモノリスアーキテクチャで
    ※ “組織の設計するシステムには ... その組織のコミュニケーション構造をそのまま反映した設計になるという制約が
    ある”
    Cake.jp システムのこれから
    14
    

    View Slide

15. コンウェイの法則※ に従う
    先の問いに…
    - YES→チームを細かく分割し、マイクロサービスアーキテクチャで
    - NO→チームを分割しすぎず、モジュラーモノリスアーキテクチャで
    ※ “組織の設計するシステムには ... その組織のコミュニケーション構造をそのまま反映した設計になるという制約が
    ある”
    Cake.jp システムのこれから
    15
    

    View Slide

16. 先人の知恵を積極的に借りる
    Cake.jp システムのこれから
    16
    

    View Slide

17. - まずは既存の業務フローを洗い出し、あるべき姿とのギャップを知る
    - あるべき業務フローから業務ロジック（≒ドメインモデル）に落とし込む
    - Cake.jpは「マーケットプレイス型のECサイト」
    - ＝ECサイトとしての基本機能は固く
    - 理想形がわからないところは柔軟に
    Cake.jp システムのこれから
    17
    

    View Slide

18. - まずは既存の業務フローを洗い出し、あるべき姿とのギャップを知る
    - あるべき業務フローから業務ロジック（≒ドメインモデル）に落とし込む
    - Cake.jpは「マーケットプレイス型のECサイト」
    - ＝ECサイトとしての基本機能は固く
    - 理想形がわからないところは柔軟に
    Cake.jp システムのこれから
    18
    

    View Slide

19. そこでKotlinですよ
    19
    

    View Slide

20. - 型安全！Null安全！
    - 表現が簡潔
    - 「どこからでも何でも呼べちゃう」が防げる
    - アプリケーション特性によって使い分けができる
    - Spring MVC / Spring WebFlux + Coroutine
    20
    そこでKotlinですよ
    

    View Slide

21. 現在は、一部機能のリプレイスが完了したところ
    （出荷日やお届け日にまつわる機能群）
    ※ 注文を受けてから製造する店舗も多いため、条件が複雑
    Kotlinリプレイスの感触
    21
    

    View Slide

22. - 型安全！Null安全！
    - 表現が簡潔！
    - Data Classべんり
    - ExceptionHandlerべんり（Spring）
    - 「どこからでも何でも呼べちゃう」が防げる
    - マルチモジュールでモジュラーモノリスを体現
    - テストが書きやすい
    - mockkべんり
    - ドメインモデルに属性と振る舞いをもたせ、検証対象が明確に
    - まずはSpring MVCから
    - 今後WebFluxも積極導入していきたい
    22
    Kotlinリプレイスの感触
    

    View Slide

23. 事業計画（開発計画）に絡めながら進めているので、総じていい感じ🥳
    - マイナスをゼロにしている感が少なく、モチベーションを維持しやすい
    - リプレイス先が風化しにくい
    - ダブルメンテが起きにくい
    - トレードオフ：リプレイス完了までの時間><
    23
    Kotlinリプレイスの感触
    

    View Slide

24. 時間がなくて盛り込めなかった内容もたくさんあるので、詳細は懇親会で！
    - 直面している課題
    - 今後取り入れたい周辺技術
    - パッケージ・モジュールの粒度と狭義のアーキテクチャ
    24
    おわりに
    

    View Slide

25. We’re Hiring!!!
    Meetyもやってます🙌 お気軽にどうぞ
    25
    おわりに
    

    View Slide