リリースから14年目！PHPと歩んだ「Chatwork」プロダクトのふりかえり

2025年1月23日(木)に開催された「「Chatwork」リリースから14年目！PHPで挑む大規模開発の舞台裏」での発表資料です。
イベントページ：https://chatwork.connpass.com/event/340062/
登壇者：株式会社kubell 田中 佑樹
-X（旧Twitter）：https://x.com/tan_yuki

Transcript

1. リリースから14年目！PHPと歩んだ 「Chatwork」プロダクトのふりかえり 「Chatwork」リリースから14年目！PHPで挑む大規模開発の舞台裏 2025年01月23日
2. 01 | 自己紹介
3. 自己紹介 株式会社kubell 執行役員 兼 コミュニケーションプラットフォームディビジョン 副ディビジョン長 田中 佑樹（たなか ゆうき） 2013年にChatwork株式会社へジョインし、UI刷新プロジェクトの Webフロントエンド開発や外部向けREST API開発、メッセージ検索 サーバー刷新など数多くのプロジェクトを担当した。 現在は執行役員として「Chatwork」プロダクトのエンジニア組織の 管掌を担当。
4. 02 | kubellの紹介
5. 会社名 株式会社kubell 代表取締役CEO 山本 正喜 グループ従業員数 557名（2024年9月末日時点） 所在地 東京、大阪 設立 2004年11月11日 会社概要 働く人の心に、薪をくべる存在へ。
6. 6 25人 25人 56人 77人 89人 91人 107人 162人 251人 312人 557人 2011/3 法人化 （設立） 13人 Chatwork リリース 2015/4 シリーズA 3億 2016/1 シリーズB 15億 マザーズ 上場 2004/11 2005 2008 2011 2015 2016 2017 2018 2019 2020 2021 2022 2023* *2023年度からグループ従業員数 2024/9 461人 従業員数の推移 • 2020年頃から、従業員数の増加ペースがアップ • 2022年には300人を超え、現在は上場時の5倍を越え557名に
7. kubellが挑む課題 7 中小企業のDXを推進し、生産性を上げることが日本の課題解決に
8. 事業概要 8 *1 Nielsen NetView 及びNielsen Mobile NetView Customized Report 2024年4月度調べ月次利用者（MAU:Monthly Active User）調査。 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む41サービスを株式会社kubellにて選定。 *2 2024年9月末時点。 • 国内最大級のビジネスチャット「Chatwork」を展開。 業界のパイオニアであり国内利用者数No.1*1、導入社数は60.5万社*2を突破 • 圧倒的な顧客基盤とプラットフォームを背景に、DXされた業務プロセスそのものを提供する クラウドサービス、BPaaSを展開 BPaaS (Business Process as a Service) ビジネスチャット「Chatwork」 お客様 オペレーター
9. ビジネスチャットの市場環境 9 *1 当社依頼による第三者機関調べ、2023年12月調査、n＝30,000 未だ低水準に止まる ビジネスチャット国内普及率*1 普及率は19.0％ほどで、非常にポテンシャルが大きいマーケット ビジネスチャット ツールを利用している
10. 「Chatwork」のポジショニング 10 プロダクトのターゲットを中小企業としているため、 主要な競合とは、中心となるターゲット層が異なっています 「Chatwork」の企業規模別 有料ユーザー割合 企業規模 大 企業規模 小 ITスキル 低 ITスキル 高 B社 中小企業を中心とした独自のポジショニング B社 A社 *1 2024年9月末時点 有料ユーザーのうち、ユーザー数ベースで 300人未満の契約が97.1%を占める*1 ※中小企業が大半であり、個社依存が少なく安定
11. 11 誰でも使えるシンプルな機能で、中小企業マーケットにフィット • ITを専門としないビジネス職をメイ ンターゲットに、機能やインター フェイスを設計 • 複雑なカスタマイズが不要で誰もが 簡単に利用可能 誰もが簡単に使える オープンプラットフォーム フリーミアム • ひとつのアカウントで、社内外と シームレスにやりとりが可能 • 取引先やお客様との間で利用する事 例が多数 • 無料で使い続けられ、活用が進むこ とで有料となる"フリーミアム"モデ ルでサービス提供 • 無料のプランがあることで、取引先 やお客様にも気軽に勧められる POINT 1 POINT 2 POINT 3 「Chatwork」の特徴
12. サービス種類 BPaaSとは BPaaS （Business Process as a Service） SaaS （Software as a Service） PaaS （Platform as a Service） IaaS （Infrastructure as a Service） ハードウェア ミドルウェア アプリケーション ビジネスプロセス 提供範囲 • BPaaSとは Business Process as a Service の略。ソフトウェアの提供ではなく、業務プロセスそのも のを提供するクラウドサービスであり、クラウド経由で業務アウトソーシング(BPO)が可能 • SaaSよりさらに上流のレイヤーをクラウド化する、次の潮流に 12
13. BPaaSは、中小企業DXの本命 13 多数のSaaSプロダクトを使い分けることが困難な中小企業に対し、 業務プロセスやそれらのSaaS活用を代行し中小企業のDXを推進する BPaaS SaaS 業務代行 CRM/SFA Web会議 ストレージ 採用 人事評価 電話代行 SaaS向きユーザー ・自力でツールを選定できる ・経営陣も従業員も使いこなせる 業務プロセスごと依頼・DXも外部に依頼 DXによる業務課題解決を自力で 自社で選定・ 使いこなす ITに詳しい先進層 BPaaS向きユーザー ・SaaS導入の意思決定が困難 ・使いこなしが困難 マジョリティ市場 勤怠管理 労務管理 エンゲー ジメント タスク管理 プロジェクト管理 ドキュメ ント管理 代行する業務の中で SaaSを積極活用
14. 03 | 「Chatwork」のエンジニアリング
15. • ビジネスチャットは、業種や職種問わず、全従業員が業務時間中を通して使い続け るという特性を持つ • そのため、トラフィック量が膨大になる傾向 • 24時間365日止めることのできない、ビジネスにおける”インフラ”となるサービス ＝パフォーマンスとシステムとしての信頼性、どちらも高いレベルで担保する必要がある 高い非機能要件 利用ユーザーの多さ 導入社数 ※ 2024年9月末時点 60.5万 登録ID数 722.1万 DAU 116.3万 現状のトラフィック量 www.chatwork.comのCloudFrontのメトリクス。 リクエスト量が現時点（※）で毎分106万ほど。 秒間約1.7万以上のリクエストをさばいている。 ※ 2024年2月時点 開発における特徴 15
16. データストレージ / キャッシュ 実行基盤 検索サーバー メッセージングシステム モバイルアプリ Web UI API エンドポイント 開発における構成イメージ S3 Aurora DynamoDb ElastiCache 16 DynamoDB OpenSearch Service
17. データストレージ / キャッシュ 実行基盤 検索サーバー メッセージングシステム モバイルアプリ Web UI API エンドポイント 開発における構成イメージ S3 Aurora DynamoDb ElastiCache 17 DynamoDB OpenSearch Service
18. 04 | 「Chatwork」とPHPの歴史
19. 「Chatwork」の歴史 • もともとは社内ツールとして「Chatwork」は誕生 ◦ 別のコミュニケーションツールにて社内のやり取りをしていたが、メッセージ検索ができなかったり、相手がオ ンラインでないとメッセージが送信できないという問題があった ◦ であれば自分たちで作っちゃおう！という考えのもと作られた • 実際に社内で使ってみたらなかなか便利、当時の社長がUstreamにて自社チャットツールを紹介したところ、「ぜひう ちでも使わせてほしい！」という引き合いがあり、「これはいけるのではないか？」ということで商品化 • 2011年3月1日にファーストバージョンをリリース ◦ 他社チャットツールよりもリリースが早い
20. β版（社内リリース版）
21. 2011年 ファーストリリース
22. （参考）現在
23. 「Chatwork」とPHPの歴史 • もともとは社内ツールということもあり、当時現在のような大規模利用を想定していなかった • 当時は別の事業も複数持っており、すべてPHP製でつくられており、かつ社内でのPHPでのエコシステムも多くあった ため、当たり前のように「Chatwork」もPHPで作られた • そのエコシステムの中の一つに、独自フレームワークがあり、現在でもそのフレームワークがベースとなっている
24. 様々な課題に直面 • 急速に膨れ上がるユーザーやスループット、データ量を適切に処理する必要があった ◦ 当時、かなり早い段階ですべてのインフラをAWS上に載せ替えてはいたが、内部的なデータ構造やアーキテク チャはまだ課題がある状態だった • ビジネスチャットという非機能要件が他サービスと比較してまったく異なるが、当時のアーキテクチャはそれらの特性 を考えると無理のある作りとなっていた • 独自フレームワークということで、内部的な進化も難しく、技術的な負債が溜まりやすいような状況下にあった
25. 課題にどう向き合うか？ • 先の技術的な課題が、おそらく今後無視できないものとなることが容易に想像ができた • そのため、今後のアーキテクチャや内部設計、言語などをゼロベースで考え、どうアーキテクチャを進化させるかを立 ち止まって考える必要があった • 上記流れで抜本的な改善をすることを決断、システムリプレイスを計画 ◦ 2014年、全エンジニアで言語選定合宿を決行 ◦ 上記選定合宿にて、言語としてはScala言語をベースにしたシステムに乗り換えるような案を意思決定 ◦ Scalaの選択理由： ▪ 大規模なコードベースであったので、静的型付けな言語の特徴を活かして保守性を高めたかった ▪ 関数型にもオブジェクト指向型にも対応できるため、習熟度に合わせた記述方法ができる柔軟性が魅力的 だった ▪ 当時はあまり採用されるようなケースはなく、チャレンジングな選択肢であり先行者優位として優秀なエ ンジニアの獲得ができることを狙っていた
26. 現在のシステムの全体像 26 データストレージ / キャッシュ 実行基盤 検索サーバー メッセージングシステム モバイルアプリ Web UI API エンドポイント S3 Aurora DynamoDb ElastiCache DynamoDB OpenSearch Service
27. 現在のシステムの全体像 27 データストレージ / キャッシュ 実行基盤 検索サーバー メッセージングシステム モバイルアプリ Web UI API エンドポイント S3 Aurora DynamoDb ElastiCache DynamoDB OpenSearch Service PHP Scala
28. 今後どうしていくのか？ • Scalaをサブシステム的に切り出していくことはできているが、現在地点としてはまだPHP：Scala = 7:3程度 • まだまだPHPのシステム上にコアな機能な多い • すべてをScalaに載せ替えていくのか？ -> No ◦ あまりにも巨大すぎるので、数年単位でのリプレイスは考えていない ◦ 一方で、価値あるものは順次切り替えていくことは考えられる ◦ また、システムの特性として、Scalaではなく別の言語という選択肢もあり得る • 今後はまず、大きなモノリスなシステムに対して、システムが分割できるような状況を狙ってやっていく ◦ 最初から細かく分割するのではなく、はじめは大きな単位で2つに分割することを目指したい ◦ 具体的な方向性については以下の資料を参考 ▪ モノリスから小さなシステムへ / Chatworkシステム移行の現在地と今後について@開発生産性カンファ レンス
29. まとめ • 今後もアーキテクチャの改善については一定の工数をもって取り組んでいきたい • 一方で、PHPのシステムがすべてなくなるということはなく、少なくとも直近ではPHPシステムをベースとした機能開 発や改善は集中することが考えられる • 加えて、アーキテクチャリプレイスや他言語に挑戦していけるような染み出しもできていけるような環境にしていきた い ◦ エンジニアに対しての「挑戦の幅」を広げられるような環境を作っていきたい
30. 働くをもっと楽しく、創造的に 30