受発注システムの刷新に、役員会で2,000万円の枠が付いた。ところが「2,000万で足りるのか」「この額で何ができるのか」は誰にも分からないまま、金額だけが先に決まっている。開発会社に聞いても「要件によります」と返ってきて、社内に持ち帰る言葉がない。システム開発の予算で発注側が困るのは、相場を知らないことではなく、手元の枠から逆に考える道具がないことです。この記事では、費用相場の一覧ではなく、決まった予算で何がどこまでできるのかを金額帯ごとに整理します。

この記事のポイント

  1. 予算は金額ではなく何人が何か月動けるかに置き換えて考える
  2. 予算の3割は要件定義やテストなど開発以外に消える
  3. 金額帯で変わるのは機能の数だけでなく体制と期間
  4. 足りないときは機能ではなく対象範囲から削る
目次
  1. システム開発の予算別にできること
  2. 予算は人数と期間に変わる
  3. 予算の3割は開発以外に消える
  4. 金額帯ごとに何が変わるか
  5. 同じ金額でも中身が変わる3つの条件
  6. システム開発の予算が足りないときの考え方
  7. 削る順番は機能ではなく範囲から
  8. 段階に分けて2回に回す
  9. 作らない選択肢と比べてから決める
  10. 開発会社に予算を伝えるべきか
  11. 総括:システム開発の予算から逆に考える

システム開発の予算別にできること

高さの違う4本の縦棒が左から順に高くなり、それぞれの上に積めるブロックの数が変わることを示した図
予算の帯が変わると、積める量だけでなく積み方も変わります

最初に、金額を金額のまま考えないことをおすすめします。2,000万円という数字だけを見ても、それが多いのか少ないのか判断できないからです。

なお、この記事に出てくる数字はあくまで一般的な目安です。同じ金額でも会社や案件によって幅が出るので、実際の判断は個別の見積もりで確認してください。

予算は人数と期間に変わる

開発費用は、大まかには「何人が何か月働くか」で決まります。だから予算を、動かせる人数と期間に置き換えると見当がつきます。

計算は単純です。予算を1人月あたりの金額で割ると、動かせる人月が出ます。1人月というのは、1人が1か月働く量のことです。仮に1人月100万円とすると、2,000万円なら20人月。これを4人で分ければ5か月、5人なら4か月という見当になります。

この置き換えをすると、社内の会話が変わります。「2,000万で足りますか」ではなく「4人が5か月かけて作れる範囲ですか」と聞けるようになるからです。後者なら、開発会社も答えやすくなります。

人数と期間に直すと、社内の準備も見積もれるようになります。開発会社が4人で5か月動くなら、自社側も同じ期間つき合うことになります。要件を決める打ち合わせ、出てきた設計の確認、受け入れテスト。誰がどれくらい時間を取られるのかが、月単位で見えてきます。ここを見込まずに「本業の合間で」と考えると、自社の作業が原因で遅れることになります。

1人月の金額は担当する人の職種や会社の規模で変わります。その内訳や算出の考え方はシステム開発費用の算出方法と工数の見方で扱っているので、金額の根拠まで詰めたいときはそちらを見てください。

予算の3割は開発以外に消える

もうひとつ、枠を作るときに必ず見込んでおきたいことがあります。予算の全額が機能を作ることに使えるわけではない、という点です。

機能を作る以外にかかるのは、要件定義、テスト、既存データの移行、現場への操作教育、そして稼働してから1年目の保守です。案件にもよりますが、私の感覚ではこれらで全体の3割前後は持っていかれます。

この分を見込まずに枠を取ると、終盤で必ず溢れます。とくに抜けやすいのがデータ移行と操作教育です。どちらも「うちでやります」と言いがちな作業ですが、実際には自社の担当者が何週間も取られることになります。お金で解決するなら、その分を最初から枠に入れておく必要があります。

初年度の保守費も見落とされます。稼働してから1年目は、想定外の不具合や運用の微調整が集中する時期です。ここを見ていないと、稼働した翌月に「保守契約はどうしますか」と聞かれて慌てることになります。年間の保守費は初期費用の1割から1割5分あたりで語られることが多い範囲ですが、これも会社によって幅があるので見積もりで確認してください。

金額帯ごとに何が変わるか

ここからが本題です。金額帯が上がると何が変わるのか。機能の数が増えるのはもちろんですが、それ以上に体制と期間が変わります。

予算 動かせる人月の目安 体制と期間の目安 作れるものの例 この帯では難しいこと
500万円 4〜6人月 2人で2〜3か月 ひとつの業務に絞った管理画面。既存の仕組みは触らない 他システムとの連携、外部公開、複数部署の同時利用
1,000万円 8〜12人月 3人で3〜4か月 ひとつの業務を通しで回せる仕組み。簡単な連携1本 基幹システムとの本格的な連携、社外向けの画面
2,000万円 16〜24人月 4人で5か月前後 複数部署がまたがる業務。既存システムとの連携数本 全社一斉の切り替え、24時間止められない要件
3,000万円 25〜35人月 5〜6人で6か月前後 基幹に近い範囲。段階的な移行と並行稼働まで含む 数十拠点の一斉展開、大規模な社外サービス

表を見るときは、右端の「この帯では難しいこと」から読んでください。作れるものより、その予算では無理なことを先に知るほうが計画が狂いません。

とくに境目が出やすいのが、他のシステムとつなぐかどうかです。連携が1本入ると、相手側の仕様調査と試験が乗るので、体感では機能を2つ3つ足すのと同じくらいの重さになります。500万円の帯で連携を前提にすると、たいてい入りきりません。

同じ金額でも中身が変わる3つの条件

同じ2,000万円でも、入る機能の量は倍近く変わります。差を生むのは主に3つです。

  • 既存のシステムとつなぐ必要があるか
  • 使うのが社内だけか、社外の取引先や顧客にも出すか
  • 今の業務のやり方を変えられるか、変えずに合わせる必要があるか

3つ目が見落とされがちです。今のやり方をそのまま再現しようとすると、例外処理を全部作り込むことになります。逆に「この機会に運用を揃える」と決められるなら、同じ予算でずっと多くのことができます。ここは開発会社ではなく、発注側にしか決められません。

システムの種類ごとに金額を知りたい場合は方向が逆になるので、システム開発の費用相場を規模別・種類別に見るのほうが近い内容です。この記事は予算から引く場合に絞っています。

システム開発の予算が足りないときの考え方

休憩スペースで届いたばかりの綴じた資料を開き、中身を確かめている手元
枠に収まらないと分かったときは、削る順番に決まりがあります

ここまで読んで「うちの枠では足りない」と気づいた方も多いはずです。実際、枠が先に決まっていて足りない、というのが現場では一番多い形です。

削る順番は機能ではなく範囲から

足りないと分かったとき、多くの会社は機能を1つずつ削ろうとします。これはうまくいかないことが多いところです。少しずつ削った結果、どの業務も中途半端に対応されて、結局は現場が使わないシステムになります。

先に削るのは対象範囲です。使う拠点を絞る、対象の部署を絞る、業務の一部だけを切り出す。同じ機能でも対象が半分になれば、要件を決める時間もテストも移行も半分になります。効き方がまるで違います。

範囲を絞る判断は、どこから使い始めると効果が見えやすいかで決めます。取引量の多い拠点から始めれば、効果の数字が早く出るので次の予算も取りやすくなります。

絞るときに注意したいのは、業務の途中で切らないことです。受注から出荷までの流れのうち、真ん中だけをシステム化すると、前後で紙とシステムを行き来することになって現場の手間がかえって増えます。切るなら業務の切れ目か、拠点や部署の単位で切ります。

段階に分けて2回に回す

範囲を絞ったら、残りをどうするかです。多くの場合、今年度の枠で1回目を作り、翌年度に広げる形になります。

正直に書くと、2回に分けると総額は増えます。2回目にも設計とテストが必要ですし、1回目の稼働中に手を入れる分の慎重さも乗ります。それでも分ける価値があるのは、1回あたりが枠に収まることと、1回目の結果を見てから2回目の中身を決められることです。

役員会には、最初から2段階の計画として出しておくほうが通りやすくなります。今年度だけの話にしてしまうと、翌年度の追加予算が「想定外の支出」に見えてしまいます。

作らない選択肢と比べてから決める

もうひとつ、予算が足りないときに必ず一度は検討したいのが、そもそも作らないという選択です。

既製のサービスで回るなら、作るより安く早く始められます。判断の線引きは、その業務のやり方が自社の競争力になっているかどうかです。競争力になっていない業務なら、既製品に自社を合わせるほうが合理的です。逆に、そのやり方こそが強みだという業務なら、作る価値があります。

作る場合でも、いきなり全部を作らずに小さく始める方法があります。MVP開発で最小限の機能から始める進め方は、予算が限られているときの現実的な選択肢になります。

既製品と作る場合を比べるときは、5年分で並べてください。既製品は初期が軽いかわりに月額が続き、作る場合は初期が重いかわりに使用料が要りません。3年で比べるか5年で比べるかで、答えが入れ替わることがあります。比べる年数を先に決めてから数字を並べるのが順番です。

開発会社に予算を伝えるべきか

エントランスで立ったまま、担当者どうしが予算の枠について短く話している場面
枠を伝えないと、各社が違う前提で見積もることになります

よく聞かれるのが、予算を先に伝えると足元を見られるのではないか、という心配です。結論から言うと、伝えたほうがいいと考えています。

伝えない場合、各社が思い思いの前提で見積もってきます。A社は1,200万、B社は2,800万という数字が並んでも、範囲が違うので比べようがありません。比較のために結局もう一度そろえ直すことになり、時間が倍かかります。

聞き方は「2,000万円の枠でどこまでできますか」です。金額を出したうえで範囲の提案を求めると、各社が同じ土俵で答えてくれます。枠に合わせて水増しされることが心配なら、内訳の出し方を指定してください。工程ごとの人月と、誰が何か月入るかを書いてもらえば、中身が薄いかどうかは読み取れます。

出てきた見積もりが枠に対して妥当かを項目単位で確かめたいときは、システム開発見積もりチェックシート(危険サインを見抜く60項目)が使えます。範囲の書かれ方と前提条件の抜けは、金額の大小より先に見るところです。

Q. システム開発の1人月の相場はいくらですか
A. 担当する人の職種と会社の規模で幅がありますが、80万円から150万円あたりで語られることが多い範囲です。ただしこれはあくまで一般的な目安で、実際の金額は個別の見積もりで確認してください。予算を人月に置き換えて見当をつける目的なら、100万円で割って概算を出し、あとで実際の単価に入れ替えるくらいで十分です。
Q. 開発会社に予算を先に伝えると、その額いっぱいの見積もりが来ませんか
A. その心配はもっともですが、伝えないほうが損をしやすいです。各社が違う前提で出してくると比較できず、やり直しになります。対策は、金額を伝えたうえで内訳の形式を指定することです。工程ごとの人月、参加する人の役割と期間を書いてもらえば、枠に合わせて膨らませたのか、根拠があるのかは読み取れます。
Q. 予算が決まっていないときは何から決めればいいですか
A. 金額より先に、対象範囲を決めてください。どの業務の、どの拠点の、誰が使うものかが決まれば、開発会社が概算を出せます。その概算を持って社内で枠を取り、要件定義を経て正式な金額で稟議を通す、という2段構えが現実的です。最初の概算をそのまま確定金額として社内に伝えると、あとで説明に苦しむことになります。