社内にアーキテクトチームがある。「堅牢なシステムアーキテクチャ」という言葉で語られることが多いが、複数のプロダクトを持つ会社でアーキテクトチームが主軸にすべきことは何か、整理してみた。基幹系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など）、月末・年末の締め処理でのバッチ集中だ。