SIerという日本独自の生態系の未来

国内企業の情報システム外注比率は約7割、IT支出の約7割が保守・運用に費やされている、という統計が繰り返し示されています。経済産業省のDXレポートが指摘するいわゆる「2025年の崖」では、レガシー維持による経済損失が最大で年間十数兆円規模（年間最大12兆円規模）に達し得ると試算されました。公開事例と現場の観察からも、クラウド移行とSaaS化が進むほどに、要件定義から試験、運用までを一括で請け負う従来型の多重下請け構造（元請け—下請け—孫請けの重層構造）は、速度と学習の観点で不利を抱えます。とはいえ、調達の厳格さやコンプライアンス対応、全国規模の人材動員といった強みは、短期には消えません。つまり、問題は「外注か内製か」の二項対立ではなく、どの能力を社内に残し、どの能力を外部の専門性に委ねるかという境界の設計に移りました。内製化（インハウス開発）とSIer活用の最適なバランスを、DevOpsやアジャイル開発、クラウド運用という文脈で再定義する段階に入ったのです。

SIerが生き残る理由と、速度が出ない構造的要因

SIerは元来、複雑な要件を安全に落とし込むプロジェクト・ファクトリーです。複数ベンダーの調達を一本化し、品質基準を維持しつつ、災害対策や監査対応まで面倒を見る。その代償として、意思決定までの承認経路が長くなり、変更コストが契約と組織の層の厚みに比例して膨らみます。固定価格契約（スコープを固定して価格を確定する契約）に代表されるリスク移転の仕組みは、要件の確定性を前提に成り立ちますが、Webやデジタルプロダクト開発が顧客行動と仮説検証を前提に回る現代では、確定性そのものが幻想に近い局面が増えました。研究データでも、アジャイルと継続的デリバリ（CD）を採用する組織ほどデプロイ頻度が高く、変更失敗率が低い傾向が示されています⁴。これはDORAメトリクス（デプロイ頻度、リードタイム、MTTR、変更失敗率）というDevOpsの標準指標に基づく知見であり、多くの国内組織がこの指標群で低成熟レンジに留まっているという報告は、構造的な遅さへの警鐘と読み替えられます⁴。

現場の事例では、元請けから三次請けに至るまでの情報損失は、仕様の曖昧さというより、学習の欠如として表面化します。ユーザーの反応がコードに反映されるまでのリードタイムが長いほど、仮説検証（Build-Measure-Learn）の単位コストは跳ね上がる。結果として、出荷はできるが成長しないシステムが量産されます。ここで責めるべきは誰かではありません。インセンティブ設計が「成果物の納品」に向きがちで、「事業の学習速度」には責任が及びにくいという、契約とガバナンスの問題です。

価値の源泉は「リスク吸収」から「変化の増幅」へ

SIerの価値は今後、変化の摩擦を下げる方向に再定義されます。調達と品質保証の機能を保ちつつ、アーキテクチャの標準化、開発環境のセルフサービス化、SRE（Site Reliability Engineering）の共通基盤化など、変化のコストを横断的に削る領域での貢献が問われます。これは、受け身の請負から、プラットフォームを提供し、プロダクトチームが自走するための安全なレールを敷く役割へのシフトです。プラットフォームエンジニアリングやガードレールの整備は、マイクロサービスやAPIエコノミーの前提条件でもあります。

三つのトレンドがSIerの役割を変える

第一に、クラウドとSaaSの普及で、システムは垂直統合から水平分解へ進みました。ベンダーが独自実装で差別化する余地は狭まり、APIとデータ契約（サービス間のインタフェース仕様）を軸に組み立てる力が重要になります。第二に、セキュリティと規制対応の難度が上がり、ゼロトラスト（境界に頼らないセキュリティモデル）や各種認証への対応は専門性の集約を促します。ここはSIerが手続きと技術の両方を持つ強い領域です。第三に、契約とガバナンスが変化を前提とする設計へ進み、準委任（時間・成果に応じた柔軟な契約）とアウトカム連動、そしてSLO（Service Level Objective：サービスの目標値）を中心に据えた信頼のマネジメントが広がります。

APIファーストと契約のコード化

要件定義書の肥大化をやめ、バージョン管理可能な契約に落とし込むと、変更が高速になります。OpenAPI（REST APIの標準仕様）やAsyncAPI（イベント駆動のAPI仕様）で振る舞いを固定し、テストと検証を自動化する。以下は、拡張メタデータでSLOを併記した簡易の契約例です。

openapi: 3.0.3
info:
  title: Orders API
  version: 1.2.0
x-slo:
  latency_p95_ms: 300
  availability: 99.9
paths:
  /orders:
    post:
      operationId: createOrder
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/Order'
      responses:
        '201':
          description: created
components:
  schemas:
    Order:
      type: object
      required: [id, items]
      properties:
        id: { type: string }
        items:
          type: array
          items: { type: string }

このように契約とSLOを同じリポジトリで管理すると、レビューは会議体ではなくプルリクエストで行われ、監査証跡も自動で残ります。SIerは契約の作成支援と検証パイプラインの提供により、変更の速度と安全性を同時に高められます。これはベンダーロックイン回避やガバナンス強化の観点でも有効です。

CTOが今すぐ着手できる境界設計

境界の設計は、能力の分解から始めます。顧客価値の仮説設定、プロダクトマネジメント、体験設計、アーキテクチャ原則といった中核は社内に残し、実装ボリュームが支配的な領域や専門特化が効く領域は、契約で振る舞いを定義したうえで外部の実行力を活用します。重要なのは、委託の単位を「人月」ではなく、「変更の安全な単位」に合わせることです。これはモジュール境界、API、データ契約、IaC（Infrastructure as Code）、そしてSLOで表現できます。マイクロサービスであれば、境界はサービスごとのAPIと運用SLOに紐づきます。

IaCとガードレールで変化の安全地帯を作る

クラウド基盤は、標準化されたガードレールを用意することで、チーム間の速度差を縮められます。以下のTerraform例は、タグ付けと暗号化を強制しつつ、監査に必要なメタデータを自動付与するものです。SIerがこの種のテンプレートを共通品として提供すると、導入組織は一貫した統制のもとで自走できます。

terraform {
  required_version = ">= 1.5"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  name   = var.system_name
  cidr   = var.cidr
  enable_dns_hostnames = true
  enable_dns_support   = true
  tags = {
    System = var.system_name
    Owner  = var.owner
    PII    = var.pii_level
  }
}

resource "aws_s3_bucket" "logs" {
  bucket = "${var.system_name}-logs"
  force_destroy = false
  server_side_encryption_configuration {
    rule { apply_server_side_encryption_by_default { sse_algorithm = "aws:kms" } }
  }
  tags = { Classification = "audit" }
}

さらに、SLOをコード化し、検証をパイプラインに組み込みます。以下は可用性とレイテンシのSLO定義を示すシンプルな例です。

service: checkout
slos:
  - name: availability
    objective: 99.9
    window: 30d
    indicator: prometheus
    query: sum(rate(http_requests_total{status!~"5.."}[5m]))
           /
           sum(rate(http_requests_total[5m]))
  - name: latency_p95
    objective: 95% under 300ms
    window: 7d
    indicator: prometheus
    query: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))

このSLOファイルをリポジトリに置き、リリース時に自動評価することで、変更がSLOを侵害していないかを即座に検出できます。契約は静的な文書から、破れば検知されるルールへ進化します。

レビューを会議からCIへ移す

契約やスキーマの検証は、CI（継続的インテグレーション）で自動化すると速度が一変します。例えばOpenAPIのスキーマをプッシュ時にバリデーションし、破壊的変更を検出したら失敗させるワークフローは次のように書けます。

name: api-contract-check
on:
  pull_request:
    paths: ["api/openapi.yaml"]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install oasdiff
        run: |
          curl -L https://github.com/Tufin/oasdiff/releases/download/v2.6.1/oasdiff_2.6.1_Linux_x86_64.tar.gz \
          | tar xz && sudo mv oasdiff /usr/local/bin/
      - name: Check breaking changes
        run: oasdiff breaking --fail-on-diff main:api/openapi.yaml HEAD:api/openapi.yaml

SIerはこのようなテンプレートをカタログ化して提供し、導入価値を「初速の向上」と「運用の持続性」で可視化できます。CTO側は、これらのテンプレートが自社のセキュリティ基準と整合するかを確認し、例外を最小化する統制の原則を決めるのが仕事です。

共創とリスク分担の新しいモデルへ

従来の固定価格や人月準委任から、成果に連動する契約に移る動きが活発です。売上やアクティブユーザー、コスト削減額など、事業KPIに基づくロイヤリティやボーナス・マリス（bonus-malus）の仕組みが現実味を増しています。もちろん、計測の厳密さと、外生要因の切り分けという難題がつきまといます。だからこそ、定義と計測をコード化して揺らぎを抑える発想が効きます。

以下は、KPIの定義と分配ルールをJSONで記述し、四半期ごとにスナップショットを取る想定の例です。監査はこのファイルと計測システムの実データを突き合わせれば済みます。

{
  "contract": "revshare-1.0",
  "period": "2025Q1",
  "kpis": {
    "new_revenue": { "baseline": 0, "target": 200000000, "actual": 225000000 },
    "active_users": { "baseline": 100000, "target": 150000, "actual": 160000 }
  },
  "payout_rules": {
    "revenue_share": { "rate": 0.06, "cap": 12000000 },
    "bonus": { "threshold": 1.05, "amount": 2000000 }
  },
  "computed": {
    "revshare": 12000000,
    "bonus": 2000000,
    "total": 14000000
  }
}

このレベルまで定義を落とすと、議論は「妥当かどうか」から「測れているかどうか」に移ります。SIerは契約運用の仕組みごと提供し、クライアントは学習速度を金銭インセンティブに直結させる。両者の利害が揃ったとき、アウトプットではなくアウトカムへ焦点が合います。

ビジネス価値の可視化が信頼を積み上げる

ROIは単なる費用対効果ではありません。新規機能の提供周期、SLOの遵守率、平均修復時間（MTTR）、そして主要KPIのトレンドといった複数の指標を束ねて初めて、事業の学習速度が見えます。四半期ごとにレビューを設け、プロダクトの仮説、観測、判断、次の施策を一本の物語にまとめる。それを支えるのが、契約・アーキテクチャ・運用のコード化です。これらは会議室ではなく、リポジトリとパイプラインの中で磨かれるのが理想です。

まとめ：境界を設計し直せば、速度は上がる

日本のSIerという生態系は、調達と品質の規律という強みを保ちながら、変化の増幅装置へと役割を変えようとしています。CTOやエンジニアリーダーにとっての焦点は、内製か外注かではありません。何を自社の戦略能力として保持し、何を契約とコードで定義して外部の実行力に載せるかという境界の設計です。もし明日一つだけ変えるなら、要件定義書の更新をやめ、APIとSLOをリポジトリで管理する小さなプロダクトから始めてみてください。次に、IaCと共通ガードレールを導入し、レビューを会議体からCIへ移す。三ヶ月後、変更のリードタイムや障害復旧の速さに改善が見え始める組織が多いはずです⁴。あなたの組織は、どの境界から設計をやり直しますか。行動を小さく、定義をコードに、学習を早く。この三点が、SIerと企業の関係を前に進める最短ルートです。

参考文献

野村総合研究所 SCSブログ「外部委託の実態と今後の方向性（日本の外部委託比率の傾向）」（https://www.nri.com/jp/media/column/scs_blog/20230605_1.html）
Publickey「企業がITに使う予算のうち、7割が既存システムの運用や維持に使われている」（https://www.publickey1.jp/blog/10/it7.html）
KOBOT Lab「DXレポートの『2025年の崖』とは」（https://kobot.jp/kobot_lab/dx/meti-report-2025/）
Splunk「DevOpsメトリクス（DORAメトリクスの概要とベンチマーク）」（https://www.splunk.com/ja_jp/blog/observability/devops-metrics.html）