SaaSを社内で広げるなら「横展開」してはいけない
（2023年7月25日追記：許諾が取れたため、初出時に匿名だった事例を記名とした上で、ご本人からの補足点を追記しました）
一部の部署では活発に使われてるんだけど、それ以外の部署・メンバーに広がらない
ベンダーの方からはエクスパンション（利用拡大）の課題として、
ユーザーの方からは社内推進・社内展開の課題として、
こういう話をホントーによくお聞きします。
お話を聞いてみるとだいたい似たような感じ。
で、私がアドバイスする内容もだいたい同じ。
これは文字に起こしておいた方が世のためになるかもしれないな、と思ったのが、本記事の背景です。
この記事の内容をざっくり言うと
ある部署でうまくいったからといって、その「やり方」を横展開すればうまくいくわけではない。
課題のない顧客に売ってはならないのと同じで、課題のない部署に解決策（ツール）を押し付けてはならない。
横展開すべきは「やり方」ではなく「変革プロセス」
です。
「あー、なるほどね」と思った方は、ここから先は読まなくても大丈夫です。
なんとなく言いたいことはわかるけど…という方は、なんらかのヒントがあるかもしれませんので、お読みいただけるとうれしいです。
ある部署でうまくいったからといって、その「やり方」を横展開すればうまくいくわけではない
この理由は、すでに「ざっくり言うと」でタネ明かしをしたとおりで、社内だからといって同じ課題があるわけではない からです。
同じ課題がない、つまりユースケースが違うのであれば、一部で「うまくいったやり方（ユースケース）」が当てはまる可能性は低いですよね。
「課題のない顧客に売ってはならない」
この名言は、社外の顧客を想定してますが、社内でも同じなんです。
課題Aには解決策Xがうまくハマった。だったら、課題Bにも解決策Xがハマるよね！
こう書けば、そんなワケないのはわかりますよね。
もっと言うと、
課題なんか聞いてないけど、解決策Xが最高だよ！Youも入れちゃいなよ！
こんなアプローチしてもうまくいくワケがないですよね。
皆さんも経験ありませんか？見ず知らずの、イケてない営業クンが闇雲に売ってくるという状況。そいつは、どう考えても、こちらの事情を知らないし、課題なんて把握してる様子もない。でも、
「このツールいいですよ、ほら、このお客さんでこんなに成果出てるんですよ！」
と言ってくる。いや、知らんがな。そのお客さんとウチらは違うし。。
この例は、他のお客さんでうまくいった事例を、あなたに「横展開」しようとしていると捉えることができます。課題を聞かずにツールを「横展開」しようとすることが、いかに的外れかわかりますよね。
でも、得てして、「社内展開」をミッションとして与えられると、なぜかこうなりがち。
社内推進担当の皆さん、どうかお願いですから、イケてない営業クンにならないでください。
うまくいった「やり方（ユースケース）」を横展開できるのは、同じ課題があるときだけです。そして、そういう状況は（社内といえども）非常に限られているのが現実です。
横展開すべきは「変革プロセス」
横展開するなと言われても、「社内展開」を業務としてやらなければならない状況もあるでしょう。DX推進とは、まさに社内展開・社内推進を業務として取り組め、という形になって実行されるケースも多々あります（その良し悪しはさておき）。
では、どうすればいいのでしょうか？
課題が違う部門・人に対して「同じやり方」を横展開するのではなく、うまくいった部門で起きた「変革プロセス」を横展開するのです。
課題を認識し、チームで共有し、解決策を試してみて、微修正して、定着した。
このプロセスを横展開しましょう。
それって、もはや「横展開」じゃなくて、「再生産」では？
はい、そのとおりです。
逆に言うと、変革プロセスというのは再生産できるものなんですよ。
ちなみに、変革プロセスの正解は以下の図のとおりでして、これだけ覚えておけばOKです。ここから外れる変革は、ほぼ間違いなく失敗します。こういうのは死ぬほど研究し尽くした先人の知恵を借りるべし。
勘のいい人ならこのフレームワークを知るだけでガラリと動きが変わるのですが、これだけだと抽象的でわかりにくいと思います。うまくやっている人はどうやっているのか、具体例をご紹介します。
先日、「大企業で社内のDX推進をめちゃくちゃうまくやってる人」の話をお伺いする機会に恵まれました。その方はどうアプローチしているかお聞きしたところ、スパッと答えが返ってきました。
困ってそうな人に「それ大変じゃない？それ困ってない？」と聞いて回る
これぞまさに「課題がある人」を見つける最良の方法だと思うんです。
「困ってない？」と聞いてみて、「いや困ってない」と言われたら、困ってないんだから無理に勧めたところで無駄なので、一旦引く。
「そうなんだよ、大変なんだよ！」と返ってきたら、その現場の声をベースに「こんな課題あるみたいですね」「大変ですね」と、その上司に伝え、課題意識を共有する。なんとかしたいのであれば手を差し伸べる。そこまででもないようなら、無理に押し付けない。
その方はこうも言ってました。
「どんなに会社の方針や上層部の後押しがあったとしても、それを上からストレートに落とすやり方だと拒否反応が出る」
「価値を感じてもらうのが大事。価値を感じてくれたら、自らやってくれる。発信してくれたり、こちら側になってくれる。それを見た他の人も、自分たちもやれるかも、と思ってくれる」
そうなんですよね。課題があるから、解決策に価値があるわけです。課題がなければ、どんなにすばらしいツールを見せても価値を感じてもらえるわけではありません。
おそらくですが、この方は変革フレームワークをご存知ないと思うのですが、もっとも大事な最初の2つのステップ、「危機意識を高める（課題意識を共有する）」と「推進チームをつくる」を自然とやっていました。
もうひとつ、似たようなアプローチを取っている事例をご紹介します。先日開催されたAsana企業ユーザー交流会でご紹介された、伝統的大企業でDXを推進されているフジテック株式会社 デジタルイノベーション本部 プロセス管理部長 山本健治さんのお話から。
山本さんは「大企業のなかで新しい取り組みやツールを推進・浸透させるのは大変だと思うんですが、苦労した点は？」と聞かれて、こう切り返していました。
「実はあんまり苦労してないです。勝ち戦しかやってないから。手を挙げた人しか相手にしてないんです。やる気がない人を相手にしてもしょうがないんで」
「その代わり、期限までに手を挙げた部署はこちらの予算でカバーする。それ以降は自分たちの予算でやってね、という形にしてます」
はい、山本さんもやはり「課題がないところに売りに行かない」を実践していますね。
さらに詳しくお聞きしてみると、「成功確率の高い対象（困っていて改革に積極的、課題認識が一致、短期で問題解決できそう）から攻める」ことを意識されているそうです。
なぜ、うまくいっている人たちは同じようなアプローチを取っているかといえば、これはもう変革のセオリーどおりでして、「課題認識（危機意識）を認識し、共有する」というのは最初にして最重要のステップだからです。
変革プロセスを繰り返し、課題についての知見と活用法（ユースケース）を溜める
SaaSを社内で広げるには、まずこういった「課題発掘→課題認識の共有→チームづくり→ビジョンと戦略づくり→ビジョン共有〜〜〜（以下略）」という小さな変革プロセスを何度か繰り返す必要があります。
おそらく最初の1回は、偶発的な形で、かなりの短期間で回ってるはずです。最初に少人数で試してみたら良かった！というのが、最初の1回です。
これを意図的に、あと2〜3回くらい回してみる。ツールの使い方・ユースケースを横展開するのではなく、変革プロセスを繰り返す。
課題を見つけ、課題認識を共有し、「今の不便さを解消したい・もっと〇〇したい」というビジョンを目指して、試してみる。
このような変革プロセスを何度か繰り返すことで、DX推進チームに「社内でよく見かける課題と、それに対する解決策としてのSaaSの活用法」についての知見、つまりユースケースが溜まっていきます。
すると、社内で「似たような場面」に出くわすことが増えてきます。あ、この部門のやり方は、あっちの部門と同じだな、と感じることが増えます。
さあ、ここまでくれば、当初思い描いていた（やり方の）横展開ができる…と思いましたか？
できるかもしれませんが、実はここに落とし穴があります。ここで
「（あ、この状況知ってる！）それなら、これで解決できますよ！」
と飛びつくのは早計です。
課題なんか聞いてないけど、解決策Xが最高だよ！Youも入れちゃいなよ！
ここで一足飛びに解決策の話をしてしまうと、イケてない営業くんになってしまう可能性が高いので、くれぐれも気をつけてください。
まったく同じ状況（例えば、Aという業務を手作業でやってるとか、抜け漏れが多いとか、Excelが巨大化してるとか）が目の前にあらわれたとしても、それが「課題」かどうかは別の話です。
相手（その部署の人）がその状況を課題だと認識していなければ、それは課題ではないんです。まずやるべきは、
「それ大変じゃない？それ困ってない？」
と聞いてみる。困ってるなら、
「現場でこんな困りごとが起きてるみたいですね」
と課題認識を共有する。
先人の知恵を活用させてもらいましょう。
ここまで進めば、いよいよ「いまの困りごとが解決している未来」、つまりビジョンをつくって共有するタイミングです。このときこそ、DXチームが蓄積した「社内でよく見かける課題と、それに対する解決策としてのSaaSの活用法（ユースケース）」が役に立つ場面です。
このツールを使うと、こんな風に良くなります（ビジョン）
そのために、こういうステップで進めましょう（戦略）
まずは、この業務（ユースケース）からはじめるといいと思います（スモールサクセス）
SaaSベンダーのノウハウを活かしたり、彼らの協力を仰ぐのも、このタイミングです。どう良くなるのかという将来像・ビジョンを描くための材料をたくさん持っているはずです。また、特定のユースケースをうまく運用するための細かなノウハウもたくさん持っているはずです。
逆に言うと、困ってない人たちを説得する方法をSaaSベンダーに求めても、良いアイディアや解決策は出てこないと思った方が良いです。課題を感じていない人たちが「おお！なんて便利なんだ！」と目覚める、なんてことは起きません。困っている人、課題を感じている人からはじめる。それが王道です。
まとめ
長くなりましたので、大事なポイントをおさらいしておきます。
一部の部署では活発に使われてるんだけど、それ以外の部署・メンバーに広がらない。
こういう状況で、SaaSを社内で広げるためには、
ある部署でうまくいった「やり方（ツールの使い方）」を横展開すれば、うまくいくわけではない。
課題のない部署に解決策（ツール）を押し付けない。「それ大変じゃない？」「困ってますよね」とアプローチする。
「やり方」ではなく、「変革プロセス」を繰り返す。やる気のある人だけを支援する＝勝ち戦しかやらない。
カジュアルな場で似たような悩みをお聞きしたり、ご相談を受けたりする機会がこれまで本当に多くあり、さまざまな形でアドバイスをお伝えしてきました。中にいると気づきにくいことが多いので、「外の視点」をうまく活用できると良いと思います。
もちろん私にご相談いただければお役に立てる部分もあるかもしれませんが、まずはこのnoteに書いたことを実行いただくだけでも効果があると思います。皆さんの社内推進がうまくいくことを願っています！
もし「ちょっと個別に相談したい！」という場合は、こちらからご連絡ください。初回のご相談は無料です。
いただいたサポートはありがたく次の記事制作に役立てたり、他のクリエイターさんの記事購入に使わせていただきます。