業務のためにSaaSを選定するテックリサーチの思考の流れを言語化してみた

こんにちは。那須野です。

今、ビジネス現場はSaaS（Software as a Service）に溢れています。稼働の問題で実質不可能だったことを実現するためのツール、技術的に不可能だったことを実現するためのツール、今までできていたことをより効率的に実現するためのツール、ビジネスのリスクを抑えるためのツール、etc...

最近だと、コロナ禍で多くの企業がリモートワークを強制される中で、新しい働き方をビジネスとして成り立たせるために新しいツールに手を出した・・・という行動パターンに思い当たる節がある方は少なくないでしょう。飛躍的な変化を、早急にもたらすには、完成されたツールを導入するのが手っ取り速いということです。

とはいえ、とりあえず見つけたツールをさっと導入すればビジネス現場の問題がたちまち解決するかと言うと、必ずしもそうではありません。というのも、

• 期待していた運用ができないことが導入後に発覚した
• 度重なる業務要件の変化にシステム仕様が耐えられなかった
• 仕様バグや実装バグが多くてどうにもならなくなった
• 細かいUIの煩雑さで運用コストが極大化した
• 管理部門のメンテナンスコストの高さに唖然とした
• 利用規模拡大で費用が急上昇してペイしなくなった
• 自社の特殊な環境制約のせいで運用に乗らなかった
• ユーザー部門に浸透しなかった
• リソース制限に引っかかる不安定さが露呈した
• カスタマイズにコストをかけられずに運用回避を余儀なくされた
• PC環境の変化でツールを使えなくなった
• 管理者不在で誰も手を付けられなくなった
• 多数のシステムが乱立して何が何だか分からなくなった

など、ツール導入にまつわる地雷は話題に事欠かないからです。つまるところ、うまく効果を出すにはそれなりにしっかりと調べてから導入する必要があるということです。

そこでこの記事では、自部門、他部門、もしくは顧客の業務のためにSaaS（Software as a Service）を選定するプロセスとしてのテックリサーチについて、私の思考の流れをモデル化して言語化してみたスライドを公開しようと思います。

正直日々鍛錬の状態なので、ご先達に指摘されたり、1年後に読み返したりすると恥ずかしい内容もあるかもしれませんが、それもご愛敬ということで。