課題が決まり、業務も整理できた。いよいよ実現手段を選ぶ段階です。
ここで多くの会社が、いきなり「システム開発会社に相談する」か「SaaSを探す」の二択で考え始めます。
しかし実際には、業務課題を解決する手段は7つあります。
そして、その多くはシステム開発より安く、速く、後から変えやすい方法です。
この記事では、7つの選択肢を並べて比較し、どういう条件でどれを選ぶかを整理します。小さく始める考え方については、中小企業のDXは小さく始める｜試験導入から横展開までの進め方をご覧ください。
解決手段は「作る」だけではない
まず、選択肢の全体像を並べます。
| 手段 | 費用の目安 | 導入期間 | 自由度 |
|---|---|---|---|
| 1. 今のExcelを改善する | ほぼゼロ | 即日〜数日 | 低い |
| 2. クラウド表計算へ移す | 月数百円／人 | 数日〜2週間 | 低い |
| 3. ノーコードツール | 月数千円〜数万円 | 2週間〜2か月 | 中 |
| 4. SaaS（クラウドサービス） | 月数千円〜数万円／人 | 1〜3か月 | 中 |
| 5. パッケージソフト | 数十万〜数百万円 | 2〜6か月 | 中 |
| 6. 既存システムをつなぐ | 数十万〜数百万円 | 1〜4か月 | 中 |
| 7. スクラッチ開発 | 数百万円〜 | 4か月〜1年 | 高い |
下に行くほど自由度が上がり、費用と期間も増えます。
大事なのは、自由度が高いことは、必ずしも良いことではないという点です。自由度が高いほど、決めるべきことが増え、判断の責任も自社に返ってきます。
なお、SaaSとスクラッチ開発の費用を5年間の総額で比較した記事もあります。金額面を詳しく検討したい場合は、【5年間コスト比較】SaaSパッケージ vs スクラッチ開発｜費用と柔軟性の真実をご覧ください。
7つの選択肢の向き・不向き
1｜今のExcelを改善する
最も軽視されている選択肢です。
入力規則を設定する、シートを分ける、不要な列を消す、集計を関数で済ませる。これだけで解決する課題は実際にあります。
- 向いている：使う人が数名、件数が月数百件まで、社内で完結する業務
- 向いていない：同時に複数人が編集する、履歴を追う必要がある、社外と共有する
2｜クラウド表計算へ移す
ファイルをクラウド上の表計算サービスへ移すだけで、「同時編集できない」「最新版が分からない」という問題は解消します。
費用はほぼかからず、操作感も大きく変わりません。Excelの限界のうち、共有まわりだけが問題なら最有力候補です。
- 向いている：共有と同時編集が主な課題、拠点が分かれている
- 向いていない：データ量が多い、入力ミスを構造的に防ぎたい、権限を細かく分けたい
3｜ノーコード・ローコードツール
プログラムを書かずに、画面や入力フォーム、簡単な業務の流れを組み立てられるサービスです。
自社で作り、自社で直せるのが最大の利点です。ただし、社内に触れる人がいないと、結局動かなくなります。
- 向いている：自社に少しITに強い人がいる、業務の変化が速い、まず試したい
- 向いていない：複雑な計算や連携がある、扱う件数が非常に多い、担当が完全に不在
4｜SaaS（クラウドサービス）
月額で使う既製のサービスです。会計、勤怠、販売管理、予約など、分野ごとに多数あります。
すぐ使え、機能追加も自動で行われます。まずここで足りるかを確認するのが基本です。
- 向いている：一般的な業務、標準的な進め方に合わせられる、早く始めたい
- 向いていない：自社独自の流れが多い、他システムとの連携が複雑、利用人数が多くて月額が膨らむ
SaaSで対応しきれなくなる典型的なパターンは、kintoneで「これができない」は危険サイン｜中小企業が陥るSaaS限界の7パターンにまとめています。
5｜パッケージソフト
業界向けに作り込まれた既製システムを導入し、設定やカスタマイズで自社に合わせます。
業界特有の帳票や商習慣に最初から対応している点が強みです。
- 向いている：業界標準の業務に近い、法制度への対応を任せたい
- 向いていない：カスタマイズが多くなりすぎる、更新のたびに追加費用が発生する
注意点として、カスタマイズ費用が本体価格を超え始めたら、方式の選び直しを検討すべきサインです。
6｜既存システムをつなぐ
今あるものを作り替えず、間をつなぐ方法です。
システム同士を連携させる、繰り返し作業を自動化する、といった手段があります。今のシステムに大きな不満がなく、つなぎ目だけが問題なら有力です。
- 向いている：個別のシステムは使えている、転記作業だけが負担になっている
- 向いていない：元のシステム自体が古くて限界、つなぐ相手が連携に対応していない
7｜スクラッチ開発
自社の業務に合わせて専用に作る方法です。
費用も期間もかかりますが、他の6つで解決できない課題は、これでしか解決できません。
- 向いている：業務の流れが独自、複数の立場が絡む、高いセキュリティ要件がある、事業の中核そのもの
- 向いていない：一般的な業務、要件が固まっていない、社内に判断できる人がいない
選ぶ順番｜上から順に検討する
7つの選択肢は、上から順に「できない理由」を探していくのが正しい進め方です。
いきなり7番から検討すると、本来1番で済んだ課題に数百万円をかけることになります。
| 検討する順 | 問い | 次へ進む条件 |
|---|---|---|
| 1. Excel改善 | 今のやり方の工夫で足りるか | 同時編集・履歴・件数で無理がある |
| 2. クラウド表計算 | 共有の問題だけか | 入力ミスや権限の問題が残る |
| 3. ノーコード | 自社で作って直せるか | 触れる人がいない、複雑すぎる |
| 4. SaaS | 既製サービスで足りるか | 独自の流れに合わない |
| 5. パッケージ | 業界向け製品で足りるか | カスタマイズ費が膨らむ |
| 6. 連携・自動化 | 今あるものをつないで済むか | 元のシステムに限界がある |
| 7. スクラッチ | ここまで来たら開発を検討する | — |
この順番で検討すると、スクラッチ開発を選ぶ場合も「なぜ他ではだめなのか」を説明できる状態になります。
これは社内の稟議でも、開発会社との打ち合わせでも、極めて強い材料になります。
判断を分ける4つのポイント
どこで線を引くか迷ったときは、次の4点を見てください。
| 観点 | 軽い側 | 重い側（開発が必要になりやすい） |
|---|---|---|
| 件数 | 月数百件まで | 月数千件以上、または急増する |
| 独自性 | 他社と同じやり方でよい | 自社固有の商習慣・計算ルールがある |
| 関係者 | 社内だけで完結 | 取引先・外部専門家など複数の立場が絡む |
| 記録の要件 | 今の状態が分かればよい | 誰がいつ何をしたかを残す必要がある |
3つ目の「関係者」は特に判断を分けます。
社内だけなら既製サービスで足りることが多いのですが、社外の相手が同じ画面を使う場合、権限の設計や見せる範囲の制御が必要になり、既製品では対応しきれないことが増えます。
【事例】既製品では要件を満たせなかったケース
医療機関どうしで検査装置の空き枠を融通し合う、予約プラットフォームの事例です。
「予約システム」と聞くと、既製のサービスで足りそうに思えます。しかし、この案件では次の条件が重なっていました。
- 1つの組織が「依頼する側」と「引き受ける側」の両方の立場を持つ。同じアカウントで両方の運用ができる必要があった
- 予約する本人がログインしない。医療機関のスタッフが代理で入力する業務フローだった
- 傷病名や既往歴といった要配慮個人情報を扱う。一般的な予約システムと同じ水準では要件を満たせなかった
- 検索の単位が行政区分ではなかった。医療業界の実務で使われる地域区分に合わせる必要があった
結果として、二要素認証を全機能の前提に置き、情報を暗号化して保存し、全操作の記録を残す構成で開発しています。
「複数の立場」「代理入力」「高いセキュリティ要件」「業界固有のルール」——この4つが重なると、既製品では届かなくなります。
逆にいえば、これらが当てはまらない業務は、既製サービスで足りる可能性が高いということでもあります。
この事例の詳細は、以下のページでご覧いただけます。
手段選びでよくある失敗
最初から「開発ありき」で相談する
開発会社に「システムを作りたい」と相談すれば、作る前提の話が進みます。
相談するなら、「この課題を解決したい。方法は問わない」と伝えてください。信頼できる会社であれば、既製サービスで足りる場合はそう言います。
月額費用を人数で掛け算していない
1人あたり月3,000円のサービスも、50人で使えば年間180万円です。
数年使えば開発費を上回ることもあります。利用人数が多い場合は、5年分の総額で比べてください。
「あとでカスタマイズすればいい」と考える
既製品のカスタマイズは、できる範囲が決まっています。
導入後に「そこは変えられません」と言われるケースは非常に多く、しかもその時点では引き返せません。絶対に譲れない条件は、契約前に実機で確認してください。
データを外に出せるか確認していない
将来、別の方法へ移る可能性は必ずあります。
そのとき、蓄積したデータを取り出せないと乗り換えられません。どの手段を選ぶ場合も、データの書き出し方法を最初に確認しておいてください。
明日からできる3つのこと
- 今の課題に、1番から順に当てはめてみる
「なぜExcel改善では解決しないのか」を言葉にできるか試します。 - 件数・独自性・関係者・記録要件の4点を書き出す
重い側にいくつ当てはまるかで、必要な手段の重さが分かります。 - 候補のサービスでデータ書き出しができるか調べる
公式サイトの仕様ページか、問い合わせで確認できます。
よくある質問
複数の手段を組み合わせてもいいですか？
むしろ、それが現実的な形です。
会計は既製のサービス、独自性の高い受注管理だけ開発、その間を連携でつなぐ。中小企業ではこうした組み合わせがよく採用されます。
すべてを1つのシステムに統合しようとすると、かえって高くつきます。
ノーコードで作ったものは、後で作り直しになりますか？
作り直しになることはありますが、無駄にはなりません。
実際に使ってみることで、必要な項目や業務の流れがはっきりします。それ自体が、次の要件定義の材料になります。
どの手段が良いか、社内で判断できません
判断に必要なのは技術知識ではなく、自社の業務条件を正確に説明できることです。
件数、関係者、独自ルール、記録の必要性。これらを整理して相談すれば、外部の専門家でも判断できます。逆にここが曖昧だと、誰に聞いても答えは出ません。
まとめ｜安い手段から順に、できない理由を探す
- 解決手段は7つある。開発は最後の選択肢
- 上から順に「できない理由」を探すと、過剰投資を避けられる
- 件数・独自性・関係者・記録要件の4点で重さを判断する
- 利用人数が多い場合は、月額を5年分で比較する
- どの手段でも、データを取り出せるかを先に確認する
手段が決まったら、次は何を作るのかを具体的に決める段階です。
ここでよくある失敗が、「こんな画面が欲しい」から始めてしまうこと。次回は、要件を3つの層に分けて整理する方法を扱います。
経営課題の整理から、業務の見直し、システムの選定・導入・定着、効果測定、継続的な改善まで。中小企業がDXを進める一連の流れを14回に分けて解説しています。
みんなシステムズでは、手段が決まっていない段階からのご相談を歓迎しています。「開発すべきか、既製サービスで足りるか」の判断からお手伝いできますので、お気軽にお問い合わせください。
