仕様書がないシステムの刷新方法｜現行調査から見積・計画まで | 株式会社ソフトウエア・サイエンス

こんにちは。ソフトウエア・サイエンスビジネスソリューション事業部の本田です。入社以来20年にわたり様々なプロジェクトに関わっており、現在は仕様書が十分に残っていない業務システムの刷新プロジェクトでPMを担当しています。

はじめに：仕様書がなくても、システム刷新は進められる

システム刷新の相談を受けていると、「仕様書が残っていない」、「資料はあるが、今のシステムと合っているのか分からない」、「昔の担当者が退職していて、なぜこの仕様になっているのか誰も説明できない」といったケースがあります。

しかし実際には、「仕様書がない」といっても状態はさまざまです。本当に何の資料も残っていないケースもあれば、古い仕様書や一部の設計書は残っているものの、現在の実装や業務との整合性が分からないケースもあります。

このような状況でも、現行システムや業務を調査し、必要な情報を整理することで刷新を進めることは可能です。ただし、重要なのは**現行システムをすべて完全に解明することではありません。**何のために刷新するのかを明確にし、その判断に必要な範囲で現状（As-Is）を整理し、将来像（To-Be）につなげていくことが重要なのです。

この記事では、仕様書が十分に残っていないシステムを刷新する際に、何を確認し、どこまで現状を把握し、どのように刷新計画へつなげていくのかを整理します。

この記事でわかること

「仕様書がない」とは、具体的にどのような状態なのか
仕様書がないと、なぜ見積やスケジュールが難しくなるのか
現行システムをどこから調査すればよいのか
現状をどこまで把握すれば、将来像の検討へ進めるのか
現行調査の結果を、刷新範囲や見積へどうつなげるのか

この記事はこんな方におすすめです

基幹システムや業務システムの刷新を検討している方
最新の仕様書や設計書が残っていない方
現行システムの担当者が退職し、仕様が分からなくなっている方
ブラックボックス化したシステムの刷新方法に悩んでいる方
システム刷新の見積や対象範囲を決められず困っている方

ソフトウエア・サイエンス（SSI）では、独自の「業務フロー中心設計技法」を活用し、仕様書や設計書、マニュアルが十分に存在しないケースも想定しながら、業務フローとプログラム分析の両面からAs-IsとTo-Beを可視化しています。

このシリーズについて

「仕様書がないシステムの刷新」を、3つの視点から解説しています。

この記事：刷新全体編
現行調査から刷新範囲・見積を決めるまでの全体像を解説します。
技術調査編
データ、DB、外部インターフェース、ソースコードから現行システムをどう読み解くのかを解説します。
「仕様書がないシステムの技術的な読み解き方」
業務理解編
業務フローや現場ヒアリングから、仕様書に書かれていない業務ルールをどう把握するかを解説します。
「仕様書だけでは分からない「本当の仕様」」

「仕様書がない」は、一つの状態ではない

仕様書がないシステムと聞くと、「資料が一つも存在しない状態」を想像するかもしれません。しかし、実際には完全に資料がないケースよりも、次のような問題が複数重なっていることが多くあります。

仕様書はあるが、現在の実装と一致しているか分からない
一部の仕様書や設計書しか残っていない
長年の改修内容がドキュメントに反映されていない
担当者しか実際の使い方を知らない
以前の担当者が退職し、仕様の背景を説明できる人がいない
システムは動いているものの、本来どうあるべきか分からない

私自身が現在携わっている刷新案件でも、まさに仕様書が十分に残っていない状態から現行調査を始めています。こうした案件で特に難しいのは、単に資料がないことよりも、現行業務を理解している人がいない状態です。仕様書がなくても、業務を理解している担当者がいれば、「現在はこう動いていますが、この認識で合っていますか？」と確認できます。

一方、その業務がなぜ存在するのか、どうあるべきなのかを説明できる人がいなければ、確認する相手そのものがいません。

仕様書がないと、なぜシステム刷新が難しくなるのか

仕様書がないことで最も大きな問題になるのは、要件定義そのものができないことではありません。顧客側には、「新しいシステムではこうしたい」という将来像が存在する場合があります。

問題は、その将来像に対して、現在地がどこにあるのか分からないことです。例えば、目的地まで20mだと思って計画を立てたものの、実際には100m離れていたとしたら、必要な時間もコストも大きく変わります。システム刷新でも同じです。現行システムの構造や業務が把握できていないと、

どこまで変更する必要があるのか
どのシステムに影響するのか
どれくらいの開発量になるのか
どのくらいの期間が必要なのか

を判断するための前提が不足します。その状態で見積やスケジュールを作ると、開発を始めてから、「想定より対象範囲が広かった」、「このシステムにも影響があった」ということが分かる可能性があります。

特に外部システムとの連携がある場合は注意が必要です。連携先の仕様が明確でないと、「連携データは変更しない」という前提で計画を進めても、実際に連携すると変更が必要になることがあります。また、変更したことで思わぬ影響が生じる場合もあります。

仕様書がない案件では、要件定義の前に「現行調査」が必要になる

仕様書や現状情報が十分にない場合は、要件定義へ入る前段階として現行調査が必要になります。例えば、

どのようなシステムが存在するのか
どのようなデータを扱っているのか
データはどこで発生し、どこへ流れているのか
他システムとどのようにつながっているのか
実際の業務ではシステムをどう使っているのか

などを整理します。現行調査は、新しい機能を作る工程ではありません。そのため、「現在のシステムを調べるために、なぜ時間や費用が必要なのか」と疑問を持たれることもあります。

しかし、現状が見えないまま刷新へ進むと、後から対象範囲が広がったり、必要な機能が抜けたりする可能性があります。SSIでも、レガシーシステムの刷新や属人化したシステムに対し、業務フローからAs-Isを可視化し、プログラム分析と組み合わせながらTo-Beの検討につなげるアプローチを取っています。

現行システムは、データと業務の両面から把握する

現行システムを把握するときには、プログラムだけを見るのではなく、データや業務も含めて整理します。例えばECサイトであれば、

顧客情報
商品情報
注文情報
配送情報

など、複数の情報が存在します。これらについて、「どこで発生し、どのシステムへ入り、どのように加工され、どこへ出ていくのか」を整理します。

同時に、「どの業務の中で、そのデータが発生しているのか」も確認します。つまり、データフローと業務フローを重ねて理解することが重要です。

技術的な調査方法については、別記事で詳しく解説しています。

[ここに「仕様書がないシステムの技術的な読み解き方」への内部リンクを追加→CPS対応]

As-Isを整理したうえで、顧客と認識を合わせる

現行システムを把握した後は、その内容を顧客と確認します。ここで重要なのは、「現在のプログラムはこう動いている」という事実だけを確認することではありません。

例えば、「現在はこのような処理になっていますが、本来やりたい業務もこれで合っていますか？」と確認します。すると、「システム上はそうなっているけれど、本当はこうしたい」、「技術的な制約があったので、仕方なくこの運用にしている」といった話が出てくることがあります。

現在動いているシステムは、過去の予算、納期、当時の技術や業務上の制約を積み重ねた結果かもしれません。そのため、現在動いているプログラム＝正しい仕様とは限りません。

As-Isは、すべてを100％明らかにする必要はない

仕様書がないと、「まず現行システムを全部明らかにしなければならない」と考えがちです。しかし、大規模な業務システムでは、すべての仕様を完全に把握しようとすると、時間と費用が増え続けます。

重要なのは、刷新の判断に必要な範囲を明らかにすることです。例えば、

今回全面刷新する領域
一部だけ変更する領域
今回は触らない領域
外部システムのため調査範囲外となる領域

では、必要な調査の深さが異なります。実務では、すべてが分かっていること以上に、「どこが分かっていて、どこが分かっていないのか」が分かっていることが重要です。

例えば、外部システムとの連携部分について詳細が分からなかったとしても、「この連携部分の、この情報が未確認」という状態まで整理できていれば、その前提を共有したうえで計画を作ることができます。

不明点が残っていても進められる条件

不明な範囲が明確になっている
その不明点を顧客と共有している
今回の刷新対象への影響を判断できる
必要になった段階で追加調査できる

現行調査では、何を成果物として残すのか

現行調査の結果は、口頭だけで共有するのではなく、見える形に整理します。例えば、

業務フロー図
データフロー図
システム構成図
システム鳥瞰図

などです。これらを関係者と確認し、「現在のシステムと業務は、この状態である」というスタートラインを合わせます。

重要なのは、仕様書を完全に作り直すことではありません。刷新の対象範囲やTo-Beを判断できる状態を作ることが目的です。それぞれの成果物は、次のような判断に活用します。

業務フロー図・データフロー図：現状（As-Is）と将来像（To-Be）の違いを整理し、目指す業務の実現可能性や生産性への影響を検討する。
システム構成図：現状の技術要素を把握し、刷新に必要な技術やスキルを判断する。
システム鳥瞰図：関連システムとの関係を俯瞰し、刷新の対象範囲や他システムへの影響範囲を判断する。

現状整理から、将来のシステム像へどうつなげるか

現状が整理できたら、次に、「今後どうしたいのか」を検討します。顧客側から出てくるのは、「この業務を効率化したい」、「この手作業をなくしたい」といった、業務レベルの要求であることが多くあります。

SIerは、その要求をシステムの変更対象へ変換していきます。具体的には、顧客が実現したい将来像を確認して現状との差を整理し、どのシステムを変更するかを判断します。そのうえで、変更する部分と残す部分を明確にし、見積とスケジュールを作成します。

将来像についても、すべての要望をそのまま実現することが最適とは限りません。コスト、納期、保守性などを踏まえ、「この方法なら主要な目的をより現実的に実現できる」といった代替案を検討することも重要です。

この検討は、次章で紹介する7ステップのうち、主にステップ5「将来像の整理」からステップ7「見積・計画」に当たります。

仕様書がないシステム刷新の進め方

仕様書が十分に残っていないシステムの刷新では、目的の整理から現行調査、関係者との認識合わせを経て、刷新範囲と計画を具体化していきます。全体の流れは、「刷新目的の明確化と現状把握」「将来像と刷新範囲の検討」「計画の具体化」の3段階に整理できます。

具体的な作業内容は、次の7ステップです。

刷新目的の整理：何のために刷新するのかを確認
現行調査：業務・データ・システム構成を確認
現状の可視化：業務フロー、データフローなどで整理
認識合わせ：顧客と現在地を共有
将来像の整理：今後の業務・システム像を検討
対象範囲の決定：変更する部分・残す部分を決定
見積・計画：工数、費用、スケジュールを整理

SSIはITコンサルティングを入口として、業務フローの可視化・改善からシステム開発、導入、運用・保守までを提供しています。

現行調査を技術面・業務面からさらに詳しく知りたい方へ

現行調査には、大きく分けて、「システムを技術的に読み解く」視点と、「実際の業務から仕様を読み解く」視点があります。

「仕様書がないシステムの技術的な読み解き方」→CPS対応
データ・DB・IF・ソースコードをどのように調査するのかを解説しています。

「仕様書だけでは分からない「本当の仕様」」→CPS対応
業務フロー、アクター、現場ヒアリングから仕様書にない業務ルールをどう把握するのかを解説しています。

仕様書がないシステムの刷新前チェックリスト

確認項目	確認したいこと
既存資料	古いものも含め、どの資料が残っているか
担当者	業務やシステムを説明できる人がいるか
業務フロー	現在の業務が整理されているか
データフロー	データの発生・加工・出力が把握できているか
システム構成	他システムとのつながりが分かっているか
不明点	分からない部分が明確になっているか
将来像	今後実現したい業務が整理されているか
対象範囲	今回どこまで刷新するか決まっているか