ここまで私は、

・調整コスト
・現場ヒアリング主義
・要件定義崩壊
・「動くが誰も触（さわ）れないシステム」

についてお話ししてきました。

そして前回は、「業務モデリングとは、仕事の設計図を作ること」だと述べました。

では、なぜ業務モデリングが重要なのでしょうか。

私は、その最大の理由の一つは、「システム構造が安定する」ことだと思っています。

ここで、多くの企業に存在する誤解があります。

それは、「システムが複雑なのは、ITの問題だ」という考え方です。

もちろん技術的問題もあります。

しかし実際には、システム構造を最も強く規定するのは、「業務構造」です。

私は以前、ある大手金融機関のCIOから、非常に興味深い話を聞いたことがあります。

そのCIOは、ある日、社長からこう言われたそうです。

「CIOさんには耳の痛い話だろうけど、当社のシステムはどうにも評判が悪い。使い勝手が悪いし、操作も複雑だ。そして運用費も莫大にかかっている。何とかしなさいよ」

多くのCIOなら、ここで、

・システム刷新
・UI改善
・クラウド化
・パッケージ導入

といった話を始めるかもしれません。

しかし、そのCIOは違いました。

彼は社長へ、こう返したそうです。

「お言葉を返すようですが、システムが複雑なのは、業務が複雑だからです。当社のシステムは、バラックの上にバラックを載せ、更にバラックで増築するような構造ですが、業務そのものが、そのようになっているのです」

これは非常に本質的な言葉だと思います。

そして彼は、さらに社長へ問い掛けました。

「ちなみに、お客さまから当社への支払方法って、何種類あるかご存知ですか？」

社長は、

「銀行口座数の話ではないよね？ まあ、せいぜい10種類程度では？」

と答えたそうです。

しかし実際には、50種類以上の支払方法が存在していたのです。

さらに商品構成も、カテゴリを横断した特殊な組み合わせが大量に存在していたと言います。

つまり、システムが複雑だったのではありません。

本当は、「業務構造そのもの」が複雑化していたのです。

ここで極めて重要なのは、この話の続きです。

その後、この社長は、本当に大規模な改革へ踏み込みました。

毎週のように、商品やサービスの打切りが日経新聞で公示され、大胆な整理を進めました。

さらに、支払方法も大幅に削減した。

この活動は、当時、「抜本改革プロジェクト」と呼ばれていたと言います。

つまり、この企業は、「システムを変える前に、業務構造を変えた」のです。

私は、ここに非常に大きな意味があると思っています。

多くの企業では、

・商品はそのまま
・例外運用もそのまま
・部門毎ルールもそのまま
・支払方法もそのまま

で、「新システムを入れれば解決する」と考えてしまいます。

しかし、それでは本質的な改善にはなりません。

なぜなら、「業務の複雑さ」が、「システムの複雑さ」へ変換されるからです。

例えば、

「この顧客だけ特別対応」
「この商品だけ別処理」
「この支払方法だけ例外運用」

が増えれば、当然システム側には大量の条件分岐が必要になります。

すると、

・コード肥大化
・データ整合性崩壊
・テスト範囲増殖
・影響範囲不明

が始まる。

つまり、「業務の曖昧さ」だけではなく、「業務の複雑さ」そのものが、システム複雑化へ変換されるのです。

逆に言えば、業務モデリングが出来ている企業では、「何を共通構造として持つか」が定義されます。

例えば、

・顧客定義
・契約定義
・承認定義
・支払定義
・状態定義

が統一される。

すると、

・データ構造
・API設計
・ワークフロー
・権限設計

も安定しやすくなります。

さらに重要なのは、「変更容易性」です。

本当に強い企業とは、「変更しない企業」ではありません。

「構造を壊さずに変更出来る企業」です。

そのためには、「どこを変えてはいけないか」を定義しなければなりません。

つまり、「共通構造」を持つ必要があるのです。

そして、その土台になるのが、「業務モデリング」です。

私は、多くの企業で必要なのは、「システム刷新」より前に、「業務複雑性を減らすこと」だと確信しています。

なぜなら、シンプルな業務構造無しに、

・DX
・AI活用
・データ活用
・内製化

を進めても、最終的には、「複雑性をデジタル化しただけ」になってしまう危険があるからです。

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

「システムを変えること」だけではなく、「業務構造をシンプルにする勇気」だと考えています。

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

[先週からの関連Blog]

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

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

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

第4回 なぜ要件定義でシステムが壊れるのか

第5回 「動くが誰も触（さわ）れないシステム」が完成する 

第6回  業務モデリングとは「仕事の設計図」である