業務自動化SaaSを売る側が、最近の営業の場でいちばん多く投げかけられる問いがある。「それ、うちで自分で作れないんですか?」
ひと昔前なら、この問いはすぐに収まった。エンジニアを何人か付けて、数か月かかり、その間ほかの仕事が止まる。そろばんを弾けば、たいてい「素直に買おう」で終わった。ところが今は空気が違う。コーディングを手伝ってくれるAIエージェント(人が指示すれば自分でコードを書いて直すAI)に「毎朝、注文データを集めて要約メールを送って」といったことを頼むと、半日で動く何かが出てくる。非エンジニアでも真似ごとはできる。
だから、この問いがふたたび重くなった。誰もが自動化の「最初のバージョン」を作れるようになった時代に、業務自動化SaaS(月額で使うクラウドソフトウェア)はいったい何を売って「内製」と競うのか。結論から言えば、勝負は「作れるか作れないか」ではなく、「失敗を先に見つけ、被害を抑え、元に戻す責任を誰が負うのか」で決まる。この記事では、その構図をSaaS事業者の目線で押さえる。顧客がなぜ内製へ傾くのか、そしてその前で製品と営業が何を証明しなければならないのか。
自動化の参入障壁が本当に下がったのは事実だ。ここから目を背けると、競合分析そのものが狂う。
小さな店をやっている人が、AIに「ネイバー予約が入ったら私にSMSで知らせて」と頼むとしよう。何度かやり取りすれば、動くスクリプト(特定の作業を自動で実行する短いプログラム)が手に入る。初日のテストも通る。この瞬間、彼は確信する。「ほら、できるじゃないか。わざわざお金を払って使う必要はないな」
ここで足を滑らせる。彼が見たのは「晴れた日の試運転」だ。予約がきちんとした形式で一件ずつ入り、インターネットが切れず、ネイバーが画面を変えていない状態。その条件でだけ動く代物だ。自動化の難しさは、この晴れた日にはない。雨風にある。そして顧客が内製へ傾く出発点こそ、この晴れた日の成功体験なのだ。
自動化でいちばん手間が残るのは、デモではなくその後だ。正常な入力を処理する最初のバージョンを作ることより、失敗を見つけて元に戻す仕組みを備えることのほうに、ずっと多くの手間が残る。この最後の区間をよく「ラストマイル(last mile)」と呼ぶ。先ほどの予約通知の例で続けると、雨風は三方向から吹く。
第一に、入力が汚い。一か月ほど順調に動いていた通知が、ある日来なくなる。客が予約メモに絵文字をたくさん入れていて、それを処理する途中でスクリプトが止まったのだ。こうした、まれに飛び出す例外的な状況をエッジケース(edge case)という。世の中のデータはきれいではない。電話番号の欄に「あとで連絡します」が入り、日付の欄に「来週のどこかで」と書かれる。デモはこういうものを想定しないが、運用は毎日こういうものに出くわす。
第二に、外の世界が勝手に変わる。ネイバーが予約画面の構造を変えれば、昨日まで問題なかった自動化が今日止まる。問題は、止まったという事実を知らせてくれる仕組みがないことだ。だから店主は「このごろ予約が少ないな」と思っているうちに、ずっとあとになって、溜まっていた通知の束を発見する。止まったことより、止まったのに気づかなかった時間のほうが高くつく。
第三に、直したものがまた壊れる。絵文字の問題を防ごうとコードに手を入れたら、今度はちゃんと動いていた英語名の処理が狂う。一か所を押すと別のところが飛び出すこの現象をリグレッション(regression)という。テストをきちんと備えておかないと、直すたびに新しい穴が開いているかどうかさえわからない。
この三つを背負うのが、自分で作った人だ。内製とは一度書いて終わる工作ではなく、終わりのない世話だ。顧客が「自分で作ればいいのに」と言うとき、そろばんに入れていないコストがまさにここにある。そしてSaaS事業者が製品と営業で見せるべき価値も、ここから始まる。
競合分析の核心はここにある。SaaSが売る商品を「機能」として書き出すと、しょっちゅう混乱する。機能は複製しやすい。「要約メールを送る」なら誰でも作る。SaaSが実際に売るのは、その機能が雨風のなかで壊れたときに、失敗を先に見つけ(検知)、被害を限定し(停止・承認)、元に戻す(復旧)責任だ。これは週末では複製できない。
何が複製しにくいのかを見よう。まず、積み上がった例外の経験だ。何千もの顧客を相手にしてきたサービスは、それだけ変な入力にすでに出くわしており、その経験がコードのなかに溶け込んでいる。自分で作る人は、この何千回もの事故を、ひとりでゼロから改めて経験しなければならない。次に、外部変化の吸収だ。外部サービスが画面を変えたりモデルが入れ替わったりしたとき、SaaS側が先に察知して直しておけば、顧客はそんなことがあったとも知らずに使い続ける。最後に、止まったときに気づく監視の仕組みだ。これをきちんと作る作業は、自動化本体を作るのと同じくらい手間がかかり、内製した人のほとんどはここまでは手が回らない。
まとめると、複製しやすいのは機能であり、難しいのは失敗を制御する能力だ。だから製品と営業が証明すべきは、デモ画面の立派さではなく「壊れたときにどうなるか」である。
競合分析が自社に有利なほうへばかり傾けば、それは分析ではなく営業だ。内製のほうが良い場合は、はっきりある。ただしその境界線は、組織の規模ではなく三つで引かれる。その自動化をどれだけ長く維持するのか、壊れたときの損失がどれだけ大きいか、直す人が常にいるか。
失敗しても損失が小さい、あるいは一度か二度使って捨てる自動化なら、ラストマイルにかける手間がそもそも少ないので、自分で作って使うほうがいい。業務が会社の秘伝のレシピそのものであって、外のツールに任せた瞬間に差別化を明け渡してしまう場合も、内で作るのが正しい。壊れたらすぐに駆けつけられる開発人材が常に待機しているなら、ラストマイルのコストを自力でまかなえる。(規模が非常に大きく、単価が逆転する地点もここに重なる。)
逆に、その業務が本業ではなく、直す人を別に置く余裕がないなら、内製はたいていこう終わる。最初は張り切って作り、二、三か月動き、ある日止まり、止まったことに気づかないまま放置され、結局その仕事を人がまた手作業でやる。元の場所に戻ったのだ。その間に捨てた時間こそ、本当のコストだ。事業者はこの境界線を正直に引かなければならない。境界の外にいる顧客を無理に連れてくれば、じきに解約となって返ってくる。
競合相手を「似たような別のSaaS」だけだと見ると、絵の半分を見落とす。実際の基準線は三つある。「内製」「人を増やす」、そしてもっとも強力な「何もせず今のまま耐える」だ。
最後のものがなぜいちばん強いのか。人は不便をけっこう長く我慢する。毎日30分、手でデータをかき集める作業を「もともとそういうもの」として受け入れ、何年も耐える。新しいツールを入れれば学ばなければならず、既存のやり方を変えなければならず、しくじれば責任を負わなければならない。その面倒くささが、目の前の30分より大きく感じられるかぎり、人はただ耐える。
だから「うちの製品は競合製品より機能が多い」では、この惰性に勝てない。勝つべき相手は惰性のほうだ。導入がより面倒でなく、既存のやり方をあまり変えなくてよく、しくじったときに知らせてくれるという信頼。この視点は、価格を見る目も変える。「内製」と比べれば月額は高く見えるが、比較対象が「その仕事をしていた人の時間」や「放置されて手作業に戻った時間」なら、まったく違う大きさに見える。勝負どころは「うちのほうが安い」ではなく、「あなたが今払っている見えないコストを見えるようにする」ことにある。
ONTLEは、このラストマイルを代わりに引き受けるサービスだ。届いたメールを読み、社内に共有し、顧客に送る返信の下書きを作り、変更を記録する過程を代わりに回す。ただし、顧客に出す返信や日程の確定のように元に戻しにくい地点は、人の承認を経る。架空の小さな製造会社を置いて、ありがちな事件をひとつ追ってみよう。顧客が「納期を一週間早めてほしい」とメールを送ってきた状況だ。
ここでひとつ押さえておきたい。AIが絡む仕方は二つあり、この二つは違う。ひとつはコーディングエージェントがコードを一度書いておけばそのまま回るもの、もうひとつは実行中にAIモデルが毎回メールを読んで判断するものだ。納期メールを解釈するのは後者だ。ところがこの判断するモデルは、数か月単位で新バージョンが出て、旧バージョンはじわじわ閉じられていく。新しいモデルは同じ指示にも少し違う反応をするので、先月まで問題なかったプロンプト(AIに与える指示文)が、今日は見当違いの答えを出すこともある。
何が失敗するのか。 現実のメールはデモのような形をしていない。「この前お話ししたあの件、できれば少し早めていただけますか?」と来る。「あの件」がどの注文なのかメールにはなく、日付も数字で書かれていない。よりによって生産スケジュールのシステムが点検中で、照会が失敗する。早めてほしいという要望が物理的に不可能なのに、自動化はそれを知らずに「はい、可能です」という下書きを作ってしまう。この下書きが検討なしに出ていけば、事故だ。
どう対応するのか。 ここで、自分で作ったスクリプトと、運用に責任を負うサービスとが分かれる。「あの件」が何かわからないとき、勝手に決めつけず「この注文のことでよろしいでしょうか?」と問い返すか、人に回す(検知・承認)。間違った注文に返信が出て生じる信頼の損失を防ぐ仕組みだ。早めることが不可能なら、嘘の約束のかわりに「ここまでは可能です」と提示する(正直さ)。守れない納期を約束して破綻する事故を防ぐ。スケジュール照会が失敗したら、先に進めず「今は確認できないので、しばらくしてから」と止まる(検知)。誤った情報で答えるのを防ぐ。外に出る返信は人の承認を経て(承認)、この変更がほかの注文に及ぼす影響まで併せて見る。
誰がそのコストを引き受けるのか。 この会社が内製するなら、この五つをすべて自分で設計し、モデルが変わるたびに点検し直し、生産システムが画面を変えればそのたびに直さなければならない。それをやる人がいなければ、自動化は「晴れた日にだけ動く代物」のまま残り、雨の日には人がまた走る。
五つがすべてONTLE固有の機能ではない点は、はっきりさせておく。「曖昧なら人に回す」と「外部発信の前に人の承認」は、ONTLEが実際にそう動くように作り込んだ地点だ。残りの三つ(不可能の判定、照会失敗時の停止、影響分析)は、運用自動化ならどこでも備えるべき設計原則であり、ONTLEもその原則の上で動く。最初の一通の返信は誰でも作る。千通目の変なメールを前に事故を起こさないのは、別の話だ。
買い手のための点検の問い 自分で作った自動化であれ、買おうとしているSaaSであれ、次を問えば、ラストマイルにどれだけ備えているかの見当がつく。 - 自動化が今止まったら、私は何時間以内に気づけるか。わからないなら、止まったことにも気づかない状態にさらされている。 - 変な入力が来たときにどうなるかを、実際にテストしてみたか。やっていないなら、晴れた日だけ検証したのだ。 - 作った人が席を外したら、誰が直すのか。答えがないなら、その自動化の寿命はその人の在職期間と同じだ。 - (SaaSを選ぶとき)機能リストの長さより、壊れたときの振る舞いを見よ。失敗をどう知らせるか、不確かなときに勝手に進めるのか人に回すのか、外に出る行動に承認のステップがあるか。
その順序自体は合理的で、実際に多くの人がそうしています。ただ、乗り換える時点のコストをあらかじめ念頭に置いておく必要があります。内製した自動化には、それまで積み上がった例外処理と社内の人たちの使い慣れた習慣が絡んでいて、移すときにそれをほどく作業が思いのほか大きいのです。だから「いつ乗り換えるか」よりも「どの線を越えたら乗り換える」を最初に決めておくほうがいいでしょう。たとえば、直す人がいなくて一週間以上放置されたことが一度でも起きたら、それが合図です。