自己紹介とセッションの内容
大野木達也氏（以下、大野木）：それではよろしくお願い致します。Chatworkの大野木と言います。ちょっとタイトル堅い感じはしますが、僕からは「大規模スクラム開発に向けたプロダクトマネジメントの取り組み」というところで、お話できればと思います。
まず簡単に経歴など、自己紹介します。もともとはフリーランスとしてや制作会社で、モバイルUIの開発や、Webディレクションやっていて、その後にチャットボット事業の立ち上げをやってました。
そのあとにメルカリに転職をして、最初はカスタマーサービス部のプロダクト連携するチームであったり、カスタマーエクスペリエンスプログラムと言って、NPS（Net Promoter Score）の導入や、顧客の声を分析して改善の企画をあげていくというようなチームの立ち上げをやりました。そのあとプロダクトの部署に移り、PMとしてマーケット管理や監視ツールの領域のプロダクトのオーナーをやってました。2021年4月、Chatworkに転職しました。
現状、プロダクトマネジメントというよりは、Product Operationsという、プロダクト戦略にフォーカスしたチームの立ち上げをやっています。
（スライドを指して）今日は、このあたりのお話をできればと思っています。
Chatworkのプロダクト開発の現状
今のChatworkのプロダクト開発の現状です。今、数年かけて、開発のアーキテクチャの刷新をやっています。その中で、Scrum@Scaleという、大規模スクラム開発の手法にチャレンジしている状況です。
プロジェクト外のところでいくと、スプリントやスクラムセレモニーを活用したチーム開発を今行っていますが、基本的にはプロジェクト型の開発です。なにかやりたい企画が決まったら、そこに対して人をアサインしてチームを作り、そこから開発をして、終わったらチームを解散するようなかたちがメインになっています。
それとは別の視点で、我々の経営方針として、2025年以降に「ビジネス版スーパーアプリ」の構想をあげています。これに向けたプロダクトの戦略も、練り上げていく必要があります。
それに合わせて、開発組織もずっとスケールアップ進めているような状態です。私が入った時は60名ぐらいでしたが、現時点でもう100名弱の組織になっていて。1.5倍以上ですね。プロダクトマネジメント部も、10名（増えました）。
先ほど言ったような、ビジネス版スーパーアプリの構想に向けては、まだ仲間が必要かなと考えています。スケールアップしてく中でも、これから説明するProduct Operationsのような組織が必要になるというところで、その進め方を模索するような状況になっています。
Product Operationsという組織
Product Operationsは、まだあまり馴染みがない言葉なのかなと思います。しかし海外だと、GoogleとかFacebookとかTwitterのような、一定プロダクトが大きくなっている組織は、だいたい存在する組織になっていて。
PMも人数が増えてくると、例えば、その中でグロース領域のチームとか、UX領域のチームとか、いろいろ出てくるので。企画もサイロ化していって、どういうところにどうリソース割いていくか、意思決定が難しくなってきます。
それをちゃんとプロダクトの戦略として、管理・運営をしていく組織が、Product Operationsという組織になると思います。先ほどお伝えしたように、テーマが決まってくるとサイロ化した企画が立ったりするので、ちゃんと俯瞰した課題の探求もやっていく。あと、各PMに対する分析のサポートみたいなこともします。
あと、Chatworkは現状まだNPSとかCSAT（Customer Satisfaction）と言われるような、顧客サーベイみたいなものを、きっちりとってフィードバックのサイクルを回している状況ではないので、このあたりもこれからやっていけたらと考えています。
大規模開発のスクラムのやり方「Scrum@Scale」
最初にお話ししたScrum@Scaleという、大規模開発のスクラムのやり方ですが、これにチャレンジしています。スクラムチームは基本だいたい10名以下で、プロダクトオーナーがいて、スクラムマスターがいて、開発メンバーというかたちで、物を作っていくと思います。
規模が大きくなっていくと、そのスクラムチームが増えていきますが、Scrum@Scaleでは、これを“スクラム オブ スクラム”と言い、もう一つ大きなスクラムにして、それがさらに大きくなっていくというようなかたち、フラクタル構造的にどんどん組織を大きくしていくようになっています。
もう1つ特徴としては、スクラムマスターのサイクルと、プロダクトオーナーのサイクルという2つのサイクルを回すようなイメージになっていて。スクラムマスターサイクルは、開発をどんどんやっていくためのサイクルです。
プロダクトオーナーサイクルは、プロダクトのビジョンであったり、それの優先順位づけ、どういうふうにリリースしてよりよいものを作っていくかを、両軸で回していくというような仕組みになっています。
Chatworkのサイクルの取り入れ方
我々のチャレンジとして両軸でチャレンジしようとしていて、スクラムマスターのサイクルを、今のアーキテクチャの刷新のプロジェクトでやってみる。
中にプロダクトオーナーサイクルがありますが、どちらかというと、プロジェクトの中で回しているようなサイクル。Product Operationsで、プロダクトオーナーサイクルを構築をしているかたちです。ここは経営陣であったり、プロダクト外の本部も巻き込んで進めているものになります。
これは一定で、アーキテクチャがちゃんとできあがった時や、うまくマージできるタイミングが来たら、このサイクルっをくっつけていくことを想定しています。
プロダクトオーナーサイクルですが、フレームワークどおり、1つのメタスクラムみたいなものを作ることは、現状のかたちの中でやろうとするとなかなか難しいというところがあるので、組織に合わせたかたちを模索しているところです。
Chatworkの半数はビジネス本部のメンバーで、あとは上場もしているので、アジャイル的にすぐ経営の方針を変えていくことは難しいです。そのため、このあたりをちゃんとカバーしながらやれるかたちを考えていると。
中長期的な方針を目標とした取り組み
Chatworkは中長期的な方針として、1つは2024年末までとして、ビジネスチャットを中小企業No.1にすることをあげています。その先に、前に少し話したような、ビジネス版スーパーアプリというかたちで、中小企業のビジネスの起点となるプラットフォームにしていくことを考えてやっています。
まだ長期的なところは完全にやり方が見えていないような状況ではあります。私が入ってから進めているのが、経営の計画や戦略に対し、中期経営計画ではマーケットシェアの40パーセントと、全社売り上げ100億にしていく目標が立っていて。
これにプロダクト戦略というフレームを立てつけて、各PMの施策がどういった意味を持つテーマに向けたものなのか、それをやった結果、どうひもづいて中期経営計画の達成に向かうのかを、全体で見える化できるように整えている状況になっています。
その中でやってることとしては、経営の数字に向かうため、そこをトラックするためのダッシュボードを作っています。あとは、これを追えばプロダクトビジョンが達成できるような「プロダクトビジョン」「North Star Metric」という指標。
そして「プロダクトイニシアチブ」という、戦略的なテーマをちゃんと定義した上で、Jiraのプロジェクトで管理をして、というようなところまで整理をしています。
現在までの進捗とこれからの予定
先ほど最初にお話をしたとおり、私は4月に入社して、Product Operationsという組織を立ち上げる準備を、最初のオンボーディングを2ヶ月ぐらいやり、チームの立ち上げで2ヶ月半ほど経ちました。その中で、プロダクトビジョンやプロダクトイニシアチブ、あと、North Star Metricの策定はできてきました。それを発表した上で、ステークホルダーやマネージャーからの反応は、比較的良好かなと感じています。
それを、先ほど少し見せた戦略ミーティングという場所で、経営陣から基本的な承認をもらっているところまでは進めています。プロダクトカウンシルという会議体をこの先で考えていますが、そのためのプレミーティングみたいなところも実施して、本格運営を9月からしていくような状況です。
個人的に、プロダクト戦略を作るところは、比較的プロダクト開発の根幹の部分でもあるので、いろいろなコミュニケーションをとったり、ディスカッションしながら進めないといけない中では、比較的よいペースで進められてるんじゃないかなと感じています。
ただ一方で、長期的な方針のプロダクト戦略とか、ビジネス版スーパーアプリの構想に関しては、まだまだ考えられてないことだらけなので、そのあたりをやっていかないといけません。理想的なスクラム体制もまだ長期戦になりそうだと感じている状況です。 個人的な全体に対する所感になってしまうんですが、Chatworkの事業自体はすごく順調に成長している状況だとは思うので、その中で私としては、恵まれた状況で、先のプロダクト開発を模索させてもらえてるのかなと感じでいます。会社としても、すごく働きやすいと感じています。
ここは先ほどからお話ししているように、いろいろなことをどんどんやっていきたい中では、プロダクトマネージャーもぜんぜん足りません。というところで、カジュアル面談など、興味あれば、オフィシャルでもTwitterのDMでもかまわないので、連絡をいただけるとうれしいです。
というところで、私の発表は以上としたいと思います。ご静聴ありがとうございました。
質疑応答
司会者：大野木さん、ありがとうございました。入社されたのが何月とお話されてましたっけ？
大野木：4月ですね。
司会者：4月か。立ち上げからこれまでの流れとか、成長の経緯が知れて、すごくおもしろいと思いました。質問がいくつか来ています。
「組織のスケールアップに関わるお仕事というお話がありましたが、プロダクトに関わる人数の理想的な規模感などはありますか？ サービスの規模にもよると思いますが、人数が多過ぎて回らなくなることがよくあるので」という質問が来ていますが、いかがでしょうか？
大野木：理想的な人数は、なかなか難しいと思います。前職のメルカリとかだともっと多かったんですが、そちらもけっこうワンサービスで作っていたようなところなので。
おそらく、使う人数であったり、開発者の数が、サービス依存。それこそヤフーさんなんかは、大勢の方が働いてると思うんですけど。いずれにしても、サービスの規模に応じて、成長すれば人が増えていくことが起こるのかなと感じてはいます。その中で、最適なサイズを探っていくようなところなのかなと。
司会者：なるほど。サービスとか、あとは企業の成長とかスケールに合わせて、適宜変えていく感じですかね。
大野木：そうですね。すみません、ふわっとした回答になっちゃいましたけど（笑）。
司会者：確かに、「この人数です」とかっちり決まっているものでは絶対ないので。ありがとうございます。もう1つが「プロダクト戦略の話がとても参考になりました。11ページのスライドの表は、すべてPMが担っているのですか？」。この表だと、右側だけではなくて、左の部分もプロダクトマネージャーは関わってるんですか？
大野木：そうですね。それでいくと、PMもやはりディレクターのレイヤーから、シニアPM、ジュニアPM、いろいろいます。基本的に、上層になればなるほど、プロダクト戦略や経営側に近いところを見ていく。なので、プロダクトマネージャーを全体としてとらえたら、そちらに強く関わる人もいるし、どちらかというと戦術側だけ関わってる人もいると思います。
司会者：なるほど。人によって役割、関わり方が違うということですかね。ありがとうございます。もう1つ来ていまして「KPIを測る指標のモデルが出てきましたが、実際に使われてるモデルはなんなのでしょうか？ AARRRモデルなどいろいろなモデルがある中で、説明のモデルを使われた理由はなんですか？」
大野木：時間的にあまり詳しく伝えていませんでしたが、Chatworkのビジネスチャットというサービス自体は、かなりSaaS型のモデルなので、基本的にはAARRRで測れると思っています。結果としてはそこに出てくるので、指標としてはAARRRを見るというようなところ。KPI自体は書いていませんが、この下にひもづくKPIを設定しているような状況になります。
司会者：ありがとうございます。あと1つだけ。「今開いているスライドは、結果指標と書いてありますが、結果ではない指標も取ったほうがよいですか？」
大野木：まさにそれはそうで、結果はあくまで、中期経営計画に結びつく、近いような指標というところで、定常的にトラックしますが、（スライドを指して）この右側に書いているような施策に対しては、各KPIを設定するということは正しいと思っていて。
これにはマクロなものもあるし、ミクロなA／Bテストとか。セグメントを切った時には、そういうものが指標になってくると思います。
司会者：なるほど。ちょっと質問来てるんですけど、ここまでとします。大野木さん、ありがとうございました。
大野木：ありがとうございます。
