モノリスから小さなシステムへ / Chatworkシステム移行の現在地と今後について@開発生産性カンファレンス

by tan-yuki

Slide 1

Slide 1 text

田中佑樹 2024年06月29日　開発生産性カンファレンス2024 モノリスから小さなシステムへ Chatworkシステム移行の現在地と今後について 1

Slide 2

Slide 2 text

自己紹介名前田中佑樹（たなかゆうき）経歴エンジニア󰞵 ⇢ EM󰳗 誰？ Chatwork株式会社執行役員兼 CP本部副本部長お仕事プロダクト人材に関わる採用や組織開発など。 2

Slide 3

Slide 3 text

会社概要 1 3

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

● 2024年7月1日より社名を株式会社kubell（読み：クベル）に変更 ● 当社の事業はビジネスチャット単体から、ビジネスチャットを包含するBPaaS事業へと大きく拡大 ● グループとして成長する企業群への展開を目指す意志をこめ、社名変更を実施社名を「kubell」へ変更すべての働く人の心に、薪を「くべる」存在へ。そのような企業でありたいという想いと決意を、新しい社名に込めています。株式会社kubell　 kubell Co., Ltd. https://corp.chatwork.com/ja/kubell/ 特設サイトを公開中 5

Slide 6

Slide 6 text

事業概要 *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2023年5月度調べ月次利用者（MAU:Monthly Active User）調査。調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む44サービスをChatwork株式会社にて選定。 *2 2024年3月末時点 ● 国内最大級のビジネスチャット「Chatwork」を展開。業界のパイオニアであり国内利用者数No.1*1、導入社数は44.1万社*2を突破 ● 圧倒的な顧客基盤とプラットフォームを背景に、DXされた業務プロセスそのものを提供するクラウドサービス、BPaaSを展開 BPaaS (Business Process as a Service) ビジネスチャット「Chatwork」お客様オペレーター 6

Slide 7

Slide 7 text

単位：% ビジネスチャットの市場環境 *1 当社依頼による第三者機関調べ、2023年12月調査、n＝30,000 *2 内閣府「第5回新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」よりテレワーク率の変化東京23区全国ビジネスチャットツールを利用している未だ低水準に止まるビジネスチャット国内普及率*1 DX推進の流れを受けテレワークが急激に普及*2 普及率は19.0％ほどで、非常にポテンシャルが大きいマーケット 7

Slide 8

Slide 8 text

「Chatwork」の企業規模別有料ユーザー割合「Chatwork」のポジショニングプロダクトのターゲットを中小企業としているため、主要な競合とは、中心となるターゲット層が異なっている企業規模大企業規模小 ITスキル低 ITスキル高 B社中小企業を中心とした独自のポジショニング B社 A社有料ユーザーのうち、ユーザー数ベースで 300人未満の契約が97.2%を占める*1 ※中小企業が大半であり、個社依存が少なく安定 *1 2024年3月末時点 8

Slide 9

Slide 9 text

長期ビジョン：ビジネス版スーパーアプリドキュメント管理 Web会議タスク管理プロジェクト管理ストレージエンゲージメント SaaSで業務効率化 CRM/SFA BPaaSで業務提供人事評価採用電話代行勤怠管理労務管理経営支援資金調達助成金請求管理契約管理決済会計受発注管理 Chatworkはビジネス版スーパーアプリへスーパーアプリ = プラットフォーム化し、あらゆるビジネスの起点になるアプリ ● ビジネスチャットは、他SaaSと比較して圧倒的に滞在時間が長く、プラットフォームとしての価値が高い ● Chatworkはオープンプラットフォームとして、様々なサービスやユーザー同士の連携が容易 BPaaSで業務提供コアビジネスに注力できる環境 9

Slide 10

Slide 10 text

本日のお話 2 10

Slide 11

Slide 11 text

モノリスシステムのシステム移行の現在地点と今後の予定について本日お話する内容現在の「Chatwork」のシステムの状況システム移行の現在地点と今後の予定について 11

Slide 12

Slide 12 text

「Chatwork」のシステム側面でみた現在の状況 3 12

Slide 13

Slide 13 text

「Chatwork」は2011年3月にリリースされ、10年以上が経過現状は、一つの巨大なモノリスのシステム上で、ほぼすべての機能が実装されているリリースから10年超の巨大サービス開発速度が低下しやすい状況 ● 10年以上運用しているサービスのため、技術的負債がたまっている状況 ● 同一のシステムを触るため、人数が増えれば増えるほどコミュニケーションが複雑になる ● 巨大ゆえに認知負荷が非常に高くなりやすく、事故に繋がりやすい／変更・追加が困難課題システムの現状 13

Slide 14

Slide 14 text

● ビジネスチャットは、業種や職種問わず、全従業員が業務時間中を通して使い続けるという特性を持つ ● そのため、トラフィック量が膨大になる傾向 ● 24時間365日止めることのできない、ビジネスにおける”インフラ”となるサービス＝パフォーマンスとシステムとしての信頼性、どちらも高いレベルで担保する必要がある高い非機能要件利用ユーザーの多さ導入社数 ※ 2024年3月末時点 44.1万登録ID数 685.3万 DAU 112.4万現状のトラフィック量 www.chatwork.comのCloudFrontのメトリクス。リクエスト量が現時点（※）で毎分106万ほど。秒間約1.7万以上のリクエストをさばいている。 ※ 2024年2月時点システムの特徴 14

Slide 15

Slide 15 text

データストレージ / キャッシュ実行基盤検索サーバーメッセージングシステムモバイルアプリ Web UI API エンドポイントシステム構成イメージ S3 Aurora DynamoDb ElastiCache 15

Slide 16

Slide 16 text

リプレイス作業の現在地点目的 ● 今後の事業成長のブレーキとならないためのシステム性能限界の解消 ● 今後の事業成長をより加速させるための開発生産性の向上現在地点 ● DBへの負荷が高いシステムのリプレイスを実施中今後の課題 ● このリプレイスを完了できたとしても、一部分のリプレイスにとどまってしまい巨大なアーキテクチャ全体に対してどのように戦っていくのかの戦略検討を深めていきたい ● 今後の全体のアーキテクチャをどのように進化させていくか、のVisionを示す必要がある 16

Slide 17

Slide 17 text

アーキテクチャ刷新と開発生産性 4 17

Slide 18

Slide 18 text

開発生産性？生産性とは？ ● アウトプット ÷ インプット ● どの程度のインプットで、どの程度のアウトプットが出せたか？ソフトウェア開発における開発生産性とは？ ● アウトプット ○ ソースコード、プルリクエスト量、開発した機能数、ユーザー満足度、売上、etc… ● インプット ○ 労働時間、労働人員、etc… 参考）開発生産性について議論する前に知っておきたいこと 18

Slide 19

Slide 19 text

開発生産性？開発アウトプットアウトカム 19

Slide 20

Slide 20 text

開発生産性？ソースコードプルリクエスト量機能数 ... ユーザー満足度売上・総利益 ... 開発アウトプットアウトカム 20

Slide 21

Slide 21 text

開発生産性？生産性？開発アウトプットアウトカム 21

Slide 22

Slide 22 text

開発生産性？広義の開発生産性狭義の開発生産性開発アウトプットアウトカム 22

Slide 23

Slide 23 text

開発生産性？ディスカバリー含めたプロダクト改善プロセス全体が対象ソフトウェア開発プロセスのみが対象広義の開発生産性開発アウトプットアウトカム狭義の開発生産性 23

Slide 24

Slide 24 text

ソフトウェア開発ライフサイクルの指標 Lead Time, Cycle Time & Change Lead Time ● Lead Time: バックログに積まれてから（事業責任者が意思決定してから）デプロイまでにかかる時間 ● Cycle Time: 開発開始してからデプロイまでにかかる時間 ● Change Lead Time: コードが最初にcommit されてからデプロイまでにかかる時間 First Commit 24

Slide 25

Slide 25 text

アーキテクチャ刷新は開発生産性へどう影響を与えるのか？ ● 「狭義の開発生産性」への影響 … 保守性の向上・変更や拡張のしやすさ ○ 狭義の開発生産性：Cycle Time / Change Lead Time ● 「広義の開発生産性」への影響 … 組織構造の最適化 ○ 広義の開発生産性：Lead Time アーキテクチャ刷新と開発生産性との関係性 25

Slide 26

Slide 26 text

「Chatwork」リプレイス戦略のふりかえり 5 26

Slide 27

Slide 27 text

「Chatwork」のリプレイスの歴史のふりかえり ● 「Chatwork」は過去にメッセージ機能のリプレイスを実施 ○ 大規模なリプレイスを計画し、年単位のPJを実施したが途中で挫折 ○ その後、メッセージ機能にのみ焦点を当てリプレイス作業を実施参考）Chatworkの新メッセージングシステムを支える技術 ● その後もいくつかのサブシステムを実装・リリース ● 現状は他の領域へのリプレイスも計画・実行に移している状態 ○ しかし、10年以上の歴史が積み重なったアプリケーションをすべてリプレイスするのは非常に難易度が高い ○ 現在は特に負荷の高い部分に範囲を絞りリプレイスを実施中 27

Slide 28

Slide 28 text

現在のシステムアーキテクチャ etc 28

Slide 29

Slide 29 text

現在のシステムアーキテクチャ etc PHP Scala 29

Slide 30

Slide 30 text

リプレイス戦略に関してのふりかえり ● 現在は特に負荷の高い部分に範囲を絞りリプレイスを実施中（再掲） ○ 今後のアーキテクチャ刷新の計画については不透明な観点が多かった ● 今後のアーキテクチャの進化の戦略をより明確にしていき、組織の構造もそれに合わせてアップデートしていきたいタスクフォースチームを結成し、今後のアーキテクチャ進化の道筋を描くことに 30

Slide 31

Slide 31 text

アーキテクチャの進化を描くタスクフォースチーム 6 31

Slide 32

Slide 32 text

タスクフォースチームの目的ゴール ● 将来必要になるであろうアーキテクチャと組織体制を定義する ● そこへ向かう道筋を示し、組織全体が「今何をするべきなのか？」が理解されている状態を目指す why? ● 今後のビジネスをドライブさせるため ○ 開発生産性を維持・向上できるようなプロダクトと組織を目指したい 32

Slide 33

Slide 33 text

タスクフォースチーム結成！ who? ● 人員の選定 -> 「Chatwork」全体の既存の仕組みや仕様について詳しい人を招集したい ● 各チームのリードエンジニアをバランスよく招集 ○ リプレイス作業に関して知見が深いメンバー ○ 既存のアプリケーション仕様に詳しいメンバー ● 最終的に揃ったメンバー：4人の精鋭たち + ぼく 33

Slide 34

Slide 34 text

タスクフォースチームの具体的なタスクゴール（再掲） ● 将来必要になるであろうアーキテクチャと組織体制を定義する ● そこへ向かう道筋を示し、組織全体が「今何をするべきなのか？」が理解されている状態を目指す想定インクリメント ● AsIs（現状）の分析 ○ 現状把握　/ 課題認識、イシューの特定 / ドメイン分析 / 開発プロセス ● Visionの策定 ○ 理想的な組織体制 / 組織体系に沿ったアーキテクチャ ● 戦略の策定 ○ Visionに向かうまでの時間軸を伴う方針 ○ 具現化する上で必要なCapability、採用計画 34

Slide 35

Slide 35 text

タスクフォースチームの成果 ● 当初、3週間（3 Sprint）と最初に期間を決めゴールを目指す ○ 毎週スプリントを実施し、ステークホルダー（= チームの代表者、PdM）からのレビューを実施 ● なんとか期間内で目標自体は達成 🎉 ○ 自分はファシリテーターとして振る舞い、今後やることついての取りまとめ、レビュー会のファシリテーションなどを担当 ● 方向性についてはある程度見えてきたスプリントレビュー用資料スプリントレビューに対してのコメント 35

Slide 36

Slide 36 text

現状分析の詳細 7 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

モノリスの種類 ● 「Chatwork」のシステムに当てはまっているモノリス ○ アプリケーションモノリス ○ データベース結合モノリス ○ モノリシックビルド / モノリシックリリース（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年ソフトウェア開発組織について語るためには避けては通れない神本 39

Slide 40

Slide 40 text

アプリケーションモノリス ● アプリケーションモノリス ○ アプリケーションモノリスは多くの依存関係や責任を持つ単一かつ巨大なアプリケーションで、多くのサービスやさまざまなユーザージャーニーを外部に公開しているものである。* ● 現状のドメイン分析をした結果が下記（かなり抽象的に書いている） ○ 下記を現状はほぼ全て一つのアプリケーションで実現している *（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p138 40

Slide 41

Slide 41 text

ドメインに対するチームの状況 ● 先に書いたドメイン図に対し、担当するチームをプロットしてみた結果↓ ● 担当領域が重複している箇所や、責任範囲が広すぎるチームなど、問題が可視化できた ● 具体的な症状：責任範囲の曖昧さによるお見合い、責任範囲が広すぎることによる認知負荷の増大 ● なぜこのような状態なのか？：システムが分割できていないことにより責任範囲が曖昧 41

Slide 42

Slide 42 text

● データベース結合モノリス ○ データベース結合モノリスは、同一のデータベーススキーマと結合している複数のアプリケーションやサービスから構成されており、それぞれ別々に変更、テスト、デプロイするのが難しい。これは、組織がサービスではなくデータベースをコアのビジネスのエンジンだと考えている場合に発生することが多い。* ● 現在の状態 ○ 複数のシステムがありながらそれぞれのアプリケーションが共通のデータベースに依存し、強い整合性を前提として設計されている ○ データモデルの変更難易度が高く、データベース分割などの改善を行うのも難しいデータベース結合モノリス *（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p138 42

Slide 43

Slide 43 text

モノリシックビルド / モノリシックリリース ● モノリシックビルド ○ モノリシックビルドでは、コンポーネントの新バージョンのために、単一の巨大な継続的インテグレーション（CI）でビルドを行う。アプリケーションモノリスがモノリシックビルドをもたらすが、小規模なサービスでも同じ問題は起こりうる。* ● モノリシックリリース ○ モノリシックリリースは、小さなコンポーネントをまとめて「リリース」する。コンポーネントやサービスはCIで独立してビルド可能でも、サービスのモックは使わず共有の固定環境でしかテストできない場合、全コンポーネントの最新バージョンをまとめて同一の環境に導入することになる。コンポーネント一式をひとかたまりとしてデプロイすることで、テストしたものが本番環境でも実行されるという確証を得るのだ。** *（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p139 **（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p139 43

Slide 44

Slide 44 text

本質的な課題はなにか？先のモノリスの中で、一番の本質的な課題はデータベース結合モノリスではないか？という仮説 ● いままではアプリケーションモノリスを解消しようとしていたが、結局のところこのデータベース結合モノリスを解消しない限り、本来の課題解決には繋がらないのでは？ why? ● アプリケーションを分割したところで、データが複数のアプリケーションで共有されているとデータモデルが変更しづらく、アプリケーションの独自進化できないため ● いわゆる ”分散モノリス” の状態からは脱せられない 44

Slide 45

Slide 45 text

アーキテクチャ移行に向けた戦略 8 45

Slide 46

Slide 46 text

アーキテクチャ刷新によって成し遂げたいVisionは？成し遂げたい状態定義 = 生産性の向上をどう獲得していくか？ ● ビジネスドメインを適切な節理面で分割していく ○ → それぞれのビジネスドメインごとにチームを紐づける ○ → ビジネスドメインとチームを整理することで、施策の実現になにが必要なのか高速に判断、実装できる状態にする 46

Slide 47

Slide 47 text

今後の移行戦略について前提（捉え方） ● 我々のアプリケーションは歴史が積み重なっており、アーキテクチャ移行は難易度が非常に高い ● そのため、一足飛びに完全移行を目指すのではなく、漸進的に進める方法を模索したい → 少しずつ価値を作りながら進めていきたい 47

Slide 48

Slide 48 text

今後の移行戦略について ● 大きく２つのパターンを検討 ○ デプロイメントを分割し、その後アプリケーションコードとデータベースを分割していく方法 ○ データベースをまず分割し、分割されたデータベースを利用してサブシステムを実装する方法それぞれ詳細を見ていく 48

Slide 49

Slide 49 text

デプロイメント分割から始めるパターン 49

Slide 50

Slide 50 text

デプロイメントの分割から始めるパターン ● ビジネスドメインの節理面を分析し、その境界でシステムを切り分け、チームを分割していく ○ 分け方として、例えばAPIエンドポイントごとの単位で分けていく ○ ALBなどでルーティングして、各チームのシステムへリクエストを流す 50

Slide 51

Slide 51 text

デプロイメント分割のメリット / デメリット ● メリット ○ 節理面さえわかればソースをコピーし自チームで管理することでチーム分割は早い段階で可能 ● デメリット ○ 一度デプロイメントを分割してしまうともとに戻すことは非常に大変 ○ 複数アプリケーションから一つのDBへの依存をすることでDBモノリスの側面を強めてしまう DBモノリスの負の側面を強めてしまうデプロイメントを分けた後は基本的には元には戻れない 51

Slide 52

Slide 52 text

デプロイメント分割の進め方 ● まずは節理面に従ってデプロイメントを分割するが、先程記載した通りDB結合モノリスの負の側面を強めることになるので早めに自チームでの管理するべきデータを特定していく ● 特定できたら既存のデータからのデータ移行を計画、アプリケーション分割からできるだけ早いタイミングで自チームで管理するデータストレージを作りにいくのが望ましい 52

Slide 53

Slide 53 text

データベース分割から始めるパターン 53

Slide 54

Slide 54 text

データベース分割から始めるパターンアプリケーション分割の前にDBから分割するパターン ● 担当ビジネスドメインを分析し、自分たちが所有するデータを明確にする ● 担当ビジネスドメインの専用データベースを構築する ● 最終的には専用データベースに対してサブシステムを構築する 54

Slide 55

Slide 55 text

データベース分割から始めるメリット / デメリット ● メリット ○ DB結合モノリスの問題に早い段階でアプローチできる ○ 先にアプリケーション分割をしてしまうとDBのリファクタリングは行いづらくなる ● デメリット ○ デプロイメント分割に比べ、各チームに独立したサービスを割り当てられるまでに時間がかかる 55

Slide 56

Slide 56 text

今後のモノリス解消への体制 56

Slide 57

Slide 57 text

いままでのリプレイスプロジェクトの進め方の課題いままでのシステム分割のやりかた ● システム分割専任のチームを用意し、システム分割をプロジェクト的に進めていた課題 ● 難易度が高く、開発人員が多く必要 → 巨大プロジェクトになりやすい ● 「負債返済チーム」と「機能開発・運用保守チーム」に分かれてしまう ○ 組織の分断 ○ 両方のチームにドメイン知識が必要なため、パワーが2倍必要 57

Slide 58

Slide 58 text

システム分割をどのような体制ですすめていくか？今後の進め方 ● システム分割専任のチームを作らずに、全チームが機能改善、保守運用と並行しながらシステム分割を遂行できるような状況をめざしたい why? ● 巨大なプロジェクトにするのではなく、少しずつ機能開発と並行しながら進められる ● 同一のドメイン知識を有したチームでモノリスの解消を進められる ● 状況に応じて新規開発に注力できる → ビジネスの変化に応じやすくなる 58

Slide 59

Slide 59 text

まとめ 9 59

Slide 60

Slide 60 text

以上、タスクフォースチームでやったことの紹介でした ● Chatworkでの今後のモノリスの解消の方法を紹介しました ● これからは、先に述べた2つのパターンを使い分けながらモノリスを解消していく ○ デプロイメント分割から始めるパターン ○ データベース分割から始めるパターン ● 分割していくシステムの特徴と、それぞれの分割パターンのメリット・デメリットを照らし合わせたうえで移行パターンを決定していく一筋縄ではいきませんが、モノリスを解消し開発生産性を飛躍的に上昇させ、チームと会社が幸せになる未来を目指していきます 60

Slide 61

Slide 61 text

● 戦略とは？ ○ AsIs -> ToBeの定義、詳しくは下記弊社COOのブログを参照ください ○ 参考）戦略とは何か？ / note Appendix：戦略とは？ \ ブログのURLはこちら！ / 61

Slide 62

Slide 62 text

Join Our Team! Chatwork採用 https://recruit.chatwork.com/engineer/ 働くをもっと楽しく、創造的に 62