伝わったのは製品ではなく「自作」だった

1. 伝わったのは製品ではなく 「自作」だった SaaSエンジニアが見た、業務システム開発の民主化
2. 自己紹介 Nassy について ソフトウェアエンジニア。 業務SaaSを作ってきました。 - AI・Agent Skills・自動化まわりに関心があります - 札幌民です。仲良くしてください。 2
3. 1. 今日話すこと 工務店2社、電気屋1社に話を聞いてきた 業務SaaSを作ってきた人間として、かなり衝撃を受けました。 1. 何が起きていたか 2. イノベーター理論でどう読めるか 3. 市場はどうなりそうか 今日は分析まで。「自分たちはどうするか」は話しません。 3
4. 2. 前提にしていたこと SaaSを契約して、業務改善をする層だと思っていた アーリーアダプター〜アーリーマジョリティは SaaSを契約して業務改善をする その前提が崩れた話です。 4
5. 3. 工務店A社が作っていたもの 従業員5人の工務店A社が、受注から請求までを自作 - 現場の写真をアップロードし、相談内容は音声で記録 - LLMが優先度付け、見積書・請求書を作成 - 請求書をPDFで出力 優先度の判断基準は、もともと会社にあったものを組み込んだ。 業務の考え方をゼロから作ったわけではない。 5
6. 4. 規模と運用 作って終わりではなく、構成を変えながら運用 約10万行 430件 40本 コード規模 自動テスト 運用ドキュメント - 社内ホスティングからCloudflareへ移行 - Tauriのデスクトップ版も、クラウド化に合わせて移行 - 改修を続けながら運用している 6
7. 5. どうやって作っているか 元エンジニアではない人が、LLMと作っている - LLMの案内を愚直に実行する - B社は、ひたすら音声で話しかけて改修 「コードの中身を深く理解しているわけではない」 とも言っていました。元エンジニアではありません。 7
8. 6. どうやって自作システムを社内に定着させたか 従業員に覚えさせたのは、3つだけ 1. 担当の工事を探す 2. そこに写真・音声をアップロードする 3. 出力された見積もりをチェックする 苦労したというより、工夫したところだそうです。 8
9. 7. A社はSaaSを解約していた 覚えることが多く、現場で入力しづらかった 以前導入した、この分野で有名な会社のSaaSを解約。 - 覚えることが多い。使い方をCSに聞かなければいけない。 - 現場に出ているので、PCを開いて入力すること自体が難しい 動かなくなってもExcelに戻れる もともとExcelで回していた業務。 だから、そこまで高いリスクではないという捉え方でした。 9
10. 8. 3社はどう広がったか 別々の会社に、AI活用が広がった 会社 立ち位置 経緯 A社 アーリー アダプター Midjourney期からAIを追い続けた。 Fable祭りにも参加。非エンジニア B社 アーリー マジョリティ A社の業務適用を見て、自社フローに適応。 2週間で社内利用開始 C社 アーリー マジョリティ A社に何度も「使え」と言われて課金。 内装の3Dイメージを作成。「早く触ればよかった」 10
11. 9. ここからイノベーター理論で読みます A社を起点に、B社・C社へ別々に伝わった 業務適用を見せる → B社 アーリーマジョリティ A社 アーリーアダプター 何度も「使え」と勧める → C社 アーリーマジョリティ B社とC社の間にやり取りはない。A社が、それぞれに働きかけた。 ただ、1つだけ読み替えが要ります。 11
12. 10. 採用されたのは「製品」ではない 伝わったのは「LLMで自分で作る」という手段 キャズム理論で、普通は「製品」が採用される。 従来 新しいSaaSを採用 アーリーアダプターからマジョリティへ 今回 「自作」を採用 アーリーアダプターからマジョリティへ A社から伝わったのは、SaaSでもツールでもない。 採用対象を手段に読み替えると、3社の事例が採用曲線に乗る。 12
13. 11. キャズムは越え始めている。しかも会社をまたいで A社が「事例を見せる」「何度も勧める」を担った B社は、他社であるA社の事例を見て2週間で自社に適用した。 身近なリファレンスで動く。ムーアの処方箋が、そのまま起きている。 通常：ベンダーが作って届ける - 導入事例を公開する - 同業の成功例を紹介する - 迷っている顧客に営業が何度も通う 今回は、ベンダーがいない B社には、事例を見せる C社には、何度も勧める A社の人が、ベンダーの役割を 無償でやっている。 13
14. 12. ただし、マジョリティの中に濃淡がある 同じアーリーマジョリティでも、「作る」と「使う」 B社：作る 業務システムを 自社フローに合わせて改修 C社：使う 内装の3Dイメージ生成 業務システムの自作には至らず 「自作」まで到達したのは1〜2社。 身近な事例の濃さと、本人への働きかけの強さで分かれる。 14
15. 13. 自作がSaaSに勝った条件 A社では、自作が勝つ5つの条件が揃っていた 条件 A社 小規模・固有で、汎用SaaSのフィットが悪い 5人、現場主体、入力は写真と音声 撤退先がある Excelに戻れる 判断基準がすでに言語化されている 優先度の観点が会社にあった 失敗が致命的でない 最後に人がチェックする 同業コミュニティにAIを追い続けた人がいる A社の人。社内でなくてよい 逆に、どれかが欠ける領域ではSaaSが残る。 15
16. 14. 市場はどうなるか — 敗因はフィット不足 機能不足ではなく、フィットで負けた 汎用SaaS 80%合うものを 学習コストを払って使う 自作 5人の業務に100%合う ものを、自分で作る 写真と音声が入力で、操作を覚える必要がなく、現場で完結する。 これが比較対象になりました。 16
17. 15. 伝播経路がSaaSの営業経路を迂回する 同業者の口コミが、SaaSの営業経路を迂回する 従来：ベンダーの導入事例・営業・展示会を経由して採用 今回は、同業者の口コミで「自作」が伝わった。 工務店 → 電気屋 → 同業組合 ムーアの言う「ボウリングのピン」が、 ベンダー不在で倒れ始めている。 17
18. 16. ただし「ホールプロダクト」が欠けている 周辺を含めた完成品が、まだ揃っていない 3社とも、同じところに不安があった。 - セキュリティ：脆弱性、攻撃を受けたらどうなるか - LLMにどこまで情報を入れてよいのか - 運用、移行、相談相手 ここが埋まらない限り、C社層は 「使う」から「作る」へは進まないと見ています。 18
19. 17. 奪われる領域と、残る領域 SaaSは「接続点・記録・証明」へ押し戻される 自作に奪われる SaaSに残る ネットワーク外部性があるもの 会計・電子契約・発注先との共通基盤 自社固有の中間工程 受注〜請求のような 社内ワークフロー コンプライアンス・証跡が要るもの 給与・インボイス・電帳法 データが資産そのもの 顧客基盤・市場データ 「Excelに戻れない」もの 多拠点・多テナント・リアルタイム連携 19
20. 18. 予測 自作の広がりと、SaaSの役割の変化を予測する 1. 密な同業コミュニティから、固有業務の自作が会社をまたいで広がる 2. SaaSの契約数が減り、残るものが連携・記録・証明に偏る 3. アーリーマジョリティは、3つの経路に分かれる - 同業の自作者からテンプレートをもらう - 自作を支援する人（点検・運用・移行）に頼む - 写真・音声入力、覚えることゼロのLLMネイティブSaaSに乗る 4. SaaSは、自作アプリの撤退先・接続先へ。Excelが担っていた場所 20
21. 19. まとめ 「製品を選ぶ」行動が、「自作する」に変わり始める 業務SaaSは「どの製品が選ばれるか」を競ってきた。 今は、その行動自体が 同業者の口コミで置き換わり始めている。 伝わったのは製品ではなく、「自作」だった。 SaaSという形が選ばれ続ける領域はどこか。問いを変える必要がある。 21
22. 20. 断り 3社の観察に基づく、2026年10月時点の見解 - 3社のインタビューに基づく観察です - 一般化には検証が要ります - 予測は2026年10月時点の私の見解 AIの見解です ありがとうございました。 22