業務システムの改修の費用は何で決まるか：見積もりの内訳と、確かめる項目

今使っている業務システムに、項目を一つ足したい。帳票の形を変えたい。制度が変わったので、計算の仕方を直したい。こうした相談を開発会社にすると、思っていたより大きな金額の見積もりが返ってくることがあります。

「画面に入力欄を一つ足すだけなのに、なぜ何十万円もかかるのか」。発注する側からすると、もっともな疑問です。ただ、開発会社の側から見ると、入力欄を一つ足す作業そのものより、その前後にある作業のほうがずっと大きいことがよくあります。その欄の値はどこに保存され、どの帳票に出て、どの集計に使われるのか。直したあと、今まで動いていた所が変わらず動くか。こうしたことを調べて確かめる作業です。

この記事は、今ある業務システムの改修を考えている情報システムの担当者や、事業の責任者に向けて書いています。新しくシステムを作るときの見積もりの見方は、別の記事で扱う予定です。ここでは「今動いているものを直す」ときに特有の話に絞ります。

• 改修の費用の内訳（何に時間がかかっているか）
• 費用を左右する7つの条件
• 保守契約に含まれる範囲と、別に見積もる範囲
• 見積もりを受け取ったときに確かめる項目
• 費用を抑えるために、発注する側でできること
• 会計の上での扱い（修繕費か、資本的支出か）

結論：改修の費用は「直す量」より「調べる量」と「確かめる量」で決まる

先に結論を書きます。改修の費用を決めるのは、主に次の3つです。

1. 調べる量：直す所がどこに影響するかを調べる手間。資料が古い、作った人がいない、といった条件で大きく増えます。
2. 直す量：実際にプログラムや設定を変える手間。発注する側が思い浮かべる「改修」は、たいていこの部分です。
3. 確かめる量：直した所と、直していない所が正しく動くかを確かめる手間。テストの仕組みが整っているかで大きく変わります。

見積もりの金額に納得できないときは、この3つのうち、どこに時間を見込んでいるかを開発会社に聞いてみてください。理由が分かれば、発注する側で減らせる所が見えてきます。たとえば、資料をそろえて渡せば調べる量は減りますし、いくつかの改修をまとめて頼めば、確かめる作業を1回で済ませられることがあります。

改修の費用の内訳：直す作業は全体の3割ほど

改修の作業のうち、何にどれだけ時間がかかっているのか。これを企業から集めた数字で示しているのが、JUAS の「ソフトウェアメトリックス調査 2018年版（システム開発・保守調査報告書）」です。ユーザー企業のシステム保守のプロジェクトについて、保守作業の割合を次のようにまとめています（データ数660件）。

（JUAS「ソフトウェアメトリックス調査 2018年版」図表 H2-7「保守作業の割合」より）

プログラムを直す「修正作業」は、平均で31.5%です。残りの約7割は、どこを直すかを調べる作業、直したものを確かめる作業、資料を直す作業が占めています。

「入力欄を一つ足すだけ」の改修でも、費用が直す作業の何倍にもなるのは、このためです。調べる、確かめる、資料を直すという作業は、直す所が小さくても、ある程度は必ずかかります。

なお、この調査の数字は、ユーザー企業が回答したプロジェクトの平均と中央値です。最小値は0%、最大値は100%で、プロジェクトによる差はとても大きいと考えてください。報告書の考察でも、保守のデータは回答のばらつきが非常に大きい、と書かれています。自社の改修の見積もりを、この割合と比べて良し悪しを決めるためではなく、「費用のうち、何に時間がかかっているか」を理解するための目安として使うのがよいと思います。

改修の作業は、どんな手順で進むのか

同じ JUAS の報告書では、保守作業の種類を7つに分け、それぞれの手順を挙げています。たとえば、法律の変化や、新しい受注仕様・顧客仕様、新しい設備や環境に合わせる「適応保守」の手順は、次のとおりです。

1. 環境変化情報の把握
2. 影響範囲の調査・分析
3. 適応計画の作成、変更方法の検討
4. 変更および変更部分のテスト
5. リグレッションテスト
6. 移行、本番投入、確認、ユーザーへの引渡し
7. 移行後のフォロー

（JUAS「ソフトウェアメトリックス調査 2018年版」図表 H3-2「保守作業発生の理由」より）

不具合を直す「是正保守」も、品質を上げる「完全化保守」も、ほぼ同じ流れです。ここで「リグレッションテスト」と呼ばれているのは、直した所以外が、間違って変わっていないかを確かめるテストのことです。報告書でも「修正必要箇所以外の箇所を間違って直していないか？」と説明されています。

見積もりの明細には、この手順のどれが含まれているかが書かれているはずです。もし「改修 一式」としか書かれていなければ、どの手順まで含んでいるかを聞いてみてください。特に、リグレッションテストと、本番に反映したあとのフォローが含まれているかで、金額は変わります。

改修の費用を左右する7つの条件

同じような改修でも、システムによって費用は大きく変わります。発注する側から見て、費用を左右する条件は主に次の7つです。

1. 資料と実際の動きが合っているか

改修の調べる量を最も大きく左右するのが、資料の状態です。IPA（情報処理推進機構）の「情報システム・モデル取引・契約書（第二版）」の解説では、長く使われてきたシステムについて、次のような問題が少なくないと書かれています。

長年運用・保守を続けてきたシステムを再構築する場合、関係者の退職や異動により、対象システムが実現する業務内容やシステムの仕様について理解する人材がいない、対象システムに関するドキュメントが散逸していることや、改良内容のドキュメントへの反映がされず動作しているシステムと設計書やソースコードとが整合していないことがある、といった問題があることが少なくない。

（IPA「情報システム・モデル取引・契約書（第二版）」の解説より）

この文章は作り直しの場面について書かれたものですが、改修でも同じことが起きます。設計書が実際の動きと合っていなければ、開発会社はソースコードを読んで、実際の動きを確かめるところから始めます。その分、調べる量が増えます。

JUAS の報告書では、保守の対象になっているシステムの経過年数は、平均値が11.0年、中央値が8.0年でした。10年近く使われているシステムでは、その間の改修が資料にすべて反映されているとは限りません。

2. 作った会社が直すのか、別の会社が直すのか

作った会社が直す場合は、システムの作りを知っている人がいるので、調べる量は少なく済みます。別の会社が直す場合は、まず今のシステムを理解するための調査が必要です。

この調査は、改修そのものとは別に見積もられることがよくあります。発注する側からすると、何も変わらない作業にお金を払うように見えるかもしれません。ただ、調査をせずに改修を始めると、思わぬ所が壊れたり、途中で見積もりをやり直したりすることになりがちです。開発会社を変えるときの調査については、開発会社を途中で変えるとき：引き継ぎで渡すものと、確かめることで詳しく書きました。

3. 影響する範囲の広さ

直す所が、システムのどこまで影響するかです。同じ「項目を一つ足す」でも、次のように影響の広さが違います。

• 画面に表示するだけで、保存しない
• 保存はするが、他の機能では使わない
• 帳票や集計、他のシステムとの連携にも使う

保存する項目を足すと、データベースの形が変わります。その項目が帳票や集計、他のシステムへの連携に使われるなら、その全部を直して、確かめる必要があります。社外のシステムとつながっている場合は、相手側の確認や日程の調整も必要になります。

4. テストの仕組みが整っているか

確かめる量を左右するのが、テストの仕組みです。プログラムで自動的に動作を確かめるテスト（自動テスト）が整っていれば、直したあとのリグレッションテストの多くを短い時間で済ませられます。自動テストがなければ、人が画面を操作して一つずつ確かめるしかありません。

テスト用の環境があるかどうかも大事です。本番と同じ構成で試せる環境がなければ、改修のたびに準備が必要になります。JUAS の報告書では、保守作業でのツールの使い方として「テスト実行、結果検証に使う」と答えたプロジェクトは46.3%でした（プロジェクト数41件、複数回答）。最も多かったのは「変更・リリース管理、バージョン管理」の58.5%です。

5. データの移行や変換が必要か

項目の意味を変える、コードの体系を変える、といった改修では、今あるデータを新しい形に変える作業が必要になります。何年分のデータがあるか、変換のルールが例外なく決められるかで、手間が大きく変わります。変換したデータが正しいかを確かめる作業も必要です。

6. 本番に反映する手順と、止められる時間

改修したものを本番に反映する作業にも費用がかかります。システムを止められる時間が短い、夜間や休日に作業する必要がある、反映の手順が手作業で多い、といった条件があれば、その分の手間と人数が必要です。反映したあとに問題が起きたとき、元に戻す手順を用意しておくことも必要です。

7. 使っている言語や部品が古くなっていないか

システムを作っている言語やフレームワーク、ライブラリの版が古く、更新を受けられなくなっていることがあります。その場合、改修しようとしても、古い版のままでは直せない、あるいは直す前に版を上げる必要がある、ということが起きます。版を上げる作業は、頼んだ改修とは別の大きな作業になることがあります。

古い版を使い続けることのリスクは、PHPの重大な脆弱性で何が起きたかでも取り上げました。改修の相談をきっかけに、版の状態を確かめてもらうのもよい機会です。

保守契約に含まれる範囲と、別に見積もる範囲

改修の費用で食い違いが起きやすいのが、「保守契約の中でやってもらえると思っていた」というケースです。

保守契約の形は、会社によってさまざまです。JUAS の報告書では、システム保守の契約の形として、次の3つが挙げられています。

（JUAS「ソフトウェアメトリックス調査 2018年版」の「システム保守契約形態」より、要約）

同じ報告書では、組み合わせの例として、一件が5人日以上の作業になるものは保守作業の請負の対象から外して、別に見積もっている企業もある、と紹介されています。

つまり、月額の保守契約を結んでいても、どこまでの改修がその中に含まれるかは、契約ごとに決まっています。よくある区分は、次のようなものです。

• 含まれることが多いもの：問い合わせへの回答、障害の調査と復旧、決められた時間内の小さな修正
• 別に見積もることが多いもの：機能の追加、画面や帳票の作り直し、データ構造の変更、版の更新

改修を相談する前に、今の保守契約で「月に何時間まで」「どの種類の作業まで」が含まれているかを確かめておくと、話が早く進みます。契約書で分からなければ、保守をしている会社に聞いてかまいません。

改修の費用は、毎年どのくらい見込んでおくものか

一つひとつの改修とは別に、システムを使い続ける間、改修にどのくらいの費用がかかるのかも気になるところです。

JUAS の報告書では、自社向けに開発した（パッケージではない）システムについて、稼働後の保守費用と追加開発費用を、初期の開発費用に対する割合で示しています。

（JUAS「ソフトウェアメトリックス調査 2018年版」図表 H2-16「保守費用分析」の自社開発の欄より）

報告書の考察では、この結果から、スクラッチ開発の場合の保守費用は開発費用の20%程度（保守8%＋追加開発12%）かかり、5年間でほぼ開発費と同じ費用がかかる、とまとめています。

この数字の元になったシステムの初期開発費用は、平均で約7億2,500万円です（中央値は約1億5,600万円）。規模の小さなシステムにそのまま当てはまるわけではありません。それでも、「作ったあとも、毎年いくらかは改修にお金がかかる」ことを前提に予算を組んでおくと、改修のたびに予算を取り直す苦労は減らせます。

初年度の追加開発の割合が高いのは、使い始めてから見えてきた要望に対応するためだと考えられます。新しくシステムを作るときにも、稼働後の改修の予算をあらかじめ見ておくとよいでしょう。

見積もりが外れやすい理由

改修の見積もりは、作業を始めてから「思っていたより大きかった」となることがあります。JUAS の報告書の2016年版のデータでは、保守作業の納期が遅れた原因として、次のものが多く挙げられていました（プロジェクト数394件、1位から3位までの合計）。

• 他の作業が割り込んだ（34.7%）
• 保守仕様の変更があった（24.0%）
• 工数見積りが甘かった（18.1%）
• 潜在的バグの影響（13.5%）

これは納期が遅れた原因で、費用が増えた原因そのものではありません。ただ、「途中で仕様が変わる」「直してみたら、もともとあった不具合が見つかる」といったことは、費用が増える原因にもなります。

発注する側でできるのは、改修の中身を始める前にはっきり決めておくことと、途中で追加したい要望が出たら、別の案件として分けて相談することです。要件のまとめ方は、要件定義とは：開発会社に頼む前に、社内でまとめておくことで詳しく書きました。

見積もりを受け取ったときに確かめる項目

改修の見積もりを受け取ったら、次の項目を確かめてください。そのままチェックリストとして使えます。

作業の範囲

• 影響範囲の調査が含まれているか。含まれていない場合、誰がいつやるのか
• 直す所の一覧（画面、帳票、データ、連携）が書かれているか
• 資料（設計書、操作説明書）の修正が含まれているか

確かめ方

• 直した所のテストに加えて、リグレッションテストが含まれているか
• どの環境でテストするか。テスト用の環境を用意する費用は含まれているか
• 発注する側が受け入れの確認をする期間と、その手順が書かれているか

本番への反映

• 本番に反映する日時と、止める時間が書かれているか
• データの移行や変換が必要な場合、その作業が含まれているか
• 反映したあとに問題が起きたとき、元に戻す手順があるか
• 反映したあとのフォローの期間が決まっているか

前提と、増える場合

• 見積もりの前提（資料がそろっている、仕様は変わらない など）が書かれているか
• 前提が崩れたときに、どう扱うか（追加の見積もり、相談 など）が書かれているか
• 今の保守契約の範囲で対応する部分と、別に払う部分が分かれているか

これらの項目が見積もりに書かれていなくても、開発会社が手を抜いているとは限りません。説明を省いているだけのこともあります。分からない所は、遠慮せずに聞いてください。説明を聞くと、金額の理由に納得できることも多いはずです。

改修の費用を抑えるために、発注する側でできること

改修の費用は、開発会社の作業だけで決まるわけではありません。発注する側の準備で、調べる量や確かめる量を減らせることがあります。JUAS の報告書には、保守作業の負担を軽くするために企業が実際に行っている工夫が並んでいます。その中から、発注する側でも取り入れやすいものを挙げます。

改修をまとめて頼む

報告書には「複数要件を対応スケジュール調整により一括で実施」「各種案件のサービスインタイミングを集約（一本化）することで負荷軽減」という工夫が挙げられています。

小さな改修を一つずつ頼むと、そのたびに調査、テスト、本番への反映がかかります。急がないものは、いくつかまとめて頼むと、テストと反映を1回にまとめられます。社内で改修の要望を集めておき、四半期ごとなど決まった時期に相談する方法もあります。

改修の要望に、優先度を付ける

JUAS の報告書の考察では、担当者からの要望から生じた保守作業について、無制限に実施できないような制約を設け始めた企業が多い、と書かれています。

すべての要望をすぐに直そうとすると、費用は増え続けます。「業務が止まる」「法律や制度に合わせる必要がある」「あると便利」のように、要望に優先度を付けておくと、どれから頼むかを決めやすくなります。

今あるものを、そのまま渡す

設計書が古くても、今使っている画面の写し、帳票の見本、操作の手順をまとめたメモなど、手元にあるものはそのまま渡してください。資料と実際の動きがずれていても、「実際にはこう使っている」という情報があれば、開発会社が調べる量は減ります。何を用意すればよいかは、開発会社に初めて相談する前に：用意しておく資料と、決めておくことにまとめています。

調査だけを先に頼む

大きな改修や、作った会社以外に頼む改修では、まず調査だけを頼み、その結果をもとに改修の見積もりを出してもらう方法があります。調査の費用はかかりますが、改修の見積もりに「分からないので多めに見ておく」部分が減り、根拠のある金額になります。調査の結果は、次の改修のときにも使える資料になります。

次の改修のための準備を、少しずつ進める

報告書の工夫には、「テストツールの拡充」「標準テストデータの整備、自動生成」「過去対応内容の蓄積により、調査および見積りの負荷軽減」といったものもあります。

自動テストや資料の整備は、それだけで費用がかかります。ただ、何度も改修するシステムなら、改修のたびに少しずつ整えていくと、次からの改修で調べる量と確かめる量が減っていきます。改修の相談のときに、「今回の改修のついでに、テストや資料をどこまで整えられるか」を聞いてみるのもよいと思います。

会計の上では、修繕費か資本的支出か

改修の費用を社内で処理するときに、経理の担当者から「これは修繕費か、資産か」と聞かれることがあります。

国税庁の法人税基本通達 7-8-6の2では、ソフトウエアのプログラムの修正等について、次のように区分しています。

法人が、その有するソフトウエアにつきプログラムの修正等を行った場合において、当該修正等が、プログラムの機能上の障害の除去、現状の効用の維持等に該当するときはその修正等に要した費用は修繕費に該当し、新たな機能の追加、機能の向上等に該当するときはその修正等に要した費用は資本的支出に該当することに留意する。

（国税庁 法人税基本通達 第7章 第8節より）

おおまかに言えば、不具合を直す、今の働きを保つための修正は修繕費、新しい機能を足す、働きを高める修正は資本的支出（資産に加えて、何年かに分けて費用にするもの）です。同じ通達の注では、仕様を大幅に変えるための費用の扱いや、研究開発費に当たる場合の扱いも書かれています。

一つの改修に、不具合の修正と機能の追加が混ざっていることもあります。経理の処理に合わせたい場合は、見積もりの段階で、作業を「不具合の修正」と「機能の追加」に分けて書いてもらえるか、開発会社に相談してみてください。実際の処理の判断は、顧問の税理士などに確かめてください。

開発会社に改修を相談するとき、伝えること

最後に、改修を相談するときに伝えるとよいことを表にまとめます。

「いつまでに必要か」は、特に大事です。動かせない日が決まっていると、開発会社はそこから逆算して、調査とテストにかけられる時間を見積もります。時間が短いほど、人を増やす必要があり、費用にも影響します。分かった時点で、早めに相談してください。

クリーヴァに相談するとき

クリーヴァでは、今動いているシステムの改修や保守のご相談もお受けしています。クリーヴァが作ったシステムでなくても、まず今の状態をうかがい、何から手を付けるかを一緒に整理します。

この記事のチェックリストと、相談のときに伝えることの表は、クリーヴァに相談いただくときにもそのまま使えます。資料がそろっていなくてもかまいません。手元にあるものから、一緒に確かめていきます。

おわりに

改修の費用が思っていたより大きく見えるとき、その多くは、直す作業の前後にある「調べる」と「確かめる」の部分です。JUAS の調査でも、プログラムを直す作業は全体の3割ほどで、残りは調査、テスト、資料の修正が占めていました。

この内訳が分かると、見積もりの読み方が変わります。どこに時間を見込んでいるかを聞き、資料を渡す、改修をまとめる、優先度を付けるといった、発注する側でできることを考えられるようになります。

見積もりを受け取ったら、この記事のチェックリストを一度使ってみてください。金額の理由が見えると、開発会社との相談も、社内での説明も、ずっと進めやすくなるはずです。