はじめに

こんにちは。CTOの松谷です。

2017年の創業直後、スタメン3人目のエンジニアとして入社をし、創業事業TUNAGのサービス基盤やデータ基盤の構築・運用、及びチームマネージャーを経験し、2020年にCTOに就任しました。

現在はCTOとTUNAG開発部部長を兼務しており、CTOとして会社全体の技術統括をしつつ、TUNAG開発部長として組織マネジメントも担っています。

TUNAGの開発体制

TUNAG（ツナグ）は、エンゲージメント経営の実践を通じて会社の成長や成功を支援するプラットフォームです。TUNAGを運営する事業部には開発部と企画部があり、2022年2月時点で開発部には14人のエンジニアが、そして企画部にはプロダクトオーナーとプロジェクトマネージャー、デザイナーが所属しており、この2つの部署が連携してTUNAGの企画・開発を担当しています。

開発部は「ソフトウェアの価値を最速でユーザーに届ける」ために最適な技術選定や開発プロセス、組織デザインを採用しています。

そしてその開発プロセスはスクラムを採用しており、以下図のように組織は3つのフィーチャーチームと1つのモバイルチームの合計4チームで構成されています。このフィーチャーチームは機能横断型で、各スプリントで価値を生み出すために必要なすべてのスキル(バックエンド・フロントエンド)を備えています。

TUNAGの技術スタックにおいては、以下図のようにフロントエンドは React/TypeScript、バックエンドはRuby on Rails、モバイルアプリはSwift/Kotlinを使用しています。クラウドはAWSをメインとし、一部でGCPを利用しています。

これまで開発部は、各技術領域のベストプラクティスを積極的に導入したり、フレームワークやライブラリの最新バージョンをできる限り追従したりするなど、開発効率や運用効率を上げてプロダクトの価値提供のスピードを維持する取り組みを行ってきました。

また、プロダクトのコアな価値以外のシステムには積極的にSaaSを活用し、開発・運用コストを圧縮しています。そしてTUNAGのデータ分析基盤など、適材適所でサーバーレスアーキテクチャを採用することで運用コストをほぼゼロにし、プロダクトのコア部分に注力できるようにしています。

スタメンは、TUNAGだけでなくFANTSというオンラインコミュニティプラットフォーム事業を展開しており、今後も新規事業を積極的に展開していきたいと考えています。

このような組織においては、組織内での車輪の再発明を防ぎ、組織化する強みを生かしていくために、横展開することを想定した設計や基盤の整備、及びナレッジの水平展開を可能にする情報共有・展開の仕組みを考えていくことが大切になります。それを実現するための施策の一つとして、Infrastructure as Codeによるコードの再利用によって、サービス基盤やデータ分析基盤がすぐに立ち上がる状況を整備し、最速でサービスの立ち上げができるようにしています。

TUNAG開発部の技術や開発体制の詳細については、以下の記事をぜひ参照ください。

事業成長を牽引するために必要なこと

事業成長に伴い、開発組織が直面する課題や求められる能力は、刻々と変化します。

例えば、TUNAGリリース後の1〜2年間は、少人数でプロダクトの仮説を検証する段階だったからこそ、手段は問わずにとりあえずカタチにして素早くリリースすることが求められていたフェーズでした。

その後順調にプロダクトの規模が大きくなり、またテクノロジートレンドが移り変わるにつれて、技術のベストプラクティスから外れたまま開発をしていくことが、プロダクトの価値向上にブレーキをかけ始めました。このフェーズでは、開発部に「高い専門性」が求められていました。

バックエンド領域では、スケーラビリティの課題を解決するためにサーバレスやコンテナなどを活用してアーキテクチャを進化させ、またクライアント領域でも、エンドユーザーの体験価値を最大化できるように技術的負債の返済やフレームワークの導入を進めてきました。チーム構成をバックエンドチームやフロントエンドチームのように技術領域ごとに分け、各技術領域の学習効率を最大化して事業成長を支えました。

しかし、無事に技術的な課題を乗り越えた後には、組織のスケーラビリティの問題に直面しました。技術領域でチームを分けたことにより、1つの機能をデリバリーするまでに「チーム間の依存関係」によって開発時のコミュニケーションコストが増えてしまうことが顕著になっていきました。

この組織規模が大きくなったフェーズでは、組織全体として大きな力を出せるような仕組みが求められます。そこで価値をユーザーに届けるために必要なコミュニケーションがチーム内で完結するように、すべてのスキルをもった機能横断型のチーム体制と、それを支える開発プロセス(大規模スクラムLeSS)への転換を決定しました。

これらのように、事業の成長段階によって常に最適解は異なります。そのため、現状の課題を見極め、開発組織自らが適応して変化していくことが、事業成長を牽引するために必要なことではないかと考えています。

今後の開発部の挑戦

「ソフトウェアの価値を最速でユーザーに届ける」ために、開発部としてはまだまだやりたいことが沢山残っています。

開発プロセスに関しては、まずは大規模スクラムLeSSの安定稼働を達成したいと考えています。しかし、開発部にはこれまで大規模スクラムの経験がなく、導入難易度も高いので、社外の支援経験が豊富なスクラムコーチに協力を仰ぎ、短期間でスクラムの良さを引き出せる状態になることを目指します。

またフィーチャーチームとしても、「ソフトウェアの価値を最速でユーザーに届ける」ために「自律したアジリティの高いチーム」へと転換していきたいと考えています。

理想としては現時点での「できる」「できない」は別として、「全てのエンジニアがプロダクト全体のオーナーである」という意識を持ち、「ユーザー目線での開発」「当たり前品質を支えるSRE活動」「価値を遅延なく届けるためのプロジェクトマネジメント」「プロダクトの拡張性・スケーラビリティを見越したコーディング・アーキテクト」「ユーザーの損失を最小限に抑える障害対応」「開発体験・開発効率向上への取り組み」などを実現できるように、足りないギャップを徐々に埋め、お互いに学び合える組織にしていこうと考えています。そして実際に開発部ではこの動きがとても活発で、社内勉強会が積極的に開催されていたり、モブプログラミングを試し始めています。

一人のエンジニアの活躍の範囲が広がれば、当然認知負荷も大きくなります。今後の技術戦略としては、技術領域を越えた学習コストをできる限り抑えられるような技術選定が重要です。今の技術スタックにとらわれず、今後は開発組織に最適なアーキテクチャや技術を選択していきたいと考えています。

私の挑戦

TUNAG開発部はこれまでさまざまな課題を乗り越えてきましたが、2022年にはさらに大きく変わっていきます。開発部全員でおおきく事業に貢献し、プロダクトで事業を圧倒的に成長させていきたいです。

そのために必要なことであれば、CTOだけでなく部長やSRE、スクラムマスターなどのように、必要に応じて何にでも役割を変えて挑戦していきたいと思っています。そして、徐々に私個人のロールを小さくしていき、組織で大きな成果を出すチームをみんなで創り上げていきたい。それが私の挑戦です。