タイのシステム開発を PoC から始める

タイで新しくシステムを入れるとき、いきなりフル開発に入って現場で頓挫する話をよく聞きます。日本本社が固めた要件がタイの現場運用と噛み合わない、タイ人スタッフが操作を覚えられない、稼働後に致命的な業務ズレが見つかる。よく見るパターンです。

これを避けるために当社が採っているのが、まず PoC を回す進め方です。小さく作って、現場で数日〜数週間動かしてみて、そこで見えた事実を元に本開発の範囲と優先度を組み直します。結果的にこの方が早く、安く、痛みが少ない場面が多くあります。

PoC で確かめること

PoC は「動くものを作ってみる」ことではなく、「本開発に進んでいいかを判断するための材料を集める」作業です。何を判断したいかを最初に決めます。

タイの案件で当社が特に確かめたいのは、現場のオペレーションに実際にフィットするか (日本本社の想定通りに動くか、ではなく)、タイ人スタッフが説明なしで操作を覚えられるか、現場で必ず出てくる例外パターン (帳票が汚れている、Wi-Fi が切れる、担当が急に休む) がどう影響するか、既存の業務フロー・既存システムとの噛み合わせ、あたりです。どれも要件定義書からは読めず、実物を現場に置いてはじめて見える情報です。

PoC の切り出し方

スコープを決めるとき、機能単位で切るのではなく「1 つの業務が完結する最小単位」で切ります。

例えば出荷ラインの QC システムであれば、「Part No 照合機能だけ」を作るのではなく、1 種類の Box を対象に、スキャンから照合、記録、翌日レポート出力までを通しで作ります。この方が、部分機能を組み合わせるときに見える連結面での問題が見つかります。

PoC の期間は 2〜4 週間、対象範囲は 1 帳票・1 ライン・1 拠点というのが、当社でよく採る規模感です。

PoC を実験として設計する

PoC の成果物はコードそのものではなく、本開発に進むか進まないかの判断材料です。最初に決めておくのが成功判定の基準です。「タイ人スタッフ 5 名中 4 名が初回説明 30 分以内に操作を覚えられる」といった、後で振り返って判断できる書き方にします。同時に失敗判定の閾値も設定します。「1 週間で 3 回以上、現場から使えないと言われたら失敗と見なす」といった形です。

ここが曖昧なまま PoC を回すと、動きはしたけれど「これで本開発に進んでいいのか?」の議論が空中戦になります。

PoC から本番への移し方

PoC が成功したら、そのコードを本番に流用したくなりますが、当社は基本的に本開発は書き直す前提で PoC を作ります。

理由は 3 つあります。PoC は捨てる前提なので、認証・監視・エラーハンドリングが省かれています。そこから本番用に肉付けするより、本番用の骨組みで最初から組んだ方が速い。PoC で見えた要件変更を既存コードに継ぎ足すのは技術負債になります。PoC で得た知見 (UI 判断、業務フロー、例外の扱い) は、コードを書き直しても本開発に持ち込めるので、価値は失われません。

「PoC のコードをそのまま本番に」というのが失敗の温床になりやすいので、最初に「捨てる」と決めておきます。

PoC が向かないケース

PoC は万能ではなく、素直に本開発から入るべき場合もあります。既に他拠点で同じ業務・同じ規模で稼働実績のあるシステムをそのまま複製導入するとき。法規制・認証・監査対応が最初から必須の領域 (医療、金融など)。PoC を作る工数と本開発 1 か月目の工数がほぼ同じ規模になる小さめの案件。このあたりは PoC を挟むメリットが小さくなります。

逆に、タイの日系製造業の受発注業務、工場現場のデジタル化、多拠点向けの SaaS 展開など、要件と現場の噛み合わせが結果を左右する案件では、PoC を挟む方が結果的に早い場面が多いです。

関連: 工場出荷ラインの QC スキャンシステム / AI を活用した OCR をタイの日系製造業へ導入 / タイの工場現場システムのオフライン設計

タイでのシステム開発をご検討中の方は お問い合わせ からお気軽にご相談ください。