はじめに
システム開発の見積書を見ると、総額が数億円になっていることがあります。
「プログラムを修正するだけなのに、なぜこれほど高いのか」
システム開発に関わった経験が少ないと、こう感じるかもしれません。
システム更改で必要になるのは、プログラムの設計や製造だけではありません。現行システムの調査、クラウド基盤の構築、データ移行、テスト、切替、プロジェクト管理など、多くの作業が発生します。
本記事では、架空のA銀行が実施するクラウド更改プロジェクトを例に、数億円の見積もりの内訳と、金額の妥当性を確認するための見方を解説します。
A銀行のクラウド更改で行う仕事の全体像は、次の記事で解説しています。
見積金額には何が含まれているのか
システム更改の費用を理解するには、最初に「何を含む金額なのか」を確認する必要があります。
システムに関係する費用は、大きく次の3つに分けられます。
本記事では、ベンダーへ発注する①更改プロジェクトの初期費用と、稼働後に継続して発生する②本番稼働後の継続費用の両方を扱います。
発注元の社員がプロジェクトへ参加する人件費や、利用部門への説明、マニュアル整備、教育などの③発注元の内部費用は対象外とします。
見積金額だけを見るのではなく、対象範囲を確認することが重要です。
開発期間中にもクラウド利用料が発生する
今回のプロジェクト期間は1年間とします。
この1年間に利用する開発環境、テスト環境、新しい本番環境のAWS利用料は、更改プロジェクト費用に含めます。
新しい本番環境は、サービス開始日に初めて作るわけではありません。事前に構築し、総合テスト、性能テスト、障害テスト、運用テスト、移行リハーサルなどで使用します。
稼働後の運用期間を5年間とすると、新本番環境を利用する期間は実質的に約6年間になる場合があります。
更改期間の1年間：更改プロジェクト費用
稼働後の5年間：継続的な運用費用
AWS利用料は、プロジェクト開始時から本番規模の金額が一律に発生するとは限りません。環境の構築時期、サーバー台数、稼働時間、テスト工程に応じて段階的に増えていきます。
開発環境やテスト環境も、稼働後にすべて廃止するとは限りません。規模を縮小し、保守開発用の環境として残す場合は、稼働後のAWS利用料へ引き継がれます。
見積書では、どの環境を、いつからいつまで、誰の契約で利用するのかを確認する必要があります。
システム開発費用を構成する3つの要素
システム更改では、プログラムだけでなく、設計書、テスト仕様書、移行計画書、運用手順書など、多くの成果物を作成します。
システム開発費用は、こうした成果物を作成する人件費に加え、環境利用料や製品費など、主に次の3つの要素で構成されます。
人が作業するための費用
プロジェクト期間中の環境利用料
製品、回線、外部サービスの費用
ベンダーは、これらの費用を算定する際に、契約範囲内で発生し得る不確定要素も見積もりへ織り込みます。
1．人が作業するための費用
システム開発では、作業量を人月で表します。
1人月は、1人が1か月働く作業量です。
見積金額は、作業量に人月単価を掛けて計算します。
作業費用 ＝ 人月数 × 人月単価
人月単価は、担当者の給与そのものではありません。
企業が技術者を雇用し、継続的にサービスを提供するには、給与以外にも次のような費用が必要です。
社会保険料や福利厚生費
採用費や教育費
オフィスや業務設備の費用
管理部門や営業部門の費用
プロジェクト管理費
会社として確保する利益
月130万円の人月単価であっても、担当者本人が月130万円を受け取っているわけではありません。
2．プロジェクト期間中の環境利用料
クラウド更改では、開発環境、テスト環境、新本番環境などのAWS利用料が発生します。
サーバーだけでなく、ストレージ、データベース、バックアップ、監視、ネットワーク通信なども費用の対象です。
利用する環境数やサーバー台数が増えれば、利用料も増加します。
3．製品、回線、外部サービスの費用
システムでは、AWS以外にも各種製品やサービスを利用します。
データベース製品
監視製品
ジョブ管理製品
セキュリティ製品
専用回線
外部サービス接続
証明書
技術サポート
製品によっては、旧環境と新環境を並行稼働させる期間に、両方のライセンスが必要になることがあります。
Oracle Databaseなどのライセンスは、製品のエディション、構成、契約内容、利用方法によって扱いが異なります。移行期間中に追加契約が必要かどうかは、契約条件を個別に確認します。
見積もりに織り込まれるリスク分
プロジェクト開始前に、すべての問題を正確に把握することは困難です。
現行システムの資料が不足している、クラウド化に伴って古いプログラムがそのままでは動かない箇所が想定より多い、データ品質に問題があるといった事象が発生する可能性があります。
ベンダーは、契約範囲内で発生し得る不確定要素を見込み、各作業の工数やプロジェクト管理費などへリスク分を織り込むことがあります。
見積もり漏れ、生産性不足、契約範囲内で発生した追加対応などを、ベンダー側で処理するための内部的な費用です。
要件追加や仕様変更によって契約外の作業が必要になった場合は、リスク分で吸収する話ではありません。作業内容と影響を整理し、追加見積もりや変更契約として扱います。
3つの要素を費用項目へ細分化する
先ほど整理した3つの要素を、A銀行のクラウド更改プロジェクトで発生する費用項目へ細分化すると、次のような見積もりになります。
3億円のうち、2億5,500万円は、人が現行調査、設計、構築、改修、移行、テスト、引継ぎを行うための費用です。全体の85％を占めています。
残る費用は、プロジェクト期間中のAWS利用料と、製品、回線、外部サービスの費用です。各項目の見積金額には、契約範囲内で発生し得る不確定要素も織り込まれています。
この見積もりでは、アプリケーション対応費は5,000万円です。
全体の約17％に当たります。
残りの約83％は、基盤、テスト、移行、管理、環境利用料、製品費、運用引継ぎなどです。
システム開発費用の大部分が、プログラム製造以外の作業に使われていることが分かります。
アプリケーション担当者は何人いるのか
アプリケーション対応費5,000万円を、人月単価130万円で計算します。
5,000万円 ÷ 130万円 ＝ 約38人月
プロジェクト期間を12か月とすると、1か月当たりの平均要員数は次のようになります。
38人月 ÷ 12か月 ＝ 約3.2人
平均すると、アプリケーション担当者は3人程度です。
ここでいう平均3.2人は、プロジェクト期間中に常に3人程度が作業するという意味ではありません。現行調査や設計の時期は少人数で進め、プログラム改修や単体テストの時期に要員を増やし、作業の完了に合わせて減らしていきます。
例として、38人月を次のように配置します。
この表を月別のグラフにすると、要員数が多い時期と少ない時期を把握できます。このような資料を、要員山積み表や要員山積み計画と呼びます。
要員山積み計画は、プロジェクト内部の進捗管理だけに使う資料ではありません。
すべての技術者をベンダーが自社内で確保できるとは限りません。協力会社へ作業を委託する場合は、この計画を基に必要な人数、スキル、参画時期、離任時期を調整します。
設計工程には、業務と現行システムを理解した技術者が必要です。改修工程では、対象言語やフレームワークの経験者を確保します。テスト工程では、検証や障害分析を担当できる技術者が求められます。
単に「3人を確保する」のではなく、どの工程に、どのスキルを持つ要員を、何人配置するのかを計画します。
3億円のプロジェクトと聞くと、数十人のプログラマーが1年間開発している姿を想像するかもしれません。実際には、アプリケーション改修を担当する人数は限られ、基盤、移行、テスト、運用、管理などの担当者が工程ごとに参加します。
アプリケーション対応費には、プログラム製造だけでなく、影響調査、設計、非互換箇所の修正、単体テストなども含まれます。純粋なコーディングに使われる工数は、38人月より少なくなります。
基盤、移行、テスト、運用、管理など、プログラミング以外の仕事を含む全体像は、冒頭で紹介した記事で詳しく解説しています。
稼働後も継続的な費用がかかる
更改プロジェクトが完了しても、システムに関する支払いが終わるわけではありません。
稼働後は、本番環境を動かすためのクラウド利用料に加え、監視、障害対応、問い合わせ対応、製品保守、パッチ適用、機能改善などの費用が継続的に発生します。
主な費用と作業内容は、次のとおりです。
運用保守費は、障害が発生したときだけ支払う費用ではありません。
24時間365日の対応を求める場合は、監視担当者が異常を検知し、一次切り分けを行ったうえで、必要に応じてアプリケーションや基盤を担当する技術者へ連絡します。実際の体制は、複数名による当番制や、監視部門から開発ベンダーへのエスカレーションで構成されます。
障害が発生していない時間も、連絡を受けられる体制を維持しなければなりません。開発ベンダーの保守要員1名分を毎月確保する契約であれば、人月単価130万円として年間1,560万円になります。
月次報告が契約に含まれる場合は、監視結果、障害件数、問い合わせ状況、作業実績、未解決課題、翌月予定などを集計し、報告書を作成します。障害が発生しなかった月にも、監視、定期確認、報告、会議などの作業が発生します。
パッチ対応も、メーカーから提供された修正プログラムを、そのまま本番環境へ適用する作業ではありません。
脆弱性や障害の内容を確認し、適用の必要性と緊急度を判断します。検証環境へ事前に適用し、アプリケーションや運用機能への影響を確認した後、本番作業の手順、停止時間、切り戻し方法を整理します。
メジャーバージョンアップでは、非互換機能の調査、アプリケーション改修、総合テストが必要になることもあります。通常の運用保守契約へ含めず、別プロジェクトとして見積もる場合もあります。
5年間の継続費用を考える
稼働後の費用は、システムの規模、構成、対応時間、保守範囲によって大きく変わります。
年間費用に一律の相場はありません。ここでは規模感をつかむための説明用モデルとして、今回の更改プロジェクト費用3億円に対し、年間10％の継続費用が発生すると仮定します。
年間の継続費用は3,000万円です。5年間では1億5,000万円となり、初期の更改プロジェクト費用3億円と合わせると、更改開始から稼働後5年間までにかかる総費用は4億5,000万円になります。
更改費用だけを見れば3億円ですが、5年間の運用まで含めると、さらにその半分に当たる1億5,000万円が必要です。システムの予算は、構築時の金額だけではなく、稼働後に発生する費用も含めて考えなければなりません。
年間3,000万円のうち、開発ベンダーの保守要員1名分を毎月確保すると、年間1,560万円です。試算では、残る1,440万円、月平均120万円の中で、AWS利用料、監視、製品保守、回線、外部サービス、パッチ対応などを賄うことになります。
この仮定では、保守要員だけで年間費用の半分を占めます。クラウド利用料や製品保守まで含めると、年間10％では不足する規模のシステムも十分にあり得ます。
この金額は、一般的な相場を示すものではありません。24時間365日の対応が不要なシステムや、問い合わせ件数が少ないシステムでは費用を抑えられます。高い可用性や短い復旧時間が求められ、外部接続や対象製品が多いシステムでは、年間10％を超えることもあります。
オンプレミスのメーカー製品では、アップグレード権などを含む保守契約が製品価格の一定割合で設定されることがあります。クラウド更改では、そこへAWS利用料、運用監視、開発ベンダーの保守体制などが加わります。外貨建てで契約する製品やサービスでは、為替変動も考慮する必要があります。
システム更改の費用を考える際は、初期の3億円だけで判断するのではなく、稼働後5年間に発生する費用を含めて捉える必要があります。契約者と費用負担者、対応時間、保守範囲、パッチやバージョンアップの扱いを、見積書や契約書で確認します。
見積書で確認すべき3つの根拠
見積金額が妥当かどうかを確認するには、総額だけを見ても判断できません。
更改プロジェクト費用だけでなく、稼働後のクラウド利用料や運用保守費についても、作業範囲、数量、算定根拠を確認する必要があります。
見積書では、次の3点を確認します。
1．何を実施するのか
最初に、見積金額に含まれる作業範囲を確認します。
「テスト一式」「基盤構築一式」「運用保守一式」とだけ記載されている場合、どこまで対応するのか分かりません。
テストであれば、対象工程、対象機能、実施回数、障害対応、再テストなどの範囲を確認します。
運用保守であれば、監視、障害対応、問い合わせ対応、定期作業、月次報告、パッチ対応のどこまで含むのかを確認します。
24時間365日の連絡体制を維持するのか、平日日中だけ対応するのかでも費用は変わります。パッチ対応についても、情報収集と適用要否の判断だけを行うのか、事前検証、本番適用、回帰テストまで含むのかを確認します。
契約書や見積書に書かれていない作業は、稼働後に追加費用となる可能性があります。
2．数量はいくつなのか
次に、費用の前提となる数量を確認します。
主な数量には、次のようなものがあります。
人月数・保守要員数
サーバー台数
環境数
テストケース数
移行対象データ量
外部接続数
ライセンス数
対応時間
パッチ対象製品数
リリース・定期作業回数
「テスト環境3面」「サーバー20台」「外部接続10本」「保守要員1名分」「月次報告12回」のように数量が示されていれば、見積金額との関係を確認できます。
数量が書かれていない見積もりでは、金額が高いのか安いのかを判断できません。
3．なぜその数量になるのか
最後に、数量の算定根拠を確認します。
サーバー20台であれば、各サーバーの役割、冗長化構成、性能要件などが根拠になります。
外部接続10本であれば、接続先、通信方式、認証方式、試験方法などを確認します。
保守要員1名分であれば、問い合わせ対応、障害調査、定期作業、月次報告、待機時間など、どの作業を積み上げた結果なのかを確認します。
AWS利用料であれば、インスタンスの種類、稼働時間、ストレージ容量、バックアップ、データ転送、冗長化などの条件が根拠になります。
パッチ対応であれば、対象製品数、適用頻度、影響調査の範囲、検証環境の有無、本番停止時間、回帰テストの範囲などを確認します。
前提条件が変わったときに、どの数量が変わり、初期費用や年間費用へどの程度影響するのかまで説明できる見積もりが、実際のプロジェクトで使える見積もりです。
まとめ
システム開発費用は、プログラマーの人件費だけで構成されているわけではありません。
現行調査、プロジェクト管理、クラウド基盤、ネットワーク、製品、データ移行、テスト、切替、運用引継ぎなど、多くの作業と費用が含まれています。
今回の3億円の見積もりは、次の3つの要素で構成されています。
人が作業するための費用：2億5,500万円
プロジェクト期間中の環境利用料：2,000万円
製品、回線、外部サービスの費用：2,500万円
各費用には、契約範囲内で発生し得る不確定要素も織り込まれています。
アプリケーション対応費は5,000万円で、全体の約17％です。人月単価を130万円とすると約38人月となり、1年間の平均要員数は約3.2人です。
平均3.2人は、1年間を通じて同じ人数が配置されるという意味ではありません。工程ごとの要員数を要員山積み計画で可視化し、社内や協力会社と必要な人数、スキル、参画時期、離任時期を調整します。
更改プロジェクトが完了した後も、クラウド利用料、運用保守費、製品保守費、回線費、外部サービス費、パッチ対応費、保守開発費が継続的に発生します。
今回の例で、稼働後の費用を更改プロジェクト費用の年10％と仮定すると、年間3,000万円、5年間で1億5,000万円です。更改から稼働後5年間までの総費用は4億5,000万円になります。
この金額は一般的な相場ではありません。保守要員1名分を毎月確保するだけでも、人月単価130万円なら年間1,560万円です。クラウド利用料、監視、製品保守、回線、外部サービスまで含めると、年間10％では不足するシステムもあります。
初期の更改費用だけを見て予算を判断すると、稼働後に必要な費用を見落とします。システムにかかる費用は、構築から運用終了までの総費用で捉える必要があります。
見積もりの説明責任とは、総額を提示することではありません。
何を実施するのか、数量はいくつなのか、なぜその数量になるのかを、金額と結び付けて説明することです。
システム開発費用を理解するには、「高いか安いか」だけでなく、その金額がどの作業、数量、契約条件から構成されているのかを見る必要があります。
システム開発入門シリーズ
コメント