【事例】ACTIVITY JAPAN CTO支援でのエンジニア組織改革

ACTIVITY JAPANは、日本国内のアウトドアアクティビティやレジャー体験を予約できるプラットフォームで、activityjapan.comとして運営されている。私がCTO支援として参画した当時、月間PVは500万を超え、掲載アクティビティ数は3万件以上。「国内最大級」の名にふさわしい規模のサービスだった。しかし、急成長の裏で技術的な課題が山積していた。

CTO支援開始時の3つの課題

CTO支援とは、企業の技術戦略を経営戦略と連携させ、エンジニア組織の能力を最大化するための助言・実行支援のことである。ACTIVITY JAPANのケースでは、以下の3つが最重要課題だった。

第一に、エンジニア組織の課題。エンジニアは15名在籍していたが、技術レベルのばらつきが大きく、コードレビューの基準も属人的だった。離職率は年間20%と業界平均（15%）を上回っていた。採用面でも、技術面接の評価基準が明確でなく、採用のミスマッチが頻発していた。

第二に、アーキテクチャの課題。サービス開始時から使い続けているモノリシックなRailsアプリケーションが肥大化し、デプロイに45分、テスト実行に2時間かかる状態だった。機能追加のたびにリグレッションが発生し、月平均のインシデント数は8件に達していた。

第三に、SEOの課題。アクティビティ予約プラットフォームにとって、SEOは生命線だ。月間500万PVの60%以上がオーガニック検索流入。しかし、Core Web Vitalsのスコアが低下傾向にあり、LCP（Largest Contentful Paint）が4.2秒と目標の2.5秒を大幅に超えていた。Google検索順位の低下が始まっており、放置すれば事業への影響は甚大だった。

エンジニア組織改革の具体的施策

エンジニア組織改革とは、技術チームの生産性・品質・モチベーションを体系的に向上させるための構造的な変更のことである。私はまず、3ヶ月間のロードマップを策定した。

採用プロセスの再設計では、技術面接を3段階に構造化した。第1段階はコーディングテスト（オンライン、60分）、第2段階はシステム設計面接（60分）、第3段階はカルチャーフィット面接（30分）。評価基準をルーブリック化し、面接官間の評価ブレを最小化した。この改革後、採用のミスマッチは70%減少し、入社後6ヶ月以内の離職者はゼロになった。

技術評価制度では、4段階のエンジニアグレード（Junior、Mid、Senior、Lead）を定義し、各グレードの技術要件とキャリアパスを明確化した。四半期ごとの技術レビューを導入し、成長の方向性をフィードバック。この制度導入後、エンジニアの離職率は年間20%から8%に改善した。

コードレビュー文化の醸成では、レビューガイドラインを策定し、全プルリクエストで最低2名のレビューを必須とした。レビュー応答時間のSLAを4時間に設定。月次の「ベストレビュー賞」を設け、質の高いレビューを称える文化を作った。結果として、本番環境でのバグ発生率は月8件から2件に減少した。

アーキテクチャ移行とSEO改善の成果

アーキテクチャ移行は、モノリスからマイクロサービスへの段階的な移行を採用した。一括移行のリスクを避け、「ストラングラーパターン」で1サービスずつ切り出す方式だ。最初に予約機能を独立サービスとして切り出し、6ヶ月で6つのマイクロサービスに分割した。

移行の成果は明確だった。デプロイ時間は45分から8分に短縮（82%削減）。テスト実行時間は2時間から25分に短縮（79%削減）。月間インシデント数は8件から1.5件に減少（81%削減）。エンジニアの開発速度（プルリクエスト数/人/週）は1.2から3.5に向上した。

SEO改善では、Core Web Vitalsの最適化に集中した。LCPは4.2秒から1.8秒に改善。CLSは0.25から0.05に改善。FIDは180msから45msに改善。これらの改善により、Google検索での平均順位が3.2ポジション上昇し、オーガニック流入は4ヶ月で28%増加した。月間PVは500万から640万に成長した。

この経験から私が確信したのは、「技術の課題は技術だけでは解決しない」ということだ。エンジニア組織、アーキテクチャ、事業指標の3つを連動させて初めて、本質的な改善が実現する。これが、20社以上のCTO・技術顧問経験から得た最大の知見だ。

よくある質問

Q: CTO支援はどのくらいの期間が必要か？

A: ACTIVITY JAPANのケースでは12ヶ月の契約だった。一般的には最低6ヶ月を推奨している。組織改革は3ヶ月で基盤を作り、残りの期間で定着と改善を繰り返す。技術的な成果は3ヶ月目から見え始めるが、組織文化の変化が定着するには6ヶ月以上かかる。

Q: 外部のCTOが社内のエンジニアに受け入れられるのか？

A: 最初の1ヶ月が勝負だ。私はまず「聞く」ことから始める。各エンジニアと1on1を実施し、現状の課題と希望を把握する。いきなり改革を始めるのではなく、チームの信頼を得てから施策を展開する。ACTIVITY JAPANでも、最初の2週間は観察とヒアリングに徹した。

Q: CRIENのCTO支援サービスの費用感は？

A: 月額50万円〜150万円が目安。稼働日数と支援範囲によって変動する。ACTIVITY JAPANの規模（エンジニア15名）であれば月額100万円程度。投資対効果で見ると、離職率の改善だけで採用コスト（1人あたり100万円〜200万円）を年間数百万円削減できる。まずは無料相談でプロジェクトの課題をお聞かせいただきたい。

まとめ

ブランディングは一朝一夕で成果が出る施策ではないが、中長期的に見れば最も高いROIをもたらす投資だ。特にAIという競争が激しい領域では、技術力だけでなくブランド力が受注の決め手となるケースが増えている。本記事のフレームワークと計測手法を参考に、自社のブランディング戦略を構築してほしい。

エンジニア組織30名規模での技術標準化の壁

ACTIVITY JAPAN CTO支援で最初に直面したのは、30名のエンジニアが各自の好みで異なるフレームワークやコーディング規約を使っている状態だった。コードレビューに1PR平均4時間かかり、デプロイ頻度は週1回に制限されていた。トップダウンで規約を押し付けるのではなく、エンジニア全員参加のRFCプロセスを導入し、3ヶ月かけてチーム全体で技術標準を策定した。結果、コードレビュー時間は平均45分に短縮され、デプロイ頻度は日次に改善された。

エンジニア組織の技術標準化は、ルールの押し付けでは定着しない。当事者が議論に参加し、合意形成を経て決定したルールだけが実効性を持つ。RFCプロセスの導入は初期コストがかかるが、長期的にはエンジニアの自律性とコード品質の両立に不可欠な投資である。この知見は、その後の組織改革支援でも繰り返し確認されている。

組織改革の定着に必要だった「成功体験の連鎖」設計

ACTIVITY JAPAN CTO支援で技術標準化を推進した際、最も重要だったのは「早期の小さな成功体験」をチーム全体に共有することだった。RFC プロセスを導入した最初の月に、あるジュニアエンジニアが提案した「エラーハンドリングの統一規約」が全員の合意を得て採用された。この成功体験がチームの空気を変えた。「自分の提案も通る」という実感が、次の RFC への参加率を3倍に押し上げた。組織改革は制度設計だけでは機能せず、「この制度は自分にもメリットがある」と個々のメンバーが体感する機会を意図的に作る必要がある。

逆に失敗したアプローチもあった。初期に技術負債の大規模リファクタリングを提案したが、「今動いているものを壊すリスク」への抵抗が強く、合意形成に2ヶ月を浪費した。この経験から、組織改革は「影響範囲が小さく、効果が可視化しやすい施策」から着手する原則を確立した。大きな改革は小さな成功の積み重ねの延長線上でしか実現しない。

レガシーRailsアプリのマイクロサービス化で踏んだ3つの地雷

ACTIVITY JAPANのモノリシックRailsアプリをマイクロサービスに移行する際、教科書には載っていない地雷を3つ踏んだ。1つ目は「ActiveRecordの関連が暗黙的にサービス境界を跨いでいた」問題。予約テーブルからユーザーテーブルへのbelongs_toが12箇所あり、サービスを分割した瞬間にN+1クエリが発生した。解決策はBFF（Backend for Frontend）層にGraphQLを導入し、サービス間のデータ結合をBFFに集約したことだ。2つ目は「セッション管理の共有」。モノリスではRailsのセッションストアを全機能が共有していたが、分割後にセッション不整合でユーザーが強制ログアウトされるバグが連発した。JWTベースの認証に移行し、2週間で解決した。

3つ目の地雷が最も厄介だった。「バッチ処理の暗黙的な依存関係」だ。深夜のバッチでアクティビティの在庫を再計算する処理があり、このバッチが予約テーブル・決済テーブル・在庫テーブルの3つを同時にロックしていた。サービス分割後、分散トランザクションの問題として表面化し、在庫数の不整合が1日平均7件発生した。最終的にSagaパターンを導入し、各サービスが独自にロールバック可能な設計に変更した。この対応だけで3週間を費やした。マイクロサービス化の見積もりには「バッチ処理の洗い出しと再設計」を必ず項目として入れるべきだ。モノリスからの移行で最もコストがかかるのは、目に見えないバッチの依存関係の解きほぐしだった。