こんにちは。ソフトウエア・サイエンス ビジネスイノベーション事業部の平田です。現在、長年利用されてきた基幹システムをERPへ置き換えるプロジェクトに携わっています。
はじめに：仕様書がなくても、システムを読み解く手掛かりは残っている
システム刷新の現場では、「仕様書が存在しない」、「設計書が古く、現在の実装と合っているか分からない」、「開発担当者がすでに退職している」といった状況に遭遇することがあります。
こうした状況をお話しすると、「その場合はソースコードを解析するのでしょうか」と聞かれることがあります。もちろん、ソースコードは重要な情報源です。私自身も若い頃は、ソースコードを読みながら現行調査を進めることが多くありました。当時は、それが最も確実な方法だったと思います。
一方で、多くの刷新案件に携わる中で、少しずつ考え方が変わってきました。現在では、最初からソースコードへ飛び込むことはあまりありません。まず確認するのは、**「このシステムは何を扱っているのか」**です。そして、調査で得た情報を、刷新に向けた判断へどうつなげるかを重視しています。
今回は、私が仕様書のないシステムをどのように技術的に読み解いているのか、実際の経験を交えながらご紹介します。
この記事でわかること
- 現行調査の目的と、調べる範囲の考え方
- データや入出力からシステムの役割を把握する方法
- ソースコードやデータから分かることと、業務部門への確認が必要なこと
- 調査結果を、残す・変える・なくすという判断につなげる視点
この記事はこんな方におすすめです
- 仕様書や設計書が十分に残っていないシステムの刷新を検討している方
- 古いシステムがブラックボックス化し、どこから調査すべきか悩んでいる方
- ソースコード解析だけで現行システムを把握できるのか疑問を持っている方
- ERP移行やシステム刷新に向けて、現行調査の範囲を決めたい方
- システム変更による影響範囲をどのように把握するか検討している方
このシリーズについて
「仕様書がないシステムの刷新」を、3つの視点から解説しています。
- 刷新全体編
現行調査から刷新範囲・見積を決めるまでの全体像を解説します。
「仕様書がないシステムはどう刷新する？現状調査から刷新計画までの進め方」 - この記事：技術調査編
データ、DB、入出力、外部インターフェース、ソースコードなどから、現行システムをどのように読み解くのかを解説します。 - 業務理解編
業務フローや現場ヒアリングから、仕様書だけでは分からない業務上の背景やルールをどう把握するかを解説します。
「仕様書だけでは分からない『本当の仕様』」
まず考えるのは「何を調べたいのか」
仕様書がないと聞くと、システム全体を解明しなければならないように感じるかもしれません。しかし、実際の現場では調査には目的があります。例えば、ERPへの移行に向けた現行調査と、特定機能の改修に向けた影響調査では、見るべきポイントが異なります。
システム間のインターフェース（IF：データをやり取りする接続部分）を変更するのであれば、入出力や関連処理を重点的に確認する必要があります。私は現行調査を始める際に、**「何を判断するために、どこまで理解すべきか」**を意識しています。調査対象を広げようと思えば、いくらでも広げることができます。
大規模な基幹システムで一つひとつの処理を追い続ければ、時間も費用もかかります。だからこそ、最初に調査の目的を明確にすることが重要です。
私が最初に見るのは、システムが扱うデータ
ソースコードを読めば、どの条件で処理が分岐するのか、どのテーブルを更新しているのか、どのシステムへ連携しているのかといった情報を確認できます。ただ、大規模な基幹システムでは、個々の処理を追うだけで全体像を理解するのは簡単ではありません。そこで私が最初に確認するのが、システムが扱っているデータです。
- どのようなテーブルが存在するのか
- どのような属性を持っているのか
- 実際にどのようなデータが格納されているのか
例えば、受注データ、出荷データ、請求データがあるとします。それぞれの内容や関連を見ていくと、「このシステムは販売管理のどの部分を担っているのか」、「どの業務を支えているのか」が少しずつ見えてきます。
私の経験では、「どんなプログラムがあるか」よりも、「どんな情報を扱っているか」の方が、システムの役割を早く理解できることが多いと感じています。ただし、必ずデータベースから調べるわけではありません。画面を中心に利用するシステムであれば、実際の画面や帳票を確認した方が、入出力を把握しやすい場合があります。
私が現在担当しているようなバッチ処理やシステム間連携が中心のシステムでは、データベースや実データ、IFが重要な入口になります。古い仕様書や設計書も、当時のシステムの目的や構成を知る手掛かりになります。現在の実装と一致しているかを確認しながら、利用できる情報を組み合わせて全体像を捉えていきます。
データの流れと業務のつながりを整理する
システムが扱うデータの全体像が見えてきたら、次はその流れを確認します。
- データはどこから来るのか
- どこで加工されるのか
- どこへ渡されるのか
- どのタイミングで連携しているのか
SSIでは、上流工程において「業務フロー中心設計」という考え方を大切にしています。システムを個々の機能や画面の集合として見るのではなく、業務全体の流れの中で理解するアプローチです。
そのため、データの流れを調べる際も、「どのシステムがデータを作成しているのか」、「どのシステムが利用しているのか」を、業務とのつながりを含めて整理していきます。
現在担当しているERP刷新案件でも、周辺システムとのIFは100本以上存在しています。こうした環境では、個々のプログラムの処理だけでなく、システムをまたいでデータがどのように流れているかを理解することが重要です。業務フローとデータフローを整理することで、
- どのシステムが中核なのか
- どこに改修影響が及ぶのか
- 何を重点的に調査すべきか
が見えてきます。また、既存のIFをそのまますべて新しいERPへつなぎ替えるとは限りません。そのまま残すもの、データ形式を変更するもの、複数の連携をまとめるもの、ERP側の機能で代替するもの、利用されていないため廃止を検討するものがあります。
こうした判断をするためにも、現在の接続方法だけでなく、その連携が業務の中で果たしている役割を把握する必要があります。
ソースコードやデータから、判断すべき論点を見つける
全体像と調査対象が見えてきたら、必要な箇所のソースコードを確認します。データがどの条件で加工され、どこへ渡されるのかを詳しく調べることで、現在の処理を具体的に把握できます。
一方で、調査を進めるほど、「なぜ、この条件が必要なのか」「なぜ、このデータ構造になっているのか」「なぜ、この帳票を出力しているのか」といった疑問が出てきます。
ソースコードは処理の仕組みを、データは格納されている状態を教えてくれます。
しかし、その仕様が生まれた背景や業務上の理由までは、分からないことがあります。私たちは、現行調査では事実を集めることに加えて、そこから判断すべき論点を見つけることが重要だと考えています。例えば、帳票を出力していることが分かれば、「誰が、何のために使っているのか」、「刷新後も同じ形で必要なのか」という確認につながります。
その論点をもとに業務部門へのヒアリングや業務分析を進めることで、本当に理解すべき内容に近づいていきます。開発当時の担当者がおらず、背景をすぐに確認できないこともあります。その場合は、データの流れや利用状況から仮説を立て、関係者に確認します。
確認できた事実と、仮説や未確認事項を分けて扱うことも大切です。
100を超える帳票調査で学んだこと
以前、100を超える帳票を対象に現行調査を行ったことがあります。帳票ごとに、
- 出力条件
- 参照テーブル
- 編集ロジック
- 出力内容
を整理し、かなりの時間をかけて分析しました。技術的な内容は十分把握できたと思います。しかし、その後、刷新後の業務・システム像であるTo-Beの検討が進むにつれて、状況が変わりました。調べてみると、次のような帳票が数多く存在していたのです。
- 実際には利用されていない帳票
- ERPの標準機能で代替できる帳票
- BI（データの集計・分析・可視化を行うツール）で実現した方が適している帳票
もちろん、調査自体が無駄だったわけではありません。ただ、この経験から私は、「詳細を把握すること」と「判断に必要な情報を整理すること」は別であると学びました。現在の帳票がどのように作られているかを詳しく把握しても、それだけでは刷新後に同じ帳票を残すべきかは決まりません。
利用実態や、ERPなどで代替できる可能性を含めて考える必要があります。現行調査では深掘りも大切です。しかし同時に、「何を判断するための調査なのか」を常に意識する必要があると感じています。
私たちが実践している現行調査の進め方
案件によって順番は変わりますが、私たちは調査の目的を確認したうえで、大きく次の流れで現行調査を進めることが多くあります。
- システムの役割を把握する
何のために使われ、どの業務を支えているのかを確認します。 - データの種類や構造を確認する
テーブルや属性、実データから、扱っている情報を整理します。 - 帳票や入出力を確認する
何を受け取り、どのような情報を出しているのかを把握します。 - インターフェースを整理する
連携先や受け渡すデータ、連携のタイミングを確認します。 - データフローを可視化する
データの発生・加工・受け渡しを、業務とのつながりを含めて整理します。 - 必要な箇所のソースコードを確認する
判断に必要な処理や条件を詳しく調べ、変更する場合の影響先も確認します。 - 論点を整理して業務部門と確認する
仕様の背景や利用実態を確認し、残す・変える・なくすという判断につなげます。
重要なのは、この順番を固定的に守ることではありません。途中で業務部門に確認し、その回答を受けて調査対象を見直すこともあります。システムの特性やプロジェクトの目的に応じて、全体像を把握しやすい入口を選び、必要な部分を掘り下げていきます。
また、調査範囲を絞る場合も、変更箇所だけを見ればよいわけではありません。例えば、コード値を一つ追加する変更でも、その値を使う別の処理や外部システムへ影響することがあります。対象とする処理と、その影響先を合わせて確認することが大切です。
まとめ
仕様書がないシステムでも、データベース、実データ、帳票、IF、ソースコード、古い資料などが、現状を読み解く手掛かりになります。私自身は、まずシステムが扱う情報とデータの流れを把握し、判断に必要な箇所のソースコードを確認することを意識しています。
また、SSIでは技術調査を、業務フローやシステム間連携を含めて全体像を理解する活動として位置付けています。調査で得た事実から「なぜこの仕様が存在するのか」という論点を見つけ、業務部門と確認することが、刷新後の姿を考えるうえで重要だからです。
システム刷新では、現行の処理を詳しく理解することと、将来に向けて適切な判断ができることの両方が求められます。何のために調べるのかを見失わず、業務の流れ、データの流れ、システムの役割を整理する。それが、私たちの現行調査で大切にしていることです。
仕様書が揃っていない段階から、現行調査についてご相談いただけます
「DBやソースコードはあるが、全体構造が分からない」、「システム間連携が複雑で、刷新時の影響範囲を判断できない」、「どこまで調べればよいか分からない」といったお悩みはありませんか。
SSIでは、業務フローと技術調査の両面から既存システムを可視化し、刷新に向けた検討を支援しています。現在残っている資料や、刷新にあたって困っていることから、お気軽にご相談ください。