SaaSを解約して自作する時代に、企業が見落としてはいけない「導入責任」

Claude Code や ChatGPT のようなAIを使って、業務をよく理解している人が、自分でアプリや業務システムを作る流れが現実的になってきました。以前であれば、要件を整理し、開発会社に伝え、時間と費用をかけて作るしかなかったものが、今は業務の知見を持つ本人が、かなりの速度で形にできるようになっています。

この変化は大きいと思います。

実際、私の周りでも、自分でアプリやシステムを作る方が増えています。しかも、単に社内で使うだけでなく、完成したものを今後は販売したいと考えている方もいます。たとえば、自分の会社にぴったり合う顧客管理システムを作り、その使いやすさや手応えから、「これは他社にも提供できるのではないか」と考える。そうした流れは、もう珍しいものではなくなってきました。

これは自然な動きです。

既存のSaaSやパッケージには、どうしても限界があります。機能が多すぎる、自社には合わない、細かな運用がずれる、現場の動きに沿っていない。その結果、現場では「便利なはずなのに、結局使いにくい」ということが起きます。そこに対して、実務を分かっている人が、自分の課題を起点に仕組みを作るのですから、使いやすいものが生まれやすいのは当然です。

自作システムが既存のSaaSを置き換えていく流れ自体は、今後さらに進むでしょう。既存サービスにとっては厳しい時代ですが、利用者にとっては健全な競争でもあります。高い、遅い、合わない。そうしたものは、今後ますます見直されるはずです。

しかし、ここで一つ、かなり重要なことがあります。

自分のために作ることと、企業に導入することは別です。
動くことと、安心して預けられることも別です。
便利であることと、継続して運用できることも別です。

この違いを甘く見ると、提供する側も、導入する側も、あとで大きな負担を抱えることになります。

自分のためのシステムであれば、多少荒くても成立します。困るのは基本的に自分です。仕様が曖昧でも、自分の頭の中に補完があります。不具合が出ても、自分で直せば済みます。運用ルールがきれいに文書化されていなくても、現場の慣れで回ることもあるでしょう。

しかし、他社に販売する、あるいは社内の正式な業務システムとして導入する段階になると、論点は一気に変わります。

そこで問われるのは、画面の出来や機能数ではありません。
本当に問われるのは、導入後に責任を持てるかどうかです。

誰が保守するのか。
障害時に誰が初動対応するのか。
データはどこに保存されるのか。
バックアップはあるのか。
復元は実際にできるのか。
アクセス権限は適切か。
ログは取れているか。
利用者が増えたときに性能は維持できるか。
法務や契約の観点で責任分界は整理されているか。
開発者本人が離れたあとも継続できるか。

要するに、企業が見るべきなのは「作れたか」ではなく、「預けられるか」です。

ローカルで動くことと、社内サーバやクラウドで安全に運用できることは別

特に強く言いたいのが、「自分のパソコンで動く」ことと、「社内サーバやクラウドで安全に運用できる」ことは、まったく別の難しさだという点です。

自分のローカル環境で動くのであれば、外部公開はされていないかもしれませんし、利用者も限定されます。データ量も小さく、アクセス条件も単純です。ところが、これを社内サーバやクラウドへ移し、複数人が日常的に使うようになると、考えるべきことが急に増えます。

認証は十分か。
パスワード運用は適切か。
権限設計は業務に沿っているか。
通信は暗号化されているか。
ファイル保存先やデータベースへのアクセス制御は適切か。
管理画面が不用意に外部へ開いていないか。
ログイン試行や不正アクセスへの対策はあるか。
バックアップ取得の頻度は妥当か。
障害時の復旧手順は整っているか。
クラウド設定の誤りで情報が露出しないか。
アップデート時に既存データを壊さないか。
将来のデータ増加や高アクセスに耐えられるか。

このあたりは、ローカルでは見えにくい問題です。しかし、企業で導入されるシステムにとっては、むしろ本体はこちらです。

たとえば顧客管理システムであれば、顧客名、担当者名、メールアドレス、電話番号、商談履歴、見積情報、案件の進捗、場合によっては契約情報や請求に近い情報まで扱うことがあります。つまり、便利な業務ツールであると同時に、漏えいしてはいけない情報の集積でもあります。

ここで「使いやすいから」「自社にぴったりだから」「価格が安いから」という理由だけで導入を決めるのは危険です。導入企業が本当に買っているのは、画面や機能ではありません。業務を預けても大丈夫な体制と、その責任です。

AIは実装を助けるが、責任までは代わらない

AIは、ここでも大きな助けになります。実装も速くなりますし、改善案やセキュリティ対策の候補も出してくれます。負荷対策の方向性も示してくれるでしょう。しかし、AIに指示したからといって、それで導入責任が自動で満たされるわけではありません。

何を守るべきか。
どのリスクを重く見るべきか。
どこまで試験するべきか。
どの障害を許容し、どの障害を許容しないか。
どの範囲までサポートを約束するのか。
契約終了時にデータをどう返すのか。
提供者が止まったとき、利用企業はどう業務を継続するのか。

この判断は、最後は経験と運用の知見の問題です。ここを持たずに「動いたから売る」「売れそうだから導入する」と進めるのは、かなり危ないです。

最初の成功体験が、いちばん危ない

特に、最初の成功体験は判断を鈍らせます。

自分で使って便利だった。
知り合いにも使ってもらって好評だった。
少額でも売れた。
すると、そのまま事業化できるように見えてきます。

しかし、1社でうまくいくことと、10社でうまくいくことは違います。10社でうまくいくことと、50社、100社でうまくいくことはさらに別です。利用者が増えれば、問い合わせも増えます。例外運用も増えます。データ量も増えます。権限パターンも増えます。障害時の影響範囲も広がります。

この段階になると、求められるのはコードを書く力だけではありません。運用設計、監視、障害対応、サポート、契約、変更管理、データ移行、責任分界の整理。そうした地味で重たい部分が、一気に中心へ出てきます。

導入企業が導入前に最低限確認すべきこと

自作システムや小規模に立ち上がったサービスを導入する際、企業側は「便利そう」「安い」「現場を分かってくれている」だけで判断しないほうがよいです。最低限、次の点は確認する必要があります。

1. 保守体制

不具合や障害が起きたとき、誰が対応するのか。連絡先、受付時間、初動対応の流れが決まっているかを確認する必要があります。

2. データ管理

データがどこに保存されるのか。クラウドか、社内サーバか、外部サービスか。バックアップの有無、保存期間、復元方法まで確認すべきです。

3. セキュリティ

認証、権限管理、通信の暗号化、ログの取得、不正アクセス対策がどこまで実装されているか。特に顧客管理システムでは、この確認は必須です。

4. 継続性

開発者本人が離れた場合でも、運用や改修を継続できるか。属人化していないか。ドキュメントや引き継ぎ可能性があるかを見ておく必要があります。

5. 性能と拡張性

現在は問題なくても、利用者数やデータ量が増えたときに耐えられるか。高アクセス時や長期運用時の見通しがあるかを確認すべきです。

6. 契約終了時の出口

利用をやめるとき、データをどう返却してもらえるのか。他システムへ移行できるのか。出口が決まっていないサービスは危険です。

それでも、自作の時代は前に進む

自作システムやAI活用を否定するつもりはありません。むしろ逆です。現場を知る人が、自分で仕組みを作れる時代は歓迎すべきだと思います。既存のSaaSやパッケージが本当に必要かを見直す動きも、もっと増えてよいでしょう。

ただし、販売するなら話は別です。
導入するなら、さらに別です。

提供する側は、「自分で使えている」ことと「他社が安心して使える」ことを混同しないこと。
導入する側は、「便利そう」「安い」「分かってくれている」で判断しないこと。
この二つは、最低限必要です。

企業が導入前に確認すべきことも、かなり明確です。

保守体制はあるか。
障害時の連絡先と初動は決まっているか。
データの保管場所と管理主体は明確か。
バックアップと復元の手順は文書化されているか。
権限設計、ログ、監査の考え方は整理されているか。
将来のデータ増加や利用者増に耐えられる見通しがあるか。
開発者本人がいなくなっても継続可能か。
契約終了時のデータ返却や移行方法は決まっているか。

ここを確認せずに導入するのは、価格だけで基幹業務を選ぶのと同じです。最初は安く見えても、あとで高くつく可能性があります。

SaaSを解約して自作する時代は、もう始まっています。
その流れ自体は止まらないでしょうし、止めるべきでもありません。

しかし、自作できることと、導入責任を果たせることの間には、まだ大きな差があります。そこを飛ばして販売に進むこと、導入に進むことには、慎重であるべきです。

AI時代に本当に価値があるのは、作る速さだけではありません。
導入してよい水準かどうかを見極める力。
そして、導入後の責任を設計できる力です。

それがなければ、便利な試作品で終わります。
それがあれば、初めて企業が安心して採用できる仕組みになります。

ということで、これからの時代に問われるのは、「作れるか」ではなく「預けられるか」だと思います。SaaSを置き換える時代だからこそ、最後まで消えないのは、やはり導入責任です。