eternal-studentのブログ

様々な便利なWebツールや知的に面白いコンテンツを共有しています。

トップ > ビジネス > 日本企業はなぜ「カスタム開発」を好むのか？—— SaaS標準 vs カスタマイズの合理性を徹底検証する

日本企業はなぜ「カスタム開発」を好むのか？—— SaaS標準 vs カスタマイズの合理性を徹底検証する

ビジネス IT 社会

日本企業はなぜ「カスタム開発」を好むのか？
—— SaaS標準 vs カスタマイズの合理性を徹底検証する

「また現場からの追加要件ですか……これでは標準パッケージの意味がありません」

基幹システム刷新プロジェクトの定例会議。ITベンダーのプロジェクトマネージャーは、20ページに及ぶ「業務要件追加リスト」を前に、疲労の色を隠せない。

「いや、これは現場が長年積み上げてきた業務ノウハウなんだ。簡単に捨てられるわけがない」業務部門のベテラン課長が反論する。「それに、ライセンス料で毎年数千万円取られるくらいなら、一度作ってしまった方が安いだろう？」

CFOが眉をひそめる。「その『一度作る』コストは本当に見えているのか？ 10年後もメンテナンスできる保証は？」

この光景は、日本企業のIT投資の現場で繰り返されてきた。「パッケージやSaaSを導入するはずが、気づけば大規模カスタマイズの泥沼へ」──そんな話は枚挙にいとまがない。

一方で、欧米企業は "Fit-to-Standard"（業務を標準パッケージに合わせる）を原則とし、カスタマイズを最小限に抑える傾向が強いと言われる。主要なSaaSベンダーは「標準機能で大部分をカバーできる」とし、Fit-to-Standardの考え方では原則として標準機能のまま使うことを強く推奨する。

では、日本企業の「カスタム志向」は本当に非合理なのか？ それとも、何らかの合理性があるのか？

本稿では、感情論や印象論ではなく、検証可能な論点と定量的な比較によって、この問いに答える。パッケージ/SaaS標準採用のメリットと、カスタム開発のメリットを、同じ土俵（TCO、リスク調整後価値、オプション価値）で評価し、「どのような条件下で、どちらの選択が合理的か」を明らかにする。

1. 定義の整理：「カスタマイズ」とは何か？

議論を始める前に、用語を整理しておく必要がある。「カスタマイズ」という言葉は、以下のように異なるレベルを含んでいる。

1.1 カスタマイズの5段階

  1. 設定レベル（Configuration）：製品が標準で提供する設定項目（ワークフロー、権限、フォーム項目、レポート等）を調整する。アップグレード時の互換性は保たれる。
  2. 拡張レベル（Extension）：API、プラグイン、アドオンを使って機能を追加する。製品が提供する拡張フレームワーク内での開発。
  3. 統合レベル（Integration）：他システムとのデータ連携や、周辺システム（データウェアハウス、BIツール等）の構築。製品本体には手を入れない。
  4. 改変レベル（Modification）：製品のソースコードを直接書き換える。アップグレードが困難になる。
  5. 独自開発レベル（Custom Build）：パッケージを使わず、ゼロから独自システムを構築する。

本稿では、主に3（統合）〜5（独自開発）を「カスタム開発」と呼び、1〜2は「標準範囲内のカスタマイズ」として区別する。問題となるのは、「標準で提供される機能を使わず、独自実装に走る」意思決定である。

1.2 Fit-to-Standard vs Fit-to-Unique

  • Fit-to-Standard：業務プロセスを、パッケージ/SaaSの標準機能に合わせる。「製品が推奨するベストプラクティスに従う」思想。
  • Fit-to-Unique：自社の業務プロセスを維持し、システムを業務に合わせる。「現場の知恵を尊重し、システムを道具として使う」思想。

この2つは、単なる技術選択ではなく、組織文化と権力構造の反映でもある。IT部門が主導すればFit-to-Standardになりやすく、業務部門が主導すればFit-to-Uniqueになりやすい。

1.3 差別化業務 vs 非差別化業務

カスタム開発の是非を論じる際、最も重要な切り分けは「その業務が競争優位の源泉か否か」である。

  • 差別化業務：顧客体験、製品開発、サプライチェーン最適化など、競合との差を生む活動。ここでの独自性は価値を持つ。
  • 非差別化業務：経費精算、給与計算、会計処理など、「やらなければならないが、差別化要因にはならない」活動。標準化が望ましい。
重要な指摘：多くの企業は、非差別化業務にまでカスタマイズを施している。「うちの会社は特殊だから」という主張の9割は、客観的には特殊ではない。これが問題の本質である。

2. なぜ日本企業はカスタム志向が強いのか？ ── 5つの仮説

日本企業のカスタム開発志向は、しばしば「文化」や「体質」で片付けられるが、それでは解決策が見えない。ここでは、より構造的な要因を5つ挙げる。

※これらの要因のうち、企業が短期的に変えられるものと、構造的に変えにくいものがある。どこに介入余地があるかは、7章の意思決定フレームワークで整理する。

2.1 稟議・監査・内部統制の要求水準

日本企業、特に大企業では、稟議承認の証跡、監査対応、内部統制報告（J-SOX）への対応が、システム要件として厳格に求められる。海外製SaaSの標準機能では、「誰がいつ承認したか」「承認権限のマトリクス」「代理承認の記録」といった細かい要件を満たせないことがある。

これは単なる「日本の特殊性」ではなく、規制環境と訴訟リスクの差による合理的な差異である。米国企業は訴訟リスクに対してシステムで対応するが、日本企業は「プロセスの証跡」に重きを置く。

2.2 雇用慣行と人事ローテーション

終身雇用と定期的なジョブローテーションを前提とする日本企業では、「業務を標準化してシステムに落とし込む」よりも、「熟練者の暗黙知に依存する」方が短期的には効率的である。標準化には、業務の明文化、教育、ルール徹底が必要だが、これは「人が育てば済む」文化とは相性が悪い。

結果として、「現場のベテランがExcelとメールで回している複雑な業務」を、そのままシステム化しようとする。これがカスタマイズ要求の源泉となる。

2.3 SIer産業構造とインセンティブ設計

日本には、受託開発を生業とする強力なSI産業が存在する。ビジネスモデル上、「標準パッケージをそのまま売る」よりも、「カスタマイズ開発で工数を積む」方が収益性が高くなりやすい構造がある。顧客側も、「発注先に丸投げできる」安心感から、この構造を受け入れてきた。

これは、プリンシパル・エージェント問題の典型である。発注側（企業）と受注側（SIer）の利害が完全には一致しない場合、情報の非対称性によって、結果的に「カスタマイズが過剰になりやすい」インセンティブ構造が生まれる。

SIer産業の構造的制約

さらに重要なのは、日本のSIer産業が規模の経済を享受しにくい構造にあることだ。

グローバルなSaaSベンダー（Salesforce、Microsoft、Google等）は、数百万〜数千万ユーザーに対して同一の製品を提供するため、巨額の研究開発投資が可能である。米国では総報酬（給与+株式報酬）が20万ドル超も一般的であり、世界トップレベルの人材を集められる。結果として、製品の品質、セキュリティ、パフォーマンスは極めて高い。

一方、日本のSIerは受託開発モデルであり、案件ごとに個別のシステムを構築する。同じシステムを何万社にも売るわけではないため、規模の経済が働きにくい。したがって：

  • 人材への投資に制約：人月単価モデルでは、個人の生産性が10倍でも報酬は限定的になりやすい。結果として、優秀なエンジニアは外資IT企業やスタートアップに流出する傾向がある。
  • 投入できる人数が限定的：大規模SIerでも、個別案件に割ける人数には限界がある。一方、Microsoftは数千人のエンジニアを1つの製品（Office 365やAzure）に投入できる。
  • 品質面での制約：限られた予算と人数で、短納期で開発するため、テスト不足、セキュリティ脆弱性、保守性の低いコードが生まれやすい構造的制約がある。

これは、産業構造とインセンティブ設計の問題であり、個々のSIerの努力だけでは解決が難しい。受託開発モデルそのものが持つ構造的制約と言える。

2.4 レガシーシステムとの結合依存

日本企業の多くは、30年以上稼働する基幹系システムを抱えている。これらは、COBOLやメインフレームで構築され、複雑なバッチ処理とデータ構造を持つ。新しいSaaSを導入する際、「既存システムとの整合性」が最優先事項となり、結果的にカスタマイズが不可避となる。

これは技術負債の問題であり、「過去の意思決定が現在を縛る」経路依存性（Path Dependency）の例である。経済産業省の「DXレポート」では、このままでは2025年以降、最大で年間12兆円の経済損失が生じる可能性が指摘されている（ただし、この試算については前提条件や根拠に関する議論も存在する）。

2.5 現場権限の強さと「業務主導」文化

日本企業では、現場（営業、製造、調達等）の発言力が強く、IT部門は「サービス提供者」の位置づけになりやすい。「現場が使いやすいシステムを作ること」が目的化し、「全社最適」や「将来の保守性」が後回しにされる。

欧米企業では、CIOやCDOが経営陣として全社IT戦略を統制する例が多いが、日本ではIT部門が「コストセンター」として扱われ、権限が限定的である。

反論の余地：これらの仮説はすべて「構造的要因」であり、単に「意識を変えればいい」という話ではない。したがって、「日本企業はカスタム志向だから非合理」という単純な批判は成立しない。問題は、「これらの構造を前提としたとき、どの選択が合理的か」である。

3. パッケージ/SaaS標準採用のメリット ── なぜ "Fit-to-Standard" が推奨されるのか

ここでは、パッケージやSaaSを「標準機能のまま使う」ことのメリットを、多角的に整理する。重要なのは、初期コストだけでなく、運用・アップグレード・組織能力の観点を含めた総合評価である。

3.1 実装コストと導入スピード

標準パッケージは、すでに動作する製品である。設定とデータ移行だけで稼働するため、ゼロから開発するよりも圧倒的に速い。SaaSであれば、インフラ構築も不要である。

  • 標準パッケージ導入：3〜6ヶ月
  • 軽度カスタマイズ：6〜12ヶ月
  • 大規模カスタマイズ：12〜24ヶ月
  • 独自開発：24ヶ月〜（終わらないプロジェクトも多数）

市場環境の変化が速い現代において、「12ヶ月遅れる」ことは、機会損失として認識されるべきである。

3.2 アップグレードと継続的改善

標準パッケージ/SaaSの最大のメリットは、ベンダーが継続的に機能改善を行うことである。セキュリティパッチ、新機能追加、UI改善、パフォーマンス最適化──これらがすべて、サブスクリプション料金に含まれる。

一方、カスタム開発したシステムは、すべての改善を自前で行う必要がある。ベンダーがアップグレードを提供しても、カスタマイズ部分との互換性検証が必要となり、事実上アップグレード不能になるケースが多い。

実例：ある製造業では、10年前にERPをカスタマイズ導入した。その後、ベンダーが3回メジャーアップグレードを提供したが、一度も適用できていない。理由は、カスタマイズ部分の再実装に1億円以上かかるため。結果、古いバージョンを使い続け、セキュリティリスクを抱えている。

3.3 運用コストとセキュリティ

SaaSの場合、インフラ運用、監視、バックアップ、災害対策はすべてベンダーが担当する。オンプレミスのカスタムシステムでは、これらすべてを自社で賄う必要がある。

セキュリティに関しても、主要SaaSベンダー（Salesforce、Microsoft、Oracle等）は、専門のセキュリティチームを持ち、常時脅威監視を行っている。中堅企業が同レベルのセキュリティ体制を自前で構築することは、コスト的に不可能である。

3.4 採用・育成コストの削減と即戦力化

標準的なパッケージ/SaaSであれば、スキルを持つ人材が労働市場に存在する。「SAP経験者」「Salesforce認定者」といった形で、即戦力を採用できる。

一方、独自開発システムは、「当社システムの熟知者」しか扱えない。退職や異動によって、知識が失われるリスクが高い。

業務要員の即戦力性の圧倒的な差

この差は、IT人材だけでなく、業務要員の採用・配置においても決定的である。

例えば、グローバル企業が海外拠点を立ち上げる際、SAP経験者を現地で採用すれば、1週間程度で経理業務を開始できる。なぜなら、SAPの標準的な画面操作、勘定体系、承認フローは世界共通だからである。新入社員であっても、「SAP FI（財務会計）モジュールの基本操作」は大学やトレーニングセンターで学んでいる可能性が高い。

一方、日本企業の独自システムの場合、新規採用者や異動者は、以下をゼロから学ぶ必要がある：

  • 独自の業務体系（「うちの会社の経費精算はこういう流れ」）
  • 独自のデータ体系（「この項目は何を意味するのか」「なぜこの分類なのか」）
  • 独自のソフトウェア操作（「このボタンを押すと何が起きるのか」「どの順番で入力するのか」）
  • 独自の例外処理（「このケースだけは手作業で対応」といった暗黙知）

これには数ヶ月の時間がかかり、その間はベテラン社員が付きっきりで教育する必要がある。つまり、採用コストだけでなく、育成コスト、機会損失（ベテランの時間を奪う）が膨大になる。

この問題は、人事ローテーションが頻繁な日本企業においては、さらに深刻である。2〜3年ごとに人が入れ替わるたびに、同じ教育コストが発生する。標準パッケージであれば、「SAP経験者」という条件で社内公募すれば、即座に配置転換が可能である。

3.5 ベストプラクティスとエコシステムの活用

主要なパッケージ/SaaSは、数千〜数万社の導入実績から得られたベストプラクティスを反映している。これは、「他社の成功事例を自社に取り込む」ことを意味する。

しかし、それ以上に重要なのは、標準パッケージを前提とした膨大なエコシステムが存在することである。

エコシステム効果：カスタム開発では得られない圧倒的優位性

標準パッケージ、特にSAP、Oracle、Salesforce、Microsoft Dynamics等の主要製品には、以下のようなエコシステムが形成されている：

  • データ分析・BIツール：SAP Analytics Cloud、Tableau for SAP、Power BI for Dynamics等、パッケージのデータ構造を前提とした分析ツールが存在する。データ接続の設定は数時間で完了し、すぐにダッシュボードを構築できる。
  • 業界特化ソリューション：製造業向けSAP、金融機関向けOracle、小売業向けDynamics等、業界ごとのテンプレートやアドオンが存在する。
  • コンサルティングサービス：Deloitte、PwC、アクセンチュア等の主要コンサルファームは、標準パッケージの導入・最適化に特化したチームを持つ。短期間（数週間〜数ヶ月）のコンサルで、ベストプラクティスを導入できる。
  • トレーニング・認定制度：公式トレーニング、認定試験、オンライン教材が充実しており、社員教育が容易。
  • サードパーティ製品：経費精算アプリ、ワークフロー拡張、AI予測分析等、パッケージと連携する製品が数百〜数千存在する。

データドリブン経営における決定的な差

特に、データドリブン経営を実現する際の差は決定的である。

例えば、「売上予測の精度を上げたい」「在庫最適化をしたい」「顧客離反を予測したい」といった要求に対して：

  • SAP等の標準パッケージの場合：既存のソリューション（例：SAP Integrated Business Planning、SAP Customer Data Cloud）を導入すれば、数週間〜数ヶ月で稼働する。データ構造は標準化されているため、コンサルタントはすぐに分析を開始できる。
  • カスタム開発の場合：まず、コンサルタントが「独自の業務体系」「独自のデータ体系」「独自のデータ取得方法」を学習する必要がある。これに数ヶ月〜半年かかる。その後、データクレンジング、ETL（抽出・変換・ロード）の設計、分析モデルの構築を一から行う。費用は数千万円〜数億円、期間は1〜2年に及ぶ。

この差は、コンサルタントの採算性にも影響する。標準パッケージであれば、コンサルタントは過去の知識・ツール・テンプレートを再利用できるため、短期間・低コストで価値を提供できる。一方、独自システムでは、すべてを学習・カスタム開発する必要があり、採算が合わないため、優秀なコンサルタントが引き受けにくい。

結果として、カスタム開発企業は、「データ活用したいが、誰も手伝ってくれない」という孤立状態に陥りやすい。

グローバル展開における標準化の威力

グローバル展開する企業では、「世界中の拠点で同じシステム・同じプロセスを使う」ことで、以下が実現できる：

  • 連結決算の自動化（各拠点のデータ構造が統一されているため）
  • グローバルでの在庫最適化、サプライチェーン可視化
  • 人材の国際異動（「SAP経験者」なら、どの国でも即戦力）
  • ベストプラクティスの横展開（ある拠点の改善を他拠点にコピー）

これは、独自システムでは実現が極めて困難である。

3.6 変更容易性：Lead Time for ChangesとChange Failure Rate

ビジネス環境の変化に対応するには、システムの変更が必要である。ここで重要な指標は、DevOps Research and Assessment（DORA）が提唱する2つの指標である：

  • Lead Time for Changes：変更要求がコミットされてから本番環境に反映されるまでの時間
  • Change Failure Rate：本番環境への変更のうち、障害や不具合を引き起こす割合

標準パッケージの設定変更であれば、数日〜数週間で完了し、失敗率も低い。カスタムコードの修正は、数週間〜数ヶ月かかり、テスト不足によるバグ混入リスクが高い。

変更内容 標準パッケージ カスタム開発
承認フローの変更 設定画面で数時間〜数日 コード修正+テスト、1〜2週間
新規フィールド追加 設定画面で数時間 DB変更+画面修正+テスト、1週間〜
新機能追加 ベンダーリリース待ち、または拡張機能利用 要件定義〜開発〜テスト、1〜3ヶ月
セキュリティパッチ適用 ベンダーが自動適用、または数日 影響範囲調査+テスト+適用、数週間

4. カスタム開発のメリット ── 反論として強く提示する

ここまで標準採用のメリットを述べたが、カスタム開発が合理的である状況も確かに存在する。それを無視した議論は、一方的である。

4.1 業務・規制要件の特殊性

すべての業務が標準化可能なわけではない。以下のような場合、カスタマイズは避けられない。

  • 法規制対応：金融機関のマネーロンダリング対策、製薬企業のGxP対応、エネルギー企業の報告義務など、業界固有の規制要件は、汎用パッケージでカバーされていないことが多い。
  • 複雑な業務ロジック：製造業の生産計画最適化、物流企業の配車アルゴリズム、保険会社の引受審査ルールなど、高度な最適化や判断ロジックは、汎用製品では実現困難。
  • データ主権とコンプライアンス：機密データを外部SaaSに預けられない場合（防衛、金融、医療等）、オンプレミスまたはプライベートクラウドでの独自構築が必要。

4.2 競争優位と模倣困難性

前述の「差別化業務」において、独自システムは競争優位の源泉となり得る。

  • Amazon：物流システム、レコメンデーションエンジン、AWSインフラ──すべて独自開発。これが競争力の核心。
  • Netflix：コンテンツ配信基盤、視聴データ分析、レコメンデーション──すべて自社開発。
  • トヨタ：生産管理システム、サプライチェーン最適化──独自のカンバン方式を反映。

これらの企業は、「標準パッケージでは実現できない独自性」を追求し、それがビジネスモデルそのものとなっている。

4.3 統制とガバナンス

独自システムを持つことで、以下の統制が可能になる。

  • データ主権：自社のデータを完全にコントロールできる。SaaSベンダーの規約変更や、サービス終了リスクから独立。
  • 可用性とBCP：ミッションクリティカルなシステムでは、「ベンダーのSLA（99.9%）では不十分」という場合がある。自社で冗長化・災害対策を設計する。
  • 監査対応：監査法人から「システムの処理ロジックを開示せよ」と要求された場合、SaaSではブラックボックスだが、独自開発なら完全に説明可能。

4.4 「ライセンス料よりSIer構築費が安い」論の成立条件

これは最も論争的な主張である。大企業の調達部門からは、「SaaSのライセンス料は年間数千万円〜数億円だが、SIerに発注すれば初期費用だけで済む」という声が聞かれる。

この主張が成立するのは、以下の条件を満たす場合のみである。

  1. 要件が安定している：10年間、業務プロセスが変わらない前提。
  2. 運用コストが低い：保守要員が少なく、インフラコストも低い。
  3. アップグレード不要：セキュリティリスクを許容し、古いバージョンを使い続ける。
  4. 会計上の処理：CAPEX（資産計上）が望ましく、OPEX（費用化）を避けたい事情がある。

しかし、これらの前提は、現代のビジネス環境では非現実的である。詳細は次章で検証する。

4.5 交渉力と値上げ耐性

SaaSベンダーは、契約更新時に値上げを要求することがある。特に、顧客がそのSaaSに依存している場合、交渉力はベンダー側にある。

独自開発システムであれば、「保守ベンダーを変える」「内製化する」といった選択肢があり、交渉力を保てる。これは、取引コスト理論（Williamson, 1979）における「資産特殊性」の問題である。

4.6 アーキテクチャ自由度

最新の技術トレンド（イベント駆動アーキテクチャ、マイクロサービス、データメッシュ、AI/ML統合等）を取り入れる際、汎用パッケージでは制約が多い。

独自開発であれば、以下のような先進的なアーキテクチャを採用できる。

  • リアルタイムデータパイプライン（Kafka、Flink等）
  • 機械学習モデルの組み込み（推薦、予測、異常検知等）
  • API-firstアーキテクチャによる柔軟な統合
小括：カスタム開発には、確かにメリットがある。問題は、「そのメリットが、デメリットを上回るか」であり、それは定量的に評価されるべきである。

5. TCO比較と価値評価 ── 同じ土俵で比べる

ここで、パッケージ/SaaS標準採用と、カスタム開発を、Total Cost of Ownership（TCO）の観点で比較する。

5.1 TCOの費目一覧

費目 SaaS標準 カスタム開発 備考
初期導入コスト 低（設定+移行） 高（要件定義+開発+テスト） カスタムは初期コストが数倍
ライセンス料（年間） 高（ユーザー数×単価） 低〜無（買い切り型の場合） SaaSはサブスクリプション型
インフラコスト 無（SaaSに含まれる） 高（サーバー、ネットワーク、運用） オンプレミスの場合
保守・運用人件費 低（ベンダーが担当） 高（専任チーム必要） カスタムは属人化リスク大
アップグレードコスト 無〜低（自動または軽微） 高（再実装が必要） カスタムは事実上不可能なケースも
セキュリティ対策 低（ベンダーが対応） 高（自社で脆弱性対応） ゼロデイ攻撃への対応速度が課題
変更・改善コスト 低（設定変更で対応） 高（コード修正+テスト） ビジネス変化への追従性
採用・育成コスト 低（市場にスキル保持者） 高（独自知識の伝承必要） 退職リスク、引継ぎコスト
業務要員の即戦力化 高（1週間で業務開始可能） 低（数ヶ月の学習期間必要） 異動・配転の容易性に直結
データ活用・分析 低（既存ツール・サービス利用） 高（独自開発、学習コスト大） エコシステムの有無が決定的
コンサルティング 低（短期間、標準手法） 高（学習期間、カスタム対応） 優秀なコンサルは標準を好む
機会損失 低（早期稼働、迅速改善） 高（開発遅延、硬直性） 市場投入遅れの損失
障害時の損失 中（SLA保証あり） 中〜高（自社対応） 事故対応体制の有無

5.2 簡易数値モデル（仮定）

以下は、「中堅製造業（従業員500名）が、営業支援システムを導入する」場合の試算例である。数値はあくまで仮定であり、実際のプロジェクトでは見積もりが必要である。

前提条件

  • 評価期間：10年間
  • ユーザー数：200名
  • 割引率：5%（現在価値計算用）
  • 年金現価係数：7.72（5%・10年）

SaaS標準採用の場合（例）

  • 初期導入：500万円（設定、データ移行、トレーニング）
  • 年間ライセンス：1,200万円（200名×月5,000円×12ヶ月）
  • 年間運用コスト：200万円（社内管理者1名分）
  • アップグレード：無料（自動）
  • 変更対応：年間100万円（軽微な設定変更）

10年間TCO（現在価値）：500万 + (1,200万 + 200万 + 100万) × 7.72 ≒ 1.21億円

カスタム開発の場合（例）

  • 初期開発：5,000万円（要件定義、設計、開発、テスト、導入）
  • インフラ初期：500万円（サーバー、ネットワーク）
  • 年間保守料：500万円（ベンダー保守契約）
  • 年間運用コスト：800万円（専任SE 2名、インフラ運用）
  • 変更対応：年間300万円（業務変更への対応）
  • アップグレード：3年ごとに2,000万円（3・6・9年目に発生と仮定）

10年間TCO（現在価値）：
初期 5,500万 + (500万 + 800万 + 300万) × 7.72 + 2,000万×(1/1.05³ + 1/1.05⁶ + 1/1.05⁹)
≒ 5,500万 + 1億2,352万 + (1,728万 + 1,492万 + 1,289万)
≒ 2.24億円

感度分析：どの前提で逆転するか

上記では、SaaS標準の方が約1億円安い。しかし、以下の前提が変わると、結論が変わる可能性がある。

  • ライセンス料が2倍になる：SaaS TCOは約2.1億円となり、依然としてSaaSが有利だが、差は縮まる。
  • カスタム開発の運用コストが大幅に低減（優秀な内製チームがいる）：カスタムTCOは約1.9億円まで下がる可能性。
  • 評価期間が20年になる：SaaSは累積ライセンス料が膨らむが、カスタムも追加のアップグレード費用が発生する。
重要：TCO比較は、前提条件と割引（現在価値）に極めて敏感である。比較対象の費目を揃え、将来費用は原則として現在価値に割り引いて評価することが必須である。自社の状況を精緻にモデル化することなしに、「どちらが安い」とは言えない。

5.3 リスク調整後の価値評価

TCOだけでなく、リスクも考慮する必要がある。

  • SaaSのリスク：ベンダーのサービス終了、値上げ、セキュリティ事故、データ主権の喪失
  • カスタム開発のリスク：開発遅延、予算超過、属人化、技術陳腐化、セキュリティ脆弱性、運用障害

これらのリスクを期待損失として定量化し、TCOに加算する。例えば、「カスタム開発で、開発遅延による機会損失が3,000万円発生する確率が50%」であれば、期待損失は1,500万円である。

5.4 リアルオプション価値

さらに高度な評価として、リアルオプション理論（Trigeorgis, 1996）を適用できる。

  • 成長オプション：将来、ビジネスが拡大した場合に、システムを容易にスケールできる価値。SaaSは柔軟、カスタムは制約あり。
  • 撤退オプション：失敗した場合に、損失を限定して撤退できる価値。SaaSは契約解除だけ、カスタムは資産が無駄になる。
  • 乗り換えオプション：より良い製品が登場した場合に、乗り換えられる価値。SaaSは移行コストが低い、カスタムは高い。

これらのオプション価値を合算すると、SaaSの方が「柔軟性」という無形価値で優位となることが多い。

6. 「SIer構築費の方が安い」論の精密化 ── 何が比較されているのか？

ここで、冒頭のシーンに戻ろう。「ライセンス料で毎年数千万円取られるくらいなら、一度作ってしまった方が安い」という主張は、どこまで正しいのか？

6.1 比較のミスリード：費目の非対称性

この主張は、しばしば以下のような非対称な比較に基づいている。

比較項目 SaaSの場合（誤った比較） カスタム開発の場合（誤った比較）
比較される費目 年間ライセンス料のみ 初期開発費のみ
除外される費目 導入コスト、運用コスト（ベンダー側で吸収） 保守料、運用人件費、アップグレード、インフラ

つまり、「SaaSは年間1,200万円」と「カスタムは初期5,000万円」を比較し、「5年で元が取れる」と結論づける。しかし、カスタムの年間運用コスト（上記例では1,600万円）とアップグレード費用（現在価値で約4,500万円）を無視している。

6.2 CAPEX vs OPEX：会計処理が意思決定を歪める

日本企業の多くは、以下の理由でCAPEX（資産計上）を好む。

  • 予算枠の違い：CAPEX（投資予算）は別枠で確保されやすいが、OPEX（経費予算）は毎年の利益圧迫要因として嫌われる。
  • 減価償却の効果：資産計上すれば、費用は5年間に分散される。一方、SaaSライセンス料は全額が当期費用。
  • 評価指標の歪み：ROA（総資産利益率）やROIC（投下資本利益率）を重視する企業では、OPEXの方が有利に見えることもあるが、逆にEBITDA重視ならCAPEXが好まれる。

しかし、会計上の見え方と、経済的実態は別物である。キャッシュフローベースで評価すれば、上記のTCO比較が正しい。

6.3 「安く見えるが高く付く」パターン

カスタム開発が「安く見える」のは、以下のコストが顕在化していないからである。

  1. アップグレード不能：初期開発費は安くても、5年後に「全面刷新」が必要になり、再度5,000万円かかる。
  2. 属人化：開発を担当したSEが退職し、後任が見つからず、「ブラックボックス」化。改修不能。
  3. 技術負債：古い技術で構築したシステムは、セキュリティリスクが高まり、対応コストが急増。
  4. 機会損失：ビジネス要求への対応が遅れ、競合に先を越される。
  5. エコシステムの欠如：データ分析、AI活用、業務改善のための外部サービスが利用できず、すべてを独自開発する必要がある。
  6. 人材調達コスト：業務要員の育成に数ヶ月かかり、異動・配転の柔軟性が失われる。

6.4 逆に「本当に安い」条件

一方で、カスタム開発が本当に合理的となる条件もある。

  • 要件が極めて安定：10年間変わらない業務（例：法定帳票の作成）。
  • 内製能力がある：自社にエンジニアチームがおり、保守・改善を内製できる。SIerに依存しない。
  • 標準化された共通部品：フレームワークやライブラリが整備されており、低コストで開発できる。
  • データ主権が絶対：規制や機密性の理由で、外部SaaSを使えない。
  • エコシステム不要：データ分析、外部連携、コンサル支援が不要な、完全独立したシステム。
判定基準：上記5つの条件をすべて満たす場合のみ、カスタム開発が合理的。1つでも欠ければ、SaaS標準を検討すべき。

7. 意思決定フレームワーク ── 読者が使える形で提示

ここまでの議論を踏まえ、実務で使える意思決定フレームワークを提示する。

7.1 二次元マトリクス：差別化度 × 変化頻度

以下のマトリクスで、システムを分類する。

  変化頻度 低 変化頻度 高
差別化度 高 カスタム開発（競争優位を固定化） 内製アジャイル開発（継続的改善）
差別化度 低 SaaS標準（コスト最小化） SaaS標準 + API統合（柔軟性確保）

7.2 スコアリング評価表

より精緻な評価には、以下のスコアリング表を使う。

評価項目 重み SaaS標準（5点満点） カスタム開発（5点満点）
導入スピード 15% 5 2
初期コスト 10% 4 2
10年TCO 20% 4 3
業務適合性 20% 3 5
変更容易性 15% 5 2
セキュリティ 10% 4 3
データ主権 5% 2 5
運用容易性 5% 5 2
合計 100% 3.95 3.20

この例では、SaaS標準が優位。ただし、「業務適合性」の重みを30%に上げ、「変更容易性」を5%に下げると、カスタム開発が逆転する。つまり、重み付けは企業の戦略次第である。

7.3 中間解：コンポーザブル・アーキテクチャ

「SaaS標準 vs カスタム開発」という二元論ではなく、中間解が存在する。

  • コンポーザブル・アーキテクチャ：コア業務はSaaS標準を使い、差別化部分だけ周辺システムやマイクロサービスで補う。
  • バイモーダルIT（Gartner）：Mode 1（安定稼働重視）とMode 2（スピード重視）を分離。非差別化業務はMode 1でSaaS、差別化業務はMode 2でアジャイル開発。
  • API-firstアプローチ：SaaSをAPIで連携し、データ基盤（Data Lake、Data Warehouse）を別途構築。分析やAI活用は独自実装。
実例：ある小売業では、基幹ERPはSAP S/4HANAを標準採用し、顧客分析とレコメンデーションエンジンだけを独自開発。APIで連携し、「標準の安定性」と「独自の差別化」を両立。

7.4 実務チェックリスト

RFP（提案依頼書）作成前に、以下を確認する。

  1. 業務標準化の単位を切る：全社統一が必要な業務と、部門ごとに異なってよい業務を明確化。
  2. 差別化業務を定義：経営陣と合意形成。「この業務で競合に勝つ」を明示。
  3. データ戦略を先行決定：マスタデータ、トランザクションデータ、分析データの管理方針。
  4. 例外承認プロセスを設計：「標準から外れる要求」の承認ルールとエスカレーション基準。
  5. TCOモデルを構築：10年間のキャッシュフロー、リスク調整、オプション価値を含む。
  6. 内製能力を評価：自社にエンジニアがいるか、採用できるか、育成計画はあるか。
  7. エコシステムの必要性を評価：データ分析、AI活用、外部コンサル支援が必要か。

8. 反証と失敗パターン ── 両方の地獄を避けるために

ここで、SaaS標準化とカスタム開発、それぞれが破綻する典型パターンを示す。

8.1 SaaS標準化が破綻するパターン

  • 業務が未整理：「とりあえずSaaSを入れれば業務が改善する」と期待するが、業務プロセス自体が混沌としており、標準機能では対応できない。
  • マスタデータが汚い：顧客情報、商品情報が重複・欠損だらけで、移行に失敗。
  • 権限設計が破綻：組織構造が複雑で、SaaSの権限モデルでは表現できない。
  • 現場が受け入れない：トップダウンで導入を決めたが、現場が「使いにくい」と反発。利用率が上がらず、放置される。
  • カスタマイズ禁止が形骸化：「標準で使う」という方針が、現場の抵抗で骨抜きに。結局、大量のカスタマイズを施す。

8.2 カスタム開発が破綻するパターン

  • 仕様凍結不能：要件が次々と追加され、プロジェクトが迷走。予算超過、納期遅延。
  • ベンダー丸投げ：発注側が要件を詰めず、「SIerに任せれば何とかなる」と期待。結果、使えないシステムが納品される。
  • 運用軽視：初期開発だけに注力し、運用体制を整備しない。障害時の対応ができず、業務停止。
  • データ軽視：システム機能だけに目が行き、データ品質、データ統合、データガバナンスを軽視。分析ができない。
  • 技術選定ミス：流行の技術を採用したが、社内にスキルがなく、保守不能に。
  • エコシステムの孤立：独自システムのため、データ分析ツール、コンサルサービス、外部人材が利用できず、すべてを自前で対応する羽目に。

8.3 「結局どっちも地獄」を避ける条件

成功するプロジェクトには、以下の共通点がある。

  1. 経営層のコミット：CIOやCDOが、全社IT戦略を統制し、例外を認めない強い権限を持つ。
  2. 業務改革とセット：システム導入は手段であり、目的は業務改革。BPR（ビジネスプロセス・リエンジニアリング）を並行実施。
  3. データ戦略が先：システムより先に、データモデル、マスタ統合、品質基準を確立。
  4. 段階的導入：全社一斉ではなく、パイロット部門で検証し、学習しながら展開。
  5. 内製能力の育成：ベンダー依存を減らし、自社で改善できる体制を構築。

9. 結論 ── 条件付き結論で締める

では、「日本企業のカスタム開発志向は合理的か？」という問いに答えよう。

結論：

単純に「非合理」とは言えない。条件次第で合理的である。

ただし、多くの企業は、カスタム開発のコストとリスクを過小評価し、SaaS標準のメリット（特にエコシステム効果）を過小評価している。その結果、「本来はSaaS標準が合理的なのに、カスタム開発を選んでしまう」ケースが多発している。

9.1 SaaS標準が合理的な条件

  • 非差別化業務である
  • 業務変化の頻度が高い
  • スピードが重要（市場投入、競争対応）
  • 内製能力が限定的
  • セキュリティ・可用性をベンダーに任せられる
  • グローバル展開や標準化が必要
  • データ分析・AI活用を推進したい
  • 外部コンサル・ソリューションを活用したい
  • 業務要員の即戦力化・配置転換の柔軟性が重要

9.2 カスタム開発が合理的な条件

  • 差別化業務であり、競争優位の源泉
  • 規制・コンプライアンス上、独自実装が必須
  • データ主権・機密性が最優先
  • 要件が極めて安定しており、10年変わらない
  • 内製能力があり、保守・改善を自走できる
  • 既存資産（レガシーシステム、データ）との整合性が絶対条件
  • エコシステム（外部ツール、コンサル、人材）が不要

9.3 最も重要なこと

前提条件を明示し、定量的に評価すること。

「SaaSは高い」「カスタムは柔軟」といった印象論ではなく、10年間のTCO（現在価値に割引）、リスク調整後価値、オプション価値を算出し、経営判断として意思決定する。

そして、一度決めたら終わりではない。環境変化に応じて、定期的に見直すことが必要である。

10. 明日からできる3つの打ち手

最後に、読者が明日から実行できるアクションを3つ提示する。

打ち手1：業務の「差別化度」を経営陣と合意する

IT企画部門だけで判断せず、経営陣を巻き込んで「どの業務で競争優位を築くか」を明確化する。それ以外は、標準化の対象とする。

打ち手2：TCOモデルを構築し、感度分析を行う

本稿で示したTCO比較表を自社版にカスタマイズし、Excel等でモデル化する。ライセンス料、開発費、運用費の前提を変えたとき、どう結論が変わるかを可視化する。特に、エコシステムコスト（データ分析、コンサル、人材育成）を明示的に含める。

そして、将来費用は必ず現在価値に割引する。割引率5%で10年間であれば、年金現価係数7.72を使う。単純な合計ではなく、現在価値で比較すること。

打ち手3：「例外承認プロセス」を設計する

「標準から外れるカスタマイズ」を要求する際の承認ルールを定める。以下の項目を明示させる。

  • なぜ標準機能では不可能か（技術的理由、業務的理由）
  • 差別化にどう寄与するか（売上増、コスト減、リスク減）
  • TCO増加はいくらか（初期+10年運用+エコシステム喪失コスト、現在価値で）
  • 代替案の検討（業務側で工夫、周辺システムで対応等）

これにより、「なんとなくカスタマイズ」を排除できる。

付録：自社診断質問（10問）

以下の質問に答えることで、自社のIT投資意思決定の成熟度を診断できる。

  1. 「差別化業務」と「非差別化業務」の切り分けを、経営陣と合意しているか？
  2. システム導入の意思決定時に、10年間のTCO（現在価値）を算出しているか？
  3. TCOに、運用コスト、アップグレードコスト、人件費、機会損失、エコシステムコストを含めているか？
  4. カスタマイズ要求に対して、「なぜ標準では不可か」を説明させているか？
  5. IT投資の評価基準に、ROIだけでなく、リスク・オプション価値を含めているか？
  6. SaaSベンダーのSLA、セキュリティ対策、BCPを評価しているか？
  7. カスタム開発する場合、保守・運用体制（人員、スキル、予算）を確保しているか？
  8. 業務標準化とシステム導入を、セットで推進しているか（BPRの実施）？
  9. IT部門に、全社IT戦略を統制する権限（予算、人事、承認）があるか？
  10. 過去のシステム投資を振り返り、失敗から学ぶ仕組みがあるか？

7問以上「はい」なら、成熟した意思決定ができている。4問以下なら、改善の余地が大きい。

▼ 関連記事のご案内 ▼

日本のビジネスに関するまとめ記事です。是非ご参照ください。

>> 日本のビジネスを「歴史・宗教・制度・慣習」から読む：未来戦略の羅針盤

参考文献

  1. Brynjolfsson, E., & Hitt, L. M. (2003). Computing productivity: Firm-level evidence. Review of Economics and Statistics, 85(4), 793-808. DOI: 10.1162/003465303772815736
  2. Carr, N. G. (2003). IT doesn't matter. Harvard Business Review, 81(5), 41-49.
  3. Davenport, T. H. (1998). Putting the enterprise into the enterprise system. Harvard Business Review, 76(4), 121-131.
  4. DevOps Research and Assessment (DORA). (2023). DORA Metrics. https://dora.dev/
  5. Gartner. (2014). Bimodal IT: How to Be Digitally Agile Without Making a Mess. Gartner Research Note G00266839. (注：アクセス制限あり)
  6. Jensen, M. C., & Meckling, W. H. (1976). Theory of the firm: Managerial behavior, agency costs and ownership structure. Journal of Financial Economics, 3(4), 305-360. DOI: 10.1016/0304-405X(76)90026-X
  7. Markus, M. L., & Tanis, C. (2000). The enterprise systems experience—from adoption to success. In R. W. Zmud (Ed.), Framing the Domains of IT Research: Glimpsing the Future Through the Past (pp. 173-207). Pinnaflex Educational Resources.
  8. McAfee, A., & Brynjolfsson, E. (2008). Investing in the IT that makes a competitive difference. Harvard Business Review, 86(7/8), 98-107.
  9. 経済産業省. (2018). 『DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~』. https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
  10. Ross, J. W., & Weill, P. (2002). Six IT decisions your IT people shouldn't make. Harvard Business Review, 80(11), 84-91.
  11. Seddon, P. B., Calvert, C., & Yang, S. (2010). A multi-project model of key factors affecting organizational benefits from enterprise systems. MIS Quarterly, 34(2), 305-328. DOI: 10.2307/20721429
  12. Trigeorgis, L. (1996). Real Options: Managerial Flexibility and Strategy in Resource Allocation. MIT Press.
  13. Weill, P., & Ross, J. W. (2004). IT Governance: How Top Performers Manage IT Decision Rights for Superior Results. Harvard Business School Press.
  14. Williamson, O. E. (1979). Transaction-cost economics: The governance of contractual relations. Journal of Law and Economics, 22(2), 233-261. DOI: 10.1086/466942
  15. 情報処理推進機構 (IPA). (2022). 『ソフトウェア開発分析データ集2022』. https://www.ipa.go.jp/publish/qv6pgp0000001x7x.html
  16. 日本情報システム・ユーザー協会 (JUAS). (2022). 『企業IT動向調査報告書2022』. https://juas.or.jp/library/research_rpt/
  17. 野村総合研究所. (2019). 『ITロードマップ2020年版』. 東洋経済新報社.