はじめに：業務フローが見えないままシステム刷新を始める危険性
こんにちは。ソフトウエア・サイエンス ビジネスソリューション事業部の実川です。業務可視化から基幹システム刷新、データ活用までの一貫支援を専門に行っています。
さて、システム刷新プロジェクトの初期段階で、私がよく確認することがあります。「現在の業務フローは整理されていますか？」という質問です。
この質問に対して、実際には次のような答えが返ってくることが少なくありません。「頭の中にはあるんですけど……図にはなっていなくて」
日々の業務が問題なく回っていると、業務フローをあえて図や資料として整理する機会は多くありません。担当者が長年の経験で業務を理解しており、現場としては大きな支障がないように見えるからです。
しかし、業務フローが未整備のままシステム刷新を始めることには、大きなリスクがあります。関係者ごとに業務の理解がずれたり、要件定義が口頭ベースになったり、データ移行で「どのデータを正とするか」が決められなかったりするためです。システム刷新を成功させるには、新しいシステムの機能だけでなく、現在の業務がどのように流れているのかを見える形にすることが欠かせません。
この記事では、業務フローが未整備のままシステム刷新を始めることで起こりやすいリスクと、刷新前に確認しておきたいポイントを整理します。
この記事でわかること
- 業務フローが未整備のままシステム刷新を始めると、なぜプロジェクトが止まりやすくなるのか
- 要件定義やデータ移行で起こりやすい問題
- 関係者間の認識ズレが、システム刷新に与える影響
- システム刷新前に整理しておきたい業務フローの確認ポイント
この記事はこんな方におすすめです
- 基幹システムや業務システムの刷新を検討している情報システム部門の担当者
- 現行業務が属人化しており、業務フローが十分に整理されていないと感じている方
- 要件定義やデータ移行で手戻りが起きないか不安を感じている方
- 現場部門、情報システム部門、ベンダー間の認識合わせに課題を感じている方
私たちはこれまで、業務フローの可視化から要件整理、システム刷新までを一貫して支援してきました。特に、属人化した業務の整理や、現場と情報システム部門の認識合わせを重視した支援を行っています。
業務フロー未整備は、地図を持たずに引っ越しをするようなもの
システム刷新を、古くなった家から新しい家への「引っ越し」に例えてみましょう。
引っ越しをするときには、どの荷物を新居に持っていくのか、どの家具を処分するのか、どこに何を置くのかを整理します。もし荷物の中身も、置き場所も、運ぶ順番も分からないまま引っ越しを始めたらどうなるでしょうか。「必要なものが見つからない」「同じものを何度も運ぶ」「新居に置けない荷物まで運び込んでしまう」といった事態になり、結果として、時間も費用も余計にかかってしまいます。
システム刷新も全く同じです。業務フローが整理されていない状態でプロジェクトを始めると、今の業務がどのように流れているのか、どこで誰が判断しているのか、どのデータがどこで発生しているのかが見えません。その結果、要件定義、設計、データ移行、テストといった工程で、後から確認しなければならないことが雪だるま式に増えていきます。
業務フロー未整備で起きやすいこと
- 関係者ごとに業務の理解がずれる
- 要件定義が口頭説明に頼り、抜け漏れが起きる
- 実際の運用とシステム仕様の違いが見えにくい
- データ移行時に「正しいデータ」の判断が難しくなる
- 予算やスケジュールが決まった後に、本質的な業務課題が見えてしまう
たとえば、「同じ受注処理でも担当者ごとにExcel管理の方法や承認タイミングが異なる」といったケースは、実務上よく見られます。
「業務フローはどこにありますか？」という質問で見えてくること
ある基幹システム刷新プロジェクトで、私はプロジェクト開始直後のヒアリング時に、必ず「業務フローはどこにありますか？」という質問をしていました。しかし、返ってくる答えはほとんど決まっていました。「頭の中にはあるんですけど……図にはなっていなくて」というものです。
多くの企業では、業務の進め方が長年の経験の中で自然と定着しています。担当者はそれぞれの業務を理解しており、日々の仕事は問題なく回っています。そのため、あえて業務フローとして整理する機会が少なく、業務の知識が「担当者の頭の中」に属人化して蓄積されているケースが多いのです。
日常業務が回っている間は、この状態でも大きな問題として見えにくいかもしれません。しかし、システム刷新のように業務全体を見直す場面では、この「見える化されていない業務」がプロジェクトを阻む大きな障害になります。
基幹システム刷新プロジェクトで実感したリスク
私は以前、情シス側で経営企画業務領域のPLとして、電気・建設業における大規模な基幹システム刷新プロジェクトに携わりました。対象となった業務は以下のような広範な領域です。
- 営業・見積・受注業務
- 下請け発注および費用管理
- 財務・会計業務
長年にわたりスクラッチ開発で拡張されてきた複数のシステムを整理し、次期基幹ERPへ移行するという大きな取り組みでした。このプロジェクトを通じて、私が強く実感したことがあります。それは、「業務フローが整理されていない状態で始まるシステム刷新プロジェクトは、必ずどこかで止まる」ということです。
当初、このプロジェクトは3年計画でスタートしましたが、最終的には4年の歳月を要することになりました。遅延の原因は一つではありませんが、業務フローが整理されていなかったことで、関係者間の認識合わせやデータ移行の判断に多くの時間を費やしたことは間違いなく大きな要因でした。特に影響が大きかったのは、データ移行と要件定義の工程です。業務ごとの前提が揃っていないため、同じデータについても解釈が分かれ、方針の合意形成に多大なリソースを消費することになりました。
リスク1：関係者ごとに業務の認識がずれる
プロジェクト開始当初、現場にはAS-IS（現状業務）やTO-BE（あるべき業務）の整理が存在していませんでした。そのため、業務の理解は基本的に口頭ベースの説明に頼るしかありませんでした。
しかし、実際にヒアリングを進めていくと、「同じ業務でも担当者によって説明が異なる」「部署ごとに『正しい手順』が微妙に違う」「システム仕様と実際の運用が一致していない」といった問題に次々と直面しました。
システム刷新プロジェクトには、各部門のユーザー、情シス内の既存サブシステム担当者、次期ERPベンダーの担当者など、さまざまな関係者が参加します。それぞれが異なる前提で議論をしているため、業務内容の認識を合わせるだけでも膨大な時間を要しました。現場、情報システム部門、ベンダーが同じ業務理解を持っていることが成功の絶対条件ですが、業務フローがなければ、それぞれが自分の経験を前提に議論を進めてしまうため、要件定義の前段階で空中分解を繰り返すことになります。
認識ズレが起きると発生しやすい問題
- 要件定義の前提が合わない
- 会議のたびに同じ業務確認が繰り返される
- 設計後に「実際の業務と違う」と判明する
- 部門間で合意形成が進まない
業務フローがあれば、どの部門が、どのタイミングで、どの情報を使って判断しているのかを共通の地図として確認できます。この土台がない議論は手戻りを生む原因となります。
リスク2：要件定義が口頭ベースになり、手戻りが増える
業務フローが未整備の状態では、要件定義も口頭での説明に頼りがちになります。口頭での説明は、その場では理解できたように感じますが、後から確認すると聞き手によって解釈が異なっていたり、重要な例外処理が抜け落ちていたりするリスクが極めて高くなります。
その結果、設計や開発が進んだ後に、「実際の業務ではこの手順では進められない」「このケースの処理が考慮されていない」といった致命的な手戻りが発生しやすくなります。こうした手戻りは、プロジェクトのスケジュールやコストに壊滅的な影響を与えます。
特に基幹システムの刷新では、一つの業務変更が複数の部門やサブシステムに連鎖します。そのため、業務フローが未整備のまま要件定義を進めると、影響範囲の確認がすべて後追いになり、プロジェクト後半の品質低下を招きます。
要件定義前に確認したいこと
- 通常業務だけでなく、例外処理も整理されているか
- 承認やチェックの流れが明確になっているか
- 部門間の受け渡しが見える形になっているか
- 現行システムの仕様と実際の運用の違いが把握できているか
SSIでは要件定義に入る前に、業務一覧、業務フロー図（AS-IS）、業務課題一覧などの整理を行い、前提となる業務認識を明文化します。例外処理や部門間の受け渡しについても事前に可視化することを徹底しています。
リスク3：データ移行で「どのデータを正とするか」が決められない
特に大きな課題となったのがデータ移行です。既存システムから新しいERPへデータを移行する際には、「どのデータを正とするのか」という厳密な基準が必要になります。しかし、業務フローが整理されていない現場では、その基準自体が曖昧でした。
「データの意味を確認する」「正しい値を特定する」「移行対象データを判断する」といった作業を一つひとつ手探りで確認する必要があり、データ移行の方針検討だけで数ヶ月単位の遅延が発生しました。
業務フローが整理されていないということは、単に業務手順が見えないだけではありません。業務とデータの相関関係（ライフサイクル）も見えなくなるということです。システム刷新においてデータ移行は避けて通れない最難関の工程だからこそ、どの業務で、どのデータが発生・更新されるのかを整理しておく必要があります。
データ移行前に確認したいこと
- そのデータは、どの業務プロセスで発生するのか
- どの部門・担当者が入力、更新、承認しているのか
- 同じ意味を持つデータが複数システムに存在していないか
- 正とするデータは、どのシステム・帳票・台帳なのか
- 移行対象に含めるデータと、移行しないデータの基準は明確か
- 移行後の新システムで、そのデータをどのように使うのか
これらが整理されていないと、データ移行の工程で判断が完全にストップします。SSIでは、既存システムの仕様調査やデータ構造の整理、データ項目ごとの意味定義の明確化から、移行対象データの選定・クレンジング方針の整理までトータルで支援を行っています。
リスク4：予算確定後に「本来あるべき業務」が見えてしまう
もう一つ、プロジェクト推進上で大きな気づきがありました。それは、業務フローを整理していく過程で、「本来あるべき業務（TO-BE）」が既存システムの制約によって歪められていた事実が、後から見えてきたことです。
しかし、その本質的な課題が見えてきた時点では、すでにプロジェクト予算や開発スコープが確定していました。そのため、システム化による解決を諦め、多くの部分を運用のマンパワーで補うしかありませんでした。これは、システム刷新の投資対効果（ROI）を著しく下げる大きなリスクです。
本来であれば、刷新前の超上流段階で現行業務を整理し、どこをシステム化し、どこを業務改善（BPR）するのかを仕分けておくべきです。業務フローの整理は「要件定義が始まってから行う作業」ではなく、刷新プロジェクトの投資判断・計画段階で行うべき作業だといえます。
業務フローの見える化は、プロジェクトを前に進める共通言語になる
こうした状況を改善するため、私たちが最初に取り組んだのは既存業務の徹底的な見える化でした。具体的には、以下の3つのレイヤーでドキュメントを段階的に整備しました。
- 業務全体を俯瞰できる鳥瞰的な「全体業務フロー」の作成
- 既存サブシステム単位での「詳細業務フロー」の作成
- 次期ERPのサブシステム単位での「TO-BE運用フロー」の整理
これらを現場・情シス・ベンダーの関係者と何度もすり合わせることで、少しずつ共通認識が生まれていきました。業務フローの見える化は、単に資料を作ることが目的ではありません。利害関係者が同じ前提で議論するための「共通言語（土台）」を作ることが真の目的です。
業務フローを整理するときのポイント
- 最初から細かくしすぎず、まずは全体を俯瞰できる形にする
- 関係者とすり合わせながら、段階的に粒度を細かくする
- 現行業務（AS-IS）とあるべき業務（TO-BE）を完全に分けて考える
- システムの仕様と、実際の運用の乖離（ギャップ）を確認する
具体的には、業務一覧、レベル別の業務フロー図、システム関連図、データ関連図などの成果物を段階的に整備しながら関係者レビューを繰り返すことで、認識のズレを早期に解消していきます。
システム刷新前に確認しておきたいチェックリスト
システム刷新を始める前には、少なくとも次のような点を確認しておくことが重要です。すべてを最初から完璧に整理する必要はありませんが、関係者が同じ前提で議論できる状態を作ることは、手戻りを防ぐ防壁となります。
| 確認項目 | 確認したいこと |
|---|---|
| 現行業務の流れ | 業務の開始から完了までの流れが見える形になっているか |
| 部門ごとの違い | 部署や担当者によって手順が異なる部分を把握できているか |
| 例外処理 | 通常業務だけでなく、イレギュラー対応も整理されているか |
| 属人的な運用 | 特定の担当者しか分からない判断や作業が残っていないか |
| システムと実運用の差 | 現行システムの仕様と実際の業務が一致しているか |
| データの発生元 | どの業務で、どのデータが発生・更新されるか整理できているか |
| AS-IS / TO-BE | 現状業務とあるべき業務を分けて整理できているか |
業務フロー未整備のまま進めた場合によくある課題
- 要件定義で同じ確認を何度も繰り返してしまう
- 現場ごとに説明が異なり、正しい業務手順を決められない
- 例外処理が後から判明し、仕様変更や設計変更が発生する
- データ移行時に、どのデータを正とするか判断できず検討が止まる
- 予算確定後に、本来改善すべき本質的な業務課題が見えてしまう
- 稼働後に現場から「実際の業務に合わない」という不満が噴出する
実際の現場では、業務整理を後回しにした結果、要件定義の途中で前提が崩れて設計をやり直すことになったケースが後を絶ちません。手戻りのないシステム開発へと導くためには、事前の可視化が不可欠です。
よくある質問
Q. 業務フローがないままシステム刷新を始めると、何が問題になりますか？
関係者ごとに業務の理解がずれ、要件定義の手戻り、設計変更、データ移行の判断遅れなどが発生しやすくなり、結果としてプロジェクトの遅延やコスト超過を招きます。
Q. 日常業務が問題なく回っていても、業務フローを整理する必要はありますか？
必要です。日常業務が回っているのは担当者の「頭の中の経験」に依存しているため（属人化）、システム刷新のように全体構造を見直す場面では、ベンダーや他部門と共通認識を持つための「見える形」のドキュメントが不可欠です。
Q. 業務フローはどの粒度で作成すべきですか？
最初から細かく作り込みすぎる必要はありません。まずは大枠の業務一覧や全体俯瞰フローから着手し、その後、部門別・システム別に段階的に粒度を細かくしていくアプローチが最も効果的です。
Q. 業務フローの整理は、システム刷新のどのタイミングで行うべきですか？
プロジェクトの計画段階（超上流工程）で行うべきです。要件定義が始まってから整理すると、予算やスケジュールが確定した後に本質的な課題が見つかり、対応できなくなるリスクがあります。
Q. 業務フローを整理すれば、システム刷新は必ず成功しますか？
業務フローの整理だけでシステム刷新が必ず成功するわけではありません。しかし、関係者間の認識ズレを最小限に抑え、データ移行や要件定義における最大の手戻りリスクを排除するための重要な土台になります。
まとめ
業務フローが未整備のままシステム刷新を始めると、要件定義、データ移行、関係者間の合意形成など、あらゆる局面でプロジェクトが失速します。本記事の重要ポイントは以下の通りです。
- 業務フローの不在は、関係者間の認識ズレと要件定義の泥沼化を招く
- 口頭ベースの要件定義は、例外処理の漏れによる後半の大手戻りを発生させる
- データ移行の基準（正本データ）を特定するためには、業務とデータの相関可視化が不可欠
- 業務フローの整理は「計画・投資判断」の段階で行うことで、初めてROIが最大化する
システム刷新を成功させるためには、最新のIT技術や機能だけでなく、その前提となる「業務の整理」という超上流の土台作りが欠かせません。刷新プロジェクトを確実に前へ進めるために、まずは現行業務を見える形にすることから始めてみませんか。
- システム刷新を進めたいが、現行業務をどこまで整理すべきか分からない
- 業務フローが属人化しており、要件定義の手戻りが不安である
- データ移行で、どの情報を「正」とすべきか判断に迷っている
- 独自の開発方法論（PmSQETs）に基づく、超上流からの確実なシステム刷新を行いたい
このような課題をお持ちの場合は、SSI（株式会社ソフトウエア・サイエンス）にご相談ください。数々の大規模基幹システム刷新を成功させてきた実績をもとに、業務フローの可視化から要件整理、安定した運用保守まで一貫して支援します。