社内システム開発の費用は、業務1つ分の小さな仕組みで数十万円から、部門をまたぐ規模では数百万円以上まで幅があります。ただし金額を左右するのは機能の数だけではありません。この記事では、規模別の費用相場と、見積もりが会社ごとに割れる理由、そして依頼する前に決めておきたい3つのことを解説します。相見積もりを取ったものの判断がつかない、という段階の方に向けた内容です。
社内システム開発の費用相場
社内システム開発の費用は、対象とする業務の範囲と、関わる人の数でおおよそ決まります。機能の数よりも、業務がまたぐ部門の数の方が金額に影響します。
規模ごとの目安を整理すると、次のようになります。
- 業務1つを置き換える小規模な仕組み：数十万円から100万円台
- 複数の担当者が使い、既存の道具と情報をやり取りする規模：200万円から500万円程度
- 部門をまたぎ、会計や基幹の情報と連携する規模：500万円以上
これらはあくまで目安であり、同じ要望でも提示される金額は会社ごとに大きく異なります。次の節で、その理由を説明します。
見積もりが割れる理由
見積もりの差は、技術力の差というより、決まっていない部分をどう扱うかの差です。要望が曖昧なほど、開発側は不確実性を吸収するための幅を金額に乗せます。
たとえば「経費申請を楽にしたい」という依頼だけでは、次のような点が未確定のまま残ります。
- 申請するのは何人で、承認は何段階か
- 例外的な申請をどう扱うか
- 既存の会計処理とどこで繋ぐか
- 過去のデータを移すのか、新しく始めるのか
これらが決まっていないと、開発側は最も手間がかかる想定で見積もるか、あるいは安く見せて後から変更費用を積むかのどちらかになります。どちらも発注側にとって望ましい状態ではありません。
社内システム開発の前に決める3つのこと
費用を適正にする最も確実な方法は、依頼する前に自社側で決めておくことです。決まっている部分が多いほど、見積もりの幅は小さくなります。
1. 誰が使うか
使う人が決まると、必要な機能の多くが自動的に絞られます。逆に「全社で使えるように」という前提を置くと、範囲が広がり金額も膨らみます。
筆者は大手不動産会社の入居者管理システムの運用に携わっていた頃、設計の基準を「自分以外が使ったときに説明なく使えるか」に置いていました。この基準があると、機能を足すかどうかの判断が早くなります。使う人が曖昧なままだと、判断の軸がないため要望がそのまま積み上がります。
2. やめる業務はどれか
新しい仕組みを入れるとき、同時に何をやめるかを決めておきます。ここを決めないと、既存の作業が残ったまま新しい入力が追加され、手間が増えます。
やめる業務が決まっていれば、開発の対象範囲も自然と定まります。「この帳票をやめる」「この転記をなくす」という形で具体化すると、効果も測りやすくなります。
3. データをどこに残すか
業務の記録がどこに蓄積され、後から何に使われるかを決めておきます。ここが曖昧だと、動くけれど後から集計できない仕組みができあがります。
判断の材料として、業務の見える化で扱う指標の考え方が参考になります。何を測りたいかが先にあると、どのデータを残すべきかが決まります。
内製と外注の判断軸
内製と外注は、どちらが優れているという話ではありません。変更の頻度で分けると判断しやすくなります。
運用しながら頻繁に手を入れる業務は、内製に向いています。改善のたびに見積もりと発注をはさむと、速度が落ちるためです。一方、仕様が安定していて数年変わらない業務は、外注でも支障が出にくくなります。
判断の詳細は内製化とはで解説しています。自社の体制と照らして考える材料になります。
費用より重い失敗パターン
社内システム開発で本当に痛いのは、金額よりも「作ったのに使われない」状態です。作り直しの費用に加え、現場の信頼も失われます。
使われなくなる原因は、多くの場合2つに集約されます。ひとつは、作った本人しか分からない設計になっていること。もうひとつは、業務の実態と手順が合っていないことです。
筆者が営業代行会社で構築したDM手配の仕組みは、退職から年数が経った今も使われ続けていると聞いています。理由を振り返ると、機能が優れていたからではなく、当時の担当者が普段やっている手順をそのまま画面の並びにしたからだと考えています。新しい手順を覚えてもらう前提の設計にしなかった点が、結果的に定着につながりました。
費用を抑える現実的な方法
費用を下げる方法として最も効果があるのは、値引き交渉ではなく範囲の設計です。同じ予算でも、どこを削るかで結果が大きく変わります。
最初から全部作らない
よくある失敗は、想定されるすべての機能を最初に盛り込むことです。実際に使われるのは一部であり、使われない機能の分だけ費用と保守の手間が増えます。
現実的なのは、まず1つの業務が回る最小の形を作り、使いながら足していく進め方です。使ってみて初めて分かる要望は少なくありません。先に作り込むほど、後で捨てる部分が増えます。
既存の道具で足りる部分は残す
すべてを新しく作る必要はありません。表計算ソフトで十分に回っている業務は、そのまま残す判断もあります。
置き換える対象は、複数人が同時に触る業務、件数が増えて限界が見えている業務、転記が発生している業務に絞ると効果が出やすくなります。判断の材料は脱エクセルにまとめています。
移行するデータの範囲を決める
見落とされやすいのが、過去データの移行費用です。何年分を移すかで、作業量は大きく変わります。
過去分は参照できれば十分という業務であれば、新しい仕組みには当月以降だけを入れ、過去は元の場所に残す方法もあります。移行そのものをやめる判断が、費用に最も効く場面もあります。
発注前に確認しておきたいこと
契約の前に、次の点を確認しておくと後の食い違いを減らせます。
- 納品後、誰がどこまで手を入れられるか
- 仕様変更が発生した場合の費用の考え方
- 運用開始後のサポート範囲と期間
- データの所有と、他社へ移す場合の扱い
特に最後の項目は見落とされがちです。将来的に別の体制へ移す可能性を考えると、自社のデータを自由に取り出せる状態かどうかは確認しておく価値があります。
よくあるご質問
Q. 社内システム開発の費用はどのくらいかかりますか
業務1つ分の小さな仕組みで数十万円から、部門をまたぐ規模になると数百万円以上が目安になります。ただし同じ要望でも会社によって見積もりが大きく割れるため、金額だけの比較はおすすめしません。
Q. 見積もりが会社によって大きく違うのはなぜですか
決まっていない部分をどこまで見込むかが各社で異なるためです。使う人や運用ルールが固まっていないほど、見積もりには不確実性を吸収するための幅が乗ります。
Q. 社内システムは内製と外注のどちらがよいですか
変更の頻度で判断する方法があります。運用しながら頻繁に手を入れる業務は内製に向き、仕様が安定していて長く変わらない業務は外注でも問題が起きにくくなります。
まとめ
社内システム開発の費用は、規模別の相場こそあるものの、実際の金額は「何が決まっていないか」で大きく動きます。見積もりを比べる前に、使う人、やめる業務、残すデータの3つを自社で決めておくと、提示される金額の幅は縮まります。
そして費用以上に重いのは、作ったものが使われない事態です。既存の手順に沿った設計にすること、作った本人以外が説明なしで扱えることを、発注時の条件として伝えてみてください。
業務の整理から仕組みづくりまでのご相談はシクミAIへ。「何を決めればよいか分からない」段階からで大丈夫です。まずは無料相談から、要件の整理を一緒に進めましょう。
