Webシステム発注初心者ガイド
第2話
まずSaaSを使えばいいんじゃないか
まず「既製品」を探す
「ゼロから作る前に、既存サービスを使えないか調べる」――これは鉄則だ。
検索してみると、見積管理・営業支援のSaaSはいくつも出てきた。月額数千円〜数万円のものが多く、初期費用ゼロのものもある。
- Aサービス：見積書作成・PDF出力・承認フロー対応。月額9,800円〜
- Bサービス：CRM連携が強み。見積機能もあり。月額15,000円〜
- Cサービス：中小企業向けシンプル設計。月額4,980円〜
「あれ、もうこれで解決じゃないですか？」とまず思った。
SaaS（サース） は「Software as a Service」の略で、インターネット越しに使えるソフトウェアサービスのことだよ。インストール不要で、ブラウザさえあればどこからでも使えるんだ。
クラウドはもう少し広い概念で、「インターネット経由でITリソース（サーバー・ストレージなど）を使う仕組み」全般を指す。SaaSはクラウドの一形態だね。
| 種類 | 内容 | 例 |
|---|---|---|
| SaaS | ソフトウェアをそのまま使う | Gmail、Slack、freee |
| PaaS | 開発環境を借りる | Heroku、Vercel |
| IaaS | サーバーを借りる | AWS EC2、GCP |
今回検討してるのはSaaSの話。「すぐ使える完成品」をイメージしてみてね。
デモを試してみた
AとCの2サービスは無料トライアルがあったので、実際に申し込んで営業部の先輩と一緒に触ってみた。
画面はきれいで、見積書の作成自体はスムーズだ。品目を入力して、単価を入れて、数量を掛けると合計が出る。PDFもワンクリックで出力できる。
「おお、いい感じじゃないですか」と先輩も言っていた。
気持ちはわかる！でも、「デモで動く」と「自社の業務で使える」は別物なんだよね。
大事なのは「自社の業務フローに合うかどうか」を確認することだよ。特に今回のケースで確認したいのはこの3つ：
- 社内の製品マスターDBと連携できるか
- 自社特有の承認フローに対応できるか
- 顧客ごとの単価設定ができるか
実際に試してみよう。
壁その1：製品データベースとつながらない
自社には、品番・品名・定価・仕入れ価格が登録された製品マスターDBがある。基幹システムの中に入っていて、在庫管理や発注にも使われている。
「製品マスターと自動連携できますか？」とサポートに聞いてみると、
「APIを使えば連携は可能ですが、開発が必要になります。別途お見積りとなります」
API（Application Programming Interface） は、システム同士が会話するための「窓口」のことだよ。
レストランで例えると、あなた（アプリ）がメニューを見て注文するとき、ウェイター（API）が厨房（データベース）に注文を伝えて料理を持ってくる、というイメージだね。
SaaSが「APIで連携できます」と言うのは「窓口は用意してあるけど、つなぐ工事はあなたがやってね」という意味なんだ。その工事（開発）には別途費用と時間がかかる。
壁その2：承認フローが自社に合わない
次に、承認フローを設定しようとした。
自社の承認フローはこうだ。
- 担当営業が作成
- 営業リーダーが確認（100万円以上の案件のみ）
- 営業部長が承認
- 3,000万円以上は役員決裁が必要
「金額によって承認ルートが変わる」のがポイントだ。SaaSの承認フロー機能は「全件：上長→部長の2段階」が標準で、条件分岐は上位プランのみ対応、しかもルートのパターン数に制限があった。
上位プランは月額3倍以上になることが多いんだよね。8人分だと年間コストがかなりの額になる。
さらに問題なのは「上位プランでも条件分岐のパターンが最大5種まで」みたいな制限がある場合だよ。今後、承認ルールが変わったり、ルートが増えたりしたときに、またサービスが対応できなくなるリスクがある。
SaaSは「多くの会社で使える汎用設計」だから、自社特有のルールへの対応に限界があるのは構造的な問題なんだ。
壁その3：顧客ごとの単価が設定できない
最後に、得意先ごとの単価設定を試みた。
自社では顧客ごとに掛率（例：A社は定価の85%、B社は80%など）が決まっており、さらに特定品番については個別の特別価格が設定されているケースもある。
SaaSの品目マスターは「1品番に1定価」が基本設計で、顧客ごとの掛率を自動適用する機能はなかった。手動で都度計算する運用ならできるが、それは今と変わらない。
理論上はできるよ。でも冷静に計算してみよう。
- SaaSの月額費用（継続的にかかる）
- API連携開発費用（初期費用）
- 承認フロー改修費用（初期費用）
- SaaSのアップデートで仕様が変わるたびに連携部分が壊れるリスク
これを合計すると、最初からカスタム開発した方が安くなるケースが多いんだ。特に「自社特有のルールが複数ある」場合は、SaaSのカスタマイズ路線は割高になりやすいよ。
SaaSを断念、カスタム開発へ
結果として、3つのサービスすべてで「自社の要件を満たすには追加開発が必要」という結論になった。
上司に報告すると、「わかった。じゃあ作ろう」と即断だった。
こうして、見積書システムのカスタム開発が正式に動き出した。
ただ、ここで新たな問題が浮上する。「どこまでの機能を作るか」という範囲の話だ。
大きく3つの選択肢があるよ。
- システム開発会社（SIer）：要件定義から開発・テスト・保守まで一括で請けてくれる。費用は高めだが安心感がある
- Web制作会社：デザインが得意。比較的小規模なWebシステムなら対応できるところも多い
- フリーランスエンジニア：コストを抑えやすいが、管理の手間がかかる
今回のような「基幹システムとの連携あり・承認フローあり」のシステムは、実績のあるシステム開発会社に相談するのが無難だね。次回は、「まず何を作るか」の範囲を決める話をしていくよ。