多くの企業には、誰もが不満を漏らすシステムが少なくとも1つはあります。古くて、見た目も時代遅れで、限られた人しか理解していない。当然「なくしてしまいたい」と思うでしょう。それが正しい判断であることもありますが、そうでないことも、あるいは「まだその時ではない」ことも多いのです。
私が答えようとしているのは「そのシステムは古いか？」ではなく、「そのシステムは、許容できるコストで今も役割を果たしているか？」という問いです。
実際に起きている問題から着手する
まずは、現場の言葉で語られる問題から始めます。「単純な変更に数週間かかる」「レポートが在庫と一致しない」「特定の担当者が休暇に入ると月末処理が止まる」「前期にシステムが2回ダウンし、注文が溜まった」といったことです。
これらは、ソフトウェアを実際の時間やコストに結びつけて考えるのに役立ちます。「古い」という言葉はここには含まれません。10年前のシステムでも、変更がほとんど必要なければ、刷新するより維持する方が安く済む場合があります。逆に、2年前に構築されたシステムでも、ビジネスの変化に対応できなければ、すでに問題と言えます。
真の維持コストを算出する
古いシステムのコストは、サーバー代だけではありません。以下のようなものが含まれます。
- 回避策や二重入力に費やされる時間
- システムの変更が困難なために遅延するプロジェクト
- システム停止と、それに伴う混乱への対応
- アップデート不可によるセキュリティリスク
- メンテナンスできる人材の確保の難しさ
これらのコストは複数の部署に分散しているため、全体像が見えにくいのが一般的です。短期間のレビューでこれを明確にします。システムが担う重要な役割、依存している人、頻繁に壊れる箇所、今後2〜3年で予想されるニーズをリストアップします。概算で構いません。推測である部分は正直に認め、現状を把握することが大切です。
選択肢は2つだけではありません
「何もしない」か「すべて作り直す」かの二択であることは稀です。その中間には、次のような選択肢があります。
- 最も問題を引き起こしている箇所だけを修正する
- レポート機能や会計ソフトとの連携など、一部の機能だけを置き換える
- 変更が難しい部分の周囲にモダンな層を構築し、新しいツールと連携できるようにする
ただし、常にスモールステップが正解とは限りません。システム内のデータが信頼できない場合や、今後のビジネスニーズに根本的に対応できない場合は、パッチを当て続けることが問題を長引かせるだけになることもあります。大切なのは、慣習ではなく、意図的に選択することです。
「明文化されていないルール」が難所
システムを刷新する際、画面を作り直すのは簡単な部類に入ります。難しいのは、誰も書き留めていない細かなルールです。特定の顧客への特別価格、特定のステップをスキップできる注文、会計担当者が毎週金曜日に頼りにしているデータ出力など。こうした細部こそが、システムの真の核心であることが多いのです。
新しいシステムへ移行する前に、信頼できるデータがどこにあるのか、重複や古い記録をどう扱うのか、そして新システムが旧システムと同じ正しい答えを出していることをどう証明するのかを確認します。また、問題が発生した際の切り戻しプランや、新旧システムを並行稼働させるかどうかも検討します。優れた計画とは、単にデータをコピーする方法ではなく、データが正しいことをどう確認するかを説明するものです。
決定を下す前の5つの質問
何かを提案する前に、私は次の5つの質問への答えを求めます。
- 具体的にどの問題を解決しようとしているのか？
- 現状維持を選択した場合のコストとリスクは何か？
- 予算、納期、規制など、本当に動かせない制約は何か？
- 新しいアプローチが正しく機能することをどう確認するか？
- 将来の選択肢を狭めることなく、リスクを軽減できる最小の有効なステップは何か？
もしこれらの答えが曖昧なら、大規模なプロジェクトを始める前に、期限を決めた短期的な調査を行うのが適切です。その結果として、システムの全体像、優先順位をつけた主要なリスク、現実的な選択肢、そして取り組むべき合理的な順序が明確になるはずです。
結論
古いソフトウェアの更新は、新しい技術を追いかけることではありません。システムがビジネスを支え続けられるようにすることです。それは作り直しを意味することもあれば、ピンポイントの修正、可視性の向上、そしてより安全な前進を意味することもあります。