「画面は完成したのに、業務で使えない」——システムの入れ替えプロジェクトで、こんな事態に陥ったことはありませんか？
今回は、あるシステム移行プロジェクトで実際に起きた問題から、本来あるべき進め方を考えてみます。
何が起きたのか
そのプロジェクトでは、長年使ってきた基幹システムを新しい技術で作り直すことになりました。
担当者は現行システムの画面を見ながら、「この画面と同じものを作れば大丈夫」と考えました。画面のレイアウト、ボタンの配置、入力項目——すべてを忠実に再現しました。
数ヶ月後、見た目は完璧に仕上がりました。
ところが、いざ業務で使おうとすると、まったく動かないのです。
「この計算結果がおかしい」「このデータが反映されていない」「月末の処理ができない」——次々と問題が発覚しました。
なぜこうなったのか
原因はシンプルでした。
画面の裏側にある「業務ルール」が、まったく引き継がれていなかったのです。
古いシステムには、長年の運用の中で積み重ねられた業務ルールが大量に埋め込まれていました。
- 特定の条件で自動計算される金額
- 月末に一括で処理される締め処理
- 例外的なケースへの対応ロジック
これらは画面には見えません。システムの裏側で静かに動いていた「業務の知恵」です。
画面だけを見て設計した結果、この「見えない資産」がすべて抜け落ちてしまったのです。
「現行システム＝要件書」という誤解
ここで重要な気づきがあります。
現行システムは「業務仕様書」ではない
長年使われてきたシステムには、確かに業務が詰まっています。しかし、それは「なぜそうなっているか」を説明してくれません。
画面を見れば「何が表示されるか」はわかります。でも、「なぜその数字になるのか」「どんな条件で変わるのか」は、画面だけでは読み取れません。
特に、夜間や月末に自動で動く処理には、業務上の重要なルールが凝縮されています。これを無視してしまうと、「動くけど使えない」システムが完成します。
本来あるべき進め方
では、どうすればよかったのでしょうか。
システム移行プロジェクトでは、6つのステップを順番に進める必要があります。
- 業務を理解する
- 要求を定義する
- 新しい業務の姿を設計する
- システムの構造を設計する
- 機能を設計する
- 画面を設計する
ポイントは、画面の設計は最後の工程だということです。
今回の問題は、①〜④をスキップして、いきなり⑥から始めてしまったことにあります。
業務理解が最重要
中でも最初の「業務理解」は、時間がかかっても絶対に省略できない工程です。
やるべきこと
- 現場の担当者に「なぜこの処理があるのか」を聞く
- 日次・週次・月次でどんな作業をしているか洗い出す
- 「普段は起きないけど、たまにある例外」を把握する
- 「昔こういうことがあったから、こうなった」という経緯を知る
これらは、システムの画面を見ても絶対にわかりません。人の頭の中にある知識です。
【分析フレームワーク1】As-Is / To-Be分析
業務理解で最も基本となるフレームワークが「As-Is / To-Be分析」です。
| 用語 | 意味 | 分析の目的 |
|---|---|---|
| As-Is（アズイズ） | 現状の姿 | 今どうなっているかを正確に把握する |
| To-Be（トゥービー） | あるべき姿 | 新システムでどうなりたいかを描く |
| Gap（ギャップ） | 差分 | As-IsとTo-Beの違いを明確にする |
使い方
- まずAs-Isを徹底的に洗い出す（業務フロー、ルール、例外処理）
- 次にTo-Beを描く（理想ではなく「実現可能な改善形」）
- 両者のGapを特定し、「何を変えるか」を明確にする
【よくある失敗】As-Isを省略してTo-Beから始めると、現実離れした設計になります。
【分析フレームワーク2】Fit & Gap分析
パッケージソフトやクラウドサービスを導入する際に使われるのが「Fit & Gap分析」です。
| 用語 | 意味 | 対応方針 |
|---|---|---|
| Fit（フィット） | 標準機能で対応できる | そのまま使う |
| Gap（ギャップ） | 標準機能では対応できない | カスタマイズ or 業務を変える |
Gapへの対応方針
| 方針 | 説明 | メリット・デメリット |
|---|---|---|
| カスタマイズ | システムを改修して対応 | 業務は変えなくて済むが、コスト増・保守が複雑に |
| 業務変更 | 業務をシステムに合わせる | コスト抑制できるが、現場の抵抗がある場合も |
| 運用回避 | システム外で手作業対応 | 一時的には楽だが、長期的には負担増 |
【ポイント】「Gapをゼロにする」のではなく、「どのGapを許容するか」を経営判断として決めることが重要です。
作るべき資料
業務理解ができたら、以下の資料を作ることをお勧めします。
| 資料名 | 内容 | 重要度 |
|---|---|---|
| 業務フロー図（As-Is） | 今の業務の流れを図にしたもの | 高 |
| 業務フロー図（To-Be） | 新システムでの業務の姿 | 高 |
| 業務ルール一覧 | 判断条件、計算式、例外処理のリスト | 高 |
| Fit & Gap一覧 | 要件とシステム機能の対応表 | 高 |
| 用語定義集 | 社内で使われている言葉の意味を統一 | 中 |
これらがあって初めて、「何を作るべきか」が見えてきます。
途中で気づいたらどうするか
もし今まさに「画面は作ったけど業務が回らない」という状況にいるなら、以下のステップをお勧めします。
- 一度立ち止まる（実装を進めない）
- 現場にヒアリングに戻る
- 業務ルールを洗い出す
- 必要な修正を特定する
- 画面の作り直しではなく、業務ロジックの補完に集中する
「もう作っちゃったから」と突き進むと、傷口が広がります。早めに立ち止まる勇気が、最終的にはプロジェクトを救います。
まとめ
システム移行は「再実装」ではなく「再設計」
古いシステムは古い技術で作られています。しかし、その中に埋め込まれた業務ロジックは資産です。
技術を新しくすることだけに目を奪われると、大切な資産を捨ててしまいます。
画面を作る前に、まず「業務を理解する」。当たり前のようで、これが最も見落とされがちなポイントです。