スタメン技術ロードマップ 2025-2026
みなさん、こんにちは。スタメンCTOのtakuya (@tn961ir) です。2024年にCTOに就任したのですが、その際のことを外部発信しないまま1年が終わろうとしてしまっていることに焦りを感じる今日この頃です。
前回はスタメン・エンジニアリング組織アップデート2024というタイトルで書きましたが、前回記事に含まれなかった、隠れた2024年実施済みアップデートと2025-26年に向けたプロダクト・技術戦略を深掘りできればと思います。
前回記事をご覧になっていない方はこちらをご確認ください。三代目CTO at stmn, inc. / CTO at stmn
SaaS企業においてプロダクトに対する投資はもっとも中長期に影響するものであり、短期的な成果以上よりも中長期的な効果を狙った内容になっています。
このnote記事は、スタメンnoteリレー第5弾の10日目です! スタメンのnoteリレーはこちら👇
https://note.com/stmn_hr/n/necfb0b68dc49
アップデート
ハイブリッドワーク（一部リモートワーク）（プロダクト人材のみ）の運用
創業時からこだわってきた週5出社（フル出社）から方針をアップデートし、2023年末にスタートしたハイブリッドワークの運用が定着してきました。ハイブリッドワークは2024年入社のメンバーは全員ハイブリッドワークを選択しており、一定の効果がありました。それまでに在籍していたメンバーもハイブリッドワークに切り替えたケースもあり、トータルでのハイブリッドワーク率は70%となりました。
ハイブリッドワーク率 = （ハイブリッドワークを選択したプロダクト系職種の人数）/（ハイブリッドワークを選択したプロダクト系職種の人数＋フル出社しているプロダクト系職種の人数）
なお、入社直後のオンボーディング期間（1ヶ月の想定ですが、オンボーディング状況により変化することがあります）については原則週5の出社をお願いしています。
Build TUNAG with Rails
2023年にMicrosoft社子会社であるGitHubより https://github.blog/engineering/architecture-optimization/building-github-with-ruby-and-rails/ という記事公開がありました。2016年の創業時にコア技術スタックとしてRuby on Railsを採択したスタメンでは2023年の大規模な技術的負債の改善に対する投資を経て、この記事とかなり似たようなことをやっています。2024年現在、GitHub社のGitHub（プロダクト）がどういう状況かは分かっていませんが、TUNAGにおいてはRailsにおいてedgeを選択しており、week dayにdailyでアップデートを作成しています。実績としては年間で200程度のアップデートにチャレンジし、実際のプロダクションへのデプロイの回数としては年間で80-90回程度の実績となっています。
GitHubの記事より一部を抜粋します。
Upgrading Rails weekly
Every Monday a scheduled GitHub Action workflow triggers an automated pull request, which bumps our Rails version to the latest commit on the Rails main branch for that day. All our builds run on this new version of Rails. Once all the builds pass, we review the changes and ship it the next day. Starting an upgrade on Monday you will already have an open pull request linking the changes this Rails upgrade proposes and a completed build.
This process is a far stretch from how we did Rails upgrades only a few years ago. In the past, we spent months migrating from our custom fork of Rails to a newer stable release, and then we maintained two Gemfiles to ensure we’d remain compatible with the upcoming release. Now, upgrades take under a week. You can read more about this process in this 2018 blog post. We work closely with the community to ensure that each Rails release is running in production before the release is officially cut.
There are real tangible benefits to running the latest version of Rails:
* We give developers at GitHub the very best version of our tools by providing the latest version of Rails. This ensures users can take advantage of all the latest improvements including better database connection handling, faster view rendering, and all the amazing work happening in Rails every day.
* We have removed nearly all of our Rails patches. Since we are running on the latest version of Rails, instead of patching Rails and waiting for a change, developers can suggest the patch to Rails itself.
* Working on Rails is now easier than ever to share with your team! Instead of telling your team you found something in Rails that will be fixed in the next release, you can work on something in Rails and see it the following week!
* Maintaining more up-to-date dependencies gives us a better security posture. Since we already do weekly upgrades, adding an upgrade when there is a security advisory is standard practice and doesn’t require any extra work.
* There are no “big bang” migrations. Since each Rails upgrade incorporates only a small number of changes, it’s easier to understand and dig into if there are incompatibilities. The worst issues from a tough upgrade are unexpected changes from an unknown location. These issues can be mitigated by this upgrade strategy.
* Catching bugs in the main branch and contributing back strengthens our engineering team and helps our developers deepen their expertise and understanding of our application and its dependencies.
TUNAGにおいてはRuby安定系最新版を利用しています。関連する記事もご参照ください。
Build TERAS with Ruby and Rails
独立したプロダクトという形では説明していませんが、プロダクト・技術観点で言うと完全に独立したプロダクトとしてTERASというものを持っています。TERASについては「with Rails」ではなく「with Ruby and Rails」と見出しした通り、以下の技術を使っています。
プレリリースを含む最新版のRuby
Rails edge (daily)
こちらはプロジェクトの開始が遅れていますが、執筆時点に至るまで継続的に1日1回のアップデートが実施できている状況です。
以上、2点の業務推進を通じて、2024年からはRubyエコシステムに対する修正をPull Requestという形で還元することができ、微力ながら組織レベルでオープンソースソフトウェア（OSS）コミュニティへの還元も実現できていると自負しています。
経営体制に新しい風
2024年より私自身も経営陣に参加したのですが、他の経営陣は2018年以前にスタメンにジョインしたメンバーとなるため、スタメン1年目の私の次に古参のメンバーがスタメン6-7年目となっており、大きな意思決定を進められてきたのではないかと思っています。実際、ストラングラー・フィグ・パターンを活用したプロダクト戦略を一気に進めることができました。その成果は2025年以降にリリースされ、長期にわたりアップデート開発を進めていく想定です。
ISMS取得
情報セキュリティマネジメントシステムの国際規格であるISMS認証（ISO/IEC 27001:2022）を2024年7月に新規取得しました。
株式会社スタメン[…]は、情報セキュリティマネジメントシステム（ISMS）に関する国際規格「ISO 27001」（ISO/IEC 27001:2022）の認証を取得いたしました。
既に社内ではプライバシーマークを取得・維持してきており、それでカバーできるのではないかという意見もありましたが、最終的には認証取得まで到達することができ、お客様、従業員のステークホルダーに対してプラスの効果を得ることができたと確信しています。
社内の体制については、既存の情報セキュリティ規程においての責任者である、CTOをISMSの中でもトップマネジメントとして、システムを導入しました。今回の取得に際しては、SecureNaviを導入し、煩雑なオペレーションを減らす形で準備・審査・取得でき、少人数の体制で情報セキュリティレベルを向上させることができました。引き続き、ISMS (ISO/IEC 27001:2022) においては維持審査ならびに更新審査が控えており、SaaSプロダクトセキュリティ向上も図れる専任の人材を募集しています。また、当社がSaaSを中心とした事業展開をしていることから、上位認証資格であるISO/IEC 27017:2015やSOC 2 Type IIの新規取得の検討もしていきます。
戦略
名古屋から世界へ 2025
私がスタメンへのジョインしたきっかけとして社内外の文脈でお伝えしているのが「名古屋から世界へ」です。そのときどきによってウェイトが違うのですが、75-90%くらいの理由と説明することが多いです。私がジョインする数年前に社内で標榜されていたようなのですが、当時在籍していたメンバー1名が辛うじて覚えているような形のようです。その内容について私自身は社外の身として採用広報で共有された文脈で拝見していたのですが、当時から現在に至るまでに採用担当組織も数度変わっているため、その戦略そのものも変化してきました。
私自身が個人として、名古屋から東京へ、そして世界へを達成したこともあり、もう一度組織として名古屋から世界へを実現するべく動いています。スタメンはちょうど名古屋から東京支社（当時は東京開発拠点のちに東京開発拠点という名称でした）を立ち上げるということで、「名古屋から世界へ」を「名古屋から東京へ、そして東京から世界へ」というステップを以て実現できるのではないかと船に乗り込むこととしました。
2023年1月の開所をスタート地点とし、2023年の開発組織の拡大（しかしそれはそれなりに紆余曲折がありました、それは別に機会に）を経て、2024年1月に東京本社+名古屋本社という2本社制という形で一段階段を登ることができました。実際に2024年9月末時点ではプロダクト開発組織では東京本社と名古屋本社が同数で並んだため名実ともに東京・名古屋の2本社制化が実現したということができると思います。
注1: 名古屋本社でのエンジニア・プロダクト人材の採用をストップしているわけではありませんし、引き続き拠点によらず採用は進めています。
注2: 企業全体で見たときの拠点ごとの人数比は非公開としていますが、スタメン単体で見たときの従業員数比率はまだ名古屋本社のほうが多い状況にあります。またスタメングループ子会社の本社は引き続き名古屋のみにあるためグループ全体ではより名古屋の割合は大きいものになります。
実態としては組織の厚みが出てきた東京本社ですが、プロダクト人材の方々との外部コミュニケーションのシーンにおいては「名古屋の会社なんですよね？（関東在住なので転職は難しいですね）」というやりとりをすることがいまだに多くあり、名古屋発のスタートアップとしてアイデンティファイされることは嬉しくもありつつ、協業する文脈での興味関心が早い段階でなくなってしまう問題も避けていかなければいけない問題です。
ということで、改めてスタメンでは東京本社・名古屋本社の両拠点でプロダクト人材、つまり、エンジニア・デザイナー・プロダクトマネージャー・その他0→1人材（セキュリティ・コーポレートエンジニアリング・PMM etc.）を募集しています: https://herp.careers/v1/stmn/requisition-groups/8d5d0858-2bda-4167-80f2-2401d8fb1891
技術的な課題
2023年からスタメンは「プロダクトカンパニー」となっていくことを宣言し、現在も続いています。プロダクトカンパニーとして主要プロダクトであるTUNAGを通じて多数の機能を展開してきました。「プロダクトカンパニー」であり続けるための柱としては「人と組織」があるものの、一方で基礎レベルの技術レベルの維持・向上が求められるフェーズとなってきました。そのような経緯を踏まえて今では以下の問題が発生しています。
技術的負債を解消する過程で発生した技術的負債の整理
プロダクトカンパニーを具現化するテックリード人材の確保
新技術の導入プロセスの困難さ
技術的負債を解消する過程で発生した技術的負債に位置付けられる新たな問題として以下があります。
2023年に立ち上げたデザインシステムのDesignOps
世の中の流れに伴い、TUNAGにおいても自社製デザインシステムを立ち上げました。デザインシステムのメンテナンス・アップデートはどの組織においても難易度の高いですが、少数チームであるTUNAGにおいても難しさに直面しています。効果的な活用としてセマンティックバージョンを採用していますが、メジャーバージョンアップデートをできないケースが発生しており、DesignOpsがうまく機能していない状況です。デザインエンジニアやツーリングに注力するフロントエンドを専任で採用し、この辺りの問題解決を推進したいと思います。
Rails文脈におけるフロントエンドテクノロジーの効率的活用
Rails edgeを最大限プロダクション活用していることはお伝えしました。Railsが目指すフロントエンド技術スタックは既に導入しているものの、歴史的経緯により、フロントエンドテクノロジーはカテゴリとその世代により7種類（ユーザー向け4種類、管理者向け3種類）存在しています。こちらは創業当初より優先していた「小さなチームと権限移譲」の進め方の中で、全体を見ながら全体の最適化を優先してこなかったためだと理解しています。 前提としてこの10年ほどのフロントエンド技術の爆発的な発展とエンジニアリングの縦割り専業化により負債が溜まりやすい領域であることは多くの共感をしてもらえるところなのではないかと思います。 1つのRailsアプリケーションに対して7種類のフロントエンドアーキテクチャが存在しているというと、microfrontendと呼ばれる技術を導入しているのですか？という疑問が湧くかもしれません。実際にはそうではなく、時系列的にv1, v2.0, v2.1, …と遷移したものになります。こちらを統合的に解決する必要があります。
社内におけるこれらの問題解決はもちろん実施していく必要がありますが、前述のRubyやRuby on RailsのようなレベルでのOSSコミュニティへの還元はできていない状況なので、こちらを社内で牽引していく体制を2025年以降は取っていければと思います。
オーバーエンジニアリングを避ける
ここまで技術面をかなり説明してきたものの、技術にオーバーエンジニアリングをしたいというわけではありません。経営的観点では「それはそう」という感想を持つかもしれません。上で書いたような問題を予防的に回避していきたいと思います。
オーバーエンジニアリングか否かを経営的観点で判断する軸として、以下の観点を気にするように心がけています。
シンプルさを維持する
今必要でないことを実装しない
枯れた技術（boring technology）を大事にする
エンジニア業界においてはよく言われがちな項目かと思います。特に最後の「枯れた技術（boring technology）」については新しい技術（new technology）が青く見えてしまうこともあり、new technologyを選択するような選択をする際は長期的な効用を検討するようにしています。
シングルプロダクト・マルチマーケット戦略のその先
2022年末のTUNAG for UNIONの立ち上げを機にシングルプロダクト・マルチマーケット戦略を打ち立ててきました。以降、複数マーケットへの展開がとてもうまく機能しているものの、世界を目指す長期的な成長の観点では別の視点も取り入れる必要があります。その一つとして現在検討中であるものがマルチプロダクト化、コンパウンド戦略となります。特に2022年スタートのクラウド型IT資産管理・ログ管理ツール「漏洩チェッカー」においては
国内にもコンパウンドスタートアップとして認識される会社は多数ありますが、私が想像しているものがRipplingとなります。こちらはまだCTOレベルの構想段階ですが、同社のコンパウンド戦略の中でRippling Employee Graphをコアに位置付けており、TUNAG/漏洩チェッカーでもこのような形で展開できればと思っています。これを実現するのは現状のリソースでは難しいので、専門チームを作るべく新たなテックリード人材を募集しております。技術スタックについてはGo言語と書いていますが、それに拘らず技術選定ができればと思います。
まとめ
プロダクトカンパニーを推進していく中で必要なことを解説しました。SaaS企業においてプロダクトと技術に対する投資はもっとも中長期に影響するものであり、中長期的な効果を意識しながら推進しています。また、組織や技術の文脈においても「名古屋から東京へ、そして東京から世界へ」という文脈の中、これらを実現するために一緒に働く仲間を募集しています。
最近、PIVOT動画を公開してましたので、合わせてご覧ください。
この記事が気に入ったらサポートをしてみませんか？