チームスピリットデベロッパーブログ

チームスピリット開発者のブログ

ミッドマーケット向け製品の開発体制の紹介(2024年3月)

はじめに

こんにちは。QAマネージャーの石原(id:m-ishihara)です。

TeamSpirit Family製品開発チームの紹介記事が本ブログにアップされてから3年近くたちました。

teamspirit.hatenablog.com

2024年3月現在、開発チームのメンバーが増え、チーム構成は大きく変化しています。
そこで今回の記事では、TeamSpirit Family製品開発チームを中心に、最新のミッドマーケット向け製品の開発体制と開発における取り組みについてご紹介します。

Service Development Divisionについて

TeamSpirit Family製品開発チームを紹介する前に、まずは、株式会社チームスピリットの開発部門であるService Development Division(略称:SDD)の現在のチーム構成について説明します。

前回記事の2021年時点では、SDDは製品別に大きく2チームに分かれていました。1つは、エンタープライズ向け製品を開発するTeamSpirit EX製品開発チーム(通称:TEXチーム)、もう1つはミッドマーケット向け製品を開発するTeamSpirit Family製品開発チーム(通称:TSFチーム)です。

現在は、TEXチーム、TSFチーム、そして新たに発足したCustomer Reliability Engineeringチーム(略称:CREチーム)の3チームとなりました。
CREチームは、お客様からの問い合わせを担当するテクニカルサポート、マニュアル作成などを行うライター、アドオン(製品外で動作するオプション機能)の開発を行うエンジニアがTEXチームおよびTSFチームから集結して独立したチームです。

ServiceDevelopmentDivisionの体制

以降では、ミッドマーケット向け製品の開発に携わるチーム(図の赤い点線部分)について説明していきます。

ミッドマーケット向け製品の開発チームについて

ミッドマーケット向け製品の開発には、TSFチームとCREチームの一部のメンバー、合わせて約30名が携わっています。前回記事ではサブチームは3チームでしたが、現在は7チームとなりました。

TSFチームは、新機能開発チーム1、新機能開発チーム2、品質改善チーム、勤怠計算リファクタリングチーム、リグレッションテストチームの5つのサブチーム、CREチームはテクニカルサポートチーム、CRE開発チームの2つのサブチームに分かれて活動しています。

ちなみにTSFチームは、組織図上はProduct Management(PM)チーム、エンジニアチーム、QAチームと職種別に分かれていますが、実際の開発に携わるサブチームは職種別のチームを横断したスクラムチームとなっています。

TeamSpirit Family製品の開発チーム体制

各サブチームの役割

ここで、各サブチームの役割を簡単にご紹介します。

新機能開発チーム1、新機能開発チーム2
経費精算やモバイル機能などの新機能の開発を担当するサブチームです。スクラム開発を行っています。

品質改善チーム
勤怠管理や休暇管理などに関する機能改善や品質改善を担当するサブチームです。スクラム開発を行っています。

勤怠計算リファクタリングチーム
勤怠計算機能のリファクタリングを担当するサブチームです。
勤怠計算リファクタリングについては別の記事で紹介していますので、よろしければ合わせて読んでいただけるとうれしいです。

teamspirit.hatenablog.com

リグレッションテストチーム
QAエンジニアのみで構成されているサブチームです。リグレッションテストの実行やメンテナンスの他、他チームのサポートなども担当します。

CRE開発チーム
CREチームに所属するソフトウェアエンジニアで構成されているサブチームです。製品外部で動作するアドオン機能の開発や、お客様向けサポートサイトであるTS Circleのメンテナンスなどを担当しています。

テクニカルサポートチーム
CREチームに所属するテクニカルサポートで構成されているサブチームです。ミッドマーケット向け製品を利用するお客様からの問い合わせの解決を行っています。

CRE開発チーム、テクニカルサポートチームの変遷や活動については note の記事で紹介していますので、よろしければ合わせて読んでいただけるとうれしいです。

note.com

note.com

note.com

サブチームの人数はおおむね2〜6名です(一部のチームは協力会社の方にも参画いただいています)。
スクラム開発を行っているチームにはスクラムマスターがいます。なお、スクラムマスターは専任ではなく、ソフトウェアエンジニアやQAエンジニアが兼任しています。

ミッドマーケット向け製品開発における最近の取り組み

ここからは、ミッドマーケット向け製品開発において、最近取り組んでいることのうち大きなものを2つご紹介します。

リグレッションテストチームの新設

1つ目は、前述のリグレッションテストチームを新設したことです。

ミッドマーケット向け製品はローンチしてから10年以上たっています。継続的に開発していると、リグレッションテストはどんどん増大していきますが、テストの整備が追いつかず手薄になるところも出てきました。そこで、戦略的にリグレッションテストを実施する、そのための基盤を整備するために、チームを新設して集中的に取り組むことにしました。

リグレッションテストチームは、チームトポロジーにおけるプラットフォームチームを目指しています。各サブチームが新しい機能の開発に専念できるようにすることがミッションです。

リグレッションテストの実施やメンテナンスだけでなく、スクラム開発を行っているチームやQAエンジニアが不在のチームがスムーズに開発を進めることができるように、QA作業のサポートやテストに関するお悩み解決の伴走もしています。

リリーストレインの導入

2つ目は、リリーストレインを導入したことです。

リリーストレインは、書籍『エッセンシャルスクラム』(Kenneth S.Rubin 著、岡澤 裕二 訳、翔泳社、P.209)では以下のように説明されています。

リリーストレインは、ビジョンやプランニング、そして複数チーム間の依存関係などの調整をするための手法のひとつで、各チームの歩調を揃えて、チーム間での同調ができるようにするものだ。

「トレイン」という言葉のとおり列車のメタファーで、あらかじめ時刻表(リリーススケジュール)が決まっており、時刻表に従ってサブチーム間で同期を取りながらタイミングを合わせてリリースを行います。
列車の発車時刻(リリース日)までに貨物を列車に載せ(機能をリリースできる状態にする)、発車時刻定刻になれば列車は出発します(機能をリリースする)。もし乗り遅れた(間に合わなかった)場合は、列車を遅らせる(リリース日を遅らせる)ことはしません。次の列車がいつ出発するかはわかっているので、次の列車を待ちます(次回のリリース日にリリースできるようにする)。

パッチリリースの頻度を上げるチームが出てきたことがきっかけで、調整コストやトラブルを減らすために導入することになりました。 現在、運用を行いながら、ルールのブラッシュアップを行っています。

最後に

最後までお読みいただきありがとうございました。
いかがでしたでしょうか。
記事を書いてみて、3年前と比べて組織の大きさもカタチもだいぶ変わったなとあらためて感じました。
今後も変化があったときには、このブログでご紹介していければと思います。

チームスピリットでは、一緒に働く仲間を募集しています。
ご興味を持ってくださった方がいらっしゃいましたら、ぜひ弊社の採用サイトからお問い合わせください。 recruit.teamspirit.com