開発会社から見た SaaS の過去・今・未来 商談と相見積もりで感じたこと

SaaS(インターネットを通して、月額などで使うサービス)は、システム開発の会社から見ると、時代ごとに違う姿に見えます。この記事では、編集部の運営会社が商談や相見積もり(何社かの見積もりを比べること)の場で感じてきたことを、過去・今・未来の 3 つに分けて書きます。国の調査の数字も添えます。

3 つの時代の見取り図

代表は、SaaS の姿を次の 3 つに分けて見ています。

• 過去: やることを限定することの損得(トレードオフ)を、気にしていました。
• 今: すぐに作れる状況になりました。その中で、SaaS がやることを限定していることは、お客さまに信頼を与えます。
• 未来: ドメイン知識(その業務の知識)をもとにした、コンサルタントになりそうです。

この順に、記録と数字で確かめていきます。

過去: やることを絞ることの損得を、気にしていた

SaaS は、機能を絞って、多くの会社に同じものを出します。トレードオフは、何かを取ると、別の何かを手放すことになる関係です。機能を絞れば、それに合わない使い方が出ます。お客さまに合わせて作ることを仕事にしてきた開発会社として、代表には、この「絞る」が、損得のある選び方に見えていました。

国の資料も、当時の日本の作り方をこう書いています。経済産業省の「DXレポート2」(2020年12月)には、「我が国企業のシステムは受託開発によってシステムを構築している割合が高い。また、パッケージソフトウェアを利用する場合もカスタマイズが多い。」とあります。受託開発は、お客さまの仕組みを、個別に作って納める仕事です。

では、使う側は、絞られていることをどう見ていたのでしょうか。総務省の「通信利用動向調査」で確かめます。

2013年末に、クラウドサービスを一部でも使っていた企業は 33.1% でした。調査の対象は、常用雇用者が 100 人以上の企業です。2014年末の調査では、使っていない企業に理由を聞いています。

• いちばん多い理由は「必要がない」の 44.7% で、次が「情報漏洩などセキュリティに不安がある」の 34.5% でした。
• 「ニーズに応じたアプリケーションのカスタマイズができない」は 6.9% でした。2018年の調査でも 7.5% です。

少なくともこの調査では、やることが絞られていること(カスタマイズができないこと)は、使わない理由の上位ではありませんでした。

今: すぐに作れるからこそ、絞り込みが信頼になる

すぐに作れる状況になった

編集部の運営会社では、AI のコーディングの道具(Claude Code)で作るようになり、作る時間が短くなりました。Claude Code の公式のドキュメントは、Claude Code を、コードを読み、ファイルを編集し、コマンドを実行する道具だと説明しています。編集部でも、社内で使う表計算と DB(データベース)の仕組みを、最初の記録から約 3 時間 40 分で形にしました(自作で脱 SaaS はできる？に書いています)。

提案のしかたにも、これが表れています。編集部の運営会社の記録では、ある業務の仕組みの提案に、動く見本(デモ)を作って持っていっています。アプリの提案書では、結論のページに、動作のデモを置いています。

それでも、クラウドは「安いから」より「安定して動くから」選ばれている

すぐに作れるようになっても、既存のサービスを使う企業は減っていません。クラウドサービスを使う企業は、2025年に 83.5% になりました(上のグラフ)。使っている企業が挙げた理由を、2018年と 2025年で比べます。

• 2025年にいちばん多い理由は、「場所、機器を選ばずに利用できるから」の 50.7% でした(2018年とは選択肢の言葉が違うため、図には入れていません)。
• 「安定運用、可用性が高くなるから」は、29.6% から 45.1% に増えました。可用性は、止まらずに使える度合いのことです。
• 「資産、保守体制を社内に持つ必要がないから」は、42.8% です。
• 「既存システムよりもコストが安いから」は 19.4% で、図の中でいちばん少ない理由でした。2018年の 21.6% から、ほとんど変わっていません。

安さを挙げた企業は 2 割ほどです。上位は、場所を選ばずに使えること、安定して動くこと、自社で持たなくてよいことでした。代表が言う「信頼」は、この「安定運用」や「信頼性」と重なります。編集部は、次のように受け取っています。すぐに作れるなら、「作れます」はどの会社も言えます。何をして、何をしないかが先に決まっていて、長く動き続けているものは、すぐには作れません。

ここから、編集部の運営会社の 3 つの場面を紹介します。

場面 1: サーバーの移行で、機能が決まっているサービスが残った

ある法人の、複数の Web サイトを新しいサーバーへ移す提案です。SaaS そのものではありませんが、事業者が機能と範囲を決めて提供するサービス、という点は同じです。

• 並べた選択肢: 構成を自由に組めるクラウドや VPS(サーバーを 1 台まるごと借りるサービス)も比べました。最後に残ったのは、事業者が機能を決めている法人向けのレンタルサーバーでした。
• 提案書に書いた安全の説明: 多くは、事業者の公式の機能の一覧にあるものでした。不正な通信を止める仕組み(WAF)、Web の改ざんの検知、毎日の自動バックアップ、稼働率の保証です。
• 保守の範囲: 提案を見直すたびに、小さくしました。動いているかの監視は、事業者の稼働率の保証に任せる方針でした。最後は、費用のかからない形を含むいくつかの段階から、お客さまに選んでもらう形にしました。
• 開発会社が受け持ったこと: 共用のサーバーは、契約ごとに使える性能の保証が公表されていませんでした。そこで、アクセスが多いサイトと同じくらいの負荷をかけるテストを、開発会社の作業に入れました。

最後の提案は、事業者が公開している機能に任せ、足りない所だけを開発会社が受け持つ形になりました。クラウドと VPS の比べ方は、クラウド vs VPSで説明しています。

場面 2: 「月額のサービスでよいのでは？」に答える

会員制のサイトを運営する会社への、メール配信の機能の提案です。提案書には、既存のメール配信のサービスとの違いを説明する節を入れました。月額のサービスで足りるのでは、という疑問を、先に取り上げています。

• 答え方: 要望のいちばん大事な所は、会員の状態や履歴のように、お客さまのデータベースにしかない情報で送り先を選ぶことでした。既存のサービスは、その情報を見られません。だから、会員の情報と直接つながる仕組みを作る、と説明しました。
• 範囲の示し方: 作る範囲を、いくつかの段階に分けました。それぞれに「できること」と「今回は含まないもの」を書いています。

月額のサービスと比べられることを前提に、提案書を書いています。作る側も、「何を作らないか」を先に示す形になりました。

場面 3: 相見積もりで、求められたこと

あるサービスを、スマートフォンのアプリにする案件です。何社かに声がかかっていて、相見積もりになる見込みの依頼でした。

• 依頼の条件: 公開の時期、いまの Web の画面を生かす作り、開発の体制のほかに、初期の開発のあと、将来は社内で保守・運用・小さな改修ができる状態へ移す、という条件が入っていました。
• 提案書の作り: 依頼書のすべての項目に、1 対 1 で答える目次にしました。いくつかの作り方を表で比べ、いちばん大事な条件を「社内で保守しやすいこと」に置いて選んでいます。

比べられていたのは、金額だけではありませんでした。作ったあとに、お客さまが自分で持てるかどうかも、条件でした。

いまの商談で、聞かれること・比べられるもの

図の左の 4 つの問いは、提案書の中で、聞かれる前に先に答えたものです。図の「既製の AI のサービスと、何が違うのか」は、AI で開発する環境を用意するサービスの提案書に足したページです。出来上がった AI のサービスを使うことと、お客さま専用の環境の上で、必要なものを作っていくことの違いを説明しました。

編集部の運営会社は、発注先を探す会社と開発会社をつなぐ紹介サイトを通した相談も受けてきました。いまの商談では、ほかの開発会社に加えて、月額のサービスと、お客さまが自分で作ること(内製)が、比べる相手に入っています。

任せる所と、作る所を分ける

SaaS がやることを絞っているなら、その外側に、作る所が残ります。2 つの場面を紹介します。

場面 4: SaaS の中でできないことを、外に置いた中継で補う

ネットショップの SaaS を使う会社が、取引先の注文のシステムとつなぎたい、という相談でした。取引先は、たがいを証明書で確かめる通信を求めていました。この SaaS の中からは、その通信を直接は行えませんでした。そこで、SaaS は置き換えず、あいだに中継のプログラムを 1 つ足す形を提案しました。決済と注文の管理は、SaaS に任せたままです。

場面 5: 自前で集めずに、既存のデータのサービスを使う案も並べる

地域の事業者の団体から、エリアの人の流れを地図で見たい、という相談を受けました。提案書では、いくつかの案を並べました。そのうち 1 つは、自前では集めず、既存の人流データのサービスを買う案です。取り組みの前後の比較や、新しい事業者を誘うための資料なら、この案で足りる見込みだと書きました。進め方の最初の段階は、無料のサービスでいまの様子を見て、使いみちを決めることにしています。

このほかに、ある会社の事業を手伝う案件では、決済と販売は既存の SaaS に任せ、新しく作る仕組みとつなぐ方針にしました。

国の報告書の分け方

この分け方は、国の報告書の考え方と重なります。

DXレポート2 は、自社の強みとは関係の薄い「協調領域」では、業務の進め方を標準に合わせて、SaaS やパッケージを使うよう求めています。ビジネスの強みになる「競争領域」は、社内に開発の体制を作り、小さな開発を繰り返すよう求めています。編集部の運営会社の提案は外からの開発ですが、任せる所と作る所を分ける考え方は同じです。

未来: 業務の知識をもとにした相談役に近づく

代表は、これからの SaaS を「ドメイン知識をベースにしたコンサルタントになりそう」と見ています。ドメイン知識は、その業務についての知識です。編集部は、こう受け取っています。すぐに作れるなら、差になるのは、何を作るべきかを知っていることです。その業務で何が起きるか、どの決まりに合わせるか、という知識です。これは、SaaS だけでなく、開発会社にも当てはまります。

編集部の運営会社の記録にも、相談役に近い仕事が出てきています。

• 何のために作るのかを、先に決める: 場面 5 の提案書は、最初に決めることとして、だれが何のために見るのかを挙げました。それによって、要る精度も、更新の頻度も、費用も大きく変わるからです。
• 業務の理由で、案を選ぶ・外す: ある法人の、お金を管理する仕組みの改修では、いくつかの画面の案を比べました。そのうち 1 つは、業務の数字の持ち方から、合計が合わなくなる、という理由で外しています。
• 作る前に、問いを整理する: ある会社の事業を手伝う案件では、作る前に、十数個の問いを並べたページを作りました。答えは先に書かず、話し合いの材料にしています。この案件の記録には、本当に届けるものは、事業と役割の整理だ、と書いています。

国の報告書も、同じ向きを示しています。DXレポート2 は、これからのベンダー企業(開発会社)の姿を 4 つ挙げました。その 1 つは、「特定ドメインに深い経験・ノウハウ・技術を有する専門技術者を供給する」ことです。サマリーには、政府の政策の方向として、「受託開発とは決別し、ユーザー企業のDXを支援・伴走してけん引する新たなベンダー企業への転換の加速」が挙がっています。

未来の部分は、代表の見方です。そうなると決まっているわけではありません。記録の残し方は、プロジェクトごとに軽い管理の仕組みを作るで説明しています。

まとめ