SaaS購買デシジョンツリー：購入・内製・既存ツール活用の選び方

重要データ：中堅企業のSaaS購買決定

SaaS評価の平均期間： 年間$25K以上の契約では、最初のデモから契約締結まで平均84日（Gartner、2025年 B2B購買ベンチマーク）。

1件あたりのベンダー候補リスト： 中堅企業の取引では通常3〜5社、エンタープライズ取引では平均6〜8社（Forrester SaaS購買調査）。

1件あたりの意思決定者数： 中堅B2Bソフトウェア購買の平均は6.8人で、2020年の5.4人から増加（Gartner B2B購買ジャーニー調査）。

体系的な判断と場当たり的な判断の差： 文書化されたデシジョンフレームワークを使ったチームは、フレームワーク手順を省略したチームと比べ、購入後1年のツール導入率が2.3倍高いと報告されている（McKinseyソフトウェア購買研究）。

中堅企業でのツール重複： SaaSツールの30〜40%は、スタック内の他のツールと機能が重複している（Productiv State of SaaS）。

COOには課題がありました。正確には、三つの課題です。一つの四半期の間に、三つの異なるチームがそれぞれ「とにかく何か早く必要だ」というリクエストを経営陣に持ち込みました。三つとも承認され、三つとも購入されました。そして四ヶ月後、ITリードがスタックを整理したとき、そのうち二つのツールは互いに大きな機能重複があり、一つは18ヶ月前にライセンスを取得済みのプラットフォームの機能と重複していることが判明しました。

誰も間違いを犯したわけではありません。各チームには本物のニーズがあり、本物の解決策を見つけていました。しかし誰も「そもそも何かを購入すべきか？」という先行する問いを立てていなかったのです。

「購入・内製・既存ツール活用」という問いは明白に聞こえます。しかし実際にはそうではありません。ほとんどの企業がこの問いを完全に省略します。ベンダーとの商談が始まる前に作業が必要で、その商談の方が楽だからです。デモはすでに予定されています。試用はすでに始まっています。デシジョンフレームワークが適用される前に購買の決断が下されてしまいます。

このガイドでは、そのフレームワークを紹介します。50〜500名規模の企業向けに設計されており、正式な調達プロセスが過剰に感じられるほど速くSaaS意思決定を行う一方で、ツールの乱立が予算と生産性に実質的な影響を与えるほど規模が大きい企業を想定しています。

なぜデフォルトの答えは常に「購入」なのか

SaaS市場は、最小抵抗経路が購入に向くよう設計されています。無料試用が摩擦を除去し、Product-Led Growth（PLG）によってツールが調達部門の関知しないまま組織内に広がります。Gartnerのソフトウェア購買行動に関する調査によれば、エンドユーザーが60%以上のソフトウェア購買を主導しており、ITや調達を完全に迂回するケースも多いとされています。2025〜2026年のAIベンダーピッチはさらに新たな複雑さをもたらしています。あらゆる機能がプラットフォームのように見え、すべてのプラットフォームが既存の三つのツールを置き換えると約束するのです。ベンダーを評価する前に、SaaS RFPを無駄な6週間にしない方法を理解しておくと役立ちます。RFPプロセスは購入を決断した後の話だからです。

デフォルトの答えが「購入」なのは、それが最も弁護しやすい答えだからです。デモを見せられます。事例を示せます。2週間でチームが成果を出せます。内製には数ヶ月かかり、既存ツールの活用には、そのツールが実際に何ができるかを理解している人材が必要です。

しかし、常に「購入」をデフォルトにするコストは積み重なります。ツール数が増え、契約が自動更新され、シート数が肥大化します。McKinseyのソフトウェア支出に関する調査によれば、組織はライセンス費用しかモデル化しない場合、ソフトウェアの総コストを30〜50%過小評価する傾向があります。そして最終的にCFOは、前年比40%増でありながら何を購入したのかまったく説明できないSaaS費用の明細を見ることになります。このステップを省略した結果生じるリスクは、急成長した中堅企業のほぼすべてに見られるSaaS乱立問題に明確に現れています。

デシジョンフレームワークは出発点を「どのベンダーにするか？」から「そもそも購入すべきか？」に変えます。

4分岐のデシジョンツリー

購入・内製・既存活用のデシジョンツリー

購入・内製・既存活用のデシジョンツリーは、ベンダーとの商談が始まる前に構造化された問いを強制する三分岐のフレームワークです。内製（機能が競争優位の中核である場合に社内でエンジニアリング）、購入（機能が非中核でベンダー市場が成熟している場合に専用SaaSツールをライセンス）、既存活用（既存スタックのカバレッジが70%以上の場合にすでに所有している機能を拡張）のいずれかを判断します。ツリーは順番に実行します。中核か非中核かを最初に判断し、次にビルドコスト、次に既存スタックの棚卸し、次にベンダー市場の成熟度、という順序で進め、明確な答えが出た最初の分岐で停止します。

以下がフレームワークです。各分岐を順番に確認してください。明確な答えが出た最初の分岐で停止します。

分岐1：これは中核機能か非中核機能か？

中核機能とは、事業を差別化するか、直接収益を生み出すものです。非中核機能はサポート業務、つまりすべての企業が必要とするが競争優位の源泉にはならないものです。Harvard Business Reviewのmake-or-buyフレームワークは、この区別を戦略的コントロールの観点から捉えています。コモディティは外部に委託し、自社固有のものは内製するという考え方です。

多くの中堅企業では、以下のように分類されます。

中核： どのように販売するか、どのように提供するか、どのように顧客を維持するか、製品がどのように機能するか。

非中核： 経費管理、スケジューリング、ファイルストレージ、HR管理、ITチケット管理。

ニーズが真に中核であれば、内製という選択肢を真剣に検討する価値があります。内製が常に優れているからではなく、差別化要素を外部に委託することには、ステッカー価格には反映されない戦略的リスクが伴うからです。

ニーズが非中核であれば、内製しないでください。分岐2に進みます。

分岐2：内製コストの実態は？

多くの企業は内製オプションを却下する前に実際のコスト見積もりを行いません。見積もりは「エンジニアを採用しなければならない」という結論で終わり、話が進みます。非中核機能のほとんどにはその答えが正しいのですが、中核機能については実際の数字を出す価値があります。

基本的な内製コストワークシートは以下の通りです。

コストカテゴリ	見積もり方法
初期開発	エンジニアリング工数 x 時間単価
継続的メンテナンス	初期ビルドの年間15〜20%
セキュリティとコンプライアンス	OWASPコンプライアンス、ペネトレーションテスト、継続的なパッチ適用
ホスティングとインフラ	目標スケールでのクラウドコスト見積もり
ドキュメントとトレーニング	多くの場合、開発時間の20〜30%
機会コスト	このチームが代わりに何を構築できるか？

最後の行は、企業が最も過小評価するものです。エンジニアが内部ワークフローツールを構築する代わりに製品機能を構築できるとしたら、内製の真のコストには生み出せなかった収益が含まれます。

内製コストが3年間のSaaS代替案よりも大幅に高くなった場合（非中核機能では通常そうなります）、分岐3に進みます。SaaSのTCOモデリングフレームワークでは、単純なライセンス比較では見落とされる実装・統合・移行コストを含む5カテゴリのコストモデルを詳しく説明しています。

分岐3：既存ツールでこれができるか？

新しいものを購入する前に、すでに所有しているものを棚卸ししましょう。これはほとんどの企業が省略するステップです。既存ツールに実際にログインして、何ができるかを理解する必要があるからです。

確認すべき問い：

現在のプラットフォームにネイティブまたは設定でこの機能があるか？
現在のプラットフォームのロードマップにこの機能が含まれているか（90日以内）？
二つの既存ツール間の統合や自動化でこのニーズを満たせるか？
この機能を持つ現在のツールに未使用のシートはあるか？

この棚卸しには、6週間ではなく1〜2日かかります。完璧な一致ではなく、十分に近い既存機能を探します。

以下の統合複雑度スコアカードは、既存ツールへの追加が本当にシンプルかどうか、それとも別の種類の作業を生み出すだけかどうかを評価するのに役立ちます。

要素	複雑度低	複雑度中	複雑度高
データモデルの整合性	同じオブジェクト、同じフィールド	異なるオブジェクトだが、きれいなマッピング可能	異なるオブジェクト、カスタムマッピングが必要
API利用可否	ネイティブ統合が存在	REST APIあり、ネイティブ統合なし	WebhookのみまたはAPIなし
メンテナンスの負担	設定後放置可能	月次レビューが必要	継続的なエンジニアリングが必要
ユーザーワークフローの変更	同じワークフロー、ボタンが追加されるだけ	入口が異なるが結果は同じ	新しいワークフローが必要

2カテゴリ以上が「複雑度高」であれば、追加よりも専用ツールを購入した方が実質的にコストが低い可能性があります。

既存スタックに真に「十分に近い」機能があれば、それを拡張します。なければ、分岐4に進みます。

分岐4：ベンダー市場は成熟しているか？

ベンダー市場の成熟度は長期的リスクを決定するため重要です。ForresterのSaaS市場分析は、5年以上の実績を持つカテゴリリーダーとまだ製品市場適合サイクルにある新興競合を区別しており、この区別は契約コミットメントの規模を決める際に直接影響します。成熟した市場での購入では以下が保証されます。

5年以上の実績を持つ複数の確立されたベンダー
明確な機能差別化（マーケティング上の差別化だけでなく）
自社の業界・規模での参照顧客
既知の交渉ポイントを持つ標準的な契約条件

AIの波が続く現在の未成熟な市場でのSaaS購入とは次を意味します。

ベンダーはシードまたはシリーズA資金調達で創業12〜18ヶ月
製品ロードマップは広大だが、本番環境での機能は限定的
価格設定は実験的で変動する
参照顧客は厳選されたアーリーアダプター

新興ベンダーから購入してはいけないということではありません。市場の成熟度に合わせてコミットメントを調整すべきということです。年間$500のPilotと自動更新2年間の年間$50K契約とでは、リスクが異なります。

判断ルール： 市場が成熟していれば、標準的なデューデリジェンスで購入します。未成熟であれば、限定的なコミットメント（複数年ではなく1年、全面展開ではなくPilot範囲）で購入し、再評価トリガーを契約に組み込みます。AIネイティブツールについては、AI機能を持つSaaSの評価ガイドが複数年契約を締結する前にマーケティング上の主張から真の機能を切り分けるのに役立ちます。

各分岐でよくある落とし穴

既存シートと重複するポイントソリューション

最も一般的で高コストな間違いです。チームが、既存のプロジェクト管理ツールの設定が気に入らないという理由で別のプロジェクト管理ツールを購入します。解決策は新しいツールではなく、より良い設定に関する会話か既存ツールのトレーニングです。

新規購入を承認する前に、申請者に対して既存ツールがすでにニーズの70%以上をカバーしているかどうかを文書化することを義務づけてください。

$200/月で購入できるものを内製する

エンジニアリング時間は高コストです。シニアエンジニアのコストは時間あたり$150〜200です。$200/月のSaaSツールが存在する場合、内製オプションが採算に合うには、SaaSツールよりも少なくとも年間$7,200の価値を提供する必要があります（最初の30時間の開発費用を回収するだけで）。それが実現することはほとんどありません。

例外：既存のSaaSソリューションがデータプライバシー、コンプライアンス、またはセキュリティ上の問題を引き起こし、内部ツールがそれを回避できる場合。その場合は計算が変わります。

データサイロを生み出す既存ツール活用

既存ツールに追加するのは低摩擦に見えます。しかし実際には、その統合が3つのシステムにまたがり1人しか理解していないデータフローを生み出すことに気づきます。その人が退職すると、統合が壊れ、誰も理由を知りません。

既存ツール活用を承認する前に、データフローを文書化し、オーナーを割り当て、ドキュメントだけで統合を再構築できることを確認してください。

決定を機能させるために

デシジョンフレームワークはデモのカレンダーが埋まる前に適用されて初めて機能します。実際に適用するための方法：

ベンダー評価を開始する前に1ページの要件概要書を義務づける。 その要件概要書には「どの問題を解決するか」「デシジョンツリーのどの分岐を確認したか」「なぜ「購入」に至ったか」を答えます。
分岐3には毎回ITリードまたは指定のSaaSオーナーを参加させる。 彼らはスタックを知っています。申請者は必ずしも知りません。
年間$10K以上の購入にはレビュートリガーを設定する。 1年後に誰かがツールが使われているか、他のツールと重複していないか、元のニーズがまだ存在するかを確認します。
廃止されたツールを成功指標として追跡する。 新規ツール取得だけを測定しているなら、問題の半分しか測定していません。

フレームワークが機能しているかの測定

デシジョンフレームワークが機能していることは以下で確認できます。

年次スタック棚卸しでツール重複が減少している
ソフトウェア購入の意思決定時間が短縮している（フレームワークが堂々巡りを減らすため）
廃止または統合されたツールから回収された予算が年次レビューの明細に現れている
ツールの混乱や重複ツールによる摩擦に関するITチケットが減少している

目標はソフトウェア意思決定を遅らせることではありません。4ヶ月の後処理を防ぐための20分間の構造化された思考を前もって行うことです。

Reworkがデシジョンツリーをどのようにサポートするか

このフレームワークが機能するのは、1ページの要件概要書、分岐3のスタック棚卸し、ITリードのサインオフがベンダーのデモより前に完了した場合のみです。これが多くの中堅チームの崩壊ポイントです。Rework Work Ops（$6/ユーザー/月〜）では、SaaSオーナーが各デシジョンツリーの実行内容（問題の説明、どの分岐が答えを出したか、既存ツール棚卸し結果、承認者）を一箇所に文書化し、Slackでの追いかけなしに適切なステークホルダーに回せます。

Work Opsのテンプレートを使えば1ページの要件概要書を標準化でき、すべての新規ツールリクエストが同じ構造に従います。ワークフロールーティングは分岐3のレビューをITリードまたは指定SaaSオーナーに直接送り、サインオフするまでハードストップがかかります。Work OpsはRework CRM/Sales Ops（$12/ユーザー/月〜）と連携しているため、収益チームに影響する商用ツールの決定も、オペレーションツールと同じ構造化されたレビューを受けられます。年間$10K以上の購入に対する12ヶ月のレビュートリガーは、元の決定記録に紐づいた定期タスクとしてスケジュールできるため、誰かが使用状況を確認しない限り何も自動更新されません。

SaaS購買デシジョンツリーについてよくある質問

中堅企業はいつSaaSの代わりに内製を選ぶべきですか？

機能が真に中核である場合、つまり製品を差別化し、収益に直接貢献し、競合他社が複製できない独自データを生み出す場合に内製を選択します。非中核機能（HR管理、経費精算、スケジューリング、ファイルストレージ）は、3年間のTCO比較で購入に勝てることはほとんどありません。本当のテスト：この機能をベンダーに外部委託した場合、競争上のポジションが弱まるか？「ノー」なら内製しないでください。

既存ツールが問題を解決しているかどうかをどうすれば知れますか？

新規購入を承認する前に1〜2日の棚卸しを実施します。現在のプラットフォームがネイティブ、設定経由、90日のロードマップアイテム、または所有ツール間の統合でニーズをカバーしているか確認します。閾値は70%のカバレッジ、つまり「完璧な一致」ではなく「十分に近い」を探します。デモをスケジュールする前に、申請者が棚卸し結果を1ページの要件概要書に文書化することを義務づけましょう。

SaaS購買の決定には誰が関わるべきですか？

Gartnerのデータによれば、中堅B2Bソフトウェア取引では平均6.8人の意思決定者が関与します。不可欠なロール：申請チームリード（問題のオーナー）、ITリードまたは指定SaaSオーナー（分岐3、既存スタック棚卸しのオーナー）、財務（TCOと更新追跡のオーナー）、年間$25K以上の購入では経営幹部のスポンサー。個人情報または顧客データを扱うツールにはセキュリティとリーガルのレビューが付きます。

SaaS意思決定における最大の間違いは何ですか？

分岐3（既存スタック棚卸し）をスキップすることです。デモがすでに予定されているため、チームは「購入」をデフォルト選択します。誰も既存ツールがすでにニーズをカバーしているかどうかを確認しません。Productivの調査では、中堅企業のSaaSツールの30〜40%がスタックにある他のツールと機能が重複しています。解決策は厳格な手続きルールです。すべての新規SaaS購入は、ITリードが署名した現在のスタックの文書化された棚卸しなしには承認されないこととします。

「既存活用」（スタックにすでにあるものを使う）が「購入」より良いのはどんな場合ですか？

既存ツールがニーズの70%以上をカバーし、統合や追加が複雑度スコアカード（データモデルの整合性、API利用可否、メンテナンス負担、ワークフロー変更）で低〜中スコアであり、データフローを文書化できるオーナーがいる場合は既存活用を選びます。追加がデータサイロを生み出し1人しか理解していない場合、つまりその人が去ると統合が壊れ誰も理由を知らない場合は、購入より既存活用の方が悪い選択です。

SaaS意思決定にはどれくらい時間がかかるべきですか？

年間$10K未満の取引なら2〜3週間が妥当です（デシジョンツリー要件概要書、分岐3棚卸し、1〜2回のベンダーデモ、参照確認、契約レビュー）。年間$10K〜$50Kの取引なら4〜6週間。年間$50K以上または複数年契約では、正式なRFPとセキュリティレビューを含む8〜12週間。Gartnerの84日というベンチマークは$25K/年以上の取引の平均です。それよりかなり長くかかっている場合、ツール自体よりも堂々巡りのコストの方が高くなっています。

オペレーター向けSaaS購買フレームワーク