業務システムのリプレイス｜直し続けるか作り直すかの判断

画面の項目を1つ増やしたいだけなのに、改修の見積が思っていた額の何倍かで返ってくる。よくある話です。内訳を聞くと、たいてい実装より前の作業が大きく取られています。どこを直せばよいかを探す作業と、直したときに他の画面や帳票に影響が出ないかを確かめる作業。この2つは、中身が分からなくなっているほど伸びやすくなります。

経済産業省のDXレポートに、この状態を言い切った一文があります。

技術が古いこと自体が問題だ、とは書かれていません。「古い技術を使っているシステムだから必ずレガシー問題が発生するわけではない」。手が入り続けていれば、ブラックボックス化はしにくい。ただし、この箇所には続きがあります。古いつくりのシステムは手を入れるほど肥大化して複雑になりやすく、開発から時間が経つほど確率は上がる。新しいクラウドの技術で作っても、時間とともに同じ問題が起こり得るとしています。

詰まる場所は、会社の規模によって違ってくるようです。IPAの2024年度ソフトウェア動向調査に、いちばん重要なレガシーシステムを1つ思い浮かべてもらい、それをレガシーだと判断した理由を聞いた設問があります。回答データを従業員の規模で割ってみました。

下の2行が、規模で入れ替わっています。大きい会社で先に効いているのは、手を入れ続けた結果として複雑になったこと。数十名規模で先に効いているのは、資料がなく、分かる人が限られていることのようです。同じ「古い」でも、詰まっている場所は同じではないと読めます。

この規模別の内訳は、調査の報告書には載っていません。IPAが公開している回答データから当社で集計したものです。対象は、回答したユーザー企業662社のうち、レガシーに該当するシステムを持っている、または過去に持っていたと答えた373社。従業員数を答えなかった1社を除くと、300人以下が140社、301人以上が232社です。当てはまるものをすべて選ぶ形式です。調査期間は2024年12月17日から2025年2月14日。ただし、どういう会社に配られた調査なのかは公表されていないので、日本の会社全体の割合として読むことはできません。

厄介なのは、この状態が外からは見えないことです。同じ資料には、改修を請け負う側でも受注の段階では判断がつかず、「開発を開始後にはじめて発覚する」とあります。そうなる理由も書かれています。発注する側にも自覚がないので、依頼の文書にそのことが載らない。そういう順番です。

裏を返せば、聞けば分かる部分でもあります。引き合いを受けてすぐに金額を出す会社より、先に何度かやり取りして、いま何がどう動いているか、中身を知っている人が誰か、資料がどこまで残っているかを確かめる会社のほうが、あとの金額が動きにくくなります。ここを飛ばした見積もりは、着手してから出てきた分が、あとで金額か納期のどちらかに乗ってきやすくなります。発注する側から見れば、値段を出す前に中を見に来るかどうかが、相手を選ぶときの手がかりです。

替えどきを調べると、「導入から5年が目安」という説明に行き当たります。その根拠をたどると、国税庁が示すソフトウエアの耐用年数に行き着きます。複写して販売するための原本と研究開発用のものが3年、それ以外が5年とされています。ここは記載のとおりです。

ただ、耐用年数は減価償却の期間です。買った費用を何年に分けて計上するかを決めた数字であって、何年で使うのをやめるかを指示したものではありません。国税庁の記載も、取得価額の扱いと年数を示しているだけで、更新の時期には触れていません。償却を終えたあとも動き続けているシステムは、珍しくありません。

年数の代わりに見るなら、次の5つです。1つでも当てはまるなら、判断の材料が揃い始めたところだと考えて構いません。

• 直したい箇所を探す時間が、直す時間より長くなった
• 動いている土台（サーバーのOS、データベース、言語）のサポート終了日が決まった
• 制度が変わるたびに、毎回まとまった改修になる
• 中身を知っている人が、社内にも開発会社側にもいなくなった
• 他のサービスとデータをやり取りしたいのに、取り出す方法が用意されていない

では、何が決め手になるのか。同じIPAの調査に、移行を決めるとしたら何が決め手かを最大3つまで聞いた設問があります。300人以下の140社で上に来たのは、障害が頻発して直しきれなくなった（55.7%）と、保守の要員が確保できない、または保守料が上がった（45.7%）。経営者の方針転換は27.1%、競合の動きは27.9%で、下に並びます。ただし、この140社のうち移行を実施中か完了しているのは34社。残りは計画の段階か、まだ判断がついていません。実際のきっかけの記録ではなく、決め手に挙がる要素と見ておくのがよさそうです。

先に挙げた5つのうち、期限が決まっているのはサポート終了日だけです。土台のサポートが切れると、脆弱性が見つかっても修正が配られません。有償で延長できる製品もありますが、期間や対象が限られるのが通例です。日付はベンダーが公表しているので、まず自社のシステムが何の上で動いているかを開発会社に一覧で出してもらい、それぞれの終了日を突き合わせます。ここが決まると、いつまでに何を決めるかが逆算できます。

直すか作り直すかの二択で考え始めると、たいてい高いほうに寄ります。実際には、ほかに3つあります。当社は作り直しを請け負う側ですが、そこまでしなくて済むなら、そのほうが安く上がるはずです。

見落とされやすいのは、いちばん下です。作り直しの相談で機能を数えていくと、毎月出しているのに誰も開いていない帳票が出てきます。作り直す前に外せば、その分を見積もりから落とせます。

既製のサービスに移す道も、思っているより広く残っています。自社ならではのやり方が要るのは業務全体ではなく、そのうちの一部であることが多いためです。自分たちで作る場合の線引きは業務システムの内製化にまとめています。

どちらを選ぶかは、次の4つを並べると見えてきます。金額の大小より、内訳の形で判断するほうが外しにくいです。

• 改修の見積のうち、調べる作業と確かめる作業が占める割合
• 直したい箇所が1つに収まるか、複数の画面や帳票にまたがるか
• 土台のサポートが、あと何年残っているか
• そのまま新しいシステムに入らないデータがあるか

1つ目がとくに効きます。実装が2割で、残りは調査と影響の確認という見積もりが返ってきたなら、次に同じ規模の改修を頼んでも、割合は大きくは変わらないことが多いです。1回分の金額だけでは判断がつかなくても、この先3年に予定している改修を並べると、作り直しの見積もりと比べられる形になります。

割合が分からないなら、調査だけを切り分けて先に頼む手があります。中身を読んで、どこに何があり、直すとどこに響くかを書き出してもらう。その結果を見てから、改修と作り直しのどちらを頼むかを決めます。まとめて発注した場合にどこへ出るかは、契約の形で変わります。準委任なら出てきた分がそのまま費用に乗り、請負なら受注側が抱え込んで納期に出る。この種の案件が大きな赤字案件になり、訴訟にまで行くことがあるのは、先ほどのDXレポートにも書かれているとおりです。どちらに転んでも、発注側に得はありません。

調査を頼む先は、作り直しも売っている会社になることが多く、当社もその一社です。作り直しが必要という結論に傾きやすい構造があるので、作り直しを売らない立場に見てもらう手もあります。どちらに頼むにしても、引き継げませんという結論だけの報告ではなく、何がどこまで分かって、何が分からなかったかまで書いてもらうと、次の判断に使えます。あわせて、報告書を他社に見せてよいことを先に決めておきます。ここが決まっていないと、調査を頼んだ1社としか次の話ができなくなります。いまの開発会社に頼む場合は、乗り換えの相談と受け取られることもあるので、伝え方はシステムの引き継ぎにまとめました。年間の保守費が開発費の何割に当たるかを調べた資料も、そちらで扱っています。

作り直しの見積もりがいちばん膨らみやすいのは、いまと同じものをそのまま作ると決めたときです。使っているあいだに足された機能は、足した理由ごと残っています。全部を移すと、使われていない画面の作り直しにも費用がかかり、確認する項目も増えます。

使われていない機能は、聞いて回るより記録から探すほうが早いことが多いです。見るのは3つ。

• 画面ごとのアクセスの記録 — 残っていれば、直近1年で開かれていない画面が出てくる
• 帳票ごとの出力件数 — 毎月自動で出しているだけのものが混ざっている
• 登録はできるのに、その後どこにも出てこない項目 — 入力の手間だけが残っている

記録が残っていないなら、担当者に3つ聞きます。この画面を今月開きましたか。開いた結果を何に使いましたか。無くなったらどう困りますか。3つ目に具体的な答えが返ってこない機能は、いったん外す側に置いて構いません。

外すと決めるのは、その業務の責任者です。開発会社ではありません。ここを開発会社に委ねると、判断がつかない機能は残す方向に寄りがちです。外した一覧は残しておきます。稼働してから「あれが無い」と言われたときに、いつ誰の判断で外したかがすぐ分かるためです。

切替のやり方は3つです。どれが優れているかではなく、業務を止められる時間と、現場が余分に負える手間のどちらを差し出すかで決まります。

範囲の切り方は、業務で切る（受注、在庫、請求の順に移す）、部門で切る、拠点で切る、まず数人だけ先に使ってもらう、あたりが多いところです。データのやり取りが薄いところで切ると、つなぎの仕組みは小さくて済むことが多いです。同じ台帳を昼も夜も書き換え合っている2つの業務は、その間で切ると高くつきます。両側に仮の仕組みが要り、そこだけで費用が乗るためです。

並べて動かす方式を選ぶときは、二重入力を誰がどれだけやるかを先に決めておきます。この手間は見積もりに出てきません。現場の残業という形で出てくることになります。期間も先に区切ります。落ち着くまでとしておくと、たいてい落ち着きません。

データ移行の見積もりを「何万件だからいくら」と考えると、たいてい足りません。件数が同じでも、新しいシステムにそのまま取り込めるデータと、形を直してから取り込むデータでは、手間が桁で変わります。先に洗い出すのは件数ではなく、次の類型に当てはまるものです。

この表は、開発会社に渡してそのまま埋めてもらう形でも使えます。埋まらない行が出たら、そこが調査の対象です。移行の費用が「一式」でしか出てこないときも、この単位で分けてもらうと比べられるようになります。

移す範囲を決めるときは、全部を移そうとしないほうが安く済みます。毎日使うのは直近のデータだけで、古い分は年に数回しか参照されない。そういうことが少なくありません。その場合、直近だけを新しい側に移し、古い分は次の節の形で残します。

切り替えた後、旧システムをいつ止めるかを決めていないと、動かしたまま何年も費用が出ていきます。逆に、決めずに止めてしまうと、後から必要になったデータが取り出せません。残し方は3つあり、費用と手間が違います。

• 動かしたまま、参照だけできる状態にする — いちばん楽だが、サーバー代と、動いている土台の面倒を見る手間が続く
• 必要なものを出力して残す — 帳票の形やCSVで保管する。安いが、後から条件を指定して探しにくい
• 新しい側に取り込む — 参照用の画面を作る費用がかかるが、止められる

1つ目は、税務の側から見ても通る残し方です。システムを変えた場合、変更前のデータは変更前のシステムで検索できていればよい。国税庁の一問一答に、そのままの問答があります。

ただし条件が付きます。検索に使うデータが、保存しているものと同じだと確かめられること。旧システムを凍結して置いておくなら、中身を書き換えられない状態にしておきます。

止める日は、自社の都合だけでは決められません。帳簿や請求書のように保存が求められる書類をシステムが持っているなら、その期間は読み出せる状態にしておきます。数え始めが取引の日とは限らないので、思っているより長くなることがあります。自社のシステムがどの書類を持っているかを一覧にして、顧問の税理士に確かめてから決めてください。

個人情報を持っている場合も、旧システムの扱いは決めておきます。止めるまで置いておくあいだは、使っていなくても管理の対象として残ると考えておくのが無難です。切り替えた後に同じデータが2か所にある状態が長引くと、削除の依頼が来たときに片方だけ消して終わりになりがちです。止めると決めた日に、中のデータをどう処分するかまで一緒に書いておきます。開発会社の環境に置いたまま残す場合は、そこをどう扱うかも相手と決めておいたほうがよさそうです。

切替の日に決めておくのは、うまくいく手順ではありません。どこまでに終わらなければ戻すか、です。ここが決まっていないと、確認が長引いたときに、進むか戻るかを判断できる人がいない時間ができます。

通しで試す作業を省くと、当日の所要時間が読めなくなります。データを移すのに3時間だと思っていたら8時間かかった、という形でずれるためです。前日までに一度通しておけば、止める時刻と開ける時刻を実測から決められます。

戻した場合に困るのは、止めてから戻すまでのあいだに現場が動いていたときです。紙やメールで受けた分をどこに書き留めておくかを、事前に1か所決めておきます。決めていないと、各自の手元に散り、どちらのシステムにも入らない分が残ります。

情報システムの専任担当がいない会社では、窓口が本業との兼務になりがちです。ここを見込まずに始めると、止まるのは開発ではなく本業のほう。筆者が関わった案件では、要件を決めている期間で週に半日から1日、切替の前後は数日単位でした。この分を先に空けておくと、あとが楽になります。

窓口が1人だと、その人が休んだ週に全部が止まりやすくなります。役割は3つに分けておくのが無難です。

• 決める人 — 費用と範囲を最後に判断する。役員か、その業務の責任者
• 答える人 — 業務の中身を説明する。実際にその画面を毎日使っている人
• 止められる人 — 期日に間に合わないと分かったときに、いったん止めると言える人

決める内容の順序は、作り直しでも新規開発でも大きくは変わりません。何をどこまで作るかを決める工程の進め方はシステム開発の要件定義の進め方に、発注先の選び方はシステム開発の外注先の選び方にまとめています。

• 分かれ目は古さではなく、直したい箇所に手を入れるのにどれだけ調べる必要があるか
• 「導入から5年」の根拠とされる耐用年数は減価償却の期間で、使うのをやめる時期ではない
• 選択肢は5つ。そのまま使い切る、直し続ける、既製のサービスに移す、作り直す、その業務をやめる
• 改修の見積のうち調査と確認が占める割合を見る。分からなければ調査だけを先に切り分けて頼む
• 作り直すなら、先に捨てる機能を決める。決めるのは業務の責任者
• 切替は3方式。止められる時間と、現場が負える手間のどちらを差し出すかで選ぶ
• 移行費は件数より、そのまま入らないデータがどれだけあるかで決まる。旧システムを止める日は、帳簿書類の保存が要る期間から逆算する
• 切替の日は、何時までなら戻せるかと、判断する人を先に決めておく

当社は受託開発と運用保守、エンジニアの常駐を提供しています。他社が作ったシステムについて、調査だけを切り分けてお引き受けすることもできます。直し続けるか作り直すかの判断だけでも構いません。必要でしたらお問い合わせからお声がけください。