- デジタル化の最終段階 (段階4) に到達したと回答した企業はわずか 2.8% で、2023 年 6.9%・2024 年 3.2% から続落している (2026 年版 中小企業白書)。
- システム開発で工期が遅延した原因を分析すると、55% が要件定義の問題に起因する (IPA「要件定義を巡る課題」2019 年)。業務フローを描かずに要件定義へ進むと、遅延の主要因を最初から抱え込むことになる。
- 解決の方向性は 「理想形 (to-be) を先に描かない」。まず現状 (as-is) を例外処理まで含めてそのまま図にし、その上で変える部分と変えない部分を線引きする。
「業務フローを図にしたことは一度もありません。毎日みんな頭の中で回しています」── 中小卸の経営者や現場責任者から、こうした話を伺うことが珍しくありません。システム化やSaaS導入の相談を受けたベンダーやSIerから「まず現状の業務フローを教えてください」と聞かれても、誰が・いつ・どんな判断で仕事を回しているかを図にしたものが社内に存在せず、答えに詰まってしまう場面です。
この記事では、中小企業のDX着手状況と要件定義の失敗要因に関する最新の統計を確認した上で、中小卸がシステム化に着手する前に業務フローをas-is (現状) / to-be (理想形) で整理する実務的な進め方と、既製品のヒアリングでは拾いきれない落とし穴を解説します。
数字で見る、中小卸の業務フロー整理とDXの現状
- デジタル化の最終段階 (段階4) に到達した企業: 2.8% にとどまり、2023 年 6.9%、2024 年 3.2% から続落。多くの企業がツール導入止まりで、業務プロセスの再設計まで進めていない (2026 年版 中小企業白書・小規模企業白書の概要)。
- ツール導入で満足してしまう構造: 会計ソフトやチャットツールを導入しただけで、その先の業務プロセス再設計やデータ活用による意思決定の高度化まで進めていない企業が大半。受注から請求までの流れを図にすると、負担の大きい工程やボトルネックが見えやすくなると指摘 (2025 年版 中小企業白書 第 5 節 デジタル化・DX)。
- 取り組みと成果の差: 日本企業の約 8 割が何らかの形でDXに取り組んでいる一方、成果を実感しているのは 6 割以下。成果を測る指標を設定している企業は 3 割以下 で、米国・ドイツ (共に 8 割以上) と大きな差がある (IPA「DX動向2025」)。
- 工期遅延の主要因: システム開発プロジェクトの工期遅延理由を分析すると、55% が要件定義の問題に起因し、残り 45% がプロジェクト管理の問題 (IPA「要件定義を巡る課題、経営者が考慮しなければならないポイント」2019 年)。
- 業務プロセスは経営指標の一部: 経済産業省「DX推進指標」は「戦略・経営ビジョン」「組織・人材」「テクノロジー・データ」「業務プロセス」の 4 領域からなる自己診断指標として 2019 年 7 月に策定され、2025 年 1 月の検討会を経て設問・成熟度レベルが改訂された (経済産業省「DX推進指標」)。
これらの数字が示すのは、多くの中小卸が「ツールを入れる」段階で足踏みし、業務プロセスそのものを見直す段階に進めていない実態です。同時に、システム開発の遅延要因の過半数が要件定義にあるということは、業務フローを図にしないまま要件定義に進むと、遅延の主要因を最初から抱え込むことを意味します。
業種別シナリオ ── 業務フロー整理でつまずく典型パターン
以下は複数のご相談を再構成した代表シナリオであり、実在の特定企業を指すものではありません。
シナリオ 1: 精肉卸 (受発注から加工指示までの流れが誰の頭にもない)
受発注・加工指示・出荷確認までの一連の流れを、一度も図にしたことがない精肉卸のケース。システム化の相談でSIerから「現状の業務フローを教えてください」と聞かれ、経営者・営業担当・加工責任者それぞれの答えが微妙に食い違い、結局「誰かに聞かないと分からない」まま話が止まってしまった。
シナリオ 2: 青果卸 (営業担当だけへのヒアリングで例外処理が抜け落ちる)
営業担当者だけへのヒアリングでas-is (現状) の業務フロー図を作成した青果卸のケース。実際には仲卸を通す規格外品の受け入れ手順や、特売時の緊急発注ルートが現場の別の担当者しか知らない例外として存在していたが、図には反映されず、要件定義が固まった後になって「これでは実際の業務と違う」と手戻りが発生した。
シナリオ 3: 食品卸 (現状を描かずいきなり理想形の仕様を書いてしまう)
現状 (as-is) の業務フローを描かないまま、いきなり理想形 (to-be) のシステム要件を書き始めた食品卸のケース。営業事務担当が日々行っている取引先別の例外処理 (掛率の個別調整や請求書フォーマットの読み替えなど) が仕様に反映されず、稼働直前になって「このままでは現場が回らない」と判明し、追加開発が発生した。
解決の核 ── 現状(as-is)を描き切ってから、変える部分だけを選ぶ
業務フロー整理で最初に守るべき鉄則は、「理想形 (to-be) を先に描かない」 ことです。
具体的には:
- 現状 (as-is) をそのまま図にする。誰が、いつ、どんな判断材料で、どの順番で仕事を回しているかを、改善案を挟まずに描き切る。
- 例外処理・属人的判断も削らずに残す。「ベテランだけが知っている特殊対応」ほど、システム化の失敗要因になりやすい。
- as-isが描き終わってから、初めて「変える部分」を選ぶ。すべてを変える前提ではなく、現場が困っている箇所だけを対象にする。
- to-beは「変える部分」と「変えない部分」の線引き図として設計する。変えない部分は既存の運用のまま残し、判断材料の見え方だけを画面に足す。
このアプローチは、ヒアリング担当者の解釈や理想論を先に持ち込まず、現場の実態をそのまま起点にする 構造です。既存の運用を残したまま判断材料の見え方だけを画面で共有する「現場を変えない開発」の思想は、業務フロー整理の段階から一貫しています。
既製品で足りない理由
- ヒアリングが「標準フロー前提」の質問票: SaaSベンダーやSIerのヒアリングシートは、既製品の標準機能に合わせた質問で構成されており、自社特有の例外業務を拾う設計になっていない。
- 業務フロー図のテンプレートが業種横断の一般形: 汎用テンプレートは卸売業特有の例外 (規格外品の受け入れ、特売時の緊急発注、返品処理、取引先別条件) を想定していない。
- 現状把握に時間と費用をかけずにいきなり理想形へ進む商流: as-isの整理を省き、理想形の要件定義から始める提案が多く、現場の実態とのズレが後工程で顕在化する。
- フロー図が「絵」で終わり、要件定義書の粒度まで落ちない: 業務フロー図を成果物として提出しても、そこから要件定義書や画面仕様に落とし込む工程が別途必要になり、担当者任せになりがち。
取り組み方の 3 ステップ
- 現状 (as-is) の可視化 (2〜3 週間): 経営者だけでなく現場の複数担当者にヒアリングし、例外処理・属人的判断も含めて業務フロー図を描く。「変えない宣言」を現場に明示し、警戒を解く。
- ボトルネックの特定と線引き (2〜4 週間): as-isの中から現場が実際に困っている箇所を特定し、「変える部分」と「変えない部分」を線引きする。線引きが終わってから理想形 (to-be) を設計する。
- 段階的なシステム化 (1〜2 ヶ月〜): 優先順位に沿って、変える部分から要件定義書と画面ラフに落とし込み、現場でレビューしながら進める。変えない部分は既存の運用のまま残す。
まとめ
業務フロー整理の本質は、きれいな図を作ることではなく、「今の業務をありのまま描き切ってから、変える部分だけを選ぶ」順序を守ること にあります。理想形を先に描いてしまうと、現場の例外処理や属人的判断が仕様から抜け落ち、要件定義後の手戻りにつながります。工期遅延の過半数が要件定義に起因するという事実は、この順序を守ることの重要性を裏付けています。as-isを丁寧に描き切ることが、結果としてシステム化を最短で現場に定着させる道になります。
引用元
- 中小企業庁・経済産業省「2026 年版 中小企業白書・小規模企業白書の概要」(2026 年 4 月) — meti.go.jp/press/2026/04/20260424005/20260424005-1r.pdf
- 中小企業庁「2025 年版 中小企業白書 第 5 節 デジタル化・DX」— chusho.meti.go.jp/pamflet/hakusyo/2025/chusho/b1_1_5.html
- 独立行政法人情報処理推進機構 (IPA)「DX動向2025 日米独比較で探る成果創出の方向性」— ipa.go.jp/digital/chousa/dx-trend/dx-trend-2025.html
- 独立行政法人情報処理推進機構 (IPA)「要件定義を巡る課題、経営者が考慮しなければならないポイント」(2019 年) — ipa.go.jp/archive/files/000072721.pdf
- 経済産業省「DX推進指標」— meti.go.jp/policy/it_policy/investment/dx-shihyo.html
最初の 60〜90 分のヒアリングから、整理メモと画面ラフ・松竹梅プランのお渡しまで、費用は発生しません。 「業務フローを一度も図にしたことがない」「SIerに現状を聞かれても答えられない」「理想形から要件定義に入って現場と食い違った」段階で大丈夫です。