SaaSをエンプラ企業に導入する時に困ること（主に開発視点）

前提

• 内製開発のSaaS企業(B2B)
• 書いている人間の所属は開発部（SEがいっぱいいる部署）
• 書いている人間の職種はPMOみたいなやつ
• 以前の仕事では個人商店みたいな小さいところから、中小企業、中堅企業、エンプラ企業まで相手に担当

この記事では中堅企業までの企業に導入する際とエンプラ企業に導入する際の「違い」について書いていきます。
エンプラ企業の定義についてくだくだしく書きません。
名が知れていて、従業員がいっぱいいて、受注当たりの金額が大きくて、あなたがエンプラ企業だと思ったらエンプラ企業です。

メガバンはエンプラ企業です。業界トップ企業はエンプラ企業です。業界トップ企業の子会社もエンプラ企業だし、トップ企業の一事業部もその範疇に入るでしょう。

結論だけ先に書く

「SaaSがエンプラ企業をメインターゲットにすると大変。何より開発部のスケジュールは死ぬ」
はい、これで読む気を無くしたらお帰りいただいて結構です。

じゃあ何が大変なんだよ、と言う話を書いていきます。
これを有効にさばく方法があればどなたか私にお知らせください。
基本的には営業のREPとCSと開発部の特に差し込み受付担当がスクラムを組んで進めていくという地味で面白くもない結論にしかならないと私は考えています。

あとエンプラ企業担当に対しては、たまに会社の金で酒飲んでガス抜きさせてくれれば最高です。
そんな会社に巡り合ったことないですけど。

受注するまでのコストと期間が大きい

エンプラ企業は契約書を巻いて受注するまでのコストがかかります。時間もかかります。
展示会で名刺交換して、うまくリードをとって情シスの担当者や事業部のキーマンに営業がアポ取ってから受注するまでにとにかく時間がかかります。

展示会で名刺もらってから契約して利用開始するまで半年で始まれば順調な方です。
１年以上かかることも珍しくありません。
営業が会うべきユーザー企業の人物が何十人もいることやユーザー側の社内手続きが煩雑で遅いことや予算確保のフローがとにかく鈍重なことも影響しています。

そして会ってから契約して利用開始するまですべてのコストはSaaS提供企業の持ち出しになります。
このクソ高い顧客獲得費用はサンクコストであり、後に記述する問題を引き起こす要因になります。
サンクコストが高い分面倒臭いことを言われても「もういい、お前は客じゃない」と言いづらくなります。
それでいて向こうはあっさりCHURNしてきます。酷い非対称性だと思います。

受注するまでの持ち出しコストが大きい

前項「受注するまでのコストが大きい」と似ていますが、このコストの担い手が営業担当に限らないことが前項との違いです。
独自フォーマットのセキュリティチェックシートや意図の見えない謎の質問、システムの構成図を提出しろなどの要求をユーザー企業は無償かつ短納期で要求してきます。
そして振り回されるのは法務担当や企画部門や開発部です。

ここで回答が遅れると相手の機嫌を損ねて失注の原因になるとSaaS企業の営業担当は恐れます。
そして今まで持ち出したサンクコストの大きさが彼の懸念を大きくします。
すると他部門に対して訳のわからない急ぎの差し込みタスクを営業担当が乱発することになります。
SaaS企業内部のメンバーとして、急ぎの差し込みタスクを差し込まれる側としては「これも全体利益のため」と頭では納得できますが、目の前のスケジュールも常に厳しいためいい気持ちはしません。

要望が多い

これは中堅企業以下とエンプラ企業の大きな違いだと思っています。
中堅企業以下なら意思決定者は一人で、担当者も少数です。
意思決定者が「俺がルールを決めた。SaaSを使い倒すために業務フローの方を変えていく。お前ら従え」と言ったら担当者は従うし、それに適応して業務を回すためのアジリティを備えています。
「前の業務フローの方が良かったッス。SaaSの方が業務フローに合わせて欲しいッス」と言い出す担当者はあまり見ません。いても転職活動を勧められるでしょう。

でもエンプラ企業においてはSaaS導入を決める担当者は「調整者」として振る舞おうとします。
「SaaSを導入します。業務フローも概ねこんな感じで。各現場でいい感じに調整して」と現場にSaaS導入を下ろすと「現行業務と合わせるためにこれができるようにして欲しい、あれもできるようにして欲しい。前システムにあったこの機能はないのか」のような要望が現場から返ってきます。
この要望は現場の数だけ返ってきます。
とりあえず導入担当者に突っ返すことはエンプラ企業の現場管理職の「義務」ですらあります。なぜならSaaS導入で効率の低下やミスが発生した場合、この要望を投げる「アリバイ工作」をしないと現場管理職の責任となりがちだからです。
突っ返す要望作る側にいた私が言うんだから間違いありません。

すると導入担当者からSaaS企業へはこんな要望が来ます。
・うちの業務フローに合わせておたくのSaaSを拡張してくれと言う要望（個社対応ですよね？）
・前の利用システムとの現行保証のためにおたくのSaaSを拡張してくれと言う要望（個社対応ry）
・１テナントに複数のシステム設定を持たせてくれと言うシステムのポリシーを捻じ曲げるような要望
・１テナントから複数のsalesforceテナントに連携させてくれと言う要望（SaaS側も複数テナントで契約したら？）

さらにやたら複雑で混乱したユーザー権限設定や外部システム連携の設定も生まれがちです。
１つのエンプラ企業の看板の下に、異なる業務フローを持つ複数の事業部がいるからです。

初期導入コストが大きい

エンプラ企業だと導入開始にあたり大量のユーザー登録や外部システムとの連携設定が必要になります。
さらに利用開始するとあれが動かない、これが動かないと大量の質問がCSや開発部に来ます。
ユーザー側の問題もありますし、実はユーザー側の複雑な設定が未知のバグを踏み抜いているケースもあります。
とにかくエンプラ企業が導入すると問い合わせや作業が大量にきます。
チケット分析していて非常に渋い表情をしたくなります。

またエンプラ企業は一通り触ると「この機能が欲しい、あの機能が欲しい、ここも変えて欲しい」と気軽に要望を投げてきます。
エンプラ企業のユーザー部門にとってはSIerに作ってもらったオーダーメイドのシステムもSaaSの吊るしのシステムも区別をつけておらず「最初だから瑕疵担保期間でしょ？」くらいの感覚でユーザー部門が投げ、「まあワンチャン」くらいの感覚でエンプラ企業の担当者がこちらに投げてくる場合もあります。
そう言うチケットを蹴ることはできますが、蹴ることでエンプラ企業側の心象悪化を恐れる自社の営業担当者との関係悪化を防ぐ心理的負荷は私もそれなりに感じます。

CSが能動的に動く必要がある

ユーザー企業側の実運用担当にとって新たに導入したSaaSが「やり方が分からない、だから使いこなせない」ケースはたびたび発生します。
ユーザー企業側の担当が忙しかったりシャイだったりプライドが高かったりするとこれをSaaSのCSに質問として投げてくれません。
なんならユーザー企業側が勝手に作った導入マニュアルなる簡素な代物だけ現場に押し付けて「あとよろしく」とかやりがちです。
するとSaaSを導入しても結果なんて出ません。
そして半年後にはCHURNします。
あれだけたっぷり顧客獲得費用をかけて契約を巻き、新規導入であれだけ問い合わせを投げまくってきたにも関わらず、です。

CHURNを防ぐためには導入時に手厚い導入支援が必要になります。
CSがユーザー企業の利用実態を定量化してデータを監視。使っていなさそうなら何かお困りでは？とグイグイ突っ込んでいくことも必要になります。
あるいはユーザー企業の導入担当者に「〜〜のユーザーのシステム上の動きが見られないがこれはいいのか？」とCSが営業経由でチクることすら必要になります。

リテラシーの高い中堅企業なら必要なかったことすらもエンプラ企業でDXの成功体験を積ませるためには必要になります。

自社プロダクトがフィットしたかを判断できるまでの時間が長い

エンプラ企業のSaaS導入の場合、契約を巻いて利用開始してから半年後あたりがチェックポイントです。
ここで自社がSaaSを利用して成果が出せたか？ちゃんとサポートしてくれたか？要望に応えてくれたか？あたりが重点的に見られます。
半年後に「やっぱりうちに合わなかったわ」とだけ言い残す。担当からはもうちょっと詳しい話が聞けるけどあくまで主観ベースでプロダクトへのフィードバックとしては弱い、みたいなケースも多いです。

プロダクト開発においては「ある機能を開発するかどうか、そのインパクトはどの程度のものか」「どの機能を優先して作るか。どの顧客から先に刺すか」をリリース単位や2週間程度のスプリント単位で判断し計画を作っています。
ところが展示会でデモを見せてからCHURNするまで1年以上経っているわけで、CHURNされたあとのフィードバックを当てにしてプロダクトを開発するにはそのサイクルは長すぎるわけです。

また実は裏の目的もあったりするのがエンプラ企業の怖いところです。
偉い人の人事目標に「10個のSaaSを導入して評価を行い、DXに貢献した3個のSaaSを採用する」みたいなことを書かれています。しかも偉い人の胸の中では採用候補のSaaSの2~3個はすでに決まっています。つまり導入時点で切られる7個の側にしれっと自社プロダクトが入っていたりします。
エンプラ企業の偉い人は「失敗しないこと」を重視するので、確実にどうにか成果を出せそうな3個のプロダクトを事前に選んでおき（Teamsやキントーンみたいなプロダクトが多いですね）、残りの7個はプロセスを踏んで導入したら半年後には切ることが決まっている出来レースだったりするわけです。
そんなもののために自社のリソースは食われ、結局LTVは赤字で終わる訳です。
こういうところからのフィードバックはアリバイ工作レベルのものも多いので、むしろフィードバックとして耳を傾けてはいけないケースもあります。

受注時期が重なりやすい

今まで散々SaaSユーザーとしてのエンプラ企業がSaaS企業の現場の人間から見てどれだけ困るかと言う話をしてきました。
しかしこれは1社の話です。
ではこれが複数社による同時攻撃として発生したらどうなるでしょう？

エンプラ企業に刺さる機能というものは「なんとなく作っていたらたまたま刺さりました」という機能ではなく「こういうペインを持っているエンプラ企業を刺すために作った機能を展示会でバキバキに作り込んだデモを作んだら何十社か刺さった」という機能が多いです。
この手の営業攻勢は片手間にやるのではなく専従チームが担当します。
展示会でリード取ってからパイプラインに対して攻勢をかけるため複数社に同時並行で話が進みます。

結果として「この機能が刺さって受注できた」エンプラ企業は複数社、同じ時期に利用開始することになります。
エンプラ企業の複数社が同じ時期に利用開始することの問題は次項「初期導入コストが大きい」で語ることにします。

なぜそうまでしてSaaS提供企業はエンプラを狙うのか？

いくつか理由はあります

• SMBよりはエンプラの方がまだ伸び代がある
  • リテラシーの高いSMBは手がかかりません。しかし手がかからない分すぐ安くて便利な方に乗り換えます。CACは安くともLTVが伸びません。
  • 一方エンプラ企業は導入時は手がかかりますが、一度安定してしまえばそう簡単にはCHURNしません。
    • 自社内でノウハウを貯めて勝手に教育してくれる上、溜め込んだデータが自縄自縛となってCHURNできなくなります。手がかかるけどそれだけの価値はあります。
• アップセルしやすい
  • 最初の導入は小口でもエンプラ企業の得意技「成功事例の横展開」でアップセルが狙えます。しかもでかい分アップセルの幅も大きいです。
• SMBの小さい売上をチマチマ積み上げるより、エンプラの売上をドカンと積み上げた方が事業計画を立てやすい
  • 営業部単位でも会社単位でも同じです。
  • また個社単位でのサポートコストや保守対応コストもいっぺん安定させてしまえば、安定したエンプラ顧客は安くつく傾向にあります。

「で、あんたはなんでエンプラ企業が嫌いなの？」

導入した企業から大量の差し込みタスクや調査タスクや要対応の改修要望が大量にくると、頻繁に開発スケジュールが狂うからです。
スクラムならまだ対応できますが（対応できるとは言ってない、役員に見せる前に地獄の中期計画作りVer.Nが待ってる）
ガントチャート引いて機能開発をするスタイルだとスケジュールが確実に崩壊します。
計画を再作成するコストが高いガントチャート引くスタイルなら確実に避けたい状況です。

でもエンプラ狙わないと事業として成長が厳しいんでしょ？

そうだよ（迫真）
「悔しい、でも狙っちゃう（びくんびくん）」