System integration システム開発の費用の決まり方

System cost システム開発の費用は何で決まるか

システム開発の費用は、「開発に必要な作業量(画面と機能の数、他システムとの連携、データの移行)」と「作業にあたる人の体制と期間」で主に決まり、一般に、その多くは人件費にあたります。サーバーやクラウドの利用料、ライセンス費用が加わることもありますが、見積もりの大きさを左右するのは「何を、どこまで作るか」です。同じ「業務システム」でも、画面や機能の数、連携先、求める性能やセキュリティの水準で費用は大きく変わるため、FAC では料金表を公開せず、ビジネス課題と業務フローを伺ったうえで個別にお見積りしています。このページは金額の相場表ではなく、見積もりがどう組み立てられ、何を決めると費用が動くのかを、発注する側の視点で整理したものです。見積もりの内訳、費用が変わる 7 つの要因と抑える考え方、見積もりを依頼するまでの 4 ステップの順で説明します。

Estimate breakdown 見積もりの内訳

システム開発の見積もりは、一般に、次の 6 つの項目に分けて整理できます。
要件定義・設計、開発、テスト、リリース・移行は主に必要な作業量(工数)をもとに見積もられ、インフラ・ライセンスは利用規模や契約内容で決まります。「何に対する費用か」と「何で増減するか」を知っておくと、範囲の調整や見積もりの比較がしやすくなります。

項目何に対する費用か費用が増減する主な要因
1. 要件定義・設計ビジネス課題と業務フローの整理、機能要件、技術仕様、開発スケジュールの策定、画面とデータの設計業務の複雑さ、関係部署の数、現状の資料がどこまで整っているか
2. 開発(実装)画面の実装、機能(業務ロジック)の実装、データベースの構築、外部システムや API との連携画面と機能の数、処理の複雑さ、連携先の数と仕様、対応する端末(PC・スマートフォン・タブレット)
3. テスト単体テスト、結合テスト、総合テスト、不具合の修正機能の数と組み合わせ、求める品質の水準(業務が止まったときの影響の大きさ)
4. インフラ・ライセンスサーバーやクラウドの構築と利用料、ドメインや証明書、外部サービスや有償ライブラリの利用料利用者数とデータ量、求める性能と可用性(止まってよい時間)、セキュリティの要件
5. リリース・移行本番環境へのリリース、既存システムからのデータ移行、並行運用、利用者への説明や操作手順の整備移行するデータの量と状態(整っているか)、並行運用の期間、利用者の数
6. リリース後の運用サポート・保守動作確認と不具合対応、機能追加や改修、監視、バックアップ、アップデート保守の対象と範囲(監視対象、対応時間、改修の扱い)

FAC の企画開発は、要件定義・設計 → プロトタイプ開発・検証 → 本格開発・テスト → リリース・運用サポートの順で、小さな単位で開発と検証を繰り返すアジャイル手法で進めます。見積もりの項目名や区切り方は会社ごとに異なるため、比較するときは、項目名ではなく「何が含まれているか」を確認することをおすすめします。リリース後に保守・運用としてお任せいただく範囲は、対象システムとご契約の範囲に応じて決めます(保守の範囲の決め方)。

7 factors 費用が変わる 7 つの要因と、抑える考え方

システム開発では、画面や機能の数といった「量」に加えて、要件の決まり具合と変更の多さも費用を動かします。
次の 7 つを知っておくと、「何を削るか」ではなく「何を先に決めれば無駄な費用が出ないか」で考えられます。

要因費用が上がる方向抑える考え方
1. 機能の数と複雑さ機能が多い。例外的な業務パターンまで作り込む。承認や権限の階層が多い機能を「必須」と「あれば良い」に分け、最初のリリースは必須に絞る。まれな例外は手作業で運用する選択肢も検討する
2. 画面と対応端末画面の種類が多い。PC・スマートフォン・タブレットのすべてに専用の画面を作る似た画面は共通の型にまとめる。主に使う端末を決め、ほかは閲覧中心にする
3. 他システムとの連携連携先が多い。連携先の仕様が不明、または変更が多い連携先の仕様書や API の情報を先に集める。最初は手動の取り込みで始め、連携を後から足す(後から足しやすい設計になっているかを確認する)
4. データ移行既存データの量が多く、形式がばらばらで整っていない移行する対象期間と項目を絞る。移行前にデータの整理(重複や欠けの確認)を社内で進める
5. 性能・セキュリティ・可用性の要件利用者数やデータ量が大きい。止まってよい時間が短い。社外公開や個人情報の取り扱いがある「止まったとき・情報が漏れたときに何が起きるか」から必要な水準を決める。個人情報や社外公開に関わる要件は下げず、業務の実態に合わない過剰な要件だけを避ける
6. 仕様変更と確認の進め方決裁者が多い。要件が後から追加される。確認が遅れて手戻りが増える決定者を 1 人決め、確認の期限を決める。小さな単位で動くものを確認しながら進め、大きな手戻りを避ける
7. 期間と体制短い納期に合わせて体制を増やす。並行作業が増えるリリースしたい時期から逆算し、段階的にリリースする計画を立てる

費用を下げること自体が目的になると、テストや保守のしやすさが削られ、リリース後の不具合対応や改修で費用がかさむことがあります。業務に効く部分には費用をかけ、効かない部分を小さくする、という順で考えることをおすすめします。

4 steps 見積もり依頼までの準備・
4 ステップ

見積もりの精度は、依頼する側が「決まっていること」と「決められていないこと」を分けて伝えられるかで変わります。要件がまだ固まっていなくても、次の 4 つを整理しておくと、見積もりの前提がそろい、あとから「想定と違う」となる場面を減らせます。

01

解決したい業務課題と優先順位を決める

的(まと)と旗、優先順位を付けた一覧のイラスト

01

解決したい業務課題と優先順位を決める

「手作業の集計に時間がかかる」「複数の台帳で情報が食い違う」「新しいサービスの仕組みを試したい」など、システムで解決したい課題を書き出し、優先順位を付けます。優先順位が決まると、最初のリリースで作る範囲と、後に回す範囲が決まります。発注側で用意しておくとよいのは、現状の困りごとと、解決したあとの状態です。

02

業務フローと利用者を整理し、必要な機能を書き出す

画面と機能の一覧、連携先のサーバー、必須・あれば良いのチェック一覧のイラスト

02

業務フローと利用者を整理し、必要な機能を書き出す

「誰が」「どの場面で」「何をするか」を業務の流れに沿って書き出し、必要な画面と機能を一覧にします。それぞれを「最初のリリースで必須」と「あれば良い」に分け、連携したい他システム(会計、顧客管理、外部サービスなど)も挙げておきます。この一覧が、見積もりの「作業量」の前提になります。

03

既存の資料・データ・連携先の情報を用意する

手元にある資料やデータと、用意できないものを 2 列に分けるイラスト

03

既存の資料・データ・連携先の情報を用意する

現行システムの仕様書や画面の一覧、いま使っている帳票や台帳のサンプル、移行したいデータの量と形式、連携先の仕様書や API の情報を、社内で用意できるものと、用意できないものに分けます。資料がない場合は「ない」と伝えていただければ、ヒアリングで整理します。資料の有無で、要件定義と移行の見積もりが変わります。

04

時期・体制・リリース後の運用を決めて相談する

カレンダーと 2 人の担当者、相談の吹き出しのイラスト

04

時期・体制・リリース後の運用を決めて相談する

使い始めたい時期(繁忙期や締め日を避けるか)、社内の決定者と確認の進め方、リリース後に誰が運用し、保守をどこまで依頼するかを決めて、相談に持ち込みます。ステップ 1〜3 が整理されていれば、相談の場で範囲の認識をそろえやすくなります。決められていない項目は「未定」のままで構いません。

4 Steps

Our approach フロンティアエージェンシーの考え方

FAC が企画開発で大切にしているのは、次の 3 つです。

01

徹底したヒアリングによるブレない設計

エンジニアと担当者が同じ画面を見ながら優先順位を並べるイラスト

01

徹底したヒアリングによるブレない設計

「誰が」「どのように」使うのか、システムの利用者や業務フローをヒアリングし、開発後の運用まで見据えて設計します。目的を明確にし、後戻りを減らすことを目指して要件と業務フローを整理し、必要性と優先度を確認した機能をシステム設計へ反映します。

02

スクラッチ開発による高い自由度

サーバー構成の図を、要件に合わせて描き直すイラスト

02

スクラッチ開発による高い自由度

既製パッケージに頼らず、貴社独自の要件に応じたフルスクラッチ開発を基本としています。ビジネスモデルや業務フローに合わせたシステムを構築できるため、独自要件を反映したソリューションをご提案できます。

03

アジャイル開発による柔軟な対応力

小さな画面が段階的に増え、循環の矢印で検証を繰り返すイラスト

03

アジャイル開発による柔軟な対応力

小さな単位で開発と検証を繰り返すアジャイル手法を採用し、早期に動くプロトタイプをご確認いただきながら、仕様変更や優先順位の調整に対応します。実際の画面や動作を確認いただきながら、認識のズレを減らし、優先度を調整して進めます。

Approach

FAQ よくある質問

料金表はありますか?

画面や機能の数、連携先、求める性能やセキュリティの水準によって作業量が大きく異なるため、サイト上では料金表を公開していません。ビジネス課題と業務フローを伺ったうえで個別にお見積りします。

要件定義から依頼できますか?

はい。ビジネス課題や業務フローをヒアリングし、システムの目的と要件を明確にするところから始めます。機能要件、技術仕様、開発スケジュールを定め、プロジェクトの基盤を固めます。

途中で仕様を変えると、費用はどうなりますか?

一般に、変更の内容によって作業量と期間が変われば、費用も変わります。FAC では、小さな単位で開発と検証を繰り返すアジャイル手法を採用しているため、仕様変更や優先順位の調整に対応しながら進めます。早期に動くプロトタイプをご確認いただきながら、仕様をブラッシュアップします。

業務課題の整理からでも、機能の一覧がある段階からでも、状況に合わせてご相談ください。発注が決まっていなくてもご相談いただけます。お問い合わせフォームの「お問い合わせ内容」に「相談希望」とご記入ください。

まず相談する

関連:企画開発/業務アプリ・レガシーシステムのリプレイス/システム保守の範囲と決め方/保守・運用