こんにちは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

この業界に入って、気づけば25年が経ちました。

フライトの累計距離を計算したことがあります。地球を90周以上。30カ国以上でプロジェクトに関わり、Convergence、Partner Conference、Directions、Ignite、AI Tour—Microsoftのイベントも数えきれないほど参加してきました。時差と戦いながら、言葉の壁を越えながら、それでも毎回思うことがあります。

世界には200カ国以上あります。できることならすべての国でプロジェクトを経験したい。でも正直、年齢を考えるとそれはもう難しいでしょう。これから世界に出ていく若い人たちが、少し羨ましいです。

どの国に行っても、最初にすることは同じです。地図を広げる。

どこに何があるか。どのルートが現実的か。どこに落とし穴があるか。地図なしに知らない街を歩けば、必ず迷います。それはDynamics 365も同じでした。

製品が増えるほど、選択肢が増えるほど、「どれを選ぶか」より先に「全体をどう見るか」が問われます。このシリーズは、その地図を一緒に広げる試みです。

今回取り上げる5つのパターンは、網羅的なリストではありません。私が過去に関わった100を超えるDynamics案件を振り返ったとき、ほとんどはこの5つに集約されていきました。もちろん例外はあります。しかし、まずこの5つの代表的なパターンを理解すると、Dynamics 365全体の地図が一気に見えやすくなる。それが、このデザインパターンの整理をした理由です。

前稿はDX365LIFEメモリアルな200回目でした。本稿は201回目。最後までお付き合いいただけますと幸いです。

Dynamics 365という地図の話

Dynamics 365は、今や20を超える製品群で構成されています。Sales、Customer Service、Field Service、Project Operations、Customer Insights—CRM側だけでも多彩です。ERP側はBusiness CentralとFinance & Operations、さらにFinanceとSCMに分かれ、HRもその中に含まれます。

問題は、これらを「使えるものを使う」という発想で組み合わせると、必ずどこかで綻びが出ることです。データがどこにあるかわからなくなる。同じ顧客が3つのシステムに別々のレコードで存在する。請求書の金額と見積書の金額が合わない。どのシステムが正しいのか誰もわからない—現場でよく見る光景です。

製品を選ぶ前に、設計の全体像を持つことが必要です。どの製品が何の役割を担うか。データの主権（Source of Truth）をどこに置くか。システム間のバトンをいつ渡すか。この問いに答える枠組みが、アプリケーションデザインパターンです。

製品を選ぶ前に、設計パターンを知る

以前このブログでも、CRM×ERPのデータ連携設計（「ノックフォワード」が起きる企業はなぜ負けるのか）やマスターデータの統合（マスターデータはDynamicsなスクラムだ）、CRM×ERPをまたぐ統合設計の全体像（CRMとERPをまたぐエージェント）を書いてきました。

データ連携に関しては、以下の事もしっておきましょう。

BC–CRM（Dataverse）

• 同期
• Virtual Table
• API
• イベント
• Power Automate等

F&O–CRM（Dataverse）

• Dual-write
• near-real-time
• tightly coupled

今回はそれらを踏まえ、Dynamics 365の製品組み合わせを「パターン」として整理します。現実のプロジェクトで頻繁に登場する5つのパターンを取り上げます。下の表が、その全体像です。横軸がERP、縦軸がCRMです。どの組み合わせを選ぶかによって、統合の仕組み・データの持ち方・帳票の出し方・月次締めの設計がすべて変わります。

以下の表は各パターンの位置関係を確認するため、各節で再掲しています。

パターン① Sales × Business Central ― SMB標準

中堅製造業・卸売業でもっとも多く見るのが、D365 SalesとBusiness Centralの組み合わせです。営業が商談・見積をSalesで管理し、受注が確定した後はBusiness Centralへ引き継いで、発注・出荷・請求・売掛を処理する。役割分担がシンプルで、規模感とコストのバランスが取れたパターンです。

以下の赤枠部分が、今回説明するパターンです。

この組み合わせの統合の仕組みは、Integration Table Mappingです。代表的には、BCのCustomer（取引先）とDataverseのAccount、BCのItem（製品）とProduct、BCのSales Order（受注）とOrderなどをマッピングします。各マッピングに対して、同期の方向・タイミング・フィルター条件を設定できるため、「顧客マスタはBCが正、Salesはその参照のみ」といった細かい制御が可能です。実際のプロジェクトでは、使用するエンティティを業務要件に合わせて選択します。すべてのエンティティを同期する必要はありません。

設計の核心は、どの時点でSalesからBCへバトンを渡すかです。見積承認時点か。受注確定時点か。それとも出荷指示まで待つか。この境界線は、与信管理とも直結します。BCは顧客ごとの与信限度額を管理しています。つまり「いつBCにデータを渡すか」を決めることは、「いつ与信チェックをかけるか」を決めることでもあります。バトンのタイミングと与信の設計は、セットで考える必要があります。

もうひとつ、帳票をどちらで出力するかも設計段階で決めておく必要があります。CRMとERPにまたがる帳票設計の考え方については、「帳票を制する#02｜Business Central編」と「#04｜CRM編」で詳しく整理しています。

パターン② Sales × Finance & Operations（Finance + SCM）― エンタープライズ標準

グローバル展開を持つ大企業、複数法人・複数通貨を扱う製造業では、Business CentralではなくFinance & Operations（FO）が基幹系を担います。SalesとFOの組み合わせは、①と基本的な役割分担は同じです。商談・見積はSales、受注後の財務処理はFinance、在庫・出荷・調達はSCM。ただし規模と複雑さが一段上がり、統合の仕組みも根本的に異なります。

以下の赤枠部分が、今回説明するパターンです。

①のIntegration Table MappingはBC固有の仕組みです。FOとSalesを繋ぐのはDual-write—DataverseとFOのデータを双方向・リアルタイムで同期させるMicrosoftのフレームワークです。Dual-writeは双方向同期の仕組みだが、各データ項目を双方向書き込みにするわけではありません。正しく設計されていれば強力な基盤になりますが、設計を誤ると修正コストが跳ね上がります。

このパターンでもう一つ重要なのが、SCMの在庫との連携です。FOのATP（Available to Promise：引当可能在庫）機能をSalesから呼び出せる構成にすることで、営業担当者がSalesを離れることなく在庫状況を確認できるようになります。在庫を持つビジネスでは、この設計がSalesの実用性を大きく左右します。

帳票の出力元もこのパターンで頻繁に論点になります。設計指針については「帳票を制する#03｜Finance & Operations編」と「#05｜総集編」を参照してください。

パターン③ CS/CC × (FS + PO) × Business Central ― 中堅プロジェクト・サービス型

設備の保守契約を受け、顧客からの問い合わせをCS/CCで受け付け、Field Serviceで技術者を手配し、Project Operationsでプロジェクトを管理する。売上・原価の計上はBusiness Centralで行う。製造業のアフターサービス部門、建設・設備工事の中堅企業でよく見るパターンです。

以下の赤枠部分が、今回説明するパターンです。

このパターンの特徴は、CS/CC・FS・POがすべてDataverseプラットフォーム上でネイティブに連携することです。課題はBCとの連携です。標準のIntegration Table Mappingに加え、API・Power Automate・Virtual Table・Custom Connectorなど、要件に応じた連携手段を組み合わせる設計が必要になります。データ連携のアーキテクチャ選定については「ERPとDataverse、パスの繋ぎ方」で整理しています。

現実的には、SMBにおいてはBC単体で導入（BCのサービスモジュールや、プロジェクトモジュールの利活用）が完結する事が一般的でしょう。ただし、先にFS/POが入っていて、ERPを国産パッケージからマイクロソフト系に変えていく事は今後多くなっていくでしょう。

WIP（仕掛品）管理が、このパターンの設計の核心です。「POで認識しているコストをいつBCへ渡すか」「BCで仕掛勘定に積み上げた原価をいつ売上原価へ振り替えるか」—この2つのタイミング設計が、財務の正確性を左右します。

売上・仕入計上認識もこのパターン固有の論点です。固定価格プロジェクトであればマイルストーン請求、T&M（Time & Material）であれば工数確認後の請求、保守契約であれば月次定額請求—請求モデルによって、POからBCへ渡す伝票の設計が変わります。

管理会計用の分析コードについては、BCのディメンション（部門・プロジェクト・コストセンター）にPOのプロジェクトコードをどうマッピングするかを設計します。マスターと伝票の連携設計については「マスターデータ統合」と「CRM×ERPのデータ設計原則」も参照してください。

パターン④ CS/CC × (FS + PO) × Finance & Operations（Finance + SCM）― エンタープライズ・プロジェクト型

③と業務の流れは同じです。CS/CCで受注し、FSで現場作業を管理し、POでプロジェクトを管理する。違いはERP側がFOであること—そしてその違いが、財務・在庫・管理会計の設計を根本的に変えます。

以下の赤枠部分が、今回説明するパターンです。

このパターンの最大の特徴は、PO+FO FinanceがMicrosoftの設計した標準統合であることです。POのプロジェクトトランザクション（工数・経費・外注費）がFO Financeのプロジェクト元帳に直接ポスティングされます。③で必要だった独自連携が不要になり、財務との統合精度が格段に上がります。「CRM×ERP統合設計の全体像」も参照してください。ただし、Financeとの連携をせず、既存で活用中の他社製品と連携する場合もあるでしょうね。

標準コネクタや標準統合があっても、実際には次の設計が必要です。

• プロジェクトカテゴリと勘定科目の対応
• 工数・経費・外注費の計上ルール
• WIPと収益認識
• 法人・通貨・税
• エラー時の再処理
• 月次締め時の照合

つまり、標準統合は独自開発を減らすが、業務設計を不要にするものではありません。

WIP管理はこのパターンの真骨頂です。FO Financeにはプロジェクト元帳があり、原価の発生・仕掛計上・売上計上・WIP取り崩しが勘定科目レベルで追跡されます。固定価格プロジェクトの完成基準、T&Mの工数認識、マイルストーン請求—いずれの請求モデルにも対応できるのはFOの強みです。Dynamics 365 Field ServiceをDynamics 365 Financeに連携する場合は、Dynamics 365 Project Operationsを経由する事が必要になっているので気をつけてください。

売上・仕入計上認識において、FOは収益認識モジュール（Revenue Recognition）を持っています。仕入側では、FSのWork Orderに必要な部品がSCMの在庫から引当・出荷され、その原価がFO Financeのプロジェクト元帳に自動計上されます。FS・SCM・FOの三者が連動する、エンタープライズならではの設計です。

管理会計用の財務ディメンションはFOの強みのひとつです。帳票については「帳票を制する#03｜Finance & Operations編」と「#05｜総集編」を参照してください。

パターン⑤ Customer Insights × Sales × CS ― CRMデータループ

①〜④はすべて「CRMとERPをどう繋ぐか」という設計でした。⑤は性格が異なります。ERPとの連携は一旦脇に置き、CRMのデータを回し続けることで顧客理解を深めるループをどう設計するか—これがこのパターンの問いです。

以下の赤枠部分が、今回説明するパターンです。

Customer Insights（CI）は、DataとJourneysという2つの主要機能群から構成されます。Dataは顧客データを統合して360度プロファイルを生成するCDPの役割を担い、Journeysはそのプロファイルをもとにマーケティングジャーニーを自動化します。SalesとCSがそれぞれ生み出す顧客接点データをCIが吸収し、統合プロファイルとAI予測を生成し、営業担当者とCSエージェントにフィードバックする。このループが回るほど、顧客理解の精度が上がる設計です。製品の最新動向については「Customer Insights – Data 2026 wave1」と「Customer Insights – Journeys 2026 wave1」を参照してください。

統合顧客プロファイルの設計が、このパターンの起点です。ここで問われるのが名寄せ（Identity Resolution）—メールアドレス・電話番号・CRM IDをどう突き合わせて「この人は同一人物だ」と判断するか。ルール設計を誤ると、同じ顧客が3つのプロファイルに分裂します。

CI-Dataが必要とするデータは、CRM（Sales・CS）の中だけにあるとは限りません。顧客の購買履歴・請求履歴・サービス完了記録—これらはERPの中にあります。FS/POを使っている場合は、Work Orderの作業記録・プロジェクトのコスト・完了レポートがCIにとって重要なデータソースになります。また、CDPに必要なデータは構造化データだけではありません。非構造化データを取り込み、AIで解析することで初めて「顧客を立体的に理解する」プロファイルが生まれます。データをAIへの経験伝承と捉えた設計アプローチについては、「データ移行とは、AIに経験・証跡を引き継ぐこと」と「続・データ移行はAIへの経験伝承」を参照してください。

どのパターンを選ぶか—判断のフロー

5つのパターンを紹介しましたが、「どれが自分たちに合うか」がわからなければ意味がありません。判断の出発点として、以下のフローを参考にしてください。

ここは賛否分かれるところだと思います。従業員数が500人以下であってもFOを使いますし、500名以上であってもBCを使うことがあります。

また、本社はSAP/Oracleだけど、海外子会社はBCというケースも多いでしょう。

実際30ユーザーくらいでFOをご利用になられているユーザー企業もあります。製品選定をどのような戦略に基づいて実行するのか。これが大切です。

ただ、何かの基準・目安が必要でしょうし、まぁここは室長が両方やってきたMicrosoft MVPであるということでお許しいただければと思います。

※ このフローは方向性を示すものです。実際の選定は、業務要件・予算・既存システム・グローバル展開計画を踏まえた上で行ってください。

地図を手に、最初の一歩を

5つのパターンを見て、「うちは全部やらなければ」と思った方がいれば、少し立ち止まってください。

地図を広げることと、すべての道を同時に歩くことは、まったく別の話です。

大切なのは、自社がいまどこにいるかを正確に把握することです。①のSales×BCで十分なのに、エンタープライズパターンに憧れて②を導入しようとする。あるいはその逆—グローバル展開・複数法人を抱えているのに、コストを抑えようとして①に収めようとする。地図を持ちながら迷子になるのは、たいていこのパターンです。

計画は実装の2倍の時間をかけても惜しくない。どのシステムが何のデータを持つか。Source of Truthをどこに置くか。バトンをいつ渡すか。これらを紙の上で決め切ってから動き始める企業が、結果として最も早くゴールに辿り着きます。

そしてもう一つ、AI時代ならではの視点を加えておきたい。データは、もはや人間だけのためにあるのではありません。AIが判断し、提案し、行動するために、データが必要です。 どのシステムに何のデータを置くか—この設計判断は、将来のAI活用の土台を決める選択でもあります。アプリケーションデザインパターンを考えるとき、「このデータはいつかAIが使う」という視点を、頭の片隅に置いておいてください。

Dynamics 365とAIエージェントがどう交差するか、その全体像については「Agentic Engineering × Dynamics 365｜エピローグ」にまとめています。

皆さんの企業は、どのパターンに近いですか？複数のパターンが混在していますか？

いつかお会いできた際に、教えてください。

次回・次々回の予告

それでは今日はこのくらいで。Let’s Enjoy our DX365Life!