既存SaaSが現場に定着しない理由｜自社業務とのズレと、それを埋めるための選択肢

SaaSを導入したのに、現場で思ったように使われていない、という会社は珍しくありません。月額を払い続けているのに、入力が滞っていたり、特定の人しか触っていなかったり、結局Excelに戻ってしまっていたり。導入時の期待と、現場の実態が乖離している状態は、中小企業の現場でかなり見かけます。

この状態を「現場のITリテラシーが低いから」と片付けてしまう経営者は多いですが、それで解決した話は聞いたことがありません。リテラシーを上げる研修を入れても、しばらくすると元に戻る。原因はもっと構造的な部分にあって、そこを直視しないと、何度導入と挫折を繰り返しても同じ結果になります。

この記事では、SaaSが定着しない現場で何が起きているかを整理した上で、定着しない構造的な原因を解きほぐし、すでに導入してしまった会社がこれから取れる選択肢までを扱います。新規にSaaSを検討中の人ではなく、すでに導入して困っている人向けの内容です。

SaaSが定着しない現場で、実際に起きていること

SaaSが完全に使われない、という極端な状態はそれほど多くありません。多くの場合、もう少し中途半端な、見えづらい形で機能不全が起きています。いちばん典型的なのは、SaaSとExcelやスプレッドシートの併用です。会社としてはSaaSを導入したのに、現場では一部の業務をExcelで補い続けている。月額を払っているのに、Excelの数も減っていない。なんなら、SaaS導入前より管理する場所が増えてしまった、ということもあります。

もうひとつのパターンが、一部の社員だけがSaaSを更新せず、自分の手元のExcelやスプレッドシートで管理を始めるケースです。表面上は「みんなSaaSを使っています」となっていても、よく見ると重要な情報の半分がSaaSの外で動いている。SaaSの中のデータが、最新でもないし、完全でもない状態になります。結果として、SaaSのデータを見ても全体像が掴めず、経営判断にも使えない。

このパターンが進行すると、SaaSは「形式的に存在しているが、実質は機能していない」状態になります。経営者は「SaaSを入れたから業務が見える化された」と思っているけれど、実際には見えていない。これがいちばん怖いところで、システムを入れた安心感だけが残り、実態は何も改善していない。

経営者と現場で、認識がズレている

SaaSが定着しないとき、経営者と現場では原因の認識がまったく違うことが多いです。経営者は「現場のITリテラシーが低い」「変化を嫌う」「使う気がない」と感じがちです。せっかく導入したのに使わない現場が悪い、という見方です。一方で現場は「このSaaSが使いにくい」「うちの業務に合っていない」「入力する手間に対して、得られるものが少ない」と感じています。使わないのではなく、使えない、または使う意味が分からない、というのが本音です。

この認識のズレは、双方が見ている事実が違うから起きます。経営者は導入の決裁をした立場として、SaaSが機能している前提で見ている。現場は実際に毎日触っている立場として、機能していない不便さを肌で感じている。同じ「SaaSが定着しない」という現象を、別の角度から見ているので、原因の理解が一致しません。そして、認識のズレがある限り、解決策にもズレが生じます。経営者はリテラシー研修や運用ルールの強化に走り、現場は「もっと使いやすいシステムにしてほしい」と求める。どちらの打ち手も、本当の原因に届いていないので、状況は改善しません。

このズレを解くには、どちらかが正しくて、どちらかが間違っているという見方をやめる必要があります。経営者から見えている事実も、現場から見えている事実も、どちらも本当です。リテラシーが追いついていない部分も実際にあるし、システムが業務に合っていない部分も実際にある。両方が原因として絡み合っているから、片方だけの対処では効きません。本当の解決には、SaaSと業務のズレがどこにあるのかを、経営者と現場が一緒に見つける作業が必要になります。それができないまま、責任の押し付け合いになるのが、SaaS導入後によく起きる泥沼です。

構造的な原因は、SaaSの設計思想と自社業務の独自性のズレ

ではSaaSが定着しない本当の原因は何か。複数の現場を見ていると、これはほぼ確実に、SaaSの設計思想と自社業務の独自性のズレから来ています。SaaSは多くの会社で使えるように、業界の標準的な業務フローを前提に設計されています。標準的というのは、最大公約数的、と言い換えてもいい。たくさんの会社の業務を観察して、共通する部分を抽出し、それを機能として実装している。だから、業務が標準的な範囲に収まっている会社では、SaaSはきれいにハマります。

ただ、ほとんどの会社には、業界の標準からは外れる独自の運用が、何かしら存在します。長年積み重ねてきた業務の進め方、業界の中でも特殊なフロー、顧客との関係性に応じた柔軟な対応、こういったものは、SaaSの標準機能ではカバーしきれません。ここでズレが生じます。SaaSは「こういう業務フローで管理してください」という前提を持っており、自社の業務はその前提と部分的に違う。違う部分について、業務をSaaSに合わせて変えるか、SaaSの機能を諦めて別のところで管理するか、どちらかの選択を迫られます。多くの会社は後者を選ぶので、ExcelやスプレッドシートがSaaSと並行して動く状態になります。

加えて、SaaSには自社にとって不要な項目や、使わないUIが多く含まれます。多機能であることを売りにしているSaaSほど、この問題は大きくなる。本当に使う機能は全体の2割か3割なのに、画面には残りの7割が常に表示されていて、毎日それを目にしながら入力することになります。これが地味に効いてきて、現場の負担感を上げます。

つまり、定着しない構造的な原因は、SaaSが悪いのでも現場が悪いのでもなく、SaaSと自社業務のフィット感が、最初から限定的だった、ということです。この、業務の独自性によってSaaSかオーダーメイドかの答えが変わる構造は、SaaSとオーダーメイド、本当に安いのはどっちかで費用面から整理しています。

ベンダー側にも、定着を妨げる構造がある

ここで、もうひとつの構造的な要因があります。SaaSを売る側、つまりベンダーの売り方の問題です。SaaSは、定義上、多くの顧客に同じものを提供することでコストを下げているビジネスモデルです。だからベンダーは、個別の顧客の業務を深く理解する動機がそもそも弱い。Web上で契約を取って、あとは使い方のマニュアルを渡して終わり、というスタイルが珍しくありません。これ自体が悪いというより、SaaSというビジネスモデルの構造上そうなる、という話です。単価が低いから、個別対応にコストをかけられない。

ただ、これが顧客側に与える影響は大きいです。SaaSを導入した会社は、自社の業務にどう適用するか、どこを業務側で吸収するか、どこをSaaSに合わせるかを、自分たちで考えないといけない。けれど、それを考えられる人材が社内にいる会社は、中小企業ではかなり少ない。結果として、運用設計が雑なまま導入が進み、現場が混乱し、定着しない、というルートを辿ります。これはベンダーが悪いというより、SaaSというモデルが運用設計まではカバーしないという、構造上の盲点です。

導入する側がこの盲点を理解していないと、「SaaSを契約すれば自動的に業務が改善する」という幻想を持ってしまいます。実際には、SaaSは道具を提供するだけで、それを自社の業務に組み込む作業は、買った側がやらないといけない。ここを誰がやるのか、どう設計するのかが事前に決まっていないと、定着しない結果は半ば必然になります。

すでに導入してしまった会社が、これから取れる選択肢

ここまで原因を扱ってきました。では、すでにSaaSを導入してしまって、定着していない状態にある会社は、これから何ができるか。選択肢はいくつかあります。

ひとつは、そのまま我慢して使い続ける選択。これは、現状の運用負荷がそれほど大きくない場合や、移行コストのほうが負担に見える場合に選ばれます。ただ、運用負荷は時間とともに積み重なるので、長期的には他の選択肢を検討したほうがいいです。ふたつめは、SaaSをカスタマイズして自社業務に寄せる選択。SaaSによってはカスタマイズが可能ですが、汎用SaaSの場合、カスタマイズ費がかさんでオーダーメイド開発と変わらない金額になることもあります。費用対効果は、カスタマイズの範囲とSaaSの種類によります。みっつめは、別のSaaSに乗り換える選択。これは、自社業務に近い設計思想を持つSaaSが見つかれば有効ですが、また同じ問題が起きるリスクもあります。乗り換え先を選ぶときは、機能の多さではなく、設計思想が自社業務とどれだけ合うかを見るのが重要です。

よっつめは、オーダーメイド開発に切り替える選択。これは、自社業務の独自性が強く、SaaSでは根本的に合わない場合に有効です。判断軸としては、移行コストとそれによる長期的な運用負荷の改善を比較することになります。コストがあまり変わらずに移行できるなら、フルオーダーメイドが一択になることが多いです。コストが大きく上がる場合は、現状の運用負荷とそれによる悪影響、たとえば現場の疲弊、ミスの頻発、本来業務に充てるべき時間の損失などを具体的に算出して、比較する必要があります。業種別の実例は、工事管理システムが自社に合わないと感じる理由で書いています。いつつめは、SaaSと部分的なカスタムシステムのハイブリッド運用。SaaSの強い部分は活かしつつ、自社独自の業務はカスタムで補う、という選択です。設計が複雑になる難しさはありますが、コストと業務適合性のバランスを取れることがあります。

どの選択肢を選ぶかは、自社業務の独自性の強さ、現在の運用負荷の大きさ、許容できる投資額、この3つで決まります。重要なのは、現状を放置するのが最もコストの高い選択肢になり得る、ということです。定着していないSaaSに月額を払い続け、現場が日々負荷を抱えている状態は、何もしていないように見えて、毎日損失を積み上げています。

そしてもうひとつ、選択肢を比較するときに見落とされやすい視点があります。SaaSが定着しなかったのと同じ理由で、次の打ち手も失敗する可能性がある、ということです。原因が「SaaSと業務のズレ」と「運用設計の不在」だったなら、別のSaaSに乗り換えても、オーダーメイドに切り替えても、自社業務の独自性を整理し、運用設計まで踏み込まないと、同じことが繰り返されます。打ち手の種類を変えるだけでは解決しません。何を、どう、誰が運用するかまで含めて設計しないと、新しいシステムも同じ運命を辿ります。これは選択肢を選ぶ前に押さえておくべき前提です。

SaaSが定着しないのは、現場のリテラシーや意欲の問題ではなく、SaaSと自社業務の構造的なズレ、そしてそれを埋める運用設計が不在だったことが本当の原因です。すでに導入して困っている会社は、自社業務の独自性の強さを正確に見極めて、現状維持以外の選択肢を比較することが、最初の一歩になります。