受発注管理をSaaSからNext.jsフルスクラッチに切り替える判断基準

毎月の受発注SaaSの請求書を見て、「この機能の半分も使っていないのに」と感じたことはないでしょうか。あるいは、自社のワークフローに合わない画面構成に合わせて業務を変えている、CSV出力のフォーマットが固定で後工程の加工に毎回手間がかかる——そうした小さな不満が積み重なっているなら、フルスクラッチへの切り替えを検討するタイミングかもしれません。ただし、SaaSにはSaaSの強みがあります。この記事では、受発注SaaSに不満を感じ始めている中小企業の経営者の方に向けて、「切り替えるべき条件」と「SaaSを残すべき条件」の両面から判断基準を整理します。

どんなサインが出たら切り替えを検討すべきか？

SaaSへの不満がすべて切り替えの理由になるわけではありません。以下のチェックリストで、自社の状況がどちらに近いかを確認してみてください。

切り替えを検討すべきサイン

• 使っていない機能に毎月コストを払っている。 SaaSの月額が膨らんでいるのに、利用しているのは受注管理と請求書発行だけ、という状態です。
• 自社固有の承認フローや帳票に対応できない。 「見積→社内承認→受注」の間に自社特有のステップがあるのに、SaaS側で再現できない。結果として、SaaSとExcelを併用している。
• データの入出力に制約がある。 欲しい項目でCSVが出せない、他システムとのAPI連携に制限がある、といった状況が業務のボトルネックになっている。
• SaaSの仕様変更に業務が振り回される。 アップデートで画面が変わるたびに現場が混乱する。自社の業務ペースではなく、SaaS側の開発ロードマップに従わざるを得ない。
• 月額課金の累積が、開発費用のレンジに近づいている。 年間で換算したときに、フルスクラッチの開発・運用費と大差がない水準になっている。

SaaSを残すべきサイン

• 法改正や税制対応をSaaS側が自動で吸収してくれている。 インボイス制度や電子帳簿保存法への対応をSaaSが肩代わりしている場合、自前で追従し続けるコストは小さくありません。
• 業務フローがSaaSの標準に十分収まっている。 不満が「ちょっとした使い勝手」の範囲なら、切り替えのコストに見合わない可能性があります。
• 社内にITの運用体制がない。 フルスクラッチのシステムは、作って終わりではなく運用が続きます。保守を外注する場合でも、窓口となる担当者は必要です。
• 受発注の件数が月に数十件以下。 業務量が少ない場合、SaaSの定額料金のほうがトータルで安く済むことがほとんどです。

どちらか一方に偏っていれば判断しやすいですが、実際にはサインが混在しているケースが多いかと思います。その場合は、「SaaSでは対応できない業務上のボトルネックが、売上や顧客対応に影響しているか」を軸に考えると、優先度が見えてきます。

Next.js + Firestore で受発注データをどう設計するか？

切り替えを検討する際に気になるのが、「フルスクラッチで作るとして、受発注データはどう持つのか」という点です。ここでは、Next.js 16（App Router）と Firebase の Firestore を前提に、基本的なデータモデルの考え方を整理します。

状態遷移の基本：見積 → 受注 → 納品 → 請求

受発注業務の中核は、1件の取引が複数のステータスを経て進むという「状態遷移」です。Firestore では、この遷移を1つのドキュメントの status フィールドで管理するのが最もシンプルな設計です。

orders/{orderId}
  ├── status: "estimate" | "ordered" | "delivered" | "invoiced" | "paid"
  ├── customerRef: customers/{customerId}
  ├── items: [ { name, quantity, unitPrice } ]
  ├── totalAmount: number
  ├── estimateDate: timestamp
  ├── orderDate: timestamp | null
  ├── deliveryDate: timestamp | null
  ├── invoiceDate: timestamp | null
  ├── statusHistory: [ { status, changedAt, changedBy } ]
  └── ...メタ情報

statusHistory 配列を持たせることで、「誰がいつステータスを変更したか」の監査証跡を残せます。SaaSでは取れなかった粒度のログが自前で取れるようになる点は、フルスクラッチの利点の一つです。

Server Components で一覧画面を構成する

Next.js 16 の App Router では、Server Components がデフォルトです。受注一覧のような読み取り中心の画面は、サーバー側で Firestore からデータを取得し、組み立て済みのHTMLをブラウザに届けます。ブラウザに送る JavaScript の量が減るため、表示が速くなる傾向があります。

ステータスの変更ボタンやフィルター操作など、ユーザーの操作が必要な部分だけを Client Component として切り出します。この「サーバーで読み、クライアントで操作する」という分離が、受発注管理のように一覧表示と状態変更が混在する画面と相性が良い設計です。

Firestore セキュリティルールで権限を制御する

Firestore のセキュリティルールを使えば、「営業担当は自分が担当する案件のみ編集可能」「経理担当は請求ステータスのみ変更可能」といったアクセス制御を、アプリケーションコードとは別のレイヤーで定義できます。SaaSでは「管理者」と「一般ユーザー」の2段階しか選べなかった権限設計が、自社の組織構造に合わせて柔軟に組めるようになります。

受発注データの設計についてより広い視点で検討したい場合は、SaaS疲れの整理と判断軸をまとめた記事も参考になるかと思います。

SaaSを即解約しない——並行運用はどう進めるか？

フルスクラッチへの移行で最もリスクが高いのは、「SaaSを止めてから新システムに切り替える」という一括移行です。私たちゼットリンカーでは、1〜3ヶ月の並行運用期間を設けることを推奨しています。

並行運用の3ステップ

ステップ1：新システムで「見るだけ」を始める（最初の2〜4週間）

まず、SaaS側のデータを新システムに読み込み、一覧表示や検索ができる状態を作ります。日常業務はSaaSで続けつつ、新システムの画面で「同じデータが正しく見えるか」を現場のスタッフに確認してもらいます。この段階ではSaaSが正、新システムは参照用です。

ステップ2：新システムで「書く」を始める（次の2〜4週間）

新規の見積や受注を新システム側で入力し始めます。SaaSにも同じ内容を手動で転記する二重入力の期間になりますが、この手間は「万が一の保険」として必要なコストです。現場スタッフからの使い勝手のフィードバックを集め、画面やフローを調整します。

ステップ3：SaaSを「読むだけ」に切り替える（最後の2〜4週間）

新システムへの入力が安定したら、SaaS側は過去データの参照用として残しつつ、新規入力を停止します。この期間が問題なく過ぎれば、SaaSの解約を進めます。過去データはCSVエクスポートしておくか、必要に応じて新システム側にインポートします。

並行運用で見落としやすいポイント

• 請求サイクルをまたぐ。 月末締めの請求処理が新旧どちらのシステムでも正しく出力できることを、最低1サイクル分は確認してください。
• 権限設定のテスト。 SaaSでは問題なく使えていた操作が、新システムの権限設定で塞がれていることがあります。全ロールで一通り操作するテスト期間を設けます。
• データ移行は「全件」にこだわらない。 過去5年分の受注データすべてを移行しようとすると、それだけで数週間かかることがあります。「直近1年分＋それ以前はCSV保管」のように割り切ると、移行のスピードが上がります。

切り替えにいくらかかるか？——撤退の現実も含めて

「フルスクラッチは高い」という印象を持たれている方も多いかと思います。実際のところ、受発注管理システムの開発費用は要件によって大きく変わりますが、目安となるレンジをお伝えします。

コスト感のレンジ

SaaSの月額が数万円の場合、年間では数十万円になります。「SaaSを3年使い続けた場合の総額」と「フルスクラッチの初期開発費＋3年間の運用費」を並べて比較すると、判断材料になります。開発費用の考え方についてはこちらの記事でも整理しています。

撤退の現実

正直にお伝えすると、フルスクラッチへの移行が途中でうまくいかなくなるケースもゼロではありません。よくある原因は以下の通りです。

• 要件が膨らみすぎた。 最初は「受注管理だけ」のつもりが、「在庫管理も」「会計連携も」と広がり、開発期間とコストが当初見込みを超えてしまう。
• 現場の抵抗。 新しいシステムへの習熟コストを現場が受け入れられず、結局SaaSに戻る。
• 運用体制が整わなかった。 開発は完了したが、不具合対応や機能追加の体制が用意できず、放置されてしまう。

だからこそ、並行運用期間を設け、SaaSの契約を維持したまま段階的に移行することが重要です。撤退できる状態を保つことが、結果的に移行の成功率を上げます。

私たちゼットリンカーでは、最小MVPから数週間の短いサイクルで開発し、動くものを見ながら要件を固めていく進め方を採っています。「作ってみたら違った」というリスクを、短いサイクルの中で早期に検知する考え方です。

まとめ

受発注SaaSへの不満がワークフローの不一致やデータ出力の制約に起因するなら、Next.js + Firebase でのフルスクラッチは有力な選択肢です。ただし切り替えは一括ではなく、並行運用で安全に進めてください。最小MVPから始め、SaaSの解約は新システムの安定を確認してからにするのが鉄則です。

本記事は Next.js 16.x / Firebase（Firestore）時点の情報です。

次のステップを考えている方へ

「自社の受発注業務がフルスクラッチに向いているか」を整理するところから始めたい場合は、業務棚卸しの考え方をまとめたチェックリストもご覧ください。要件が固まっていなくても構いません。15分のカジュアル相談で、切り替えの方向性を一緒に整理できます。営業目的のご連絡はしません。

切り替えを検討する際は、開発会社から提示される見積もりの妥当性を見極める視点も欠かせません。金額の内訳や工数の考え方を確認したい方は、Next.jsシステム開発の見積もりを適正化する5つの観点もあわせてご覧ください。