SaaSを活かすか殺すかは、情報システム企画構想の質が決める

企業の中で利用されるソフトウェアの多くが、SaaSで提供されるようになりました。

PCやサーバへの入れ込みをせずとも、ネットに繋がり、ブラウザでアクセスすれば、自由自在にデータを共有でき、いつでもどこからでも、業務を行うことができる。2025年現在からすると、当たり前すぎてなんの不思議はない話ですが、考えてみれば、そんな世の中になったのは、たかだかここ10、20年ほどのことです。

ふと、見回してみると、ときはまさにSaaS時代・
ありとあらゆる業務のためのソフトウェアが開発され、販売されています。

営業系	生産・オペレーション	人事総務系	バックオフィス系
SFA(営業支援システム)	ERP	勤怠管理システム	財務会計
WEB接客	生産管理	ストレスチェック	予算管理
CRM(顧客管理システム)	工程、タスク、課題管理	人事情報、人事評価	管理会計
名刺管理ソフト	在庫管理	タレントマネジメント	固定資産管理
ウェビナーツール	原価管理	給与計算、労務管理	BIツール
動画配信	施工管理	採用管理(ATS)	データ連携
自動チャット応答	倉庫管理	eラーニング	ワークフロー、文書管理
マーケティング自動化	車両管理	適性検査	経費精算
CMS/Web制作	会員管理	採用広報、ブランディング	電子契約、契約書管理
アクセス解析/SEO	イベント管理	パート、アルバイト採用	債権管理
メール配信システム	決済代行	1on1支援	与信管理

しかし、悲しいことに、情報革命は、それでめでたしめでたし、とはなってはおりません。

多くの業務現場は、一向に、まったく、便利にはなっていません。

SaaS導入のしくじりパターン

ITサービスを導入したけど、期待通りにならなかった、というものでよく見かけるものとして、以下のようなケースがあります。

例①
「カスタマイズ自由自在なCRM」を導入し、大喜びでカスタマイズした。メンバーに使うように通達したが、なんだかよくわらないが、不便だ不便だと言われ、活用が進まない。

例②
導入後しばらくの間は、問題なく使えていたが、新たな業務課題が発生し、解決をする必要が発生した。しかし、ベンダに連絡しようと思ったが、契約書類が見当たらない。電話をかけてみたも、担当者が誰かもわからない。
カスタマーサポートやカスタマーサクセスの窓口に連絡してみても、待たされたり、同じことを何度も聞かれたりして、一向に解決につながらない。誰に頼ればよいかもわからず、途方に暮れてしまった。そのうち、解決を諦めて、放置した。

例③
長年、業務システムや自社サイトを運用してきた。継ぎ足し継ぎ足しでベンダに要望を伝えながらやってきたが、気がつけば、誰がどこで、どの画面を触ったらホームページのどこが更新されるのか、誰も知らない、わからない、よくわからないシステムになってしまった。
いきなり致命的に業務が止まるわけでもないが、システム更改もままならず、業務や業績の足かせとなっている。

むかし、「ソフトウェア」のソースコードがぐちゃぐちゃにこんがらがって「スパゲッティ化」してしまう、という言葉がありました。思えばそれは、まだ牧歌的な時代、だったのかもしれません。

クラウド＆SaaS時代は、やたらめったら、思いつきでITサービスを導入してしまった結果の「業務のスパゲッティ化」が起きています。

情報システム企画構想のコツ

業務のスパゲッティ化は、結局のところ、情報システムに対する企画構想に、その根本原因があるのです。

例えば、「人材紹介業」を例に考えてみましょう。

紹介業の最大の特徴は、例えば製造業や金融業とは異なり、在庫や資本を持たずに、人的ネットワークと情報のみにより、収益を生み出すことができる、という点です。

2020年代現在、一般的な企業への人材紹介業における斡旋料の相場は、「理論年収の30%程度」が標準的な相場とされています。年収1,000万円の人が1人成約したら、300万円の売上になるわけですから、コンスタントに成果をあげることができたら、利益率の高いビジネスとなります。
ところが当たり前ですが、世の中そんなうまい話が転がっているわけはありません。小規模事業を営む分には、確かに資本や設備は要さないものの、そもそも人材紹介サービスとは、原理的にはタイミングや運の要素も強く、一定の労働力を投下したら、必ずこれだけリターンが得られる、というものではないのです。

理論上は、活動量や規模そのものを大きくすれば、これを確率論としてコントロールできるようになります。実際、数十名、数百名といった単位で組織的にこうした事業を成り立たせている企業はたくさんあります。

その組織の中心には「情報システム」が不可欠となります。

人材サービス企業の情報システムは、個人情報や履歴書、職務経歴書、求人情報や企業情報など、ありとあらゆる情報の魔窟とでも呼ぶべきもので、とかく複雑怪奇になりがちです。その結果、データベースに情報が入っていても、欲しい情報を検索することが、できない、なんていう残念なことは、実によくあります。
業務プロセスを標準化をしようと、いくらルールを周知しても、きれいなデータにならない。ゆえに、システム化をしたつもりが、いつのまにか、結局属人化してしまい、生産性がちっともあがらない、なんてことも、よくあります。

そうなると、人間、考えるのが面倒になってしまい、

「結局は、紹介するタマがないとしょうがないんだから、とにかく、広告を打つ」
「とにかく、スカウトを打ちまくる」
「人間がやるのは大変だから、RPAで自動化してみる」

といった方向性に比重が置かれていく、というのも、珍しくありません。実は、こうしたことをやっていると、いつのまにやら経費も手間もかさむばかりで、生産性もあがりません。

うまくすれば利益率の良かったはずの人材ビジネスが、やってもやっても儲からない、労働集約型の苦行になってしまったりします。

業務効率を高めることで、極めて高い収益率を期待できる、紹介ビジネス。
しかし、現実としては、様々な要因により、なかなかそう理想通りにはいかない、紹介ビジネス。

これを、情報システムという面で支えるために、なにをどんな順番で考えるべきでしょうか。

（ちょっと脱線、参考に）
紹介業というビジネスモデルは、農耕や都市経済とともに発生した、人類史における最も古いものの一つです。現代においては人材紹介業や不動産紹介、M&A仲介など、様々な紹介業が営まれていますが、例えば江戸時代にも「口入れ屋」という事業形態がありました。口入屋は、例えば武家や商家の注文通りを受け、奉公人を紹介し、その手数料を双方から貰う、といった商いをしていました。同業者同士の組合や、大きな口入れが小規模な事業者を束ねるグループ経営も行われていたそうです。また、一方で、虚偽の情報による詐欺まがいの業者や、人身売買に近いような悪質なケースなどもあり、それをいかに規制するのか、という議論がなされていたこともあったとのこと。
参考：
江戸時代の奉公人制度と日本的雇用慣行
江戸時代の奉公人調達・斡旋に係わる 事業・業者の諸類型試論

情報システム企画構想の第一歩：「大前提を整理する」

企画構想の第一歩は「基本的な大前提を、ざっと並べてみること」です。

①根本的な事業構造と、基本的なサービス提供の流れ
・紹介業には、必ず、取引の相手を求める「売り手」と「買い手」が存在する
・その双方から、「一般公開していない内部情報」と「取引における希望条件」を取得する
・両者の情報を蓄積し、互いに成約する可能性の高い候補を選び出す
・双方に対して、情報の開示を行い、選考や検討を促す
・互いの交渉状況がスムーズに進むようにサポートする
・契約が成立し、売買が実行されたら、費用の決済を実行する

②以上の「基本的なサービス提供」を支えるためにある業務や仕組み
・紹介事業者としての信用を得るための社会への情報発信
・より魅力的な「売り手」を集め、取引への希望条件を確認する活動
・より魅力的な「買い手」を集め、取引への希望条件を確認する活動
・競合でなく、自社を選んでもらうための認知獲得活動

③それらの各種業務を支えるための、企業としての活動基盤
・経営戦略の策定や営業計画の立案、実行、計数管理
・自社の従業員の採用活動や教育活動
・従業員への労務管理、評価や人事異動など
・トラブルが発生した場合への、キャンセルや返金も含めた各種対応
・かかった経費や人件費等を集計し、決算し、税務を行う
・監督官庁や業界団体等への報告を行う

江戸時代の口入れ屋は、和紙と筆、そろばんと頭脳を用いて、これらを捌いていたわけですが、令和において以上の業務を円滑に回転させるには、その中心に基幹となるシステム基盤を置くのが通常です。

完全にひとつのソフトウェアでそれをまかなうのは難しいため、主にマーケティングや販売管理面を担うもの、主に社内の業務管理をするためのもの、主にコーポレート・マネジメントを実施するためのもの、といった具合に、主なシステムを導入し、必要に応じてそれらをつなぎあわせる、ということをします。

ちなみに、図のなかでは、ソフトウェア同士の連携について補足していますが、人と人もつなげていかないと、業務は回りません。人と人をつなげていくために、SlackやTeams、LINE、zoom、社内WIKIといったコミュニケーションツールが導入されます。

これらのなかで、特に社内の業務管理システムに着目しますと、それは、

●小規模事業であれば、各個人のPCスマホ、EXCELやメーラー、社内の共有ドライブやgoogleDrive
●中規模以上であれば、業界向けに提供されているSaaS
●大組織の場合は、スクラッチ開発による自社専用の業務基盤

といったところが、典型的な選択肢となります。

しかし、その発想で安易に情報システムの基盤を決め込んでしまうと、思いも寄らない不便を招いてしまうかもしれませんので、要注意です。

例えば、「小規模事業だが、今後大きくマーケットが伸びる領域を狙っていて、最初のうちから高度にシステム化しておかないと、後々、規模が拡大したときに、大変困ったことになる」という場合もあります。

逆に、「事業規模はそれなりにあるが、個々の社員の裁量の広さが重要なビジネスモデルだから、あまりシステムで統制してしまうと、かえって足かせになり、危ない」という場合も、あるのです。

情報システムの企画構想は、まさに「基盤選び」から始まります。土台が固まってないのに、そのうえに建物を立ててしまうと、絶対に、安定しません。

では、その基盤は、どうやって選ぶのか。考える順番を、次の項で、解説します。

情報システム企画構想の第二歩：「基盤を選ぶ」

たとえば、「売り手を大量に、素早く集めたい、集客したい」と考える事業者は、それを叶えるために、複数の選択肢を検討します。

「紹介業」というビジネスモデルそのものの、根幹自体は普遍的ですが、事業活動を展開するドメインやマーケット、セグメントが異なると、どの施策を優先すべきかは、まったく異なりますので、いわばここに、その企業や事業、ブランドの、個性や独自の戦略性があらわれます。

●とにかく手を動かし、足を運んで行動し、新規営業を頑張る
●過去の顧客に対する掘り起こしや、紹介キャンペーン
●チラシや雑誌などの紙の広告
●テレビ、ラジオなどのマス広告
●自社サイトのSEO対策やSNS運用などの、デジタル系オーガニック施策
●SEMやSNS広告、youtube広告などの、デジタル系広告施策
●展示会やイベント開催などの、リアルの場を通じた露出
●プレスリリースなどによるメディアへのアピール
●同業他社との協業による、レベニューシェア
●業界内のソーシング事業者の活用

これらにおける、どの施策を実行するにも、いまどきは、なんらかのソフトウェアを用います。
スケジュール調整やメール、チャット、といったものもあれば、他社のシステムへの入稿作業、管理システム、などなど。

それらのソフトウェアを個別単体に評価すれば、大変便利なものです。しかし、横断的に、複数のソフトウェアを使う、となった場合、これがどうにも厄介なものです。「総体としての情報システム」の利便性は、下がってしまうのが通常です。

それは、人間には「わかりきった情報を、決まり切った形式で、いちいち手作業で入力させられること」を嫌う、という根本的な習性があり、
一方の機械には「決まり切った形式で、適切な仕様で情報をもらえないと、処理できない」という、根本的な性質があるからです。

情報サービス産業における業務環境は、長らく「システム入力が面倒」という問題に悩まされてきましたが、どんなに自動化技術が発達しても、一向に現場は改善されていかない、という不思議な現実が、存在します。

ここで、情報システムに対する究極の理想は「あらゆる業務がシームレスにつながり、オールインワン、ストレスフリーに対応可能。業務要件の変化があっても、手軽に柔軟に更新ができて、スピーディに改善可能！」というものになるでしょう。

しかし、そんなものは、企画構想が駄目なうちは、無限の資源を費やしても、絶対に完成しません。

そもそも、事業運営における各種の施策そのものが、前提として、有限の資源のなかで、必要なものに優先順位を付けて、展開していくはず。であれば、先に考えるのは「いかなる施策を展開するか」です。そこが見えて初めて、情報システム基盤に求める要件や仕様が明らかになる。

SEOに力をいれるなら、検索エンジンが受け付けやすいデータ構造、キーワードについて敏感にならざるを得ません。
ソーシング事業者を活用するなら、それを前提としてデータのやりとりがしやすいような、形を作っておく必要があります。

そのような前提をおさえずに、思いつきでソフトウェアや施策を選んでしまうと、データとデータ、業務と業務の接合性が悪い、ただただ生産性の低い情報システムが出来上がってしまいます。

まとめますと、手にするべき情報システムの基盤を選ぶための順番は、以下の通りとなります。

①事業戦略をもとに、連携したい個々のソフトウェアや外部サービスを絞り込む

②それらの中心に置くものとしてふさわしい、連携性と拡張性を持つ基盤を選ぶ

ちなみに、今現在すでに何らかの業務システムを利用していて、そこから新たなものに移行したい、となった場合は、それもひとつの「連携するソフトウェア」に入ります。移行プロジェクトでは、移行元と移行先の仕様が全然違うことによる中途トラブルがよくありますが、こうしたものも、構想段階でしっかりと計算にいれておきたい話です。

情報システム企画構想の第三歩：「データモデルを磨く」

「あらゆる業務がストレスフリーになる」を成功基準にした場合、世の中の情報システム導入プロジェクトの98%は、間違いなく、失敗しています。（筆者の個人的には、99.9%は、と、言いたいところですが・・）

ちなみに、「遅延やコスト超過などの失敗状況に直面し、苦労したが、なんとか導入できた」というプロジェクトは、約66%、というのが定説です。

「他の手段で目的を満たした」を成功基準にしたならば、失敗確率は2%程度に下がります。

では、極めて例外的な、ごく一部の、2%の「導入大成功」では、何が起きているのか。

それは「事業モデルと組織モデルが明瞭に定義され、情報システムの企画構想を的確に表現できたおかげで、データモデルとシステム構成が、適切な塩梅に調整されたから」という一点に、集約されます。

その究極の根本は、「データモデル」です。

では、「データモデル」とはなにか。

「発生するレコードデータの内部構造と、その外延であるテーブル同士の構成、関係」のことです。

これを、システム企画者の勝手気ままな願望で描いてはなりません。

必ず、どんな事業にも、事業戦略があります。
まず、事業戦略があり、そこから導かれる、「関係性を持つべき外部連携システム」がある。
そこに加えて、自分たちのスキルやリテラシ、組織構造を加味した「最高効率の業務像」がある。

これらを重ね合わせて、始めて、正しいデータモデルを描くことができます。

データモデルを、軽く考えてはいけません。例えば「性別」ひとつとっても、それをどのような選択肢マスタとして用意するのか。サービスを展開するうえで、性別情報を管理することが必要な場合、その選択肢の作り方は、その事業者の世界観や社会観を反映したものになるはずで、そうしたディテールが、顧客体験の質にダイレクトに響くものです。特に、デジタル上のUXは情報産業にとって諸刃の剣です。

デジタルデータでこうした情報を扱うにあたって、最も根本的な「データのあり方」を突き詰めて検討することは、ある意味では事業戦略を考えることそのものである、といっても過言ではありません。

「第一歩」の話も含めて総括しますと

①自社事業の大前提となる構造や、根本的な業務の流れを整理する

②事業オペレーションのなかで活用したいソフトウェアや外部サービスをリストアップする

③それらとの連携が可能なシステム基盤を選択する

④事業コンセプトやマーケット、顧客に提供したい体験とはなにか、を突き詰める

⑤以上の考察を踏まえ、自社のビジネスにおける、根幹となるデータモデルを磨き込む

⑥実装するための、具体的なシステム構成を描く

⑦データのインプット、アウトプットフローやインターフェイスを定義する

⑧最終的に、ユーザーフレンドリなUIや機能となるように、細部を作り込む

こんな順番で考えて初めて、業務システムは、ストレスフリーなものを作ることが可能になります。

ITセンスを磨くコツは「業務の適切な切り分けと分配」

実は、世の中の情報システム企画は、この「あるべき順番の、逆」で検討されていることが通常です。

①こんなUIがいいな

②あんなメール連携機能がほしい、こんな自動化機能がほしい

③どのSaaSベンダと付き合うかは、営業担当者の雰囲気と値段で決める

④だって、項目は、ノーコード、ローコードでさくっとカスタマイズすればOKだから！

こういう順番で情報システムを企画構想するのは、「キャンプをしたこともないのに、デパートのなかでキャンプギアを揃えて、いきなり山に繰り出す」といった行為に似ています。

「RPA？知ってる知ってる、聞いたことある！便利だよね！」

「AI？知ってる知ってる！便利だよね！」

そのようなレベルの議論をしているようでは、このAI時代は、到底乗り切れるものではありません。

ちなみに、「AIを使えば、面倒なことはいくらでもほったらかしで大丈夫になる」といった期待感が膨らみ続けていますが、2025年現在においては、それは幻想です。LLMやAIエージェントは、非常に高価で、遅いサービスです。作り込みに成功したら、局所的には面倒な作業から人間を開放してくれますが、どこに使うか、という知恵を絞るのは大切です。

ビジネスロジックというものは、LLMの得意とする自然言語処理的なものや、曖昧な情報処理が必要な局面もありますが、一方で、論理演算によるルーチン処理をしたほうが、よっぽど生産効率が高まる、という部分もあります。もっといえば、ロジックでは対応できない、カオスな問題や不合理な問題もあります。

情報システムは、極めてハイコンテクストな、論理と抽象のワンダーランドです。

各種の問題を、適切に分解し、適切に、人と機械に分配することができれば、かなりストレスフリーな情報システムが構築されますが、それに失敗したら、非常に過酷な、ただただ面倒で、労働集約的な業務環境が、できあがります。

その世界を生き抜く、たった一つのコツは、ITに詳しくなること、では、ありません。

あるべき事業の姿を考える。
あるべき組織の姿を考える。
あるべき業務の姿を考える。
評価や育成の仕組みを考える。
踏み出したい市場を考える。
向き合いたい顧客を考える。

つまり、経営戦略、事業戦略を、立てましょう、ということです。

実際のところ、自社独自の戦略を考えるのは、かなり知的負荷が高い話ではあります。とはいえ「とりあえず、定評のあるパッケージやSaaSを入れておけば、戦略が弱くても、なんとかなるだろう」ぐらいの軽い感覚で、経営活動を行ってしまうと、結局のところ、冒頭で申し上げたような「業務のスパゲッティ化」が起きてしまい、にっちもさっちもいかなくなってしまう、というのも、現実です。

企業経営にはコンセプトや戦略というものが、絶対に欠かせません。以上のことをきちんと具体化し、ドキュメントとして表現すれば、あとは、腕の良いITベンダにそれを渡せば、ほどよく合理的なものが出来上がるはずです。以上、ご参考になると幸いです。