DXの第一歩は、SaaSを使いこなすこと

どうも、エンジニアのgamiです。

LayerX代表 福島さんのインタビュー記事がとても良かったです。

日本のDX、難しく考えすぎでは？　LayerX代表 福島氏が語るDX推進の処方箋

特に良かったのは、SaaSについて語っている次の部分。

もっとシンプルな話だと私は捉えていて、たとえばSaaSを使うことが、DXの第一歩だと思います。
（中略） DXを本気で進めたいのなら、デジタルのスピード感覚に慣れ、デジタル的な感覚のビジネスリテラシーをもって意思決定し、トライ＆エラーを繰り返し学習する組織や意思決定できる構造を、ちゃんと根付かせることのほうがよっぽど重要だと思います。

DXについての議論で、大上段の話から始めて結局何をやればいいかよくわからなくなっている事例を目にします。それに比べて、「SaaSを使う」という具体的なステップを提示しているのが、良い割り切りだなと思いました。

LayerX福島さんのインタビュー記事、最高だった。大事なことはシンプルだ。

↓特に刺さった部分

・DXの要は高速に学習を回せる組織づくり
・その第一歩はSaaSを導入して業務で使うこ
と
・SaaSを導入しまくっても埋められなかった領域が、自社の競争優位の源泉になる
https://t.co/DsOvwRU1zW

— gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) June 25, 2021

一方で、どうしてDXの第一歩はSaaSを使うことと言い切れるのかわからない人も多いと思います。そこで今回のnoteでは、DXとSaaSをつなぐ補助線を引いてみます。

DXとは、デジタル活用によるアジリティの獲得

DXとは何かについては、これまでのnoteでも何回か取り上げています。そして考える度に自分の中のDX像が更新されていきます。

最近、ところてんさんの「ビジネスパーソンのためのDX入門講座エッセンス版」というスライドを発見しました。DXの全体像がコンパクトにまとまっているので、もうこれでいいじゃん感がありました。

「DXとは何か」を説明するの面倒くさいなと思ってたけど、このスライドをぶん投げればいいことに気付いた。感謝しかない。

「ビジネスパーソンのためのDX入門講座エッセンス版」 https://t.co/fC4Zxo1NwU

— gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) June 24, 2021

このスライドの要点を一言でいうと、「DXとはデジタル活用によってアジリティを獲得することである」です。実際には「デジタル活用」と言っても色んなレベルや目的がありますが、「組織のアジリティが重要である」という視点は受け入れやすい感じがします。デジタルなプロダクトは作ったり壊したりが簡単にできるので、あれこれ議論する前に作って運用しながら学習サイクル回した方が短時間でより多くの成果を得られるよね、みたいな。

ちなみに、アジリティとは敏捷性のことです。文脈に合わせて意訳すると「サクッと試したり適切な意思決定を素早くできたりする性質」といった感じでしょうか。アジリティを形容詞にすると、アジャイルになります。

このDXの定義に合わせて「DXの第一歩はSaaSを使うこと」というのを言い換えれば、「組織はSaaSを活用することでアジリティを獲得できる」となります。ちょっとわかりやすくなりましたね。

「SaaSを組織として使いこなす」とはどういう状態か？

もちろん、「DXの第一歩はSaaSを使うことだ」というのは、個人でGoogleスプレッドシート使ってますとか、そういう話では足りません。DXの第一歩としての「SaaSを使う」というのは、「SaaSを組織として使いこなす」ことが必要です。

さて、「SaaSとはWebブラウザで使える業務アプリケーションである」と説明されることがあります。それは全く間違っていないのですが、ちょっと本質を外しています。GoogleスプレッドシートはSaaSですが、単に「Webブラウザで使えるExcel」ではありません。SaaSとはスタンドアローンで使うソフトウェアではなく、ITシステムです。テクニカルに言えば、SaaS製品の裏側にはたくさんのサーバーがあります。SaaSを契約するとは、そのサーバーリソースの上で稼働するシステムの利用権を買うということです。大抵はそのサーバー上にデータベースがあり、複数の社員が同じデータに対して更新したり閲覧したりできます。

かつては、こうしたITシステムを構築するにはそれ相応の時間やお金や専門技術が必要でした。SaaSはその前提をぶっ壊して、現場社員が自分たちに必要なシステムの構築・運用を主導できる夢のような世界を作りました。たとえば人事・労務部門の人が「人事労務を効率化するシステム欲しいわー」と思ったら、SmartHRのWebサイトで会員登録するだけですぐに使い始められるわけです。

現場社員が自分たちの業務で使うシステムを自由に選んだり運用したりできるというのは、当然、組織のアジリティに直結します。たとえば人事部がNotionを使って採用サイトを自分で運用できるようになると、サイトの文言や構成を直すのにいちいち情シスに依頼しなくても済むようになります。また、優れたSaaSプロダクトにはその業務のベストプラクティスが詰め込まれているので、SaaSをちゃんと使うだけで自社の業務プロセスを人類が導き出した正解まで一気に近付けることができます。

もちろん、「SaaSを使う」ときの広さ（何人が使うか）の話以外に、深さの話もあります。ここでは、「SaaSを使いこなす」というのを「コアに近い業務プロセスの中で自然とSaaSを使っている状態」と定義します。たとえば組織や事業にとって重要なデータがSaaSの中で管理されていたりすると、SaaSを使いこなしている感じがあります。Salesforceに貴重な商談や契約のデータが全部入っている、などなど。

SaaSの価値を活かす組織、殺す組織

僕が最近『未来を実装する』という本にハマっています。本の中で、電気というテクノロジーが蒸気機関をどのようにリプレースし社会実装されたのか、という例が紹介されています。

電気モーターの場合、蒸気機関と違ってエネルギー消費量の多い機械を動力源の近くに置く必要もなくなりました。その結果、従来の蒸気エンジンを中心に考える工場と比べて、全く異なる配置の工場設計ができるようになりました。これによって「流れ作業方式」と呼ばれる大量生産のやり方が確立したのです。ヘンリー・フォードは「機械を作業順に置くことができるようになり、作業の効率が2倍になった」と述べています。
（『未来を実装する』2. 社会実装とはなにか）

重要なのは、工場の蒸気エンジンをただ電気モーターに置き換えただけでは、電気というテクノロジーの価値を活かせないということです。

SaaSも同じで、既存の外注オンプレITシステムをただSaaSに置き換えようとするだけでは、SaaSによって本来得られる価値は半減してしまいます。「SaaSをトップダウンで導入すれば解決！」みたいな単純な話じゃないということですね。

なんか、ITとかデジタルをめぐるかなり多くの問題が
「技術を導入すれば課題が解決されると思ってしまう」
という誤解から来ている気がしてきた。
課題を感じるのも、課題を解決するのも、人間だ。

— gami@デジタル教育系YouTuber兼エンジニア (@jumpei_ikegami) June 20, 2021

従来型の企業がSaaSの価値を引き出すには、仕事の進め方それ自体を変革する必要があります。たとえば現場に近い部署がSaaSプロダクトを使いたいと言ったときにセキュリティチェックや稟議を通すのに半年かかりますという状況では、アジリティも何も無いわけです。また、せっかく導入したSaaSの運用を外部のパートナー会社に丸投げしてしまっては、「現場の社員が自分たちの業務で使うシステムを運用しそこから学習する」というSaaSの価値を享受できなくなるわけですね。

ということで、冒頭に載せたLayerX代表 福島さんのインタビュー記事にあった、「SaaSを使うことが、DXの第一歩だと思います」という発言の僕なりの解釈は次の通りです。

・DXを実現するには、デジタルを活用して組織のアジリティを上げる必要がある
・SaaSを使うと、現場に近い部門が自分たちの業務に使うシステムの導入や運用を主導でき、アジリティが上がる
・SaaSを多く導入してその良さを最大限活かすには、（DXの文脈で語られるような）組織変革が前提となる

もちろん、SaaSを使いこなすことはDXの第一歩でしかありません。一方で、SaaSの運用を通じて組織のメンバーが「デジタルの流儀」に慣れることは必ずその先のDXにつながります。既存SaaSの組み合わせだけでは実現できない領域が見えてきたら、そこが自社の競争優位性の源泉かもしれません。その領域で自社の独自プロダクトを開発できれば、きっとDXが目指すところの「デジタルを前提とした独自の価値創出」につながるでしょう。

従来型企業がSaaSを導入するとき、まずどうなるか？

以上が今回書きたかったことです。

さて僕は現職で、エンジニアの立場からSaaSの導入支援やテクニカルサポートをしています。実際、従来型の企業がSaaSを導入するといった現場に出くわし、従来の仕事の進め方との摩擦を感じるケースもあります。

最後にマガジン購読者の方に向けて、「仕事の進め方を変えないとSaaSの価値を引き出せなさそう」と感じた具体的な事例を（適度にぼやかしながら）紹介します。

わかりやすいのは、導入までの意思決定に時間がかかるケースです。すぐに導入して試せるというのはサブスクSaaSの価値ですが、社内事情によって「すぐに試せる」という価値を享受できないのはもったいないです。もちろんSaaSといっても価格帯はピンキリなのですが、「とりあえず安いプランで試して違ったら解約しよう」みたいな発想になりにくい傾向はあります。

関連して、導入前にとにかく安価にPoCをやりたがるというのもアンチパターンになりがちです。「PoC期間中は安くしてください」という交渉をして、導入失敗のダメージを減らしたいということですね。しかし「今はPoCである」みたいな気持ちで運用すると、結局中途半端になって判断できなくなるということが多発します。とりあえず導入して、本気で運用して、ダメだったら壊して別のSaaSにリプレースしよう、というマインドの方が長期的にはアジリティ高くなります。

せっかくSaaSを導入したのにSIerや運用会社に運用を丸投げしてしまうケースもあります。多くの場合、SaaSをちゃんと運用するのは大変です。業務プロセスを整理して必要な機能やデータを定義したり、運用ルールを決めて周知したり、使ってみて微妙だったところを改善したり。一方で、これらを現場社員自身が経験しスキルとして身に付けることは、システム内製化の第一歩です。もちろんプログラミングなどの専門スキルが必要なケースもありますが、運用全部を丸投げするのは大切な学習機会をみすみす逃してしまうことにつながります。

過度なセキュリティポリシーによってSaaSの導入が頓挫するというケースもあります。新しいシステムを導入するとき、そのシステムが抱えるセキュリティリスクを事前に評価することはガバナンス上とても重要です。一方で、「管理画面にアクセスできるIPアドレスを制限できないと導入できない」みたいなルールがあると、せっかく便利なSaaSでも採用見送りになったりします。「多要素認証が必須」とかならまだ本質的な気がしますが、やたら「通信元IPアドレス制限！」とか「通信先ドメイン制限！」みたいな話が出てくるのは割とつらいです。

ちなみに、データの保管場所の問題もよく出てきます。先日もLINEのデータが中国や韓国で保管されていたみたいなニュースがありましたが、「個人情報は国内サーバーになければいけない」というルールを採用している会社はたまに見ます。このあたりは業界特性に依るので仕方ないかなーとも思うのですが、国内SaaSでもGCPやAWSのサービスで海外リージョンを使っている場合があり、業務遂行上は入れた方がいいデータがポリシーの問題で格納できなかったりします。

関連して、SaaSの提供をしていると「このチェックリストの項目を満たしていないと御社のSaaSは導入できません」みたいな長ーいリストを渡されることがあります。中にはオンプレシステムを前提としていて依頼してる本人たちもよくわかってない秘伝のチェック項目とかがあり、香ばしい感じです。特に単価の安いSaaSはそのようなチェックリストの確認にコスト使っても割に合わないので、「じゃあ使わなくていいです」と言われたりしそう。機会損失ですね。

思いついた事例は以上です。全体的に、「試しながら学習する」とか「信じて任せる」みたいなマインドが組織に求められることがわかりますね。

さて、こうした事例を挙げると「これだからレガシー企業はダメなんだ」という論調になりがちです。しかしこうした現代のビジネスにそぐわないルールも、かつては正解だったはずです。SaaSの導入という具体的なプロジェクトを通じて、こうしたルールを新しい正解に合わせて少しずつアップデートしていくことが、まさにDXの第一歩といえるでしょう。