モバイルアプリ開発チームを プラットフォームチームで 分割した話 Chatwork株式会社 福井 章平 実践から学ぶ チームトポロジーを活用したチーム分割 2023年7月20日

自己紹介 2 ● 名前：福井 章平 (tw: @tinpay) ○ 2014年入社 ● 役職：プロダクト本部 　　　モバイルアプリケーション開発部 　　　マネージャー 　　　（15年前にiOSアプリ作り始めた） ● 趣味 ○ 大阪のスパイスカレー屋さん巡り ○ ビール🍺

会社概要 3 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 グループ従業員数 379名（2023年3月末日時点） 所在地 東京、大阪 設立 2004年11月11日

事業概要 *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 2023年3月末日時点 ● 国内最大級のビジネスチャット「Chatwork」 を中心に、複数の周辺サービスを展開*1 ● ビジネスチャットのパイオニアであり国内利用 者数No.1*2、導入社数は39.7万社*3を突破 ● 電話やメールから効率的なチャットへ、ビジネ スコミュニケーションの変化を加速させ、 プラットフォーム化を目指しています 4

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

今日お話する内容 ● Chatworkでは開発生産性向上の取り組みとしてフィーチャーチーム化を目指していま す。その中で、モバイルアプリケーション開発部がどのようなチーム構成で開発を進めて きて、課題に対してどのようなアクションをとったのかお話させていただきます。今後の組 織開発の参考にしていただければと。 ● まだまだ弊社モバイルアプリ開発としては課題があるので、もし良い取り組みやご意見 があれば是非参考にさせていただきたいと考えています。

AGENDA アジェンダ 目指している組織構成 モバイルアプリケーション開発部のチーム変遷 まとめ 1 2 3

目指している組織構成 1

組織が目指す未来 Chatworkでは開発生産性向上の取り組みとして フィーチャーチーム化を目指している ● DevOpsを実現する職能横断型の自己管理されたチーム ● ちいとぽでいうところの「ストリームアラインドチーム」 ● 中にはモバイルアプリ開発能力を持つチームも存在する 「フィーチャーチーム」とは？ くわしくはこちらのスライドをご覧ください 『フィーチャーチーム化への取り組みと、それを支える組織マネジメント体制』 https://speakerdeck.com/tanakayuki/huitiyatimuhua-henoqu-rizu-mito-sorewozhi-eruzu-zhi-manesimentoti-zhi

モバイルアプリケーション開発部のチーム変遷 2

モバイルアプリケーション開発部のチーム構成の変遷 モバイルアプリケーション開発部は、 ここ1年半ぐらいで大きく2回チーム編成を変えました。 どういう課題があり、どう改善されることを期待して変更したのか、 また、その結果どうだったのかを説明します。

モバイルアプリケーション開発部のチーム構成の変遷 ① iOS/Android混合チームを発足 ② プラットフォームチームを発足 ● ストリームアラインドチーム (iOS/Android) ● iOSプラットフォームチーム ● Androidプラットフォームチーム ● 2つのiOS/Android混在チーム ● iOSチーム ● Androidチーム 時間軸

モバイルアプリケーション開発部のチーム構成の変遷 ① iOS/Android混合チームを発足 ② プラットフォームチームを発足 ● ストリームアラインドチーム (iOS/Android) ● iOSプラットフォームチーム ● Androidプラットフォームチーム ● 2つのiOS/Android混在チーム ● iOSチーム ● Androidチーム 時間軸

① iOS/Android混合チームを発足 iOS iOS iOS iOS Android Android Android iOS iOS Android iOS iOS Android Android Android Android iOSチーム Androidチーム チーム チーム OSごとのチームではなく、 iOS/Androidエンジニア混在チームを 2つにした

① iOS/Android混合チームを発足 どういう課題を解決したかったのか？ ● iOSアプリ、Androidアプリで機能差が生まれていた。 ● iOS/Androidの実装スピードの違いによって、必要な人員リソースに偏りがでていた。 新チームに期待したこと ● iOS/Androidエンジニア同士がチーム内で仕様についての認識を合わせる。 ● iOS/Android両方開発できるようになることで、リソースの偏りを吸収する。 ● 2つのiOS/Android混在チーム ● iOSチーム ● Androidチーム

① iOS/Android混合チームを発足 結果 ● 部内においてiOSエンジニアとAndroidエンジニアのコミュニケーションが活性化し、機能 差異が生まれないようにしようとする動きがでてきた。 ● 別プラットフォームのチケットをやる方もいたが、日常的に開発をしないとなかなか身につ かなかった。 ○ モバイル領域は変化が激しいので、キャッチアップを行うのに労力がかかる。 ● 機能開発が優先されてしまい、技術的負債の解消が後回しになることが多かった。 ● チーム間でコンフリクトすることを防いだり、リリース時期を調整したり、別チー ムのコードレビューをするために、別チームが開発している機能の仕様や実装を認 知しておく必要があった。 ● 2つのiOS/Android混在チーム ● iOSチーム ● Androidチーム Good More More More

モバイルアプリケーション開発部のチーム構成の変遷 ① iOS/Android混合チームを発足 ② プラットフォームチームを発足 ● ストリームアラインドチーム (iOS/Android混在) ● iOSプラットフォームチーム ● Androidプラットフォームチーム ● 2つのiOS/Android混在チーム ● iOSチーム ● Androidチーム 時間軸

② プラットフォームチームを発足 iOS iOS iOS iOS Android Android Android Android チーム チーム ちいとぽを参考に、ストリームアラインドチーム、プラットフォームチームに分割した iOS iOS Android Android iOSプラットフォームチーム Androidプラットフォームチーム iOS Android iOS iOS モバイルストリームアラインドチーム Android Android

② プラットフォームチームを発足 どういう課題を解決したかったのか？ ● チーム間でコンフリクトすることを防いだり、リリース時期を調整したり、別チームの コードレビューをするために、別チームが開発している機能の仕様や実装を認知して おく必要があり、そこにコストがかかった。 → 認知負荷の向上 新チームに期待したこと ● ストリームアラインドチームの認知負荷を軽減 ○ 組織としてフィーチャーチーム化を目指しており、将来的には部外のチームでもモバイ ルアプリ開発がどんどん行われていく想定。それらフィーチャーチームの認知負荷軽減 を目指す。 ● 2つのiOS/Android混在チーム ● ストリームアラインドチーム (iOS/Android混在) ● iOSプラットフォームチーム ● Androidプラットフォームチーム

② プラットフォームチームを発足 ストリームアラインドチームの作業 ● 機能開発 プラットフォームチームの作業 ● ストリームアラインドチームのコードレビュー、開発サポート ● リリース作業 ● モバイルアプリ開発基盤整備 ○ CI/CDメンテナンスなど ● リアーキテクチャ主導 ● カスタマーサポートからの問い合わせ窓口 ● 2つのiOS/Android混在チーム ● ストリームアラインドチーム (iOS/Android混在) ● iOSプラットフォームチーム ● Androidプラットフォームチーム

② プラットフォームチームを発足 結果 ● ストリームアラインドチームの認知負荷が下がった。 ○ 機能開発に集中できるようになり、リードタイム短縮に繋がった。 ● いきなりちいとぽのプラットフォームチームとして振る舞うのは難しい。 ○ オフライン、アクセシビリティ、審査ガイドライン、 HIG/MDなどモバイル領域の専門性が高く、 機能開発してリリースするまでの流れの中でこれらの知見が必要。 ■ ストリームアラインドチームの中には上記のような専門知識がないチームもある。その ため、プラットフォームチームがファシリテーションし、チームの自律性を高める必要が ある。 ● アーキテクチャやコーディングルールだけでは網羅できない領域が多い。 ● 2つのiOS/Android混在チーム ● ストリームアラインドチーム (iOS/Android混在) ● iOSプラットフォームチーム ● Androidプラットフォームチーム More Good

まとめ 4

まとめ ● ちいとぽを参考にプラットフォームチームを発足させてみて … ○ ストリームアラインドチームの認知負荷はある程度軽減できたと思う ○ モバイルアプリ開発の専門家が少ないチームだとチーム内でコードレビューが完結しないため、他 チームにコードレビュー依頼することでリードタイムが長くなってしまう ○ ストリームアラインドチームとプラットフォームチームの責務の分割が難しい ■ チーム分割の目的としてはストリームアラインドチームの認知負荷を下げること ■ 負荷を下げるためには、機能開発以外の作業をすべてプラットフォーム取れば良いわけではな い ● 組織が目指している「 DevOpsを実現する職能横断型の自己管理されたチーム」とは違う ● ストリームアラインドチームは運用保守も行う ● モバイルアプリ開発において、開発生産性を上げていくアイデアがあれば教えてください

iOSエンジニア Androidエンジニア 最後にPR Chatworkでは仲間を募集しています！ こんなチームで、一緒にモバイルアプリの機能開発や開発生産性向上を 目指していただける仲間を募集しています！ もう少し詳しく今日の話を聞きたい方、興味を持っていただけた方は 気軽にDMや以下ページよりご連絡ください！( tw: @tinpay )