業務システム開発の費用と進め方｜脱Excelを判断する

業務システム 開発 費用を知りたいときは、広い価格相場を集める前に、対象業務と運用条件を整理します。誰が何を入力し、どこで承認し、どのデータと連携し、障害時にどこまで復旧させるか。こうした条件が費用を左右します。同じ「案件管理」でも、条件が違えば見積もりは別物になります。

脱Excelの判断では、共同編集、権限、履歴、データ連携に生じている支障を確かめます。その損失が開発後の運用費まで含めた負担を上回る業務が、システム化の候補です。担当者が限られ、処理が安定し、Excelで十分に統制できている業務は残せます。

難しいのは「支障」を具体的な発注条件へ変えることです。ここを曖昧にしたまま機能一覧を作ると、見積もりを比較できず、完成後も例外処理が人に戻ります。

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

開発費用は、実装する機能と、その機能を業務で安全に使い続けるための作業から成ります。見積もりを見る際は、少なくとも次の項目を分けます。

• 企画・要件定義：対象業務、利用者、権限、完了条件を決める
• 設計：画面、データ、処理、外部サービスとの連携方法を定める
• 実装：画面やAPI、通知、帳票などを作る
• レビュー・テスト：業務ルールとの一致、権限、異常系、操作性を確かめる
• 移行：既存ファイルの整形、重複除去、初期データ投入を行う
• 導入・運用：利用者への案内、監視、バックアップ、問い合わせ、変更に備える

したがって、画面単価だけの比較では総額を判断できません。初期開発に含まれる範囲と、リリース後に別途必要になる作業を同じ表に並べることが重要です。

業務の例外が多い、承認経路が条件ごとに変わる、既存データの表記が揃っていない、複数サービスとの連携が必要、といった場合は費用が膨らみやすくなります。対象者と処理を限定し、既製の認証・通知・クラウド機能を適切に使えるなら、独自実装の範囲を抑えられます。既製サービスの利用料や仕様変更への対応は運用費として見込んでおきます。

2026年7月時点で公開されているデジタル庁のデジタル社会推進標準ガイドラインは政府情報システム向けですが、要件定義書と調達仕様書の標準テンプレートを公開しています。小規模な民間開発へそのまま適用する必要はないものの、業務要件、機能要件、非機能要件を分けて確認する考え方は、見積もりの抜けを探す際にも有効です。

脱Excelを判断する5つの観点

Excelは、柔軟で、利用者が自分で変更できる道具です。その便利さを手放してシステムへ移す意味があるか。業務上必要な統制と、変更のしやすさを判断材料にします。

1. 正しいファイルと値を特定できるか

複製されたファイルが複数あり、どれが最新版か分からない。入力形式が担当者によって異なり、集計前の修正が常態化している。この状態では、データを使うたびに確認作業が発生します。

ただし、入力規則、保管場所、命名、更新担当を決めれば解消できるなら、すぐに開発する理由にはなりません。運用ルールを整えた後にも問題が残るかを見ます。

2. 権限と履歴が業務に足りるか

閲覧者と更新者を分けたい、項目単位で扱える情報を制限したい、誰がいつ変更したか追跡したい場合は、ファイル共有だけでは運用が複雑になります。個人情報や重要情報を扱うなら、漏えい、改ざん、利用不能をそれぞれ検討します。

IPAの重要情報を扱うシステムの要求策定ガイドは、2024年7月29日の最終更新時点で、データの漏えい・改ざんの防止と、データの利用不可・システム停止の防止を分けて評価する考え方を示しています。自社で必要な強度は情報の性質に合わせて決め、要求だけを過大にしないことが費用管理にもつながります。

3. 承認や例外処理を人が覚えていないか

金額や取引条件によって承認者が変わる、差し戻し後の処理が担当者の記憶に依存するなら、単なる表の置き換えでは足りません。承認条件と状態遷移をシステムへ持たせる範囲を検討します。

頻繁に変わる業務を固いルールとして実装すると、変更のたびに改修費がかかります。標準経路をシステム化し、例外は記録を残して人が判断する設計も候補です。

4. 転記と連携がボトルネックか

同じ顧客情報を複数の表へ入力する、受注内容を別サービスへ転記する、月末にファイルを結合するといった作業は、システム化の候補です。ただし、連携先にAPIがあるか、取得できる項目は何か、利用上限や料金はどうなるかを確認しなければ見積もれません。

連携を増やすほど便利になるとは限りません。業務上の基準となるデータをどこに置くかを決めないまま同期すると、値が違ったときの正解が分からなくなります。

5. 障害時にも業務を続けられるか

システム化すると、端末やネットワーク、クラウド側の障害も業務へ影響します。許容できる停止時間、バックアップの対象、復旧時点、緊急時の代替手順を決めます。これらは画面には見えませんが、設計・テスト・運用の費用を左右します。

以上の観点のうち複数で問題が継続し、Excelの運用改善だけでは統制できないなら、脱Excelの検討を進める根拠があります。該当数だけで機械的に決めず、問題が起きた際の事業影響を併せて評価します。

見積もりの前に作る業務整理

発注前に詳細な仕様書を完成させる必要はありません。発注者が整理したいのは、現状の事実と、変えてよい範囲です。まず一つの業務を始点から終点まで追い、次を一枚にまとめます。

• 目的：何の判断や処理を成立させる業務か
• 利用者：入力、承認、閲覧、管理を誰が担うか
• 入出力：どの情報を受け取り、何を作成・通知するか
• ルール：必須項目、計算、承認、締め、例外の条件
• データ：既存ファイルの量、形式、重複、保管期間
• 連携：利用中のサービス、API、手作業で残す部分
• 運用：問い合わせ先、権限変更、監視、復旧、改善担当

この整理から「初回リリースで必須」「後で追加」「システム外に残す」を分けると、見積もりの前提が揃います。要望を削るというより、最初に検証すべき業務の境界を決める作業です。

現行業務の手順をそのまま機能一覧へ写すのも避けたいところです。その手順は、Excelの制約を補うために増えた可能性があります。「なぜこの転記や確認が必要か」を問い直し、不要な作業を除いてから新しい業務フローを作ります。

小規模開発は一つの業務から発注する

全社のExcelを一度に置き換えると、関係者、データ、例外、移行の範囲が同時に広がります。小規模に始めるなら、入力から完了までを一つの流れとして切り出せ、効果と不具合を確認できる業務を選びます。画面数を基準にせず、利用後の判断まで完結する範囲を切り出すことが重要です。

進め方は、次の順序で考えられます。

1. 現状業務と課題を観察し、対象外を決める
2. 新しい業務フロー、権限、データ、完了条件を合意する
3. 概算見積もりで前提、除外事項、変動要因を確認する
4. 画面や操作の試作で認識差を減らす
5. 実装し、通常処理と例外処理を業務担当者が受入確認する
6. データ移行、権限設定、代替手順を整えて公開する
7. 利用状況と問い合わせを基に、次の改修を判断する

小さな発注でも、要件定義とテストは行います。範囲を狭めることで、判断と検証の対象を減らせます。

AIを使う開発でも同じです。AIが実装作業を支援し、コード作成の一部を速めることはありますが、業務要件の決定、設計判断、レビュー、テストの責任までは置き換えません。「AIを使うから一律に安い」と捉えず、どの工程を誰が担当し、成果物をどう検証するかを見積もりで確認します。

見積書で確認したい費用と契約の境界

複数社へ相談する場合は、各社へ同じ業務整理を渡し、金額と前提を一緒に比較します。少なくとも、次の問いに回答があるかを確認します。

• 要件が未確定の部分は、いつ、誰が、どの方法で決めるか
• 見積もりに含む画面、権限、連携、帳票、データ移行は何か
• 対応ブラウザや端末、性能、可用性、セキュリティの前提は何か
• テストの担当範囲と、発注者が行う受入確認は何か
• 仕様変更と不具合をどう区別し、追加費用をどう決めるか
• ソースコード、設計資料、アカウント、データを誰が保有するか
• 公開後の保守、監視、問い合わせ、障害対応は別契約か
• 外部サービスの利用料と、値上げ・終了時の対応はどうなるか

これらは高機能なシステムを求める一覧ではなく、費用に含まれる責任を揃えるための確認事項です。見積もりの外に残った作業まで把握して、総額を判断します。

契約形態も名称だけでは選べません。成果物と完成条件を合意しやすい範囲か、要件を探索しながら進める範囲かによって適合が変わります。検収条件、変更手続、知的財産、秘密情報、再委託、解約時の引き継ぎを契約書と提案書で一致させます。

費用を抑えるとは、判断を先送りしないこと

業務システム開発の費用を管理するには、必要な品質を保ちながら、作らない範囲と後で判断する範囲を明示します。既製サービスで足りる業務、Excelに残す業務、独自開発する業務を分ければ、投資対象が見えます。

冒頭の「支障」を発注条件へ変えるには、最新版の特定、権限と履歴、承認と例外、転記と連携、障害時の継続という五つの観点で現状を記録します。そのうえで、一つの業務について利用者、ルール、データ、運用責任を定め、初回リリースの外側を決めます。

Excelで統制できる部分は残し、継続的な事業影響があり、運用改善で解消できない部分をシステム化する。この境界を説明できたとき、脱Excelを手段として選べるようになり、見積もりも比較可能になります。

費用、期間、契約、法務・税務上の扱いは条件により異なります。記事の確認日とリンク先の一次情報を確認し、個別判断は専門家へご相談ください。

システム開発・発注ガイドへ戻る