シェア
はてブ
2024年6月28日(金)・29日(土)、ファインディ株式会社は「開発生産性Conference 2024」を開催しました。本カンファレンスは、虎ノ門ヒルズフォーラムのオフライン会場にて実施され、一部のセッションはオンライン配信も行われました。
国内最大級のビジネスチャット「Chatwork」を展開する株式会社kubell（旧Chatwork株式会社 ※2024年7月1日より社名変更）では、技術負債を解消して開発生産性を高める取り組みを行っています。本カンファレンスでは、「モノリスから小さなシステムへ：Chatworkシステム移行の現在地と今後について」と題して、執行役員 兼 コミュニケーションプラットフォーム副本部長の田中 佑樹氏が登壇しました。
本記事では、田中氏の講演内容をもとに、モノリスシステムの課題とリプレイス戦略、そして開発生産性向上への取り組みの事例をお届けします。
■登壇者
株式会社kubell 執行役員 兼 コミュニケーションプラットフォーム副本部長
田中 佑樹（たなか ゆうき）
SI企業にてWeb系システムの開発に従事したのち、2013年にChatwork株式会社（現 株式会社kubell）に入社。UI刷新プロジェクトのWebフロントエンド開発や外部向けREST API開発、メッセージ検索サーバー刷新など数多くのプロジェクトを担当。その後エンジニアリングマネージャーとして、プロダクト領域の幅広い領域のマネジメントを経験したのち、2023年3月にプロダクト本部長、2023年10月に執行役員に就任。
「Chatwork」のシステムの現状と問題
「Chatwork」は2011年3月にリリースされた、10年以上の歴史を持つ巨大なサービスです。このシステムの特徴として、高い非機能要件が求められます。
まず、ビジネスチャットという特性上、他のSaaSと大きく異なり、アプリケーションが常に立ち上げっぱなしになっています。ユーザーが出社しビジネスチャットを開いて終業するまで、利用時間がかなり長い。そのため、トラフィック量が非常に膨大になる傾向があります。ピークタイムには秒間約1.7万リクエストを処理しています。
さらに特徴的なのは、ピークタイムだけスパイクしているわけではなく、同等の流量が日中時間ずっと続いているという点です。
加えて、ビジネスチャットなのでシステムダウンしてしまうとユーザーに甚大な影響を与えてしまいます。ユーザーにとってはコミュニケーション手段が絶たれることになるので、ほぼ仕事ができない状態になります。このように、パフォーマンスとシステムの信頼性、どちらも高いレベルを担保する必要があるというのが大きな特徴です。
リプレイスを進める目的は2つあります。1つは、今後の事業成長のブレーキとならないように、システム性能限界の解消をし、マイナスの側面を抑えること。もう1つは、今後の事業成長をより加速させるため、開発生産性を向上させるというプラスの側面を強化することです。
現在はデータベースへの負荷が非常に高いシステムについてリプレイスを実施中です。
アーキテクチャ刷新と開発生産性
そもそも生産性とは何かというと、さまざまな定義がありますが、最もシンプルな定義としては、「アウトプット÷インプット」だと考えています。インプットでどれだけのアウトプットを出せたかということです。
ソフトウェアにおける開発生産性を考える際、アウトプットにはソースコード、プルリクエスト数、機能数、ユーザー満足度、売上などが含まれます。一方、インプットとしては労働時間や労働人員が挙げられます。
開発生産性は2つの視点で捉えることができます。広義の開発生産性は、開発からアウトカム（ユーザー満足度、売上、利益など）までの全プロセスを指します。一方、狭義の開発生産性は、開発からアウトプット（ソースコード、機能など）までの工程に焦点を当てています。
また、ソフトウェア開発のライフサイクルには主要な指標があります。リードタイムはバックログ追加からデプロイまでの時間を指し、サイクルタイムは開発着手からデプロイまでの時間を表します。また、チェンジリードタイムは最初のコミットからプロダクションデプロイまでの時間を意味します。
アーキテクチャ刷新は、その目的によって異なる側面の開発生産性に影響を与えます。保守性向上や変更のしやすさを目指す場合は、狭義の開発生産性（サイクルタイム、チェンジリードタイムなど）に影響を及ぼします。一方、組織構造の整理を目的とする場合は、広義の開発生産性やリードタイム全体に影響を与えることになります。
「Chatwork」では、過去にメッセージ機能のリプレイスを行いました。当初は大規模なリプレイスを計画しましたが、途中で方針を変更し、メッセージ機能に焦点を絞ったリプレイスを2017年頃に実施しました。その後も、複数のサブシステムの実装とリリースを続けています。このアプローチは、段階的なアーキテクチャ刷新の一例として捉えることができます。
アーキテクチャの進化を描くタスクフォースチーム
今後のアーキテクチャ刷新の計画や全体をどうしていくかという点については、不透明な観点が多くなっていました。そこで、今後のアーキテクチャの進化の戦略をより明確にして、組織の構造もそれに合わせてアップデートしていくために、タスクフォースチームを結成しました。
タスクフォースチームの役割は、将来必要になるであろうアーキテクチャとそれに対する組織体制を定義することです。そこへ向かう道筋を示して、組織全体が今何をするべきかを理解している状態を目指しています。
チームメンバーを集める際に考慮したのは、既存の仕組みや仕様について詳しい人を招集したい、ということでした。各チームのリードエンジニアを集めて、バランスよく招集しました。最終的に私と4人のエンジニアでこのタスクフォースチームを結成しました。
具体的なタスクとしては、現状（As Is）の分析をしっかり行い、それに対してどういうビジョン（To Be）があるかというところから描き、現状からビジョンへの道筋にどういう選択肢があるかを、大きく3つのステップで考えました。
このタスクフォースは3週間というタイムボックスで区切り、1週間ごとのスプリントで、ステークホルダーを集めてスプリントレビューを実施しました。
タスクフォースチームで現状分析を行った結果、リリースから10年を超えた巨大なモノリスのシステム上に、ほぼすべての機能が実装されているという点が、冒頭で挙げた課題の主な原因だろうという結論に至りました。
ですが、モノリスと言ってもさまざまな種類があります。『Team Topologies』という本を参考に、「Chatwork」では主に3つのモノリスの特徴が当てはまっていると考えました。
- アプリケーションモノリス
- データベース結合モノリス
- モノリシックビルド／モノリシックリリース
私たちはこれまで、アプリケーションの分割に注力しようとしていました。ですが、一番の課題はデータベース結合モノリスであり、それを解消しない限り、本質的な課題解決にはつながらないのではないかという結論に至ったのです。
なぜなら、アプリケーションを分割したところで、データが複数のアプリケーションで共有されているとデータモデルが変更しづらく、アプリケーションの独自進化ができないからです。いわゆる「分散モノリス」の状態からは脱することができないんです。
アーキテクチャ移行に向けた戦略
リプレイスを具体的にどのように進めていくかについて、大きく2つのパターンを検討しています。
- デプロイメントを分割し、その後アプリケーションコードとデータベースを分割していく方法
- データベースをまず分割し、分割されたデータベースを利用してサブシステムを実装する方法
まず、デプロイメントから分割するパターンについて説明します。このアプローチでは、ビジネスドメインの節理面を分析し、その境界でシステムを切り分け、チームを分割していきます。
例えば、APIのエンドポイント単位で分けていき、ALBなどでルーティングして各チームのシステムへリクエストを流します。このパターンのメリットは、節理面さえ分かれば、各チームがソースをそのままコピーするだけで簡単にチームの分割が実現できることです。そのため、早い段階でチームの分割が可能になります。
ただし、デメリットもあります。一度デプロイメントを分割してしまうと、分割後それぞれが独自の進化を遂げた後、元に戻すのが非常に大変です。また、データベースはそのままになってしまうため、データベース結合モノリスの負の側面を強めてしまう可能性があります。
デプロイメントの分割の進め方ですが、まずは節理面に従って分割します。データベース結合モノリスの負の側面が強まるので、早めに自チームで管理するべきデータを特定すべきです。特定できたら既存のデータからのデータ移行を計画します。アプリケーション分割からできるだけ早いタイミングで、自チームで管理するデータストレージを作るのが望ましいでしょう。
次に、データベース分割から始めるパターンについて説明します。これはアプリケーション分割の前にデータベースから分割するパターンです。担当ビジネスドメインを分析して、自分たちが所有しているデータをまず明確にします。そして、担当ビジネスドメインの専用データベースを構築し、最終的には専用データベースに対してサブシステムを構築します。
このパターンにはメリットがあり、データベース結合モノリスの問題に早い段階でアプローチできます。ですが、実際には非常に難しい作業で、各チームが独立したチームになるまでにはかなり時間がかかると予想されます。
そのため、これら2つの戦略をうまく組み合わせながら分割を検討し、段階的に進める方法を模索しています。少しずつ価値を作りながら進めていきたいと考えています。
今後のモノリス解消に向けて、組織体制の変革
モノリス解消は単に技術的な課題ではなく、組織的な課題でもあります。システムアーキテクチャと組織構造は密接に関連しているため、モノリスを解消し、より柔軟なアーキテクチャに移行するには、それに合わせた組織体制の変革が必要です。
これまでのシステム分割やリプレイスの進め方として、専任のチームを作ってプロジェクト的に進めていました。しかし、これには大きな課題がありました。
まず、システムリプレイスそのものが非常に難易度が高いという大前提があります。また、開発人員が多く必要になるため巨大プロジェクトになりやすく、負債返済のチームと機能開発・運用保守のチームにはっきりと分かれてしまいます。これにより組織が分断してしまうという問題が生じます。
さらに、技術負債の返済やアーキテクチャのリプレイス、機能開発、運用保守にも同じようにドメイン知識が必要になるため、両方に同じドメイン知識が求められ、結果として必要なパワーが2倍なってしまうという課題がありました。
そこで、私たちは組織体制の変革を通じてこれらの課題を解決し、同時にモノリス解消を促進する方法を検討しました。今後は、できる限り専任のチームは作らずに、全チームが機能改善や運用保守と並行しながらシステム分割を遂行できるような状態を目指していきたいと考えています。
ただし、完全にこの状態を目指すのは難しく、どこかにオーケストレーションのような機能が必要になってくると思われます。そういった機能をどこに置くかという課題はありますが、基本的には各チームの状況をそれぞれが判断しながら進めていくという方向性を目指したいと思っています。
このような方針を採用する理由は、巨大なプロジェクトにするのではなく、少しずつ機能開発と並行して進められる状況を目指したいからです。これは、モノリス解消の段階的なアプローチと一致します。
また、同一ドメインの知識を有したチームでモノリス解消を進めていきたい。さらに、状況に応じて新規開発に注力でき、ビジネスの変化に応じやすくしたいといった理由もあります。
このように、組織体制の変革はモノリス解消と密接に関連しており、両者を並行して進めることで、より効果的にシステムの改善と開発生産性の向上が図れると考えています。
以上が、タスクフォースチームで取り組んでいる内容です。一筋縄ではいきませんが、モノリスを解消して開発生産性を飛躍的に向上させ、チームと会社が幸せになる未来を目指していきます。
