Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

事業概要 *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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Chatwork iOSアプリの歴史 1

Slide 8

Slide 8 text

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年

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

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