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

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

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

「業務が整っていないからシステム化できない」は半分嘘だ。正確には「業務が整っていないから、ウォーターフォール型の要件定義は進まない」。順序を変えれば、業務未整理のままでもシステム化は進められる。本記事では、業務未整理の状態から抜ける「PoCで動かしながら業務を整理する逆転発想」を整理する。

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

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

第1に、業務フローは「書き出した瞬間に古くなる」性質を持つ。現場の業務は日々変化している。3ヶ月かけて書き上げた業務フロー図は、書き上がった時点で半分は実態と合っていない。完璧な業務フローを目指すほど、目標に到達しない構造になる。

第2に、業務フローは「誰が書くか」で内容が変わる。現場担当者が書くと例外処理が詳細になり、管理者が書くと標準化されすぎる。複数人で書き合うと、誰の正解を採用するかで揉める。整合性を取る作業に時間が吸われる。

第3に、業務フローを書き上げても、それが「あるべき姿」かは分からない。現状の業務フローは、現状の制約に最適化された結果だ。システム化で何を変えるかが決まっていないと、整理しても次のステップに進めない。

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

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

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

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

PoC設計の3つの原則

業務未整理の状態から始める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の利用ログから、現実に発生した業務ステップを書き出す。机上の業務フローではなく、実データから抽出する。誰が、いつ、どの操作をしたか、どのケースで例外が起きたか。データが一次資料になる。

ステップ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ヶ月後に「動いている領域がある」状態を作れれば、業務未整理の言い訳は不要になる。