業務システムはSaaSで十分？個別開発と迷ったときの選び方

その独自ルールは、事業に必要なものですか

説明用の例として、訪問作業を請け負う会社を考えます。顧客名や連絡履歴の管理は一般的でも、採算には移動費、再訪問、未使用部材の戻しまで含めたいとします。この計算が受注判断に欠かせないなら、製品に合わせてなくすのは難しいでしょう。一方、申請をメールで送り直す慣習まで残す必要があるとは限りません。

ここで分けたいのは、必要な結果と慣れた方法です。「担当者別の原価が分かる」は必要な結果で、「今の表と同じ列順」は方法です。方法を変えられる部分が多ければ、SaaSの設定と業務の見直しで解決する余地があります。個別開発でもこの整理をしておくと、使われていない機能まで再現する費用を避けやすくなります。

選択肢は、買うか作るかの二つだけではない

既存サービスで顧客情報を管理し、案件の採算計算だけを個別開発する方法もあります。全部を作らずに必要な機能を補える反面、顧客の統合や案件の取消を双方に反映する連携が増えます。部分開発が小さいからといって、運用全体まで単純になるとは限りません。つなぐ部分を誰が直すかも費用と一緒に考えます。

次の表は、方式ごとの得意な条件を比べたものです。SaaSには設定や拡張があり、個別開発にも外部サービスの制約があります。製品名や技術名だけで決めず、「この仕事が終わったとき、誰に何が残るか」を候補ごとに書くと、自社の体制に合う案を探せます。

表が収まらない場合は横にスクロールできます。

デモでは、きれいに終わらない一件を試す

通常の登録ができても、取引が途中で変わったときに仕事が増えることがあります。先ほどの説明用の例なら、訪問後に追加作業が決まり、請求済みの案件へ原価を追加する場面です。自社の担当者に触ってもらい、どこまで自分で直せるか、何を別の表へ転記するかを観察します。候補ごとに同じ入力と訂正を試すことが大切です。

結果は「できた」でまとめず、標準機能でできたのか、設定したのか、別料金の拡張が必要なのかを分けます。月に一度だけの例外を人が処理する案もあり得ますが、その作業を担当する人と記録先が必要です。提供元に操作してもらうだけでは分からない負担があるため、採用予定のプランで試せる機会を求めましょう。

「APIあり」でも、必要な連携ができるとは限らない

SaaSにAPIがあっても、必要な項目を更新できるか、添付や履歴を取り出せるかは別の確認です。大量のデータを一度に送る場合には制限もあります。Microsoft Dataverseの公式資料では、サービス保護による429応答に待機時間が示されます。このような制約を調べずに月末集計を計画すると、通常日は動いても締めに間に合わない構成になり得ます。

併用を選ぶ場合は、項目ごとに正しい値を決める場所を揃えます。顧客の連絡先はSaaS、案件別原価は独自システム、と分けると説明しやすくなります。双方から同じ情報を自由に更新すると、古いデータで訂正を消すことがあります。初回のデータ取り込みと、停止後に未反映分を取り戻す作業まで、試作で確かめたい部分です。

参考：Microsoft Learn：Service protection API limits

月額と開発費を、そのまま比べない

比較する期間、人数、業務範囲を揃え、導入設定、移行、教育、利用料、連携の保守、改修を並べます。SaaS利用料が小さくても、毎日別の表で数字を合わせるなら社内作業が残ります。個別開発も初期費用で終わらず、業務変更や環境更新の費用が必要です。将来の人数を一つに決め打ちせず、現状と部門追加時を分けると変動要因が見えます。

ダンドリの業務システム・Webサービス開発の公表料金は80万円〜、設計・開発の料金基準は1人月160万円、160時間換算です。SaaS製品の平均相場や特定機能の定額ではありません。外部サービス利用料は別途必要で、機能、移行、連携の内容から個別に見積もります。同じ範囲で比較したうえで、予算が合わなければ初期対象をどこまで絞るかを検討します。

使い始めた後と、使うのをやめる日も考える

クラウド側で基盤を運用しても、自社の業務判断は残ります。Microsoftの責任共有モデルでも、SaaSのデータ、設定、利用者管理は利用者側の責任に含まれます。退職者のアクセスを止める、誤った取引を訂正する、承認者を変えるといった仕事を担える人が必要です。管理担当を置けない問題は、導入方式を変えるだけでは解決しません。

最後に、契約を終えるときに何を取り出せるかを試します。CSVの出力ができても、添付、変更履歴、データ同士を結ぶIDがなければ、次の仕組みへ移す調査が必要です。個別開発ではコードや設定、データ定義の引き継ぎ範囲を確かめます。候補の提案を比べる際は、導入後に残る制約まで説明してくれるかを見てください。

参考：Microsoft Learn：Shared responsibility in the cloud

検討・発注前のチェックリスト

担当者と確認状況を添えて、社内の検討メモや打ち合わせの議題にご活用ください。

確認日：________________ / 担当者：________________

• □残す必要がある独自ルールを、その理由とともに選ぶ。確認状況・メモ：
• □取消や締め後訂正を含む一件を各候補で試す。確認状況・メモ：
• □利用予定のプランに必要機能が含まれるか確かめる。確認状況・メモ：
• □追加開発を行う場合は、更新元と障害時の担当を揃える。確認状況・メモ：
• □比較期間と人数を揃え、社内作業も費用表に残す。確認状況・メモ：
• □履歴・添付・IDを含むデータの取り出しを試す。確認状況・メモ：

よくある質問

参考資料

製品の仕様・提供条件は変更されることがあります。採用時には公式資料と契約内容をご確認ください。

• Service protection API limitsMicrosoft Learn
• Shared responsibility in the cloudMicrosoft Learn