非エンジニア出身者が多い組織で考えた、Microsoft 製品群を前提にしたDX設計

はじめに

株式会社学情で、社内DXを推進するDXチームのマネージャーをしています。
kanemakiと申します。

IT・DXの文脈では、いわゆる Best of Breed（分野ごとに最適なツールを組み合わせる設計） が
一般的で、合理的な選択肢であることは広く知られています。

CRMはCRM専業ベンダー、
BIはBIツール、
生成AIは別のAI基盤。

技術的には、たしかにその通りです。

それでも当社では、
Microsoft 365 / Power Platform / Dynamics 365 / Copilot を前提とした
Microsoft製品群中心のDX設計を続けてきました。

なぜ「最適なツールの組み合わせ」を選ばなかったのか。

本記事では、その理由を
DXを「誰が回し続けるのか」 という視点で整理します。

前提：非エンジニア出身の社員が多い

まず、すべての判断の前提です。

エンジニア専業採用を前提にしていない
非エンジニア出身で業務部門から異動してDXに関わってきた社員が多い
そのためプログラミングができる社員ばかりではない

現在ではエンジニア経験を持って入社してくる社員も増えてきましたが
数年前は

エンジニアリングを理解した非エンジニア出身者が多い組織

という状態でした。

この前提において、
一般論として語られがちな Best of Breed（複数ベンダーの最適ツールの組み合わせ） は、
必ずしも合理的ではないと判断しました。

※2018年にMicrosoft 365を導入する段階で上記の判断を行い、
　今に続く当社における社内システム選定の考え方の基礎となっています

Best of Breed を採らなかった技術的理由

単体で見れば、

CRMはA社
基幹はB社
BIはC社
生成AIはD社

という構成は、技術的に「正しい」選択に見えます。

しかしこの構成では、

システム間連携の理解
仕様変更時の影響把握
障害時の切り分け

が 特定の詳しい人に集中 します。

非エンジニア出身者が多い組織では、
この時点でDXは「回せる人が限られた仕組み」になります。

また、Best of Breed には一般に、
システム間連携の設計・維持が必要になり、運用や管理が複雑になりやすい という課題があります。

当社でも、別々のシステムだった場合に
自分たちで連携を容易には実装できない
→外注すれば費用がかさむ・変更に時間がかかる
という問題を強く意識していました。

Microsoft製品群を選んだ理由は「ノーコード開発」だけではない

よくある説明として、

ノーコード／ローコードだから

という理由が挙げられがちですが、
それは理由の一つであって、すべてではありません。

本質的に重視したのは、

非エンジニア出身の社員が、自分たちで作り、
そのまま“つなげて”運用まで持っていけること

でした。

アプリや自動化を自分たちで作れること
システム間でデータ連携できること
権限・データ・業務文脈が分断されないこと
引き継ぎ可能なこと

これらを 同一思想・同一基盤上で成立させられるか を重視しています。
その判断が、実際の業務運用でどう効いたのかを、もう少し具体的に書いてみます。

具体的に、何がつながると便利だったのか

当社で重視したのは、単に同じベンダーで揃えることではなく、日々の業務の流れの中で、データとアプリが自然につながることでした。

たとえば CRM に入った顧客・案件情報を起点にして、

必要な入力や補完・通知を Power Apps で業務フローに組み込む
Power Automate で通知や承認、転記を自動化する
Dataverse や Power BI で可視化・分析する

といった流れで、同じ基盤・同じ権限設計の延長で作りやすくなります。

重要なのは、これが「個別最適な連携の積み上げ」ではなく、
業務システムの土台そのものがつながる前提で設計できることでした。

非エンジニア出身者が多い組織では、
この「つながり方の自然さ」が非常に重要です。

別々の製品を都度つなぐ構成だと、
どこで何が連携しているのか、変更時に何を見ればよいのか、
障害時にどこを切り分けるべきかが見えにくくなります。

一方で、基盤・認証・データの置き場がある程度そろっていると、
現場の改善活動そのものを止めにくくなります。
これが、当社にとって Microsoft 製品群を前提にした設計の大きな利点でした。

Google でも近いことはできるが、構成の考え方は違う

なお、ここで言いたいのは 「Microsoft でなければ実現できない」 ということではありません。

たとえば Google Workspace でも、公式に提供されている主要サービスとして Gmail、Drive、Meet、Calendar、Chat、Gemini、Docs、Sheets、Slides、NotebookLM、AppSheet などがあり、AppSheet を使ったノーコード開発や、BigQuery と組み合わせたデータ活用も可能です。

一方で、Google Workspace の公式な主要サービス一覧には CRM / ERP は含まれていません。

そのため、CRM や基幹まで含めて一体で設計する場合は、Google Workspace 単体というよりは、AppSheet や BigQuery、さらに外部の CRM / ERP を組み合わせる発想になりやすい、と私は考えています。

当社では、CRMや基幹まで含めて一体で設計する前提だったため、Microsoftを選択しました。
一方で 「どこまでを同じ基盤として持ち、どこからを外部連携にするか」 は組織の考え方次第になると思います。

生成AI時代に、その設計がどう効いてきたか

こうした 「業務データが自然につながる構成」 は、
生成AI活用の段階に入って、さらに意味を持つようになりました。

生成AI活用でよくある課題は、

どのデータを参照しているのか分からない
業務データとの距離が遠い
AIが“別物”として存在してしまう

という点です。

当社では、

CRM：Dynamics 365
データ：Dataverse / Power BI / Microsoft Fabric
業務：Microsoft 365

が同一基盤上にあるため、

「CRMや業務データを前提に、業務文脈で生成AI（Copilot）を使う」

という状態を、特別な設計なしで実現できます。

API連携や独自RAG構成を組まなくても、

権限
データの所在
業務文脈

が自然につながります。

これは 単体最適なAIツールの組み合わせでは実現しにくい部分です。

この点は、Microsoft 365 と Copilot を実運用している方であれば、
同じような感覚を持たれているかもしれません。

生成AIが業務に本格的に入り込む現在では、
単に「賢いAIを使う」こと以上に、

業務データを正しく参照できること
そのデータが生まれた業務文脈を理解できること
誰の権限で、どの流れの中で使われているかを把握できること

が、AI活用の成否を分ける要素になってきています。

Microsoft 365 と Copilot の組み合わせでは、
こうした 業務データと文脈の統合 が前提として設計されています。

近年登場した Work IQ も、
メール・会議・チャット・ドキュメントといった日常業務の履歴から
「人と仕事の文脈」を理解し、Copilot やエージェントに渡すための基盤です。

その意味では、当社で採ってきた
「業務データが自然につながる構成」を前提にした設計は、
生成AI全盛の今になって、ようやく本領を発揮し始めている　とも感じています。

特別なAI基盤を別途用意しなくても、
業務の流れを理解したAI活用が“自然に成立する”。
これも、Microsoft製品群を前提にしてきたことの大きな副次的効果でした。

他の SaaSを使わない、という話ではない

また、これは 「他のSaaSを使わない」 という話でもありません。

実際には、特定用途で優れた SaaS を是々非々で採用することは当然あります。
ただ、その場合でも土台となる業務データや認証、主要プロセスの基盤が揃っていることで、本当に価値のある連携ポイントにだけ注力できる というメリットがあります。

Best of Breed では、柔軟性や専門性の高さという利点がある一方で、連携設計・データ整合性・運用管理の複雑化が課題になりやすいこともよく知られています。

コアの設計思想が整理されていると、外部 SaaS の採用も「増築」になりやすく、全体が破綻しにくいと感じています。

まとめ：DXでは「つなぎやすさ」も技術力

DXにおける技術力は、

最先端であること
単体で優れていること

だけで決まるものではありません。

誰が理解できるか
誰が手を動かせるか
誰が直し、引き継げるか

まで含めて、最初にどんな前提で設計したかが、
数年後のDXの成否を大きく左右すると感じています。

Microsoft製品群を選び続けているのは、
ベンダーロックインを良しとしたからではなく、

「非エンジニア出身者が多いこの組織で、
DXとAI活用を回し続けるには、これが最も合理的だった」
という、設計上の判断の結果です。

生成AI全盛となった今、
業務データと業務文脈を理解したAI活用が重要になっています。

それが後付けの設計なしに自然と成立する。
この点でも、当時の判断は間違っていなかったと感じています。

DXを推進される同じような立場の方が、
自社の前提を見直すきっかけになれば幸いです。

お断り
この記事は筆者の個人的な経験や考えに基づいて書いています。所属組織の公式な意見や方針とは関係ありませんのでご了承ください。