こんにちは。CTOの松谷です。現在はCTOとTUNAG開発部部長を兼務しており、CTOとして会社全体の技術統括を行いながら、TUNAG開発部長として開発組織マネジメントを担っています。
本記事では、スタメンの創業事業であるTUNAGについて、プロダクトと開発体制の紹介をします。
目次
TUNAGについて
TUNAG（ツナグ）は、エンゲージメント経営の実践を通じて会社の成長や成功を支援するプラットフォームです。
昨今は、外部環境の変化により、働き方にもリモートワークなどの変化が生まれ、社員それぞれの価値観も多様化しています。そんな中、リモートワークによって社員間のコミュニケーションが少なくなってしまったり、経営理念が浸透しにくくなってしまったりと、組織における課題にも変化が生じています。
スポーツにおいては、メンバーが相互に信頼しあっているチームは強いのと同じように、ビジネスにおいても経営陣と従業員、従業員間で信頼関係を築けているチームは強く、さまざまな業界において競合他社に勝り、継続的な成長を遂げている企業があります。企業における経営陣と従業員、従業員間のこの信頼関係を「エンゲージメント」と定義し、TUNAGではこのエンゲージメントの醸成を支援しています。一見すると「従業員満足度」と似ている概念に思われますが、エンゲージメントと従業員満足度は似て非なるものです。従業員満足度は外部環境の変化などで待遇や環境が悪化するとともに満足度も下がってしまいますが、エンゲージメントは外部環境に左右されず、一丸となって支え合う強い組織をつくることができます。
TUNAGは企業のエンゲージメントの構築、つまりお互いを知って理解し、信頼し合う組織を作るための社内コミュニケーションを活性化させるプロダクトです。メイン機能としては、「会社や人の今」を知るための「タイムライン機能」や人を深く知るための「プロフィール機能」、会社の方針や文化を知る「社内制度機能」が組み込まれています。
「社内制度」は、サンクスカードや社内報、1on1ミーティングなど、会社ごとの経営方針や組織課題に合わせてさまざまな形で運用されており、その種類は多岐に渡ります。TUNAGではこれらの社内制度をアプリケーション上で利用することができ、その利用結果がタイムライン上にフィード形式で投稿され、会社全体に共有することができる仕組みになっています。
弊社内でもTUNAGを利用しており、スタメンにおけるタイムラインの画面が以下のスクリーンショットになります。人や情報が自然と集まる「コーポレートリビング」のような空間をオンライン上で実現できるよう、タイムラインに会社の情報が集約される機能設計やUI設計をしているのが特長です。
また、メイン機能以外にも業務アプリケーションとして、「ビジネスチャット機能」や「ワークフロー機能」、「組織管理機能」「データ分析機能」などのさまざまな機能を備えており、従業員数1万名超のグローバル企業から十数人の企業まで規模や業種、業態を問わず、さまざまな企業の利用を支えられる大規模なSaaSアプリケーションです。
東海テレビでTUNAGが紹介されました。YouTubeで公開されているので、ぜひ見てください。
開発体制について
TUNAG開発部は、「プロダクトの価値を最速でユーザーに届ける」ために最適な技術選定や開発プロセス、組織デザインを採用しています。
技術スタック
TUNAGの技術スタックにおいては以下の図のように、フロントエンドは React/TypeScript、バックエンドはRuby on Rails、モバイルアプリはSwift/Kotlinを使用しています。クラウドはAWSをメインとし、一部でGCPを利用しています。
これまで開発部は、各技術領域のベストプラクティスを積極的に導入したり、フレームワークやライブラリの最新バージョンをできる限り追従したりするなど、開発効率や運用効率を上げてプロダクトの価値提供のスピードを維持する取り組みを行ってきました。
スタートアップのプロダクト成長の舞台裏とコンテナ化までの道のり
Ruby on Rails 5.1から6.1へのバージョンアップをカナリアリリースしました
今後も、このベストプラクティスの導入などの取組みを継続していきたいと考えています。例えば、現状のTUNAGのフロントエンドは、RailsのViewの中にReactが埋め込まれる形式で画面が構成されているため、ReactのバージョンがRailsによって管理されていたりとメンテナンス性が悪く、モダンフロントエンドの強みをプロダクトに取り入れにくい状況になっています。今後、ユーザー体験と開発者体験の両方が、世の中のスタンダードに追従できるように、去年からフロントエンドの分離プロジェクトを開始しました。分離後のフロントエンドはNext.jsを採用し、バックエンドはAPIサーバーに徹する方向へと徐々に改善を進めています。
アーキテクチャ
TUNAG本体のアーキテクチャの概要は以下になります。
Amazon ECS上のDockerコンテナで実行された、モノリシックなRailsアプリケーションを中心としたシンプルな構成になっています。データベースにはAmazon AuroraやAmazon ElastiCache、Amazon S3、そして全文検索エンジンとしてはAmazon OpenSearch Serviceを利用しています。CI/CDにはCircleCIを利用しており、RSpecやJestによる単体テスト、そしてCypressによるE2Eテストを実施した後にデプロイをしています。プロダクトのコアな価値以外のシステム(メール・SMS・プッシュ通知・画像配信基盤など)には積極的にSaaSを活用し、開発・運用コストを圧縮しています。
またTUNAGでは、アプリケーション上のユーザーのアクティビティを追跡し、各社ごとにエンゲージメントに関する数値などを集計した結果をダッシュボード機能で提供しています。この機能を支えるデータ分析基盤のアーキテクチャの概要は、以下になります。
データはすべてデータレイク(Amazon S3)で一元管理し、必要なときに必要なデータを取り出せるようにしています。またデータ処理基盤は、Amazon AthenaやAWS Glue、AWS Lambdaなどのマネージドサービスとサーバーレスアーキテクチャを組み合わせたシンプルな構成であり、特に複雑なことはしていません。クラウドの強みをちゃんと活かし、かつ今後のデータ分析における試行錯誤がしやすい、柔軟な基盤になっています。
このように、適材適所でマネージドサービスやサーバーレスアーキテクチャを採用することで運用コストをほぼゼロにし、プロダクトのコア部分に注力できるようにしています。アーキテクチャの詳しい説明は以下を参照いただければと思います。
スタメンは、TUNAGだけでなくFANTSというオンラインサロンプラットフォーム事業も展開しており、今後も新規事業を積極的に展開していきたいと考えています。 このような組織においては、組織内での車輪の再発明を防ぎ、組織化する強みを生かしていくために、横展開することを想定した設計や基盤の整備、及びナレッジの水平展開を可能にする情報共有・展開の仕組みを考えていくことが大切になります。特にTUNAGはスタメンの創業事業なので、他の事業に先行して知識を獲得することが多く、ノウハウの横展開を意識することが重要になります。それを実現するための施策の一つとして、Infrastructure as Codeによるコードの再利用によってサービス基盤やデータ分析基盤がすぐに立ち上がる状況を整備し、最速でサービスの立ち上げができるようにしています。実際に第二の事業FANTSでは、TUNAGの資産を大きく活かして素早くサービスを立ち上げることができました。
開発組織
TUNAGを運営する事業部には開発部と企画部があり、2022年5月時点で開発部には15人のエンジニアが、そして企画部にはプロダクトオーナーとプロジェクトマネージャー、デザイナーが所属しており、この2つの部署が連携してTUNAGの企画・開発を担当しています。
そしてその開発プロセスはスクラムを採用しており、以下の図のように組織は3つのフィーチャーチームと1つのモバイルチームの合計4チームで構成されています。このフィーチャーチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキル(バックエンド・フロントエンド)を備えています。
開発組織の変遷
TUNAG事業が成長するに従い、開発組織が直面する課題や求められる能力は、刻々と変化してきました。現在はフィーチャーチーム体制としていますが、事業の成長段階に合わせて開発組織も変化させてきました。
例えば、TUNAGリリース後の1〜2年間は、プロダクトの仮説を検証する段階だったからこそ、手段は問わずにとりあえずカタチにして素早くリリースすることが求められていたフェーズでした。少人数でお互いの作業を詳しく把握できていたため、チーム分けなどの組織化の必要性はありませんでした。
その後順調に開発組織とプロダクトの規模が大きくなり、またテクノロジートレンドが移り変わるにつれて、技術のベストプラクティスから外れたまま開発をしていくことが、プロダクトの価値向上にブレーキをかけ始めました。このフェーズでは、開発部に「高い専門性」が求められていました。バックエンド領域では、スケーラビリティの課題を解決するためにサーバレスやコンテナなどを活用してアーキテクチャを進化させ、またクライアント領域でも、エンドユーザーの体験価値を最大化できるように技術的負債の返済やフレームワークの導入を進めてきました。チーム構成をバックエンドチームやフロントエンドチームのように技術領域ごとに分け、各技術領域の学習効率を最大化して事業成長を支えました。
しかし、無事に技術的な課題を乗り越えた後には、組織のスケーラビリティの問題に直面しました。技術領域でチームを分けたことにより、1つの機能をデリバリーするまでに「チーム間の依存関係」によって開発時のコミュニケーションコストが増えてしまうことが顕著になっていきました。この組織規模が大きくなったフェーズでは、組織全体として大きな力を出せるような仕組みが求められます。そこで価値をユーザーに届けるために必要なコミュニケーションがチーム内で完結するように、すべてのスキルをもった機能横断型のチーム体制と、それを支える開発プロセス(大規模スクラムLeSS)への転換を決定しました。
フィーチャーチーム
TUNAG開発部の主体となるフィーチャーチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキル(バックエンド・フロントエンド)を備えたチームです。そして、「ソフトウェアの価値を最速でユーザーに届ける」ために、自律したアジリティの高いチームを目指しています。
理想としては現時点での「できる」「できない」は別として、「全てのエンジニアがプロダクト全体のオーナーである」という意識を持ち、「ユーザー目線での開発」「当たり前品質を支えるSRE活動」「価値を遅延なく届けるためのプロジェクトマネジメント」「プロダクトの拡張性・スケーラビリティを見越したコーディング・アーキテクト」「ユーザーの損失を最小限に抑える障害対応」「開発体験・開発効率向上への取り組み」などを実現できるようになりたいと考えており、足りないギャップを徐々に埋めて、お互いに学び合える組織にしていこうと、モブプログラミングなどのさまざまな取り組みをしています。
その結果、今までのマネージャーやSREなどの個人のロールへ依存していた状態から、多くの機能をもつ自律したチームへと徐々に変化していきました。例えば、TUNAG開発部のエンジニアには、バックエンド領域(Ruby on Rails)とフロントエンド領域(React)の両方を担当できるメンバーが増えてきました。また、自分自身でプロジェクトマネジメントをするのは当然のこと、リリースした機能のパフォーマンスを自ら監視し、必要があれば自分でパフォーマンスチューニングをすることもしています。また、開発者がAWSなどのクラウドのアラート対応などのSRE業務をしたり、開発フェーズだけでなく運用フェーズも担当できるエンジニアの比率が大きくなってきました。
一人のエンジニアの活躍の範囲が広がれば、当然認知負荷も大きくなります。そのため、コンテナ化やサーバーレス化など、アーキテクチャのモダン化などによる運用コストの圧縮や、社内勉強会の積極的な開催やモブプログラミングによる組織学習がこのアジリティ向上の取り組みを支えています。
一方でフィーチャーチーム体制は、プロダクト開発におけるコミュニケーションを最優先することになり、技術領域ごとにおけるコミュニケーションの優先順位が下がってしまうことを意味します。ただ、そのコミュニケーションの優先順位が下がってしまうことを意識した上で、それをカバーできるような動きを取れば対処できると考えています。例えばSRE領域やフロントエンド領域などは、今まで以上に標準化の推進や分科会などの会議体設計の工夫を行っています。
また、大切な点は、プロダクト開発に最適化されたフィーチャーチームを開発組織の主体にしていきたいということであり、全てをフィーチャーチームで統一したいというわけではありません。事業をプロダクトで伸ばすためには、各技術領域のエキスパートの力が不可欠です。今後はモバイルアプリチーム含めて必要に応じて専門チームを追加していくなど、上手くバランスを取っていきたいと考えています。
開発プロセスについて
技術領域でチームを分けていた頃は、開発プロジェクトごとに必要なスキルを持ったメンバーが各チームから集められ、完了するとチームを解散するといったように「プロジェクト」を中心に開発を進めてきました。そのため、「納期」や「担当」といったようなプロジェクト自体の関心事が大きくなりがちで、プロダクト全体の価値を考える機会が多くはありませんでした。今後はプロジェクト中心ではなく、プロダクト全体における優先順位に関心を向けることで、「なぜこれが重要なのか」「誰のためなのか」といったようにプロダクト全体の価値を追求する「プロダクト文化」を醸成していきたいと考えています。
また、今までは開発タスクに個人が割り当てられていたため、「個人vs課題」という構図になりやすく、同じチームだったとしてもメンバーの開発内容や困っていることを把握しづらいという状況がありました。そのため、今後は開発タスクをチームに割り当てることで「チームvs課題」という構図に変え、より一体感を持って課題に向き合えるような「チーム文化」を醸成できる土台をつくっていきたいと考えています。
2021年冬、これらの狙いを実現できそうな開発プロセスを調査しました。プロダクト全体の価値を追求できるように、「複数チームに対して１つのプロダクトバックログで対応するフレームワークであること」、そして「シンプルなものであること」という観点で、最終的に大規模スクラム(LeSS)を採用しました。
2022年2月から大規模スクラム(LeSS)への移行を開始したものの、開発部にはこれまでスクラム自体の経験がありません。さらに大規模スクラム(LeSS)ともなると導入難易度も高いので、社外の支援経験が豊富なスクラムコーチに協力を仰ぎ、短期間でスクラムの良さを引き出せる状態になることを目指しています。
まだまだ手探りの状態なので、大規模スクラムの導入とその後については、別途発信してお伝えできればと思います。
おわりに
TUNAG開発部は「ソフトウェアの価値を最速でユーザーに届ける」という目的のために、技術スタックや開発組織、開発プロセスを柔軟に変化させてきました。先に述べましたが、事業が成長するに従い、開発組織が直面する課題や求められる能力は刻々と変化します。特にTUNAG事業のように成長が速く、変化率が高い事業ではなおさらです。その変化の中で一人ひとりのエンジニアが急成長し、これまでの事業を支えてきました。そして2022年には、さらに大きく変わっていきます。
今後も続くTUNAG開発部の転換期を一緒に楽しみ、プロダクトで事業を圧倒的に成長させていく仲間を募集しています！
TUNAG開発部の技術スタックやアーキテクチャ、開発組織、開発プロセスに興味を持っていただけましたら、下記の採用ページからエントリーいただけると幸いです。
また、松谷のMeetyも公開していますので、TUNAG開発部について気になることがあれば気軽に聞いてください😄
