スモールスタート システム導入｜規模とQCDの関係で決める刻み方

スモールスタート システム導入は、予算が足りないときの妥協案として語られがちです。しかし一次データを見ると評価は逆になります。プロジェクトの規模が大きいほど、品質・予算・工期のいずれも「不良」の割合が上がる。つまり、どの大きさで切るかという判断そのものが、工場の基幹システム刷新における最大のリスク管理です。この記事では公開調査の実数を示しながら、どこで切るか、そして絶対に切ってはいけないのはどこかを整理します。

「小さく始める」は妥協ではない — 結論から先に

タイやASEANの日系工場で生産管理システムの刷新を検討すると、たいてい最初に出てくるのは「どうせやるなら一度に全部」という案です。受注から出荷まで、在庫も原価も品質記録も一気に載せ替える。理屈としては正しく見えます。段階導入は移行期間中に新旧が併存し、その分の手間がかかるからです。

ところが、実際に完了したプロジェクトを規模別に集計した調査を見ると、この直感は数字に裏切られます。日本情報システム・ユーザー協会（JUAS）の『企業IT動向調査 報告書 2026』（2025年度調査）第7章「システム開発」は、プロジェクト規模別のQCD（品質・コスト・納期）遵守状況について、次のように書いています。

不良の割合は、「10人月未満」のプロジェクト規模ではQCDともに10.0％を下回っているが、「500人月以上」のプロジェクト規模では品質で29.6％、予算で42.2％、工期で47.8％と高い。

報告書はさらに「QCDすべてでプロジェクト規模が小さいほど良好な割合が高く、プロジェクト規模が大きいほど良好な割合が低い」と明記しています。両端だけを並べると、こうなります。

この表の見方には注意が要ります。品質と予算の数値は規模を5区分にした図表から、工期の47.8%は規模を3区分にした別の図表から来ています。「10人月未満の工期」という区分は3区分の表には存在せず、報告書本文の総括的な記述からしか読み取れません。だから上の表の左下だけは、数値ではなく記述をそのまま置いてあります。

それでも、伝わることははっきりしています。500人月級を一度に作ろうとすると、予算が超過したプロジェクトの割合がおよそ4割、工期が遅延した割合がおよそ5割。これは「うまくやれば避けられる例外」ではなく、多数のプロジェクトを集計した結果の平均的な姿です。一方で10人月未満に刻めば、QCDのいずれも不良は1割を切る。刻むことは能力の不足を認めることではなく、統計的に有利な側に自分を置く選択だということになります。

本記事はこの一点を全編で貫きます。小さく刻むことは妥協ではない。プロジェクト規模とQCD不良率には一次データで裏づけのある関係があり、刻み方そのものが最大のリスク管理である。

データが示すプロジェクト規模とQCDの関係

まず、根拠となる数字を省略せずに置きます。出典はJUAS『企業IT動向調査 報告書 2026』（2025年度調査）の図表7-1-4「プロジェクト規模別 システム開発 QCD遵守状況」です。単位はすべて%、nはプロジェクト件数です。

品質の遵守状況

品質の「不満」は5.4%から29.6%まで、規模が上がるにつれて単調に増えています。両端の比を実際に割ると、29.6 ÷ 5.4 = 5.48倍です。丸めずに書くと5.481…なので、小数第2位で5.48倍と表現するのが妥当なところです。「約6倍」と言いたくなりますが、割り算の結果は5.48であって6ではありません。本記事では丸めずに5.48倍として扱います。

次に予算です。同じ図表の予算側を見ます。

予算の遵守状況

予算超過の両端比は 42.2 ÷ 6.0 = 7.03倍です。品質の5.48倍より傾きが急で、規模の影響がより強く出ています。工場の投資判断の現場では、この差のほうが痛いはずです。品質の不満は運用でごまかせる余地がありますが、予算超過は稟議のやり直しに直結します。

なお、途中の区分どうしの比を作るのは避けてください。たとえば「50〜100人月未満の予算超過19.6%は10人月未満の6.0%の何倍か」といった計算は算術としては可能ですが、報告書が意味づけしているのは「規模が大きいほど不良が増える」という単調性であって、個々の倍率ではありません。本記事で比として扱うのは、上の2つだけです。

工期については、規模の区切りが変わります。同報告書の図表7-1-3「プロジェクト規模別・年度別 システム開発の工期遵守状況」（2025年度）は3区分です。

工期の遵守状況（3区分）

ここで区分数を突き合わせておきます。品質・予算の表は5区分、工期の表は3区分です。数が違うので、5区分の表の行と3区分の表の行を横に並べてはいけません。件数でも確かめられます。以下の合算はいずれも本記事が報告書の表のnを足し合わせたものです。品質の表のnを足すと688＋562＋405＋319＋223＝2,197件、工期の表のnを足すと1,647＋317＋226＝2,190件で、7件ずれます。さらに、品質の表の小さい側3区分（688＋562＋405＝1,655件）と、工期の表の「100人月未満」（1,647件）も8件ずれています。集計母集団が完全には一致していないということであり、2つの表を接続して「10人月未満の工期遅延率」を導くことはできません。

この数字を読むときの前提も押さえておきます。第一に、これは日本国内のユーザー企業を対象とした調査であって、タイ法人のプロジェクトを集計したものではありません。タイの日系工場に当てはめるときは、傾向の参照として使うべきで、そのまま自社の予測値にはできません。第二に、nはプロジェクト件数であって企業数ではありません。調査全体の有効回答は957社ですが、1社が複数のプロジェクトを回答しているため、表のnと957社を混同しないでください。第三に、2025年度調査から回答選択肢に「期待を超えて満足」「予定より抑えて完了」「予定より早期に完了」が新たに追加されています。報告書自身が「改善側で選択肢を一段階増やしており、これによる影響を勘案する必要がある」と注意しているため、前年からの改善を単純に比較して語ることはできません。本記事が使っているのは、あくまで同一年度内での規模間の比較です。

各行の合計が100.0%にならない箇所があるのは四捨五入によるものです。表の値をそのまま足し引きして新しい指標を作る、といった加工もしないほうがよいでしょう。

なぜ大きいと壊れるのか — 要件が仕様に届かない

規模とQCD不良率に関係があることは分かりました。では、なぜ大きいと壊れるのか。同じ報告書の別の図表が、その手前の理由を示唆しています。図表7-2-7「システム開発の内製化を進めるうえでの課題」（複数回答・2025年度・n=953）です。

この表は複数回答なので、縦に足しても意味がありません。合計は100%を超えます。読むべきは順位と水準です。

上位3つは人材の量・質・PM人材という「頭数と練度」の話ですが、本記事の文脈で重いのは4番目と5番目です。現行業務への理解不足が38.2%、システム企画力不足（ビジネス要件をシステム仕様に落とせない）が34.5%。内製化を進めるうえでの課題として、3社に1社以上が、自社の業務を仕様に翻訳する工程のつまずきを挙げています。

ここが規模の問題と直結します。プロジェクトが大きいほど、要件を固めてから最初の画面が動くまでの距離が長くなります。500人月級なら、要件定義の議事録に書いた「こういう運用にしたい」が、実際に現場で試せる形になるのは何か月も先です。その間、要件が仕様に正しく翻訳されたかどうかを確かめる手段がありません。翻訳の誤りは、テスト工程か、最悪の場合は稼働後に発覚します。そこで直そうとすると、すでに周辺の機能が積み上がっているため、修正の影響範囲が広い。これが予算超過と工期遅延の主要な発生経路です。

逆に10人月未満に刻めば、要件を書いてから動くものを見るまでの距離が短い。翻訳の誤りは早期に、影響範囲が小さいうちに見つかります。スモールスタートの本質は「作る量を減らすこと」ではなく「翻訳の誤りを早く見つける仕組みを作ること」です。 作る総量は最終的に同じかもしれません。違うのは、誤りを抱えたまま進む距離です。

報告書は同章のまとめで、QCD悪化の要因として社員およびベンダーのスキル不足がより顕著になってきている、とも述べています。スキルは短期には上がりません。上げられないものを前提に設計を変えるなら、打てる手は「一度に扱う複雑さを減らす」ことになります。

もう一点、人材の量の問題は国内調査だけの話ではありません。独立行政法人情報処理推進機構（IPA）の2025年度「DX動向調査」（回収数1,799社、調査期間2026年4月17日〜6月12日）では、DXを推進する人材の「量」について「やや不足」と「大幅に不足」の合計が85.5%でした。ただしこれはJUASとは調査主体も時期も対象企業も異なる別の調査です。JUASの数値と並べて比率を計算したり、同じ物差しで大小を論じたりはできません。ここでは「人が足りないという認識は広く共有されている」という背景としてのみ参照します。

どこで切るか — 切る単位の決め方

刻むと決めたら、次は切り方です。工場の業務システムで実務的に機能する切り口は、おおむね4つに整理できます。

このうち最も失敗が少ないのは、工程で切る方法と帳票で切る方法です。どちらも「現場の誰が使うか」がはっきりしていて、稼働の合否が現場の実感で判定できます。逆に期間だけで切るのは危険です。3か月という枠に合わせて機能を削ると、削ってはいけないところが削られることがあります。期間は制約として置き、切る単位は業務側で決めるのが順序です。

拠点で切る場合は、もう一段の注意が要ります。タイの複数工場で運用がばらついているとき、その差には「製品や設備が違うから必然的に違う」ものと、「担当者が代わるたびに少しずつずれただけ」のものが混ざっています。前者は残す、後者は第1弾で揃える。この仕分けをせずに拠点展開すると、拠点ごとのカスタマイズが増え、結局は大きな一括プロジェクトと同じ複雑さを抱えることになります。

帳票で切る場合の具体的な進め方は、電子帳票の導入を扱った記事にまとめてあります。紙の運用から抜けるときにどの順で置き換えるかは、電子帳票システムで工場の紙運用を脱却する方法を参照してください。工程で切る場合の対象範囲と費用感については、工程管理システムの費用と選び方が参考になります。

切る単位を決めたら、必ず「第2弾以降で何を足すか」を同時に書いてください。第1弾の設計書に、第2弾で追加される項目・画面・連携先の名前だけでも並んでいるかどうか。ここが空白のまま第1弾を作ると、第2弾で土台から作り直すことになります。後述する「横展開の設計が無い」という失敗パターンの入口がここです。

切ってはいけない場所 — マスタ・採番・権限

ここが本記事で最も伝えたい部分です。スモールスタートを勧める記事は多くありますが、「切ってはいけない場所」を明示しているものは多くありません。そして実務で事故が起きるのは、たいていこの3か所です。

刻むという行為は、機能を分割することです。しかし、機能の裏にある共通の土台まで分割してしまうと、第2弾以降で必ず二重管理が発生します。土台とは具体的に、マスタ・採番・権限の3つです。

マスタを分けてはいけない

品目マスタ、取引先マスタ、工程マスタ、設備マスタ、単位マスタ。これらを第1弾のスコープに合わせて「今回使う分だけ」作ると、第2弾で必ず別のマスタが生まれます。よくある壊れ方はこうです。

第1弾で受入検査だけを対象にしたので、品目マスタには購入品だけを登録した。第2弾で組立実績を扱うことになり、今度は製造品を登録する必要が出た。しかし第1弾の品目マスタには製造品を持つための項目（工程、標準時間、構成）がないので、第2弾用に別のマスタを作った。この時点で、同じ「品目」という概念に対して2つの台帳が存在します。以後、品目の追加・変更のたびに2か所を直すことになり、片方だけ直された品目が必ず出ます。

回避策は単純です。マスタの項目設計だけは、第1弾のスコープではなく最終形のスコープで行う。 実際に値を入れるのは第1弾で使う分だけでかまいません。器を最終形で作り、中身を段階的に埋めるという順序です。器を作る工数は、機能を作る工数に比べれば小さい。ここをケチると後で何倍にもなって返ってきます。

もう一つ、マスタのコード体系も第1弾で決め切ってください。品目コードの桁数と意味づけ、拠点コード、工程コード。これらは後から変えると、既存データ全体の変換が必要になります。第1弾の時点でデータ量が少ないうちに固めるのが最も安いタイミングです。

採番を分けてはいけない

製番、ロット番号、伝票番号、指図番号、検査番号。これらの採番ルールと採番の主体を分割すると、番号の重複または欠番が発生します。

典型例です。第1弾で出荷梱包を対象にし、梱包番号を新システムで採番するようにした。第2弾で在庫移動を扱うことになったが、既存のエクセルでも同じ体系の番号を振っていたため、両方が同じ番号を発行した。倉庫では同じ番号のラベルが2枚存在することになり、実物とデータの対応が取れなくなる。

この事故が厄介なのは、発覚が遅いことです。番号の重複は、たまたま同じ番号の2件が同時に処理されるまで表面化しません。半年後の棚卸で初めて「合わない」と分かる、という形で出てきます。そのときにはもう、どちらのデータが正しいかを人手で追うしかありません。

採番は必ず単一の発番元を決めてください。 第1弾のシステムが発番元になるなら、第2弾以降で扱う番号の体系もそこに含めておく。まだシステム化していない領域の番号も、体系だけは先に予約しておく。この「予約」は設計書に1ページ書くだけで済みます。

トレーサビリティを重視する工場では、この点がとくに重い意味を持ちます。ロット番号の連続性が切れると、遡及調査そのものが成立しません。刻むこととトレーサビリティは矛盾しませんが、それは採番を分けなかった場合に限ります。

権限を分けてはいけない

ユーザーの登録、組織階層、承認ルート、参照範囲。これらを第1弾ごとに独立して持つと、退職者のアカウントが残ります。

タイ拠点では、この問題が国内以上に効きます。ローカルスタッフの入れ替わりがある環境で、システムごとにユーザー台帳が分かれていると、「Aシステムでは削除したがBシステムには残っている」という状態が必ず生じます。生産実績を入力できるアカウントが退職者のまま生きている、という状況は、監査でも品質保証の観点でも説明が難しい。

ユーザーと権限は、第1弾の時点で全社共通の1か所に置いてください。 既存の認証基盤があるならそれに寄せる。無いなら第1弾で作り、以後のすべての弾がそこを参照する。第1弾だけを見れば過剰な投資に見えますが、3弾目までを見れば確実に安いはずです。

分けてよいもの・分けてはいけないもの

整理すると、次のようになります。

この表の下半分が、いわば「第0弾」です。第1弾の機能を作る前に、共通の土台として先に置く。工数としては全体の一部にすぎませんが、ここを置かずに走ると、第2弾・第3弾の工数が膨らみます。刻んだのに大きく作ったのと同じ苦しさを味わうのは、たいていこのパターンです。

基幹システムとの統合を前提にする場合の費用構造については、業務システム開発の費用とERP統合の考え方で層ごとに分解しています。第0弾に相当する部分がどこに乗るかを確認するのに使えます。

タイ拠点で刻むことが効く理由

ここまでは日本国内の調査データに基づく一般論でした。タイ・ASEANの日系工場には、さらに刻むことを有利にする事情があります。

第一に、長いプロジェクトは人の入れ替わりをまたぐという点です。RECRUITdeeの「Thailand Job Market 2026 Outlook」によれば、2026年の昇給予算の平均は約4.7%、高スキル分野では転職時の待遇上昇が15〜30%とされています。この2つは次元が違う数字です。4.7%は在籍したまま1年で上がる年率、15〜30%は職を変えたときの一時的な跳ね上がりです。割ったり足したりできる関係ではありませんが、並べて眺めれば、スキルのある人が動く動機がどこにあるかは見えます。同レポートは域内の離職率を約17.5%としています。これは「域内（regional）」の数値と書かれており、タイ単独の数字だとは明記されていないため、タイの離職率だと断定はできません。それでも、水準感としての参考にはなります。なお、同レポートには給与の金額そのものは記載がないため、本記事では金額に踏み込みません。

仮に18か月のプロジェクトを想定してみます（この期間は説明のための仮定値です）。要件定義に参加した現地スタッフが、稼働時にも在籍している保証はありません。日本人駐在員も、任期の区切りでプロジェクトの途中に交代することがあります。要件定義の議事録には書かれていない「なぜそう決めたか」は、多くの場合その場にいた人の頭の中にしかありません。人が入れ替わると、その文脈が失われます。残った仕様書だけを見て「なぜこの設計なのか分からない」となり、確認のために止まる。これが工期遅延の、タイ拠点特有の増幅要因です。

3か月の弾に刻めば、要件定義から稼働までを同じ人が担当できる可能性が高くなります。文脈が失われる前に成果物が完成する。これは組織論ではなく、単純に期間の問題です。

第二に、判断の場が分散しているという事情があります。タイ法人の工場長、管理部門長、日本本社の情報システム部門、場合によっては本社の事業部門。大きなプロジェクトは、この全員の合意を一度に取り付けようとします。合意形成そのものに時間がかかり、しかも一度合意した内容を変えるコストが高い。小さな弾なら、決裁の範囲も小さくて済みます。第1弾の実績を持って第2弾の承認を取る、という形が使えるのも利点です。

第三に、経済環境の不確実性です。同レポートはタイの2026年の経済成長率見通しを約1.6%としており、出典はIMFと明記されています。伸びが緩やかな局面では、大きな投資の稟議は通りにくく、また通ったとしても途中で見直しがかかるリスクがあります。3か月ごとに投資判断を刻めるスモールスタートは、この環境と相性がよい進め方です。

タイでの発注先の選定については、タイのシステム開発会社の選び方に判断軸を整理しています。刻んで進めるなら、1弾ごとに発注先を変えるのではなく、共通の土台を理解している相手と継続する方が結果的に安くつきます。

スモールスタートが失敗する典型パターン

刻めば必ずうまくいく、という話ではありません。スモールスタートには固有の失敗の仕方があります。よく見るのは次の4つです。

1. PoCで終わる。 効果を確認するための試行をやり、確認できたところで満足して止まる。原因の多くは、試行の設計に「本番へ移す条件」が書かれていないことです。何がどうなったら本番展開に進むのか、誰が判断するのか、そのときの予算はどこから出るのか。この3つを試行の開始時に決めておかないと、試行は試行のまま終わります。

2. 小さすぎて効果が出ない。 1つの帳票だけを電子化したが、その帳票の前後は紙のままなので、結局は転記が残る。むしろ入力先が増えて手間が増えた、という状態です。刻む単位は「業務が一巡する最小の単位」であるべきで、機能の最小単位ではありません。作業日報を電子化するなら、日報から集計・実績反映までを一巡させる。途中で紙に戻る設計にしないことです。

3. 横展開の設計が無い。 第1弾は成功したが、第2工場に広げようとしたら、第1弾が第1工場の運用に密着しすぎていて使えない。前章の「切ってはいけない場所」を守っていれば大部分は防げますが、それに加えて、第1弾の設計時に「この設定は拠点ごとに変わる／変わらない」の仕分けを明示しておく必要があります。

4. 弾ごとにベンダーを変える。 都度の相見積もりでは安く見えても、共通土台の理解が引き継がれないため、2弾目以降に「前の弾の仕様調査」という工数が乗ります。マスタや採番の意図はドキュメントに書き切れない部分があり、そこは前の弾を作った人の頭にあります。

この4つに共通するのは、第1弾を単体で最適化してしまうという誤りです。スモールスタートは「小さいプロジェクトを1回やること」ではなく、「大きな目標を小さいプロジェクトの連なりに分解すること」です。連なりの設計が無ければ、それはただの小規模開発であって、規模とQCDの関係から得られる利益も部分的にしか受け取れません。

第1弾に何を選ぶか — 症状から入る

では、最初の弾に何を選ぶか。工場の現場で語られる困りごとは、たいてい次の4つの症状のどれかに落ちます。

第1弾として最も扱いやすいのは二重入力の解消です。理由は3つあります。第一に、範囲が明確です。「この紙とこのエクセルの両方に入れている項目」という形で、対象がリストアップできます。第二に、効果の測定が単純です。入力の回数と時間が減ったかどうかで判定できます。第三に、現場の抵抗が小さい。二重入力は誰にとっても無駄な作業であり、なくすことに反対する人がほとんどいません。

エクセル管理の限界から入る場合は、限界の中身を切り分けてください。ファイルが分裂して最新版が分からないのは共有と権限の問題、計算が重いのはデータ量の問題、集計に手作業が入るのは構造の問題です。それぞれ処方が違います。「エクセルをやめてシステムにする」という言い方で括ってしまうと、要件が広がり、第1弾が大きくなります。

属人化の解消は重要ですが、第1弾には重いことが多いテーマです。属人化しているということは、手順が文書化されていないということで、システム化の前に業務そのものの棚卸しが要ります。前章で見たとおり、現行業務への理解不足を課題に挙げた企業は38.2%。ここは時間のかかる工程です。第1弾では属人化の「入口」だけを取る、たとえば当人しか知らない判断基準のうち数値で書ける部分だけをシステムに載せる、という進め方が現実的です。

効果を語るときの約束を1つ置いておきます。ベースラインは1つに固定して宣言してください。 たとえば「2026年6月の1か月間、A工程の作業日報について、記入から集計完了までに要した延べ時間」を基準にする、と書く。改善後の測定も同じ定義で行う。基準を月ごとに変えたり、都合のよい月を選び直したりすると、数字は作れても意味を持ちません。

金額の試算については、公開データに人月単価や導入費用の相場が含まれていないため、本記事では絶対額を示しません。自社で試算するなら、手順は次の通りです。まず対象作業の月あたり延べ時間を測る。次に自社の実際の人件費単価を掛けて、月あたりの人件費相当を出す。改善後の延べ時間を同じ定義で測り、差分を取る。この差分と、実際に見積もりで提示された導入費用を比べる。ここで使う単価は自社の実数であり、外部の相場ではありません。これらはすべて自社の値を入れて計算する手順であって、本記事が提示する数値ではありません。

製品を選ぶ段階に進んだら、生産管理システムの比較と選定に評価軸をまとめてあります。スモールスタートで進める場合、製品選定で重視すべきは機能の網羅性より、段階的に範囲を広げられる構造かどうかです。

内製と外注の線引きとスモールスタートの関係

刻み方を決めるとき、同時に決まるのが「誰が作るか」です。JUAS報告書は同じ章のまとめで、次の点を挙げています。

• 約7割の企業が、方針として内製と外部委託を使い分ける姿を目指している
• 実状としても、システム企画や機能要件定義といった上流工程は内製の割合が高く、設計・実装・テストといったシステムづくりは外部委託の割合が高い
• 2025年度調査では、内製化に期待する効果として、ナレッジの蓄積よりコスト削減が上位になった（報告書はベンダーの価格高騰の影響と推察しています）

この構造は、スモールスタートの設計とよく噛み合います。上流を内製で持つということは、切る場所を自分で決めるということです。どこで切るか、何を第0弾の共通土台にするかは、自社の業務を理解している人にしか判断できません。前章で見た「現行業務への理解不足38.2%」「システム企画力不足34.5%」は、まさにこの上流工程の課題です。ここを外部に丸投げすると、切る場所が「作りやすさ」で決まってしまい、業務の一巡が途中で切れた弾ができあがります。

一方、設計・実装・テストは外部の力を使ってよい部分です。刻んで進めるなら、1弾あたりの実装量は小さいので、外注の管理負荷も小さくなります。

層ごとに誰が持つかという線引きそのものについては、AI内製化支援と社内に残す層の決め方で扱っています。あちらの記事が「層ごとに誰が持つか」を縦に切る話であるのに対し、本記事は「1回のプロジェクトをどこで切るか」を横に切る話です。2つは補完関係にあり、実務では両方を同時に決める必要があります。縦の線引きだけを決めても弾の大きさは決まらず、横の刻み方だけを決めても誰が上流を持つかは決まりません。

この点は、先に触れたスキル不足の指摘とも重なります。内製に寄せれば解決する、外注に寄せれば解決する、という単純な話ではないということです。どちらに寄せるにせよ、一度に扱う複雑さを下げるという手当ては有効に働きます。

13週（約90日）で第1弾を回すための進め方

最後に、実際の進め方を時間軸で置きます。以下は本記事が提案する標準的な組み立てであり、期間や配分は仮定値です。自社の体制に合わせて調整してください。

この組み立ての要点は、第3〜4週に第0弾を置いていることです。ここを飛ばして第5週から要件定義に入りたくなりますが、飛ばした場合のツケは第2弾で必ず来ます。逆に言えば、第0弾に2週間を割けるかどうかが、スモールスタートが機能するかどうかの分かれ目です。

もう一つの要点は、第5〜6週に「第2弾以降の項目名の列挙」を入れていることです。設計まではしません。名前を並べるだけです。それでも、マスタの器に足りない項目があるかどうかは分かります。この作業は数日で終わりますが、これをやったかどうかで第2弾の工数が変わります。

第11週の判定基準を「現場の担当者だけで1日回せる」としているのも意図があります。プロジェクトメンバーが横にいる状態で動くことは、稼働できることを意味しません。手が離れた状態で回るかどうかが、実質的な合否です。

そして13週が終わったら、次の弾に入る前に必ず振り返りをしてください。切る単位は適切だったか、第0弾で足りなかったものは何か、効果測定の定義は次も使えるか。この振り返りが、弾を重ねるほど精度が上がる仕組みになります。

よくある質問

工場のDXは何から進めればよいか

まず、症状を1つ選んでください。二重入力、転記ミス、エクセル管理の限界、属人化のうち、現場が最も痛いと言っているものです。そのうえで、その症状が「業務が一巡する最小の単位」で切れるかを確認します。切れるなら、それが第1弾です。切れない場合、たとえば工程全体を通さないと効果が出ない場合は、範囲を少し広げます。順序としては、症状の特定→ベースライン測定→共通土台の設計→第1弾の実装、です。DXという言葉から入ると範囲が発散するので、困りごとから入るのが実務的です。

エクセル管理の限界はどこで来るか

限界は3種類あり、来る順番も原因も違います。1つ目は共有の限界で、ファイルが複数に分裂して最新版が分からなくなる状態です。2つ目は容量と速度の限界で、行数が増えて開くのに時間がかかる状態です。3つ目は構造の限界で、集計のたびに手作業のコピー＆ペーストが必要になる状態です。実務でよく効くのは3つ目で、これは行数が少なくても発生します。「まだ行数が少ないから大丈夫」という判断は、限界の種類を取り違えている可能性があります。なお、限界の具体的な行数や件数についての公開された基準値は、本記事が参照した出典には含まれていません。

二重入力をなくすには何から手をつけるか

まず、二重入力になっている項目を紙に書き出してください。「どの帳票のどの欄が、どこに転記されているか」を矢印で結ぶだけの図で十分です。次に、その矢印のうち本数の多いもの、または1回あたりの時間が長いものを選びます。片方を廃止できるならそれが最も安い解決です。どちらも必要な場合は、入力を1回にして、もう一方は自動で生成される形にします。この作業は、システムを買う前にできます。むしろ先にやっておくと、見積もりの前提が明確になります。

属人化を解消するには製造業では何から始めるか

属人化には、手順が文書化されていないタイプと、判断基準が言語化されていないタイプがあります。前者は手順書を作れば大部分が解けますが、後者はシステム化の前に判断基準を数値で表現する作業が必要です。「見た目で判断している」ものを「この数値がこの範囲なら合格」に置き換えられるかどうか。置き換えられる部分から段階的に載せていくのが現実的です。すべてを一度に言語化しようとすると、そこで止まります。JUASの調査では、現行業務への理解不足を内製化の課題として挙げた企業が38.2%あり、これは属人化の裏返しでもあります。

紙運用からの脱却は一気にやるべきか

一気にやらないほうが安全です。理由は、紙には記録以外の機能が付いていることがあるためです。掲示、持ち回りによる承認、現場での書き込み、外部への提出。これらを一度に置き換えようとすると、置き換え漏れが稼働後に発覚します。帳票を1つ選び、その帳票が果たしている機能をすべて列挙してから置き換える。この手順を1つの帳票で確立してから、次の帳票に進むのが確実です。

スモールスタートだと結局トータルで高くつくのではないか

移行期間中に新旧が併存する分の手間は確かに増えます。ただし、比較すべきは「うまくいった場合の一括導入」ではなく「実際に起きることの期待値」です。JUASの調査では、500人月以上のプロジェクトで予算が予定より超過した割合は42.2%、10人月未満では6.0%でした。両端の比は42.2 ÷ 6.0 = 7.03倍です。工期の遅延も、500人月以上で47.8%です。一括で進めた場合の超過や遅延を織り込んだうえで比べる必要があります。なお、この調査は日本国内のユーザー企業を対象としたもので、タイ法人の実績ではありません。傾向の参照として使ってください。

生産管理の業務フロー改善はシステム導入の前と後どちらでやるか

前です。ただし、全部を前にやる必要はありません。工場の業務改善をシステムで進める場合も同じで、第1弾の対象範囲についてだけ、現状のフローを書き、明らかな無駄を取ってから載せます。無駄を残したままシステム化すると、無駄が固定されます。一方で、フロー改善を完璧にやり切ってからシステムに入ろうとすると、いつまでも始まりません。第1弾の範囲に限定して改善し、実際に動かしてから次の改善に進む、という往復にするのが実務的です。

第1弾はどのくらいの規模が適切か

公開データが示しているのは、10人月未満の区分でQCD不良率が最も低いという傾向です。JUAS報告書は「10人月未満のプロジェクト規模ではQCDともに10.0%を下回っている」と記述しています。ただしこれは日本国内の調査であり、また「10人月」という区切りは調査の集計区分であって推奨値として提示されているわけではありません。実務的には、業務が一巡する最小の単位で切ったときに自然に決まる大きさを採用し、それが極端に大きくなるなら切り方を見直す、という順序が妥当です。期間で言えば、要件定義から稼働まで3か月前後に収まるかどうかが1つの目安になります（この3か月という数字は本記事の仮定値であり、出典に基づくものではありません）。

第2弾以降の予算はどう確保するか

第1弾の効果測定の結果を、第2弾の稟議に使います。だからこそ、ベースラインの定義を最初に固定しておくことが重要です。第1弾が終わってから「どう測るか」を考え始めると、比較可能な数字が作れません。第1〜2週にベースラインを測る工程を置いているのは、この理由からです。また、年度予算の枠で動く組織では、弾の区切りを年度の区切りに合わせるより、四半期に合わせて年内に複数弾を回す方が、途中での軌道修正がしやすくなります。

まとめ

スモールスタート システム導入は、投資を惜しむための選択ではありません。JUASの『企業IT動向調査 報告書 2026』が示すとおり、プロジェクト規模とQCD不良率のあいだには明確な関係があります。品質の不満は10人月未満で5.4%、500人月以上で29.6%（比にして5.48倍）。予算の超過は10人月未満で6.0%、500人月以上で42.2%（比にして7.03倍）。工期の遅延は、区切りの異なる3区分の集計で、500人月以上が47.8%です。刻むことは、この関係の有利な側に自分を置くという判断であり、それ自体が最大のリスク管理です。

同時に、刻み方には守るべき線があります。画面も帳票も業務ロジックも分けてよい。しかし、マスタの項目設計、コード体系、採番、ユーザーと権限、日時の扱い、履歴の保持方針は分けてはいけません。ここを分けると、二重台帳・番号の重複・退職者アカウントという形で、後から高いツケが来ます。共通土台を第0弾として先に置くこと。これが、スモールスタートを「ただの小規模開発」から「大きな目標の分解」に変える分かれ目です。

タイ・ASEANの拠点では、長いプロジェクトが人の入れ替わりをまたぐという事情が加わります。要件を決めた人が稼働まで在籍しているかどうかは、期間の長さで決まります。この点でも、3か月前後の弾に刻む進め方は理にかなっています。

最後に、本記事が参照した数値はすべて日本国内または域内の公開調査に基づくものであり、個別の工場の予測値ではありません。金額や人月単価は出典に含まれないため示していません。自社の判断は、自社の実数をベースラインに置いて行ってください。

TOMAS TECHはタイ・バンコクを拠点に、日系製造業向けの生産管理・IoT・FAシステムを手がけています。どこで切るべきか、第0弾に何を含めるべきかは、現場の業務と既存システムの状態によって変わります。第1弾の範囲設定や、共通土台の設計から相談したい場合は、お問い合わせフォームからご連絡ください。現状のヒアリングと、切り方の案の提示までを無償で対応しています。

参考情報

• JUAS『企業IT動向調査 報告書 2026』（第7章 システム開発） — 一般社団法人 日本情報システム・ユーザー協会。図表7-1-3、7-1-4、7-2-7を参照
• JUAS『企業IT動向調査2026』プレスリリース第2弾 — 調査概要（有効回答957社、調査期間2025年9月5日〜10月24日）
• JUAS 企業IT動向調査（調査の紹介ページ） — 調査の位置づけと過年度の一覧
• IPA「DX動向調査」2025年度 プレスリリース — 独立行政法人情報処理推進機構。回収数1,799社、DX推進人材の量の不足85.5%
• Thailand Job Market 2026 Outlook — RECRUITdee。昇給予算平均約4.7%、域内離職率約17.5%、経済成長率見通し約1.6%（出典元はIMF）
• JUAS『企業IT動向調査2026』プレスリリース第1弾 — 調査の公表に関する第1報