SaaS時代の社内システム導入は「システムを開発」するのではなく「システムに迎合する」

社内システムにおいてはSaaSソリューションを活用するのが一般的になっていますし、仮にスクラッチで開発をするとしても便利なライブラリやフレームワークが充実しています。これらを活用することで、システム開発はこれまでの何倍も簡単になるはずなのに、システム導入はあまり簡単になっていない気がします。これがなぜか考えたのでシェアします。

結論としては、SaaS時代はシステム導入=システム開発ではなく、システム導入=システムに合わせた業務変革となるため、システム導入の難しさの種類がシステム開発それ自体やシステム移行の難しさから、業務や人（働き方）を変えることという別の種類の難しさに変わったためだと思います。

「システム導入」は「業務に合ったシステムを開発すること」だった

スクラッチ開発の時代は、システムを導入するということは業務に合ったシステムを開発することを意味していました。

初期のシステム導入（紙業務、手作業をシステム化）
初期のシステム導入では、これまで紙や手で行われていた業務がシステム上で行われるようになりました。この時代は、システムは業務に従属すべきだと考えられ、従業員が行っている業務に合わせてシステムが作られました。この時代のシステム導入の難しさは、システム開発それ自体や、システムに慣れていくことだったと考えられます。

システム刷新（オープン化など）
技術が進み標準化されてくると、基幹系システムのオープン化など、既存システムを新システムで置き換えるというパターンのシステム導入が行われるようになりました。この場合、業務と現行システムは強く結びついているため、基本的に新しく作られるシステムはそれらに合わせて作られることになります。COBOLのコードをJavaコードに変換するような"コンバージョン"や"現行踏襲"という言葉が生まれたのもこの時代でしょう。この時代のシステム導入の難しさは、新技術を使ってどうシステムを作るかに加え、現行システムを理解することや、現行システムを止めずにいかに移行するかという新たな難しさが生まれたと考えられます。

「システム導入」は「システムに迎合し業務を変革すること」へ

SaaS時代のシステム導入は、これまでとは様子が異なります。システムにもよりますが、基本的にSaaSは特定の業務に特化しており、業界の標準的なユーザペルソナ（この業務にはこんな役割の人がいるよね、というユーザのタイプ）や業務プロセスが組み込まれています。これと現行業務と結びついた現行システムが出会うと何が起こるでしょう。

現行に合わせSaaSをカスタマイズする
これまでの発想でSaaS導入を行うと、SaaSが前提とする標準的な業務を無視して、現行業務に合うようにカスタマイズしていくことになります。

しかし、このやり方ではSaaSの価値を十分に享受することはできません。カスタマイズを行った機能は大抵の場合サポート対象外となり、自分たちで運用・保守が必要になります。また、スクラッチ開発とは異なりパッケージ製品としての制約があるため、そもそも現行業務に完全に合わせることは制約的に不可能であったりして、結果的にユーザから「このシステムなんか使いづらいね」なんて言われたりします。そこで、SaaSを使いこなすためには、SaaSを自分たちに合わせるのではなく、業務に合わせて自分たちが変わる必要があります。

標準に合わせて人と業務を変える
SaaSのシステムの仕様やそれが前提とする業務と自社業務が異なっているなら、むしろ自社業務の方が業界標準からずれていると考え、自社の業務や人（働き方）を変えていくのです。

このやり方では、これまで何カ月、何年もかけて行っていたシステム開発が不要になるため導入一日目から使い始めることができますし、システム運用・保守の大部分をSaaS事業者に任せることができるため、経産省のDXレポートで指摘されている「IT関連予算の多くが現行システムの維持・運営に費やされ、戦略的なIT投資に資金・人材を振り向けられていない」という問題の解決策となりえます。

ここにシステムを開発するという発想はなく、むしろシステムに迎合するという発想へとパラダイムシフトすることになります。そして、この場合において、システム導入の難しさはもはやシステム開発の難しさではありません。これまでの自分たちが信じてきた業務を疑い、自分たち自身が変わっていくことができるか、という問題になるのです。

システムに迎合するためのコツ　コストと納期を最優先にする

とはいえシステムに迎合するのは難しいです。特に御用聞きマインドが染みついたITエンジニアや、継ぎ足し継ぎ足しで独自に発展させた業務を守り続けてきた業務部門のメンバは、システムは業務に従属するのが当たり前だと考えており、システムに迎合するという発想を理解するのは難しいです。

そこで、誰でも理解できる、古くから伝わるプロジェクト評価指標であるQCDにある"コスト"と"納期"を使うのです。重要なのは"品質"を使わないことです。個別最適のカスタマイズ・システムの肥大化を避け標準に合わせていく際の説得方法として、ついついエンジニアは「全体最適が」とか「技術負債が」という言葉を使い、こちらの方が"品質"が高くなるんですよ、というアプローチをとりたくなってしまいます（私もそうでした）。しかし、彼らにとっての"品質"は「いかに現行通りに業務ができるか、どれだけ現行業務にマッチしているか」であるため、ここで戦っても説得することはできません。

そこで、「まずはお試しとしてコストと納期を優先させてスモールスタート・クイックウィンを得られるように導入を進めます。そのためにはシステムに業務を合わせるのが最も効率的です！」という言い方をすることで、より説得しやすくなるのではないでしょうか。そして、一度使い始めて便利さに気づいてしまえば、彼らも納得せざるを得ないのです。

2025年の崖

ちょっと話は飛びますが、経産省のDXレポートで「2025年の崖」という概念が提唱されています。2025年の崖の上には何があるんだろう？その崖を上るためには何が必要なんだろう？とよく考えます。様々な要素が必要だとは思いますが、私はこの崖を上るための一つの要素として、システム開発からシステム迎合へのパラダイムシフトがあるのではないかと考えています。