Excel台帳をそのままWebシステム化するといくらかかる？

「今使っているExcel台帳を、フルスクラッチのWebシステムにしたらいくらかかりますか」。この質問に、開発会社の営業担当が即答で金額を提示してきたら、むしろ警戒したほうがいいかもしれません。台帳の中身も、業務フローも、連携先も見ないまま出てくる金額には、たいてい根拠がないからです。

Excel台帳の限界を感じて情報収集を始めると、kintoneのようなノーコードツールの記事はたくさん見つかります。ところが「フルスクラッチでWebシステムを作るといくらか」という情報は、驚くほど出てきません。出てきたとしても「30万円〜」「100万円〜」といった、根拠の見えない金額が並んでいるだけだったりします。そのため、Excel運用の限界サインは自覚しているのに、次の一歩である「発注」のイメージが全くつかめず、検討が止まってしまう担当者は少なくありません。

結論から言うと、Excel台帳をフルスクラッチのWebシステム化する費用は、他社の事例をそのまま当てはめて予測できる性質のものではありません。金額は「機能の複雑さ」「データ量」「連携先の数」という3つの軸の掛け合わせで決まり、同じ「在庫管理システム」という名前がついていても、この3軸の内容次第で規模は大きく変わります。この記事では、根拠のない相場観を提示する代わりに、何が金額を左右するのかという構造そのものを解説します。読み終える頃には、自社のExcel台帳がどのくらいの規模の話になりそうか、当たりをつけられるようになるはずです。

この記事で分かること

Excel台帳のWebシステム化を検討し始めた担当者が抱える疑問に、順番に答えていきます。

• なぜ「相場」という考え方がそもそも当てはまらないのか
• 費用を左右する3つの軸（機能の複雑さ・データ量・連携先の数）の中身
• ノーコードとフルスクラッチで、費用の考え方がどう違うのか
• 見積もりを取る前に、自社側で整理しておくべきこと
• 「安い見積もり」と「高い見積もり」の差が何を意味するか
• 費用以外に発生するコスト（保守・運用体制）
• 発注前に確認すべきチェックリスト

一つずつ、順を追って見ていきます。

なぜ「Excel台帳のシステム化はいくら」という質問に答えが出ないのか

まず押さえておきたいのは、「Excel台帳をシステム化する」という表現自体が、実はかなり幅の広い依頼だということです。

たとえば同じ「顧客管理台帳のシステム化」という依頼でも、次の2つは要求される開発規模がまったく違います。

• パターンA: 顧客名・連絡先・対応履歴を入力し、一覧で検索できればよい。利用者は社内の3人だけ
• パターンB: 顧客情報に加えて、契約書PDFの添付、承認フローの多段階チェック、会計システムとの自動連携、支店ごとの閲覧権限管理まで必要

パターンAとBでは、必要な設計・実装・テストの工数が数倍〜数十倍単位で変わります。それにもかかわらず、両方とも「顧客管理システム」という同じ言葉で語られてしまうのが、この分野で「相場」が機能しない最大の理由です。

実務上の視点: 見積もりサイトや比較記事で「Webシステム開発 30万円〜500万円」のような幅の広い表示を見たことがある方も多いはずです。この幅の広さ自体が、機能次第で規模が何十倍にも変わるという実態を正直に反映した結果とも言えます。逆に言えば、幅を示さず単一の金額を即答してくる相手には、その金額がどの前提に基づいているのかを必ず確認する必要があります。

家を建てるときに「家を建てるといくらですか」と聞いても答えが出ないのと似ています。平屋か3階建てか、部屋数はいくつか、素材は何かによって金額は大きく変わります。それと同じで、Excelシステム化も「間取り」に相当する要件が定まらない限り、金額は決まりません。

費用を左右する3つの軸

Excel台帳のシステム化費用は、大きく分けて3つの軸の掛け合わせで決まります。それぞれの軸が何を意味するのか、具体的に見ていきましょう。

軸1: 機能の複雑さ

もっとも金額への影響が大きいのが、この軸です。「単純な入力・一覧・検索」だけのシステムと、「複雑な業務ロジックを伴う」システムでは、必要な設計工数が桁違いになります。

複雑さを押し上げる代表的な要素は次の通りです。

• 承認フロー: 「入力→上長承認→経理確認→確定」のように、複数人・複数段階のチェックが必要か
• 権限管理: 「支店ごとに見える範囲を分ける」「役職によって編集可否を変える」といった細かい権限設計が必要か
• 自動計算・条件分岐: Excelの関数やマクロで実現していた複雑な計算ロジックを、システム側で再現する必要があるか
• 帳票出力: 決まったレイアウトの請求書・納品書などをPDFやExcel形式で出力する必要があるか
• 通知機能: 「在庫が一定数を切ったらメールで通知する」といった能動的な仕組みが必要か

Excelでマクロを組んで自動化していた業務ロジックほど、システム化の際に「同等の動きを再現するための設計」が必要になり、複雑さが増す傾向があります。逆に「入力して、一覧で見て、検索する」だけであれば、比較的シンプルな部類に入ります。

軸2: データ量

2つ目の軸は、扱うデータの量です。ここで言うデータ量とは、単なる行数だけでなく、データの「構造の複雑さ」も含みます。

• 現在のExcel台帳の行数（数百行か、数万行か）
• 1件のデータが持つ項目数（列数）
• 過去データをどこまで移行するか（直近1年分だけか、全履歴か）
• 複数のExcelファイルにまたがるデータを1つに統合する必要があるか

データ量そのものよりも、実は「複数のExcelファイルに分散したデータを1つの構造に統合する」作業のほうが、費用への影響が大きくなりがちです。表記ゆれの是正や重複データの整理といったデータクレンジングの工程は、システム開発そのものとは別に発生する作業であり、見落とされやすい部分です。ファイルが1つの台帳だけで完結しているか、複数の台帳・複数の部署のExcelを寄せ集める必要があるかで、前提が大きく変わります。

軸3: 連携先の数

3つ目の軸は、そのシステムが他の何と連携する必要があるかです。これは意外と見落とされがちですが、費用への影響が大きい要素です。

• 会計システムやレジシステムとのデータ連携が必要か
• 既存の基幹システムからデータを取り込む必要があるか
• 外部の取引先とデータをやり取りする必要があるか
• 既存のメール配信システムやチャットツールと連携する必要があるか

連携先が1つ増えるごとに、その連携先の仕様を調べる工程、実際につなぎこむ実装工程、双方でテストする工程が追加で発生します。連携先が多いシステムほど、単純に「機能を作る」以上の手間がかかると考えておく必要があります。

3軸をまとめると

ここまでの3軸を整理すると、次のような対比になります。

自社のExcel台帳をこの3軸に当てはめてみると、「思ったより単純な部類」なのか、「実はかなり複雑な部類」なのかが見えてきます。見積もりを依頼する前に、まず自社でこの3軸を書き出してみることをおすすめします。

3軸の掛け合わせを、仮想の3パターンで見てみる

3軸の考え方をより具体的にイメージするために、架空の3つのケースで思考実験をしてみます。いずれも金額を示すものではなく、あくまで「どの要素が規模を押し上げるか」を確認するための例です。

ケース1: 備品貸出台帳（小規模想定）

社内の備品（ノートPCやプロジェクターなど）の貸出・返却を記録しているExcel台帳です。機能面では、貸出者・備品名・貸出日・返却予定日を入力し、一覧で「今誰が何を借りているか」を検索できれば足ります。承認フローや複雑な計算はなく、データ量も数百件程度、外部システムとの連携もありません。3軸すべてが「小規模」側に寄っており、比較的シンプルな部類に入ると考えられます。

ケース2: 発注管理台帳（中規模想定）

取引先への発注内容と入荷状況を管理しているExcel台帳です。発注担当者が入力した内容を、上長が金額に応じて承認するフローがあり、発注確定後は指定フォーマットの発注書PDFを出力して取引先にメールで送る運用になっています。機能の複雑さは中程度、データ量は数千件規模、連携先は「PDF出力」「メール送信」の2つです。3軸のうち1つ以上が「大規模」側に寄っている状態であり、備品貸出台帳より確実に規模は大きくなります。

ケース3: 在庫・受発注一元管理台帳（大規模想定）

複数の支店それぞれが個別に管理していた在庫Excelを1つに統合し、さらに会計システムへの売上データ連携、レジシステムとの在庫数リアルタイム連携まで求めるケースです。支店ごとの権限管理、在庫が閾値を切った際の自動通知、複雑な原価計算ロジックも必要とします。機能の複雑さ・データ量（複数ファイル統合）・連携先の数（会計・レジの2系統以上）のすべてが「大規模」側に該当し、3軸が重なり合うことで、ケース1やケース2とは比較にならない規模の開発になることが見て取れます。

実務上の視点: この3ケースの違いを生んでいるのは「業種」や「業界」ではなく、あくまで3軸の内容です。同じ「在庫管理」という括りでも、ケース1相当の単純な入出庫記録なのか、ケース3相当の複数拠点・複数システム連携なのかによって、必要な開発規模は大きく変わります。自社の台帳がどのケースに近いかを考えることが、見積もり依頼の第一歩になります。

開発工程ごとに費用がどう積み上がるか

見積書に「一式」とだけ書かれていると、何にいくらかかっているのか分かりにくいものです。フルスクラッチ開発の費用は、いくつかの工程を経て積み上がっていきます。各工程で何をするのかを知っておくと、見積書の内訳を読み解きやすくなります。

1. 要件定義: 「何を作るか」を発注側と開発会社ですり合わせる工程。前章で挙げた3軸の内容を、実際にヒアリングを通じて具体化していきます。ここが曖昧なまま次の工程に進むと、後から「思っていたものと違う」という手戻りが発生しやすくなります
2. 設計: 要件定義で固めた内容を、実際にどんな画面構成にするか、データベースにどうデータを持たせるかといった形に落とし込む工程です
3. 実装: 設計に基づいて、実際にプログラムを組む工程です。一般的に開発工数の中で最も大きな割合を占めます
4. テスト: 想定通りに動くか、想定外の入力をしたときに壊れないかを確認する工程です。特に既存Excelからのデータ移行や外部システム連携がある場合は、テストの範囲も広がります
5. リリース・移行: 実際にExcel運用からシステム運用へ切り替える工程です。並行運用の期間を設けるかどうかも、この段階で検討します

これらの工程のうち、要件定義が曖昧なまま進んでしまうと、実装やテストの段階で「これも必要だった」という追加要望が発生し、当初の見積もりから膨らんでいく原因になります。見積もりの精度を上げたい場合、要件定義の工程に十分な時間をかけてくれる開発会社かどうかも、比較のポイントになります。

「まず小さく試す」という発注の選択肢

要件がどうしても固まりきらない、あるいは投資判断のために一度動くものを見てから本格発注を決めたい、というケースもあるかと思います。そうした場合には、いきなり全体を発注するのではなく、段階を分けて発注するという選択肢もあります。

• PoC（概念実証）（概念実証）を先に依頼する: 本格開発の前に、特定の機能や技術的な実現可否だけを小さく検証する進め方です。「このExcelの複雑な計算ロジックは本当にシステム上で再現できるのか」といった不安がある場合に、リスクを抑えて確認できます
• 必須機能だけで最初のバージョンを作る: 前述のMVP（実用最小限の製品）の考え方です。「あったら嬉しい機能」を後回しにし、まず最小限の範囲で稼働させてから拡張していきます
• 部署・拠点を絞って先行導入する: 全社一斉切り替えではなく、1部署・1拠点で試験運用してから展開範囲を広げる進め方です

いずれの進め方も、初期投資と手戻りリスクを抑えられる一方、段階を分けた分だけ全体のスケジュールは長くなる傾向があります。「早く全体を完成させたい」のか「リスクを抑えながら着実に進めたい」のかは、社内の状況に応じて優先順位をつける必要があります。

契約形態によっても費用の考え方が変わる

見積もりを比較する際、金額の内訳と同じくらい重要なのが契約形態です。フルスクラッチ開発の契約は、大きく分けて請負契約と準委任契約の2種類があります。

請負契約は、あらかじめ定めた成果物を完成させる責任を開発会社が負う契約形態です。要件が明確に固まっている場合に向いており、金額も工程全体を通じて確定しやすい傾向があります。一方、準委任契約は、成果物の完成そのものではなく、決められた業務を遂行することを約束する契約形態です。要件が変化しやすいプロジェクトや、前述のMVP的な進め方と相性がよく、契約期間中の稼働に応じて費用が発生する形が一般的です。

どちらの契約形態を提案してくるかは、開発会社によって、また案件の性質によって異なります。見積もりを比較する際は、金額だけでなく「どちらの契約形態か」「その契約形態が自社の状況に合っているか」もあわせて確認することをおすすめします。

ノーコードとフルスクラッチ、費用の考え方の違い

「Excel台帳の次」を考えるとき、多くの担当者はkintoneのようなノーコード・ローコードツールと、フルスクラッチのWebシステム開発の両方を検討対象に入れます。この2つは費用の発生の仕方が根本的に異なるため、混同すると判断を誤ります。

ノーコードツールは、月額や年額のライセンス費用を継続的に支払うことで、あらかじめ用意された機能の枠内でシステムを組み立てる形が一般的です。初期費用を抑えやすい一方、枠を超える複雑な業務ロジックや、独自性の高い画面デザインには対応しづらい場面があります。

一方フルスクラッチ開発は、要件定義から設計・実装・テストまでを一から作り上げるため、初期費用は相応にかかりますが、業務にぴったり合わせた作り込みが可能で、月額のライセンス費用は発生しません（サーバー代・保守費用は別途必要です）。

どちらが自社に向いているかは、前章の3軸、特に「機能の複雑さ」に大きく左右されます。ノーコードの標準機能で足りる業務であれば、無理にフルスクラッチを選ぶ必要はありません。逆に、承認フローや独自の計算ロジックがノーコードツールの枠を超える場合は、フルスクラッチのほうが結果的に無理のない選択になることがあります。この判断軸をより詳しく知りたい方は、脱Excelの判断フローを扱った別記事、ノーコードツール同士の比較を扱った別記事もあわせてご覧ください。

実務上の視点: 「ノーコードは安い、フルスクラッチは高い」という単純な図式で語られがちですが、正確ではありません。ノーコードツールでも、複雑な業務に無理やり当てはめようとしてカスタマイズを重ねた結果、当初の想定より費用がかさむケースは珍しくありません。逆にフルスクラッチでも、機能を絞り込めば想定より抑えられることもあります。ツールの種類ではなく、自社の要件の複雑さが費用を決めるという原則は変わりません。

見積もりを取る前に、自社で整理しておくべきこと

金額の根拠が見えない見積もりが出てくる最大の原因は、発注側の要望が固まっていないまま相談してしまうことにあります。開発会社に相談する前に、次の項目を自社内である程度整理しておくと、見積もりの精度が大きく変わります。

1. 現在のExcel台帳を実際に見せられる状態にしておく: 「顧客管理をシステム化したい」という言葉だけでなく、実物のファイルを見てもらうことで、開発会社側も複雑さを具体的に把握できます
2. 「必須の機能」と「あったら嬉しい機能」を分けておく: すべてを一度に実現しようとすると費用が膨らみます。優先順位をつけることで、段階的な開発（まず必須機能だけで動かし、後から拡張する）という選択肢も取れるようになります
3. 利用人数と利用部署を把握しておく: 権限管理の複雑さに直結します
4. 連携させたい既存システムを洗い出しておく: 「実は経理システムとも連携したかった」が後から判明すると、手戻りや追加費用の原因になります
5. 予算の上限をおおまかにでも決めておく: 青天井で要望を並べるのではなく、「この予算内でどこまでできるか」という会話ができると、現実的な提案を引き出しやすくなります

これらの整理は、開発会社が正式に要件定義を行う前の、いわば下準備にあたります。この段階での情報が具体的であるほど、開発会社が提示するRFP（提案依頼書）への回答や見積もりの精度が上がり、後工程での認識のズレを減らせます。

補足: 最初から全部を完璧に決めようとする必要はありません。すべてを一度に作るのではなく、まず最小限の機能で動かしてみて、実際の使用感を見ながら拡張していくという進め方を提案してくる開発会社もあります。この進め方自体は不自然なものではなく、要件を固めきれない場合の現実的な選択肢のひとつです。

「安い見積もり」と「高い見積もり」は何が違うのか

複数の開発会社から見積もりを取ると、同じ要望を伝えたはずなのに金額に大きな差が出ることがあります。これは開発会社が不誠実だからとは限らず、いくつかの構造的な理由があります。

• 前提にしている機能範囲が違う: ヒアリング時点で聞き取った要望のどこまでを見積もりに含めているかが会社によって異なります。安い見積もりは、実は一部の機能が含まれておらず、後から追加費用として提示される場合があります
• 保守・運用費用の扱いが違う: 初期開発費用だけを比較していると見落としがちですが、開発後の保守契約費用を含めているかどうかで、総額の見え方が変わります
• 契約形態が違う: 請負契約と準委任契約では、成果物に対する責任の重さが異なり、それが金額にも反映されます
• リスクの織り込み方が違う: 要件が固まりきっていない案件をあえて安く受け、後から仕様変更のたびに追加費用を積み上げていく進め方をする会社もあります

見積もりを比較する際は、金額の大小だけでなく、「何が含まれていて、何が含まれていないか」を項目単位で確認することが欠かせません。可能であれば、見積書の内訳をSOW（作業範囲記述書）（作業範囲記述書）に近い粒度で出してもらい、機能ごとの範囲を明確にしてもらうとよいでしょう。

また、契約書に契約不適合責任がどう定められているかも、金額の妥当性を判断する材料になります。極端に安い金額は、こうした責任範囲や保証内容を削ることで実現している場合もあるため、金額だけでなく契約条件もあわせて確認する姿勢が重要です。

費用以外に発生するコストも忘れずに

初期の開発費用にばかり目が行きがちですが、フルスクラッチのWebシステムには、稼働後にも継続的なコストが発生します。見積もり比較の際は、これらも含めた総額で考える必要があります。

• サーバー・インフラ費用: システムを動かし続けるための月額費用
• 保守費用: 障害対応やちょっとした修正依頼に応じてもらうための費用
• 将来の機能追加費用: 運用しているうちに「この機能も欲しい」となった場合の追加開発費用

ここで注意したいのがベンダーロックインのリスクです。特定の開発会社にしか分からない独自仕様で作られてしまうと、将来その会社と関係が切れた際に、別の会社への引き継ぎが難しくなったり、高額な調査費用が発生したりすることがあります。契約時点で、ソースコードの権利がどちらに帰属するのか、開発ドキュメントは残してもらえるのかを確認しておくことは、初期費用の比較と同じくらい重要な観点です。

相見積もりを取るときに気をつけたいこと

見積もりの精度を上げるために複数社から相見積もりを取るのは有効な手段ですが、進め方を誤ると比較そのものが成立しなくなります。最後に、相見積もりを取る際の実務上の注意点を整理します。

• 各社に同じ情報を渡す: A社には現物のExcelファイルを見せたのに、B社には口頭説明だけだった、という状態では、そもそも比較の前提が揃いません。前章の「発注前に整理しておくこと」を各社に同じ粒度で伝えることが大前提になります
• 質問の内容も比較材料にする: 要件を伝えた際に、開発会社側からどれだけ具体的な質問が返ってくるかは、その会社の見積もり精度を測る目安になります。質問がほとんどなく即座に金額が出てくる場合、その金額がどこまで実態を反映しているか、慎重に確認したほうがよいでしょう
• 極端に安い見積もりの理由を確認する: 相場が存在しない以上、「安いから得」とは限りません。前述の通り、機能範囲が狭い、保守費用が別立てになっている、契約上の保証が薄いといった理由で安くなっている可能性を、遠慮なく質問して確認してください
• 担当者との相性も判断材料に含める: 開発は発注して終わりではなく、要件定義から稼働後の保守まで長い付き合いになります。金額の妥当性だけでなく、疑問に対して誠実に答えてくれるか、専門用語を分かりやすく説明してくれるかといった点も、実務上は無視できない判断材料です

実務上の視点: 相見積もりの目的は「一番安い会社を選ぶこと」ではなく、「自社の要件に対して、それぞれの会社がどう向き合っているかを知ること」にあります。金額の比較表だけを見て決めるのではなく、各社とのやり取りの中で見えてくる姿勢もあわせて判断材料にすることをおすすめします。

発注前チェックリスト

ここまでの内容を、見積もり依頼の前に確認するチェックリストとしてまとめます。

• [ ] 現在のExcel台帳を、開発会社にそのまま見せられる状態にしてある
• [ ] 「必須の機能」と「あったら嬉しい機能」を分けて整理してある
• [ ] 利用人数・利用部署・権限の考え方をおおまかに把握している
• [ ] 連携させたい既存システムを洗い出してある
• [ ] 予算のおおまかな上限を決めてある
• [ ] 複数社から見積もりを取り、機能範囲を項目単位で比較する予定である
• [ ] 初期費用だけでなく、保守費用・インフラ費用も含めた総額で比較する
• [ ] ソースコードの権利・ドキュメントの引き渡しについて確認する予定である
• [ ] 見積もりに記載のない前提（含まれない機能）がないか、質問する準備がある

このチェックリストをすべて埋めた状態で相談に臨めば、開発会社側も的確な見積もりを出しやすくなり、結果として「なぜこの金額になるのか」が納得できる見積もりを受け取れる可能性が高まります。

まとめ

Excel台帳をフルスクラッチのWebシステム化する費用は、「相場」という一律の数字では語れません。金額を左右するのは、機能の複雑さ・データ量・連携先の数という3つの軸であり、この3つがどう組み合わさるかによって、同じ「台帳のシステム化」でも規模はまったく異なります。

根拠のない金額を提示してくる相手より、「なぜその金額になるのか」を3軸に沿って説明できる相手のほうが、信頼できる可能性が高いと言えます。見積もりを依頼する前に、自社の要件を3軸で整理し、この記事のチェックリストを埋めてから相談に臨むことで、的外れな見積もりに振り回されるリスクを減らせるはずです。

次に読むなら、そもそも自社のExcel運用がシステム化を検討すべき段階に来ているかどうかを判断したい方は、Excel台帳の危険度チェックの記事を、システム化する範囲・しない範囲の判断基準を知りたい方は、脱Excelの判断フローの記事をあわせてご覧ください。