刷新の見積もりを取ろうとして開発会社に相談したら、「まず現行システムの調査からになります」と言われた。設計書は残っておらず、作った当時の担当者もとっくに退職している。よくある場面だと思います。ただ、その調査が何をする作業で、どこまでやれば終わりで、いくらかかるのかは、こちらから聞かないと出てきません。相手は調査そのものを商品として売っているので、範囲は広めに提案されがちです。
レガシーシステムの解析は、設計書が失われたシステムの仕様を、動いている現物から復元する作業です。大事なのは、全部を網羅する必要はないという点です。到達点を「刷新の見積もりが取れる状態」に置けば、調べる範囲はかなり絞れます。この記事では、調査範囲の決め方、調査だけを単独で発注するときの成果物と費用の見方、そして頼まなくてよいケースまでを整理します。刷新そのものの進め方や費用相場は別の記事に譲り、ここでは前工程だけを扱います。
この記事のポイント
- 解析の到達点は網羅ではなく、開発会社が刷新の金額を出せる状態にすること
- 調べる範囲は機能の数ではなく、止まったときに事業が困る業務から決める
- 調査は刷新とセットにせず単独で契約すると、相見積もりの前提が揃う
- 成果物の形式を先に指定しないと、次の見積もりに使えない資料が納品される
目次
レガシーシステムの解析はどこまで必要か
最初に押さえたいのは範囲の考え方です。解析を売っている会社のページを読むと「必要なドキュメントを厳選しましょう」と書かれていますが、その厳選の基準までは書かれていません。発注する側が基準を持っていないと、提案された範囲をそのまま受け入れることになります。ここでは、作業の中身を分解したうえで、どこで線を引けばよいのかを整理します。
解析でやっているのは仕様の復元
レガシーシステムの解析は、大きく3つの層に分かれます。ひとつ目は関係者へのヒアリングで、今その機能を誰がどう使っているかを聞き取ります。ふたつ目は実際にシステムを操作して、画面遷移や入出力を記録する作業です。みっつ目がソースコードを読んで処理の中身を書き起こす作業で、リバースエンジニアリングと呼ばれます。
この3層は、下に行くほど費用も時間もかかります。ヒアリングは数日で終わりますが、ソースコードの読解は行数と言語次第で数週間から数か月に伸びます。にもかかわらず、相談すると最初からソースコード解析込みの提案が出てくることが少なくありません。売り手にとっては当然なのですが、発注する側から見れば、3層すべてが必要な場面はそう多くないんですね。
私が最初に確認するようにしているのは、「その機能について、社内で誰か一人でも説明できる人がいるか」です。説明できる人が残っている機能は、ヒアリングと画面の記録で足ります。誰も説明できず、業務も止められない機能だけが、ソースコードまで踏み込む対象になります。この仕分けをせずに全機能を同じ深さで調べると、費用は簡単に数倍になります。
見積もりが取れる状態を到達点にする
では、どこまで調べれば終わりなのか。私は「開発会社が刷新の金額を出せる状態」を到達点に置くのが実務的だと考えています。完全な設計書を作ることではありません。設計書一式の復元は、刷新後には使わない文書まで作ることになりがちで、費用の割に残らない成果物になります。
金額を出せる状態とは、具体的には次が分かっている状態です。どの業務がいくつの機能で構成されているか、外部とやり取りしているデータ連携が何本あるか、帳票や画面がそれぞれ何種類あるか、そして「現行と同じにする必要がある処理」がどれかです。開発会社はこの4点から工数を積みます。逆に言えば、この4点が埋まらないうちは、いくら細かい仕様書があっても金額は固まりません。
ここを甘く見ると後で効いてきます。IPAが公開しているシステム再構築を成功に導くユーザガイドでも、時間の経過で曖昧になった現行仕様のまま開発に入ることが再構築の失敗要因として整理されています。調査を表面的に終わらせると、後工程で仕様変更が膨らみ、結局は予算を超えることになります。急いで飛ばした調査ほど高くつく、というのが実際のところです。
調べる範囲は業務の重さで決める
範囲を決めるときは、機能の数から入らないほうがうまくいきます。機能一覧を作って「全部で320機能あります」と言われても、どれを深く調べるかの判断はできません。代わりに、止まったときに事業がどれくらい困るかで並べ替えます。
| 業務の重さ | 調べる深さ | 目安の作業 |
|---|---|---|
| 止まると即日で事業が止まる | ソースコードまで読む | 処理ロジックと例外処理を書き起こす |
| 数日は手作業でしのげる | 画面と入出力の記録まで | 画面遷移と帳票の項目を押さえる |
| 使っている人が限られる | ヒアリングのみ | 誰が何のために使うかを確認する |
| 直近1年で誰も使っていない | 調べない | 引き継がない候補として一覧に残す |
いちばん効くのは最下段です。長く動いてきたシステムには、数年間誰も出力していない帳票や、退職者が自分のために作った例外処理が必ず残っています。これを調査対象から外すだけで、範囲は目に見えて縮みます。しかも、使っていない機能を特定できるのは発注する側だけです。開発会社は使われているかどうかを判断できないので、聞かれなければ全部を対象に見積もります。
この仕分けは、部門ごとに「直近1年で使ったか」を確認するだけでできます。半日から1日の作業で、調査費用が数十万円単位で変わることも珍しくありません。調査を頼む前に社内でやっておく価値があります。
解析を頼まなくてよいケース
逆に、解析を発注しなくてよい場面もあります。上位に出てくるサービス紹介のページには書かれていない話なので、ここで触れておきます。
ひとつ目は、業務そのものを作り替えると決めている場合です。現行の処理を引き継がず、パッケージの標準機能に業務を合わせる方針なら、現行仕様を細かく復元する意味は薄くなります。この場合に必要なのは、現行の処理内容ではなく「今どんなデータが入っているか」というデータ側の調査です。移行するデータの量と品質が分かれば足ります。
ふたつ目は、現行を作ったベンダーが今も保守を続けていて、設計書は無くても中身を把握している場合です。この場合は、そのベンダーに現行仕様の説明資料を出してもらうほうが早く安く済みます。保守契約の範囲内で対応してもらえることもあります。ただし、そのベンダーにそのまま刷新も任せる前提になりやすいので、他社にも声をかけるつもりがあるなら、説明資料を自社の資産として受け取れるかを先に確認しておいてください。自社がそもそもレガシーの状態に当たるのかを整理したい場合は、レガシーシステムとは？基幹システムとの違いと見分け方から読むと順序がつながります。
レガシーシステムの解析を単独で発注する
範囲が決まったら、次は頼み方です。ここで多いのが、刷新の提案とセットで調査もお願いしてしまうパターンなのですが、私は調査だけを先に切り出して契約することをおすすめしています。理由と、そのときに決めておくことを順に見ていきます。
調査だけを先に契約する理由
調査を刷新とセットにすると、調査した会社がそのまま刷新も担当する流れになります。それ自体が悪いわけではありませんが、他社と比べる機会を失うことになります。しかも調査結果は調査した会社の中にしか残らないため、他社に声をかけようとしても、また同じ調査からやり直すことになってしまいます。
調査を単独で契約しておくと、この構図が変わります。調査結果が自社の資産として手元に残るので、複数の開発会社に同じ資料を渡して見積もりを依頼できます。前提が揃うので、返ってきた金額を横に並べて比べられるようになります。相見積もりで金額が大きくばらつく原因の多くは、各社が想像した前提が違うことなので、ここが揃うだけで比較の意味が変わります。
契約の形としては、成果物を約束する請負ではなく、作業時間に対して払う準委任になることが多いです。調査は始めてみないと分量が読めない性質があるためです。ただし準委任だからといって期間を無制限にせず、「まず2週間分」のように区切って、そこで出てきた内容を見てから次を判断する形にすると、費用が読めなくなるのを防げます。
受け取る成果物を先に決める
調査で一番もったいないのは、時間とお金をかけたのに、出てきた資料が次の工程で使えないというケースです。これは成果物の形式を先に決めていないときに起こります。
調査を発注する前に決める成果物
- 機能の一覧（業務ごとに分類され、引き継ぐ・引き継がないの欄がある形式）
- 外部システムとのデータ連携の一覧（連携先・頻度・データ項目まで）
- 画面と帳票の一覧（それぞれの点数と、実際に使われているかの印）
- 現行データの状況（件数・保持年数・欠損や表記ゆれの有無）
- 編集できる形式での納品（表計算やドキュメントファイル。PDFのみにしない）
最後の項目は地味ですが効きます。PDFだけで納品されると、他社に渡して見積もりを取るときにも、要件を書き足していくときにも、そのまま使えません。編集できる形で受け取り、自社で更新していけるようにしておくと、この資料は刷新後の設計書の土台としても生き続けます。
あわせて、調査中に出てきた「誰も理由を説明できない処理」を別リストにしてもらうよう頼んでおくと役に立ちます。この一覧が、後で引き継ぐかどうかを判断する材料になります。開発会社は判断できないので、リスト化までを依頼し、判断は自社で持つのが現実的な分担です。
解析費用の見方と変動する条件
費用については、正直なところ一律の相場を示せる作業ではありません。同じ「販売管理システムの調査」でも、対象が20機能か200機能かで桁が変わりますし、ソースコードまで読むかどうかでも大きく違います。金額そのものよりも、何によって増減するのかを押さえるほうが実用的です。
増減の要因は主に4つあります。調べる機能の数と深さ、ソースコードの行数と言語（COBOLなど扱える人が限られる言語は単価が上がります）、外部との連携本数、そして社内で協力できる人がどれだけ時間を出せるかです。最後の要因は見落とされがちですが、現場に聞けばすぐ分かることを開発会社が調べると、その分の工数が請求されます。社内の担当者がヒアリングに応じる時間を確保できるかどうかで、費用は素直に変わります。
見積書を受け取ったら、金額の総額より先に「何機能を、どの深さで、何人日かけて調べる前提か」を確認してください。ここが書かれていない見積書は、後から範囲が増えたときに追加請求の根拠になります。なお、ここで挙げた要因はあくまで一般的な目安なので、実際の判断は個別の見積もりで前提を確認してください。刷新本体の費用がどう積まれるかは、基幹システム刷新の費用相場はいくら？内訳と見積もりの読み方で整理しています。
解析結果を刷新の依頼にどうつなぐか
調査が終わると、機能一覧やデータ連携の一覧が手元に残ります。ここからが本番で、この資料をそのまま開発会社に渡しても、返ってくるのは「現行と同じものを作る」見積もりです。現行踏襲の見積もりは、使っていない機能まで含んだ金額になります。現行踏襲がなぜ失敗しやすいのかは、基幹システムのリプレイスとは？進め方と発注側の判断基準でも触れています。
やることは2つです。ひとつは、引き継がない機能に印を付けること。調査で「直近1年で使われていない」と分かったものを落とします。もうひとつは、今後やりたいことを1行ずつ足すことです。現行にはないが業務として必要になっている処理を書き足しておくと、開発会社は刷新後の姿を前提に見積もれます。
この2つを反映した資料が、そのまま発注時の要件のたたき台になります。抜けが出やすいのは非機能の部分（同時に使う人数、保存期間、締め処理の時間帯など）なので、要件定義書レビューシート（8カテゴリ60項目）で照らして確認しておくと、後からの追加費用を減らせます。
レガシーシステムの解析についてよくある質問
- Q. レガシーシステムの解析とリバースエンジニアリングは同じですか？
- A. リバースエンジニアリングは解析の一部です。解析はヒアリング・画面操作の記録・ソースコードの読解という3層で構成され、このうちソースコードから仕様を書き起こす部分がリバースエンジニアリングにあたります。全機能でソースコードまで読む必要はないため、どの機能をどの層まで調べるかを先に決めるのが費用を抑える鍵になります。
- Q. 解析にはどれくらいの期間がかかりますか？
- A. 対象の広さと深さ次第で、数週間で終わることも数か月かかることもあります。期間を読みやすくするには、最初から全体を契約せず「まず2週間で機能一覧とデータ連携の一覧まで」のように区切って発注し、出てきた内容を見てから次の範囲を決める進め方が有効です。社内でヒアリングに応じる時間を確保できるかどうかでも期間は変わります。
- Q. 解析はAIを使えば安くなりませんか？
- A. ソースコードの読解や処理の要約にはAIが使われ始めており、下読みの効率は上がっています。ただし、そのコードが業務上どういう意味を持つのか、今も使われているのかという判断は現場の情報がないとできません。安くなる可能性がある部分と、人が確認しないと決まらない部分が混在するため、見積書ではAIで何を代替する前提かを確認しておくと納得感が出ます。
- Q. 現行のベンダーに調査を頼んでも問題ありませんか？
- A. 中身を把握している相手なので、早く安く済むことが多い選択です。注意点は、成果物を自社の資産として受け取れるかどうかです。他社にも刷新の声をかけるつもりがあるなら、資料の二次利用が可能かを契約前に確認してください。ここを曖昧にすると、結局その会社にしか頼めない状態が続きます。
- Q. 設計書がないまま刷新を進めることはできますか？
- A. 進められないわけではありませんが、見積もりの精度が落ちます。前提が固まらないぶん、開発会社はリスクを金額に乗せるか、着手後に追加請求する形になります。結果として、調査費用を惜しんだ分より大きな金額差になることが多いです。少なくとも機能一覧とデータ連携の本数だけは、発注前に押さえておくことをおすすめします。
