ROI事件ファイル No.459『新しいシステムの古い設計』
新しいシステムの古い設計
第一章：新品の使えないシステム
「新しいシステムに変えたのに、誰も使いたがらない」
Globex Corporation社のIT部門長、松田浩二氏は、そう言いながら苦い顔をした。手元には、三月に完了したばかりの基幹システムリプレイスの報告書がある。予算通り、スケジュール通りに完了した——はずだった。
「二十年前の基幹システムをZohoベースの新システムに移行しました。プロジェクト期間は十四ヶ月。ベンダーへの発注金額は想定内でした。しかし、稼働開始から二週間で、現場から不満の声が上がり始めました」
「どんな不満ですか」と私は尋ねた。
「受注から進捗確認までの画面遷移が複雑すぎる、と。旧システムでは三クリックでできていた作業が、新システムでは七クリック必要になった。社員情報と案件情報が別々のモジュールにあり、一つの案件の状況を確認するために二つの画面を行き来しなければならない。旧システムの設計思想をそのままZohoに移植したため、Zohoの機能を活かせていないと、ベンダーにも言われました」
「なぜ旧システムの設計を踏襲したのですか」とClaudeが問いかけた。
松田氏が黙った。「移行コストと、現場の反発を最小化したかったからです。慣れた操作フローを変えないことが、円滑な移行につながると判断しました。しかし、結果的に古い非効率をそのまま新しいシステムに転写してしまった」
「慣れさせることと、使いやすくすることを混同した」とGeminiが静かに言った。
松田氏が頷いた。「その通りです。今から改善できることを教えてほしい」
第二章：RICEが優先順位を照らす
「この案件には、RICEが必要です」
Claudeがホワイトボードに四つの文字を書いた。R・I・C・E。
「RICEとは、Reach（影響範囲）、Impact（改善効果）、Confidence（成功確率）、Effort（必要工数）の四軸で、改善施策を評価するフレームワークです」と私が説明した。「稼働直後のシステムに対して改善を行う際、『全部直す』は予算と時間の観点から現実的ではありません。何を先に直すかを決めるために、RICEは問いを絞ります」
「現場から上がっている不満を、まずリストアップしてください」と私が松田氏に依頼した。
松田氏が一週間後に持ってきたリストには、二十七件の改善要望が並んでいた。
「Strategic ROI Intelligenceでこのリストを分析します」とGeminiが提案した。「同規模のZoho導入企業の改善事例と比較し、対応優先度の参考指標を出しましょう」
ツールが分析結果を返した。二十七件のうち、他社でも高頻度で報告されている課題が九件。その九件に絞り、RICEスコアを計算することにした。
[RICEスコアの計算]
「最もスコアが高かったのは」とGeminiが読み上げた。「受注案件の進捗ダッシュボードの統合です。R（全社員）× I（大）× C（0.8）÷ E（中）——スコアトップです」
「現在、受注情報は営業モジュール、進捗情報はプロジェクト管理モジュール、請求情報は経理モジュールに分かれています」とClaudeが説明した。「これを一画面で確認できるダッシュボードを作るだけで、一案件の状況確認にかかる時間が大幅に短縮されます。Zohoには、複数モジュールのデータを統合するダッシュボード機能が標準装備されています。旧システムにはなかった機能です——使われていなかっただけで」
「つまり」と松田氏が気づいた。「旧システムを踏襲したことで、Zohoの機能が使われていなかった。改善は、機能を追加するのではなく、すでにある機能を使い始めることから始まる」
「RICEのスコア二位は」とGeminiが続けた。「社員情報と案件情報の紐付けの改善です。現在は手動でIDを入力して紐付けているが、Zohoの標準機能で自動紐付けができます。設定変更のみで対応可能なため、Effort（工数）が最も小さく、Confidence（成功確率）が最も高い」
「三位は」とClaudeが言った。「画面遷移の簡素化です。三クリックで済むワークフローの設計は、Zohoのカスタムビュー機能で対応できますが、現場ヒアリングが必要なため、Effortは上位二つより大きい」
[三段階の改善計画]
「RICEスコアの順序で改善を進めましょう」と私が提案した。
「第一週——ダッシュボードの統合。設定作業のみで完了。現場への影響範囲が最大で、即効性があります。まずこれを見せることで、改善への信頼が生まれます」
「第二週——社員情報と案件の自動紐付け。設定変更のみ。現場からの不満件数で二位に相当します」
「第三週以降——現場ヒアリングをもとにした画面遷移の改善。一部のカスタマイズが必要になるため、ベンダーと協議しながら進めます」
松田氏が腕を組んだ。「RICEスコアが高い上位二件は、設定変更だけで対応できる。追加費用がほぼかからない」
「それが、RICEの力です」と私が応じた。「改善施策を四軸で評価すると、コストがかからずに効果が高いものが浮かびます。リプレイスに多大な費用をかけた直後に、また大きな改修費用を使う必要はない。すでにある機能を使いこなすことが、最初の一手です」
第三章：古い地図と新しい地形
松田氏がホワイトボードのRICEスコアの表を写真に収めながら言った。
「リプレイスの設計段階で、このフレームワークを使っていれば、と思います」
「次のリプレイスの時のために」とClaudeが言った。「覚えておいてほしいことがあります。システムの移行は、旧システムの機能を新システムに写す作業ではありません。旧システムの目的を新システムで達成する方法を設計する作業です。旧システムでの三クリックが最適解だったのは、旧システムの制約の中での話です。新システムには新しい制約と新しい可能性がある。旧システムの地図を持って新しい地形を歩くと、迷います」
「今回の失敗の教訓として」と私が付け加えた。「次のリプレイスでは、移行前にRICEで『新システムで実現したいこと』を優先順位づけしてください。現場の『慣れ』と、組織の『改善』は別の問いです。両方を同時に満たすことはできない。どちらを優先するかを、最初に決めておくことが重要です」
三ヶ月後、松田氏から報告が届いた。
第一週のダッシュボード統合後、現場からの不満の声が急減した。「一画面で全部見える」という声が複数の部署から上がった。第二週の自動紐付け設定後、入力ミスによる問い合わせが週平均で四件から一件以下に減少。
二十七件あった改善要望は、RICEで優先順位をつけて対応した結果、三ヶ月で十九件が解消された。残り八件は、第二フェーズの計画に組み込んだ。
松田氏は報告書にこう記していた。「旧システムを踏襲したことの失敗は、設計の問題でした。しかし、その失敗が、Zohoの機能を本来の使い方で使い始めるきっかけになりました。リプレイスの本当の成果は、稼働開始日ではなく、三ヶ月後に出始めるものだと気づきました」
新しいシステムが、新しい設計を持ち始めた日だった。
「システムのリプレイスは、古い問題を新しい容器に移す作業ではない。新しい容器が持つ可能性を使いこなす設計をする作業だ。RICEが問うのは、何を先に改善するかではなく、何が最も大きな価値を最も少ない労力で生むか、だ。稼働直後の混乱の中で、この問いを立てることができれば、新しいシステムは設計し直されず、使いこなされていく。旧システムの地図は、新しい地形では使えない」
関連ファイル
使用ツール
- Strategic ROI Intelligence — 同業他社の改善事例との比較分析と優先度参考指標の算出
