私は長年、企業のシステム導入や業務改革に関わる中で、非常に不思議に感じてきたことがあります。

それは、多くのシステム開発プロジェクトが、「最初は綺麗だった」ということです。

開発初期には、

・整理された要件定義書
・綺麗なシステム構成図
・統一されたデータ設計
・整合性のあるアーキテクチャ

が存在しています。

しかし、プロジェクト後半になると、急速に崩れ始める。

そして最終的には、

・例外処理だらけ
・条件分岐だらけ
・Excel補完だらけ
・属人運用だらけ

になっていく。

なぜ、こうなるのでしょうか。

私は、その原因の多くは、「要件定義」そのものにあると思っています。

ただし、ここで誤解して欲しくないのは、

「要件定義が不要だ」と言いたい訳ではありません。

問題なのは、「何を要件として定義しているのか」です。

多くの企業では、要件定義が、「現場作業の収集」になっています。

つまり、

「今、何をしていますか？」を大量にヒアリングし、その内容を要件定義書へ整理していく。

しかし、ここには重大な問題があります。

それは、現場担当者が説明しているのは、多くの場合、「作業」であって、

「業務構造」ではないということです。

例えば、

・どの画面を開くか
・どのExcelを使うか
・どの順番で入力するか
・誰へメールするか

といった説明は出来ます。

しかし、

・なぜその処理が必要なのか
・そのデータは何を意味しているのか
・他部門とどう関係しているのか
・本来どうあるべきなのか
・将来変更時に何を守るべきなのか

までは整理されていないケースが非常に多い。

つまり、多くの要件定義は、「現状作業の写経」になってしまっているのです。

これは非常に危険です。

なぜなら、システムは本来、「作業」を実装するものではなく、

「業務構造」を実装するものだからです。

ところが、業務構造が定義されないまま開発が始まると、システム側は“人間の運用”を前提に実装せざるを得なくなります。

すると、

・曖昧な判断
・属人的運用
・例外対応
・部門毎の特殊ルール

が、そのままシステムへ流れ込んでいきます。

しかし、開発初期はまだ問題が見えません。

なぜなら、設計上は綺麗に整理出来ているように見えるからです。

問題は、総合テストやユーザーテストの段階で発生します。

ここで突然、

「実業務では困る」
「現場運用に合わない」
「この例外処理が抜けている」
「部門間調整が考慮されていない」

といった“業務的ダメ出し”が大量に出始めます。

私は、この瞬間こそが、多くのプロジェクトの分岐点だと思っています。

なぜなら、この段階で初めて、「本当の業務」が出現するからです。

つまり、要件定義の段階では、まだ業務構造が定義されていなかった。

だから後半になって、「運用」という形で、業務構造が噴き出してくるのです。

しかし、その時には既にシステム構造は固まり始めています。

本来、システム設計とは、

・データ構造
・状態遷移
・責任分界
・処理整合性

を保ちながら構築するものです。

ところが、後付けで業務的修正を繰り返すと、その構造が徐々に壊れていきます。

例えば、

「このケースだけ特別対応」
「この部門だけ別ルール」
「このデータだけExcel管理」
「この承認だけメール対応」

といった“局所改修”が積み上がる。

すると、

・条件分岐が増殖する
・データ意味が揺れ始める
・処理整合性が崩れる
・影響範囲が読めなくなる

という状態へ進んでいきます。

そして、企業はその後、何年にも渡って、「構造を壊した代償」を払い続けることになります。

私は、多くの企業で必要なのは、「現場ヒアリング能力」ではなく、

「業務構造定義能力」なのではないかと思っています。

つまり、本来、要件定義の前に必要なのは、

「この会社の業務構造をどう設計するのか」を定義することなのです。

これは単なるシステム論ではありません。

企業活動そのものを設計するという話です。

そして、この視点が抜け落ちたまま進められるDXは、最終的に、

「調整をデジタル化しただけ」になってしまう危険があります。

私は、日本企業に本当に必要なのは、

「現場作業の整理」ではなく、「業務構造の設計」

なのではないかと思っています。

合同会社タッチコア　小西一有

[今週のBlog]

第1回 「現場に聞けば業務は分かる」という危険な誤解 

第2回 「断捨離」が局所改善になる会社

第3回 日本企業は「調整」を仕事にしてしまった