タイの工場で「現場の紙をアプリにしたい」という話が出たとき、最初にぶつかるのは技術ではなく線引きです。ノーコードで自分たちで作るのか、外に頼むのか。実際にはこの二択ではなく、業務アプリ開発を層に分けて「どの部分を、誰が、どのくらいの寿命で持つか」を決める作業になります。この記事では工場のアプリを4つの層に分解し、費用の読み方、タイ特有の前提、失敗パターン、90日で1本目を出す進め方までを、自分の工場に当てはめて判断できる形で整理します。
業務アプリ開発とは｜工場で作るアプリを4層に分けて考える
工場の業務アプリは、外から見ると「タブレットで入力する画面」に見えます。しかし中身は性質のまったく違う4つの層が積み重なってできています。この層を意識せずに「アプリを作る」と言ってしまうと、内製と外注の議論が噛み合わなくなります。
入力UI層｜作業者が触る画面
作業者が実際に触る部分です。日報、点検、不良報告、入出庫、設備の始業前チェックなど、指の動きと現場のレイアウトに直結します。ここは変更が最も多く、寿命が最も短い層です。ラインの組み替え、製品切り替え、監査対応で四半期ごとに変わることも珍しくありません。逆に言えば、多少作りが荒くても作り直せる層でもあります。
業務ルール層｜判定と分岐のロジック
「この値を超えたら管理者へ通知」「この不良コードなら再検査へ回す」「ロット番号はこの規則で採番する」といった判定です。画面より寿命が長く、間違えると品質記録そのものが壊れる層です。ここは誰が作ったか、なぜその条件なのかが後から追える状態でなければなりません。
データ基盤層｜蓄積と再利用の土台
マスタ（製品、工程、設備、作業者）、履歴テーブル、権限、バックアップ、保存期間。ここは一度決めると数年単位で使い続けます。後から直すコストが最も高い層であり、ここを軽く作るとアプリを増やすたびに同じマスタを二重管理することになります。
基幹連携層｜ERPや生産管理システムとのつなぎ
会計、在庫、購買、受注といった基幹側との受け渡しです。連携の失敗は数字の不一致として経理や本社に出るため、影響範囲が社外にまで及びます。ここは仕様書、テスト、障害時の復旧手順まで含めて成果物として残す必要があります。基幹システム側の作り込みや費用については、業務システム開発の費用と進め方も合わせて確認してください。
4層で見ると意思決定が単純になる
この4層に分けると、判断の原則はひとつに集約されます。上の層ほど内製・ノーコードが向き、下の層ほど受託開発とドキュメントが要る。入力UIは現場に近い人が作ったほうが速くて使いやすく、データ基盤と基幹連携は設計者が変わっても引き継げる形で残す必要がある。この非対称性が、あとに出てくるすべての判断の土台になります。
| 層 | 変更頻度 | 想定寿命 | 向いている作り方 | 必須の成果物 |
|---|---|---|---|---|
| 入力UI層 | 高い | 数か月〜1年 | 内製・ノーコード | 画面一覧と操作手順 |
| 業務ルール層 | 中 | 1〜3年 | 内製＋外部レビュー | ルール定義書と変更履歴 |
| データ基盤層 | 低い | 3〜7年 | 受託開発 | ER図・マスタ定義・権限表 |
| 基幹連携層 | 低い | 3〜7年 | 受託開発 | IF仕様書・テスト仕様・復旧手順 |
内製・ノーコード・受託開発｜3つの作り方の境界線
作り方は大きく3つあります。どれが優れているかではなく、どの層に当てるかで正解が変わるという理解が出発点です。
ノーコード・ローコードが強い場所
ノーコードやローコードは、入力UI層と軽い業務ルール層で圧倒的に速いです。現場の担当者が「この項目も要る」と言ったその日に直せることの価値は、開発手法の議論より大きいことがあります。市場としても拡大が続いており、ITRが2026年2月5日に発表した調査では、国内のローコード／ノーコード開発市場の2024年度売上金額は994億円、2025年度は前年度比14.9%増の見込み、2024〜2029年度のCAGRは12.9%と予測されています（国内22ベンダーへの調査に基づく数値です）。世界市場の規模予測についてはさらに幅があり、調査会社によって同じ年の予測でも値が大きく異なるため、特定の1社の数字を根拠に投資判断をするのは避けたほうが安全です。
一方でノーコードには構造的な弱点があります。ロジックが画面の中に埋め込まれ、ドキュメントとして外に出ないことです。作った本人が説明できるうちは問題になりませんが、日本人駐在員の帰任やタイ人IT担当の転職で、その説明能力ごと失われます。
受託開発が要る場所
受託開発が必要になる境界は、次のどれかに触れたときです。
- 会計・在庫・原価など、社外や本社に出る数字に影響する
- 品質記録・トレーサビリティとして監査や顧客監査で提示する
- 複数のアプリが同じマスタを共有する
- 設備やPLC、計測器からデータを直接取る
- 停止したときに生産が止まる、または出荷判定ができなくなる
この5つのどれかに当たるなら、動くものだけでなく仕様書とテスト結果と復旧手順を成果物として買うべき領域です。逆にどれにも当たらないなら、まず内製で作って現場で回してみるほうが速く、安く済みます。
パッケージソフト導入支援という第三の選択肢
自作でも受託開発でもなく、既存パッケージを入れて自社の運用に合わせ込む形もあります。会計、勤怠、在庫のように業務が標準化されている領域はパッケージが強く、パッケージソフト導入支援の役割は「機能を作ること」ではなく「自社の業務をパッケージが想定する形に寄せること」になります。逆に、現場の検査手順や自社独自の工程管理のように他社と同じにする理由がない業務にパッケージを当てると、カスタマイズ費用が受託開発を超えることがあります。
3つの比較
以下の期間は当社が実際に案件を進めるときの目安であり、業界の標準値ではありません。対象範囲と連携先の数で大きく振れます。
| 観点 | 内製ノーコード | 受託開発 | パッケージ導入支援 |
|---|---|---|---|
| 立ち上がりの速さ | 数日〜数週間 | 2〜6か月 | 1〜4か月 |
| 変更の速さ | 即日〜数日 | 見積と工程が要る | 設定範囲なら速い |
| 引き継ぎやすさ | 弱い | 強い（文書次第） | 強い |
| 独自業務への適合 | 高い | 高い | 低い |
| コストの出方 | 人件費に埋もれる | 見えやすい | ライセンスが継続 |
| 向く層 | 入力UI・軽いルール | データ基盤・基幹連携 | 標準化された業務全体 |
境界線の引き方を1文にすると
「壊れたときに誰が謝るか」で決めるのが実務的です。壊れても現場の中で吸収でき、担当者が自分で直せる範囲は内製。壊れると本社や顧客に説明が要る範囲は外注。この線は組織の責任範囲と一致するので、後から揉めにくくなります。
業務アプリ開発の費用｜見積を5層に分解する
費用を「アプリいくら」で見ると必ず外します。工場の業務アプリのコストは5つの層に分かれていて、それぞれ増え方の理屈が違うからです。以下の金額感は当社が実際に見積を出すときのレンジの例示であり、業界の標準単価ではありません。要件が変われば桁が変わります。
初期開発費｜画面数より「連携の本数」で決まる
初期費用を押し上げるのは画面の枚数ではなく、外とつながる本数です。単独で完結する入力アプリなら比較的軽く収まるケースが多い一方、ERPや既存の生産管理システムと双方向でつなぐと、テストと立ち会いの工数が跳ね上がります。連携先が1つ増えるごとに、開発だけでなくテスト・移行・障害時の手順が1セット増えると考えてください。
人月単価の感覚をつかむ材料として、タイのIT人材の給与水準が参考になります。JobsDBタイの2026年6月時点の掲載データでは、ソフトウェア開発者の平均月給はバンコクのその他エリアでTHB 37,500、サムットプラカン／サムットサコンでTHB 50,000、ソフトウェアエンジニアでTHB 42,000、ソフトウェアテストエンジニアでTHB 46,500、プログラムマネージャーでTHB 93,000となっています。これは求人掲載の平均値であり統計調査ではないため実勢とはずれますが、工業団地に近いエリアほど人件費が高いという傾向は見積を読むときの実感と合います。この給与に対して、間接費・管理費・保証期間の負担が乗ったものが人月単価になる、という順番で見ると見積の妥当性を判断しやすくなります。
改修費｜1年目にいちばん効いてくる
現場アプリは、稼働してから3か月が最も変更要求が出ます。ここを「追加見積」で都度処理すると社内の稟議が回らず、結局アプリが使われなくなります。初年度に初期開発費の2〜4割程度を改修枠として最初から予算化しておく進め方のほうが、結果的に総額は下がるケースが多いです。
運用・保守費｜監視・障害対応・アカウント管理
サーバやクラウドの費用だけでなく、作業者アカウントの追加削除、パスワードリセット、バックアップの確認、OSやアプリの更新追従が含まれます。工場は人の入れ替わりが多いため、アカウント運用の手間を誰が持つかを最初に決めていないと、IT担当1〜2名の工数が静かに溶けます。
端末費｜台数ではなく「共用か個人か」で変わる
タブレットやハンディの費用は、台数よりも運用形態で変わります。個人持ちなら破損対応は個人単位で済みますが、共用端末は充電・保管・消毒・故障時の予備機まで含めた運用設計が要ります。防塵防滴や落下耐性のある産業向け端末は、コンシューマ端末より本体価格が大きく上がるケースが多いのですが、現場で年に何台壊れるかを掛け算すると逆転することがあります。ここは実際の破損実績で判断するのが正解です。
回線・インフラ費｜工場の中でいちばん見落とされる
倉庫の奥、金属棚の間、屋外ヤード、めっき槽の周辺など、工場にはWi-Fiが届かない場所が必ずあります。アクセスポイントの追加、電源工事、配線ルートの確保は建屋の構造によって金額が大きく振れ、アプリ本体より高くつくことも珍しくありません。設計段階で電波の実測をしていない見積は、後から必ず増額されます。
5層まとめ
| 費用の層 | 主な中身 | 金額を決める要因 | 見落としやすい点 |
|---|---|---|---|
| 初期開発費 | 設計・実装・テスト | 連携本数、帳票の複雑さ | テストと立ち会いの工数 |
| 改修費 | 稼働後の変更 | 現場の変更頻度 | 予算化していないと止まる |
| 運用・保守費 | 監視・障害対応・アカウント | 拠点数、利用者数 | IT担当の実工数 |
| 端末費 | タブレット・ハンディ | 共用か個人か、耐環境性 | 予備機と充電運用 |
| 回線・インフラ費 | AP増設・配線・電源 | 建屋構造、電波環境 | 実測なしの見積は増額する |
タイ工場ならではの5つの前提
日本の工場向けの記事をそのまま持ち込むと必ず外れる部分があります。タイの日系工場では、次の5点を設計の前提に組み込む必要があります。
多言語UI｜タイ語とミャンマー語が混在する
作業者がタイ人だけとは限りません。ミャンマー、カンボジア、ラオス出身の作業者が同じラインにいる工場は普通にあります。ここで効くのは翻訳の網羅性より画面から文字を減らす設計です。色、アイコン、写真、数字だけで判断できる画面にしておけば、言語追加のたびに全画面を翻訳し直す必要がなくなります。管理者向け画面は日本語とタイ語の二言語、作業者向け画面は言語非依存に寄せる、という切り分けが現実的です。
さらに、タイ語は同じ意味でも文字数が日本語より長くなりがちで、ボタンのラベルが折り返して崩れます。最初から最長言語で表示確認をすることを開発の受入条件に入れておくと、公開後の手戻りが減ります。
端末と防塵防滴｜共用前提の認証と、現場環境に耐える機種選定
現場のタブレットは棚に置きっぱなしの共用が基本です。ここで「誰が入力したか」を厳密に取ろうとして個人ID・パスワードを毎回入力させると、共有アカウントで運用されるか、付箋にパスワードが書かれるかのどちらかになります。社員証のバーコードやNFC、あるいは工程開始時に一度だけ担当者を選ぶ方式など、現場の手が止まらない認証に落とすほうが、記録の信頼性は結果的に高くなります。
機種の選定では、タイの工場環境そのものが条件になります。雨季の高湿度、空調の効かない建屋、切削油やめっき液のミスト、粉体を扱う工程の粉塵。ここにコンシューマ向けタブレットを裸で置くと、タッチが効かなくなる、端子が腐食する、といった形で数か月単位の消耗品になります。防塵防滴等級のある産業向け端末や、専用ケースと保護フィルムの組み合わせを検討する価値があるのはこのためです。判断の基準は仕様表の等級ではなく、その工程で実際に年間何台が壊れているかです。破損実績が出ていない工程なら過剰投資になり、出ている工程なら初期費の差はすぐに回収できます。
もうひとつ見落とされやすいのが、手袋をしたままの操作です。作業手袋の上からでは静電容量式のタッチが反応しない端末があり、作業者が手袋を外して操作するようになると、その時点で入力が後回しになります。現場で使う手袋を持ち込んで実機を触ることを、機種決定の前に必ず入れてください。
工場内無線｜オフラインで動くかを設計要件にする
構内Wi-Fiは、必ずどこかに穴があります。設計時点で「通信が切れたらどうなるか」を決めていないアプリは、現場で入力途中のデータが消えた瞬間に信用を失い、二度と使われません。入力はローカルに保持し、通信復帰時に同期する方式を最初から前提にするか、少なくとも切断時に警告を出して入力をブロックする挙動を決めておく必要があります。帳票の電子化を検討している場合は、電子帳票システム導入ガイドで紙からの移行手順も確認してください。
IT人材の採用と定着｜1〜2名体制で回る設計にする
タイの日系工場のIT担当は1〜2名というのが一般的で、その1名がネットワーク、PC、ERP、複合機、そして新しいアプリまで抱えます。ここに「自社で全部作る」という方針を乗せると、担当者の作業がアプリ保守に占有され、本来のIT運用が止まります。さらに、その担当者が転職した瞬間にすべてがブラックボックス化します。内製化を進める場合でも、担当者が1名抜けても復旧できる状態、つまりアカウント、ソースやアプリ定義のエクスポート、設計メモの保管場所を決めておくことが条件になります。
給与面でも、工業団地が集中するサムットプラカンやサムットサコンの水準はバンコク中心部以外のエリアより高く、採用競争は緩くありません。人を採って内製するか、外部に持たせるかは、採用できる前提で計画しないほうが安全です。
BOI恩典｜ソフトウェア開発が対象になる場合の条件
タイでは、ソフトウェアやデジタルサービス向けプラットフォーム、デジタルコンテンツの開発がBOIの奨励事業に位置づけられています。2021年9月16日告示のSor. 4/2564（2021年9月17日施行）で、旧5.7ソフトウェア・5.8 eコマース・5.9デジタルサービスがカテゴリ5.10に統合されました。A2相当の恩典として法人税免除は最大8年（対象経費の実額に基づくキャップがあります）、主な条件はタイ人IT人材の新規雇用で年間給与合計150万バーツ以上を満たすこと、および開発工程をBOI承認のもとタイ国内で実施することとされています。
ただしカテゴリ番号や条件はその後も改訂が入っているため、申請を検討する段階で必ず最新の告示を確認してください。ここで実務上重要なのは、恩典を取りに行くかどうかで「開発をどこでやるか」の選択肢が変わる点です。オフショアで安く作る案と、タイ国内で人を雇って作る案は、BOIを前提にすると比較の土俵そのものが変わります。
失敗する業務アプリの5パターン
導入がうまくいかない工場には、共通した型があります。
作った人しか直せない
最も多い型です。ノーコードで現場担当が作り、業務ルールが画面の設定の中に埋め込まれ、外に一切ドキュメントが出ていない。その人が帰任・異動・退職した時点で、誰も条件を変えられなくなります。内製化の一般的なリスクとしてシャドーITやブラックボックス化が繰り返し指摘されるのはこのためです。「作った本人が1週間休んでも運用が回るか」を、稼働判定の基準に入れてください。
現場に聞かずに管理側の欲しい項目だけ増やす
管理部門が見たい指標を全部入力項目にすると、1回の入力にかかる時間が数倍に膨らみます。当社が現場で見てきた範囲では、この状態になると作業者はまとめて後で入力するようになり、データはリアルタイム性も正確性も失います。入力項目は「その作業者がその瞬間に確実に知っていること」だけに絞り、そこから計算できるものは計算させるのが原則です。
紙をそのまま画面にする
既存の帳票をそのままタブレットの画面にすると、A4一枚に詰まった項目が縦に長いフォームになり、スクロールが止まらない画面ができます。紙は一覧性が高く、画面は一覧性が低い。紙を電子化するのではなく、業務を分解して画面に割り直す必要があります。
一気に全工場・全ラインへ展開する
パイロットを飛ばして全社展開すると、電波の穴、端末の不足、教育の遅れ、例外業務が同時に噴出し、原因の切り分けができなくなります。結果として「アプリが悪い」という結論になり、次の投資が止まります。1ライン、1工程で回してから広げるほうが、総所要時間はむしろ短くなります。
DX推進チームが社内ベンダー化する
内製化のために作った推進チームに、各部門から開発依頼が集中し、チームが社内の受託開発部隊になる型です。依頼は無償なので優先順位がつかず、待ち行列が伸び、やがて各部門が勝手にツールを買い始めます。内製チームは「作る係」ではなく「作れる状態を保つ係」として、標準テンプレート、共通マスタ、レビューの提供に役割を絞るほうが持続します。
発注前に決める10項目
見積を取る前にこの表を埋めておくと、各社の提案が比較可能な形で出てきます。逆に、ここが空欄のまま出てきた見積は、後から必ず増額されます。
| 決める項目 | 具体的に書くこと | 決めないと起きること | 決める人 |
|---|---|---|---|
| 対象業務の範囲 | どの工程のどの作業か。対象外も明記 | スコープが膨張して納期が延びる | 工場長・工程責任者 |
| 利用者と人数 | 作業者・班長・管理者の別と人数 | ライセンスと端末台数が読めない | 製造管理 |
| 端末と運用形態 | 機種、共用か個人か、予備機の数 | 現場で使えない端末が届く | 製造管理・IT |
| 認証方式 | 個人ID、社員証、工程開始時の選択など | 共有アカウント運用になり記録が無意味化 | IT・品質 |
| 言語 | 画面ごとに必要な言語を指定 | 公開後に全画面の翻訳やり直し | 人事・製造管理 |
| オフライン時の挙動 | 保持して同期か、入力ブロックか | データ消失で現場の信頼を失う | IT |
| 連携先と方向 | 相手システム名、項目、頻度、片方向か双方向か | テスト工数が読めず増額される | IT・経理 |
| データ保存期間と権限 | 何年保持、誰が見られるか、削除の可否 | 監査で提示できない、または情報が漏れる | 品質・管理部門 |
| 改修の受け方 | 年間の改修枠と依頼窓口 | 稼働後3か月で更新が止まる | 管理部門 |
| 引き継ぎ条件 | 納品する文書、アカウント、エクスポート手段 | 担当者の退職で全体がブラックボックス化 | IT・工場長 |
この表の使い方
すべてを厳密に決める必要はありません。重要なのは、空欄になっている項目こそが将来の増額とトラブルの発生源だと認識して、見積依頼のときに「ここは未定です」と明示することです。未定を明示した見積と、未定を隠した見積では、後者のほうが必ず高くつきます。
90日で最初の1本を出す進め方
最初の1本は、機能を欲張らず「日程を守ること」を目的にします。現場が最初に見るのは機能の多さではなく、言ったことが本当に形になって出てくるかだからです。
最初の30日｜対象を1工程に絞り、電波を実測する
対象は1ライン1工程、利用者は10人以下に絞ります。この期間にやるべき最重要作業は、要件のヒアリングではなく現地での実測です。対象エリアの電波強度、端末を置く場所、作業者の手の空き具合、既存の紙帳票の実物と記入例、そして例外処理（誰がいつ、どんなときに手書きで補記しているか）を集めます。上の10項目の表を、この期間で埋め切ります。
31〜60日｜入力UIを現場で触りながら固める
この期間は、動く画面を現場に持ち込んで触ってもらいます。会議室でのレビューでは、手袋、照明、騒音、立ち位置といった条件が再現できません。週1回、実際のライン上で15分だけ触ってもらうサイクルを回すと、画面への指摘は数周で収束していくケースが多いです。この段階ではデータ基盤層と業務ルール層は最小限にとどめ、基幹連携は行いません。
61〜90日｜1工程で本番運用し、紙と並走させる
いきなり紙を廃止せず、2〜4週間は紙とアプリを併用します。件数が一致するか、入力にかかる時間が紙より短くなっているか、班長が集計に使えているかを見ます。ここで紙をやめる判断ができる状態になっていれば、その1本は成功です。ならなければ、範囲を広げずに原因を潰します。
90日を過ぎてからやること
2本目以降で初めて、データ基盤層の共通化と基幹連携に手をつけます。1本目で使ったマスタを共通マスタとして切り出し、2本目からはそれを参照させる。この順番を守ると、アプリが増えても管理対象は増えません。逆に1本目から全社共通基盤を設計しようとすると、90日では絶対に出ません。開発パートナーの選定基準については、タイのシステム開発会社の選び方も参考になります。
進め方の要約
| 期間 | 主な作業 | 完了の判定 |
|---|---|---|
| 1〜30日 | 対象工程の確定、電波と現場の実測、10項目を確定 | 未定項目がゼロか、明示されている |
| 31〜60日 | 入力UIをライン上で反復改善 | 画面変更の要望が収束する |
| 61〜90日 | 1工程で本番運用、紙と並走 | 紙をやめる判断ができる |
| 91日以降 | 共通マスタ切り出し、基幹連携 | 2本目が1本目のマスタを参照できる |
よくある質問
業務アプリ開発の費用はいくら？
「アプリ1本いくら」では答えが出ません。金額を決めるのは画面数ではなく、外部システムとの連携本数、対象人数、端末と回線の状況です。初期開発費だけを比較しても意味が薄く、改修枠、運用、端末、回線を含めた5層で見てください。参考として、タイのIT人材の給与水準はJobsDBタイの2026年6月時点の掲載データでソフトウェア開発者の平均月給がTHB 37,500〜50,000程度のレンジで示されており、工業団地に近いエリアほど高い傾向があります。これは求人掲載の平均値であり統計調査ではないため、実勢とはずれる点に注意してください。人月単価はこの水準に間接費と保証負担が乗ったものとして読むと、見積の妥当性を判断しやすくなります。
スマートフォンの業務アプリ開発は自社でできる？
入力UI層に限れば十分可能です。ノーコード基盤を使えば、点検、日報、簡易な不良報告のようなアプリは現場担当者でも作れます。ただし条件があります。作った人以外が変更できる状態を保つこと、データの保存先とバックアップを情シスが把握していること、そして基幹システムと直接つながないこと。この3つを外すと、便利なアプリが数か月後に触れない資産になります。スマートフォンを使う場合は、私物端末を使うのか会社支給かで情報管理の設計が大きく変わる点にも注意してください。
パッケージソフト導入支援と受託開発の違いは？
パッケージ導入支援は「自社の業務をパッケージが想定する形に寄せる」作業、受託開発は「自社の業務に合わせて作る」作業です。会計、勤怠、在庫のように標準化されている業務はパッケージが有利で、導入支援の価値は設定やデータ移行、運用ルールづくりにあります。一方、自社の検査手順や独自の工程管理のように他社と同じにする必要がない業務では、パッケージのカスタマイズ費用が受託開発を超えることがあります。「この業務を他社と同じやり方に変えられるか」を自問すると、どちらを選ぶべきかがはっきりします。
製造業のアプリケーション開発はどこに頼めばいい？
技術力より、現場に入れるかどうかで選んでください。判断材料は、工場のラインに立ち入って作業を観察した経験があるか、タイ語での現場ヒアリングができるか、電波や端末の環境調査を見積の前にやるか、そして納品物に仕様書とテスト結果と引き継ぎ手順が含まれているかです。製造業に強いシステムインテグレーターかどうかは、提案書の言葉より現場調査の提案の有無に表れます。
タブレットの業務システムを工場で使うとき、端末は何を基準に選ぶ？
画面サイズと耐環境性、そして充電と保管の運用です。手袋をしたまま操作するなら静電容量式の感度、油や粉塵があるなら防塵防滴等級、落下が想定されるなら耐衝撃性が要ります。加えて、共用端末の場合は充電ステーションの場所、シフト交代時の受け渡し、故障時の予備機を先に決めておかないと、端末が現場から消えます。コンシューマ端末の安さは、年間の破損台数を掛けると逆転することがあるため、実際の破損実績で判断してください。
システムインテグレーターに製造業の経験は必要？
データ基盤層と基幹連携層を任せるなら必要です。工程、ロット、不良コード、トレーサビリティといった概念を前提から説明しなければならない相手だと、設計の妥当性を発注側だけで検証することになります。逆に入力UI層だけを短期で手伝ってもらうなら、製造業経験より現場に入る姿勢と反応速度のほうが効きます。ここでも、どの層を任せるかで必要な条件が変わります。
まとめ
工場の業務アプリは「作るか買うか」で決めるものではありません。入力UI層、業務ルール層、データ基盤層、基幹連携層の4つに分け、上の層は現場に近い人が速く回し、下の層は文書と引き継ぎを含めて外部に持たせる。この非対称性を最初に認めるだけで、内製と外注の議論はほとんど片づきます。
費用は初期開発だけでなく、改修、運用、端末、回線の5層で見る。タイの工場では、多言語、共用端末、無線の穴、IT担当1〜2名という体制、そしてBOIの条件が設計の前提として効いてきます。そして最初の1本は、範囲を1工程に絞って90日で出し、紙をやめる判断ができるかどうかで評価する。この順番を守れば、2本目以降のコストは目に見えて下がります。
どの層まで内製で持ち、どこから外に出すかは、工場の人員構成と端末環境によって変わります。TOMAS TECHでは、要件が固まる前の「そもそもどこを自社でやるべきか」という段階からのご相談も承っています。現場の写真や既存の帳票をお持ちいただければ、どの層を先に手当てすべきかの整理だけでもお手伝いできます。ご相談はお問い合わせフォームからお願いします。
参考情報
- ITR｜国内ローコード／ノーコード開発市場の規模と予測に関するプレスリリース（2026年2月5日発表） (https://www.itr.co.jp/topics/pr-20260205-1)
- Tilleke & Gibbins｜Thailand’s BOI Revamps Promoted Digital Activities (https://www.tilleke.com/insights/thailands-boi-revamps-promoted-digital-activities/12/)
- JobsDB Thailand｜Software Developer Salary（2026年6月時点の掲載データ） (https://th.jobsdb.com/career-advice/role/software-developer/salary)
- 日立ソリューションズ｜RPAコラム（システム内製化のリスクに関する解説） (https://www.hitachi-solutions.co.jp/rpa/column/rpa_vol42.html)
- ダイキン工業 ITEC｜製造業向けブログ（システム内製化の解説） (https://www.itec.daikin.co.jp/manufacture/blog/naisei/)
- モンスターラボ｜DX用語解説（内製化・インハウス化） (https://monstar-lab.com/dx/about/inhouse-production/)
- グローバルインフォメーション｜ローコードアプリケーション開発プラットフォーム市場に関する調査レポート案内 (https://www.gii.co.jp/report/ires2011670-low-code-application-development-platform-market.html)
