Blog

2026.08.24

システムインテグレーター製造業選定|失敗しない発注ガイド2026

システムインテグレーター製造業選定|失敗しない発注ガイド2026

「生産管理システムを刷新したいが、どのシステムインテグレーターに頼めばよいか分からない」。製造業の情報システム担当者からよく聞く悩みです。特にタイ・東南アジアに進出した日系製造業では、現地SIerの実力差や言語の壁も加わり、選定の難易度が一段上がります。本記事では、SIerの種類と選定基準、よくある失敗パターン、そしてタイ・ASEAN特有の論点を、公開データをもとに整理します。

システムインテグレーターとは|製造業における位置づけと種類

システムインテグレーター(SIer)とは、企業のシステム開発を要件定義から設計・開発・導入・保守まで一貫して請け負う事業者の総称です。ひとことでSIerと言っても、その実態は幅広く、頼む相手によって出てくる提案も体制もまったく異なります。

SIerの4つのタイプを区別する

製造業がシステム開発を委託する際に出会うSIerは、おおむね次の4タイプに分けられます。

  • 元請けSIer。発注企業と直接契約し、プロジェクト全体の責任を負う立場です。実際の開発工程の一部または大部分を、下請けの協力会社に再委託していることが少なくありません。
  • 専業ベンダー。生産管理や基幹システムなど特定領域に特化した製品・開発力を持つ会社です。業界固有の用語やロジックへの理解が深い傾向があります。
  • コンサル系SIer。上流の業務改革や要件整理を強みとし、開発工程そのものは自社で持たず、パートナー企業に委託する場合があります。
  • オフショア/ニアショア開発会社。海外や地方都市に開発拠点を置き、人件費や体制面での最適化を図る事業者です。

元請け・下請けの多重構造が生むリスク

見積書に記載された会社名と、実際に手を動かすエンジニアが所属する会社が違う、という状況は珍しくありません。元請けが要件を整理し、実装は二次請け・三次請けに流れていく多重下請け構造では、伝言ゲームのように要件が薄まっていくリスクがあります。誰が最終的な品質に責任を持つのか、契約段階で確認しておく必要があります。

多重下請け構造そのものが悪いわけではありません。元請けが適切にプロジェクト管理を行い、下請け先の品質を担保できていれば、発注側は窓口を一本化できるという利点もあります。問題になるのは、元請けが単なる「取り次ぎ」になっていて、要件の意図や現場の背景事情が実装担当者まで伝わっていないケースです。商談の段階で、元請けが下請け先の進捗をどう管理しているか、仕様変更が発生したときに誰がどう情報を伝えるかを具体的に聞いてみると、その会社の実際のプロジェクト管理力が見えてきます。

SIerのタイプ強み注意点
元請けSIerプロジェクト全体を一括管理できる実装が再委託されると現場の実態が見えにくい
専業ベンダー業界知見が深く要件定義が速い対応領域が限定され、周辺システムは別途調整が必要
コンサル系SIer業務改革を含めた上流設計に強い開発実務は別会社になり、責任分界が曖昧になりやすい
オフショア/ニアショア開発単価を抑えやすい言語・時差・商習慣の違いがコミュニケーションコストになる

自社が求めているのが「作ってほしい」なのか「一緒に考えてほしい」なのかによって、向いているタイプは変わります。この見極めを飛ばして相見積もりだけを取ると、比較対象がそもそも別物になってしまいます。

たとえば同じ「生産管理システムを刷新したい」という相談でも、専業ベンダーは自社製品をベースにしたアドオン開発を提案し、コンサル系SIerはまず業務フロー全体の見直しから入り、オフショア/ニアショア開発会社は要件がすでに固まっていることを前提に実装コストの見積もりを出してきます。3社の提案書を横に並べて金額だけを比較すると、そもそも前提にしている作業範囲が違うため、正しい比較になりません。まず自社がどの段階にいるのか、要件は固まっているのか、それとも業務そのものから見直したいのかを、社内で言語化しておくことが選定の出発点になります。

製造業のシステム開発がなぜ失敗するのか|典型パターンと構造要因

システムインテグレーター製造業選定|失敗しない発注ガイド2026 - figure 1

システムインテグレーターの選定を急ぐ前に、なぜ製造業のシステム開発が失敗しやすいのかを押さえておくことには意味があります。失敗の型を知っていれば、提案を評価する目が変わるからです。

よくある失敗パターン

システム開発の外注に関する失敗事例の調査では、想定の倍以上のコストがかかった、納期が半年遅れた、完成したものの結局使われず棚上げになった、といった典型パターンが繰り返し報告されています。逆に成功した事例に共通するのは、小さく始めて段階的に拡張したこと、開発中にベンダーと密なコミュニケーションを取り続けたこと、そして現場ユーザーの意見をきちんと反映したことの3点です。

  • コストが想定の倍以上に膨らむ。要件が曖昧なまま契約し、後から仕様変更や追加開発が積み重なるケースです。
  • 納期が大幅に遅れる。マスタ整備や現場テストにかかる時間を、発注側もベンダー側も甘く見積もっている場合に起きます。
  • 完成しても使われない。現場の運用実態とかけ離れた仕様で作られ、結局Excelでの二重管理に戻ってしまうパターンです。

製造業特有の落とし穴

一般的な業務システムと違い、製造業のシステム開発には機械や設備との接点という固有の難しさがあります。機械側の制御ソフトとシステム側の想定が噛み合わない、工場の温度や粉塵といった使用環境の条件が開発会社にきちんと伝わっていない、といったトラブルが指摘されています。こうした課題は、業界ノウハウを持つベンダーを選べるかどうかで発生確率が大きく変わります。FA機器との連携を伴う開発を検討している場合は、FAシステム構築の発注ガイドで、設備側との整合性をどう詰めるかを扱っていますので、あわせて参照してください。

IT人材の需給ギャップという構造問題

失敗の背景には、個別プロジェクトの問題だけでなく構造的な要因もあります。経済産業省系の分析では、ユーザー企業のIT人材需要に対してベンダー企業側の供給充足率は66パーセントにとどまり、特にビジネスアーキテクトやITアーキテクトといった上流人材が不足していると報告されています。日本企業は外部ベンダーへの依存度が高く、ユーザー企業側でICT人材を内製・育成できていない構造問題があるとも指摘されており、国内IT人材は2030年に最大79万人不足すると予測されています。つまり「良いSIerが見つからない」という感覚は、個社の運の問題ではなく、業界全体の需給が逼迫していることの表れでもあるのです。だからこそ、限られた候補の中から見極める選定基準の重要性が増します。

システムインテグレーターの選定基準|製造業のシステム開発委託で確認すべき5つの視点

システムインテグレーターを選ぶ際に確認すべき視点を整理します。どれも当たり前に聞こえますが、実際の商談では意外と確認されずに契約まで進んでしまいます。

基幹システムとの連携実績も確認する

生産管理単体で完結する開発は実はそれほど多くなく、多くのプロジェクトは会計や販売管理、在庫管理といった基幹システムとの連携を伴います。候補となるSIerに対しては、生産管理システム単体の実績だけでなく、基幹システムとの連携を含むプロジェクトをどれだけ手がけてきたかを確認してください。連携部分は後から追加開発になりやすく、ここでのつまずきが工期遅延の原因になりがちです。

選定基準確認のポイント
業界知見製造業、できれば同業種での構築実績があるか
実績直近3年の受注案件の業種・規模・システム種別
コミュニケーション体制打ち合わせ頻度、議事録の作成主体、質問への回答速度
保守体制稼働後の対応時間帯、担当者の継続性、障害時の初動時間
契約形態請負か準委任か、責任範囲と支払いタイミングの整合性

業界知見と実績

生産管理や在庫管理は企業ごとの独自ロジックが多い領域です。内示の扱い方、工程の分割方法、外注先への支給ルールは会社ごとに異なり、業界知見のないSIerに任せると、要件定義の段階で余計な時間がかかります。基幹システムとの連携を含む大きめの開発を検討している場合は、業務システム開発の費用とERP連携で費用感と連携パターンを整理していますので参考にしてください。

コミュニケーション体制

認識のズレは手戻りに直結します。商談の段階で、実際に開発を担当するエンジニアが同席するか、進捗報告の頻度と形式はどうか、質問への回答にどれくらいの時間がかかるかを確認してください。提案時の担当者と実装担当者が別人であること自体は珍しくありませんが、その事実を隠す会社は避けたほうが無難です。

保守体制と契約形態

稼働後の改修対応が止まってしまうと、せっかく作ったシステムが資産として機能しなくなります。保守契約の範囲、対応時間帯、障害時の初動時間を具体的な数字で確認してください。あわせて、契約形態が請負なのか準委任なのかによって、責任の所在と支払いのタイミングが大きく変わります。契約実務の詳細は、システム開発契約の実務で扱っている論点が参考になります。

請負契約では、SIer側が成果物の完成に責任を持ち、納品と検収をもって対価が支払われます。仕様が事前にある程度固まっている案件に向いていますが、途中の仕様変更には追加契約が必要になりやすく、身動きが取りにくい面もあります。一方の準委任契約では、成果物の完成そのものではなく、決められた工数・業務を遂行することに対して対価が支払われます。要件を固めながら段階的に進めるアジャイル的な開発には向いていますが、発注側にも進捗管理や意思決定の負担が生じ、丸投げはできません。どちらが優れているという話ではなく、自社のプロジェクトの性質に合っているかどうかで選ぶべきものです。

複数社比較は前提を揃える

金額だけで比較すると、テストの範囲やデータ移行の扱いといった前提条件がそろっていないまま高い安いを判断してしまいがちです。同じ要件でも提示の仕方によって見積額は大きく開きます。この前提を揃える役割を担うのが、次章で扱うRFPと要件定義です。

RFP・要件定義の重要性|発注前に固めるべきこと

システムインテグレーター製造業選定|失敗しない発注ガイド2026 - figure 2

システム開発の失敗の多くは、ベンダーの技術力ではなく、発注側の準備不足に起因します。中でも影響が大きいのが、RFP(提案依頼書)と要件定義の位置づけを取り違えることです。

RFPと要件定義書の役割の違い

ベンダーに丸投げした結果、認識のズレによってシステム導入が失敗するケースは少なくありません。複数のベンダーに対して課題と要望を伝え、比較可能な提案を引き出すための文書がRFPです。RFPと要件定義の役割を取り違えると、見積もり精度の低下や想定外の追加費用につながると解説されています。RFPは「何を実現したいか」を伝えて複数社から提案を募る段階の文書であり、要件定義書は選定後にベンダーと一緒に「どう実現するか」を詳細化していく文書です。この順序を逆にして、詳細な要件定義書をいきなり1社にだけ渡してしまうと、そもそも比較検討の機会を自ら手放すことになります。

RFPに含めるべき最低限の項目

  • 現状の課題。業務のどの場面で、何に困っているかを具体的に書きます。
  • システム化の目的。コスト削減なのか、リードタイム短縮なのか、優先順位を明確にします。
  • 対象範囲。生産管理だけなのか、在庫や基幹システムとの連携まで含むのかを示します。
  • 予算感と希望スケジュール。幅を持たせてよいので、目安を示すことで提案の精度が上がります。
  • 評価基準。価格だけでなく、実績やコミュニケーション体制をどう評価するかをあらかじめ決めておきます。

業務システムそのものの開発費用や進め方の基礎を押さえておきたい場合は、業務アプリ開発の費用と進め方にRFP作成の前段として整理した内容がありますので、あわせて確認してください。

複数ベンダー比較で見るべきポイント

複数社から提案を受け取ると、金額や工期に差が出ます。このとき安いほうを選ぶ前に、テストの範囲、データ移行の扱い、現場教育の有無、稼働後の保守が無償か別契約かという前提条件がそろっているかを必ず確認してください。前提がそろわないまま金額だけを比較すると、結局は最も安く見えるだけの提案を選んでしまうことになります。

2026年、生成AIとオフショア/ニアショアの潮流をどう見るか

システムインテグレーター選びの前提となる開発環境そのものも変化しています。2026年時点の潮流を押さえておくと、提案内容を評価する材料が増えます。

コストからリソース最適への転換

2026年は、為替変動や海外人件費の上昇を背景に、単純な「コストの安さ」よりも「どれだけ安定した開発体制を確保できるか」という観点で委託形態を選ぶ戦略へシフトしていると分析されています。ニアショア、つまり国内地方都市への委託には、言語や商習慣が共通しているという利点がある一方で、地方でも人材不足が進んでおり、体制構築に数ヶ月待ちとなるケースがあると指摘されています。オフショア、ニアショア、国内開発のいずれを選ぶにしても、コストだけでなく体制の確保しやすさを比較軸に含めることが実務的です。

生成AIによる開発効率化の現在地

日本では生成AIの活用企業が全体の55.2パーセントに達しているとの調査がありますが、多くは試験導入や部分的な効率化にとどまっているのが実情です。2026年は、生成AIをPoC(概念実証)から限定的な本番運用へ進める企業と、様子見を続ける企業の差が開き始める年になるとされています。開発の現場では、要件定義からコーディング、テスト、運用保守まで、開発工程全体で生成AIの活用が始まっており、自然言語での指示からコードや設計書を自動生成する取り組みも進んでいます。SIerを選ぶ際には、こうした技術をどこまで実務に取り入れているかも、開発スピードや品質を左右する要素として質問しておく価値があります。

タイ・東南アジアで製造業がSIerを選ぶときの論点

システムインテグレーター製造業選定|失敗しない発注ガイド2026 - figure 3

日本国内でのSIer選定と、タイをはじめとするASEAN拠点での選定では、検討すべき論点が変わります。

現地特有の論点

論点具体的な内容
言語の壁日本人駐在員、タイ人管理者、現場オペレーターで必要な言語が異なる
現地SIerの実力差会社によって上流工程の経験値に大きな差があり、実績確認が必須
BOI(投資奨励制度)ソフトウェア開発事業でBOI認定を受ける場合、タイ国内での開発が要件になる点に留意
日本本社との連携締めのタイミングや品目コード体系の違いをどう吸収するか
データ活用の前提現場のデータ収集自体が未整備なことが多く、システム導入前の下地作りが必要

タイの製造現場では、そもそもデータ収集の基礎が整っていないケースが多く、システムを導入しても使われずに放置される事例が多いと、現地SIerのコラムで指摘されています。これは日本国内以上に、要件定義の前段階で現場の実態を丁寧に確認する重要性が高いことを意味します。

言語の壁は、単純な翻訳の問題にとどまりません。日本本社への報告や要件の最終確認は日本語で行いたい一方、現地の管理者層とはタイ語または英語でのやり取りが中心になり、現場のオペレーターへの操作教育はさらに平易なタイ語での説明が必要になります。同じシステムについて3つの言語層で正確に意思疎通できる体制がなければ、どこかの層で認識のズレが生まれ、稼働後に「聞いていた仕様と違う」という声が現場から上がることになります。SIer選定の段階で、誰がどの言語でコミュニケーションの窓口になるのかを具体的に確認しておくことをおすすめします。

BOIと産業政策の動き

タイの製造業は労働力不足と賃金上昇を背景に、付加価値の高い事業構造への転換が急務とされており、JETROバンコクも日系製造業のDX推進と現地事業拡大を支援しています。BOI(タイ投資委員会)の投資奨励制度は、2025年から2026年にかけてEEC政策やEV産業振興と連携する形で拡充が進んでおり、AI活用システム開発やクラウドサービスもBOIの対象業種に含まれています。ただし、ソフトウェア開発事業としてBOI認定を受ける場合はタイ国内での開発が要件となる点には注意が必要です。国内開発を前提とするBOI活用を検討している企業にとって、現地に開発体制を持つSIerかどうかは選定上の重要な分岐点になります。

現地開発というコスト最適化の選択肢

日本の開発会社に発注し日本の単価で開発する方法もあれば、現地に開発拠点を持つパートナーに依頼する方法もあります。後者は人件費構造の違いからコストを抑えやすく、現地の商習慣や法制度に沿った実装がしやすいという利点があります。一方で、現地企業に直接発注する場合の最大の障壁は、日本語での要件定義と、日系製造業特有の商慣習の理解です。内示と確定注文の扱い、有償支給と無償支給の区別、検収のタイミングといった暗黙の前提は、仕様書だけでは伝わりきりません。

そのため実務上は、日本語で要件を詰められ、かつ現地に開発体制を持つパートナーを選ぶのが最も無理のない形になります。TOMAS TECHはバンコクを拠点に、日系製造業向けにPEGASUS生産・エネルギー管理システムを提供しており、日本語での要件定義から現地での開発・保守までを一貫して担える体制を取っています。

よくある質問

システムインテグレーターとは?

企業のシステム開発を要件定義から設計、開発、導入、保守まで一貫して請け負う事業者のことです。元請けとして案件全体を統括する会社もあれば、専業ベンダー、コンサル系、オフショア/ニアショア開発会社など、得意領域や体制が異なるさまざまなタイプが存在します。製造業の場合は、生産管理や設備連携に関する業界知見の有無が、選定における重要な分かれ目になります。

SIerの選び方は?

業界知見と実績、コミュニケーション体制、保守体制、契約形態の4点を軸に確認してください。特に製造業では、生産管理特有の独自ロジックや設備との接点を理解しているかどうかが成否を分けます。1社だけの提案で判断せず、RFPを用いて複数社を同じ条件で比較することが、失敗を避ける最も確実な方法です。

費用はどれくらいかかりますか?

システムインテグレーターへの発注費用は、対象範囲やカスタマイズの量によって大きく変わります。生産管理単体か、基幹システム全体まで含むかによっても水準は異なります。概算を早く知りたい場合は、対象業務の範囲、想定利用人数、連携したい既存システムの3点を整理してRFPに落とし込むと、精度の高い見積もりを複数社から得やすくなります。契約形態が請負か準委任かによっても支払いのタイミングや総額の見え方が変わるため、金額の比較は前提条件をそろえたうえで行ってください。

失敗しないためにはどうすればよいですか?

前章で触れた成功パターンの3要素に加えて、契約の前段階でできることが2つあります。1つは、RFPの段階で複数社を同じ条件で比較し、価格だけでなく体制やコミュニケーション力も含めて評価すること。もう1つは、マスタデータの整理や現場の課題の言語化など、発注側自身が準備できる作業を早めに始めておくことです。SIerに任せきりにできる部分と、自社でしか進められない部分を切り分けておくと、後戻りできない失敗を防ぎやすくなります。

まとめ

システムインテグレーター選びで押さえるべき点を整理します。

  • SIerには元請け、専業ベンダー、コンサル系、オフショア/ニアショアの4タイプがあり、自社が求めるものに応じて向き不向きが変わる。
  • 製造業のシステム開発は、コスト超過・納期遅延・使われないシステムという失敗パターンが起きやすく、業界知見のあるベンダー選びが成否を左右する。
  • 選定基準は、業界知見、実績、コミュニケーション体制、保守体制、契約形態の5つの視点で確認する。
  • RFPと要件定義は役割が異なる。RFPで複数社を比較し、選定後に要件定義で詳細を詰める順序を守る。
  • 2026年は生成AIの実務活用とオフショア/ニアショアの体制最適化が同時に進む年であり、SIer選びの評価軸にも影響する。
  • タイ・ASEAN拠点では、言語の壁、現地SIerの実力差、BOIの要件、日本本社との連携という論点が加わる。

最も避けたいのは、相場観や比較の物差しを持たないまま1社だけに相談し、提示された提案が妥当かどうか判断できないまま契約してしまうことです。本記事の整理を、その判断の出発点として使ってください。

システムインテグレーター選びの方針がまだ固まっていない段階でも構いません。TOMAS TECHはタイ・バンコクを拠点に、日系製造業向けのシステム開発と現地での保守を手がけています。現状の課題整理や進め方のご相談だけでも承っていますので、検討段階の方はお問い合わせフォームからお気軽にご連絡ください。

参考情報