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

2024/06/29（土）開発生産性Conference2024での登壇資料です

1. 田中 佑樹 2024年06月29日　開発生産性カンファレンス2024 モノリスから小さなシステムへ Chatworkシステム移行の現在地と今後について 1
2. 自己紹介 名前 田中 佑樹（たなか ゆうき） 経歴 エンジニア󰞵 ⇢ EM󰳗 誰？ Chatwork株式会社 執行役員 兼 CP本部 副本部長 お仕事 プロダクト人材に関わる採用や 組織開発など。 2
3. 会社概要 1 3
4. 会社概要 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 グループ従業員数 465名（2024年3月末日時点） 所在地 東京、大阪 設立 2004年11月11日 4
5. • 2024年7月1日より社名を株式会社kubell（読み：クベル）に変更 • 当社の事業はビジネスチャット単体から、ビジネスチャットを包含するBPaaS事業へと大きく拡大 • グループとして成長する企業群への展開を目指す意志をこめ、社名変更を実施 社名を「kubell」へ変更 すべての働く人の心に、薪を「くべる」存在へ。 そのような企業でありたいという想いと決意を、新しい社名に込めています。 株式会社kubell　 kubell Co., Ltd. https://corp.chatwork.com/ja/kubell/ 特設サイトを公開中 5
6. 事業概要 *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
7. 単位：% ビジネスチャットの市場環境 *1 当社依頼による第三者機関調べ、2023年12月調査、n＝30,000 *2 内閣府「第5回 新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」より テレワーク率の変化 東京23区 全国 ビジネスチャット ツールを利用している 未だ低水準に止まる ビジネスチャット国内普及率*1 DX推進の流れを受け テレワークが急激に普及*2 普及率は19.0％ほどで、非常にポテンシャルが大きいマーケット 7
8. 「Chatwork」の企業規模別 有料ユーザー割合 「Chatwork」のポジショニング プロダクトのターゲットを中小企業としているため、 主要な競合とは、中心となるターゲット層が異なっている 企業規模 大 企業規模 小 ITスキル 低 ITスキル 高 B社 中小企業を中心とした独自のポジショニング B社 A社 有料ユーザーのうち、ユーザー数ベースで 300人未満の契約が97.2%を占める*1 ※中小企業が大半であり、個社依存が少なく安定 *1 2024年3月末時点 8
9. 長期ビジョン：ビジネス版スーパーアプリ ドキュメント 管理 Web会議 タスク管理 プロジェクト管理 ストレージ エンゲージメント SaaSで業務効率化 CRM/SFA BPaaSで業務提供 人事評価 採用 電話代行 勤怠管理 労務管理 経営支援 資金調達 助成金 請求管理 契約管理 決済 会計 受発注管理 Chatworkはビジネス版スーパーアプリへ スーパーアプリ = プラットフォーム化し、あらゆるビジネスの起点になるアプリ • ビジネスチャットは、他SaaSと比較して圧倒的に滞在時間が長く、プラットフォームとしての価値が高い • Chatworkはオープンプラットフォームとして、様々なサービスやユーザー同士の連携が容易 BPaaSで業務提供 コアビジネスに注力できる環境 9
10. 本日のお話 2 10
11. モノリスシステムのシステム移行の現在地点と今後の予定について 本日お話する内容 現在の「Chatwork」のシステムの状況 システム移行の現在地点と今後の予定について 11
12. 「Chatwork」のシステム側面でみた現在の状況 3 12
13. 「Chatwork」は2011年3月にリリースされ、10年以上が経過 現状は、一つの巨大なモノリスのシステム上で、ほぼすべての機能が実装されている リリースから10年超の巨大サービス 開発速度が低下しやすい状況 • 10年以上運用しているサービスのため、技術的負債がたまっている状況 • 同一のシステムを触るため、人数が増えれば増えるほどコミュニケーションが複雑になる • 巨大ゆえに認知負荷が非常に高くなりやすく、事故に繋がりやすい／変更・追加が困難 課 題 システムの現状 13
14. • ビジネスチャットは、業種や職種問わず、全従業員が業務時間中を通して使い続け るという特性を持つ • そのため、トラフィック量が膨大になる傾向 • 24時間365日止めることのできない、ビジネスにおける”インフラ”となるサービス ＝パフォーマンスとシステムとしての信頼性、どちらも高いレベルで担保する必要がある 高い非機能要件 利用ユーザーの多さ 導入社数 ※ 2024年3月末時点 44.1万 登録ID数 685.3万 DAU 112.4万 現状のトラフィック量 www.chatwork.comのCloudFrontのメトリクス。 リクエスト量が現時点（※）で毎分106万ほど。 秒間約1.7万以上のリクエストをさばいている。 ※ 2024年2月時点 システムの特徴 14
15. データストレージ / キャッシュ 実行基盤 検索サーバー メッセージングシステム モバイルアプリ Web UI API エンドポイント システム構成イメージ S3 Aurora DynamoDb ElastiCache 15
16. リプレイス作業の現在地点 目的 • 今後の事業成長のブレーキとならないためのシステム性能限界の解消 • 今後の事業成長をより加速させるための開発生産性の向上 現在地点 • DBへの負荷が高いシステムのリプレイスを実施中 今後の課題 • このリプレイスを完了できたとしても、一部分のリプレイスにとどまってしまい巨大なアーキテク チャ全体に対してどのように戦っていくのかの戦略検討を深めていきたい • 今後の全体のアーキテクチャをどのように進化させていくか、のVisionを示す必要がある 16
17. アーキテクチャ刷新と開発生産性 4 17
18. 開発生産性？ 生産性とは？ • アウトプット ÷ インプット • どの程度のインプットで、どの程度のアウトプットが出せたか？ ソフトウェア開発における開発生産性とは？ • アウトプット ◦ ソースコード、プルリクエスト量、開発した機能数、ユーザー満足度、売上、etc… • インプット ◦ 労働時間、労働人員、etc… 参考）開発生産性について議論する前に知っておきたいこと 18
19. 開発生産性？ 開発 アウトプット アウトカム 19
20. 開発生産性？ ソースコード プルリクエスト量 機能数 ... ユーザー満足度 売上・総利益 ... 開発 アウトプット アウトカム 20
21. 開発生産性？ 生産性？ 開発 アウトプット アウトカム 21
22. 開発生産性？ 広義の 開発生産性 狭義の 開発生産性 開発 アウトプット アウトカム 22
23. 開発生産性？ ディスカバリー含めた プロダクト改善プロセス全体が対象 ソフトウェア開発プロセス のみが対象 広義の 開発生産性 開発 アウトプット アウトカム 狭義の 開発生産性 23
24. ソフトウェア開発ライフサイクルの指標 Lead Time, Cycle Time & Change Lead Time • Lead Time: バックログに積まれてから（事業責任者が意思決定してから）デプロイまでにかかる時間 • Cycle Time: 開発開始してからデプロイまでにかかる時間 • Change Lead Time: コードが 最初にcommit されてからデプロイまでにかかる時間 First Commit 24
25. アーキテクチャ刷新は開発生産性へどう影響を与えるのか？ • 「狭義の開発生産性」への影響 … 保守性の向上・変更や拡張のしやすさ ◦ 狭義の開発生産性：Cycle Time / Change Lead Time • 「広義の開発生産性」への影響 … 組織構造の最適化 ◦ 広義の開発生産性：Lead Time アーキテクチャ刷新と開発生産性との関係性 25
26. 「Chatwork」リプレイス戦略のふりかえり 5 26
27. 「Chatwork」のリプレイスの歴史のふりかえり • 「Chatwork」は過去にメッセージ機能のリプレイスを実施 ◦ 大規模なリプレイスを計画し、年単位のPJを実施したが途中で挫折 ◦ その後、メッセージ機能にのみ焦点を当てリプレイス作業を実施 参考）Chatworkの新メッセージングシステムを支える技術 • その後もいくつかのサブシステムを実装・リリース • 現状は他の領域へのリプレイスも計画・実行に移している状態 ◦ しかし、10年以上の歴史が積み重なったアプリケーションを すべてリプレイスするのは非常に難易度が高い ◦ 現在は特に負荷の高い部分に範囲を絞りリプレイスを実施中 27
28. 現在のシステムアーキテクチャ etc 28
29. 現在のシステムアーキテクチャ etc PHP Scala 29
30. リプレイス戦略に関してのふりかえり • 現在は特に負荷の高い部分に範囲を絞りリプレイスを実施中（再掲） ◦ 今後のアーキテクチャ刷新の計画については不透明な観点が多かった • 今後のアーキテクチャの進化の戦略をより明確にしていき、組織の構造もそれに合わせて アップデートしていきたい タスクフォースチームを結成し、 今後のアーキテクチャ進化の道筋を描くことに 30
31. アーキテクチャの進化を描くタスクフォースチーム 6 31
32. タスクフォースチームの目的 ゴール • 将来必要になるであろうアーキテクチャと組織体制を定義する • そこへ向かう道筋を示し、組織全体が「今何をするべきなのか？」が理解されている状態を目指す why? • 今後のビジネスをドライブさせるため ◦ 開発生産性を維持・向上できるようなプロダクトと組織を目指したい 32
33. タスクフォースチーム結成！ who? • 人員の選定 -> 「Chatwork」全体の既存の仕組みや仕様について詳しい人を招集したい • 各チームのリードエンジニアをバランスよく招集 ◦ リプレイス作業に関して知見が深いメンバー ◦ 既存のアプリケーション仕様に詳しいメンバー • 最終的に揃ったメンバー：4人の精鋭たち + ぼく 33
34. タスクフォースチームの具体的なタスク ゴール（再掲） • 将来必要になるであろうアーキテクチャと組織体制を定義する • そこへ向かう道筋を示し、組織全体が「今何をするべきなのか？」が理解されている状態を目指す 想定インクリメント • AsIs（現状）の分析 ◦ 現状把握　/ 課題認識、イシューの特定 / ドメイン分析 / 開発プロセス • Visionの策定 ◦ 理想的な組織体制 / 組織体系に沿ったアーキテクチャ • 戦略の策定 ◦ Visionに向かうまでの時間軸を伴う方針 ◦ 具現化する上で必要なCapability、採用計画 34
35. タスクフォースチームの成果 • 当初、3週間（3 Sprint）と最初に期間を決めゴールを目指す ◦ 毎週スプリントを実施し、ステークホルダー（= チームの代表者、PdM）からのレビューを実施 • なんとか期間内で目標自体は達成 🎉 ◦ 自分はファシリテーターとして振る舞い、今後やることついての取りまとめ、レビュー会のファ シリテーションなどを担当 • 方向性についてはある程度見えてきた スプリントレビュー用資料 スプリントレビューに対してのコメント 35
36. 現状分析の詳細 7 36
37. 「Chatwork」は2011年3月にリリースされ、10年以上が経過 現状は、一つの巨大なモノリスのシステム上で、ほぼすべての機能が実装されている リリースから10年超の巨大サービス 開発速度が低下しやすい状況 • 10年以上運用しているサービスのため、技術的負債がたまっている状況 • 同一のシステムを触るため、人数が増えれば増えるほどコミュニケーションが複雑になる • 巨大ゆえに認知負荷が非常に高くなりやすく、事故に繋がりやすい／変更・追加が困難 課 題 現状のシステムの状況（再掲） 37
38. 「Chatwork」は2011年3月にリリースされ、10年以上が経過 現状は、一つの巨大なモノリスのシステム上で、ほぼすべての機能が実装されている リリースから10年超の巨大サービス 開発速度が低下しやすい状況 • 10年以上運用しているサービスのため、技術的負債がたまっている状況 • 同一のシステムを触るため、人数が増えれば増えるほどコミュニケーションが複雑になる • 巨大ゆえに認知負荷が非常に高くなりやすく、事故に繋がりやすい／変更・追加が困難 課 題 現状のシステムの状況（再掲） 課題の主な原因？ 38
39. モノリスの種類 • 「Chatwork」のシステムに当てはまっているモノリス ◦ アプリケーションモノリス ◦ データベース結合モノリス ◦ モノリシックビルド / モノリシックリリース （出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフ トウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年 ソフトウェア開発組織について語るためには 避けては通れない神本 39
40. アプリケーションモノリス • アプリケーションモノリス ◦ アプリケーションモノリスは多くの依存関係や責任を持つ単一かつ巨大なアプリケーションで、 多くのサービスやさまざまなユーザージャーニーを外部に公開しているものである。* • 現状のドメイン分析をした結果が下記（かなり抽象的に書いている） ◦ 下記を現状はほぼ全て一つのアプリケーションで実現している *（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p138 40
41. ドメインに対するチームの状況 • 先に書いたドメイン図に対し、担当するチームをプロットしてみた結果↓ • 担当領域が重複している箇所や、責任範囲が広すぎるチームなど、問題が可視化できた • 具体的な症状：責任範囲の曖昧さによるお見合い、責任範囲が広すぎることによる認知負荷の増大 • なぜこのような状態なのか？：システムが分割できていないことにより責任範囲が曖昧 41
42. • データベース結合モノリス ◦ データベース結合モノリスは、同一のデータベーススキーマと結合している複数のアプリケー ションやサービスから構成されており、それぞれ別々に変更、テスト、デプロイするのが難し い。これは、組織がサービスではなくデータベースをコアのビジネスのエンジンだと考えている 場合に発生することが多い。* • 現在の状態 ◦ 複数のシステムがありながらそれぞれのアプリケーションが共通のデータベースに依存し、 強い整合性を前提として設計されている ◦ データモデルの変更難易度が高く、データベース分割などの改善を行うのも難しい データベース結合モノリス *（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p138 42
43. モノリシックビルド / モノリシックリリース • モノリシックビルド ◦ モノリシックビルドでは、コンポーネントの新バージョンのために、単一の巨大な継続的インテ グレーション（CI）でビルドを行う。アプリケーションモノリスがモノリシックビルドをもたら すが、小規模なサービスでも同じ問題は起こりうる。* • モノリシックリリース ◦ モノリシックリリースは、小さなコンポーネントをまとめて「リリース」する。コンポーネント やサービスはCIで独立してビルド可能でも、サービスのモックは使わず共有の固定環境でしかテ ストできない場合、全コンポーネントの最新バージョンをまとめて同一の環境に導入することに なる。コンポーネント一式をひとかたまりとしてデプロイすることで、テストしたものが本番環 境でも実行されるという確証を得るのだ。** *（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p139 **（出典）マシュー・スケルトン,マニュエル・パイス.『チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計』.日本能率協会マネジメントセンター.2021年.p139 43
44. 本質的な課題はなにか？ 先のモノリスの中で、一番の本質的な課題はデータベース結合モノリスではないか？という仮説 • いままではアプリケーションモノリスを解消しようとしていたが、結局のところこのデータベース結 合モノリスを解消しない限り、本来の課題解決には繋がらないのでは？ why? • アプリケーションを分割したところで、データが複数のアプリケーションで共有されているとデータ モデルが変更しづらく、アプリケーションの独自進化できないため • いわゆる ”分散モノリス” の状態からは脱せられない 44
45. アーキテクチャ移行に向けた戦略 8 45
46. アーキテクチャ刷新によって成し遂げたいVisionは？ 成し遂げたい状態定義 = 生産性の向上をどう獲得していくか？ • ビジネスドメインを適切な節理面で分割していく ◦ → それぞれのビジネスドメインごとにチームを紐づける ◦ → ビジネスドメインとチームを整理することで、施策の実現になにが必要なのか高速に判断、 実装できる状態にする 46
47. 今後の移行戦略について 前提（捉え方） • 我々のアプリケーションは歴史が積み重なっており、アーキテクチャ移行は難易度が非常に高い • そのため、一足飛びに完全移行を目指すのではなく、漸進的に進める方法を模索したい → 少しずつ価値を作りながら進めていきたい 47
48. 今後の移行戦略について • 大きく２つのパターンを検討 ◦ デプロイメントを分割し、その後アプリケーションコードとデータベースを分割していく方法 ◦ データベースをまず分割し、分割されたデータベースを利用してサブシステムを実装する方法 それぞれ詳細を見ていく 48
49. デプロイメント分割から始めるパターン 49
50. デプロイメントの分割から始めるパターン • ビジネスドメインの節理面を分析し、その境界でシステムを切り分け、チームを分割していく ◦ 分け方として、例えばAPIエンドポイントごとの単位で分けていく ◦ ALBなどでルーティングして、各チームのシステムへリクエストを流す 50
51. デプロイメント分割のメリット / デメリット • メリット ◦ 節理面さえわかればソースをコピーし自チームで管理することでチーム分割は早い段階で可能 • デメリット ◦ 一度デプロイメントを分割してしまうともとに戻すことは非常に大変 ◦ 複数アプリケーションから一つのDBへの依存をすることでDBモノリスの側面を強めてしまう DBモノリスの負の側面を強めてしまう デプロイメントを分けた後は基本的には元 には戻れない 51
52. デプロイメント分割の進め方 • まずは節理面に従ってデプロイメントを分割するが、先程記載した通りDB結合モノリスの負の側面を 強めることになるので早めに自チームでの管理するべきデータを特定していく • 特定できたら既存のデータからのデータ移行を計画、アプリケーション分割からできるだけ早いタイ ミングで自チームで管理するデータストレージを作りにいくのが望ましい 52
53. データベース分割から始めるパターン 53
54. データベース分割から始めるパターン アプリケーション分割の前にDBから分割するパターン • 担当ビジネスドメインを分析し、自分たちが所有するデータを明確にする • 担当ビジネスドメインの専用データベースを構築する • 最終的には専用データベースに対してサブシステムを構築する 54
55. データベース分割から始めるメリット / デメリット • メリット ◦ DB結合モノリスの問題に早い段階でアプローチできる ◦ 先にアプリケーション分割をしてしまうとDBのリファクタリングは行いづらくなる • デメリット ◦ デプロイメント分割に比べ、各チームに独立したサービスを割り当てられるまでに時間がかかる 55
56. 今後のモノリス解消への体制 56
57. いままでのリプレイスプロジェクトの進め方の課題 いままでのシステム分割のやりかた • システム分割専任のチームを用意し、システム分割をプロジェクト的に進めていた 課題 • 難易度が高く、開発人員が多く必要 → 巨大プロジェクトになりやすい • 「負債返済チーム」と「機能開発・運用保守チーム」に分かれてしまう ◦ 組織の分断 ◦ 両方のチームにドメイン知識が必要なため、パワーが2倍必要 57
58. システム分割をどのような体制ですすめていくか？ 今後の進め方 • システム分割専任のチームを作らずに、全チームが機能改善、保守運用と並行しながらシステム分割 を遂行できるような状況をめざしたい why? • 巨大なプロジェクトにするのではなく、少しずつ機能開発と並行しながら進められる • 同一のドメイン知識を有したチームでモノリスの解消を進められる • 状況に応じて新規開発に注力できる → ビジネスの変化に応じやすくなる 58
59. まとめ 9 59
60. 以上、タスクフォースチームでやったことの紹介でした • Chatworkでの今後のモノリスの解消の方法を紹介しました • これからは、先に述べた2つのパターンを使い分けながらモノリスを解消していく ◦ デプロイメント分割から始めるパターン ◦ データベース分割から始めるパターン • 分割していくシステムの特徴と、それぞれの分割パターンのメリット・デメリットを照らし合わせた うえで移行パターンを決定していく 一筋縄ではいきませんが、モノリスを解消し開発生産性を飛躍的に上昇させ、チームと会社が幸せになる 未来を目指していきます 60
61. • 戦略とは？ ◦ AsIs -> ToBeの定義、詳しくは下記弊社COOのブログを参照ください ◦ 参考）戦略とは何か？ / note Appendix：戦略とは？ \ ブログのURLはこちら！ / 61
62. Join Our Team! Chatwork採用 https://recruit.chatwork.com/engineer/ 働くをもっと楽しく、創造的に 62