システム開発をしない判断：SaaS/Excelで見分ける

この記事の要点

システム開発すべきか迷うときは、まず「システム開発をしない判断」も選択肢に入れるのが安全です。SaaS/Excelで十分な業務を見分け、過剰開発で使われない失敗を避ける判断基準と進め方を整理します。

システムを作らない選択肢も同じ条件で比較する

「この業務、システム開発した方がいいのか…」と迷う業務改善担当の方へ。結論から言うと、すべてをシステム開発する必要はありません。むしろ、SaaSやExcelで十分な業務にまで開発投資をすると、過剰開発で使われない・運用が回らない・追加改修が止まらないといった失敗が起きがちです。

意思決定で大事なのは「開発する／しない」の二択ではなく、どこまでを標準（SaaS/Excel）で回し、どこからを作るかの線引きです。この記事では、システム開発をしない判断を合理的に下すための見分け方と、判断の手順、チェックリスト、合意形成のコツまで整理します。

結論：開発すべきか迷ったら「目的・頻度・変化・責任」の4点で切り分ける

システム化の相談

フォーム、予約、CSV、会員機能などを業務に合わせて整理できます

システム開発は機能を増やすほど複雑になります。今ある業務フローを整理し、最初に作るべき範囲と後回しにする範囲を切り分けることが重要です。

• 手作業やExcel管理を減らしたい
• フォーム、予約、会員、CSV出力をつなげたい
• 小さく始められる開発範囲を決めたい

システム開発を相談する システム開発の詳細を見る

意思決定で最短回答を出すなら、次の4点で整理します。ここが揃うと、関係者との議論も噛み合います。

• 目的：売上・原価・品質・納期・法令対応など、経営インパクトが明確か（「何が良くなるか」が1文で言えるか）
• 頻度：毎日／毎週の繰り返しで、手作業コストが積み上がっているか（1回の手間より、累積の工数）
• 変化：業務ルールが頻繁に変わり、要件が固まっていないか（例外が増え続けていないか）
• 責任：ミス時の損失（顧客影響・監査・情報漏えい・返金）が重いか（統制が必要か）

このうち「目的が曖昧」「変化が多い」場合は、まずはSaaSやExcelで小さく回して仮説検証し、要件が固まってからシステム開発に進むのが安全です。逆に「責任が重い」「頻度が高い」業務は、早めに仕組み化した方がコストもリスクも下がります。

よくある失敗：過剰開発で使われないのは“設計”ではなく“判断”のミス

過剰開発の典型は、「現場の困りごと」を“理想の仕組み”で一気に解決しようとすることです。特に、現場の例外対応や暗黙知をそのまま仕様に落とすと、入力が重くなり、結果として使われなくなります。

• 入力項目が多すぎて現場が避ける（結局、Excelに逆戻り）
• 例外処理が多く、運用ルールが決まらないまま開発が進む（仕様が膨張する）
• 担当者が異動・退職し、仕様の背景が引き継がれない（「なぜこうしたか」が不明）
• 周辺業務（マスタ整備、権限設計、教育、運用監視）が抜け落ちる（運用の穴）
• 「便利機能」を積み上げて、完成が遅れる（リリースが遠のくほど現場の熱が冷める）

「開発したのに使われない」は、技術力不足というより、システム開発をしない判断が必要な領域に踏み込んだケースが多いです。まずは“使われる最小構成”を定義し、それ以外はSaaS/Excel/運用で吸収できないかを検討します。

開発前に既存ツールと運用変更で検証する場面

特に次のような状況では、いきなりシステム開発を始めるより、作らない前提で整理した方が成功率が上がります。

• 業務フローがまだ定着していない（部門ごとにやり方が違う、責任分界が曖昧）
• 例外が多い（イレギュラーが多く、標準フローが見えない）
• 成果指標が曖昧（「便利そう」だけで、改善目標が数字になっていない）
• 関係者が多い（合意形成に時間がかかる。まずは小さく試した方が早い）

この場合の勝ち筋は、ExcelやSaaSで“仮運用”を作り、データを溜めて、変化のパターンを把握してから要件化することです。「何を作るか」より先に、「何が決まっていないか」を洗い出すことが重要です。

SaaSが候補になる業務の特徴

SaaSで十分な業務は、すでに市場で“型”が確立しています。代表例は、勤怠、経費、ワークフロー、請求、CRM、問い合わせ管理、在庫、スケジュール管理などです。次に当てはまるほどSaaS向きです。

• 業務が業界標準に近く、特殊ルールが少ない（「独自仕様」より「設定」で解決できる）
• 法改正・制度変更に追随する必要がある（自社開発だと追従コストが高い）
• 複数拠点・複数担当で使い、権限管理や監査ログが必要（統制の要求が強い）
• 外部連携（会計、給与、メール、チャット、API）が前提（つなぐほど価値が出る）
• 運用の属人化を避けたい（担当者が変わっても回る仕組みにしたい）

逆に、SaaSの設定で吸収できない固有ルールが多いなら、まずは「何が固有なのか」を棚卸しします。固有要件の多くは、業務ルールの未整理や、過去経緯による例外運用が原因であることも多いです。先に運用を整えれば、SaaSで吸収できる範囲が広がることがあります。

Excelを継続できる条件と卒業する条件

Excel（またはスプレッドシート）で十分な業務は、要件が未成熟で、まずは業務の形を作るフェーズに向きます。目安は次の通りです。

• 利用者が少人数（1〜5名程度）で、責任範囲が限定的
• 処理頻度が低い／月次などで、運用の負担が致命的でない
• 項目や計算式が頻繁に変わる（仕様が固まっていない）
• 例外が多く、現場の判断が入り続ける（「判断基準」がまだ共有されていない）

この段階でのゴールは「完璧な仕組み」ではなく、判断基準の共通化と、データが溜まる状態を作ることです。Excel運用を成功させるコツは、ツールより運用です。

• 入力責任者（誰が最終確定するか）
• 更新タイミング（毎日/週次/締め）
• 版管理（ファイルを増やさず、1つを正にする）
• 例外の記録（例外が増えるほど“後で作る要件”の材料になる）

Excelが破綻するのは「大きくなったから」ではなく、ルールがないまま人と版が増えるからです。最初からルールを入れると、Excelでも十分に戦えます。

開発・SaaS・Excelを比較する3ステップ

1. 現状コストを“時間×回数×人数”で見える化する

「手間がかかる」は主観になりがちです。1回あたりの作業時間、月の回数、関与人数を掛け合わせ、月間工数を出します。加えて、繁忙期のピーク（締め作業など）も別で見積もると、ボトルネックが見えます。

例えば「1回15分×1日20回×2人×20営業日」なら、月200時間。ここまで出ると、SaaS/Excel/開発の投資判断が一気にしやすくなります。

2. 失敗コスト（ミスの損失）とリスクを整理する

入力ミスが売上・請求・顧客信頼に直結する業務は、多少コストをかけても統制が必要です。一方で、ミスしても社内でリカバリーできる業務は、まずは運用改善で十分な場合があります。

• 金銭損失：誤請求、返金、再配送、残業増
• 信用損失：顧客クレーム、取引停止、口コミ
• コンプラ：監査指摘、個人情報、権限漏れ

この整理があると、「便利だから作る」から「守るために整備する」に論点が変わり、合意が取りやすくなります。

3. 「分ける」発想で最小構成を決める

全部を一気に作らず、基幹はSaaS、現場の表はExcel、つなぎ目だけ小さく開発のように分けると、過剰開発を避けられます。最初の開発は“自動化より可視化”を優先すると、運用が安定しやすいです。

具体的には、最初のゴールを「入力を完璧にする」ではなく、次のどれかに寄せます。

• 状況が分かる（一覧化・ステータス管理）
• ミスが減る（入力チェック・必須項目・権限）
• 連絡が減る（通知・締め・承認の導線）

こうすると、現場が“使う理由”が生まれ、段階的に改善できます。

判断の補助線：スコアリングで“作る/作らない”を数字にする

議論が平行線になりやすい場合は、簡易スコアリングが有効です。5段階で点を付け、合計点で方向性を決めます。

• 頻度：日次5点／週次3点／月次1点
• 手戻り：再作業が多いほど高得点
• 責任：顧客影響・監査が重いほど高得点
• 変化：変化が多いほど低得点（まずはExcel/SaaSで固める）
• 標準化：業界標準に近いほどSaaS寄り

合計が高いのに変化が少ないなら「作る」へ、合計が低いか変化が高いなら「作らない（まずはSaaS/Excel）」へ。数字は正確さより、論点の共通化に役立ちます。

チェックリスト：システム開発をしない判断を後悔しないために

• 業務の目的（何を良くするか）が1文で言える
• 現状の月間工数（時間×回数×人数）を出している
• 繁忙期・締め処理のピーク負荷も把握している
• 要件変更がどのくらいの頻度で起きるか把握している
• 例外処理のパターンが洗い出せている
• 「SaaSで代替できる機能」と「固有要件」を分けている
• Excel運用の場合、入力責任者・更新ルール・版管理を決めている
• ミス時の損失と、必要な統制（権限・ログ・監査）を整理している
• まず作るなら“最小構成（MVP）”で合意できている
• 導入後の運用（教育・サポート・改善サイクル）の担当を決めている

よくある質問

Q. どの段階で「Excel卒業＝システム開発」に進むべきですか？

目安は、①利用者が増えて版管理が破綻し始めた、②入力ミスが顧客影響に直結する、③毎週の作業が固定化して改善余地が小さくなった、のいずれかが明確になった時です。データ項目と業務フローが安定しているほど、開発は速く・安く・失敗しにくくなります。

Q. SaaSを入れたのに現場が使ってくれません

多くは「入力の動機」と「運用ルール」が不足しています。まずは、入力しないと困る仕組み（承認、通知、締め処理）を運用で作り、最初は項目を絞ってスタートします。現場が慣れたら段階的に項目を増やす方が定着します。導入初期は“完璧”より“継続”が勝ちです。

Q. 部分開発（つなぎ目だけ開発）はどんな時に有効ですか？

基幹はSaaSで十分だが、CSVの整形・集計・二重入力など「最後のひと手間」だけが重い時に有効です。ここを小さく自動化すると、費用を抑えつつ効果が出やすくなります。特に、帳票出力や一括登録、通知などは小さく作って効果が出やすい領域です。

Q. 社内で判断が割れて合意形成できません

目的（KPI）と、現状コスト、失敗コストの3点を同じフォーマットで並べると、感情論が減ります。判断材料を揃えた上で「まずは3ヶ月、SaaS/Excelで試す」など期限付きの意思決定にすると進みやすいです。結論を先延ばしにするのではなく、学びを増やすための“試す”を決めるのがポイントです。

Q. 「作らない」場合でも、業務改善の成果は出せますか？

出せます。むしろ、入力項目の削減、責任分界の明確化、例外処理のルール化などは、開発前にやるほど効果が出ます。SaaS/Excelで回しながら、必要な部分だけ作る方が、スピードと定着の両方を取りやすいです。

まとめ：迷ったら“作らない前提”で整理し、必要なところだけ作る

システム開発は強力ですが、万能ではありません。システム開発をしない判断を入れることで、投資を最適化し、現場が使い続ける仕組みに近づきます。迷ったら「目的・頻度・変化・責任」の4点で切り分け、SaaS/Excelで回る領域と、作るべき最小構成を分けてください。

もし「SaaS/Excelで回るのか」「部分開発が必要か」「要件整理から手伝ってほしい」など、判断材料の整理が必要なら、まずは現状の棚卸しだけでもOKです。スポット相談でも対応可能なので、切り分けから一緒に進められます。

システム化の相談

フォーム、予約、CSV、会員機能などを業務に合わせて整理できます

システム開発は機能を増やすほど複雑になります。今ある業務フローを整理し、最初に作るべき範囲と後回しにする範囲を切り分けることが重要です。

• 手作業やExcel管理を減らしたい
• フォーム、予約、会員、CSV出力をつなげたい
• 小さく始められる開発範囲を決めたい

システム開発を相談する システム開発の詳細を見る