「現場に聞けば業務は分かる」

日本企業の多くが、この考え方を前提にシステム開発を進めています。

そして、私はこの考え方こそが、日本企業のDXがうまく進まない根本原因の一つだと考えています。

もちろん、現場は重要です。
実際に業務を遂行しているのは現場ですし、現場を無視してシステム開発を進めることは出来ません。

しかし、ここで非常に重要な論点があります。

それは、

「現場が知っていること」と、
「システム開発に必要なこと」は、
必ずしも一致しないということです。

多くの経営者は、

「現場が一番業務を知っているのだから、現場に聞けば要件は整理出来る」と考えています。

しかし実際には、現場が知っているのは、多くの場合「自分の作業」です。

一方で、システム開発に本当に必要なのは、

・業務全体の流れ
・部門間の関係
・データの意味
・判断ルール
・責任分界
・状態遷移
・例外処理
・将来変更時の整合性

といった、「業務構造」です。

つまり、「作業知識」と「構造知識」は違うのです。

ところが、日本企業ではこの二つが混同されることが非常に多い。

その結果、要件定義が「現場ヒアリング大会」になってしまいます。

例えば、システム開発の初期段階では、

「今、どのような業務をしていますか？」

というヒアリングが大量に行われます。

そして、現場担当者は、自分が普段行っている処理を説明します。

しかし、その説明には、往々にして、

・なぜその処理が必要なのか
・他部門とどう繋がっているのか
・そのデータは何を意味しているのか
・どのような例外が存在するのか
・本来どうあるべきなのか

が抜け落ちています。

なぜなら、現場担当者自身が、業務全体を構造として見ていないからです。

これは、現場が悪いという話ではありません。

そもそも日本企業では、「業務を構造として設計する」という教育を、ほとんど行ってこなかったのです。

そのため、多くの企業では、「現状作業をそのままシステム化する」ことが、要件定義になってしまう。

しかし、本来システムとは、「作業」を実装するものではありません。

システムとは、本来、「業務構造」を実装するものです。

ここを間違えると、プロジェクトは後半で必ず苦しくなります。

なぜなら、要件定義の段階では見えていなかった「業務」が、後から出現するからです。

例えば、総合テストやユーザーテストの段階になると、突然、

「実業務では困る」
「この部門との連携が考慮されていない」
「この判断では現場が回らない」
「例外処理が抜けている」

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

ここで、多くのプロジェクトは慌てて改修を始めます。

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

本来、システム開発では、

・データ構造
・責任分界
・処理フロー
・状態管理

などを整合性を持って設計します。

ところが、後付けで業務的修正を繰り返すと、その構造が崩れ始める。

すると、

・条件分岐が増殖する
・例外処理が散乱する
・Excelによる裏管理が始まる
・部署毎の特殊運用が増える
・システム全体の整合性が壊れる

という状態になっていきます。

そして最終的には、「動くが、誰も触（さわ）れないシステム」が完成します。

これは、日本企業で極めて頻繁に起きています。

しかも問題は、開発費ではありません。

本当に恐ろしいのは、その後の保守運用コストです。

少し仕様変更をするだけで、「どこに影響が出るか分からない」という状態になり、改修コストとテストコストが爆発的に増えていく。

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

では、本来どうあるべきなのでしょうか。

私は、その答えの一つが、「業務モデリング」だと考えています。

業務モデリングとは、単なる業務フロー図作成ではありません。

本来の業務モデリングとは、

「誰が、何を、どの順番で、どの情報を使い、どのような判断を行い、何を生み出すのか」

を構造として定義することです。

つまり、「仕事の設計図」を作ることです。

そして、この業務構造が定義されて初めて、

・システム構造
・データ構造
・権限構造
・ワークフロー
・KPI

を整合性を持って設計出来るようになります。

DXとは、本来、単なるシステム導入ではありません。

業務構造を再設計することです。

しかし、日本企業の多くは、そこを飛ばしてしまう。

だから、

「DXを進めるほど調整が増える」

という現象が起きるのです。

私は、日本企業に本当に必要なのは、「現場ヒアリング能力」

ではなく、「業務構造設計能力」ではないかと思っています。

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