古いシステムの刷新をようやく決めたものの、どこに頼めばいいのかで止まっている。検索すると「おすすめ○社」という記事ばかり出てきて、並んでいる会社の違いがよく分からない。そんな状態でこの記事にたどり着いた方が多いのではないかと思います。
レガシーシステムの刷新で最初に決めるのは、どの会社に頼むかではありません。今の保守をしているベンダーに続けて任せるのか、別の会社にも声をかけるのか、という分岐です。ここが決まらないと候補の集め方も比較のしかたも定まりません。この記事では、その分岐の考え方から、古い言語や環境を扱えるかの確かめ方、提案を受けたときの質問、そして刷新後に同じ状態へ戻さない契約条項までを整理します。会社の規模別の違いや選定プロセス全般は別の記事に譲り、ここではレガシー刷新に固有の判断だけを扱います。
この記事のポイント
- 最初の分岐は会社選びではなく、今の保守ベンダーに続けて任せるかどうか
- 「古い言語に対応可」は、社内に現役の技術者がいるのか協力会社に出すのかで意味が変わる
- 刷新実績は社数ではなく、同じ言語からの移行かデータ移行の規模かまで聞く
- 設計書の更新義務と成果物の権利を契約に入れないと、10年後にまた同じ相談になる
目次
レガシーシステムの刷新を任せる開発会社の条件
まずは候補を集める前の話からです。レガシーの刷新は、まっさらな状態から作る新規開発と違って「今動いているもの」が相手になります。長年の運用で積み上がった例外処理や、部門ごとの独自ルールを引き継ぐかどうかを判断しながら進むため、会社に求める条件も新規開発とは変わってきます。
まず現行ベンダーに続けるかを決める
最初の分岐は、今そのシステムを保守しているベンダーに刷新まで任せるかどうかです。ここを決めずに候補を集め始めると、比較の土俵が定まりません。
現行ベンダーに続けて頼む利点は、中身を知っていることに尽きます。設計書が残っていなくても、当時の経緯や例外処理の理由を把握している人がいれば、調査にかかる時間と費用は確実に減ります。一方で難しいのは、その会社にとって都合の悪い提案が出にくいことです。現行の作りを前提にした案になりやすく、業務ごと見直す発想は出てきにくくなります。
他社に替える場合は逆で、しがらみのない提案が出てくる代わりに、現行を理解するところから始まるので初期の手間が増えます。判断の目安としては、今後も業務のやり方を大きく変えないなら現行ベンダー継続が現実的で、業務そのものを作り替えたい、あるいは今の保守費用や対応速度に不満があるなら他社にも声をかける価値があります。
大事なのは、現行ベンダーを候補から外す必要はないという点です。声をかける先を増やしたうえで、現行ベンダーにも同じ条件で提案してもらえば、中身を知っている強みを活かしつつ比較もできます。なお、刷新の進行管理そのものを外部に頼むかどうかは別の判断になるので、基幹システム刷新はコンサルに頼むべき？開発会社との役割分担のほうを参照してください。
古い言語と環境を扱えるかの確かめ方
次に、そもそも扱える会社かどうかです。会社紹介のページには「COBOL対応可」「オフコンからの移行実績あり」と書かれていますが、この一文だけでは判断できません。確かめたいのは体制のほうです。
聞き方としては、「その言語を書ける技術者は御社の社員ですか、協力会社ですか」「今そのスキルを持っている方は何名で、平均何年くらい携わっていますか」の2つが有効です。協力会社に出すこと自体は普通のことですが、その場合はプロジェクトの途中で人が入れ替わるリスクと、費用に中間マージンが乗ることを見込んでおく必要があります。
もうひとつ確認したいのが、動かしている環境側の対応です。言語だけでなく、オフコンやメインフレーム特有の運用、ジョブ管理、帳票出力の仕組みまで含めて経験があるかどうかで、移行時のつまずき方が変わります。プログラムは変換できても、夜間バッチの並びや帳票のレイアウトで詰まるケースが実際には多いところです。
刷新実績は移行の中身まで聞く
実績の確かめ方も、粒度を落とさないと意味がありません。「刷新実績200社」と言われても、自社に近いのかどうかは分からないからです。
聞くべきは社数ではなく中身です。具体的には、同じ言語・同じ環境からの移行を手がけたことがあるか、そのときのデータ移行はどれくらいの規模だったか、外部システムとの連携は何本あったか、並行稼働の期間はどれくらい取ったか。この4つが具体的に返ってくれば、実際にやっている会社だと判断できます。
あわせて有効なのが、うまくいかなかった箇所を聞くことです。移行のどこで想定より時間がかかったか、追加費用が出たとしたら何が原因だったか。経験のある会社ほど具体的に答えられますし、その内容が自社の状況と重なるかどうかも見えてきます。成功事例だけを並べる提案は、判断材料としては弱いと考えておいてください。
安い提案より現行調査を明言する会社
金額の比較は最後にしたほうがうまくいきます。レガシー刷新で相見積もりを取ると、各社の金額が大きくばらつくことがありますが、その差の多くは前提の置き方から来ています。
安い提案は、現行の調査を軽く見積もっているか、そもそも範囲に入れていないことが少なくありません。着手してから「調査が必要でした」となれば、結局その分は追加になります。逆に、最初から「まず旧システムの全構成を洗い出します」と明言する会社は、金額としては高く見えても後から膨らみにくい傾向があります。
ここを揃えるいちばん確実な方法は、現行調査を先に済ませて、その結果を各社に同じ資料として渡すことです。前提が揃えば金額を横に並べて比べられます。調査をどこまでやれば見積もりが取れる状態になるかは、レガシーシステムの解析はどこまで必要？費用と頼み方で整理しています。
レガシーシステムの開発会社を見極める質問
候補が絞れたら、次は提案を受けたあとの確認です。技術的な詳細が分からなくても、聞き方さえ決めておけば会社の実力と姿勢はかなり見えてきます。あわせて、刷新後に同じ状態へ戻さないための契約条件も、この段階で決めておきます。
提案を受けたら確かめる5つの質問
提案書を受け取ったら、内容の評価に入る前に次の5つを聞いてみてください。答えの中身だけでなく、その場で答えられるかどうかも判断材料になります。
提案を受けたときに聞く5つの質問
- 実際に手を動かすのは御社の社員か、協力会社か。その比率はどれくらいか
- 現行システムの調査はどこまで行い、その結果は誰の資産として残るか
- 引き継がない機能は誰がどう決める前提になっているか
- 並行稼働の期間は何か月を見込み、その間の運用は誰が担当するか
- 稼働後の保守は同じ体制が続くのか、別のチームに引き継がれるのか
特に3つ目が効きます。引き継ぐ機能を決めるのは本来こちらの仕事なのですが、提案によっては「現行踏襲」として全部を作り直す前提になっていることがあります。この場合、使っていない機能まで金額に含まれます。誰が決めるのかを明確にしておくと、後から範囲を削る余地が残ります。
5つ目も見落とされがちです。作る体制と運用する体制が別会社になっていると、稼働後に不具合が出たときの窓口が分かれて、対応が遅くなることがあります。稼働後まで含めて誰が面倒を見るのかを、契約前に確認しておいてください。
同じ状態に戻さない契約条項
ここが刷新ならではの論点です。せっかく作り直しても、契約が以前と同じままなら、10年後にまた「設計書がなくて誰も触れない」という相談に戻ります。それを避けるために、次の3点を契約に入れておきたいところです。
ひとつ目は、設計書の更新義務です。改修のたびに設計書を最新の状態に保つことを、保守契約の作業範囲として明記します。ふたつ目は、成果物とソースコードの扱いです。誰が権利を持ち、他社に引き継ぐときに二次利用できるのかを決めておきます。みっつ目は、保守の引き継ぎ条件です。将来的に別の会社へ移すことになった場合に、どの資料をどの形式で引き渡すかを事前に決めておきます。
こうした条件を発注側から出すときの拠り所になるのが、IPAが公開している情報システム・モデル取引・契約書（第二版）です。ユーザー企業とベンダー、業界団体、法律の専門家が参加して作られた中立的なひな型で、第二版では見直しのポイントに「再構築対応」が含まれています。ゼロから条文を考えるのではなく、ここを土台に自社の条件を足していくのが現実的です。特定の会社に縛られる状態そのものをどう避けるかは、ベンダーロックインの対策と回避・脱却の方法で詳しく整理しています。
避けたほうがよい提案のサイン
逆に、慎重になったほうがよい提案の特徴もあります。断定はできませんが、次のような傾向が出ている場合は、追加で確認したほうが安全です。
| 提案に出るサイン | 確認したいこと |
|---|---|
| 現行調査の工程が入っていない | 調査なしで金額を出した根拠は何か |
| 「全部お任せください」と説明される | 自社側で決める作業は何がどれだけ残るか |
| 実際の担当者が商談に出てこない | 着手時に誰が入る想定で、いつ会えるか |
| 再委託先を明かさない | どの工程を誰が担当し、責任はどこにあるか |
| 並行稼働の期間が極端に短い | その期間で確認できる業務の範囲はどこまでか |
「全部お任せください」は、一見ありがたい言葉なので判断が難しいところです。ただ、引き継ぐ機能の取捨や業務側の受け入れ確認は、外部の会社には決められません。ここを引き受けると言う会社は、こちらの事情を知らないまま現行踏襲で作ることになりがちです。頼もしさと危うさが同居している言葉だと考えておくとよいと思います。
社内に残す役割を決めてから頼む
最後に、会社選びと同じくらい大事な点です。どの会社に頼むにしても、自社側に必ず残る役割があります。ここを決めずに発注すると、良い会社を選んでもプロジェクトは滞ります。
残るのは主に3つです。引き継ぐ機能と捨てる機能を決めること、業務側の受け入れ確認を回すこと、そして社内の各部門との調整です。どれも現場の事情を知っている人でないと判断できないので、外に出せません。逆に言えば、この3つを担当する人を社内で決めておけば、開発会社に任せられる範囲がはっきりします。
複数社から提案を受ける場合は、同じ観点で並べて比べられる形にしておくと判断が早くなります。ベンダー選定比較表テンプレート（10カテゴリ100項目）を使うと、体制・実績・保守・契約条件を同じ軸で整理できます。
レガシーシステムの開発会社についてよくある質問
- Q. 今の保守ベンダーにそのまま刷新も頼んで問題ありませんか？
- A. 中身を知っている強みがあるので、選択肢としては十分に妥当です。ただし現行の作りを前提にした提案になりやすいため、業務のやり方から見直したい場合は他社にも声をかけて比べたほうが判断材料が増えます。現行ベンダーを候補から外す必要はなく、同じ条件で提案してもらう形が現実的です。
- Q. COBOLやオフコンを扱える会社は今も見つかりますか？
- A. 見つかりますが、体制の確認が欠かせません。対応可と書かれていても、実際に書ける技術者が社員なのか協力会社なのかで、途中の人員交代のリスクや費用の構造が変わります。何名がどれくらいの経験を持っているかまで聞いておくと、着手後のずれを減らせます。
- Q. 相見積もりは何社くらい取るのがよいですか？
- A. 3社前後が扱いやすい数です。増やすほど比較の手間が増えますし、こちらの説明工数も社数分かかります。それよりも、各社に渡す前提資料を同じにするほうが効きます。前提が揃っていない状態で5社から取っても、金額は比べられません。
- Q. 大手と中小のどちらに頼むべきですか？
- A. 規模だけでは決まりません。レガシー刷新では、自社と同じ言語・環境からの移行経験があるか、稼働後の保守まで同じ体制で見てもらえるかのほうが結果に効きます。会社の規模による一般的な違いは、受託開発会社の選び方を扱った記事のほうが詳しいので、そちらと合わせて判断してください。
- Q. 提案の金額に大きな差が出たときはどう見ればよいですか？
- A. まず前提の違いを疑ってください。現行調査を含むかどうか、引き継ぐ機能の範囲、並行稼働の期間、保守の年数。この4つが揃っていないと金額は比べられません。差の理由を各社に確認し、それでも説明がつかない場合だけ、金額そのものの妥当性を見る順番が安全です。
