リリースから12年！ Chatworkの過去をふりかえり ~ ChatworkとPHPの歩み ~

2023年11月8日におこなったChatwork社イベントの登壇資料です。

PHP開発ってどうですか？「Chatwork」を通じて見る、開発のリアル
https://chatwork.connpass.com/event/298193/

Transcript

1. リリースから12年！ Chatworkの過去をふりかえり ~ ChatworkとPHPの歩み ~ PHP開発ってどうですか？「Chatwork」を通じて見る、開発のリアル 2023年11月8日
2. 1 Stripe Tour Tokyo 2023 「Chatwork」開発の歴史 「Chatwork」とPHPの関係性 今後の「Chatwork」について AGENDA 2 3
3. 自己紹介
4. 4 プロフィール Chatwork株式会社 執行役員 兼 プロダクト本部長 田中 佑樹 2013年にChatwork株式会社へジョインし、UI刷新プロジェクトの Webフロントエンド開発や外部向けREST API開発、メッセージ検索 サーバー刷新など数多くのプロジェクトを担当。 現在は執行役員兼プロダクト本部長として、組織改善のために尽力す る。 現在の仕事 組織開発、採用など、部署横断のお仕事が中心 趣味 サウナ、ビール
5. Chatworkの紹介
6. 会社概要 6 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 グループ従業員数 所在地 東京、大阪 設立 2004年11月11日 411名（2023年6月末日時点）
7. 7 一部の先進的な人だけではなく、 世界中で働くあらゆる人が、自分自身の働き方を 常に「一歩先」へと進めていける プラットフォームを提供する すべての人に、 一歩先の働き方を 働くをもっと楽しく、 創造的に　 人生の大半を過ごすことになる「働く」という 時間において、ただ生活の糧を得るためだけではなく、 1人でも多くの人がより楽しく、自由な創造性を 存分に発揮できる社会を実現する Vision Mission ミッション・ビジョン
8. 事業概要 • ビジネスチャット「Chatwork」を中心に、複 数の周辺サービスを展開 • 導入社数は41.0万社*1を突破 • 電話やメールから効率的なチャットへ、ビジネ スコミュニケーションの変化を加速させ、 プラットフォーム化を目指しています 8 *1 2023年6月時点
9. 9 普及率は18.6％*2ほどで、非常にポテンシャルが大きいマーケット コロナ禍やDX推進の流れを受け テレワークが急激に普及*3 未だ低水準に止まる ビジネスチャット国内普及率*2 全業種に展開可能な 潜在市場規模(TAM*1) 国内労働人口 6,724万人 Chatwork 料金単価 6,455億円 *1 実現可能な最大の市場規模（Total Addressable Market）。外部統計資料や公表資料、当社保有のデータを元に当社が想定する市場を推察した市場規模であり、客観的な市場規模を示すものではありません。 *2 当社依頼による第三者機関調べ、2023年3月調査、n＝30,000 *3 内閣府「第5回 新型コロナウイルス感染症の影響下における生活意識・行動の変化に関する調査」より ビジネスチャットの市場環境 テレワーク率の変化 東京23区 全国 単位：% ビジネスチャット ツールを利用して いる
10. プロダクトのターゲットを中小企業としているため、 主要な競合とは、中心となるターゲット層が異なっています 10 「Chatwork」の企業規模別 有料ユーザー割合 「Chatwork」の業界におけるポジショニング 企業規模 大 企業規模 小 ITスキル 低 ITスキル 高 B社 中小企業を中心とした独自のポジショニング B社 A社 *1 2022年12月末時点 有料ユーザーのうち、ユーザー数ベースで 1社あたり300人以下の契約が79.7%を占める*1 ※中小企業が大半であり、個社依存が少なく安定
11. 11 • ビジネスチャットは、業種や職種問わず、全従業員が業務時間中を通して使い続け るという特性を持つ • そのため、トラフィック量が膨大になる傾向 • 24時間365日止めることのできない、ビジネスにおける”インフラ”となるサービス ＝パフォーマンスとシステムとしての信頼性、どちらも高いレベルで担保する必要がある 高い非機能要件 利用ユーザーの多さ 導入社数 ※ 2023年6月時点 41.0万 登録ID数 621.4万 DAU 108.6万 現状のトラフィック量 www.chatwork.comのCloudFrontのメトリクス。 リクエスト量が現時点（※）で毎分88万ほど。 秒間約1.5万のリクエストをさばいている。 ※ 2022年12月時点 開発における特徴
12. 12 PHP Conference 2023 ブース出展しました！
13. 1 「Chatwork」開発の歴史 テーマ
14. 「Chatwork」はリリースしてから12年！ • 「Chatwork」というプロダクトはリリースしてから12年の歴史があります ◦ 2011年に正式リリース • 実は他社チャットツールよりも歴史が長い！ ◦ Chatwork：2011年3月1日 ローンチ ◦ プライベート用コミュニケーションツール：2011年6月23日 ローンチ ◦ 外資系チャットツール：2013年8月 ローンチ 14
15. 「Chatwork」のUI変遷
16. ※比較対象：現在のUI 16 etc
17. 2011年 β版（社内リリース版） 17 etc
18. 2011年 ファーストリリース 18 etc
19. 2013年 初の大規模UI刷新 19 etc
20. 2014年 ロゴ・カラーテーマの変更 20 etc
21. 2016年 チャット一覧のUI刷新 21 etc
22. 2020年 お色直しPJ ダークテーマ対応、色の統一化 22 etc
23. 2 「Chatwork」とPHPの関係性 テーマ
24. 「Chatwork」とPHP • 「Chatwork」はリリース当初からサーバーサイド言語としてPHPを採用 • 現在に至るまで、長期間にわたりお世話になり続けることに • 現在は一部機能をScala化はするものの、大部分はPHPのまま 24
25. システムリプレイス挑戦の歴史 • 2011年、リリースし順調にユーザー数が伸び始めていたが、同時に技術的負債も たまりつつあった ◦ 元々社内システム前提で作られていたものだったため、スケールすることを考えた 構成ではない ◦ 独自フレームワークの上に成り立っている • これ以上の負債を抱える前に、抜本的な改善をすることを 決断、システムリプレイスを計画 ◦ 全エンジニアで言語選定合宿を決行（2014年） ◦ 上記選定合宿にて、Scala言語を選択 25 記事URL：https://c-note.chatwork.com/post/82673710090/dev-camp
26. • Scalaエンジニアの採用も成功し、リプレイスに本格的に乗り出す • 年単位のPJを実施-> システムが巨大なため難易度が非常に高く、途中でストップ判断 • 再度、スコープをメッセージ機能のみに絞り、リプレイスを再開 • 無事、メッセージシステムのリプレイスに成功（2016年末） • 現在も技術的負債の返却を目的として、継続してリプレイス計画を実施中 システムリプレイス挑戦の歴史 26
27. データストレージ / キャッシュ 実行基盤 検索サーバー メッセージングシステム モバイルアプリ Web UI API エンドポイント 現在のシステムの全体像 27 S3 Aurora DynamoDb ElastiCache
28. 現在のシステムアーキテクチャ 28 etc
29. 現在のシステムアーキテクチャ 29 etc PHP Scala
30. 現在のシステムアーキテクチャ • 一部Scala化はしているが、PHP製のアプリケーションは多い（体感7割程度はPHP） • 機能ごとにScala製のアプリケーションにサブシステム化 • ユーザーからのリクエストはすべてPHP製のアプリケーションで受け取り、部分的に Scalaのアプリケーションに流している • 「Chatwork」のコア機能に関してはほぼすべてPHPで動いている ◦ 例 ▪ グループチャット　 ▪ チャットメンバー ▪ メッセージの既読・未読 ▪ タスク ▪ ファイル ▪ etc… 30
31. 現在の課題 • 一部はリプレイスはしているものの、まだまだ技術的負債は溜まっている状況 ◦ 独自フレームワーク ◦ -> 学習コストも高い • システム的にはほぼ巨大なモノリスの上に成り立っているため、複数チームができても 同一のシステムをさわるしかない ◦ -> 認知負荷が高い ◦ -> 意思決定がチームに閉じない 31
32. 3 今後の「Chatwork」について テーマ
33. PHPのシステムはすべてリプレイスされていく？ • 現時点では、答えはNo • PHPのシステムをすべてリプレイスしていくのは、現実問題として非常に難しい ◦ リリース後10年以上の超巨大なシステムであるため • PHPのメリットを理解した上で利用し続ける 33
34. PHPとScalaの使い分け 大きな使い分けとしては以下 • 以下はScalaを使うことを検討 ◦ 新規機能開発で、かつ大規模なプロジェクトの場合 （ハイスループットなど、非機能要件が高い場合など） ◦ EventSourcingのようなアーキテクチャを採用したいとき（Akkaを使いたいとき） • 以下はPHPを使うことを検討 ◦ 既存システムとの依存が強いもの また、以下のようなシステムについてはPHPからのリプレイスを検討 • スループットが巨大すぎて、システム的な限界が来そうな部分 34
35. PHPアプリケーションとしての進化 • 課題 ◦ 現状もPHPのコードの大部分は独自フレームワークの上で成り立っている • 今後 ◦ リプレイスされないPHPアプリケーションのコードも進化が必要 ◦ すべてをリプレイスするわけではなく、部分的に技術的負債を解消していく活動を 継続していく ▪ おそらく地道な道のりをコツコツと登り続けるしか無い ◦ 最終的には独自フレームワークからは脱却したいが、これを目的化しない ▪ あくまで「今後の開発生産性の向上」を目的とした手段として捉える 35
36. 組織としての進化 • 課題 ◦ 現状は巨大な一つのモノリスなシステムなため、各チームでのコミュニケーション がかならず発生してしまう • 今後 ◦ 各チームにシステムが閉じる形へ変更していく ▪ -> コミュニケーションがチーム内で完結しやすくし、開発から運用まで 一貫して責任を持たせる • 打ち手 ◦ 現在もシステムリプレイスを長く継続中、リプレイスにて一部マイクロサービスの ような形へしていく ◦ 各チームにて自律的に動けるような支援（ScMの育成、役割を定義） 36
37. 3 まとめ テーマ
38. まだまだやるべきことは多い • 「Chatwork」の歴史のふりかえりから、現在の課題、今後の動きについて紹介しました • まだまだ課題は多いものの、一歩ずつできるところから進んでいきます • 特に、PHPエンジニアの方の挑戦の幅は広いと考えています ◦ 今後、システムリプレイスは計画中ですが、中長期的に見てもやるべきことは多い • また、PHPだけでなく、いくつかの方面にもチャレンジの幅があります ◦ Scalaや他言語への挑戦など • 歴史の長いシステムにて、一緒に挑戦していただける仲間を募集しております 次のセッションでは、実際に現場で働くPHPエンジニアの生の声を聞けます！ ぜひお楽しみに 38
39. 働くをもっと楽しく、創造的に