前回の記事で、AI要件定義の現在地について書きました。要件定義という工程の意味が「整理する工程」から「決断する工程」へと変わりつつあること。そして、多くの現場でその変化に気づかないまま「思考の丸投げ」が進んでいることへの懸念です。
今回は、その延長線上にある、もうひとつの警鐘を鳴らしたいと思います。
CTO・社内SEが、AI駆動開発でコーディングが早くできるがゆえに事業部門の御用聞き、つまり「社内SIer」になってしまっている問題です。
AI駆動開発が生んだ新しい力学
AI駆動開発の浸透によって、コーディングのハードルは劇的に下がりました。これは疑いようのない事実です。
その結果、事業部門の側からも「こういうのが欲しい」「これをシステム化したい」という要望が、以前とは比べものにならないスピードで上がってくるようになりました。事業部門の担当者自身がAIで要件をリストアップし、場合によってはプロトタイプまで作ってくることも珍しくありません。
一見、これは良いことのように思えます。事業部門が主体的にDXに取り組み、情報システム部門と連携してスピーディーにシステムを立ち上げる理想的な姿に見えるかもしれません。
しかし、ここに落とし穴があります。
CTO・社内SEが、この流れの中で「事業部門から来た要望を、そのまま形にする人」になってしまっているケースが増えていると感じています。要望を受け取り、技術的に実現し、納品する。まさに「社内SIer」です。
御用聞きの先に待っているもの
「事業部門の要望に応える」こと自体は間違っていません。問題は、事業部門ごとの要望にそのまま応え続けた結果、何が起きるかです。
僕はこれを**「野良システム」「野良データベース」の乱立**と呼んでいます。
営業部門が独自のCRMを作り、マーケティング部門が別のデータ分析基盤を立て、カスタマーサポートが独自のチケット管理を構築する。それぞれの部門は満足しています。自分たちの業務に最適化されたシステムが、高速で手に入ったのですから。
しかし、全社で見るとどうでしょうか。
データはバラバラの場所に散在し、フォーマットも統一されていません。同じ顧客情報が複数のデータベースに異なる形で存在しています。部門間でデータを連携しようとすると、その都度手作業やカスタム開発が必要になります。
これが技術サイロです。
AI駆動開発で簡単にシステムが作れるようになったからこそ、このサイロ化は以前とは比べものにならないスピードで進行します。従来であれば、開発コストの高さが自然な歯止めになっていました。「作るのが大変だから、本当に必要なものだけを厳選する」という力学が働いていたのです。
しかし今は、その歯止めが外れています。作れてしまうがゆえに、作ってしまう。その結果、野良システムと野良データベースが社内に増殖していきます。結果として管理するアプリやインフラはどんどん増えていきます。
なぜこれがAI時代に致命的なのか
「多少システムが散らばっても、動いているならいいじゃないか」そう思われるかもしれません。しかし、AI時代においてこのサイロ化は、従来以上に致命的な問題を引き起こします。
理由はシンプルです。AIの価値はデータの統合度に比例するからです。
AIが本当に力を発揮するのは、全社横断のデータを統合し、部門を越えた知見を引き出せる状態です。営業データ、顧客対応履歴、マーケティング施策の効果、財務データ、これらが統合されて初めて、AIは経営判断に資するインサイトを出すことができます。
しかし、野良システムが乱立した環境では、そもそもデータが繋がっていません。部門ごとに最適化された小さなAI活用はできても、全社的なAI活用、つまり、本当に事業インパクトのあるAI活用には永遠にたどり着けないのです。
部門最適を積み重ねた結果、全社最適を永久に失う。これが、御用聞き型のCTO・社内SEが無自覚に作り出してしまうリスクです。
CTO・社内SEが果たすべき本当の役割
では、CTO・社内SEはどうあるべきでしょうか。
答えは明確です。「作る人」ではなく「設計する人・切断する人」になることです。
ここで言う「設計」とは、個別システムの設計ではありません。全社のデータとシステムのアーキテクチャを設計するということです。
事業部門から要望が来たとき、それをそのまま形にするのではなく、「この要望は全社のアーキテクチャの中でどう位置づけるべきか」を判断する。場合によっては、「個別に作るべきではない」と言い切る。既存の基盤を拡張することで対応できるなら、そちらに誘導する。
これは事業部門にとって不便に感じることかもしれません。「すぐに作ってほしいのに、なぜ全社の話が出てくるんだ」と言われることもあるでしょう。
しかし、その判断ができるのはCTO・社内SEだけです。事業部門には自部門の最適化を考えるインセンティブはあっても、全社のアーキテクチャを守るインセンティブはありません。だからこそ、技術の専門家であるCTO・社内SEが、全体最適の番人としての役割を果たす必要があるのです。
「作らない判断」こそが最高の技術力
AI時代のCTO・社内SEに求められる最も重要な能力は、皮肉なことに「作らない判断」かもしれません。これが「切断する人」と呼称する理由です。
事業部門から要望が来た。技術的には作れる。AIを使えば数日で形になる。しかし、それを作ることが全社にとって本当に正しいのかを問い直す力です。
この要望は、既存の基盤で対応できないか。データの持ち方は全社のルールに合っているか。他部門で似たシステムが既に動いていないか。個別最適のシステムを増やすことで、将来のデータ統合を困難にしないか。
こうした問いを立てられることが、AI時代における本当の技術力です。
コーディングはAIがやってくれます。しかし、何を作り、何を作らないかを判断することは、AIにはできません。前回の記事で「要件定義は決断する工程になる」とお伝えしましたが、CTO・社内SEの役割もまったく同じ構造です。
御用聞きではなく、全社アーキテクチャの設計者として、AI時代だからこそ、その役割はますます重要になっていきます。
未来が読めないからこそ、「動ける状態」を作る
ここまで「作らない判断」の重要性を述べてきましたが、もうひとつ、CTO・社内SEが持つべき視点があります。
AI時代は未来が読めないからこそ、いつでも動ける状態にしておくことです。
今、「SaaS is Dead」という言説が広がっています。2024年末にMicrosoft CEOのサティア・ナデラがこの言葉を発して以来、SaaSの終焉を予測する声は少なくありません。実際、SaaS企業のバリュエーションは圧縮が続いており、投資家の関心はAIネイティブなプラットフォームへと急速にシフトしています。
しかし、本当にSaaSは死ぬのでしょうか。
僕はそう単純な話ではないと考えています。SaaS企業は多額の研究開発費を投じて、AI時代におけるソフトウェアの最適な形を模索しています。エージェント型AIの組み込み、成果ベースの課金モデル、業界特化型のAIプラットフォーム化……その進化の先に、今の我々には想像できないような形のプロダクトが生まれる可能性は十分にあります。
つまり、「SaaSは死ぬ」と断定して自前主義に走ることも、「SaaSで十分」と思考停止することも、どちらもリスクなのです。
CTO・社内SEが取るべきスタンスは、どちらかに賭けることではありません。どちらに転んでも対応できるアーキテクチャを設計しておくことです。
具体的には、データの持ち方を標準化し、特定のSaaSやツールにロックインされない構造を作る。システム間の連携をAPIベースで疎結合にしておく。野良システムを乱立させず、全社のデータ基盤を一元化しておく。
こうした設計思想があれば、SaaSが進化してより良いプロダクトが出てきたときには乗り換えられます。逆に、自前で構築した方が良い領域が明確になれば、そちらに移行することもできます。
未来を予測することはできません。しかし、未来に対応できる構造を作ることはできます。それこそが、AI時代のCTO・社内SEに求められるアーキテクチャ設計の本質ではないでしょうか。裏を返すと、これができるのは技術者しかいません。その貴重なリソースを社内SIerとして過ごさないでほしいのです。
「作れる」だけでなく「設計できる」「事業を動かせる」技術者へ。そのヒントを探している方に、GEAR.base はきっと役立つはずです。ぜひ覗いてみてください。
