$30 off During Our Annual Pro Sale. View Details »

iOSアプリの 大きな技術的負債に立ち向かう

tinpay
April 12, 2023

iOSアプリの 大きな技術的負債に立ち向かう

tinpay

April 12, 2023
Tweet

More Decks by tinpay

Other Decks in Technology

Transcript

  1. © Chatwork
    iOSアプリの
    大きな技術的負債に立ち向かう
    Chatwork株式会社
    モバイルアプリケーション開発部
    福井 章平
    2023-04-12 モバイルアプリの技術的負債 みんなで学ぶ Lunch LT

    View Slide

  2. 自己紹介
    福井 章平(@tinpay)
    ● Chatwork株式会社
    ○ モバイルアプリケーション開発部 マネージャー
    ● iOSアプリ開発

    View Slide

  3. 会社概要
    3
    会社名
    Chatwork株式会社
    代表取締役CEO
    山本 正喜
    従業員数
    312名(2022年12月末日時点)
    所在地
    東京、大阪
    設立
    2004年11月11日

    View Slide

  4. 4
    一部の先進的な人だけではな 、
    世界中で働 あらゆる人 、自分自身の働 方を
    常に「一歩先」へと進めていける
    プラットフォームを提供する
    すべての人に、
    一歩先の働き方を
    働くをもっと楽しく、
    創造的に 
    人生の大半を過ごすことになる「働 」という
    時間に いて、ただ生活の糧を得るためだけではな 、
    1人でも多 の人 より楽し 、自由な創造性を
    存分に発揮で る社会を実現する
    Vision
    Mission
    ミッション・ビジョン

    View Slide

  5. 事業概要
    *1 Chatworkセグメント以外の事業として、ESET社提供のセキュリティ対策ソフトウェア「ESET」の代理販売事業を展開。安定的な収益貢献となっている
    *2 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者(MAU:Monthly Active User)調査。
      調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。 *3 2022年12月末時点
    ● 国内最大級のビジネスチャット「Chatwork」
    を中心に、複数の周辺サービスを展開*1
    ● ビジネスチャットのパイオニアであり国内利用
    者数No.1*2、導入社数は38.6万社*3を突破
    ● 電話やメール ら効率的なチャットへ、ビジネ
    スコミュニケーションの変化を加速させ、
    プラットフォーム化を目指しています
    5

    View Slide

  6. Chatwork iOSアプリの歴史
    Chatwork iOSアプリが抱える技術的負債
    2022年までのチームと課題
    負債と向き合うチーム構成へ
    1
    2
    3
    AGENDA
    アジェンダ
    4

    View Slide

  7. Chatwork iOSアプリの歴史
    1

    View Slide

  8. iOSアプリの歴史
    ファーストリリース (Titanium)
    ネイティブ版リリース
    CoreData → Realm
    ReactiveCocoa → RxSwift
    Swift化
    Chatwork Live
    リアクション
    モバイルマルチアカウント
    リンクプレビュー
    iOS5
    iOS16
    2023年
    2011年
    2016年
    2018年
    2020年
    2014年
    ネイティブ版 実装開始
    (Objective-C / ReactiveCocoa)
    AST
    ブックマーク
    ダークモード対応
    モバイル広告
    行動分析(TreasureData)
    iPad 2カラム対応
    メッセージ閲覧制限
    Google / Apple 認証
    In-App Purchase
    GDPR対応
    RxSwift → Combine
    Swift Concurrency
    SwiftUI
    Swift Package Manager
    Carthage
    CocoaPods
    XcodeGen
    Mantle → Codable
    モバイルの技術 Chatwork新機能
    9年

    View Slide

  9. Chatwork iOSアプリが抱える
    技術的負債
    2

    View Slide

  10. 去年書いたTech Blogの紹介
    https://creators-note.chatwork.com/entry/2022/09/29/100807

    View Slide

  11. iOSアプリが抱える技術的負債
    1. Objective-Cのコード 残っている
    2. ビルド時間 長い
    3. ユニットテスト 少ない
    4. 特定の機能に ける属人性 高い
    5. リアーキテクチャ 中途半端な状態で、レガシーなコード 多い

    View Slide

  12. iOSアプリが抱える技術的負債
    1. Objective-Cのコード 残っている
    2. ビルド時間 長い
    3. ユニットテスト 少ない
    4. 特定の機能に ける属人性 高い
    5. リアーキテクチャ 中途半端な状態で、レガシーなコード 多い

    View Slide

  13. 2022年までのチームと課題
    3

    View Slide

  14. 2022年までのチーム構成
    ● 部署メンバーを2つチームに分
    けた
    ● iOS / Androidエンジニアが
    1つのチームに混在している
    ● 両チームともスクラム開発を
    行っている
    ● 両チームを兼任しているPOと
    ScMがいる

    View Slide

  15. 2022年までのチーム構成の特徴
    15
    Rougeチーム Noirチーム
    ● 責務が分かれておらず、責任範囲が同じ。
    ● 直接的なユーザー価値提供も行うし、それ以
    外のことも行う(リファクタリング、リアーキ
    テクチャなど)。
    価値
    価値
    情報共有
    リファクタリング / リアーキテクチャ

    View Slide

  16. 2022年までのチーム課題
    1. 認知負荷 向上して生産性 低下する
    ○ 複数のチームが新機能開発を行う場合、自分の所属チー
    ム以外の作業内容についても把握しておく必要があり、
    認知負荷が高くなる。
    → 把握していないとどうなる?
    ● チーム間で機能や実装のコンフリクトが発生する
    ● 他チームがコードレビューできない

    View Slide

  17. 2022年までのチーム課題
    2. 新機能開発 優先され、リアーキテクチャ 進まない
    ○ 新機能開発することでユーザー価値提供を行うことは大切
    ○ リアーキテクチャも大切だが、顧客ニーズに直接的に影響を
    与えないため、新機能開発に比べて優先度が低くされがち
    新機能
    リファクタリング
    リアーキテクチャ → 新機能開発の合間にリアーキテクチャを行うよう
    になり、中途半端な実装が散見されるようになった

    View Slide

  18. (参考) 認知負荷とは?
    ワーキングメモリに対して る負荷のこと。ワーキングメモリの容量は大 な
    、認知負荷 増えす ると情報を処理し れな なる。
    出典: https://speakerdeck.com/mizuman/team-agility-by-learning-from-team-topology?slide=18
    脳が処理できる量は限界があり、
    負荷 高 なることでパフォーマンス 落ち、
    学習や理解 止まる
    開発生産性の低下

    View Slide

  19. 2022年のチーム課題と解決策
    チーム構成の見直し
    解決するために…
    1. 認知負荷 向上して生産性 低下する
    2. 新機能開発 優先され、リアーキテクチャ 進まない

    View Slide

  20. 負債と向き合うチーム構成へ
    4

    View Slide

  21. チーム構成見直しのポイント
    チームごとに責務分割する
    参考: https://www.ryuzee.com/contents/blog/14566
    1. 認知負荷が向上して生産性が低下する
    → 適切なチームの境界を引くことで境界の向こう側を知らな
    くてもOKな状態になり、認知負荷を軽減することができる
    2. 新機能開発が優先され、リアーキテクチャが進まない
    → リアーキテクチャの優先度が、新機能開発に左右されなく
    なる

    View Slide

  22. 現在のチーム構成
    (見直し後)

    View Slide

  23. 現在のチーム構成
    ● Rouge
    ○ iOS、Androidエンジニア
    が混在している
    ● Blanc
    ○ iOSエンジニアのみ在籍し
    ている
    ● Noir
    ○ Androidエンジニアのみ在
    籍している

    View Slide

  24. 現在のチーム構成の特徴
    ストリームアラインドチーム
    (Rouge)
    iOSプラットフォーム(Blanc)
    価値
    価値
    Androidプラットフォーム(Noir)
    チームトポロジーで
    定義されているチーム
    役割
    Rouge ストリームアラインドチーム ユーザーに対して価値提供を行う
    Blanc
    プラットフォームチーム
    Rougeに対して価値提供を行う
    (iOS)
    Noir
    Rougeに対して価値提供を行う
    (Android)

    View Slide

  25. 各チームが行っている作業の一例
    ストリームアラインドチーム
    (Rouge)
    ● 新機能開発
    ● 不具合調査、修正
    ● テスト、検証
    ● 運用、保守
    プラットフォームチーム
    (Blanc / Noir)
    ● リアーキテクチャ
    ● コーディングルール策定
    ● リリース作業
    ● CI / CD
    ● Rougeのサポート

    View Slide

  26. 現在のチームにおける課題
    プラットフォームチーム作業の肥大化
    ● ストリームアラインドチームとプラットフォームチームの境界にある
    ボールをプラットフォームチームが全て取りがち
    ○ 今後の対策
    → 適切な境界を探し、権限委譲が必要
    ● 自己組織化できていないストリームアラインドチームが増えると、プ
    ラットフォームチームと密にコミュニケーションが必要になり、コスト
    が増える
    ○ 今後の対策
    → チーム内で完結できるようなモジュール分割

    View Slide

  27. まとめ
    ● 計画的にリファクタリングやリアーキテクチャを進めるた
    めにチーム分割を行った
    ● チームごとに責務を分けることで、機能開発とリアーキテ
    クチャを並行して進めることができた
    また、各チームの認知負荷を下げることができ、開発生産
    性が向上した

    View Slide

  28. iOS/Android、ともにリアーキテクチャすすめています
    iOS
    ● マルチモジュール化
    ● ApplicationService層のDI化
    ● Swift Concurrency
    ● SwiftUI
    ● SwiftUIを実現するためのリアーキテクチャ
    ○ Single Source of Truthを実現する独自アーキテ
    クチャ (SVVS: State, View, ViewState)
    Android
    ● マルチモジュール化
    ● MVVM再設計
    ● Clean Architecture
    ● Jetpack Compose

    View Slide

  29. iOSエンジニア Androidエンジニア
    最後にPR
    Chatworkでは仲間を募集しています!
    もう少し詳しく今日の話を聞きたい方、興味を持っていただけた方は
    気軽にDMや以下ページよりご連絡ください!( tw: @tinpay )

    View Slide