リリースから12年を迎えた「Chatwork」は、国内ビジネスチャットのフロントランナーとして、中小企業を中心に41万社以上の企業・組織に利用されています（2023年6月時点）。DAU（デイリーアクティブユーザー）も100万を超えるため（108.6万、2023年6月時点）、ビジネスタイムには絶えず飛び交う大量のメッセージをサービスとして安定して処理することが求められます。
一方で、長期間の開発によって蓄積した技術的負債等に対応するため、システムのアーキテクチャを見直す時期にもあります。それにあわせて開発組織も、巨大なモノリスに対して案件ごとにプロジェクトを組み直す既存の体制から、職能を横断したチームが自律して開発を推進できるフィーチャーチームへの移行がまさに進行しています。
こうした開発改善の実情と進め方について、本部長として推進する田中佑樹さん、エンジニアとしてフィーチャーチームに所属する大道翔太さん、そしてフィーチャーチームのマネジメントを担う澁谷哲也さんにお話を伺いました。
※この記事はChatwork株式会社によるタイアップ広告です。
- サービスのリプレイスにあわせて開発体制の改善も
- EMがいないフィーチャーチームでどう開発するか
- 開発チームの外からマネジメントチームによる客観的な評価
- 移行期の組織を適切に定義していくことが次の課題に
- ■ Chatworkではサービスをともに作るエンジニアを募集
サービスのリプレイスにあわせて開発体制の改善も
── 今回はフィーチャーチーム化という開発体制の話をお聞きするわけですが、その前にChatworkのサービス開発はどういった状況でしょうか？ やはり歴史のあるサービスですので、システム的には改善すべきところもあるのではないかと思いますが。
田中 「Chatwork」は、ユーザーからの要望に答える形で数多くの機能をこの12年間で追加してきました。その結果、システムがひとつの巨大なモノリスと化してしまい、技術的負債も多くなっています。
また、ひとつのサービスに複数のチームやエンジニアが関わるため、一部の開発であっても多くのコミュニケーションが必要ですし、開発時に考慮すべき要素も多く、認知的負荷も高くなっています。そのため開発速度の低下が問題になってきました。
── 巨大なモノリスという話がありましたが、技術ブログでも2021年ごろからマイクロサービス化に言及されていますね。
田中 はい。技術負債の解消やマイクロサービス化のため、システム全体のリプレイス計画を進めているところです。そのリプレイスの進展にあわせて、フィーチャーチーム体制への移行もさらに進むことを想定しています。
── 新しいアーキテクチャにリプレイスされた機能についてフィーチャーチームが開発を進める形になるわけですね。比較のため、まず既存の開発体制を教えてください。
▲ 田中佑樹（たなか・ゆうき）：写真右
Chatwork株式会社 プロダクト本部 本部長
田中 これまでのChatworkの開発部門では、フロントエンド・バックエンド・モバイルアプリといった職能別に組織が分かれ、エンジニアはそのいずれかに所属します。新たな開発案件が立ち上がると、担当するEM（エンジニアリングマネージャー）が各組織に依頼し、必要なスキルを持つエンジニアを集めてプロジェクトチームを編成します。
このプロジェクトチーム体制の課題は、毎回チームビルディングが必要になってしまうためイニシャルコストが高くなりがちということです。また、プロジェクト完了後にチームが解散してしまうため知見が蓄積されず、後から機能改善やメンテナンスが必要になっても実施する主体が不明確という問題もあります。
── そうした課題を解決するためにフィーチャーチーム体制に移行するということですが、これはどういった組織なのでしょうか？
田中 メンバーが固定され、継続して存続するチームなのですが、職能横断型で自己管理化されていることを理想としています。立案から開発・運用まで一貫してオーナーシップを持ったDevOpsの実現を目的に、自律して活動できるチームを組織しています。
── 既存の体制からフィーチャーチームへのシフトは、現在どのくらい進んでいますか？
田中 「Chatwork」というサービスの機能全体の中で、フィーチャーチームが担当するのはまだ一部です。現在、固定的に運用しているフィーチャーチームは4つあり、マイクロサービス化された「決済・料金プラン」「認証」「API」の各機能のチームと、大道が在籍するグロース担当のチームです。
── 最終的にはシステム全体がリプレイスされるわけでしょうか。
田中 いえ、全てをリプレイスすることは考えていません。システムをリプレイスするのも組織を改善するのも、目的は開発生産性を高めることです。既存のプロジェクトチーム体制の方がフィットする案件もありますから、全体でのバランスを探りながらフィーチャーチーム化を進めることになります。
── 開発生産性の話がありましたが、2023年7月に開催された開発生産性カンファレンスでもフィーチャーチーム化の一環として、ピープルマネジメント体制を独立したチームに移行する話をされていました。この独創的な組織改編の意図は何でしょう。
田中 フィーチャーチーム化によってチーム数が増えることで、将来的にEMが足りなくなることが想定されます。そこで、各チームにはEMを置かず、ピープルマネジメント専門のチームを立ち上げて、開発チームの外部からマネジメントを行うようにしました。
技術的な意思決定といったエンジニアリング面でのマネジメントはチームのメンバーで分担して行いつつ、人事的な評価や経費精算といったピープルマネジメントは、外部からピープルマネージャーが専門のチームとして行うという構造です。
EMがいないフィーチャーチームでどう開発するか
── 大道さんは、フィーチャーチームのひとつでエンジニアとして働いているそうですが、どんなお仕事をされていますか？
大道 私が所属しているのは、グロース施策を担当するチームです。「Chatwork」の登録ユーザー数を増やすため、新規登録に関わるUI/UXを改善しています。
── 具体的にどういった機能開発を手掛けられましたか。
大道 最近は、既存のユーザーが新たなユーザーを招待する際に、携帯電話番号によるSMSを利用できるようにしたり、その場で読み取った名刺に記載されたメールアドレスや携帯電話番号から招待したりといった機能を開発しました（2023年9月時点ではiOS版アプリのみで提供）。
▶ 写真を撮るだけ、スマホの簡単操作で「Chatwork」への招待が実現 Chatwork、「名刺読み取り機能」をiOS版アプリにて提供開始
ゆくゆくは新規登録だけでなくサービス全体のUI/UX改善まで手がけ、退会に至るユーザーを減らして、もっと定着してもらえるような施策も進めたいと思います。
── どういった経緯でできたチームでしょうか。
大道 もともとグロース施策を行う数名程度のチームがあり、これが母体となって、会社の中期経営計画に基づきMAU（マンスリーアクティブユーザー）を増やす施策のため、2023年3月にフィーチャーチームとして独立しました。
その際にエンジニア・デザイナー・プロダクトマネージャーを増員し、現在では15名という大きなチームになることもあって、そろそろ分割しようという話が出ています。
▲ 大道翔太（だいどう・しょうた）
プロダクト本部 プロダクト開発ユニット
── フィーチャーチームに移行したメリットについて、現場ではどう感じますか？
大道 実感するのは、チームが解散せず、同じメンバーで継続的に開発しているので、お互いのバックグランドやスキルが分かっていることですね。チームビルディングの必要もなく、コミュニケーションも円滑になって開発速度が上がりました。
新規にAPIを作る際にも、資料やたたき台を作りミーティングして決定するまでがとてもスムーズですし、開発に入ってから仕様変更があっても共有やフィードバックがスピーディです。そして田中からもありましたが、自分たちが開発した箇所に不具合が発生した場合でも、責任が明確なので素早く確実に解消できます。
── 逆にデメリットに感じることはありますか？
大道 プロジェクトチーム体制と比べると、現状のフィーチャーチーム体制はデメリットがとても少ないと感じます。
前職のアプリケーション開発では1つのチームが中規模のプロダクトに関わる全ての開発を担当していたりして、言ってみればフィーチャーチームみたいな開発体制は自分にとって自然なものだし、馴染みやすかったです。
── フィーチャーチームにはEMを置かず、外部にピープルマネジメント専門のチームがあるわけですが、この体制についてはどうでしょう？
大道 チーム内にEMがいないということは、何事もメンバーが自分たちで判断して決定する必要があります。そのためメンバーの自主性は大きく伸びたと感じています。タスクのアサインや、他のチームとのコミュニケーションなど、従来ならEMが前面に立つところでも、自分たちで自主的に解決しなければならないので。
── 一方でデメリットもあるのではないかと思いますが？
大道 チーム全体に関わることの判断が難しいということは分かりました。先ほども言ったように、メンバーが増えてきたので分割を検討しているところですが、従来ならEMが各個人の特性や志向、チーム全体のスキル構成やバランスを考慮してチームビルディングしてくれます。これをボトムアップで行うのは難しいですね。
チームのあり方にもかかわるような意思決定は、全体を見る立場の人がチーム内にもいて、トップダウンで決めてくれる方が楽だろうということは感じています。
開発チームの外からマネジメントチームによる客観的な評価
── 澁谷さんは、フィーチャーチームやプロジェクトチームの外部からピープルマネージャーとして関わっているわけですが、あらためてどういう役割なのでしょう。
澁谷 ピープルマネジメントをチーム化したのは、先ほど田中が話したように、EMの不足がチームがスケールする際のボトルネックとならないようにする意図があります。
「Chatwork」は複雑で大きなアプリケーションのため、開発に携わるEMにも技術的な素養のほか、プロジェクトマネジメントができ、プロダクトマネジメントにも理解があり、チーム内のピープルマネジメントもできる、という高いスキルセットが求められます。実際には、この全部を兼ね備えた人材はなかなかいません。
── 確かにそういった限られる人材でやりくりしなければならないわけですね。
澁谷 それに加えて、チームに評価者を入れたくないこともあります。フィーチャーチームには自主的・自律的に課題を解決してほしいのですが、発言権を持った評価者がチームを引っ張る限りは実現しないだろうと考えました。むしろ評価者はチーム外に出した方がよいのではないか、という仮説に立っています。
技術やプロダクトに関してはチーム内で自律的に判断・意思決定してもらいつつ、ピープルマネジメントは独立したチームが担当する。ピープルマネジメントチームのメンバーが助け合いながら、複数の開発チームをマネジメントする。そういった体制にしました。
▲ 澁谷哲也（しぶたに・てつや）
プロダクト本部 エンジニアリングマネージャー 兼 フロントエンド開発部 マネージャー
── 具体的にどういった規模で体制が組まれているか教えてください。
澁谷 現在、ピープルマネジメントチームには4人のピープルマネージャーがいて、それでおよそ60人のエンジニアを見ています。
── ひとり当たり15人とするとかなり大変そうにも思えますが。
澁谷 実際にはマネジメント業務に専念できることと、チームのなかで横のつながりがあって、助け合うことができるので、問題なくマネジメントできています。
「マネージャーは孤独なもの」とは良く言われますし、メンタルへの負荷が大きい面もあります。同じマネージャーという立場のチームメンバーと相談できることは、その点ですごく大きなメリットですね。
── 直観的には、チームの外にいる評価者が適切にエンジニアの仕事ぶりを評価するのは難しいのではないかと思えますが、うまくできるものでしょうか？
澁谷 外部からの評価は、思っていたよりも普通にできる。というのが正直な印象です。評価される当人だけでなく、所属チームのメンバーや、仕事上でコミュニケーションが必要な他チームのメンバーとも話をして、さまざまな情報が入ってきます。
もちろん自分の目でメンバーを見ることも大事ですが、自身で捉えているメンバーの姿と、他の人から見たメンバーの姿を照らし合わせることで、より多角的な視点での仕事ぶりを知ることができ、結果的に客観的なマネジメントができているように思います。
── デメリットはあるでしょうか？
澁谷 こういう体制を実践している会社はまだ少なく、社外で話すと珍しがられることもよくあります。だから問題が発生したときに、社外の知見やノウハウに頼ることができません。メンバーとの向き合い方も含めて、問題解決が手探りになることは確かですね。
── 澁谷さんは、フロントエンド開発部のEMも経験されていますが、旧来のEMとピープルマネジメントチームの違いはどこにあるのでしょうか？
澁谷 はい。以前はEMとして見ていたフロントエンド開発部にも、今ではピープルマネージャーとして関わるようになったのですが、マインドセットを転換するにあたって最初は違和感がありました。
というのも、しばらくは「フロントエンド開発部が自分のチーム」という意識があったんです。そのため課題が生じると、無意識に自分のチームとしてどう振る舞うかを考えてしまっていました。自分としては全体最適の観点で物事を考えていたつもりだったので、これに気づいたときには自分でも驚きました。
今では職能別チームとしての意識ではなく、開発組織全体に対する課題として捉えるように、視点をうまく切り替えられたんじゃないかと思います。
── 大道さんは外部から評価される側として、どんな風に感じていますか？
大道 チームの外から評価されることについて、それほど違和感はありません。むしろ評価者が外側にいる方が公平性では上かもしれません。
評価者が近いと、どうしても遠慮して言えない場面が出てきます。チーム内での関係がフラットの方が、日々の開発も進めやすいと思います。
── 実際の評価も納得感があるということでしょうか。
大道 実際に、ピープルマネージャーにはよく見てもらえています。月に1回は1on1ミーティングをしており、その月の成果をアウトプットする機会もありますし、こんなに仕事しているのに最終的には評価してもらえなかったといったこともないように思います。
移行期の組織を適切に定義していくことが次の課題に
── これまでフィーチャーチームおよびピープルマネジメントチームという新しい体制について伺ってきましたが、少し視点を変えて経営や組織運営上の課題としては何か出てきていないでしょうか？
田中 この体制は、テクニカルマネジメントとピープルマネジメントを分けたい、と考える中で自然発生的に出てきたものです。そういう意味でピープルマネジメントにおける大きな課題は、現時点ではないと思います。
一方、開発組織の運営という点では課題が見えてきました。一般にはチームのEMが権限と情報を持っているので、聞けば何でも分かります。ところがピープルマネジメントチームでは戦略進捗への理解も解像度も高くないため、誰に聞けばいいのかが分かりづらいという状況があります。
── それは解決できる課題でしょうか？
田中 今後さらにフィーチャーチーム化を推し進めるには、今のような「誰がどう責任持っているのか？」「チームがどういうミッションを持っているのか？」といったことをチーム外にも分かりやすく定義しないと、組織的な混乱が生じます。
経営戦略や事業戦略に基づいた各チームのミッションを定める際には、最上位の戦略からカスケードする形で「どのチームの・誰が・どういう責任を持っているのか」を明確にすることで、フィーチャーチーム化の課題のひとつに対応した運営ができると思います。
この問題も、従来のプロジェクトチーム体制からフィーチャーチーム体制の移行期で、両者が混在しているからこそ生じる面もあります。ツリー構造の組織にオーバーレイする形でフィーチャーチームを実装しているので、少しいびつな状態です。
組織のガバナンスを効かせながら、自分たちのやりたいことを実現するために最適な組織体制は何か、最適なバランスを探っていかないといけません。
── ありがとうございます。それでは最後にみなさんそれぞれの立場からお答えいただきたいのですが、これからフィーチャーチーム化をさらに進める中で、この体制にジョインしてフィットするのはどんなエンジニアでしょうか？
田中 仕事をする上で、HowよりWhyやWhatに意識を向けられる方が合っていると思います。戦略を十分に理解した上で、それに向かってできることは何かを考え、目標に向かって手段に捕らわれず突き進めることが、求める理想的なエンジニア像ですね。
── マネジメントを実践する澁谷さんの視点はどうでしょうか？
澁谷 技術でも組織運営でも試行錯誤をしている会社なので、そういったチャレンジを楽しめる方が合っていると思います。Chatworkとしてやるべきことに対して、自分ができることは何かを考え、新しいものとか、理想通りじゃないけどこれならできそうだとか、自分のなかで試行錯誤しながらも、一緒に進んでいける方がよいですね。
── 大道さんとしてはどうでしょう？
大道 「Chatwork」は大きなプロダクトで、正直なところ歴史も長いので技術的負債もあり、会社が急拡大しているので組織的な課題もあります。そこを一歩ずつ、地道に改善できるような人にジョインしてほしいと思います。私もそうした改善を地道に進めたいので、一緒にやってくれる人が来てくれると嬉しいです。
── この新しい働き方に興味があるエンジニアの方も多いでしょうから、組織がより発展されることを期待します。本日はありがとうございました。
▼ Chatworkではリモートワークを推進しており、Chatwork東京本社での撮影に田中さんは出社して、関西在住の大道さんと澁谷さんはリモートで参加しました。
■ Chatworkではサービスをともに作るエンジニアを募集
Chatworkではサービスをともに作っていくエンジニアを募集しています。詳細は下記の採用情報ページをご覧ください。
この記事に登場したフィーチャーチームに関連する求人はこちら！
キャリア登録やニュースレターの購読も可能です。
▶ キャリア登録する
Chatworkのエンジニア組織の詳細はこちらの資料をご覧ください。
[タイアップ広告] 企画・制作：はてな
取材・構成：青山 祐輔（@buru）
撮影：小野 奈那子（nanakoono_）
撮影場所：WeWork 日比谷FORT TOWER
