古いプログラミング言語や複雑なシステム構成が、よく原因として挙げられます。
でも、コンサルタントとして業務やシステムを見ていると、レガシー化の本質は技術だけではないと感じます。
組織変更に対応するための承認ルート。
一部の取引先だけに必要な例外処理。
過去のトラブルを防ぐために追加された確認項目。
担当者が変わっても残り続ける、用途の分からない機能。
それぞれは、追加された当時には合理的な判断だったはずです。
問題は、新しいルールや機能が増える一方で、古いものを「やめる判断」がほとんど行われないこと。
その結果、誰も全体を説明できないけれど、影響が怖くて消せないシステムが出来上がっていきます。
そして刷新プロジェクトでも、「現行業務を変えると混乱するから」という理由で、既存の仕組みをそのまま新しいシステムへ移してしまう。
技術は新しくなっても、過去の意思決定は残ったままです。
ここに、デザインが果たせる役割があるのではないか？と思っています。
今の画面を使いやすくするだけではなく、
「この業務は、そもそも誰のためにあるのか」
「このルールは、今も必要なのか」
「どんな働き方を実現したいのか」
という問いから、業務と体験を設計し直すこと。
基幹システム刷新で本当に難しいのは、新しいものをつくることではなく、過去の正解を捨てることなのかもしれません。
