社内にアーキテクチャチームがあります。「堅牢なシステムアーキテクチャ」という言葉で語られることが多いのですが、複数のプロダクトを持つ会社でアーキテクチャチームが主軸にすべきことは何か、整理してみました。基幹系SaaSを例に取りますが、CMSでも他のシステムでも、アーキテクチャチームの振る舞いの本質は変わらないと思っています。
アーキテクチャチームが担う範囲
アーキテクチャチームの仕事は3つの軸に分けて考えるとわかりやすくなります。
システムアーキテクチャ（技術的骨格）
インフラ・デプロイ構成、サービス分割の指針、データモデル設計の原則、可用性・スケーラビリティ、セキュリティアーキテクチャ。いわゆる「堅牢」という文脈はここに当たります。
開発アーキテクチャ（作り方の骨格）
ADR（Architecture Decision Record）の管理、コーディング・設計規約、共通基盤の整備、CI/CDパイプライン設計。チームが一貫した方法で作れるようにする役割です。
横断ガバナンス（組織への貢献）
技術負債の可視化・優先付け、新機能開発における設計レビュー、プロダクトチームへの技術的な意思決定の支援、技術ロードマップの策定。「チーム」として存在する理由がここにあります。
複数プロダクトを持つ会社のアーキテクチャチームが主軸にすべきこと
複数プロダクトという文脈では、どこが主軸になるかを整理します。
単一プロダクトなら、アーキテクチャチームはそのプロダクトの技術判断に集中できます。複数プロダクトへ移行した瞬間、固有の問題が生まれます。
各プロダクトが勝手に育つと、後で統合・連携できなくなる
これを防ぐことがアーキテクチャチームの存在意義です。
主軸1：プラットフォーム化
複数プロダクトが共通で使う基盤を整備します。認証・認可基盤（SSO、テナント管理）、共通APIゲートウェイ、通知・メール基盤、課金・サブスクリプション基盤。ここを整備しないと、各プロダクトが同じものを別々に作り始めます。
主軸2：データ戦略
プロダクト間でデータをどう連携するか、マスタデータ（テナント、組織、ユーザー）をどのプロダクトが持つか、分析基盤（DWH）への集約方針。基幹系SaaSでは「どのプロダクトがマスタデータを持つか」を定義しておかないと、プロダクト間で矛盾が生じます。
主軸3：技術標準のガバナンス
各プロダクトチームが独立して動ける範囲を定義します。技術スタックの選定ルール、ADRのプロセス統一、セキュリティ・コンプライアンス要件の共通化です。
アーキテクチャチームの関与の濃淡は次のように整理できます。
| 領域 | アーキテクチャチームの関与 |
|---|---|
| プロダクト内の実装詳細 | 薄い（各チームに委譲） |
| プロダクト間の境界設計 | 濃い |
| 共通基盤の設計・判断 | 濃い |
| 技術選定の承認 | 濃い |
一言でまとめると「各プロダクトが速く動けるための土台を作り、プロダクト間の矛盾を防ぐ」のがアーキテクチャチームの主軸です。プロダクトの中ではなく、プロダクトの間と下にいるイメージになります。
基盤がある状態での「整理と標準化」フェーズ
課金・マスタデータ・認証・認可は存在するものの、それぞれで揃っていないところや技術的負債があります。こうした状態は、基幹系SaaSが成熟し始めた段階によく出てきます。
このフェーズで重要なのは、負債と「ばらつき」を分けて扱うことです。混同すると優先度が狂います。
| 種類 | 意味 | 対処 |
|---|---|---|
| 技術的負債 | 将来の変更コストを上げているもの | 計画的に返済 |
| ばらつき | 統一されてないが今は動いているもの | 標準化で吸収 |
| 意図的な差異 | プロダクト特性上、違って当然のもの | そのままでいい |
全部を統一しようとするのが最大の罠です。
標準化の優先度が高いのは、セキュリティに関わる負債（認証・認可のばらつきは特に危険）、複数プロダクトをまたぐ連携に関わる部分（APIの仕様がバラバラなど）、開発速度を直接落としている負債です。逆に後回しでいいのは、各プロダクト内に閉じていて外に影響しないものになります。
まとめ
このフェーズのアーキテクチャチームは、コードを書くより「何を直す順番か」を決めて組織を動かすことが仕事の中心になります。技術判断だけでなく、プロダクトチームの開発計画と交渉しながら負債返済を組み込んでいく調整力が問われます。
補足：2025年の壁
経済産業省が2018年に出した「DXレポート」は、古いシステムの老朽化と IT 人材不足を放置すれば、2025年以降に年間最大12兆円の経済損失が生じると警告しました。これが「2025年の崖」です。
『アーキテクチャモダナイゼーション』の翻訳版は2026年に出ました。崖を越えたタイミングで、崖の越え方を説く本が届いた形です。著者のあとがきには「もう遅いんじゃないか」という問いへの応答があります。
読んでいて腑に落ちた感覚があります。古いシステムという借金を返しながら、生成 AI という「今なら低金利ですよ」という話が同時に来る。片付けなきゃいけないことと手を出したいことが、同時に押し寄せてきます。
著者が伝えたかったのは、モダナイゼーションは「やる・やらない」の問題ではなく「どうやるか」の問題だ、ということです。やらない選択肢はありません。それなのに方法がわからない。わからないまま時間だけが過ぎていきます。この本がその「どうやるか」のヒントになることを著者は願っています。そこが響きました。
土台がぐらついている上に、丈夫な家は建てられません。屋根を豪華にすればするほど、家全体が傾いていきます。では土台を直せばいいかというと、単純な話ではありません。その土台には何年分もの判断と積み重ねがのっているからです。
これを技術的負債と呼びます。ただ、この「負債」という言葉の響きがよくありません。借金、返済義務、マイナスといったイメージが先行します。
本にはこんな見方が書かれていました。住宅ローンを組めるのは、銀行から「返せる」と信用された証拠です。技術的な負債も同じで、それを抱えながら事業を回せているのはビジネスが成立している証拠になります。技術の美しさより顧客への価値提供を優先した結果として負債が積み上がっているなら、それはある意味、正しい判断の積み重ねでもあります。そのフレームが気に入りました。
負債とどう向き合うか。著者の視点はここでも逆転しています。モダナイゼーションは「負債を返す」作業ではなく、「資産を再構築する」作業だといいます。過去を否定するのではなく、過去の上に未来を積むわけです。
この視点の違いは大きな要素です。「返済」という言葉を使うと、過去は消し去るべきものになります。ですが「再構築」と捉えると、過去の判断はそのまま土台になります。何年も事業を支えてきたシステムには、コードに刻まれた知識があります。それを丸ごと捨てるのではなく、引き継ぎながら形を変えていく。それがモダナイゼーションの本質だということです。
参考メモ：基幹系SaaSの設計領域
基幹系（会計・ERP・人事など）のSaaSでは、「データの正確性」と「止まらないこと」が最優先になるため、一般的なWebサービスより設計の制約が厳しくなります。以下は基幹系を例にした設計領域のメモです。
マルチテナント設計
テナントデータをどう分離するかは基幹系SaaSの核心です。方式は大きく3つあります。
| 方式 | 概要 | トレードオフ |
|---|---|---|
| Shared DB / Shared Schema | テナントIDカラムで分離 | コスト低・データ漏洩リスク高 |
| Shared DB / Separate Schema | スキーマ単位で分離 | バランス型 |
| Separate DB | DB単位で完全分離 | 安全・コスト高 |
大手企業向けの基幹系では Separate DB か Separate Schema が多くなります。
データ整合性・トランザクション設計
最も妥協できない領域です。分散トランザクション（Sagaパターンなど）、冪等性の確保、イベントソーシング（仕訳・ログなど変更履歴が重要な領域）、監査ログ（いつ・誰が・何を変えたかの追跡）が主な関心事になります。
可用性・障害設計
SLA定義（99.9% = 年間8.8時間ダウン許容、99.99% = 52分）、サーキットブレーカー、グレースフルデグラデーション、DR（RTO/RPOの定義とフェイルオーバー戦略）。
ネットワーク・セキュリティアーキテクチャ
ゼロトラストアーキテクチャ（ZTA）は「信頼しない、常に検証する」を原則とする設計思想です。アーキテクチャチームが方針を持つべき範囲は次のとおりです。
- テナント間のネットワーク分離方針。VPC per tenant など、どの粒度で分離するかの設計判断
- サービス間通信のセキュリティ。mTLS の適用範囲、サービスメッシュの導入可否
- 認証・認可基盤との接続。OIDC・SCIM・SSO の標準化方針
- 開発者の本番アクセスポリシー。Bastion 廃止や VPN レスをどう実現するかの原則定義
SASE 製品の選定・運用や、ネットワーク機器の設定はインフラ・セキュリティチームが担う領域です。
基幹系特有の設計課題
一般SaaSと違いが出るのは、会計期・年度またぎ処理、法改正対応（インボイス制度、電帳法など）、オンプレ連携（CSV、SFTP、EDIなど）、月末・年末の締め処理でのバッチ集中です。