生産管理システムのスクラッチ開発2026｜分かれ目は機能でなく改造頻度

会議室のスクリーンには、パッケージ3製品の機能比較表が映っています。丸とバツと三角が並び、丸の数が一番多い製品に印がついている。ここまでは2週間で終わりました。それでも決まらないのは、現場側が「うちの検査記録はこれでは回らない」と言い続けているからです。生産管理システムのスクラッチ開発とパッケージ導入のどちらを選ぶかは、この比較表の上では決着しません。決めるのは機能の丸バツではなく、稼働してからの5年間に業務ルールが年何人月ぶん変わるか、という一点です。

生産管理システムのスクラッチ開発を選ぶ基準は、機能一覧ではない

機能比較表が答えを出せない理由は単純です。あの表は「今の業務」に対して丸バツをつけたものだからです。システムが本当に評価されるのは稼働した後、業務のほうが変わり始めてからです。

工場の業務ルールは止まりません。新しい客先が入れば帳票が増えます。客先監査が入れば記録項目が増えます。ラインを1本足せば工程マスタの構造が変わります。法令が変われば保管年限が変わります。こうした変更が、稼働後に毎年、決まった量だけ発生します。

パッケージとスクラッチの本当の違いは、この「毎年発生する変更」をどれだけの手数で吸収できるか、そしてその手数にいくら払うかです。機能が足りているかどうかは初日の問題で、変更を吸収できるかどうかは残り5年間の問題です。金額として大きいのは後者です。

「機能は足りている」が3年後に崩れる理由

導入時点でパッケージの標準機能が業務の9割をカバーしていたとします。残り1割を軽い設定と少量の改造で埋めて、無事に稼働しました。ここまでは成功です。

問題は3年目に起きます。この3年間で追加された業務ルールは、当然ながらパッケージの設計思想を考慮せずに発生します。客先が要求する検査記録の粒度も、本社が求める原価の按分ロジックも、パッケージの想定を知らずに決まります。それを載せようとすると、標準機能の裏側に手を入れることになります。

一度裏側に手を入れると、次のバージョンアップで同じ場所を作り直す作業が発生します。作り直した箇所には、また新しい要求が乗ります。この積み上がりが3年から5年かけて進み、気づいたときには「パッケージを使っているのに、パッケージのメリットが1つも残っていない」状態になります。

Panorama Consulting Groupの2026年ERPレポートを引くGodlanの集計は、この構造の帰結を数字で示しています。2025年9月から2026年1月にかけて2,400件超の実装を分析した結果、ディスクリート製造業のERPプロジェクトの73%が目標未達で、業界平均の68%を上回っています。平均のコスト超過は215%（業界平均189%）、期間超過は30%（業界平均25%）、目標達成率は27%です。製造業は他業種より失敗しやすい、というのがこの数字の読み方です。

そして同じ集計は、対処法も示しています。重改造よりも「製品の設計思想の枠内での中程度の適合」のほうが結果が良く、45%の企業がその方法で最良の結果を得ています。つまり、パッケージを選ぶなら軽く使うか、重く作り込むならパッケージの土台を捨てるか。中途半端が一番悪い、ということです。導入時に何が崩れるかについては生産管理システム導入失敗の5つの断層で別に整理しています。

決めるべき問いは1つに絞れる

したがって、選定会議で議論すべき問いは「どの製品が機能豊富か」ではありません。

うちの工場は、年に何人月ぶん業務ルールが変わる会社か。

この1つだけです。この記事ではこの量を x（人月/年）と書きます。xが小さい工場はパッケージが安く、xが大きい工場はスクラッチが安くなります。そして後で示すモデル試算では、その分岐点が約1.4人月/年という具体的な数字に落ちます。

xは主観ではなく、過去24か月の変更履歴から測れます。測り方は本記事の後半で5ステップに分けて書きます。

二択ではなく三択である ― 最も高いのは真ん中

「パッケージか、スクラッチか」という設問の立て方に、最初の落とし穴があります。実際に多くの工場が選んでいるのは、その中間だからです。パッケージを買って、足りないところを大量に作り込む。社内的には「良いとこ取り」と説明され、稟議も通りやすい選択肢です。

このモデル試算では、この中間案が最も高くつきます。

方式A・B・Cの定義

比較のために、3つの方式を人月で定義します。以下はすべて、タイの日系工場1拠点、生産管理システムの利用者40名という同じ規模を前提にしています。

方式Aは、先ほどのGodlanの集計でいう「製品の設計思想の枠内での中程度の適合」にあたります。方式Bはその外側に出た状態です。方式Cは土台ごと自社で持つ形です。

注意していただきたいのは、Bの22人月とCの26人月の差が4人月しかない点です。「パッケージを買えば作る量が減る」という直感は、重改造まで行くと成立しません。標準機能に合わない業務を標準機能の上に載せる作業は、白紙から書く作業より安くならないことがあります。既存のデータ構造と処理順序に合わせながら差し込む必要があるためです。

なぜ「パッケージを重改造する」が2つの税を払う形になるのか

方式Bが高くなる理由は、構築費が高いからだけではありません。構築費を払い終えた後も、毎年2つの費目を払い続ける構造になるからです。

1つ目の税：ライセンス料。パッケージを土台に使っている以上、改造をどれだけ積んでもライセンス料は減りません。このモデルでは40ユーザー×2,500 THB/月＝年1,200,000 THB、5年で6,000,000 THBです。方式Aも同額を払いますが、Aは払った分だけ標準機能を使っています。Bは標準機能の多くを改造で上書きしているのに、上書きされた標準機能の分まで払い続けます。

2つ目の税：バージョンアップ再適合。パッケージのバージョンが上がると、改造した箇所は動作を確認し、多くは作り直します。改造量が多いほどこの作業は大きくなります。このモデルでは5年間に1回のバージョンアップを想定し、その時点までに積み上がった改造工数の40%を作り直す、と置いています。Bは初期改造が14人月と大きいので、この再適合だけで方式Aの約2.4倍（x＝1のとき1,368,000 THB対576,000 THB）から約1.5倍（x＝4のとき2,448,000 THB対1,656,000 THB）を負担します。

この2つは、どちらもスクラッチには存在しません。スクラッチにはライセンス料がなく、他社のバージョン計画に合わせて作り直す作業もありません。代わりにインフラ費と保守費が必要になりますが、後で見るとおり合計額はライセンス料より小さく収まります。

さらに、この2つの税には「払っても業務が良くならない」という性質があります。バージョンアップ再適合の工数は、業務要求を1つも実現しません。動いていたものを、動く状態のまま作り直すだけです。予算会議でこの費目を説明する担当者が毎回苦労するのは、そのためです。

5年総額のモデル試算：分岐点は年1.4人月

ここから金額を置きます。以下はすべて当社のモデル試算であり、特定案件の見積もりではありません。前提を全部書きますので、自社の値に置き換えて読んでください。

前提（人月単価・ユーザー数・期間）

人月単価180,000 THBは幅のある数字です。実勢は15万〜25万THB/人月に散らばります。ERI SalaryExpertの同じ調査では、経験1〜3年のバンコクのソフトウェア開発者が年間834,099 THB、8年以上が1,362,287 THBで、月額に直すと約44,000 THBの開きがあります。誰を何人張り付けるかで単価は動きます。

なお、参考値として海外の相場も置いておきます。LI Solutionsの2026年版のまとめでは、受託開発の保守費は初期構築費の年15〜25%が相場とされ、中小規模の業務システム構築が5万〜12万USD、統合・分析・QAを含む本格構築が10万〜50万USDのレンジです。日本国内については、c3indexの2026年版まとめが基幹システム構築費を規模別に500万円〜3億円としています。これらは通貨も対象範囲も異なるため、本試算のTHBには一切換算していません。相場感の確認用です。

保守費12%という置き方については補足が必要です。受託開発の保守費の相場はLI Solutionsの整理で年15〜25%ですが、本試算では機能追加（x）を別建てにしているため、保守を12%と低めに置いています。x＝1人月/年のケースで合算すると初期構築費に対して年15.8%となり、相場の下限付近に収まります。x＝4人月/年なら27.4%で、相場をやや上回ります。この整合が取れているかどうかは、自社の値を入れたときにも確認してください。

この表のうち、自社の値に置き換えてほしいのは人月単価とユーザー数の2つです。この2つを差し替えるだけで、以下の結論の方向は自社向けに引き直せます。インフラ費の置き方が気になる場合はクラウドとオンプレミスの選び方を併せてご覧ください。

5年総額の式

3方式の5年総額は、xの1次式で書けます。

• 方式A(x) ＝ 1,980,000 ＋ 6,000,000 ＋ 900,000x ＋ 0.4×(3＋5x)×180,000 ＝ 8,196,000 ＋ 1,260,000x
• 方式B(x) ＝ 3,960,000 ＋ 6,000,000 ＋ 900,000x ＋ 0.4×(14＋5x)×180,000 ＝ 10,968,000 ＋ 1,260,000x
• 方式C(x) ＝ 4,680,000 ＋ 1,200,000 ＋ 2,808,000 ＋ 900,000x ＝ 8,688,000 ＋ 900,000x

各項の内訳は次のとおりです。

3方式は同じベースライン（現状のExcel運用）から測っています。効果額を二重に数えないため、削減額ではなく支出総額だけで比較します。年次改造の900,000xは3方式に共通で、どの方式を選んでも業務ルールの変化そのものは消えません。

x＝1人月/年のとき

年に1人月、つまり20営業日ぶんの改造要求が発生する工場です。

最安は方式Aです。ただしCとの差は132,000 THBで、Aに対して+1.4%にすぎません。5年で1,000万THB近い支出のうちの13万THBですから、実務的には互角です。前提を少し動かせば順位は入れ替わります。

一方、方式Bは12,228,000 THBで、Aより2,772,000 THB高く、Aに対して+29.3%です。Cと比べても2,640,000 THB高く、Cに対して+27.5%です。xが小さい工場でも、重改造は突出して高いという点がここで確認できます。

x＝4人月/年のとき

年に4人月、80営業日ぶんの改造要求が発生する工場です。個別受注が多く、客先ごとに帳票と検査項目が違う工場ではこの水準になります。

順位が入れ替わります。最安は方式Cの12,288,000 THBです。方式AはCより948,000 THB高く、Cに対して+7.7%。方式BはCより3,720,000 THB高く、Cに対して+30.3%です。

方式BとAの差は、x＝1のときもx＝4のときも2,772,000 THBで一定です。両者は年次改造の傾き（1,260,000x）が同じで、違いは初期改造量と再適合量だけだからです。つまり重改造で上乗せした金額は、xがどれだけ大きくなっても回収されません。重改造を擁護する論拠は「先に作り込んでおけば将来の変更が楽になる」ですが、両者の傾きが同じである以上、変更が増えてもBがAに追いつく局面は訪れません。この2,772,000 THBは、パッケージの土台の上に載せるという選択そのものの価格です。

損益分岐点の式と、自社値への置き換え方

方式Aと方式Cの5年総額が等しくなるxを求めます。

“`

8,196,000 ＋ 1,260,000x ＝ 8,688,000 ＋ 900,000x

360,000x ＝ 492,000

x ≒ 1.37

“`

分岐点は約1.4人月/年です。1人月を20営業日とすると、年およそ28人日。このとき両者の5年総額はどちらも約9,918,000 THBで一致します。

式の構造を言葉に直すと、こうなります。右辺の492,000 THBは、方式Aが持つ固定費上の優位です。Cのほうが初期構築で2,700,000 THB多く払う一方、5年間の維持費ではCのほうが2,208,000 THB少なくて済むため、差し引き492,000 THBだけAが有利な位置から始まります。維持費の差の内訳は、ライセンス6,000,000 THBに対してCのインフラ＋保守が4,008,000 THBで、年あたり398,400 THB、5年で1,992,000 THB。これにAの再適合216,000 THBを足すと2,208,000 THBです。

左辺の360,000xは、xが1人月増えるごとにAがCより余分に払う額です。年次改造そのものは3方式共通ですが、Aだけはその改造の40%を5年後に作り直すため、1人月あたり0.4×5×180,000＝360,000 THBが上乗せされます。この上乗せが492,000 THBを食い潰す点が、分岐点です。

自社値に置き換える手順は3つです。

1. 人月単価を自社の実勢に差し替える。180,000 THBを150,000 THBにするなら、人月に比例する項をすべて0.833倍します。ここで漏らしやすいのが方式Cの保守費です。保守費は初期構築費の12%/年と置いているので、単価が下がれば初期構築費が下がり、保守費も連動して下がります。つまり0.833倍する対象は、初期構築費・年次改造・再適合・C保守費の4つです。動かないのはライセンス料とインフラ費の2つだけです。C保守費を年561,600 THBのまま据え置くと、Cの5年総額を468,000 THB過大に見積もり、分岐点の位置を誤ります。
2. ユーザー数を差し替える。40名を80名にすればライセンスは年2,400,000 THBになり、Aの固定費優位は消えます。ユーザー課金型のパッケージでは、人数がそのまま分岐点を押し下げます。
3. 自社のxを測って代入する。測り方が次の章です。

分岐点が約1.4人月/年という数字は、この2つの前提に強く依存します。単価が下がるとCが有利になり、ユーザー数が減るとAが有利になります。数字そのものより、どちらの方向に動くかを理解して自社に当てはめることが重要です。より広い費目レンジについては生産管理システムの費用にまとめています。

なお、この試算にはいくつか意図的に含めていないものがあります。回収年数は書いていません。3方式はいずれも支出であり、投資と回収の関係が一意に置けないため、分母の根拠がない年数は出しません。また、方式Bの22人月と方式Cの26人月が同等の業務適合に到達すると置いています。実際にはBのほうが標準機能に引きずられて適合が甘く残ることも、Cのほうが作り込み過剰になることもあります。

自社の改造頻度 x を測る5ステップ（生産管理システム 選び方の実務）

ここが本題です。xは感覚では出ません。過去の記録から機械的に出します。所要は2人で3日程度、資料が散っていても1週間です。

ステップ1：過去24か月の変更履歴を集める

集める先は4か所です。

• 情シスまたは生産技術に出された依頼票、社内チケット、依頼メールのフォルダ
• ベンダーへのメールと見積書、追加開発の発注履歴
• Excelの改版履歴（ファイル名の日付、シートの追加履歴、変更履歴シート）
• マクロ・Accessの更新日時、VBAモジュールのコメント欄

24か月にする理由は、季節性と決算期の影響を平準化するためです。12か月では期末に集中した変更が過大に効きます。逆に36か月まで遡ると、当時の担当者がいなくなっていて内容が判定できない件が増えます。

この段階では件数を集めるだけで、内容の評価はしません。1件1行でスプレッドシートに落とします。列は、発生年月、依頼元、1行の概要、対応の有無だけで足ります。

ステップ2：「業務ルールの変更」と「使い方の修正」を分ける

集めた件を2つに分けます。xに数えるのは前者だけです。

業務ルールが変わったもの（xに数える）

• 客先要求で検査項目や記録項目が増えた
• 新しい製品ラインが立ち上がり、工程マスタの構造を変えた
• 原価の按分方法や在庫の評価方法を変えた
• 帳票のレイアウトを客先仕様に合わせて新設した
• 法令・規格の改定で保管年限やトレーサビリティの粒度を変えた
• 拠点や倉庫が増えて、コードの体系を拡張した

使い方を直しただけのもの（xに数えない）

• 入力ミスのデータ修正、マスタの単発メンテナンス
• 権限追加、ユーザー登録、パスワード再発行
• 帳票の印刷が崩れたので余白を直した
• 「使い方が分からない」という問い合わせへの回答
• サーバーの再起動、バックアップ関連

この仕分けを厳しくやることが、xの精度を決めます。運用の問い合わせを混ぜると、xが実態の2倍から3倍に膨らみます。判定に迷ったら「この件は、同じ業務を続けていれば発生しなかったか」を基準にしてください。発生しなかったなら業務ルールの変更、業務を続けていても起きるなら運用です。

ステップ3：規模を3段階に丸めて年換算する

残った件を、対応工数で3段階に丸めます。細かく見積もると時間ばかりかかり、精度は上がりません。

合計したら、24で割って12を掛けます。これが年間人月です。

2つ例を挙げます。

工場ア（量産品目が固定、客先が少数）：24か月で業務ルールの変更に該当したのは7件。小0.2人月×5件＝1.0、中0.5人月×2件＝1.0。合計2.0人月。年換算は 2.0 ÷ 24 × 12 ＝ 1.0人月/年。

工場イ（個別受注、客先ごとに帳票と検査項目が違う）：24か月で該当したのは19件。小0.2人月×10件＝2.0、中0.5人月×6件＝3.0、大1.0人月×3件＝3.0。合計8.0人月。年換算は 8.0 ÷ 24 × 12 ＝ 4.0人月/年。

この2つは、先ほどの試算のx＝1とx＝4にそのまま対応します。工場アはパッケージ標準運用（方式A）が最安で、工場イはスクラッチ（方式C）が最安です。同じ「日系工場40ユーザー」でも、答えが逆になります。

ステップ4：今後2年に確定している変更を足す

過去だけで決めると、確定済みの将来を見落とします。次の4つは経営計画や営業の受注見込みから拾えます。

• 新製品ラインの立ち上げ計画（工程マスタの追加、検査基準の新設）
• 客先から要求されているトレーサビリティの強化（ロット追跡の粒度、記録の保管期間）
• 法令・規格対応（環境規制、輸出管理、業界認証の更新）
• 拠点追加・生産移管（コード体系の拡張、拠点間の在庫移動）

これらを同じ3段階で見積もり、2年ぶんを24で割って12を掛け、ステップ3の値に加算します。過去の実績値だけを使うと、今まさに事業が伸びている工場でxを低く見誤ります。

タイの製造業では、この将来分が効きます。JETROの整理によると、タイのBOIへの投資申請は2025年に過去最高の約1兆8,000億バーツに達しました。さらにバンコク週報が伝えるところでは、2026年6月に先端製造分野向けの許認可短縮制度「タイランド・ファストパス」が正式に発足し、対象案件は合計7,000億バーツを超えています。周辺の投資が動くということは、自社の受注構成と生産品目も動くということです。

ステップ5：出てきたxを式に入れる

方式A(x) ＝ 8,196,000 ＋ 1,260,000x、方式C(x) ＝ 8,688,000 ＋ 900,000x に代入して比べます。xが1.4を明確に下回るならパッケージ標準運用、明確に上回るならスクラッチ。1.0から1.8のあいだに入った場合は、この試算だけでは決まりません。総額が互角なので、金額以外の条件で決めることになります。

xが大きくなりやすい工場の特徴

該当数で自己診断してください。3つ以上当てはまるなら、測る前からxは大きい側です。

1. 個別受注・多品種少量で、客先ごとに帳票と検査項目が違う
2. 客先監査が多く、監査のたびに記録項目が増える
3. 拠点や生産品目が増える計画が経営計画に載っている
4. 現場が強く、改善提案がそのままシステム要求として上がってくる文化がある

逆にxが小さいのは、量産品目が固定で、客先が少数で、業務ルールが本社標準で決まっている工場です。この場合、現地で業務ルールを変える権限がそもそも少ないため、xは構造的に上がりません。

1番の個別受注型は、xが大きくなる代表格です。受注ごとに工程が変わる業務をどう設計するかは個別受注生産の生産管理で詳しく扱っています。

それでもパッケージが正解になる4つの条件／スクラッチが正解になる4つの条件

xだけで決められない場合があります。金額以外の条件を整理します。

パッケージ（方式A）が正解になる4つの条件

1. xが1人月/年を下回る見込みである。過去24か月の実績と今後2年の確定分の両方で下回ることを確認してください。片方だけでは足りません。
2. 本社が業務標準を握っており、現地に業務ルールを変える権限がない。この場合、現地で発生する要求の多くは「本社に確認して却下」で終わり、xに積み上がりません。
3. 立ち上げ期限が短い。工場稼働に間に合わせる必要がある、監査までに記録の仕組みが要る、といった期限がある場合、初期11人月と26人月の差は金額以上に重い制約になります。
4. 社内に仕様書とソースを維持し続ける体制がない。スクラッチは仕様の正本を自社が持つ方式です。持てないなら選んではいけません。

スクラッチ（方式C）が正解になる4つの条件

1. xが1.8人月/年を超える。分岐点の1.4に対して余裕を見た水準です。測定の誤差を考えると、1.4をわずかに超えた程度では判断材料になりません。
2. 業務ルールそのものが競争力になっている。特殊工程の管理方法、独自の原価計算、客先との取り決めが差別化要因である場合、それをパッケージの標準に合わせて捨てるのは事業上の損失です。
3. 5年以上使う前提で、拠点展開や品目追加が計画に載っている。比較期間が7年、10年と伸びるほど、ライセンス料の累積がCに有利に働きます。
4. 仕様の正本を自社で保持し続ける意思と体制がある。要件定義書、テーブル定義、変更履歴を自社の資産として管理し、担当者が交代しても引き継げる状態を維持できることが条件です。

4番目の条件は、満たせない場合の代償が最も大きい項目です。経済産業省は2025年5月28日に「レガシーシステムモダン化委員会総括レポート」を公表し、2018年のDXレポートが示した「2025年の崖」、すなわち放置すれば2025年以降の5年間で最大年12兆円の経済損失が生じるという指摘への対応状況を総括しています。ここで言うレガシー化は、古い技術で書かれていることそのものではありません。中身を説明できる人と資料が失われた状態を指します。この意味では、仕様書を持たないスクラッチも、改造の記録を残さない重改造も、同じ場所に着地します。方式Cを選ぶということは、5年後に自社の誰かがその中身を説明できる体制を維持すると約束することです。

方式B（パッケージ重改造）はどうか。このモデルの中では、Bはどのxでも最安になりません。Aより常に2,772,000 THB高く、Cとの差はx＝1で2,640,000 THB、x＝4で3,720,000 THBと、xが増えるほど開きます。それでもBを選ぶ理由があるとすれば、モデルの外側にある条件です。たとえばグループ会計上パッケージ製品であることが本社要件になっている、監査対応上ベンダーの製品保証が必要である、といった場合です。その場合は「金額では不利だと分かったうえで選んでいる」ことを稟議書に明記してください。後から「なぜこんなに高いのか」と問われたときに、説明できる状態にしておくためです。

「AIで作れば安い」は本当か

2026年の選定会議では、必ずこの論点が出ます。「AIでコードが書けるから、スクラッチはもう安い」という主張です。数字を見て判断します。

DX（getdx.com）が400社超を14か月にわたって分析した調査によると、AIコーディングアシスタント導入によるPRスループットの中央値改善は7.76%です。多くの企業は5〜15%に収まり、90パーセンタイルで43.9%。そしてコーディングは開発者の1日の約14%にすぎません。ツールの費用は1人月あたり200〜600 USD（シート＋トークン）とされています。

中央値7.76%であって、数倍ではありません。この差は決定的です。生産性が数倍になるなら、方式Cの26人月は8人月前後になり、比較の構造そのものが変わります。7.76%なら26人月が約24人月になるだけです（26 × 7.76% ＝ 約2.0人月）。しかもこの計算は、コーディング以外の要件定義・テスト・移行・立上げにも同率が効くと仮定した、かなり甘い見積もりです。コーディングが1日の14%なら、実際の波及はこれより小さくなります。

この試算にAI効果を織り込まなかった理由

本記事の試算はAI効果をゼロで置いています。理由は2つです。

1つは、片側だけに割り引くと結論が壊れるからです。感度を見ておきます。仮に方式Cの初期26人月が2人月減ると、初期構築費が360,000 THB減り、その12%×5年の保守費も216,000 THB減るため、合計576,000 THBが減ります。方式Aの固定費上の優位は492,000 THBしかないので、これだけで分岐点は理屈のうえで消えてしまいます。ところが同じAI効果は方式Aの11人月にも方式Bの22人月にも効きます。Cだけに割引を適用した試算は、結論を先に決めた計算です。

もう1つは、方向性は分かるが幅が置けないからです。方向として言えるのは、AIは人月に効き、ライセンス料には効かないということです。方式A・Bは5年で6,000,000 THBのライセンスを抱え、これは開発効率がどれだけ上がっても1バーツも減りません。総額の大半が人月である方式C（x＝0の8,688,000 THBのうち人月非連動はインフラ1,200,000 THB、13.8%）のほうが、効率化の恩恵を受けます。したがってAIを織り込むと分岐点は下がる方向、つまりスクラッチが有利になる方向に動きます。逆に言えば、本記事が示した1.4人月/年という分岐点は、スクラッチにとって厳しめに出た数字です。

なお、AIコーディングツール自体の費用（開発者1人あたり月200〜600 USD）は、他のUSD建て出典と同様、THB建ての本試算には含めていません。ただし、下がり幅は中央値7.76%という水準から逆算されるものであって、生産性が数倍になる前提の議論とは別物です。「AIがあるから作ろう」ではなく、「xが大きいから作る。AIはその判断を少し後押しする」という順序が正しい読み方です。

生産管理システム 自作・内製の現実的な線引き

「AIで作れる」からもう一歩進んで、「社内で作る」という話になることがあります。生産管理システムの自作・内製は、範囲を限れば有効です。線引きを3つで示します。

内製に向くもの：日報入力、簡易な進捗表示、既存システムからのデータ抽出とレポート、現場の掲示用ダッシュボード。データの正本を持たず、壊れても在庫や出荷が止まらない領域です。

内製に向かないもの：在庫の正本、原価計算、客先向けトレーサビリティ記録、他システムとの基幹連携。ここは、担当者が退職した瞬間に誰も直せないという状態が事業リスクになります。

判断の基準：そのプログラムが止まったとき、翌日の出荷が止まるかどうか。止まるなら内製の範囲外です。作った本人が3年後もその工場にいる保証はありません。

なお、範囲を限った業務アプリの費用感については製造業の業務アプリ開発で扱っています。生産管理の全体をスクラッチするかどうかとは別の判断軸です。

生産管理システム 導入期間はどれだけ違うか

金額の次に必ず聞かれるのが期間です。ここも当社のモデル試算として置きます。

前提：ベンダー側の同時稼働人数を平均2.5名、ユーザー側の確認待ちや現場都合による停滞を含めた実働率を80%とします。カレンダー月数 ＝ 人月 ÷ 2.5 ÷ 0.8 で計算します。

読みどころは、BとCの差が2.0か月しかない点です。方式Bは、期間の面でもスクラッチの2か月手前までしか短縮できません。それでいてx＝4のとき5年総額はCより3,720,000 THB高い。2か月早く立ち上げるために1か月あたり1,860,000 THBを払う計算になります。x＝1でも差額2,640,000 THBを2か月で割って、1か月あたり1,320,000 THBです。「早く立ち上げたいから重改造」という理由づけは、この金額に見合うかどうかで検証してください。

期間が伸びる本当の理由

上の表はベンダー側の工数から逆算した数字ですが、実際の案件で期間が伸びる主因はベンダー側にはありません。3つあります。

1つ目は、決められないこと。要件定義中に「この帳票は誰が承認するのか」「この在庫は誰の責任か」という業務側の未決事項が出てきます。システムの話ではないので、ベンダーは待つしかありません。上の試算で実働率を80%に置いているのは、この待ち時間を織り込むためです。日系工場では本社確認が挟まるため、実働率が60%台に落ちる案件もあります。

2つ目は、現行業務が文書化されていないこと。Excelとベテランの頭の中で回っている業務は、要件定義で初めて言語化されます。この作業自体に数か月かかることがあります。しかもこれは方式A・B・Cのどれを選んでも発生します。パッケージだから省略できるわけではありません。

3つ目は、データ移行。品目マスタ、取引先マスタ、在庫の初期残高。既存データの重複と欠損を洗い出す作業は、どの方式でも避けられません。方式Cの26人月に「テスト・移行・立上げ6人月」を含めているのはこのためです。

Godlanが引くPanorama Consulting Groupの2026年ERPレポートでは、製造業のERPプロジェクトの期間超過が平均30%（業界平均25%）とされています。上の表の月数に3割を上乗せした値を、社内には伝えておくのが現実的です。

タイで発注する場合の追加論点

日本国内の判断基準がそのままは使えない部分があります。システム開発を委託する先をタイのシステム開発会社にする場合、5つの論点が追加されます。

言語と仕様書

タイの工場では、日本語（本社と駐在員）、英語（ベンダーと管理職）、タイ語（現場作業者）の3つが同時に動きます。仕様書を何語で書き、画面を何語で出すかを最初に決めてください。ここを決めないまま進むと、要件定義は英語、画面はタイ語、承認は日本語という状態になり、変更のたびに3回訳すことになります。

実務的な線引きは、仕様書の正本を1言語に決め、他は参照訳とすることです。正本を2言語持つと、改版のたびに差分が生まれ、どちらが正しいか分からなくなります。画面のラベルは別で、現場が使う画面はタイ語が必須です。方式Cを選ぶなら多言語化は設計の最初に組み込みます。後付けは高くつきます。

開発体制と人材の流動性

ERI SalaryExpertによると、バンコクのソフトウェア開発者の年間報酬は平均1,185,019 THB、経験1〜3年で834,099 THB、8年以上で1,362,287 THBです。日本と比べれば低い水準ですが、経験者の確保という観点では別の問題があります。転職の頻度が日本より高く、プロジェクト期間中の担当者交代が起きやすいことです。

対策は契約段階で打ちます。担当者が交代した場合の引き継ぎ責任をベンダー側に置くこと、設計書と変更履歴を成果物として定義すること、キーパーソン1名への依存を体制図の段階で潰しておくこと。この3つは、見積金額の交渉より優先してください。

BOIと投資環境

BOI（タイ投資委員会）の恩典を受けている法人では、ソフトウェア資産の扱いや調達先の条件が案件ごとに異なります。開発費の計上方法と恩典への影響は、発注前に会計事務所に確認してください。金額が大きい方式B・Cでは、この確認を後回しにすると期末に問題になります。

投資環境そのものも動いています。JETROが伝えるとおり、BOIへの投資申請は2025年に過去最高の約1兆8,000億バーツに達し、バンコク週報によると2026年6月には先端製造分野向けの許認可短縮制度「タイランド・ファストパス」が発足しました（対象案件は合計7,000億バーツ超）。周辺で投資が加速するということは、自社の生産品目と拠点構成も5年のあいだに動く可能性が高いということです。これはxを押し上げる方向に働きます。

撤退時・切り替え時の引き継ぎ

最も見落とされるのがここです。ベンダーとの契約が終わるとき、あるいはベンダーを変えるとき、何が自社に残るのかを契約書に書いておきます。最低限、次の4点です。

1. ソースコードの著作権または利用権。誰が持つのか、他社に改修を依頼できるのか。
2. 設計書・テーブル定義・変更履歴の納品。納品形式と更新責任を明記します。
3. データのエクスポート。稼働中のデータを標準的な形式で全件出せること。出せない形式でロックされると、方式の選び直しが実質不可能になります。
4. 本番環境のアカウントとインフラの所有者。クラウドの契約名義が自社かベンダーかで、切り替えの難易度が変わります。

方式Cを選ぶ場合、この4点が守られていなければ「自社で持つ」という前提が成立しません。ライセンス料を払わない代わりに、ベンダーへの依存が構造化されるだけです。方式A・Bでも、改造部分については同じ論点が残ります。

日本国内相場との比較の落とし穴

本社に稟議を上げるとき、日本の相場と比較されることがあります。c3indexの2026年版まとめでは、日本国内の基幹システム構築費は規模別に500万円〜3億円と幅があります。この幅の中のどこと比較するかで、話がいくらでも変わります。

比較を成立させるには、金額ではなく人月数と役割分担を並べてください。26人月という数量は通貨に依存しません。日本のベンダーが同じ範囲を何人月と見るか、その人月に要件定義と移行が含まれるか。ここを揃えれば、単価差の議論に進めます。単価だけを比べても、含まれる範囲が違うので結論は出ません。

よくある質問（FAQ）

生産管理システムのスクラッチ開発とパッケージ、結局どちらが安いですか

稼働後の年間改造要求（x）で決まります。本記事のモデル試算（タイ日系工場40ユーザー、5年、人月単価180,000 THB）では、x＝1人月/年ならパッケージ標準運用が9,456,000 THBで最安、スクラッチは9,588,000 THBで132,000 THB高く、差はわずか1.4%です。x＝4人月/年ならスクラッチが12,288,000 THBで最安になり、パッケージ標準運用は948,000 THB高く、スクラッチに対して+7.7%です。分岐点は約1.4人月/年（年およそ28人日）。この分岐点は人月単価とユーザー数に依存するため、自社の値で引き直してください。

生産管理システムの導入期間はどれくらいかかりますか

同じモデルの前提（同時稼働2.5名、実働率80%）で、パッケージ標準運用が約5.5か月、パッケージ重改造が約11.0か月、スクラッチが約13.0か月です。ただしGodlanが引くPanorama Consulting Groupの2026年ERPレポートでは、製造業のERPプロジェクトの期間超過が平均30%（業界平均25%）とされています。社内に伝える期間には3割の余裕を乗せてください。期間が伸びる主因はベンダーの作業速度ではなく、業務側の未決事項、現行業務が文書化されていないこと、データ移行の3つです。

パッケージのカスタマイズはどこまでなら許容範囲ですか

金額の面では、初期改造が3人月（本記事の方式A）に収まる範囲です。それを超えて14人月（方式B）まで行くと、5年総額はパッケージ標準運用より2,772,000 THB高く、スクラッチよりもx＝1で2,640,000 THB、x＝4で3,720,000 THB高くなります。考え方の面では、Godlanが引くPanorama Consulting Groupの集計が参考になります。重改造よりも製品の設計思想の枠内での中程度の適合のほうが結果が良く、45%の企業がその方法で最良の結果を得ています。製品の設計思想の外に出る改造が必要になった時点で、それはパッケージを選び直すか、土台ごと自社で持つかを再検討する合図です。

生産管理システムを自作（内製）できますか

範囲を限れば可能です。日報入力、簡易な進捗表示、既存システムからのデータ抽出とレポート、現場掲示用のダッシュボードは内製に向きます。一方、在庫の正本、原価計算、客先向けトレーサビリティ記録、基幹連携は向きません。判断基準は「そのプログラムが止まったとき、翌日の出荷が止まるか」です。止まるなら内製の範囲外です。AIコーディングアシスタントを前提にした内製についても、DXの400社超・14か月の調査ではPRスループットの中央値改善は7.76%で、多くの企業は5〜15%です。作る速さは多少上がりますが、作った人が辞めた後に誰が直すかという問題は変わりません。

タイのシステム開発会社に委託する場合、契約書に何を書くべきですか

最低4点です。ソースコードの著作権または利用権（他社に改修を依頼できるか）、設計書・テーブル定義・変更履歴の納品形式と更新責任、稼働中データを標準形式で全件エクスポートできること、本番環境のアカウントとクラウド契約の名義。加えて、担当者が交代した場合の引き継ぎ責任をベンダー側に置く条項を入れてください。バンコクの開発者市場は人材の流動性が高く、プロジェクト期間中の交代は珍しくありません。見積金額の交渉より、この5項目を先に固めるほうが最終的な支出は下がります。

いまExcelで回しています。最初に何をすべきですか

製品の資料請求ではなく、過去24か月の変更履歴を数えることです。依頼票、ベンダーへのメール、Excelの改版履歴、マクロの更新日を集め、業務ルールが変わったものと使い方を直しただけのものに分け、前者を0.2／0.5／1.0人月の3段階に丸めて合計し、24で割って12を掛けます。これが自社のxです。今後2年に確定している変更を足して、本記事の式に代入すれば、パッケージとスクラッチのどちらが自社にとって安いかが金額で出ます。この作業は2人で3日程度、資料が散っていても1週間で終わります。製品比較よりも先にやる価値があります。

まとめ

生産管理システムのスクラッチ開発とパッケージ導入の分かれ目は、機能一覧ではありません。稼働後に業務ルールが年何人月ぶん変わるか、というxの1点です。

選択肢は二択ではなく三択で、最も高いのは真ん中です。パッケージを重改造する方式Bは、ライセンス料とバージョンアップ再適合という2つの税を毎年払い続ける形になり、5年総額はパッケージ標準運用より常に2,772,000 THB高く、スクラッチよりもx＝1で2,640,000 THB、x＝4で3,720,000 THB高くなります。両者は傾きが同じなので、この上乗せはxがどれだけ大きくなっても回収されません。

金額の結論は1本の式に落ちます。方式A(x)＝8,196,000＋1,260,000x、方式C(x)＝8,688,000＋900,000x。両者が等しくなるのはx≒1.37、つまり約1.4人月/年（年およそ28人日）で、このとき5年総額はどちらも約9,918,000 THBです。x＝1ならパッケージが132,000 THB安く（Aに対して+1.4%の差で実質互角）、x＝4ならスクラッチが948,000 THB安くなります（Cに対して+7.7%）。人月単価とユーザー数は自社の値に置き換えてください。単価が下がるとスクラッチが有利になり、ユーザー数が増えるとパッケージのライセンス累積が効いて分岐点は下がります。

「AIで作れば安い」は、方向としては正しいが幅が違います。DXの調査ではPRスループットの中央値改善は7.76%で、数倍ではありません。本記事の試算はAI効果をゼロで置いているため、示した1.4人月/年はスクラッチにとって厳しめに出た数字です。それでも判断を動かすのはAIではなくxです。

そして最初にやるべきことは、製品の資料請求ではなく、過去24か月の変更履歴を数えることです。この作業は数日で終わり、その結果が5年で1,000万THB規模の意思決定を根拠づけます。

まだ方式を決めていない段階でも構いません。手元の依頼票やベンダーへのメールを一緒に並べて、自社のxがいくつになるかを数えるところからお手伝いできます。3方式の式に自社の人月単価とユーザー数を入れ直して、どこで順位が入れ替わるかを確認するだけでも、社内の議論の土俵は変わります。ご相談はお問い合わせフォームからどうぞ。

参考資料

• ERP Implementation Failure Statistics（Godlan／Panorama Consulting Group「2026 ERP Report」を引用）
• AI Coding Assistant Pricing and Impact（DX / getdx.com）
• Custom Software Development Cost 2026（LI Solutions）
• レガシーシステムモダン化委員会 総括レポート（2025年5月28日／経済産業省・IPA）
• タイの製造業をめぐる構造変化に関する地域・分析レポート（JETRO）
• タイランド・ファストパス関連記事（バンコク週報）
• Software Developer Salary in Bangkok, Thailand（ERI SalaryExpert）
• 基幹システム構築費用の相場（c3index）

本記事の金額はすべて当社が仮に置いた前提にもとづくモデル試算であり、特定案件の見積もりではありません。前提（人月単価180,000 THB、40ユーザー、5年、ライセンス2,500 THB/ユーザー/月、インフラ年240,000 THB、保守12%/年、再適合40%）を変えれば結論は変わります。文中で言及した製品カテゴリや調査はいずれも各社・各機関のものであり、当社の製品ではありません。数値は2026年8月時点で公表されている内容にもとづきます。