シェア
はてブ
2023年7月13日、ファインディ株式会社が主催するイベント「開発生産性Conference」が、開催されました。本カンファレンスは、KABUTO ONE（東京）のオフライン会場にて実施され、一部のセッションはオンライン配信も行われました。
本記事では、オンラインでも配信されたセッションのうち、Chatwork株式会社でプロダクト本部長を務める田中佑樹さんによるセッション「フィーチャーチーム化への取り組みと、それを支える組織マネジメント体制」の内容をお届けします。
開発体制をプロジェクト型からフィーチャー型へと移行しているChatworkで、どのようにチーム体制の移行に取り組んでいるか、どのようなマネジメント体制を目指しているかなどについて、お話いただきました。
■プロフィール
田中 佑樹（たなか ゆうき）/ @tan_yuki
Chatwork株式会社 プロダクト本部長
2013年よりChatwork株式会社に入社。入社当初はサーバーサイド及びフロントエンドエンジニアとしてプロダクト開発に従事。その後、エンジニアリングマネージャーとして複数部署のマネージメントを経験した後、プロダクト本部 副本部長としてDevHRチームの立ち上げ、プロダクトセキュリティ部の立ち上げを実施。2023年の3月からプロダクト本部 本部長としてプロダクト組織全体の組織課題対応などに継続的に対応中。
DXにより中小企業の生産性向上を目指すChatwork
田中：Chatwork株式会社の田中佑樹と申します。本日はChatworkの開発体制について、いくつか発表させていただければと思います。まずは自己紹介ですが、私はChatwork株式会社でプロダクト本部の本部長として、プロダクト人材に関わる採用や組織開発を中心に担当しています。
経歴としてはエンジニア出身で、フロントエンドやバックエンドの開発を経験したのち、いくつかの部署のマネージャー、今で言うEMのような仕事を経験しました。2019年ごろから副本部長として、セキュリティチームや、DevHRという開発と人事が一体になったチームなど、いくつかの組織の立ち上げを行い、今年3月から本部長として部門を見ています。
本日お話する内容について、Chatworkでは開発生産性向上の取り組みとして、フィーチャーチーム化というものを目指しています。その挑戦における現在のお話や、未来についてお話したいと思います。私たちもまだ道半ばな状況なので、これまでにしてきたトライや、それによってわかったことなどをご紹介します。
本日のアジェンダとしては、まずChatworkという会社やサービスを紹介したのち、今回のお話をするうえで前提となる知識を簡単に紹介します。その後、具体的なフィーチャーチーム化に関する取り組み、マネジメント体制についてお話し、その上でわかってきたことや今後に関してお話できればと思っています。
田中：まずは、Chatworkという会社とサービスのご紹介をさせていただきます。もともとCTOをしていた、現CEOの山本正喜が開発してできたものが「Chatwork」というサービスで、それが成長して今に至ります。
弊社は、「働くをもっと楽しく、創造的に」というコーポレートミッションを掲げています。「働く」時間に創造性をもっと持たせられるようなサービスを展開していくことを掲げており、こうしたテーマをもとに、今後いくつかのサービスの立ち上げも視野に入れています。
ビジネスチャットとしてサービスを展開する「Chatwork」には、代表的な機能として、グループチャットやタスクの管理機能、ファイルの管理、ビデオ音声通話などがあります。
おそらく会場に来られている方々は、ビジネスチャットにSlackやTeamsを使っている方が多いかと思いますが、弊社のターゲットユーザーは主に中小企業の方々です。そういった方々の、DXや生産性向上に貢献することを目指しています。
現在のChatworkにおける、組織とシステムの特徴
田中：続いて、Chatworkの組織についてご紹介します。 社内にはいくつかの本部があり、本部ごとにセクションが分けられています。私が見ているプロダクト本部には、主にエンジニアやデザイナー、プロダクトマネージャーの方々が所属しています。
この部門の在籍人数は、現在およそ100名。エンジニアとデザイナーとPdMの割合が、8：1：1くらいになっています。この部門をくわしく見ていくと、職能ごとに縦割りの組織体系になっていて、例えばフロントエンド開発部、モバイルアプリケーション開発部、サーバーサイド開発部など、「何ができるか」によって部署が分かれています。
田中：次は、「Chatwork」のシステムについてです。「Chatwork」はビジネスチャットという特性上、トラフィック量が他社SaaSに比べて多くなる傾向があります。ユーザーさんが朝に出社して「Chatwork」を開いて、夜まで開きっぱなしというのが基本的なユースケースなので、その間ずっと裏側で通信が発生するんですね。
下記左側のグラフが、現状のトラフィック量です。これは www.chatwork.com のCloudFrontのメトリクスで、ヘルスチェックのリクエストも入っていますが、ピークタイムのリクエスト量が毎分880kほど。秒間で15kくらいさばいています。ピークタイムにスパイクするわけではなく、ビジネス時間帯はずっとそれくらいのリクエストが続きます。
また、現状の利用ユーザーは、導入社数でいうと約40万社（2022年12月末日時点では37.6万社）。DAUとしては、100万以上（2022年12月末日時点では105.3万）のユーザーさんに使っていただいています。下図の右側に数値がありますが、これは2022年12月時点の数値なので、現時点ではもっと多い数字になります。
田中：そして、サービスの特性上、「Chatwork」が使用できない状態というのは、ユーザーさんにとって業務が止まってしまう状況になるため、リライアビリティの担保が非常に重要になります。つまり、パフォーマンスとリライアビリティ、どちらも高いレベルで担保する必要があるサービスです。
また、「Chatwork」は2011年にリリースされ、現在12年目になる歴史あるプロジェクトです。現状は、一つの巨大なモノリスのシステム上で、「Chatwork」のほぼすべての機能が実装されています。そのため、技術的な負債がたまっている状況があり、かつ同一のシステムを触るので、人数が増えれば増えるほどコミュニケーションが複雑化する状況があります。
さらに、システムの巨大さゆえに認知負荷が非常に高くなりやすく、事故につながりやすいことや、変更や追加が難しいといった現状もあり、開発速度が低下しやすくなっています。その打ち手として、現在は数年がかりのリプレイスプロジェクトが進行しています。
Chatworkが目指す、職能横断型のフィーチャーチーム
田中：こうした前提を踏まえて、開発生産性の取り組みにおいて、今やっていることを紹介したいと思います。現在は職能ごとの縦割り組織になっていますが、以前までは大きなプロダクト開発の案件があると、各部署から寄せ集めのプロジェクトチームをつくって対応していました。こういった開発体制のことを、弊社ではプロジェクト体制と呼んでいます。
田中：昔はこのプロジェクト体制で、案件が起案されると、EMの方がプロジェクトに必要な人材を考え、各部署に依頼していました。流れとしては、各部署のマネージャーに「誰々さんを案件にアサインしたいのですが、いいですか？」と、メンバー全員分の確認を行っていきます。
メンバーが集まったら、キックオフミーティングからプロジェクトがスタート。数ヶ月間プロジェクトを進行し、リリースします。そしてリリース後、そのプロジェクトチームは解散していました。
これの何が問題だったかというと、まず1つはイニシャルコストが高くなりやすいこと。プロジェクトの人員確保のためにEMが各部署を行脚しなければならず、かつ基本的に毎回メンバーが変わるので、スタートするたびにチームビルディングが必要になります。
もう1つは、運用主体が不明確になりやすいこと。プロジェクトが終わると解散してしまうため、リリース後の改善や運用において、どこがボールを持っているのか不明確になりやすくなっていました。
田中：こうした背景から我々は、開発から運用まで一貫して責任を持ったチームを用意して、自律して活動できる組織にしていきたいと考えました。そのためにはどうしたらよいか。この問いは、DevOpsを実現するにはどうしたらよいか、とも置き換えられます。
DevOps体制の実現方法のHowとして、職能横断の固定化したチームをつくっていこうと考えています。理想は、都度プロジェクトチームを発足させるのではなく、継続して存続できるチーム。つまり、チームに閉じて立案・開発・運用までを一貫して担当でき、オーナーシップを持って作業ができる、職能横断型の自己管理化されたチームが理想です。
このような職能横断型のチームを、我々はフィーチャーチームと呼んでいます。私たちは今この体制を大きく3つのチームに分けて考えています。
- フィーチャーチーム：事業価値を創出するチーム
- プラットフォームチーム：フィーチャーチームの認知負荷を下げるために、技術支援や教育を行う支援特化型のチーム
- ピープルマネジメントチーム：横串で各チームをマネジメントするチームです。
田中：現状、上記体制の移行を目指し、組織を少しずつ変化させている状況です。なお、この構想は、組織設計について書かれた『チームトポロジー』という本が出る前に考えたもので、チームの名称が一致していません。
先ほど挙げたフィーチャーチームは、『チームトポロジー』でいうストリームアラインドチームです。私たちがプラットフォームチームと呼んでいるものが、『チームトポロジー』で定義されているプラットフォームチームとイネーブルチームを、合体させた概念になっているかなと思います。
ややこしいことに、どちらにもプラットフォームチームがあるという状況なのですが、本日の発表内でのプラットフォームチームは、我々が定義するプラットフォームチームを指すこととさせていただければと思います。
なお、我々が定義したピープルマネジメントチームは、『チームトポロジー』では定義されていません。『チームトポロジー』では、コンプリケイテッドサブシステムというチームが定義されていますが、これはフィーチャーチームとプラットフォームチームの間くらいという認識です。
適切な責任分界点を探り、チームを分けていくトライ
田中：フィーチャーチーム体制に向けて、チームをどう分けるか、という大きな課題があります。「Chatwork」は歴史的な積み重ねもあり、膨大な機能があります。
システムを網羅的に保守していくために、機能でもチームを分けていきたい。しかし、前提として先ほどお話した通り、今は巨大なモノリスのシステムになっていて、現在システムリプレイスが進行している状況です。
田中：王道のパターンで言うと、逆コンウェイ戦略に沿って、アーキテクチャを分割し、そこにチームを割り当てていく方法があります。ただ、現状はシステムリプレイス中で、スコープを区切りながら少しずつ進めており、完全な移植は先になることが見えています。
つまり、現在の状態で進めるとしたら、モノリスなアーキテクチャ上にフィーチャーチームをつくっていく必要があります。こうしてチームを分割してしまうと、同じシステムを複数のチームで触ることになり、コミュニケーションが煩雑になりやすい。そうなると、フィーチャーチーム化する旨味が減ってしまいます。
こうした状況のなかで、現状は「できるところからやっていく」というトライをしています。システムは同じでも、完全ではないにせよコミュニケーションを疎にできる境界が必ずあるはずだと考え、その点を探りながらフィーチャーチームをつくっています。
そのためには、現在のアプリケーションが、どういうドメインで構成されているのかという、深いドメイン分析が必要になります。適切な責任分界点はサービスによってまったく異なると思うので、一般的な回答は難しいですが、Chatworkではいくつかの分け方を試しながら、現状は決済・料金プランチーム、認証チーム、APIチームの3チームを形成しています。
ただし、この3つではまだ、全機能を網羅的に保守できているわけではありません。残りの部分は今まで通り、職能別のプラットフォームチームで保守運用から開発までを行っている状況です。
現在のフィーチャーチーム体制としては、先ほど触れたモバイルやフロントエンドなどの職能別の部署は、プラットフォームチームとみなしています。フィーチャーチームは、それぞれを部署化しているわけではなく、部署内のチームとして定義しています。なので、1つの部署に複数のフィーチャーチームがあります。
そして、部署内のマネージャーが各チームのピープルマネジメントをしています。プラットフォームチームのマネージャーは現状、プレイングマネージャーがほとんど。いずれは、ピープルマネージメントチームで見ていく体制にしていきたいと思っていますが、まだそこまでは手が回っていない状況です。
フィーチャーチームにおいて目指すマネジメント体制
田中：ここでマネジメントについて、少し深く触れたいと思います。旧来の体制では、職能別の組織で各部署にマネージャー、たいていの場合プレイングマネージャーがついていました。これをフィーチャーチームではどうするか、という話です。
フィーチャーチームでは、それぞれにEMをつけるという案もありますが、個人的には評価者を現場のチームにあまり入れたくないと考えています。「Gorilla in the Room」という言葉がありますが、チームに特定の権威者がいると、その人の発言に引っ張られてしまい、自律性を保てなくなる可能性があるからです。
さらに、EMの方は採用市場でも非常に希少な方々です。技術的な素養に加え、ピープルマネジメントの能力も必要で、そんな方はなかなかいません。場合によっては、プロジェクトマネジメントもしなければならず、EMに負荷がかかりすぎる問題もあります。
なので、私たちは現在以下のような形で、ピープルマネジメント特化のチームをつくり、外からマネジメントする体制を目指しています。このような体制を、弊社ではピープルマネジメント体制と呼んでいます。
田中：この体制のメリットは、EMのリソース効率が良いこと。少ないEMの人数で、より多くのマネジメントができます。また、状況によっては冗長化が可能で、例えばEM2人で1つのチームを見ることができます。EMは孤立化しやすいと言われますが、複数人でマネジメントできることは大きなメリットになります。さらに、チームへの干渉を低減し、チームに自治権を与えることができるとも考えています。
ただ、この体制にもデメリットがあります。まず、1人で結構な人数のマネジメントする能力が必要になるため、VPoEの職能に近く、採用や育成におけるハードルが高くなります。また、ピープルマネジメント一本になるので、プレイングとマネジメントを両立したい人のキャリアパスには不向きだと言えます。
続いて、ピープルマネジメントチームの責務についてです。このチームはピープルマネジメント業務に特化し、各チームが自律性を持ってワークするためのサポートを行います。具体的な業務の例は、メンバーのメンタリング、目標設定、考課査定、勤怠管理、稟議、予算管理。それから、チーム外に落ちたボールを拾うことや、採用、チームメンバーのアサインメントなどがあります。
弊社のCreator’s Noteというテックブログに、ピープルマネジメントに携わるメンバーが書いた「開発組織でピープルマネージャーをやっている」という記事があるので、くわしくはぜひこちらを参考にしてください。
各チームの関わりについては、まずフィーチャーチームが経営戦略に沿った戦略実行に責任を持っています。そして、プラットフォームチームがそれらを技術的にサポートし、ピープルマネジメントチームが人やもの、Opsのオペレーションの整理などをサポートするという関係性になっています。
フィーチャーチーム体制で各チームをつなぐ3つの会議体
田中：ここでAppendixとして、フィーチャーチームの運用に関する内容を、いくつかご紹介したいと思います。
まず、フィーチャーチームの開発プロセスは、スクラムを採用しているケースがほとんどで、POとスクラムマスターを配置し、自律的に動けるチームを目指しています。なかには、カンプランやウォーターフォールを採用しているチームもあり、チームの色に合わせて、それぞれの開発プロセスを選択しています。
また、各チーム間のコミュニケーションに関しては、チーム横断の連絡手段としての会議体が存在しています。代表的なものとして、MetaScrum、EAT（Executive Action Team）、マネージャー定例の3つがあり、こうした会議体にチーム内では解決できない相談事項が持ち込まれます。
MetaScrumは、プロダクトの優先順位や戦略について話し合われる場。主にPOやPdMなど、意思決定者に近い方が集まります。EATは、戦術について話し合われる場。スクラムマスターやエンジニア、チームの代表者が参加します。
マネージャー定例は、人や組織について話し合われる場。人事系のセンシティブな内容も扱うので、比較的クローズドな会議体になります。ここには、各部署のマネージャーやピープルマネジメントチームの方々が参加します。
田中：なお、MetaScrumやEATという単語は、Scrum@Scaleの考え方から採用しています。ただ、Scrum@Scaleでは、MetaScrumもEATも1つのスクラムとして扱われているのですが、私たちはただの会議体として定義しています。
その他の補足事項として、EATはチームメンバーの補填や教育訓練など、人に関する話題も取り扱うことがあります。すべての話題がどこかにきれいに収まるわけではなく、グラデーションがあり、取り扱う先がわからない場合は、どこかの会議体に持っていって適切な場を都度決めます。
あとは、議題の共有範囲についてですね。MetaScrumやマネージャー定例では、秘匿にする必要があるリリース情報や人事情報を扱うことがあるので、共有用の議事録を別途作成して全体に共有しています。
逆に、EATは基本的にすべての議題を全員に共有していて、参加も自由な開放された会議体です。すべてに共通しているのは、議事録を作って誰でも閲覧可能な状態にしているところです。
取り組みのなかで、ぶつかった課題とわかってきたこと
田中：続いて、ここまでの取り組みのなかで、わかってきたことを紹介したいと思います。繰り返しになりますが、現状のフィーチャーチーム体制は巨大なモノリスのシステム上でつくろうとしているため、課題感も大きいです。
特に大きな課題は、担当者不在という状況と、スキルがチームに閉じないという状況の2つ。これは後ほどくわしく説明しますが、課題があるのは当然なので、どこかで妥協点を探るしかないと考えています。
まず、担当者不在については、全機能に対してチームの保守範囲が網羅的でないという状況です。また、全機能に対して網羅的にフィーチャーチームを用意する場合、分け方次第ではありますが、人員が多く必要になりやすい。これはフィーチャーチームが、リソース効率よりフロー効率を重要視する考え方だからです。
そのため、担当者不在となっている機能の運用保守については、以前と同様に、職能別の組織であるプラットフォームチーム任せになってしまい、プラットフォームチーム側の負荷が高くなりやすくなっています。
田中：もう1つは、スキルがチームに閉じないということ。チームでの獲得が難しい職能は、外部に依存する必要があります。足りない職能を持った専門家をアサインすればいい話なのですが、特に専門性の高い職能は人が足りなくなりやすい。そのため、これも外部のプラットフォームチームに依存してしまっている状況です。
今いくつかのチームを見ているなかで、2つのスキルセットが不足しがちなことがわかっています。1つはデザイン。エンジニアが8割の組織なので、エンジニア中心のチームになりやすく、毛色が違うスキルセットは獲得が難しくなります。もう1つは、モバイルアプリケーション開発。これはプラットフォーマー依存のノウハウがあり、経験がないとわからない部分が多いためです。
田中：スキル獲得の問題については、専門家をアサインするのが理想だと思っています。ただ、現実問題としてそういった人の獲得は難しく、現時点ではリソース効率を重要視するための対応をしています。
1つ目は派遣型で、一時的にフィーチャーチームへ専門家を派遣する方法。2つ目は受託型で、フィーチャーチームからプラットフォームチームへタスクを依頼する方法。これらはあまり良くないパターンかなと理解しているのですが、妥協点を探るために、現状こういう対応策を取っています。
今後は人をたくさん採用して、各チームに専門家をアサインしていくことが理想ではありますが、そうなると各専門家が単独でバリューを発揮できる環境づくりも必要になってくると思います。例えば、デザイナーが自走してバリューを発揮するための、デザインシステムやデザインガイドラインの整備などです。
また、上手くワークしているフィーチャーチームの特徴も見えてきました。それは、やはり「チームで閉じている」ことです。例えば、ステークホルダーが外部に存在せず、コミュニケーションがチームに閉じている。あとは、他のチームの助けを借りる必要がなく、スキルがチームに閉じている。他にもいろいろな変数が存在しますが、この条件が変数としては圧倒的に大きいと感じます。
それならチームに閉じればいいじゃないか、という話なのですが、現実はそうもいきません。人が足りなかったり、スキルにばらつきがあったりするので、限られた人員のなかでどうやって妥協点を探るかが今の課題だと思っています。
加えて、フィーチャーチームに適した人材についてもわかってきました。さまざまな職能が必要とされやすいので、スペシャリストよりも、広く対応できるジェネラリスト的な人材が合いやすい。T型人材と呼ばれるような人たちです。
そのため、「私はこれしかやりません」というマインドセットは、あまり良くないなと思います。とはいえ、ジェネラリストだけではダメで、先ほど挙げたような専門性が高い人材も必要です。
課題感のまとめとしては、徐々にフィーチャーチーム化を進めるなかで痛みもわかってきて、妥協点を探る必要性が出てきました。現状は、プラットフォームチームへの人員強化、フィーチャーチーム化できる責任分界点の模索、フィーチャーチームの作成。この3つを繰り返しながら、フィーチャーチームで閉じて運用保守ができる範囲を広げていこうと考えています。
今後の組織体制、フィーチャーチーム化に必要なもの
田中：今後の組織体制についてお話します。フィーチャーチーム化を目指すために必要で、現状足りていないものとしては、適切な責任分界点で分けられたシステムと、人員や組織能力が挙げられます。
田中：そして、フィーチャーチームが上手くワークする環境として、意思決定やスキルがチームに閉じる環境が必要です。かつ、専門家が単独でバリューが発揮できるようなガイドラインの整備など、自律して動ける環境も必要になってくると思っています。
さらに、チームに閉じすぎた際の、サイロ化の暗黒面をできるだけ避ける準備も必要だと考えています。例えば、各職能別のギルドの立ち上げですね。これは既にいくつかボトムアップで立ち上がってきています。また、先ほどお話したような、MetaScrumやEATといった会議体による、横の連携を強化していく必要もあります。
あとは、専門家の関わり方について。専門家がチーム内に入り込むか、派遣型でそのチームに能力がつくようにイネーブルするかは、獲得したい能力やチームの状況により異なると思っています。
例えば、セキュリティのような能力は、程度の差はあれ、各エンジニアが一定レベルで獲得済みの状態だと思います。であれば、横ぐしのセキュリティチームが、各フィーチャーチームに対してイネーブルするだけでもいいかもしれません。これらは現在の状態を正確に捉えて、使い分ける必要があると考えています。
それでは、最後のまとめです。Chatworkの取り組みについてご紹介しましたが、開発生産性の向上への道のりは険しいなというのが感想です。正直まだまだ道半ばで、特に弊社のように歴史もある、巨大なシステムだと一筋縄ではいかない状況です。
ですが、現在の状態をしっかりと把握し、できるところから一歩一歩、歩み始めることができています。なぜこんな大変なことをしているかというと、やはり目的はDevOps能力の獲得と、それによってユーザーに価値提供していきたい、というところにあります。
リードタイムをできるだけ短くして、価値を提供し続けられる環境を用意していきたい。そして、エンジニアやデザイナー、PdMが、ユーザーへの価値提供を通じて自己実現できる環境を用意したい、というのが弊社の思いです。そのために、私たちはこれからも学習し、変化して適応し続けていきたいと考えています。
最後に、Chatworkでは中小企業の生産性向上を実現するために新たな構想を掲げ、そのためのプロダクト開発などを進める仲間を絶賛募集中です。もしご興味があればカジュアル面談などから、気軽にお話いただけると嬉しいです。本日は以上になります。
ご清聴ありがとうございました。
