情報システムの50年史は『振り子』だった。IT統制の揺れ戻しがBizOpsを必然にした

株式会社テイクアステップ 代表取締役社長 兼 一般社団法人BizOps協会 代表理事の祖川慎治です。

この記事の要点（3行サマリ）

• 企業のIT統制は50年間、「集中」と「分権」の間を振り子のように揺れてきました。メインフレーム、Excel・Access、ERP、SaaS。フェーズが変わるたびに前の課題を解決し、新しい課題を生んでいます。
• 情報システム部門は「経営のためのIT」に軸足を置いてきた歴史と、コストセンターとしての予算制約により、「売上を伸ばす側のオペレーション」まで手が回らない構造的限界を抱えています。
• 振り子の歴史が問うているのは「集中と分権のどちらが正しいか」ではありません。「分権化した現場の力を殺さず、全体最適をどう実現するか」です。その答えとして必然的に浮上してきたのがBizOpsという機能です。

御社にこんな心当たりはありませんか。

• 各部門がそれぞれSaaSを契約し、同じ顧客のデータが部門ごとに微妙に違う形で存在している
• 情報システム部門に相談しても「基幹システムの保守で手一杯」と言われ、現場の困りごとが後回しにされ続けている
• 「全体を横串で見てくれる人がほしい」という声が現場から上がっているのに、それが誰の仕事なのか組織図上どこにも書かれていない

いずれも、偶然起きているのではありません。IT統制が50年かけて辿ってきた歴史の必然的な帰結です。この記事では、その歴史的な経緯と、なぜ今BizOpsという機能が求められているのかを整理します。

目次

1. 結論：IT統制は「集中と分権」を繰り返す振り子だった
2. 1970年代〜2010年代、4つのフェーズを辿る
3. なぜ情報システム部門は「攻めのIT」を担えないのか
4. 現場が自走した結果、何が起きているか
5. 課題の本質は「ツールの数」ではなく「接続の設計不在」
6. 振り子は「集中か分権か」を問うていない

1. 結論：IT統制は「集中と分権」を繰り返す振り子だった

企業とITの関係は、この50年間、一つの方向に進化してきたわけではありません。「集中」と「分権」の間を、振り子のように行ったり来たりしてきました。

情報部門がすべてを統制する時代があり、現場が自分たちでツールを使い始める時代があり、再び全社統合の機運が高まる時代があり、そしてまた現場が主導権を握る時代が来る。この繰り返しです。

そして今、その振り子はかつてないほど大きく「分権」の側に振れています。理由はSaaS(Software as a Service)の普及です。現場のマネージャーが情報システム部門の承認を待たずに、クレジットカード一枚で業務ツールを導入できるようになりました。

この記事で伝えたいのは一つです。BizOpsという機能は、誰かが思いつきで作ったポジションではありません。50年に渡るIT統制の歴史が、構造的に生み出した必然だということです。

2. 1970年代〜2010年代、4つのフェーズを辿る

歴史を振り返ると、IT統制は次の4つのフェーズを経てきました。

1970〜80年代：メインフレームの時代（集中化）

企業がコンピュータを使い始めた時代、ITは情報部門の専有物でした。部屋いっぱいの大型コンピュータを情報部門が一元管理し、他の部門はそこに処理を依頼する形で利用していました。経理の計算も在庫の管理も、すべて情報部門のオペレーターを通す必要がありました。

統制する主体が一つしかないため、混乱は起きにくい時代でした。ただし現場がやりたいことをやるには、情報部門の順番待ちが発生します。帳票一枚を出力してもらうのに数週間かかることも珍しくありませんでした。

1990年代：クライアントサーバー時代（分権化）

1990年代、パソコンが企業に一気に普及します。各部門の机にPCが置かれ、現場の担当者がExcelで独自の管理表を作り始めました。Accessでデータベースを組む人も現れました。情報部門を経由せずに、現場が自分たちの業務をITで回せるようになったのです。

現場の生産性は上がりました。しかし同時に、部門ごとにバラバラのExcelファイルが増殖し、同じ数字を複数の担当者が別々に管理する状態が生まれます。「この人がいないとファイルが開けない」という属人化も進みました。分権化は現場の自由度を高めた代わりに、データの分断という新しい課題を残しました。

2000年代：ERP導入ブーム（再集中化）

2000年代、この混乱を収束させるためにERP(統合基幹業務システム)の導入が進みます。バラバラだった会計・販売・在庫・人事のデータを一つのシステムに統合し、経営層がリアルタイムで経営状況を把握できるようにする。分権化で散らばったITを、再び情報システム部門の統制下に戻す動きでした。

ただしこのERP導入には偏りがありました。統合の対象は主に「経営管理のための情報」です。経理処理や在庫管理、人事給与を正確に把握する仕組みが優先され、「現場が売上を伸ばすためのオペレーション」は優先順位が低いままでした。営業の受注率向上、マーケティングのリード育成、カスタマーサポートの顧客満足度維持。こうした攻めのオペレーションは、ERPのスコープの外に置かれたのです。

2010年代〜現在：SaaS普及(再分権化)

2010年代、クラウド上で動くSaaSが普及します。かつてなら情報システム部門への稟議と多額の予算をかけて導入していたようなシステムが、安価な月額課金で使えるようになりました。現場のマネージャーが承認を待たずに業務ツールを導入できる時代です。

これは1990年代の分権化の「SaaS版」ですが、スケールがまったく違います。1990年代は部門内のファイルが増える程度でした。2010年代以降は、部門ごとに独立したクラウドサービスが次々と契約され、それぞれが独自のデータベースとAPIを持ち、独自のダッシュボードで数字を表示します。分散の度合いが桁違いに大きくなったのです。

この50年の流れを一覧にすると、次のようになります。

振り子が動くたびに、前のフェーズの課題を解決する代わりに、新しい課題が生まれています。今の「再分権化」フェーズで生まれている課題――SaaSの乱立、データの分断、全体を見る人の不在――こそが、BizOpsの必要性を生み出している構造的な背景です。

3. なぜ情報システム部門は「攻めのIT」を担えないのか

本来であれば、情報システム部門がこの再分権化の波をコントロールし、全社のIT統制を維持するはずでした。しかし、多くの企業でそれは実現していません。理由は、情報システム部門が抱える構造的な限界にあります。

限界1:「経営のためのIT」に特化してきた歴史

情報システム部門の歴史的な主軸は、経営のための基幹システム統合です。ERP・会計システム・人事システム・グループウェア。経営層が全社の数字を一元管理し、正確な意思決定を行うための基盤を整える。これが存在意義でした。この軸足は2000年代のERP導入ブームで確立され、今も多くの企業で変わっていません。

問題は、「売上を伸ばす側のオペレーション」――営業プロセスの最適化、マーケティングファネルの設計、カスタマーサクセスの仕組み化――が、この軸足の外にあることです。営業部門がSalesforceの商談ステージを再設計したい、マーケティング部門がMA(マーケティングオートメーション)ツールのリードスコアリングを見直したい。こうした「攻めのIT」に、情報システム部門は十分なリソースを割けていません。基幹システムの保守、ネットワークの維持、セキュリティ強化、社内ヘルプデスク。「守りのIT」だけで手一杯なのが実態です。

限界2:コストセンターとしての予算制約

情報システム部門は、多くの企業で「コストセンター」に分類されます。売上を直接生まない間接部門として、予算はできるだけ抑える方向で管理され、増員の稟議も通りにくい傾向があります。基幹システムの維持・保守で予算の大半が消え、残った予算でセキュリティ対策とインフラ更新をまかなう。「現場のSaaS運用を支援する」「部門横断のデータ連携基盤を構築する」といった投資は、優先順位が下がらざるを得ません。

情報システム部門の人員も慢性的に不足しています。IPA(情報処理推進機構)の「IT人材白書」によると、日本企業のIT人材の約7割がITベンダー側に偏在しており、事業会社側のIT人材は質・量ともに不足しています(出典:IPA「IT人材白書」)。少ない人員で基幹システムの維持からヘルプデスクまでカバーしなければならない。「現場のオペレーション改善」にまで手が回る余裕がないのは、構造的な必然です。

限界3:現場のスピードについていけない

かつてのオンプレミスシステムは、要件定義から導入完了まで1〜2年かかるのが普通でした。情報システム部門はこの「年単位のサイクル」に最適化されています。一方、SaaSは契約から利用開始まで数日、場合によっては当日です。営業マネージャーが月曜日に「このツールを使おう」と決めて、金曜日には部門全体で運用を始めている。従来の「稟議→検討→承認→導入」というプロセスでは、このスピードに対応できません。

結果として、現場は情報システム部門を通さずにツールを導入するようになりました。いわゆる「シャドーIT」です。ただし、これは現場が情報システム部門を軽視しているわけではありません。「情シスは基幹システムで手一杯だから、うちのことまで面倒は見てもらえない」と理解した上で、自分たちで何とかしようとしているのです。

4. 現場が自走した結果、何が起きているか

情報システム部門が対応しきれない領域を、現場が自分たちで埋めていく。この動き自体は、決して悪いことではありません。現場が自走できるスピードは、企業にとって競争力の源泉にもなります。

問題は、各部門がそれぞれ独自のSaaSを導入し、独自のデータを持ち、独自のプロセスで業務を回した結果、部門間のデータが断絶することです。同じ顧客の情報が、マーケティング・営業・カスタマーサクセスの3か所に別々の形で存在する、という事態が起こり得ます。

具体例で考えてみます。マーケティング部門がMAツールでリードを管理し、確度の高い見込み客を営業部門へ引き渡す。営業部門はSFA(営業支援システム)で商談を管理し、受注するとカスタマーサクセス部門が別のツールで顧客管理を始める。一見きれいに分業できているように見えますが、実態は違います。

ツールが変わるたびに、データの構造が微妙に違います。ある部門では「会社名」と「担当者名」が別フィールドで、別の部門では別のオブジェクトで管理されている。データの引き渡し時に情報が欠落したり、重複レコードが生まれたりします。営業が入力した契約条件と、実際にオンボーディングで確認した条件に齟齬が生じることもあります。結果として、マーケティングが把握している顧客像、営業が認識している顧客像、カスタマーサクセスが見ている顧客像が、同じ企業内で三者三様に並立してしまうのです。

こうした状態を放置すると、次のような症状が積み重なっていきます。

• 全社的な統制を受けずに現場判断で導入された「野良SaaS」が増え、セキュリティリスクやコストの全体像が誰にも見えなくなる
• 部門間のツールをつなぐために誰かが個人で組んだ自動連携が、その担当者の異動とともにメンテナンスされなくなる
• 部門ごとに独自のダッシュボードが作られ、部門間で示す売上の数字が一致しなくなる

やがて現場から、こんな声が上がり始めます。「うちの部門だけじゃなくて、全体を横串で見てくれる人がほしい」。各部門の中で閉じた改善なら、部門のOps担当者でも対応できます。しかし、部門をまたぐ接続点の設計は、どの部門の担当者にも属さない「名前のない仕事」です。情報システム部門は経営のための基幹システムを守り、現場は自分たちの業務を回すためにSaaSを導入する。その間に、「全体のオペレーションを設計・最適化する機能」が構造的に欠落しているのです。

5. 課題の本質は「ツールの数」ではなく「接続の設計不在」

ここまでの話を読んで、「SaaSが多すぎるなら減らせばいい」と思われるかもしれません。しかし、SaaSの数を減らすことは解決策になりません。

各SaaSは、それぞれの領域で高い専門性を持っています。MAツールはマーケティングオートメーションに強く、SFAは商談管理に長け、会計SaaSは会計処理に最適化されています。一つのツールですべてをまかなう「何でもできるソフト」は、各領域で専門ツールに劣ります。

課題の本質は、ツールの数ではなく、「ツール間の接続を誰が設計するか」が不在であることです。

一つのSaaSの中では、データは整合性を持って管理されています。商談データとアカウントデータのリレーションはきちんと設計されている。しかし、あるSaaSから別のSaaSへのデータ連携、部門をまたぐリードの引き渡し、通知の仕組みとデータ更新の同期。こうした「SaaS間の接続部分」を全体として設計し、運用する機能が欠けているのです。

一つひとつのSaaSは優秀な臓器です。しかし、臓器と臓器をつなぐ血管と神経の設計が不在のまま、臓器だけが増えている。人体に例えれば、心臓も肺も肝臓も高性能なのに、血液が回っていない状態です。この血管と神経の設計こそが、BizOpsの仕事です。個々のSaaSの専門性を活かしながら、それらを一本のオペレーションとしてつなぎ、データの流れを設計し、全体の整合性を保つ。ツールの導入は現場が自走できます。しかし、ツール間の接続と全体最適の設計は、BizOpsという機能がなければ実現しません。

6. 振り子は「集中か分権か」を問うていない

ここまで見てきた50年の歴史をあらためて振り返ります。

集中化のフェーズでは、情報部門が全体を統制していたから、横串の機能は不要でした。分権化のフェーズでは、現場が自走していたけれど、その規模が小さかったから大きな問題にはなりませんでした。しかし今、SaaSという強力な武器を手にした現場が、大規模かつ高速に独自の仕組みを構築し続けています。この再分権化の波を放置すれば、組織全体のオペレーションは断片化し、収拾がつかなくなります。

振り子の歴史は、「集中と分権のどちらが正しいか」を問うているのではありません。問われているのは、「分権化した現場の力を殺さず、全体最適をどう実現するか」です。

現場のスピードを止めれば、SaaSがもたらした競争力を失います。かといって、全体設計を放置すれば、データの分断とサイロ化が組織を蝕みます。両方を同時に成立させる機能が必要です。その答えとして必然的に浮上してきたのが、BizOpsという機能なのです。

情報システム部門を置き換える話ではありません。情報システム部門が担ってきた「守りのIT」と、現場が自走してきた「攻めのIT」の間に、これまで名前がなかった機能を立てる話です。50年かけて振れ続けた振り子を止めるのではなく、振り子の動きそのものを事業成長につなげる。それがBizOpsという機能の役割だと私は考えています。

よくある質問

Q1. BizOpsは情報システム部門の仕事を奪うのですか。

A. いいえ。情報システム部門が担ってきた基幹システムの保守やセキュリティといった「守りのIT」は、引き続き情報システム部門の重要な役割です。BizOpsが担うのは、情報システム部門の軸足の外にあった「現場のオペレーションを横断して設計する」領域です。両者は競合するのではなく、補完し合う関係にあります。

Q2. SaaSの数を減らせば問題は解決しませんか。

A. 解決しません。各SaaSは専門領域で高い機能を持っており、一つのツールに統合すると各領域の専門性が下がります。課題の本質は「ツールの数」ではなく「ツール間の接続を誰が設計するか」です。接続の設計を担う機能がなければ、ツールを減らしても同じ問題が形を変えて再発します。

Q3. 中小企業でもBizOpsという機能は必要ですか。

A. 組織の規模に関わらず、複数のSaaSを部門ごとに使い分けている状態であれば、接続の設計という課題は発生します。専任の担当者を置けない規模であれば、まずは既存の担当者が「横串で見る時間」を業務として確保するところから始めることをおすすめします。

Q4. 情報システム部門の予算を増やせば解決しませんか。

A. 予算の問題だけではありません。情報システム部門は歴史的に「経営のためのIT」に軸足を置いており、評価指標も守りのITに最適化されています。予算を増やしても、担う役割の定義そのものを見直さない限り、「攻めのIT」への投資は後回しになりやすい構造があります。

お知らせ

自社のIT統制がどのフェーズにあり、部門間の接続にどんな課題を抱えているか。整理したい経営者・責任者の方は、お気軽にご相談ください。

現場に入って一緒に整理するところから始めます。初回のご相談は無料です。

お問い合わせはこちら

これまでの支援実績はこちら

参考文献・出典

• IT人材の偏在に関する記述は、IPA(独立行政法人情報処理推進機構)「IT人材白書」に基づきます(日本企業のIT人材の約7割がITベンダー側に偏在)
• IT統制の歴史的変遷(メインフレーム・クライアントサーバー・ERP・SaaS)の整理、および情報システム部門の構造的限界に関する考察は、筆者が執筆中の書籍『BizOps本(仮題)』第3章の議論を再構成したものです
• 本記事内の企業事例(顧客情報の分断・野良SaaS等)は、特定の企業を指すものではなく、複数の現場でよく見られる一般的なパターンを筆者が再構成したものです
• 本記事内に出典のない記述は、いずれも筆者(祖川慎治)の実務経験に基づく記述です
• 関連記事：BizOpsの組織が生まれる日――担当者の意思ではなく、会社の力学が決める

この記事を書いた人

祖川 慎治(そがわ・しんじ)

株式会社テイクアステップ 代表取締役／一般社団法人BizOps協会 代表理事。大手メーカー・大手SIerを経て、HR Techベンチャーで全社の業務改善を担うBPR部署の責任者として社内IT戦略の立案から実行・定着化までを担当。5年で300名から1,400名へ成長する組織とIPO実現を業務基盤の面から下支えした。2021年に株式会社テイクアステップを設立し、BizOps・業務プロセス設計の実行支援を行う。ポッドキャスト「どうする?BizOps」配信中。

会社概要はこちら