生産管理システム導入の流れ2026｜9フェーズ実務ガイド

タイやベトナムの現地工場で生産管理システム導入を具体的に検討し始めると、最初にぶつかるのは「何から手をつければよいのか」という問いです。製品比較も費用相場もひととおり調べた。それでも、要件定義からベンダー選定、Fit&Gap分析、テスト、データ移行、本稼働までが実際にどう進み、自社の誰がいつ何をするのかは見えてきません。本記事はこのプロセス全体を9つのフェーズに分け、各段階の作業内容と関係者、つまずきどころを実務目線で解説します。あわせて、日本人SEの出張ビザ、12月の決算繁忙期、現地SIerの日本語対応体制といった、ASEAN拠点に固有の論点も扱います。

生産管理システムの導入とは何か、なぜ今検討されているのか

生産管理システムの導入は、多くの現場で「ソフトウェアを買って入れること」と受け止められています。しかし実務上は、業務の流れを一度言語化し直し、標準化できるところを標準化し、システムに合わせて仕事のやり方そのものを再設計する取り組みです。買う対象はソフトウェアですが、変わるのは人と情報の動き方です。この理解のずれが、後半で触れる失敗の多くの出発点になっています。

検討が増えている背景

日本国内の中小企業を対象にした調査では、DXに「既に取り組んでいる」または「取組みを検討している」と答えた企業は39.1%でした。2025年12月5日から18日にかけて全国の中小企業1,000社を対象に実施され、2026年2月に公開されたもので、前回の2024年12月調査とほぼ横ばいの水準です。一方でAI活用は28.4%と、前回比で14.1ポイント伸びています。全体としてのDX着手率は足踏みしているのに、個別技術の利用は急速に立ち上がっている、という構図が読み取れます。

製造業に絞ると、もう少し厳しい数字が出てきます。2026年5月に第221回国会へ提出されたものづくり白書2026では、デジタル技術の活用戦略を「策定しておらず予定もない」と答えた中小企業が55%に上りました。共通する課題として挙げられたのは、デジタル技術に関する知識・ノウハウの不足がおよそ46%から58%、人材不足がおよそ47%から58%です。設備投資の是非以前に、社内に設計できる人がいないという状態が広く共有されています。

海外拠点では、この制約がさらに強く効きます。日本本社の情報システム部門は現地の業務を細かくは知らず、現地には専任のIT担当が一人もいない、あるいは兼務が一人だけ、という体制は珍しくありません。だからこそ、プロジェクトの進め方をあらかじめ型として持っておくことの価値が大きくなります。

「システム選び」で終わらせないための前提

生産管理システムの導入は、大きく2つの段階に分けて整理できます。ひとつは導入前の段階で、パッケージをそのまま使うのか、カスタマイズを加えるのか、フルスクラッチで作るのかという方式の決定までを指します。もうひとつは導入実行の段階で、Fit&Gap分析からマスタデータの整備、設定・カスタマイズ・テストを経て本番運用と移行に至るまでを指します。

この2段階のうち、社内の関心はほとんどが前半の「どれを選ぶか」に集まります。しかし工数と失敗リスクの大半は後半にあります。本記事が9つのフェーズに細かく割って解説するのは、後半で何が起きるのかを先に知っておくと、前半の選択基準そのものが変わるからです。製品の機能一覧を眺めるより、Fit&Gap分析で自社に何個のギャップが出そうかを想像したほうが、選定の精度は上がります。

なお、どの製品カテゴリを選ぶかという比較の観点そのものについては、タイで導入できる生産管理システムの比較と選び方で個別に扱っています。本記事はその先、選定を含む導入プロセス全体をどう回すかに焦点を当てます。

生産管理システム 導入の流れ｜9フェーズの全体像

まず全体像を示します。呼び方はベンダーによって多少異なりますが、実務上は次の9フェーズに整理すると、社内説明でもベンダーとの会話でも齟齬が起きにくくなります。

この9フェーズは一直線に進むように見えますが、実際にはフェーズ4のFit&Gap分析で要件定義の抜けが見つかり、フェーズ1に部分的に戻るということが必ず起こります。戻ること自体は失敗ではありません。問題は、戻るべきときに戻らず、曖昧なまま先へ進めてしまうことです。

期間について補足します。全フェーズの標準所要期間を示した信頼できる統計は、少なくとも公開情報の中では見当たりません。ベンダーの提示する目安も、対象範囲と業務の複雑さによって大きく変わります。したがって本記事では断定的な月数は示しませんが、要件定義だけでも3ヶ月程度は必要になるケースが多いとされる、という程度の幅を持った理解にとどめておくのが安全です。工程表の組み方については生産管理システムの導入期間とスケジュールの立て方で個別に整理しています。

各フェーズの実務解説

ここからは、9つのフェーズを順に見ていきます。特にフェーズ4のFit&Gap分析は、後述する失敗要因の統計とも直結する山場なので、厚めに解説します。

フェーズ1 要件定義で何を決めるのか

要件定義は、システムに何をさせたいかを決める工程だと理解されがちですが、実際に時間を使うのは現状の可視化です。受注情報がどの帳票でどこへ渡り、誰が何を判断して、どこで手書きのメモに置き換わっているのか。この経路をひとつずつ辿ると、社内の誰も全体を把握していなかったという事実が出てきます。

要件定義書は、クライアントと開発者のあいだの認識のずれを防ぐための成果物として位置づけられます。つまり、書く目的は網羅性ではなく合意です。分厚い文書を作っても、業務部門が読んでいなければ役割を果たしません。

実務的には、次の順で進めると詰まりにくくなります。

• 対象とする業務範囲を最初に線引きする。受注から出荷までなのか、原価計算まで含むのか、購買と在庫はどこまで入れるのか。
• 部門ごとに現行フローをヒアリングし、そのまま図に落とす。理想の姿ではなく、いま実際にやっていることを書く。
• 課題を「困っていること」の粒度で列挙し、そのうちシステムで解決するもの、運用ルールで解決するもの、今回は扱わないものに仕分ける。
• 他システムとの連携要件、必要な帳票、将来の拡張余地を洗い出す。ここを後回しにすると、フェーズ4で大きな手戻りになります。

海外拠点で特に注意したいのは、日本本社への報告フォーマットです。現地の業務としては不要でも、本社が求める原価の切り方や進捗報告の粒度が決まっているなら、それは要件です。本社の要求を要件定義の最後に足すと、設計をやり直すことになります。

フェーズ2 ベンダー選定とRFPの使い方

要件がある程度まとまったら、ベンダーに提案を依頼します。ここでRFPを作らずに口頭とメールだけで進めると、提案の粒度がベンダーごとにばらばらになり、比較そのものができなくなります。RFPの具体的な書き方は生産管理システムのRFPの書き方と記載項目にまとめています。

ASEAN拠点での選定では、機能一覧の比較よりも体制と対応言語の確認が効きます。確認すべき項目を整理すると次のようになります。

このうち最初の行が、後で最も効いてきます。理由は「タイ特有の注意点」の節で詳しく述べますが、日本語で要件を引き出せる人員は現地SIerでも限られた資源であり、その配分は契約前に握っておく必要があります。

フェーズ3 契約で曖昧にしてはいけないところ

契約段階で決めておくべきは、金額よりもむしろ範囲と責任の分界です。特に次の3点は、後の紛争の火種になりやすい箇所です。

ひとつめは、カスタマイズの扱いです。Fit&Gap分析の結果として発生するアドオン開発が、契約金額に含まれるのか、別見積もりになるのか。含まれるとしても何人日分までか。この線引きがないと、フェーズ4以降で費用の話が延々と続きます。

ふたつめは、データ移行の責任範囲です。移行元データの整備、つまり品番の重複や取引先マスタの表記ゆれを直す作業は、通常は発注側の責任です。ここをベンダー任せにできると誤解していると、フェーズ7で止まります。

みっつめは、検収の条件です。何をもって完了とするのか。UATの合格基準を契約時に文章化しておくと、フェーズ6で「これは仕様です」「いや不具合です」という不毛な議論を減らせます。

費用の全体像とTCOの考え方は生産管理システムの導入費用とTCOの内訳で別途扱っています。

フェーズ4 Fit&Gap分析の具体的な進め方

導入実行フェーズの中核がFit&Gap分析です。パッケージの標準機能で対応できる業務(Fit)と、対応できない業務(Gap)を洗い出し、Gapごとに対応方針を決める工程を指します。

進め方は、おおむね次の4段階になります。

第1段階は、対象業務の範囲と優先順位を明確にすることです。全業務を同じ熱量で分析しようとすると、期間内に終わりません。売上や品質に直結する基幹の流れから着手し、月次で数件しか発生しない例外処理は後回しにするか、今回の対象外と明示します。

第2段階は、各部門へのヒアリングです。現行の業務フローと課題を整理し、それを標準機能の画面に当てながら「この操作で回るか」を確認していきます。ここで重要なのは、業務部門の担当者に実際の画面を触ってもらうことです。資料を見せて説明するだけでは、Gapは見つかりません。

第3段階は、仕様の決定です。他システムとの連携、必要な帳票、将来の拡張性を考慮しながら、標準機能のどの設定を使うかを固めます。帳票は特に見落とされがちで、現場が日常的に印刷している紙の一覧が標準機能に無い、という形でGapが顕在化します。

第4段階が、Gapへの対応方針の決定です。ここには3つの選択肢があります。

実務では、この3つを機械的に選ぶのではなく、Gap一覧に「業務上の必然性」と「代替手段の有無」を書き添えたうえで一件ずつ判定していきます。判定は業務部門が行い、ベンダーは選択肢と工数の見積もりを提示する役割に徹する、という分担にすると議論が進みます。

ここで陥りやすいのが、アドオン開発への安易な傾斜です。現場の要望をすべて拾うと、Gap一覧の大半がアドオンになります。そうなると費用も期間も膨らみ、さらにパッケージのバージョンアップのたびに改修が必要な資産を抱え込むことになります。逆に、すべてをBPRで押し切ろうとすると現場が動かず、稼働後に誰も使わないシステムが残ります。

判断の目安として、次のような問いを一件ごとに立てるのが有効です。この業務のやり方は、顧客が当社を選ぶ理由と関係があるか。関係がないなら、標準機能に合わせる余地があります。関係があるなら、そこは投資すべきGapです。

タイの拠点では、これに現地固有の観点が加わります。現地の税務要件や取引先が求める帳票様式は、運用対処やBPRで回避できない性質のGapです。これらは早い段階で「必須のアドオン」として切り出し、残りの検討から分離しておくと、議論が整理されます。

フェーズ5 開発・カスタマイズ期間に発注側がやること

このフェーズは、ベンダーが手を動かす期間です。発注側は待っているだけになりがちですが、実際にはやるべきことがあります。

ひとつは、フェーズ7のデータ移行に向けたマスタ整備の着手です。品目マスタ、取引先マスタ、工程マスタの重複と表記ゆれを潰す作業は、時間がかかるうえに現場の判断が必要で、外注できません。開発期間中に並行して進めておかないと、移行の直前に詰みます。

もうひとつは、テスト計画の準備です。次のフェーズで業務部門がUATを行うことになりますが、その時点でテストケースを作り始めると間に合いません。開発期間中に、業務部門が自分たちの言葉で「こういう受注が来たら、こう処理されるはず」というシナリオを書き出しておきます。

三つめは、仕様変更の抑制です。開発が始まってからの仕様変更は、後述する統計でもスケジュール超過の最大要因として挙げられています。変更の要否を判定する場を週次で設け、そこを通らない変更は受け付けないという運用にしておくと、進行が安定します。

フェーズ6 テストとUATをどう設計するか

テストは、ベンダーが行う単体テストと結合テスト、そして発注側が行う受入テスト(UAT)に分かれます。プロジェクトの成否を分けるのはUATのほうです。

UATで避けたいのは、きれいなサンプルデータだけで確認してしまうことです。実際の業務では、途中で数量が変わる注文、締め日をまたぐ返品、単位の異なる在庫、といった例外が日常的に発生します。これらをテストケースに含めておかないと、稼働後1週間で「このパターンが処理できない」という報告が上がってきます。

テストケースを作るときは、次の観点で並べると漏れが減ります。

• 通常の流れを最初から最後まで通す基本シナリオ
• 途中で変更・取消が入るシナリオ
• 数量ゼロ、締め日当日、最大桁数といった境界値
• 他システムへ連携するデータの中身が正しいかの確認
• 権限の異なる利用者でログインしたときの見え方

UATの合格判定は、検出した不具合の件数ではなく、業務が最初から最後まで止まらずに流れたかどうかで行います。不具合が残っていても、回避策があり業務が回るなら稼働できます。逆に、不具合がゼロでも業務が流れないなら稼働してはいけません。

フェーズ7 データ移行とマスタ整備

データ移行は、技術的には単純な作業でありながら、最も現場負荷が高いフェーズです。理由は、移行対象データの品質が発注側の責任範囲にあるからです。

作業は、移行対象の決定から始まります。過去何年分の実績を持っていくのか。在庫は移行するのか、棚卸しで作り直すのか。仕掛品の扱いはどうするのか。これらは業務部門しか判断できません。

続いてマスタの整備です。同じ部品に複数の品番が振られている、取引先名が全角と半角で混在している、といった状態を放置したまま移行すると、新システムの中に同じ問題が再生産されます。移行はデータをきれいにする最後の機会でもあるので、ここに工数を割く価値があります。

そして移行リハーサルです。本番と同じ手順で実際に移行を実行し、所要時間と結果を検証します。1回のリハーサルで終わらせず、最低でも2回は行い、2回目は本番と同じ時間帯・同じ体制で実施すると、当日の想定外が減ります。

フェーズ8 本稼働(カットオーバー)の判断

カットオーバーは、事前に決めた判定基準に照らして、稼働するかしないかを経営が判断する場です。「もう日程を決めてしまったから」という理由で進めるのが最も危険です。

判定に使う基準は、遅くともUAT開始前に文章化しておきます。典型的には、UATの必須シナリオがすべて通過していること、未解決の重大不具合がゼロであること、移行リハーサルが成功していること、利用者教育が完了していること、そして稼働直後の問い合わせ対応体制が確保されていること、といった項目になります。

切替方式は、一斉切替と並行稼働のどちらかです。並行稼働は安全ですが、現場は2つのシステムに同じ入力を行うことになり、負荷が倍になります。期間を限定し、いつ旧システムを止めるかを最初に決めておかないと、並行状態が半年続くという事態になります。

フェーズ9 定着化と効果測定

稼働は終わりではなく、開始点です。定着化のフェーズでやることは3つあります。

第1に、運用ルールの明文化です。誰がいつ入力するのか、実績はどのタイミングで登録するのか。これが曖昧だと、システムには入っているが実態と合っていないというデータが積み上がります。

第2に、教育の継続です。稼働前の集合研修だけでは、例外処理の対応方法は身につきません。稼働後1ヶ月、3ヶ月のタイミングで、実際に起きた事例をもとにした振り返りの場を設けると、運用の質が上がります。

第3に、効果測定です。要件定義の段階で設定した課題が、実際に解消したかを数字で確認します。ここを行わないと、次の投資判断の材料が残りません。

タイ特有の注意点｜スケジュール設計に効く3つの論点

ここまでは国内外を問わず共通する話です。ここからは、タイをはじめとするASEAN拠点で導入する場合に、日本国内の進め方をそのまま持ち込むと破綻する論点を扱います。

日本人SEの短期出張とビザ・就労許可の制約

日本の本社やベンダーから日本人SEを送り込んで要件定義や設置作業を行う、という段取りは自然に見えますが、タイの入国管理と就労許可の制度上、そのまま実行できない場合があります。

制度の概要を整理すると、次のようになります。日本を含むビザ免除対象国の一般旅券所持者は、観光や商談、視察といった目的であれば、一定期間の滞在についてビザなしで入国できる枠組みがあります。さらに2024年7月15日以降は、日本を含む93のビザ免除対象国・地域の一般旅券所持者について、1回の入国につき15日以内の滞在であれば就労目的でも一定条件下でビザ免除の対象になりうる、という運用が示されています。

ただし重要なのは、タイ国内でのサービス提供、技術支援、設置作業、あるいはタイ企業への直接的な業務貢献が含まれる場合、それは「就労」とみなされるという点です。報酬を伴う技術指導や実働が発生する場合、また60日を超える滞在が必要な場合には、ノンイミグラントビザの取得が必須になります。加えて2025年からは、ビザ免除での入国者に対してもタイ電子入国承認(ETA)の事前申請が段階的に義務化されています。

この制度がプロジェクトに与える影響は、想像より大きいものです。

• 要件定義のヒアリングを日本人SEが現地で行う場合、滞在日数と業務内容によって必要な手続きが変わるため、日程を先に決めてしまうと手続きが間に合わない
• 開発フェーズの合間に「必要なときだけ短期で呼ぶ」という運用は、渡航手続きのリードタイムを織り込まないと成立しない
• 本稼働の立ち会いは最も長期の滞在になりやすく、就労許可を前提とした計画が必要になる

実務上の対処としては、現地に常駐する日本人SEを擁するベンダーを選ぶ、あるいは日本側SEの関与を設計レビューやオンラインでの支援に限定し、現地での実働は現地法人の要員が担う、という体制の切り分けが有効です。

なお、ここに記した制度内容は執筆時点で確認できた情報であり、入国管理や就労許可の運用は変更される可能性があります。実際の渡航計画を立てる際には、必ず最新の制度を大使館や専門家に確認してください。

12月の決算繁忙期とカットオーバー計画

タイでは12月決算の法人が多く、12月は会計事務所・監査法人ともに決算処理と監査業務が集中する繁忙期になります。この事実そのものは会計実務の解説で広く指摘されているところです。

ここから先は出典に直接書かれていることではなく、プロジェクト運営上の推論になりますが、実務上は12月を本稼働(カットオーバー)の時期として選ばないほうが安全だと考えられます。理由は次のとおりです。

カットオーバー直後は、新旧のデータが並存し、想定外の処理が続出する期間です。この時期には経理部門の判断を仰ぐ場面が頻繁に発生します。ところが12月は、その経理部門が決算対応で最も動けない時期にあたります。加えて監査対応が重なると、外部の会計事務所からの照会にも応じなければなりません。現場側も、年末の出荷集中と長期休暇前の駆け込み対応で余力が乏しくなります。

同じ理由から、決算月の直前直後、たとえば11月後半から翌年1月にかけての期間も、慎重に扱う価値があります。会計期間をまたぐ切替は、期首から新システムで開始できるという利点がある一方で、期末の締めと移行作業が重なるという難しさを併せ持ちます。どちらを取るかは、経理部門の体制と移行データの量によって判断が変わります。

実務的な進め方としては、要件定義の段階で経理部門にカレンダーを出してもらい、動けない期間を先に塗りつぶしたうえで、そこを避けてマイルストーンを引くことをおすすめします。スケジュールを先に引いてから経理に相談すると、たいてい引き直しになります。

現地SIerの日本人SE体制をどう確認するか

タイの現地SIerで日本語対応が可能な日本人SEの人数は、どの会社でも限られた資源です。ある現地ベンダーが公開している体制の一例では、バンコク常駐の日本人スタッフ7名とタイ人スタッフ40名という構成で日本語・タイ語の両方に対応するとされています。これは1社の例であって業界標準を示すものではありませんが、日本人要員が全体の一部にとどまるという構造自体は、多くの現地SIerに共通しています。

この構造が問題になるのは、要件定義のフェーズです。現場の担当者が日本語で語る業務のニュアンスを、そのまま設計に落とせるかどうかが、Fit&Gapの精度を左右します。通訳を介する場合、業務の言葉が一度抽象化され、細部が落ちます。「だいたいこうしている」「例外のときはこうする」といった、まさにGapの温床になる部分が最初に落ちます。

したがってベンダー選定では、次の3点を数字で確認することを推奨します。第1に、要件定義フェーズに日本人SEが何名、どの程度の稼働率で入るのか。第2に、その要員は提案フェーズの担当者と同一なのか。第3に、稼働後の保守で日本語の問い合わせに応じる体制は何名で、対応時間帯はいつか。

「日本語対応可能です」という回答は、ほぼすべてのベンダーから返ってきます。意味があるのは、その先の稼働率と人数です。

もうひとつ、体制の持続性という観点もあります。現地の労務動向の解説によれば、タイではITエンジニアやプログラマーの賃金が年8%から12%の水準で上昇しており、一般ワーカーの年3%から5%と比べて明確に高い伸びを示しています。月給のレンジも35,000バーツから80,000バーツと幅があり、人材の流動性が高い市場であることがうかがえます。長期の保守を前提にするなら、特定の個人に依存しない体制になっているかを確認しておく価値があります。

要件定義とテストに生成AIをどう使えるか

近年、要件定義工程に生成AIを取り入れる動きが出てきています。まだ確立された手法とは言いがたい段階ですが、可能性としては認識しておく価値があります。

紹介されている活用の形は、大きく2つです。ひとつは、生成AIを「対話型ヒアリング役」として使い、業務部門との対話から要件定義書のたたき台を生成させるという使い方です。業務部門は自分の仕事を語ることには慣れていても、それを要件の形に整理することには慣れていません。その変換を補助する役割として使う、という発想です。

もうひとつは、レビュー工程での活用です。チェックすべき観点をあらかじめ標準化しておき、生成AIに要件定義書を読ませて、記載の不足箇所や記述間の矛盾を抽出させるという使い方が示されています。人間のレビューでは見落としやすい、文書内の整合性の確認には相性が良いと考えられます。

一方で、課題も明確に指摘されています。生成AIの出力には不確実性があり、そのまま採用すると開発者の想定と現場の実際のニーズとのあいだにずれが生じうる、という点です。生成された要件定義書は、あくまで下書きです。業務部門による確認と、実際の画面を使った検証を省略できるものではありません。

テスト工程については、テストケースの生成に使うという方向が考えられます。要件定義書や設計書をもとに、想定される入力の組み合わせを列挙させ、人間が業務知識で取捨選択するという分担です。ただしこれも、生成された網羅的なリストが自社の業務における重要度を反映しているとは限らないため、優先順位づけは人が行う必要があります。

現時点での位置づけとしては、要件定義やテストの「たたき台を早く作るための道具」であり、判断そのものを代替するものではない、と捉えるのが妥当でしょう。

よくある失敗とその防ぎ方

導入プロジェクトが期待どおりに終わらないことは、決して珍しくありません。日経コンピュータが10年ぶりに実施し、2018年2月27日に報じられたITプロジェクト実態調査2018では、1,745件のシステム導入・刷新プロジェクトのうち47.2%が「失敗」と判定されました。半数近くが期待した結果に至っていないという数字です。

この調査が示した内訳は、これまで述べてきたフェーズ構成と正確に対応しています。

満足度が得られなかった理由の筆頭が「要件定義が不十分」であるという点は、本記事がフェーズ1とフェーズ4を厚く扱った理由そのものです。コスト超過の筆頭が「追加の開発作業が発生」であることは、Fit&Gap分析でのアドオン判定が費用の主因であることを裏づけます。スケジュール超過の筆頭が「システムの仕様変更が相次いだ」であることは、開発フェーズに入ってからの変更管理の重要性を示しています。

同調査では、もうひとつ重要な指摘がなされています。経営者や業務部門がITベンダーに任せきりにしている企業は、プロジェクトを成功させにくいという点です。業務に責任を持つ人がプロジェクトに参画し、要件を取りまとめ、進行を見守ることが必要だとされています。

補足のデータとして、企業IT動向調査報告書2021を紹介した記事では、プロジェクトの規模によって67%から85%がスケジュール遅延、60%から85%が予算超過というデータが示されています。規模の違いによって幅はあるものの、いずれの水準でも過半のプロジェクトが遅延と予算超過を経験しているという点は、計画時に見込んでおくべき前提です。

これらを踏まえた防ぎ方を、フェーズごとに整理すると次のようになります。

• 要件定義に業務部門の責任者を必ず参画させる。情報システム担当者だけで進めると、現場が知らない要件が出来上がります。
• 対象範囲を最初から広げすぎない。全工場・全業務を一度に対象にすると、要件の量も関係者の数も一気に増え、要件定義の質を保ちにくくなります。1拠点1業務から始めて横展開する進め方は、この負荷を分散させる現実的な選択肢です。
• Fit&Gap分析の結果を、費用と期間に換算してから対応方針を決める。アドオン件数の一覧だけでは判断できません。
• 開発開始後の仕様変更に、承認の手続きを設ける。変更を禁止するのではなく、可視化することが目的です。
• 稼働判定の基準を、UAT開始前に文章にしておく。

失敗要因のより詳細な分析と、実際に起きた典型パターンについては生産管理システム導入が失敗する原因と対策で個別に扱っています。

よくある質問

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

対象範囲と業務の複雑さによって大きく変わるため、一律の目安を示すのは困難です。フェーズごとの標準期間を示した信頼できる統計も、公開情報の中では確認できていません。ただし要件定義だけでも3ヶ月程度は必要になるケースが多いとされており、そこからベンダー選定、設計、開発、テスト、移行と続くことを考えると、相応の期間を見込んでおく必要があります。ベンダーから短い期間を提示された場合は、その期間に何が含まれ、何が含まれていないかを確認してください。要件定義を発注側で完了している前提の見積もりであることは珍しくありません。

導入の第一歩は何から始めればよいですか

製品資料を集めることではなく、現状業務の可視化から始めてください。受注から出荷までの情報の流れを、部門ごとに書き出す作業です。この段階で、社内の誰も全体像を把握していなかったという事実が判明することがよくあります。可視化した現状に対して、どこが困っているのかを列挙し、そのうちシステムで解決すべきものを選別する。ここまでを社内で行っておくと、ベンダーとの会話の質が大きく変わります。

パッケージのカスタマイズはどこまで許容すべきですか

一件ごとに、その業務のやり方が自社の競争力と関係しているかを問うのが実務的な判断基準です。関係が薄いものは標準機能に合わせる余地があり、関係が強いものは投資すべきGapです。ただしタイの拠点では、現地の税務要件や取引先が求める帳票様式のように、運用では回避できないGapが存在します。これらは早い段階で必須のアドオンとして切り出し、任意のカスタマイズ検討とは分けて扱うと整理しやすくなります。カスタマイズを増やすほど、将来のバージョンアップ時の改修負荷が積み上がる点も判断材料に含めてください。

本稼働の時期はいつを選ぶべきですか

タイでは12月決算の法人が多く、12月は会計事務所・監査法人ともに決算処理と監査が集中する繁忙期になります。カットオーバー直後は経理部門の判断を仰ぐ場面が頻発するため、実務上は12月を本稼働の時期として選ばないほうが安全だと考えられます。決算月の前後も同様に慎重に扱う価値があります。要件定義の段階で経理部門から動けない期間を先に聞き出し、そこを避けてマイルストーンを引くのが現実的です。

日本から自社のSEを出張させて導入作業を行えますか

滞在日数と業務内容によって、必要な手続きが変わります。視察や商談であればビザ免除の枠組みで入国できる場合がありますが、タイ国内での技術支援や設置作業、タイ企業への直接的な業務貢献は「就労」とみなされます。報酬を伴う実働が発生する場合や60日を超える滞在が必要な場合には、ノンイミグラントビザの取得が必須になります。2025年からはビザ免除入国者に対してもタイ電子入国承認(ETA)の事前申請が段階的に義務化されています。制度は変更されうるため、渡航計画を立てる前に最新の運用を確認してください。日程を先に確定させると手続きが間に合わなくなるおそれがあります。

社内にIT担当者がいなくても導入できますか

可能ですが、業務側の責任者が要件定義とFit&Gap分析に主体的に関わることが前提になります。日経コンピュータの調査でも、経営者や業務部門がITベンダーに任せきりの企業はプロジェクトを成功させにくいと指摘されています。技術的な部分はベンダーに委ねられますが、「自社の業務がどうあるべきか」という判断は外注できません。IT担当者の不在を補うのは、業務を最もよく知る人の参画です。

まとめ

生産管理システムの導入は、要件定義、ベンダー選定、契約、設計とFit&Gap分析、開発・カスタマイズ、テストとUAT、データ移行、本稼働、定着化という9つのフェーズで進みます。工数と関心が集まりやすいのは製品選定ですが、失敗の統計が示しているのは、満足度を左右するのが要件定義の質であり、費用を左右するのがFit&Gap分析でのアドオン判定であり、期間を左右するのが開発開始後の仕様変更だという事実です。

そしてASEAN拠点では、これに3つの制約が加わります。日本人SEの渡航には入国管理と就労許可の制度が関わるため、日程を先に決めることができないこと。12月が決算繁忙期にあたるため、カットオーバーの時期は経理部門のカレンダーから逆算して決めるのが安全だと考えられること。現地SIerの日本語対応要員は限られた資源であり、要件定義への関与度は契約前に数字で確認すべきこと。この3点は、日本国内の進め方をそのまま持ち込んだプロジェクトが、必ずと言ってよいほどつまずく箇所です。

逆に言えば、この9フェーズの流れと3つの制約を最初に理解しておけば、プロジェクトの見通しは大きく改善します。最初の一歩は、製品資料を集めることではなく、自社の現状業務を書き出すことです。

TOMAS TECHは、バンコクを拠点に、タイをはじめとするASEANの日系製造業向けに生産管理システムPEGASUSの導入支援を行っています。要件定義の進め方、Fit&Gap分析でどこまでを標準機能で吸収できるか、日本人SEの関与体制やカットオーバー時期の設計といった論点は、製品を決める前の検討段階でこそ整理しておく価値があります。まだ導入するかどうかを判断していない段階でも、現状の課題を伺いながら進め方を一緒に考えることは可能です。ご相談はお問い合わせフォームからお気軽にどうぞ。

参考情報

• 生産管理システム導入の流れ｜キッセイコムテック
• ITプロジェクト実態調査2018｜日経クロステック
• 企業IT動向調査報告書2021の紹介記事｜Promapedia
• タイ出張でビザは必要か｜BORDER
• タイのERP・販売管理・生産管理システム｜SMRI
• タイの会計の決算時期について｜東京コンサルティンググループ
• 生成AIを活用した要件定義書作成・レビュー高度化のポイント｜KPMGジャパン
• 中小企業のDXに関する調査結果｜創業手帳
• 2026年版ものづくり白書 5分で掴む最重要ポイント｜テクノア
• ものづくり白書2026を読み解く｜BrainPad DOORS
• 2026年最新版タイ労務・タイ労務管理の最新動向｜東京コンサルティンググループ