業務フローが整っていないのに「システム化しろ」と言われたときの進め方

「業務が整っていないからシステム化できない」は半分嘘

「業務フローが整理されていないのに、上から早くシステム化しろと言われている」という相談が、中堅企業のDX担当者から繰り返し届く。多くの場合、担当者は「まず業務フローを書き起こしてから要件定義へ」という王道ルートを試し、3ヶ月後に停滞する。各部署から出てくる業務フローがバラバラで整合が取れず、結論が出ない。プロジェクトが「業務整理委員会」になり、システム化のほうは一歩も動かない。

「業務が整っていないからシステム化できない」は半分嘘だ。正確には「業務が整っていないから、ウォーターフォール型の要件定義は進まない」。順序を変えれば、業務未整理のままでもシステム化は進められる。

なぜ業務整理が先に進まないのか

業務フロー整理が停滞する理由は3つある。

1. 書き出した瞬間に古くなる

現場の業務は日々変化している。だから3ヶ月かけて書き上げた業務フロー図は、書き上がった時点ですでに半分が実態と合っておらず、精度を上げようとして期間を延ばすほど、完成と実態のズレは開いていく。完璧を目指すほど到達しない構造になっている。

2. 「誰が書くか」で内容が変わる

立場が出る。現場担当者が書くと例外処理が詳細になり、管理者が書くと標準化されすぎる。複数人で書き合えば、誰の正解を採用するかで揉める。整合性を取る作業に時間が吸われていく。

3. 書き上げても「あるべき姿」かは分からない

現状の業務フローは、現状の制約に最適化された結果でしかない。システム化で何を変えるかが決まっていなければ、どれだけ丁寧に整理しても、その先の設計に手をつける根拠が出てこない。だから止まる。

逆転発想: 動かしてから整理する

業務未整理の状態で前に進める方法は、順序を逆にすることだ。要件定義 → 設計 → 開発ではなく、小さく動かす → 動いたもので業務を整理 → スケールの順で進める。これがゼロスタート型アプローチだ。

業務全体を一度に扱わない。「見積もり作成業務」「受発注の問い合わせ対応」「月次レポート作成」のような、1〜2部署の中で完結する業務をひとつ選ぶ。1ヶ月でPoCを動かし、動いた結果から業務フローを逆引きで整理する。

動かしたPoCの中では「このステップは必要」「このステップは省ける」「このステップは標準化できる」が見える。机上で書き出したものより、動いたPoCから抽出した業務フローのほうが実態に近い。整理の質と速度が、同時に上がる。

PoC設計の3つの原則

原則1: 1ヶ月以内に動くものを作る

1ヶ月を超えるPoCは机上設計の比率が増え、結局ウォーターフォールに戻る。生成AI駆動の開発を使えば、1ヶ月で動くPoCを数十万円規模で作れる時代になっている。期間と予算の制約を最初に置く。

原則2: 1〜2部署、10名以下のユーザーで始める

全社展開は目指さない。10名以下なら、業務フローの個人差を吸収しながら動かせる。10名で動いたら20名、20名で動いたら全社、という段階的な拡張を前提にする。

原則3: 撤退条件を最初に決める

走り出す前に置く。「1ヶ月後の評価で、業務時間が10%以上削減できなければ撤退」「ユーザー満足度が50%未満なら設計やり直し」といった定量的な条件を書いておかないと、PoCは結果が出ないまま惰性で続き、整理されていない業務の上に新たな負債を積み増していく。

PoCから業務整理に戻す

PoCが1ヶ月動いたら、業務整理に戻す。手順は3ステップ。

ステップ1: 利用ログから実際の業務ステップを書き出す

机上の業務フローは使わない。誰が、いつ、どの操作をしたか、どのケースで例外が起きたか。PoCを1ヶ月動かせばこれらはすべてログに残っているので、そこから書き出したものが一次資料になる。

ステップ2: 3つに分類する

抽出した業務ステップを「このまま標準化したい」「変えたい」「削りたい」に分ける。現場担当者と管理者で分類の合意を取る。実際のログを見ながら話せるので、議論が具体的になる。

ステップ3: 業務フローとして整理する

標準化したいステップは仕組みに組み込み、変えたいステップは次のPoCで改善し、削りたいステップは仕組みから外す。ここまで来ると、整理した業務フローがそのまま次のスケール展開の設計図になる。

この進め方のリスクと対処

「動かしてから整理」にもリスクはある。事前に対処を用意しておくと、関係者の不安を減らせる。

リスク1: PoCで作ったものが後から大きく作り直しになる

作り直しは想定内だ。生成AI駆動の開発では、PoCのコードをそのまま本番化しない設計が標準になっている。「PoCは検証用、本番は別途構築」を最初から前提にすれば、作り直しを失敗と捉えなくて済む。

リスク2: PoCで触れていない領域が放置される

段階的に解消する。1つ目のPoCで業務領域Aを整理し、2つ目で領域B、と並行で進める。「全領域を1年で整理」という構え方をやめ、「1領域を1ヶ月で整理、12領域を1年で整理」に切り替える。

リスク3: 経営層から「全体像が見えないまま進めるのは不安」と言われる

1枚サマリーで対処する。「1年間で整理する業務領域の一覧」「各領域のPoCタイミングと評価軸」「全領域整理後の到達点」を1枚にまとめておく。全体像は描く、ただし各領域は順次PoCで進める、という構造を明示する。

逆に、ウォーターフォール（計画先行型）が向く場面

すべての業務がPoC先行で進むわけではない。

たとえば、業務フローが法律・業界規制で厳密に定められている領域（経理の月次決算、医療記録、金融の取引履歴管理）。ここは現場の創意工夫の余地が小さく、要件定義を先にやるほうが早い。あるいは、複数システムの大規模統合（10システム以上の連携を伴う基幹刷新）。動かしてから整理では、影響範囲が大きすぎてリスクを取りにくい。

判断軸は2つ。「規制で固まっている業務か」「影響範囲が10システム以上か」のどちらかにYESがあれば、ウォーターフォール寄りで進める。どちらもNOなら、PoC先行のほうが早い。

業務整理は「結果」、システム化は「手段」

順序の問題だ。業務整理を目的化するとシステム化が遅れる。業務整理は、システム化の結果として得られるものだからだ。動くものを作って、現場が使って、ログから業務が見える。机上で書く業務フローより、ログから読み取る業務フローのほうが、はるかに実態に近い。

「システム化しろ」と言ってきた経営層が期待しているのは、業務フロー図ではない。業務が変わった結果だ。動いた結果を見せながら、業務整理も並行で進める。3ヶ月後に「動いている領域がある」状態を作れれば、業務未整理の言い訳は要らなくなる。