システム開発費用の内訳とは？詳細項目や妥当性の判断方法を解説

システム開発を実行する際、必ず行う工程の中に「見積もり」があるのではないでしょうか。多くの開発ベンダーが存在する中で、提示された見積もり内訳の妥当性判断や、読み解き方に苦戦されている方も少なからずいることでしょう。

当コラムでは、システム開発費用の構成詳細や、内訳項目の例、さらに見積書の見直しを図るポイントなどをご紹介します。「どの開発ベンダーに依頼を頼めばよいか分からない」「見積書の妥当性を少しでも判断できる方法が知りたい」などのお悩みを抱えている方は、ぜひご覧ください。

システム開発費用を構成する要素

基本は単価×作業工数

システムの開発費用は、エンジニアの人件費が主な割合を占めます。この人件費を算出する計算式が、単価×作業時間です。

「単価」とは

エンジニアの稼働単価を指します。エンジニアの職種や技能、役職といった、エンジニアが身に付けているスキルを変数として加味し算出されます。またプラスアルファとして「労務費」や「販売管理」費に加え、ベンダー側が得る「利益分」も含まれています。

「作業工数」とは

システムを実際に開発したエンジニアの「作業量」として算出される数値です。算出単位は人月（1人あたりの1カ月分の作業量）です。たとえば「3人月」の場合、解釈としては「3人で1カ月かかる作業量」もしくは「1人で3カ月分かかる作業量」となります。

各エンジニアの単価に、1人あたりが担う作業工数を掛け合わせた数値が、基本的な開発費用です。

必要に応じて管理費・実費がプラスされる

上記の人件費が基本的な内訳となりますが、開発環境に応じて、以下プラスアルファの費用が発生します。

管理費

主に、開発用で発生する設備代や、その他開発に付随して発生した費用を指します。例えば、サーバーや開発用のパソコンといった買い切り型の費用から、ソフトウェア・OSのライセンス料、システム開発の現場となるオフィスの賃貸料など長期的に発生する費用も該当します。

実費

設備代のみならず、交通費・宿泊費なども開発費用として含まれます。発生するシチュエーションとしては、開発のために遠方からエンジニアを招集した場合などです。

遅延などのリスクも考慮

開発が当初のスケジュール通りに進行すればよいですが、何らかのトラブルなどで開発スケジュールが延長した場合、その分の追加費用も発生します。予算組のために開発費用を算出するのであれば、この点も踏まえて予備費として組んでおく方が賢明といえます。

システム開発費用の見積もり内訳項目例

システム開発費用を構成する要素がどのようなものかご紹介しました。続いて、先述の要素によって算出された数値が、具体的にどのような項目として見積書に落とし込まれるかについてご紹介します。

開発作業に対する費用

要件定義

「システムがどのような機能を満たしているべきか」を定義づけるために必要な費用です。クライアントからのヒアリングや、機能の精査が該当します。

設計

サーバーやアプリなど、開発に必要な土台を形作るために必要な費用です。「基本設計」「データベース設計」「UI設計」など、開発に必要な工程ごとに記載されている場合があります。

開発・実装

設計書をもとに、システム上へプログラミングを施すために必要な費用です。「各種機能・設定」など、機能ごとの名称で記載されている場合があります。

テスト

システムを形作ったあと、正常に動作するかを確認するために必要な費用です。テストの仕様書や、実際にテストを行う工数も当項目に該当します。

スケジュール管理

上記一連の流れを調整するために必要な費用です。「管理費用」などの名称で記載されている場合があります。

導入サポート

初期設定やマニュアル作成など、クライアントが導入から実際に使用するまでをサポートする費用です。「トレーニング費用」「初期設定費用」などの名称で記載されている場合があります。

運用保守

導入後、システムをトラブルなく活用できるようメンテナンスしたり、万が一のトラブル発生時に対応するための費用です。

機材・設備に対する費用

先項の「管理費」に該当する費用です。「管理費」として記載されているケースもあれば、「設備購入費用」などの名称で記載されている場合もあります。

その他開発に必要な費用

先項の「実費」に該当する費用です。「出張・会議費用」などが該当します。

費用内訳の妥当性評価

エンジニアの単価をチェックする

費用内訳の割合の内、主に占める要素はエンジニアの人件費です。まずはエンジニア単価に着目します。単価を左右する要素としては、先述の通り、エンジニアのスキルや役職などが大きく起因します。

単価の高さは技術力の高さを表す指標ともなるため、参考値としてとらえることは必要ですが、あくまで開発ベンダー側が定めた指標であることも念頭に置いた方が賢明です。単価の高さは成功担保の意味合いだけでなく、トラブル時のリスクヘッジ分が工数として見積もられているケースも存在し得るためです。もちろん一概には言えませんが、着実に見積もりを取りたいのであれば、単価設定の背景は入念にヒアリングし、認識をすり合わせた方がよいでしょう。

作業工数に過不足がないかをチェックする

人件費内訳の内、作業工数にも着目します。作業の具体的な範囲は明示されているか、本来自社には不要であった工程が含まれていないか、反対に本来必要であった工程が含まれているかをチェックしましょう。

なお開発工程では、要件定義や設計など開発における実作業のみを連想しがちですが、開発のための要件定義に必要な調査や分析、さらに開発後からリリース前の品質評価などを含む必要があるケースも存在します。自社の状況に応じて、まずはどの工程が含まれているかを洗い出す方がよいでしょう。

なお、工数および費用の妥当性を評価する手法として「FP（ファンクションポイント）法」というものがあります。詳細については次項にて解説します。

開発前提に齟齬はないかをチェックする

算出された費用数値の根拠として、システム開発における、前提条件もチェックしておきたいところです。例としては、そのシステムの開発言語や、使用するハードウェア・ソフトウェアなどの機材が挙げられます。

システム開発費用を見積もるFP法について

先述のFP（ファンクションポイント）法について、概要をご紹介します。

FP法とは

システムを構成する、各機能の難易度を点数付けし、開発工数およびシステム開発費用における大方の見積もりを導く計算手法です。メリットとして、システムに必要な機能を定義できた時点で見積もりを可能とする利便性、定量的な要素をもとに算出するため誰が計算しても同様の数値となる明瞭さが挙げられます。

FP法の計算方法

次に、FP方法の計算手順の概要をご紹介します。

1：機能の分類

扱う機能を、下記5つのいずれかに分類します。

・外部入力（EI）

・外部出力（EO）

・外部照会（EQ）

・内部論理ファイル（ILF）

・外部インタフェースファイル（EIF）

2：難易度を設定

分類した機能を、3段階の難易度（高・中・小）で分類。各難易度には点数を設定し、難易度で分類された各機能の点数に係数をかけ合算。出た値を基準値として算出します。

3：複雑さの算出

システム特性を司る項目（14種）を、6段階（0～5）で評価、調整値を算出します。

4：FP（ファンクションポイント）を算出

上記の基準値と調整池をもとに、計算式（基準値×（0.65 + 調整値 × 0.01））に当てはめてFPを算出します。

システム開発費用の見直しを図るポイント

具体的な算出方法についてご理解いただいたところで、ここからは、システム開発費用が想定以上にかかってしまっていた場合における、見直しを図るポイントについてご紹介します。

システムに求める要素の明文化

一つ目の手法としては、システムを必要とする理由を洗い出し、あらかじめ欲しい機能を具現化することが挙げられます。先述の「要件定義」に該当しますが、当項目を決めておくことで、ある程度費用のスリム化を図れます。たとえば、下記のような要素を定めておくだけでも、開発ベンダーとの打ち合わせがスムーズに進行します。

・システム開発の目的

・目的を果たすために必要な機能

・他システムとの連携有無

ただし、今の課題に対して、システム開発だけでは実現が難しいケースや、どのような機能を満たしていればよいか判断がつかない場合もあるでしょう。その場合は、上記を想定で明文化し、開発ベンダーと詳細をすり合わせる方が堅実です。その際、すり合わせ後に提示された機能が改めて本当に必要か、また機能を搭載した理由が不明瞭でないかのチェックも忘れずに行いましょう。

パッケージ・ASPの活用も検討する

パッケージとはすでに一定の形ができあがっている購入型の既成システム、ASPとはレンタルで活用する既成システムを指します。ゼロから開発すると、その分工数がかかるため費用もかさみますが、既成システムを活用することで、費用を幾分か削減することはできます。ただし、カスタマイズ性やオリジナリティは、ゼロからの開発と比べて相対的に落ちてしまう点に留意しましょう。

複数社から相見積もりを取る

開発ベンダーと一口にいっても、開発時の提案内容やアフターフォロー、また開発にかかる期間・金額設定も異なります。過去の実績を参照し、目途をつけた複数社から相見積もりを取りながら比較検討する方が堅実です。

システム開発費用の回収目途を立てる

見積もりが出た後、どの程度の期間までシステムを活用すれば元が取れるか、シミュレーションも行っておきましょう。いくらオリジナリティが高いシステムを開発したとしても、短期間で利用が止まってしまっては意味がありません。

なお、途中で利用が止まってしまいやすい要素としては、主に機能の「利便性」や「活用シチュエーションの不一致」が挙げられます。例として、他システムとの連動性が悪い、操作が難しい、本当に必要だった機能が不足しているなどのケースが想定されます。原因として、現場の利用者との認識相違が発生している可能性もあるため、実際に活用する担当者からもヒアリングを行っておいた方がよいといえます。

まとめ

システム開発費用について、内訳を構成する要素と具体的な項目例、妥当性の判断方法についてご紹介しました。まとめると、開発を検討する際には、以下の点に留意をしておきたいところです。

• 開発ベンダー選定時…現場状況から本当に必要なシステム機能を見極め、複数社と相見積もり・相談を行う
• 見積書のチェックポイント…「単価」「工数」「開発前提」などに着目。作業工数の妥当性については、FP法などの計測手法を活用
• 見直しを図るポイント…「システム機能」「開発費用の回収分」に着目。ケースに応じて、パッケージ製品やASPの活用も検討

さて、これから実際にシステム開発費用の見積もりを検討されている方もいらっしゃるのではないでしょうか。慣れていると見積もりのコツを掴めてきますが、はじめて見積もりを行う方であれば、以下の課題に突き当たりやすくなります。

• 見積金額の平均相場や他社の事例など、定める基準が分からず、判断が難しい
• 見積以前に、現状にどのようなシステムが必要なのか、正しく把握できている自信がない
• 開発ベンダーから受けた提案の妥当性について、適切な見極めが難しい

上記の課題に直面した際、解決策の一つに「外部人材」の活用が挙げられます。豊富な経験を身に付けている第三者の目線を取り入れることで、ひいき目のない現状把握や、適切な打ち手の検討、知見の蓄積が期待できます。

フリーランスITエンジニア専門エージェント「HiPro Tech」では、ITコンサルティングの経験者から、実際に現場で開発を経験しているエンジニアまで、幅広いスキルを兼ねそろえたフリーランスエンジニアが活躍しています。開発ベンダーとの交渉から、見積書の読み解き方まで、現場に即したアドバイスによって、課題をスムーズに解決まで導くことでしょう。少しでも興味をお持ちいただけましたら、まずはお気軽にお問合せください。