ゼロから作るか、既存のパッケージを使うかの判断基準

新規事業のシステムをゼロから作るか既存のパッケージ（SaaSを含む）を使うかは、「その機能そのものが顧客に選ばれる理由になるか」でほぼ決まります。顧客価値の核になる部分だけを作り、それ以外は既存の製品で済ませるのが基本で、検証段階では「作らずに確かめる」方法を先に探すことをおすすめします。

この記事では、判断の前提となる考え方、具体的な判断軸、検証段階ごとの選び方、よくある失敗を順に整理します。特定の製品の比較ではなく、どの製品を検討するときにも使える判断の枠組みを扱います。

判断の出発点は「どこで勝つか」

競争する部分と、そうでない部分を分ける

新規事業のシステムには、大きく分けて2種類の機能があります。

顧客がその事業を選ぶ理由になる機能（独自の業務フロー、独自のデータの使い方、他社にない体験など）
どの事業にも必要だが差別化にはならない機能（会員登録、決済、請求、問い合わせ管理、社内の承認フローなど）

前者は自分で作り込む価値がありますが、後者を自前で作っても顧客から見た価値はほとんど増えません。後者は既に多くの事業者が使っている製品を採用したほうが、品質も保守もたいてい安定します。

判断の最初の作業は、作ろうとしているシステムの機能を書き出し、この2つに振り分けることです。振り分けが曖昧なまま「全部作る」「全部パッケージで」と決めると、どちらを選んでも後で苦労します。

「差別化になる」は仮説にすぎない

注意したいのは、新規事業の段階では「この機能が差別化になる」という見立て自体がまだ仮説だという点です。顧客が本当にその機能に価値を感じるかは、実際に使ってもらうまで分かりません。

そのため「差別化になるから作る」と決める前に、「その機能に顧客がお金や時間を払うかを、作らずに確かめる方法はないか」を考えます。手作業での代行、既存ツールの組み合わせ、画面のモックアップなどで確かめられるなら、まずそちらを選びます。検証の方法についてはPoC・プロトタイプ・MVPの違いと進め方で詳しく扱っています。

具体的な判断軸

機能を振り分けたら、次の軸で「作る」「使う」を比べます。1つの軸だけで決めず、複数の軸を並べて見ることが大切です。

1. 業務や体験を製品に合わせられるか

パッケージは、多くの利用者に共通する業務の流れを前提に作られています。自社の業務や顧客体験をその前提に合わせられるなら、パッケージは有力です。合わせられず、大規模な改修（カスタマイズ）が必要になるなら、パッケージを選ぶ利点は小さくなります。

目安として、パッケージに対して「変えたい点」を書き出し、それが設定の範囲で済むのか、追加開発が必要なのかを確認します。追加開発が多い場合、製品のバージョンアップのたびに改修部分の動作確認や修正が必要になり、長期的な負担が増えやすくなります。

2. 立ち上がりまでの時間

新規事業では、市場に出して反応を見るまでの時間が重要です。既存の製品なら契約と設定だけで使い始められることが多く、ゼロから作るより早く検証に入れる場合がほとんどです。一方で、製品の選定、試用、社内の審査（大企業では情報システム部門やセキュリティ部門の確認）に時間がかかることもあるため、その期間も見込んでおきます。

3. 総コスト（初期費用だけで比べない）

比較するときは、初期費用だけでなく、一定期間の総額で見ます。

自社開発: 開発費、インフラ費用、保守・改修の人件費または外注費、障害対応の体制
パッケージ・SaaS: 初期費用、利用料（利用者数や件数に応じて増えるものが多い）、設定・連携の作業費、追加オプション

SaaSの利用料は、利用者や取引件数が増えると比例して増える料金体系が少なくありません。事業が伸びたときの料金を試算しておかないと、成長するほど採算が悪くなる構造になることがあります。逆に、自社開発は規模が大きくなっても費用が比例しにくい反面、立ち上げ時の負担が重く、事業をやめたときに回収できません。

4. データを持ち出せるか

新規事業では、顧客の利用データそのものが後の意思決定や次の開発の材料になります。パッケージを選ぶ場合は、次の点を契約前に確認します。

自社のデータを、使いやすい形式でいつでも取り出せるか
他のシステムと連携する手段（APIなど）が用意されているか
解約したときのデータの扱い（返却、削除の時期）

データを取り出せない製品に事業の中心を置くと、後から自社開発に切り替えたくなっても移行が難しくなります。

5. 誰が保守するか

自社開発を選ぶ場合、作った後の保守を誰が担うかを最初に決めておく必要があります。外注で作って社内に分かる人がいない状態は、新規事業では特に危険です。仕様の変更が頻繁に起きるため、そのたびに外部に依頼していると、改善の速度も費用も読めなくなります。

パッケージを選ぶ場合も、設定を理解している担当者を社内に置く必要があります。「設定だけだから誰でもできる」と考えず、担当者と引き継ぎの方法を決めておきます。

6. 撤退しやすさ

新規事業は、途中で方向転換や撤退をすることが前提です。月額契約のSaaSは、解約すれば費用が止まる点で撤退しやすい選択肢です。ただし、年単位の契約や最低利用期間がある製品もあるため、契約期間と解約条件を確認します。自社開発は、撤退時に開発費が回収できないことを前提に、投資額を段階的に区切るのが現実的です。

検証段階ごとの考え方

同じ事業でも、段階によって適した選択は変わります。

課題・ニーズの検証段階

この段階では、原則としてシステムを作りません。表計算ソフト、フォーム作成ツール、チャットツールなど既に手元にあるものと手作業で、顧客の課題と反応を確かめます。

MVP（最小限の製品）の段階

顧客に実際に使ってもらう段階です。差別化の核になる部分だけを最小限作り、それ以外は既存の製品で補う構成が基本になります。起業家の場合は、ノーコードツールで核の部分まで作ってしまう選択肢もあります。進め方と限界はノーコードでMVPを作るときの進め方と限界にまとめています。

事業拡大の段階

顧客が増え、どの機能が選ばれる理由なのかが分かってきた段階で、核となる部分を自社開発に置き換えるかを判断します。この時点では利用データがあるため、「どこに投資すべきか」を仮説ではなく実績で判断できます。

大企業と起業家で異なる点

大企業の新規事業部門の場合

大企業では、既に全社で契約しているパッケージや、情報システム部門が認めた製品の一覧があることが多く、それ以外の製品を使うには審査が必要になります。審査に時間がかかる場合、検証の速度が落ちる原因になります。

対応としては、次のような方法があります。

検証段階に限り、扱うデータの範囲を限定して簡易な審査で使える枠を相談する
本格導入時の審査に必要な資料（データの保存場所、アクセス管理、解約時のデータ削除など）を早めに製品側から取り寄せておく
既存の基幹システムとの連携は、検証段階では手作業で代替し、本格化の判断後に設計する

また、社内の既存システムを流用すれば「作らずに済む」と考えがちですが、既存事業向けの仕組みは新規事業の業務に合わないことも多く、改修の調整に時間がかかる場合があります。流用する場合も、どこまで合わせられるかを最初に確認します。

起業家・スタートアップの場合

資金と人手が限られるため、差別化にならない機能を作る余裕はまずありません。既存の製品を最大限使い、開発者の時間は顧客が選ぶ理由になる部分に集中させます。

一方で、プロダクトそのものが事業の中心であり、投資家から技術的な優位性を問われる場合もあります。その場合は、「どの部分を自社で作り、なぜそこが優位性になるのか」を説明できるようにしておくことが、資金調達の場面でも役立ちます。

よくある失敗

パッケージを大きく改修してしまう

パッケージを選んだのに、自社のやり方に合わせるために大規模な改修を重ねると、自社開発とパッケージの悪いところを併せ持つ状態になります。改修が必要な項目が多いと分かった時点で、業務の側を変えるか、別の製品を探すか、その部分だけ自社開発するかを改めて判断します。

将来の規模を前提に作り込む

「将来、利用者が大幅に増えたときに困らないように」と、最初から大規模な構成で自社開発するのは、新規事業では多くの場合過剰です。まだ顧客がいない段階では、将来の規模に耐えることよりも、早く出して学ぶことを優先します。

「作れる人がいる」ことを理由に作る

社内や身近に開発できる人がいると、既存の製品で済むものまで作りたくなることがあります。作れるかどうかではなく、作ることで顧客価値が増えるかで判断します。

発注や契約の段階で確認すること

自社開発を外部に依頼する場合も、パッケージを導入して設定や連携を外部に依頼する場合も、契約の形と責任の範囲を明確にしておく必要があります。独立行政法人情報処理推進機構（IPA）が公開している「情報システム・モデル取引・契約書（第二版）」には、受託開発向けのほかに、パッケージ・SaaS/ASP活用や保守・運用を扱う契約書のひな型も含まれており、検討時の参考になります。

発注先の選び方はMVP開発を外注するときの発注先の選び方と見積もりの読み方で扱っています。

判断のまとめ

最後に、判断の手順を整理します。

システムの機能を書き出し、「顧客が選ぶ理由になる部分」と「それ以外」に分ける
「それ以外」は既存の製品で済ませる前提で考える
「選ぶ理由になる部分」も、まず作らずに確かめる方法を探す
作る・使うを比べるときは、業務への適合、立ち上がりの速さ、総コスト、データの持ち出し、保守体制、撤退しやすさを並べて見る
事業が伸びて実績が出た段階で、核の部分を自社開発に置き換えるかを改めて判断する

最初の選択は固定ではありません。段階ごとに見直すことを前提にしておくと、どちらを選んでも後で方向を変えやすくなります。

参考資料

情報システム・モデル取引・契約書（第二版）（独立行政法人情報処理推進機構）