机の上に、1枚の提案書があるとします。
「この業務なら、AIを使って御社専用のシステムを作れます」。そう書かれている。
決裁の期限は決まっていて、判断するのは自分です。技術的に作れるのかは分かりません。かといって「よく分からないから却下」では、機会を逃すかもしれない。
この記事は、その1件をどう判断するかの話です。
なお、こうした提案が増えた結果として社内のシステムが増えすぎる、という別の論点もあります。そちらはAIで「作れる」時代の落とし穴で扱っています。本記事は、目の前の1件について「作るか、買うか」を決めることに絞ります。
この記事は、NetSuite認定パートナー（Solution Provider）であるベンチャーネットが書いています。ERPを扱う立場ではありますが、内製を否定するつもりはありません。作ったほうがよい領域は、確かに存在します。
お伝えしたいのは、判断の軸です。
この記事で分かること
- スクラッチ開発が向いているケースと、その見分け方
- 「作る」と「買う」を分ける5つの判断軸
- 選定段階でよくある4つの判断ミス
- 二択にせず、両方を使い分けるという現実解
読了時間の目安：約13分
「AIで作れます」という提案が増えている
まず、この提案が増えている背景と、この記事の結論を先にお伝えします。
なぜ、いま増えているのか
生成AIの登場で、コードを書く作業そのものが速くなりました。
以前なら数人がかりで数か月かかっていた規模のものが、少人数で形になる。試作の段階までなら、驚くほど短期間で到達します。
その結果、これまで「予算的に無理」とされていた自社専用システムが、選択肢として浮上してきました。
これは、間違いなく前向きな変化です。選べる幅が広がったこと自体は、歓迎すべきことです。
問題は、選び方の物差しが追いついていないことにあります。
結論：二択で決めないほうがよい
先に結論をお伝えします。
「全部を作る」か「全部を買う」かの二択にすると、判断を誤りやすくなります。
現実的な解は、領域ごとに分けることです。
- 基幹業務（会計・販売・在庫・購買）：パッケージERPを使う
- 自社の競争力の源泉になっている業務：作ることを検討する
なぜこの分け方になるのか。その理由が、これから説明する5つの判断軸です。
ERPとは、Enterprise Resource Planningの略で、会計・販売・在庫といった基幹業務を一つの仕組みで統合管理する考え方を指します。
先に言っておきたい：スクラッチが向いているケース
判断軸の話に入る前に、作ったほうがよいケースを先に整理します。
ERPを扱う立場からこう書くのは奇妙に見えるかもしれません。ですが、ここを曖昧にしたまま判断軸だけ並べても、公平な材料にはなりません。
その業務が、自社の競争力そのものである場合
他社と違うやり方をしているから勝てている。そういう業務があるはずです。
独自の配車ロジック、独自の見積もり算定、独自の品質判定。
こうした領域を標準的な仕組みに合わせると、強みを手放すことになります。作る価値が最も高いのは、ここです。
パッケージが存在しない領域である場合
業界が特殊で、そもそも該当する製品が市場にない。
このケースでは、探し続けるより作るほうが早いことがあります。
影響範囲が小さく、業務として閉じている場合
一部門だけで完結し、他の業務とデータをやり取りしない。
こうした小さな業務なら、作って動かし、合わなければ捨てるという進め方が成立します。生成AIの恩恵が最も出やすいのも、この規模です。
作った後を担える体制が、社内にある場合
これが最も重要な条件です。
作ることと、動かし続けることは別の仕事です。後者を担える人と予算が社内にあるなら、作る選択は現実的になります。
該当するなら、作ることをお勧めします
以上のいずれかに当てはまるなら、ベンチャーネットは「作ってみてはいかがでしょうか」とお伝えします。
ERPを勧めることが仕事だとは考えていません。お客様が遠回りしないことのほうが大事だからです。
そのうえで、次の章の判断軸を見てください。当てはまらなかった場合に、何を考えるべきかの話です。
「作る」と「買う」を分ける5つの判断軸
ここからが本題です。5つの軸で見ていきます。
いずれも技術の話ではありません。すべて、経営として判断できる論点です。
軸①：初期コストの見え方 ── 安いのは「作り始め」だけ
何を見る軸か
最初の見積もりだけでなく、どこまでが見積もりに入っているかを見る軸です。
スクラッチ開発の提案は、初期費用が安く見えることが多くあります。
なぜ安く見えるのか
見積もりの範囲が「動くものを作るまで」に限られているためです。
そこには、テスト環境の維持、障害対応、機能追加、担当者の引き継ぎといった費用が入っていません。
パッケージの利用料には、これらの多くが最初から含まれています。だから額面が大きく見えます。
判断のポイント
比べるべきは、初期費用ではなく5年分の総額です。
この考え方をTCO（Total Cost of Ownership：総保有コスト）と呼びます。何をTCOに含めるべきかは、NetSuiteのライセンスは高い？で整理しています。
金額の相場感を知りたい方は、クラウドERPの費用・料金相場をご覧ください。
軸②：5年後の保守責任 ── 誰が直し続けるのか
何を見る軸か
システムが動かなくなったとき、誰が責任を持って直すのかを見る軸です。
なぜ重要か
基幹システムは、止まると業務が止まります。受注も出荷も請求も止まります。
パッケージの場合、直す責任はベンダーとパートナーにあります。契約として明確です。
作った場合、責任は自社にあります。開発を委託していても、その会社が5年後も同じ体制で対応できるとは限りません。
判断のポイント
「誰が直すのか」を、契約書のレベルで確認してください。
口頭の「もちろん対応します」は、担当者が変われば消えます。
軸③：法改正への追随 ── 変更は必ずやってくる
何を見る軸か
制度が変わったとき、誰がどのくらいの費用で対応するかを見る軸です。
なぜ重要か
会計や税務に関わる制度は、数年ごとに変わります。
インボイス制度も電子帳簿保存法も、施行のたびにシステム側の改修が必要になりました。今後も同じことは起こります。
パッケージの場合、多くが標準のアップデートで対応されます。追加の費用が発生しないケースが一般的です。
作った場合、そのたびに改修の見積もりを取り、予算を確保し、テストをすることになります。
判断のポイント
法改正は「起きるかもしれないリスク」ではなく、「必ず起きる定期費用」です。
計算から外さないでください。ここを外すと、比較そのものが成り立ちません。
軸④：AI機能の進化への追随 ── 止まっているものは古くなる
何を見る軸か
新しい技術が出たとき、自社のシステムがそれに追いつけるかを見る軸です。
なぜ重要か
AIをめぐる状況は、いま非常に速く動いています。
パッケージERPの側では、AI機能の実装が継続的に進んでいます。NetSuiteも「#1 AI Cloud ERP」を掲げ、年2回の自動アップデートで機能が追加されていきます。
一方、作ったシステムは、作った時点の設計のまま止まります。新しい機能を取り込むには、そのつど開発が必要です。
いま最新の技術で作ったとしても、2年後には自分で追いかけることになります。
判断のポイント
その領域の技術が、今後も速く変わり続けるかを考えてください。
変化が速い領域ほど、追随してくれる側に乗るほうが有利です。逆に、技術がほぼ枯れている領域なら、作っても陳腐化しにくくなります。
なお、ERPに組み込まれたAIと、外部のAIをつなぐ仕組みの違いは、NetSuiteの純正AIと外部AI連携の違いで解説しています。
軸⑤：属人化 ── 作った人がいなくなった後
何を見る軸か
作った本人が抜けたとき、そのシステムを扱える人が残るかを見る軸です。
なぜ重要か
AIを使って作ったシステムでも、設計の意図までは残りません。
「なぜこの処理がこうなっているのか」を説明できるのは、作った本人だけです。その人が退職や異動でいなくなると、誰も触れないシステムが残ります。
これは、ブラックボックスの再生産です。
パッケージの場合、扱える人は市場にいます。ドキュメントも公式に整備されています。
判断のポイント
「作れる人が社内にいる」ではなく、「その人が抜けても続けられるか」で判断してください。
属人化がなぜ経営リスクになるのかは、キーマンリスクとBCPで詳しく扱っています。
比較表：作る場合と買う場合
5つの軸を一覧にまとめます。
| 判断軸 | スクラッチ開発（AI活用） | パッケージERP |
|---|---|---|
| ① 初期コストの見え方 | 安く見えやすい。見積もり範囲は「作るまで」が中心 | 高く見えやすい。運用・保守が最初から含まれる |
| ② 5年後の保守責任 | 自社に残る。委託先の体制継続は保証されない | 契約で明確。ベンダーとパートナーが担う |
| ③ 法改正への追随 | 都度、改修の見積もり・予算・テストが必要 | 多くが標準アップデートで対応 |
| ④ AI機能の進化 | 作った時点で止まる。取り込みには開発が必要 | 定期アップデートで継続的に追加される |
| ⑤ 属人化 | 設計意図が個人に残りやすい | 扱える人が市場にいる。公式文書がある |
どちらが向いているか
| 状況 | 向いている選択 |
|---|---|
| その業務が自社の競争力そのもの | スクラッチ開発 |
| 該当するパッケージが市場にない | スクラッチ開発 |
| 一部門で完結し、影響範囲が小さい | スクラッチ開発 |
| 作った後を担う体制が社内にある | スクラッチ開発 |
| 会計・販売・在庫などの基幹業務 | パッケージERP |
| 制度変更の影響を受ける業務 | パッケージERP |
| IT担当者が少ない、または不在 | パッケージERP |
| 5年以上使い続ける前提がある | パッケージERP |
表を見ると、分かれ目がはっきりします。
「差別化したい業務か、止まってはいけない業務か」。これが、実質的な分岐点です。
「両方使う」という現実解
多くの会社にとって、現実的な答えは中間にあります。
基幹は買い、差別化領域は作る
基幹業務は、他社と違うやり方をしても競争力になりません。
会計の処理が独特であることに、経営上の意味はほとんどありません。ここはパッケージに任せ、標準に合わせるほうが得です。
一方、自社の勝ち筋に直結する業務は、標準に合わせると強みが薄れます。ここは作る価値があります。
境界線の引き方
分け方に迷ったときは、次の問いを使ってください。
「この業務のやり方が他社と同じになったら、自社は困るか」
困るなら、差別化領域です。困らないなら、基幹領域として標準に寄せて構いません。
つなぐことを前提に設計する
両方を使う場合、データをどうつなぐかが論点になります。
つなぎ方を後から考えると、たいてい苦労します。作る側の設計に、最初から連携の口を用意しておくことが大切です。
選定段階でよくある4つの判断ミス
ここからは、実際に判断を進めるときのつまずきを整理します。
これは、判断を誤った会社を批判するためのものではありません。どれも、条件がそろえば誰でも踏む種類のものです。だから、先にお伝えしておきたいのです。
ミス①：「作れる」と「持ち続けられる」を同じことだと考える
よくある現象
- 試作がうまく動いたことで、導入が決定してしまう
- 「もう動いているのだから大丈夫」という空気になる
- 運用フェーズの予算が計上されていない
なぜ失敗するか
作ることと、動かし続けることは別の仕事です。
試作は、条件が整った状態で動けば成功と見なされます。しかし本番の業務では、例外処理も、繁忙期の負荷も、担当者の交代も起こります。
生成AIが速くしたのは前者です。後者の負担は変わっていません。
どう回避するか
判断の場では、必ず「5年後、これを誰が動かしているか」を口に出してください。
答えられないなら、その計画はまだ完成していません。
なお、1件ずつの判断は正しくても、積み重なると社内のシステムが増えすぎるという別の問題が起きます。その構造はAIで「作れる」時代の落とし穴で整理しています。本記事では、あくまでこの1件の判断に絞ってお伝えします。
ミス②：比較の期間が、双方で揃っていない
よくある現象
- 作る側は初期費用で語られ、買う側は5年分で語られる
- 「作れば一度きり、買えば毎年かかる」という説明を受ける
- 比較表の期間の前提が、そもそも書かれていない
なぜ失敗するか
期間が揃っていない比較は、比較になりません。
作る側にも、保守・改修・人件費が毎年かかります。それを含めずに初期費用だけを並べれば、当然そちらが安く見えます。
どう回避するか
期間を揃えてください。5年、できれば7年で比べます。
そして両方に、同じ費目を入れます。開発費、運用人件費、改修費、教育費。片方だけに入れないことが重要です。
ミス③：変更コストを「起きないもの」として外す
よくある現象
- 法改正対応の費用が、見積もりに含まれていない
- 「その時になったら考えます」で判断が進む
- 業務変更や組織変更の影響が計算に入っていない
なぜ失敗するか
制度も業務も、5年間まったく変わらないということはありません。
変更が起きる前提で計算していないと、後から想定外の支出が積み上がります。そして、その支出には稟議のたびに時間がかかります。
どう回避するか
過去5年間で、自社のシステムに何回の改修が発生したかを数えてください。
その回数が、これからの5年でも起きます。それを見積もりに入れれば、比較の精度は一気に上がります。
ミス④：二択で決めて、使い分けを検討しない
よくある現象
- 会議の議題が「作るか、買うか」の一択になっている
- 全社一括で方針を決めようとする
- 領域ごとに分ける案が、そもそも検討されていない
なぜ失敗するか
業務によって最適解が違うのに、一つの答えを全体に当てはめているためです。
その結果、基幹業務まで独自に作ってしまうか、差別化領域まで標準に合わせてしまうか、どちらかの無理が生じます。
どう回避するか
議題を「どこを作り、どこを買うか」に変えてください。
問いの立て方を変えるだけで、出てくる答えが変わります。
四つに共通するもの
四つを並べると、共通点が見えてきます。
いずれも、判断の時間軸が短いことから生じています。作り始める瞬間だけを見ると、判断を誤りやすくなるのです。
ベンチャーネットは、お客様と対等な関係で仕事をしたいと考えています。だから、都合のよい比較だけをお見せするつもりはありません。
作るべき領域があるなら、そう申し上げます。判断材料をそろえるところから、ご一緒させてください。
自社はどちらから考えるべきか
判断の入り口を整理します。次のうち、いくつ当てはまるかを見てください。
パッケージERPから検討したほうがよい状態
- 会計・販売・在庫の基幹業務が対象になっている
- 部門ごとにシステムが分かれ、数字の突合に時間がかかっている
- IT担当者が少ない、または専任者がいない
- 制度変更の対応に、毎回まとまった費用がかかっている
- 5年以上、同じ仕組みを使い続ける前提がある
3つ以上当てはまるなら、まずパッケージを軸に検討することをお勧めします。
製品ごとの違いは、ERPを徹底比較で整理しています。
スクラッチ開発から検討したほうがよい状態
- 対象業務が、自社の競争力に直結している
- 市場に該当する製品が見つからない
- 影響範囲が一部門で閉じている
- 開発と運用を担える体制が、社内にある
こちらに当てはまるなら、作る方向で構いません。ベンチャーネットに相談する必要もありません。
どちらとも言えない場合
多くの会社が、ここに入ります。
その場合は、業務を分解してから判断してください。「自社のシステム」とひとくくりにすると、答えが出ません。
受注、在庫、請求、原価。単位を小さくすれば、それぞれについて判断できます。
よくある質問
Q1. AIで作れるなら、そのほうが安いのではありませんか
作り始めるまでは、安く済むことが多いと思います。
論点は、その後です。動かし続ける費用、変更に対応する費用、人が抜けたときの費用。これらを5年分足したときに、順位が入れ替わることがあります。
安いか高いかではなく、どの期間で比べているかを確認してください。
Q2. 内製はダメということですか
いいえ、違います。
自社の競争力の源泉になっている業務は、作る価値があります。標準に合わせると強みが薄れる領域だからです。
お伝えしたいのは、業務によって答えが違うということです。全部を作るか全部を買うかの二択にしないでください。
Q3. すでにスクラッチで作ってしまった場合はどうすればよいですか
すぐ捨てる必要はありません。
まず、その仕組みが今後5年間、誰の責任でどう維持されるかを確認してください。答えが出るなら、そのまま使い続けて問題ありません。
答えが出ない場合は、基幹部分から段階的に移すことを検討します。全部を一度に入れ替える必要はありません。
Q4. パッケージだと、自社のやり方に合わないのではありませんか
基幹業務については、合わせにいく価値があります。
会計や在庫の処理が他社と違うことに、経営上の意味はほとんどありません。むしろ標準に寄せることで、人の採用も引き継ぎも楽になります。
合わせられない業務が本当にあるなら、それは差別化領域かもしれません。その場合は作る候補になります。
Q5. 判断を急がされています。何から確認すべきですか
三つだけ確認してください。
- 比較の期間は、両方とも5年で揃っているか
- 法改正や業務変更の対応費用が、両方に入っているか
- 5年後に誰が保守するかが、契約として書かれているか
この三つが揃っていない比較表は、判断材料としては不十分です。時間がないときほど、ここだけは確認する価値があります。
導入そのものでつまずく典型的な原因は、ERP導入はなぜ失敗するのかで整理しています。
まとめ：決めるべきは「作るか買うか」ではない
ここまで、5つの判断軸と4つの判断ミスを見てきました。
最後に、いちばんお伝えしたいことを書きます。
この判断で決めているのは、技術の選択ではありません。
決めているのは、この仕組みに誰が責任を持ち続けるかです。
作れば、責任は自社に残ります。買えば、責任の一部を契約として外部と分け合います。
どちらが正しいということはありません。自社の体制と、その業務の性質によって答えが変わります。
だからこそ、この判断は情報システムの案件ではなく、経営の案件です。ERPの導入も同じで、ITプロジェクトではなく経営プロジェクトとして扱うほうがうまくいきます。
もし「作れます」という提案を受けて迷っているなら、まず業務を分解してみてください。
どこが差別化領域で、どこが止まってはいけない領域か。その線を引くところから始めれば、判断はずいぶん楽になります。
その線引きを一緒に考えるところから、ご相談いただければと思います。作るべきだと判断したときには、そのようにお伝えします。
もう少し詳しく知りたい方へ
- 実際の画面を見ながら相談したい方へ：NetSuiteの無料デモ・個別相談
- AIとERPの組み合わせを知りたい方へ：AIクラウドERP NetSuite
- 自社の状況を整理するところから相談したい方へ：お問い合わせ
関連記事
