ビジネス成長に不可欠なプロダクト組織のあり方について[CTO meetup]

ビジネス成長に不可欠なプロダクト組織のあり方について

※本記事は2023年2月に公開された内容です。

Chatworkは、2011年にリリースされたビジネスチャットツールです。Chatwork株式会社は2019年9月に上場を果たし、2021年2月に初めて中期経営計画を発表。3年間でプロダクト組織は40名から100名規模まで拡大しましたが、その過程にはさまざまな課題があったそうです。
Chatworkが果たしてどのようなプロセスを経て壁を乗り越え、ビジネス成長をしてきたのか。執行役員CTOである春日 重俊氏に、その変遷を事業フェーズごとに解説していただきました。

CTO関連の求人案件の検索はこちらから

2月10日に開催したCTO meetup「関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略」

関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略

CTO meetup初の試みとして2023年2月10日に大阪なんばのイベントスペースFun Space Dinerを貸し切り、関西のCTO/技術責任者10名をお呼びしカンファレンス形式でオフラインイベント「関西CTO/技術責任者10名が語るDX時代のエンジニアリング組織戦略」を開催しました。
採用/育成/技術戦略をはじめとしたエンジニアリング組織戦略を軸に、各社での取り組みをお話しいただきました。

春日 重俊氏

「ビジネス成長に不可欠なプロダクト組織のあり方について」をテーマにChatworkの執行役員CTO 春日 重俊氏にセッションいただいた内容をご紹介します。

Chatwork紹介

会社概要

自己紹介 春日 重俊氏

スピーカーの春日と申します。私は2016年1月にChatworkにジョインし、現在在籍して8年目となります。最初はエンジニアを管掌していましたが、徐々にデザイナー、プロダクトマネージャーという形で干渉範囲がどんどん広がり、最近ではM&AのプロダクトPMI業務まで手掛けています。

Chatworkのコーポレートミッションは、「働くをもっと楽しく、創造的に」で、ビジネスチャットツールChatworkをメインに現在はさまざまなサービスを展開しています。「中小企業No.1からビジネス版スーパーアプリへ」という形で、投資を最大化しているフェーズです。
背景にあるのは、2020年のコロナ禍です。ビジネスチャットツールがキャズムの壁を超え始めて事業フェーズが変化してきたので、投資する意思決定をしてマジョリティ市場でシェアNo.1を獲得するために取り組んでいるところです。

中期・長期経営計画

中期・長期経営計画

当社は2019年9月に上場しましたが、CAGR――年平均成長率は40%を目標に頑張っています。売上高はマザーズ上場以降順調に成長し、再度Jカーブを描きました。いわゆるスタートアップ的な動きが、今は段々と落ち着きつつある状態です。
規模感としては、KPIハイライトを見ると例えば登録ID数が574.1万、課金ID数が66.9万、NRRが122%などです。なかなか良い規模感なのではないかと自負しています。

中期経営計画としては、Product-Led Growth(PLG)とHorizontal×Vertical、DXソリューション戦略を掲げています。PLGは日本では珍しいのですが、プロダクトを通じてグロースを成功に導くことを主戦略として考えるものです。PLGを採用している最近の有名所で言うと、ZoomさんやShopifyさんですね。彼らも、プロダクトを通じてカスタマーを呼んでいます。
よく言われるSaaSはどちらかというとSales-Led Growthで、セールスを通じてエンタープライズに展開していきます。一方、私たちは中小企業のお客様がメインターゲットなので、マーケティングコストはエンタープライズほど効率がよくありません。プロダクトを通じてお客様を獲得する必要があるということで、PLG戦略を採っています。

長期ビジョン

長期ビジョンでいうと、ビジネスチャットを通じた形のビジネス版スーパーアプリを目指し、さまざまなプロダクトをリリースしようとしています。最近は、ストレージや勤怠管理サービスを提供している企業をM&Aしました。
今回の発表の後半でもご紹介させていただきますが、今後はBPaaS――Business Process as a Serviceという形で、ビジネスチャットをインターフェースにしながらマジョリティ市場に事業を展開したいと考えています。

事業フェーズと組織の壁

強力な競合他社の影響を受けず指数関数的に成長

ユーザー数の推移

Chatworkは2011年3月に提供開始し、2023年で12年目です。ちょうど干支が一周回るほど長く続いているサービスですから、成長とともにさまざまな壁がありましたので、時系列で皆さんに共有できたらと思います。
簡単にマーケットに触れておくと、労働人口が6700万人ほどで、これらを全て獲得すると6000億円以上の規模にもなる、大きな市場です。我々はその中で、「ITスキルはやや低い」「企業規模はやや小さい」層をターゲットとしているため、競合企業と被らないマーケットを獲得できているのが特徴的です。
ユーザー数は直近でいうと600万近くにまで伸びてきています。強力な競合サービスの影響をあまり受けずに指数関数的な成長を遂げられたのは、マーケットやターゲット層の状況を如実に示していると考えています。

Chatworkが経た「The Process」

事業フェーズ毎の組織の壁

ここからが、本日お伝えしたい部分です。大前提として、「The Process」という、スタートアップが成長するために必要なプロセスがあります。私がChatworkに入社したのは、ちょうどThe Processの図で表されるところの「Tech Crunch」の時期でした。調子に乗った後にズドンと落ちる体験を経て、ようやく向上できた形です。

組織のコンセプト自体には、コンウェイの法則で言われるような技術と組織の切り離せない関係があったと考えています。システムと組織構造が、非常にリンクしているんですね。Chatworkのプロダクト人材は現在100名を超える大きな組織規模になってきていますが、そこもやはりコンウェイの法則に則り、システムと組織がリンクしながら成長してきた特徴があります。

そんな当社がどうやって試行錯誤をしながら成長プロセスを乗り越えてきたのかについて、これからご説明していきます。

試行錯誤の歴史

悲しみの谷

悲しみの谷

それでは最初に、The Processにおける「悲しみの谷」――苦しい時期についてお話しします。当時のChatworkがどんな構造だったかというと、2011年のサービスローンチから第二進化形態になったところでした。RDSとEC2のシンプルな構成だったところから、キャッシュやSQS、検索エンジンを用いて負荷分散できるようなシステムになっています。

体制面の課題は、サービス成長に比べて組織の規模が脆弱で、CTOが一人だったことです。エンジニア組織を直接管轄していても、マネジメントが弱かったですね。提供機能別の組織デザインになっていましたが、インフラのメンバーは専属が1名のみで、毎日オンコールが鳴って夜寝られないような時期もありました。これが2014~2015年頃です。スタートアップは3年に一度リプレイスしたくなると言われますが、そんな時期ですね。今回参加されている多くの皆さんも、そのうち実感されるフェーズだと思います。

そして私が2016年1月にジョインさせていただいたのですが、一番のボトルネックは、やはりチャットという24時間365日稼働する提供レベルの高いサービスに対して、インフラチームがないことでした。これは不健全だろうと、入社してすぐに経営陣に掛け合ってSREチームを組成しましたね。このときちょうどオライリー氏のSREに関する書籍が出版され、SREというワードは頻繁に耳にするようになっていました。
当時のSREチームのメンバーは1名ではありましたが、それでも徐々に拡大していけば、安心安全な運用が可能です。SREの人材は貴重ですし、サービス規模が拡大したため現在も募集はしていますが、チームでSREを実施できるようになったのは、一つ大きく乗り越えた壁だと思っています。

約束の地へ

約束の地へ

「サービスがダウンするかもしれない」という心理的安全性が低い状態を乗り越えた後に、次に我々がどのように綺麗なグロースを遂げたのかを示すのが、The Processの「約束の地へ」です。いわゆる好転してきた時期ですね。私が入社してから約1年です。サービスの利用規模が拡大したため、今のChatworkのメッセージ機能を支えているHBaseやCQRSといった大規模分散システムを導入しました。

組織的には開発本部というCTO以外のミドルマネジメント機能を追加したり、技術領域で組織を集約したりしました。結構いろいろと変更していますね。サービスも安定してきたので、定常的なアップデートをするプロダクトマネジメントチームも作っています。どういう機能を作るべきなのか、事業的に判断する一本の芯が通ったのは、大きな構造の変化でした。
プロダクトのバックログがたくさん来るため、Product CouncilやMeta Scrumなど、いわゆるイシューをどのようにディスカバリーで届けるかというワークフローも併せて作っていきました。

プロダクトを作るためには、何を基に優先順位を決めて開発をしないといけないのか、インプットとアウトプットのバランスも重要です。市場理解・ユーザー理解、競合理解・自社理解、MVP設計、Go to Market、成果測定。大きくはこの5つのステップがあると考えています。
私たちは常にプロダクトを開発するためのライフサイクルを回していますが、その中で「プロダクトを誰の何のために提供するのか」を振り返って明確化する、PRDも作成しています。これはシリコンバレーでは当たり前に実施されているやり方で、開発者とPM、営業とカスタマーサクセス間の手戻りを少なくするための動きができるようになりました。その後はどのようにバリューを生むべきなのか、ユーザーストーリーマッピングも作成しています。
また、本当に事業課題を解決できるかどうかを知るためには、目標となる指標を立てないといけません。そこでKGIやNorth Star Metricを立ててプロダクト開発をしています。
これはあくまでも一例ですが、結果的に手戻りがなくなるため個人的にはこういうサイクルをきちんと回したほうがいいと考えています。

あとはリスク面についても対処しました。ある程度ユーザーが増えてくると、機能は追加するだけではなく利用されてない機能は削除することも発生しますし、既存ユーザーが離れてしまう可能性があります。そのリスクをきちんと鑑みた上で、ユーザー体験やセキュリティ、事業的なリスクなどを加味したプロダクト開発が必要になると考えました。
リリースタイミングもありますね。対外的な効果を踏まえ、いつ、どのタイミングでユーザーにどういう形で送るのかを考えるべきです。作りっぱなしもよくないので、きちんと狙った指標の改善ができたのか、仮説検証も重要な観点ですね。

流動性の獲得

流動性の獲得

以上のような流れで順調なステップアップが始まったのに続いて、次は流動性の獲得――非連続の成長時期ですね。上場前後ぐらいと思っていただければと思います。当時のChatworkのシステムはDAUが100万近い規模で、少しでもサービスがつながらないとTwitterやヤフーでトレンド1位になり、10~30分止まるとITメディアの記事にされるようになってきました。一瞬たりとも気が抜けないサービスです。

いかにサービスを落とさないかが非常に重要になってきたので、このときはマイクロサービス化を行い、全てのサービスが止まらないような形にしています。モノリスの場合、機能が複雑化するとデプロイスピードも遅くなってしまうので、提供機能別に分けた上でのマイクロサービス化を推進しました。SREでも、インフラ化しているサービスに対して少しずつカオスエンジニアリング的な概念を導入し始めています。

体制面でいうと、1~2年前からいわゆるフィーチャーチームという形に変更しました。提供チーム別に事業目標を持って動き、それを支えるようなピープルマネジメントをVPoE室で実施しています。さらにそれを支えるようなアーキテクトチームが存在するような構想になっています。
このあたりについては、ChatworkのDevHRについて調べていただくと、具体的にどういう組織開発を行っているのかを見ていただけます。人事とエンジニアが一緒に組織開発を行う珍しい事例になっているので、ぜひご覧ください。
現在Chatworkはスーパーアプリ化成功に向けたチャレンジをしているフェーズで、コアとなるビジネスチャット事業を展開しながら、複数事業を成功させていくのが重要なキーとなっています。

買い手の登場

Chatworkが展開するBPaaSのイメージ

さて、ここも非常に重要なポイントなのですが、基本的に、事業戦略と組織戦略は紐付かなければいけません。これはちょうど今日、IRでも説明させていただきました。できたてほやほやの資料がありますから、その内容についても解説させていただきます。
もともと2021~2022年の中期経営計画では、ビジネスチャットをどう伸ばすかという観点でProduct-Led GrowthとHorizontal×Vertical、DXソリューション戦略を掲げていましたが、2023年はビジネスチャットをメインにしたコミュニケーションプラットフォーム戦略と、それを支えるマジョリティ層を開発していくためのインキュベーション本部を2軸とした戦略を展開していこうとしています。

インキュベーションの点で我々がやろうとしているのが、BPaaSです。私たちが提供しているようなアプリケーションやサービスはSaaSで、ビジネスプロセスごとクラウドで提供するのがBPaaSです。これはアメリカで先行して成り立っているサービス形態ですね。Chatworkがマジョリティ市場を獲得するためには、ビジネスプロセス自体を提供するのが重要になると考えておりまして、経営陣として意志をもってBPaaSに取り組んでいます。
というのも、日本の労働人口の一番大きいボリュームゾーンのお客様にいろいろなサービスを案内しても、使いこなせずに終わってしまうんです。それでもテキストメッセージでコミュニケーションするチャットぐらいは使ってもらえるので、例えば人の出入りが激しい飲食店などの企業で、出社・退社をChatwork上でコミュニケーションすれば、裏で全て自動化してくれる。そんなサービスモデルを提供していく予定です。
日本企業は大体400万社近く存在すると言われますが、Chatworkはその中の中小企業をメインターゲットに取っていく上で、すでに親和性が高いプロダクトになっています。だからこそ、上記のようなビジネスモデルが開発しやすいと考え、チャレンジしているわけです。
具体的には、Chatworkというビジネスチャットをメインにしながら、窓口的なサービスが今後提供されていくイメージです。自動化しなければ単なる労働集約的なビジネスモデルになってしまうので、いかに自動化エンジンを使うかが大切です。今、世の中にはChatGPT的なアプローチがありますが、そういったものもChatworkならではの形で自動化するのが重要だと考えています。

春日 重俊氏

現在Chatworkの組織は、事業単位で分割し始めたところです。私は今グループCTOの立ち位置で、既存事業にも新規事業部にもそれぞれCTOが存在します。ここを今後拡大させていく上でも、事業戦略と組織開発をリンクさせていく必要があると考えています。
最後は駆け足になってしまいましたが、発表は以上とさせていただきます。ありがとうございました。

まとめ

Chatworkのプロダクト組織が3年間で40名から100名の2.5倍に成長・拡大した背景とその過程における課題について紹介していただきました。
事業フェーズ毎にぶつかる壁や課題も変わってきますので、Chatworkの試行錯誤の歴史は大変参考になりそうですね。

他のセッションのレポートもご覧ください。

FLEXYのご紹介

FLEXYは、エンジニア、技術顧問、CTO、デザイナーの方向けに案件をご紹介するサービスです。
リモートワークや週1-5日、高単価案件など、ご希望に合った案件をご紹介いたしますので、是非お気軽にご相談ください。

FLEXYに登録する

FLEXYとはABOUT FLEXY

『FLEXY』はエンジニア・デザイナー・CTO・技術顧問を中心に
週1~5日のさまざまな案件を紹介するサービスです