「このシステム、下手に触らないでください」
企業の情報システム部門や保守担当者から、このような言葉を聞いたことがある人は少なくないのではないでしょうか。
例えば、
「どこに影響が出るか分からない」
「改修すると別機能が壊れる」
「担当者しか構造を理解していない」
「仕様書と実装が一致していない」
といった状態です。
しかし、不思議なことに、そのようなシステムでも、日常業務自体は何とか回っている。
つまり、「動いてはいる」のです。
ただし、その代償として、企業は膨大な保守運用コストを払い続けています。
私は、日本企業の多くが、「動くが誰も触（さわ）れないシステム」を抱えていると思っています。
そして、その原因の多くは、
「技術力不足」ではなく、「業務構造を定義しないままシステム化してきたこと」
にあると考えています。
前回お話しした通り、多くの企業では、要件定義が「現場作業の収集」になっています。
つまり、「今どう運用しているか」を集め、それをシステム化していく。
しかし、本来システムとは、「作業」を実装するものではありません。
システムとは、本来、「業務構造」を実装するものです。
ところが、業務構造が定義されないまま開発が始まると、システムは“人間の調整”を前提に設計されるようになります。
例えば、
・担当者判断
・例外対応
・部門毎運用
・Excel補完
・口頭確認
といった曖昧な処理が、そのままシステムへ流れ込んでいきます。
しかし、開発初期はまだ問題が見えません。
なぜなら、コード自体は綺麗に書かれていることが多いからです。
例えば、
・共通部品
・統一ルール
・整理されたデータ構造
・整合性あるアーキテクチャ
など、開発側は本来、構造化を意識して設計しています。
ところが、総合テスト以降で、
「実業務では困る」
「この例外処理が必要」
「この部門だけ特殊運用」
といった後付け要求が大量に発生する。
そして、その都度、「このケースだけ特別対応」が積み上がっていきます。
すると、システム構造が徐々に壊れ始める。
例えば、
・条件分岐が増殖する
・データ意味が揺れる
・責任範囲が曖昧になる
・画面単位最適が始まる
・例外処理が散乱する
といった状態です。
これは、システムが“複雑”なのではありません。
本当は、「業務構造が未定義のまま、後付けで運用を吸収し続けた結果」なのです。
つまり、
「システムの複雑化」とは、多くの場合、「業務構造崩壊の結果」なのです。
しかも恐ろしいのは、この状態になると、保守運用コストが爆発的に増えることです。
例えば、小さな仕様変更一つでも、
「どこへ影響するか分からない」ため、大規模な調査と総合テストが必要になります。
さらに、
・属人化
・ブラックボックス化
・ベンダー依存
も進みます。
すると企業は、
「システムを維持するために、システムへ従う」状態へ入っていきます。
本来、システムは業務を支援するためのものだったはずです。
しかし、いつの間にか、
「システムを壊さないために業務を合わせる」ようになってしまう。
私は、この状態こそ、日本企業におけるDX停滞の本質の一つだと思っています。
しかも、多くの経営者は、「開発費」には敏感です。
しかし、本当に恐ろしいのは、その後10年、15年と続く、
・保守費
・改修費
・テスト費
・調整費
・運用負荷
なのです。
つまり、企業は、「構造を定義しなかった代償」を、長期間払い続けることになる。
では、どうすれば良いのでしょうか。
私は、その答えの一つが、「業務モデリング」だと思っています。
業務モデリングとは、単なる業務フロー整理ではありません。
本来の業務モデリングとは、
・誰が
・何を
・どのデータを使い
・どの状態へ遷移させ
・どのルールで判断するのか
を構造として定義することです。
つまり、「変更しても壊れない構造」を先に設計することです。
もし業務構造が定義されていれば、システム構造も安定します。
すると、
・コード規約
・データ定義
・API設計
・権限設計
・テスト観点
も統一しやすくなる。
つまり、「変更容易性」が高まるのです。
これは単なるIT論ではありません。
企業が、将来の変化へ耐えられるかどうかという話です。
私は、日本企業に本当に必要なのは、
「システム開発力」だけではなく、「業務構造設計力」なのではないかと思っています。
そして、その力無しに進められるDXは、最終的に、
「人力による調整をデジタルで固定化した複雑系」を量産してしまう危険があるのです。
合同会社タッチコア 小西一有
第1回 「現場に聞けば業務は分かる」という危険な誤解
第2回 「断捨離」が局所改善になる会社
第3回 日本企業は「調整」を仕事にしてしまった
第4回 なぜ要件定義でシステムが壊れるのか
…来週もこのテーマでBlogをお届けします！
