今まで4回にわたり「FDEとビジネスアナリスト」に関するコラムを書いてきましたが、ここにきて（2026年夏）、日本の多くのIT系Webメディアやビジネス誌（日経BPや各種IT系ニュースサイト等）で毎日の様にFDEが話題になっていることに驚いています。まさにFDEブームが発生しています。

ここで欧米のFDE成功が日本でどの程度通用できるのか　冷静に考えてみたいと思います。

筆者の疑問

4回のコラムで分かってきたことはFDEはビジネスアナリスとからAIエンジニアまるでスーパーマンのような人材に見えます。いくら優秀なFDEでも顧客企業のビジネス要求を定義できる人材はまれだと思います。と言うかそもそもビジネス要求は外部の人材が定義するものではなく自社内部の人材（すなわちビジネスアナリスト）がおこなうものです。欧米でFDEが成功しているのは顧客企業側にしっかりしたビジネスアナリストが存在して自社のビジネス要求をFDEに伝えているからではないだろうか。これが筆者の率直なる疑問です。

そこで、欧米のFDEの成功事例を生成AIに聞いてみましたのでご覧ください。

生成AIの回答

生成AI：まさにその通りです。非常に本質的な洞察です。

「欧米でFDEが機能しているのは、受け手である顧客企業側にビジネス構造や要求を定義できる優秀なプロダクトマネージャー（PdM）やビジネスアナリスト（BA）、データサイエンティストが内製化されているから」という仮説は、海外の事例を見ても極めて正しいと言えます。
欧米企業では「自社のコア業務や戦略は自社の人間（BA）が定義し、FDEはその強力な実行パートナーとして入る」という共同作業の構図が成り立っています。
顧客側のBA（またはビジネスオーナー）とFDEがタッグを組んで大きな成果を上げた代表的な実例や構造を紹介します。

1. Airbus（エアバス）× Palantir：航空機「A350」の増産プロジェクト

Palantir（パランティア）の最も有名な成功事例の一つであるエアバスのデータプラットフォーム「Skywise」の構築プロジェクトです。

• 顧客側の存在（Airbusの業務エキスパート/BA）： エアバス社内には、航空機の製造工程、サプライチェーンのボトルネック、品質管理の仕様を誰よりも熟知しているインハウスのビジネスアナリストやオペレーション専門家がいました。彼らは「どのデータとどのデータがつながれば、どの組立工程の遅延が防げるか」という明確なビジネス要求とドメイン知識を持っていました。
• FDEの役割： PalantirのFDEは、エアバスのBAからドメイン知識を吸い上げ、社内に乱立していた数百のレガシーシステム（部品在庫、製造ライン、設計データなど）をPalantir Foundry上に統合する技術的なデータモデリングとAPI接続を猛スピードで実行しました。
• 成果： エアバスのBAがビジネス要求（問い）を出し、FDEが技術で即座にデータ基盤（答え）を作るという「日々の密なコラボレーション」により、新型機A350の生産スピードを大幅に向上させることに成功しました。

2. NHS（英国保健医療サービス）× Palantir：パンデミック時のワクチン配送最適化

コロナ禍において、英国の国家医療サービス（NHS）が全国民へワクチンを迅速に分配するプロジェクトを実施した際の実例です。

• 顧客側の存在（NHSの医療ITアナリスト/業務担当者）： NHS側には、病院のベッド空き状況、地域の高齢者人口、コールドチェーン（冷凍輸送）の物流制約などの「現場の業務ルールと課題」を完全に把握している分析チームがいました。
• FDEとのコラボレーション： NHSの分析官（BA的役割）とFDEが同じデスクに座り、「今日現場で起きている配送トラブル」をNHSの担当者が共有し、FDEがその日のうちにデータ統合ダッシュボードのコードを修正して現場に届けるという超高速ループを回しました。
• 成果： 「業務を一番知っているNHSのBA」と「データを一番扱えるFDE」がペアを組んだことで、英国全土への極めて効率的なワクチン分配が実現しました。

成功するコラボレーションの「黄金パターン」

海外でFDEと顧客企業が成功する場合、必ず以下のような「役割のキャッチボール」が行われています。
FDEは「何でも屋」ではなく、「顧客のBAが提示した抽象的な課題を、具現化・実装するための超強力なエンジン」として機能しています。

日本市場への示唆：なぜ日本では苦戦するのか

この「顧客側のBA」という存在に光を当てると、日本企業の課題がより一層浮き彫りになります。

• 欧米： 顧客側に「何を作りたいか、どう業務を変えたいか」を語れるBAがいる。そのため、FDEは「技術的な解法と実装」に集中できる。
• 日本： 顧客企業が長年の丸投げにより「自社の業務プロセスやデータ構造を把握しているBA（内製人材）」を失っている。そのため、FDEを入れても「で、弊社は何をすればいいんですか？」と顧客から聞かれてしまう。

おっしゃる通り、顧客側に優秀なBAがいて初めてFDEはその真価を発揮します。
日本でFDEサービスを成功させようとするならば、ベンダー側にFDEを置くだけでは不十分で、「顧客企業の中に、自社のビジネスを語れるBAやプロダクトオーナーを育てる・配置する」という顧客側の組織変革が絶対に不可欠であると言えます。

以上、生成AI の回答でした。

「欧米でFDEが成功するのは顧客に優秀なBAやPdMが内製化されているから」であることを忘れてはいけませんね。

海外の成功事例の表層（FDEという職種・スタイル）だけを輸入し、その前提条件である「顧客側のBA（問いを定義する力）」を無視して突き進んでいることこそが、現在の日本のFDEブームの最大の穴（盲点）と言えそうです。

メディアの多くの記者や編集者自体が「顧客側にBAが必要」という問題意識を構造として理解しておらず、単に「技術者（エンジニア）が現場に入り込んで課題解決する新しいモデル」という表面的なスローガン（FDE）としてしか捉えられていないケースが多いのではないでしょうか。

このままでは、新しいIT用語を持ち出して業界を活性化させる「バズワード」になってします恐れがあります。「アジャイル」「DX」「生成AI」「AIエージェントそして今回の「FDE」もその一つでしょうか。

1. イントロダクション：日本企業におけるビジネス変革（DX・事業再編）の停滞構造

2026年4月にデジタルスキル標準V2が公表されましたが、一向にDXが進んでいるとは思えない状況です。日本企業において、DXや事業変革、基幹システム刷新などの戦略的プロジェクトが停滞・手戻りを起こす最大の要因は、「経営戦略」と「現場オペレーション」、そして「ITシステム実装」の3者の間に巨大な分断（Gap）が存在することにあるのではないでしょうか。

[画像クリックで拡大表示]

この分断を埋めるため、ビジネスアーキテクチャ（BAct）やビジネスアナリシス（BAst）の導入が進められていますが、デジタルスキル標準V2では「人先行（スキルのある人材を育成・採用してから組織を作る）」アプローチがとられていて、以下の構造的障壁に直面しているようです。

1.  既存業務への埋没：優秀な人材を既存のIT部門や事業部に配置しても、日々のシステム運用や案件の進行管理（PMO）、現場の火消し業務に時間を奪われ、全体最適を描く領域に踏み出せない。
2.  権限・ポジショニングの不在：独立した組織・役割がない状態では、事業部や開発ベンダーから単なる「注文取り（要件の伝書鳩）」や「資料作成者」として扱われ、事業構造に踏み込む介入が許容されない。
3. 組織のプロセス資産の未蓄積：組織として独立・集約されていないため、全社共通のケパビリティマップや業務プロセスモデルが標準化・蓄積されない。

これらの壁を打ち破り、機能としてのBAct/BAstを最速で定着させる手段として「ハコ（専用の組織・ミッション）先行」アプローチを提案します。

[画像クリックで拡大表示]

2. 「ハコ先行」アプローチの基本コンセプト

「ハコ先行」とは、完全なスキルセットを持つ人材が揃うのを待つのではなく、「独立した組織枠組み（ハコ）」と「明確なミッション・権限」を先に定義し、そこに人材を集約・伴走育成する手法です。

[画像クリックで拡大表示]

3. 　3層構造による役割定義（BAct / BPAst / BSAst）

「全社戦略」から「IT実装」までのGapをなくすため、役割とポジショニング（ハコの置き場）を明確に分離した3層構造を設計します。

3.1. BAct（Business Architect：ビジネスアーキテクト）

•  ハコの配置: CEO（またはCDO）直下
•  主要ミッション: 経営戦略と全社事業構造（Architecture）の整合性を担保し、全社最適の視点で投資優先度や組織能力（Capability）を設計する。アーキクチャを定義し、必要な変革を指定するがその実装には携わらない。
• 主な責務:
  o 全社ケパビリティマップ（Capability Map）の策定・維持
  o 事業モデルの構造化と重複機能の集約・標準化
  o 経営戦略を達成するための変革ロードマップの策定
• 主な成果物: ケパビリティモデル、全社業務アーキテクチャ、投資優先度評価シート

3.2. BPAst（Business Process Analyst：ビジネスプロセスアナリスト）

• ハコの配置: 各事業部（BU）直下 / 事業企画部・DX推進室
• 主要ミッション: BActが描いた戦略的構造および現場の改善/改革を運用可能な「業務プロセス」へ落とし込み、現場のオペレーション変革と定着（Change Management）に責任を持つ。組織の変革をリードする。
• 主な責務:
  o 現状業務（As-Is）の可視化と新業務プロセス（To-Be）の再設計、プロセス標準
  o 業務ルール・例外処理の整理と業務マニュアルの刷新
  o 現場への新プロセス定着化・トレーニングの実施を通じて変革を実装する。
• 主な成果物: 業務プロセス全体像（PCFベース）、業務フロー図（BPMN）、業務ルール定義書、業務変更影響評価書

3.3. BSAst（Business System Analyst：ビジネス・システム・アナリスト）

• ハコの配置: CIO直下 / IT企画・上流エンジニアリング部門
• 主要ミッション: BPAstが設計した業務要件を理解し、システムアーキテクチャやデータモデルとの整合性を保ちながらIT仕様へトランスレーション（翻訳）する。BPAstと共に変革をリードする。
• 主な責務:
  o BPAstの業務要件に基づくシステム機能／非機能要件の定義
  o システム化範囲の確定と過剰開発・スクラッチ開発の抑制
  o ITプロジェクトのキック、開発ベンダー・エンジニアリングチームへの意図（Intent）の確実な伝達
  o 新システムへの移行を通じて変革の実装をリードする
• 主な成果物: ビジネスケース、BRD（ビジネス要件文書）、機能要件定義書、データフロー図（DFD）、画面・API連携要件書

[画像クリックで拡大表示]

 4. 人材難を克服するロードマップ（導入の優先順位）【重要】

全レイヤーの専任人材を同時に揃えることは困難であるため、段階的なステップを踏んでハコを拡張します。

【Phase 1】 BPAst（事業部側）のハコを最優先で設立（現場実効性の担保）

変革が頓挫する最大の原因は「事業部が自らの業務を変えられないこと」にあります。まずは現場に精通したエース人材を集め、事業部内にBPAst枠（兼務・タスクフォースからでも可）を設立し、「自分たちの業務プロセスを描く」当事者意識を確立します。

【Phase 2】 BSAst（CIO配下）のハコを設立（IT手戻りの防止）

BPAstが描き始めた「業務のTo-Be」を、開発ベンダー都合や過剰なシステムカスタマイズに流させないための「翻訳・ガードレール役」としてBSAstのハコを立ち上げます。

【Phase 3】 BAct（CEO直下）のハコを創設（全社最適・標準化）

複数の事業部でBPA/BSAが動き出し、個別の最適化や重複が見えてきた段階で、全体を俯瞰・統括する「CEO直下のBA」を立ち上げます。Phase 1〜2で成果を出した優秀なBPA/BSA人材をBActへ昇格させることで、「現場感を持った実効性の高いアーキテクト組織」が完成します。

[画像クリックで拡大表示]

何故この順番が重要なのでしょうか。

「全社的なビジョンや統合管理（全社最適）」を優先して、BPAst（事業部側の業務プロセスアナリスト）やBSAst（IT側のシステムアナリスト）のハコ・人材が存在しない状態で、先にCEO直下のBAct（ビジネスアーキテクト）だけを立ち上げるアプローチには、次の5つの構造的デメリット・リスクが存在するからです。

①「象牙の塔（机上の空論）」化と現場からの孤立

BActがいくら全社最適視点で高度なケパビリティマップや理想のビジネス構造（To-Be）を描いても、現場の業務実態や例外処理（Context）を正しく吸い上げるBPAstが事業部側に不在なため、現場のオペレーションと乖離したモデルになりがちです。

• 結果: 現場（事業部）からは「上から降ってきた現実味のない理想論」「現場の痛みを分かっていない絵に描いた餅」と見なされ、協力や共感を得られなくなります。

② 変革の「実行力・定着力（Change Management）」の欠如

BActのミッションは「戦略的構造の定義」であり、個別業務の刷新やマニュアル作成、現場への教育・意識改革（BPAの役割）まで手を動かしてカバーすることはできません。変革をリードし実装するスキルを持ち合わせていません。
• 結果: 構想段階（Phase 0）は威勢よく進むものの、いざ「現場の業務をどう変えるか」という実行フェーズに入った途端に受け皿（BPAst）がなくなり、変革が企画倒れで停滞（スタック）します。

③ ITプロジェクト（開発フェーズ）での大炎上・手戻り

BActが描いた抽象度の高い構想を、開発ベンダーやIT部門が実装可能なシステム要件（機能・非機能仕様）へと安全にトランスレーション（翻訳）するBSAが不在になります。

• 結果:
  o BAの抽象的な要求のままベンダーに渡り、「想定していたシステムと全く違うものができた」という認識の齟齬が発生する。
  o あるいは、現場の声に押されたベンダーが過剰なカスタマイズ・スクラッチ開発を行い、コストと納期が大幅にオーバー（大炎上）する。

④ BAct人材の「早期摩耗・離職」

BActのハコを先に作った結果、BPAstやBSstAが担うべき泥臭い業務（現場の業務フローヒアリング、例外処理の整理、ITベンダーとの要件定義調整など）が、すべてBActの元に流れ込んできます。

• 結果: 高度な戦略・構造化を担うべきBAct人材が、日々の現場トラブル対応やITプロジェクトの火消し業務に追われて埋没し、本来のミッションを果たせないまま疲弊して離職するリスクが高まります。

[画像クリックで拡大表示]

⑤ 成果（ROI）が見えるまでの「タイムラグ」と組織的解体リスク

BAct（全社構造）の成果は、全社的な重複排除や効率化として現れるまでに数年単位の時間がかかります。一方、BPAst（現場の業務改善）やBSAst（IT要件の最適化による開発費削減）は、単一プロジェクト単位で数ヶ月〜1年で分かりやすい成果（リードタイム短縮やコスト削減）を出せます。

• 結果: 現場で目に見える成果が出ないままBAct組織の維持コストだけがかさむため、経営陣や事業部から「あの部署は何をやっているのか」と懐疑的な目を向けられ、成果を出す前に縮小・解体されるリスクを負います。

[画像クリックで拡大表示]

まとめ・対策への示唆

BActを最優先で設置することが有効なのは、「M&A直後の構造再編」や「CEOの超強力なトップダウン主導」といった極めて限定的な場面に限られます。
日本企業においてBAct先行のデメリットを回避するためには、以下の工夫が不可欠です。

• BActを置く場合でも、外部コンサル＋少数精鋭にとどめる
• 同時に特定の1事業部に絞ってBPAst（兼務でも可）を即座に配置し、現場の実装ラインを同時に立ち上げる

「まずBPAst/BSAstで現場の成果と構造化の手応え（型）を作り、それを集約する形でBActをつくる」ステップを踏む方が、失敗の確率は大幅に下がります。

【結論】

日本企業におけるBAct/BAstの定着は、個人のスキル向上に依存するのではなく、「戦略（BAct：CEO直下）」「業務（BPAst：事業部側）」「IT（BSAst：CIO下）」の役割とハコ（組織）を明確に分権配置することから始まります。
「ハコ」を先行して作り、執行業務から独立したミッションと権限を与えることで、初めて人材が育ち、経営戦略と現場・ITが一直線につながる強固な変革体質を構築できます。
そしてその順番を間違えてはいけません。

[画像クリックで拡大表示]

BPAst（ビジネス・プロセスアナリスト） ⇒ BSAst（ビジネス・システムアナリスト） ⇒ BAct（ビジネスアーキテクト）

[画像クリックで拡大表示]

最近AI駆動開発という言葉を聞きます。またAI-DLCもあります。この2つは同じことでしょうか、それとも別の意味があるのでしょうか。またビジネスアナリストとはどのような関係があるのでしょうか。

「AI駆動開発」と「AI-DLC」はかなり近い概念ですが、同義ではありません。

• AI駆動開発＝「AIを開発プロセスの中心的な協働者として位置づける開発スタイル全般」を指す包括的な概念です
• AI-DLC＝AWSのRaja SPが2025年に提唱し、「AI-Driven Development Lifecycle (AI-DLC) Method Definition」というホワイトペーパーで定義した、具体的なソフトウェア開発メソドロジーです

1. まず「AI駆動開発」とは何か

「AI駆動開発」という言葉は、現時点ではかなり広く使われています。典型的には、

• ChatGPT / Claude / Geminiによるコード生成
• GitHub Copilotによるコーディング支援
• Cursor / Windsurf等によるAIコーディング
• Claude Code等によるAgentic Coding
• AIによるテストコード生成
• AIによるコードレビュー

などを総称して「AI駆動開発」と呼ぶケースが多いです。
つまり従来の、

• 人間 → コードを書く → AIが支援　から

• 人間＋AI → AIがコードを生成・修正・テストする

へ変わったものです。

2. しかし、ここには大きな段階差があります

AI駆動開発を、4段階に分けて考えると分かりやすい。

現在、多くの企業が「AI駆動開発」と呼んでいるものは、実際には L2～L3 くらいです。
例えば、「ログイン機能を作って」とClaude Codeなどに指示すると、

1. ソースコードを調査
2. 必要なファイルを特定
3. コードを書く
4. テストを書く
5. テストを実行
6. エラーを修正
7. 再テスト

までやってくれます。これは明らかに従来の「AIコーディング支援」より格段進んでいます。

3. そこで登場するのがAI-DLC（AI-Driven Development Lifecycle）。

AI-DLCの具体的な構造：

• 3フェーズ構成:Inception(方向づけ)、Construction(構築)、Operations(運用)の3フェーズに、人間の意思決定ゲートを組み込んだ構造になっています
• 「Mob Elaboration」：Inception時にチーム全員でAIの質問・提案に答えながら要件定義を行います。
  「Mob」とは、ソフトウェア開発の既存プラクティスであるモブプログラミング(1台のPCの前にチーム全員が集まり、1人がドライバー(入力担当)、残り全員がナビゲーター(思考・指示担当)として同時に1つのタスクに取り組む手法)の考え方をAI協働に転用したものです。ペアプログラミングの「2人版」をチーム全体に拡張したイメージです。AI がビジネス意図を詳細な要件、ストーリー、ユニットに変換し、チーム全体が AI の質問や提案を積極的に検証します。作業そのものは全てAIが行い、そのアウトプットの是非をチームが判断します。意思決定能力のあるメンバーが参加することが本質的に重要です。AIが作成したものをその場で意思決定するので、要件定義が爆速で行われるわけです。
• 「Mob Construction」：AI が論理アーキテクチャ、ドメインモデル、コードによる実装、テストを提案し、チームメンバーがリアルタイムで技術判断を行います。ここでも意思決定能力のあるメンバー（アーキテクトやテスターなど）が必須です。その結果爆速で構築が可能になります。
•  独自用語:「Bolt」：従来の「スプリント」に相当しますが数時間~数日単位の短サイクルです。爆速開発を実現するためにはスプリント（2週間）では間に合いません。
• ガバナンスの課題:誰がAIの計画したものを承認する権限を持つか、本番投入前にAIが書いたコードがクリアすべき評価基準は何か、といった点は文書化されておらず、組織側で承認者・レビュー基準・評価基準を自前で用意する必要があります

両者の関係整理を整理します

ビジネスアナリシスとの関係

AI-DLCの構造は、BABOKの要求分析プロセスと重なりつつ、BAの役割を進化させます。

1. Inceptionフェーズ=要求の引き出しを再定義します:
   AIが対話を開始し、ビジネス上の意図を実行可能なタスクに分解し、ドメインモデル・コード・テストを生成する一方で、開発者やプロダクトオーナーは重要な意思決定ポイントでの戦略的検証者として機能します。つまり従来BAが担っていた「要求の言語化」の初動をAIが代行し、BAはAIが生成した要求の妥当性検証・優先順位付け・ステークホルダー調整という、より上流の判断業務にシフトします。
2. Mob Elaboration=BAのファシリテーション能力が問われる場です:
   AIへの質問・提案にチーム全体で応答する形式は、従来のワークショップ型引き出し(BABOKの「引き出しとコラボレーション」知識エリア)のAI版と言えます。BAには、AIの提案の曖昧さや漏れを見抜き、適切な追加質問を即座に投げる能力が求められます。
3. 要求のトレーサビリティ:
   金融や医療などの厳格な業界において、AWS AI-DLCは「ビジネスの目的」から「最終的にデプロイされたコード・テスト結果」までを1つのチェーンで自動記録します。 ビジネスアナリストが「この機能は法改正の条項Aを満たすため」と定義（Inception）すれば、AIはその要件に紐づくテストケースと実装を作成し、監査用ログを残します。ビジネスガバナンスとAIの爆発的なスピードを両立させる要となります。これはBABOKの「要求ライフサイクルマネジメント」知識エリアそのものであり、AI-DLC導入企業ではBAがこのトレーサビリティ設計の責任者になる可能性が高いです。
4. Inception フェーズ/Mob Elaborationや要求のトレーサビリティを考慮するとBAの役割が最重要と言えます。BAなくしてAI-DLCはあり得ないと言えます。

更にAI-DLCを高度に実装しようとすると「技術的な問題のみならず組織的・政治的な問題」がAI-DLCの実装局面で大きく顕在化します。それはInception フェーズで意思決定の権限を持たない開発者やプロダクトオーナーだと効果が薄れてしまうからです。そこには組織そのもののAI-Readyな成熟度モデルを理解する必要があります。

成熟度レベルとAI-DLC適用度の対応

成熟度レベル2→3移行の核心 ― なぜ「組織的」なのか

AI-DLCの3フェーズ構造自体は技術的にはレベル2でも動かせます。しかし、それが機能するかどうかを分けるのは以下の非技術的な壁です。

1. 承認権限の再配置が必要 — 従来「誰が要件を承認するか」は明確な組織階層(スポンサー→BA→開発リード)に沿っていました（BABOKでは「BAガバナンスを計画する」タスクで決めておく）。AI-DLCのMob Elaborationでは、AIの提案に対してチーム全員がリアルタイムで応答するため、承認権限が「役職」から「その場で判断できる専門性」へと移行します。これは人事評価・責任の所在という政治的問題そのものです。持ち帰って上司の判断を仰いでいる時間はありません。
2. 評価基準の空白を誰が埋めるか — 前回触れたとおり、AWS自身のドキュメントもここは示していません。「AIが書いたコード/生成した要求モデルがどの品質基準をクリアすれば本番適用可か」を決める権限を、開発リードが持つのか、BAが持つのか、新設のCAIOが持つのか——これは技術選定ではなく権力配分の設計です（BABOKでの「BAガバナンスを計画する」タスク）。
3. BoltへのAgile組織の抵抗 — 2週間単位のスプリント運用に最適化された評価制度・報告ライン・予算サイクルが、時間~数日単位のBoltと衝突します。人事考課制度や予算承認プロセスという「制度の慣性」が変わらない限り、現場はAI-DLCの速度についていけません。

このように、AI駆動開発（特にAI-DLC）を効果的に機能させるためには組織のAI成熟度もそれなりに高めておく必要があります。その中心的役割を果たすのがビジネスアナリストです。AI駆動開発（特にAI-DLC）を効果的に実装するためには早期にビジネスアナリストを育成する必要があります。

最近はSIerのみならず、コンサル会社までFDEサービスに躍起になっているように見受けらます。このようなサービスはPalantirのような「プロダクトと現場のフィードバック・ループ」を回す本物のFDEとの違いは何でしょうか。日本市場のみの現象でしょうか。

Palantir（パランティア）などのテック企業が実践する「本物のFDE」と、日本のコンサル会社が打ち出す「FDEサービス」には、ビジネスモデルと構造上の決定的な違いがあります。

「本物のFDE」と「コンサル型FDE」の決定的な違い

最大の違いは、「自社のコアプロダクト（製品）の成長」を目的にしているか、それとも「純粋な人月の受託・サービス提供」を目的にしているかという点です。

フィードバック・ループの「中身」が違う

• 本物のFDE： 現場でコードを書く中で「製品のこの機能が足りない」と気づいたら、自社の製品をアップデートします。つまり、彼らにとっての現場は「製品を育てるための実験場」です。
• コンサル型FDE： 現場でAIを実装して得た知見（現場知見）を、製品ではなく「顧客の次の戦略」へとループさせます。これは非常に優れたアプローチですが、実態としては「戦略から実装までを一気通貫でやる、超高速・密着型のITコンサルティング」であり、プロダクトありきのFDEとは根本的に構造が異なります。

なぜ日本のコンサルやSIerが「FDE」に躍起になるのでしょうか（日本特有の事情）

日本には「ユーザー企業にITエンジニアがほとんどおらず、SIerやコンサルに丸投げしている」という独自の構造があります。 これまで日本のコンサルは「絵（戦略）を描くだけで実装しない」、SIerは「言われた通りに作るだけでビジネスがわからない」と批判されてきました。さらに昨今の生成AIブームにより、「PoC（概念実証）ばかりで本番実装されない」という強い危機感が顧客側にあります。 そこで、コンサルは「私たちは戦略から本番コードの記述（実装）まで地続きでやりますよ！」という姿勢をアピールするための最高に格好いいラベルとして、「FDE」という言葉を拝借しているのではないでしょうか。

 顧客にとって「コンサル型FDE」は悪なのか？

もしこのサービスが、単に「コンサルタントとエンジニアをセットにして高く売るためのパッケージ（言葉のすり替え）」であれば、いずれ顧客に見限られて失敗するでしょう。
しかし、もし彼らが「本番環境で稼働するシステムまで責任を持って提供し、PoCで終わらせない」ことを本当に泥臭くやり切る（＝旧来の口先だけのコンサルから脱却する）のであれば、エンジニア不足に悩む日本のユーザー企業にとっては、頼もしい「外付けの変革エンジン」になる可能性はあります。
いずれにせよ、「FDE」という言葉が持つ本来の『プロダクト重視』の思想とは形を変え、日本市場の“丸投げ構造”に適応した「高速・現場密着型コンサル」へとガラパゴス進化した姿が、現在の日本のFDEブームの正体と言えそうです。

名称だけ自分たちの都合の良いタイトルFDEを使用しても、中身は似ても似つかない「FDEサービス」になってしまっているのは情けないですね。

日本で成功する条件：ビジネスアナリシス

ただし、成功する可能性がないわけではありません。そのための重要な条件がビジネスアナリシスです。FDEのチーム構成として戦略部分をしっかりビジネスアナリストが分担すると成功する可能性が高まります。そして優秀なAIエンジニアとタッグを組むことです。従来日本のエンジニアが顧客の戦略（ビジネス）を経営者と対等に議論できることはあり得ません。まさにビジネスアナリストの出番です。それが日本流のFDEの成功する道ではないでしょうか。

そういえば、当初はデジタルトランスフォーメーションをDXと言っていたはずのものが、いまでは単なるIT化のことまでDXと扱っているのと似ていますね。横文字の用語（FDEやDX）を日本流に勝手な解釈で言い換えてしまうのはいい加減やめにしてほしいと思います。

日本のSierが常駐SEの進化系としてFDEを進めようとしています。顧客の言われるままのITシステムを構築してきただけで、BAスキルは殆どないままです。このような日本のSierのFDEが失敗しないためにはどのようなことが必要でしょうか。失敗することの方が良いのかもしれませんが。生成AIに聞いてみました。

「これまでの常駐SE（言われた通りに作る人）」の延長線上で、名前だけをFDE（ビジネスを技術で解決する人）に変えても、100%失敗します。
なぜなら、両者は「求められるマインドセット」と「ビジネスモデル」が真逆だからです。
日本の伝統的なSIerがこの「FDEへのトランスフォーメーション」で自滅せず、かといって単なる言葉遊びで終わらせないために何が必要なのか。そしてなぜ「一度派手に失敗した方がいい」と言えるのか、3つの視点からアドバイスをまとめました。

SIer型FDEが直面する「3つの致命的な罠」

まず、BA（ビジネスアナリスト）スキルやドメイン知識がないままFDEを名乗ると、高確率で次の罠にハマります。

1. 「高級な御用聞き（何でも屋）」の再生産

顧客の言われるがままに動く癖が抜けないため、現場に入り込んだ結果「顧客の社内ニート化したIT部員」の雑用や、エクセルのマクロ修正、単なるデータ整形をやらされる「超高給な派遣エンジニア」に成り下がります。

2. 多重下請け構造の限界

FDEの本質は「顧客と対等に議論し、アーキテクチャを決める」ことです。しかし、SIerの商流（元請け→二次請け…）の中にFDEを組み込もうとすると、現場のエンジニアに裁量権がなくなり、結局「上の指示待ち」になって機能しなくなります。

3. 「人月ビジネス」との自己矛盾

SIerの儲けの源泉は「人を長く、多く現場に張り付けること（人月）」です。一方でFDEの価値は「仕組みを作って、早く現場を自立させて撤退すること」です。ビジネスモデル自体が矛盾しているため、SIerの営業や経営層がFDEの足を引っ張ることになります。

失敗しないために必要な「3つのドラスティックな変革」

もし本気でSIerがFDEを成功させたいのであれば、単なる「技術研修」ではなく、組織のOSそのものを入れ替える必要があります。

1. 「NO」と言える契約と評価制度への変更

「顧客の言う通りにシステムを作ったこと」を評価するのをやめ、「顧客の不要な業務プロセスをどれだけ削ったか」「どれだけ早く自社が撤退できる状態を作ったか」をFDEの評価指標（KPI）にする必要があります。また、顧客が理不尽なシステム化を求めてきた際に、技術的・ビジネス的観点から「それはやるべきではない」と突っぱねられる契約上の地位（あるいは関係性）を担保しなければなりません。

2. 「BA＋データ工学」のハイブリッド人材の『外部登用』

既存の常駐SEを教育してFDEにするのは時間的にもマインド的にも無理があります。まずは、コンサルティングファーム出身のBAや、事業会社で修羅場をくぐってきたデータエンジニアを「FDEチームのリーダー」として外部から高給で引き抜くべきです。生粋のSIer育ちのエンジニアは、そのリーダーの動きを現場で「見習う」ことから始めるしかありません。

3. 提供価値の「標準化（アセット化）」の仕組み化

個人の能力に依存するSIerの体質のままでは、FDEはただの「一騎当千のスーパーマン」頼みになります。A現場でFDEが作ったデータパイプラインや業務改善のフレームワークを、即座に社内で共有・テンプレート化し、「2回目からは誰でも7割のクオリティで再現できる」仕組み（アセット化）を組織として構築する必要があります。

組織のOSの入れ替えがうまくできなかった場合。

名前だけ変えた「疑似FDE」が現場でバグを連発したり、顧客のビジネスを混乱させたりして大炎上すれば、SIerも顧客企業もようやく以下の現実に気づくことになります。

• 顧客側： 「ITの丸投げはもう限界だ。自分たちでビジネスと技術がわかる人間（本当のBAやPM）を内製化しないと会社が潰れる」
• SIer側： 「人貸しビジネスの延長で高度なDXビジネスを気取るのは不可能だ。自社のビジネスモデルを根本から変えるか、受託開発に特化するか選ばなければならない」

「中途半端に延命するくらいなら、一度この取り組みで手痛い失敗を迎えた方が、日本のIT業界のためになる」のかもしれません。（清水）

前回、顧客業務を深く理解し、適切な業務設計・AI設計・実装を一気通貫で行える人材としてFDEの需要は高まると論じてきました。しかし良いことだけではありません。FDEが不在（別の顧客に移った場合）の際の製品のメンテナンスはどうするのでしょうか。後半（今回）はその課題への対処方法を考えてみましょう（清水）。やはり生成AIによる回答をご覧ください。

結論から言うと、FDEに依存したままプロジェクトを進めると、メンテナンス上の大きなリスクがあります。 実際、多くのAI企業でもこの点が課題として認識されており、FDEは「何でも一人で抱え続ける人」ではなく、顧客が自立運用できる状態を作る人へと役割が変化しています。

なぜFDEが属人化しやすいのか

FDEは次のような領域を横断して担当します。

• 業務分析
• AIエージェント設計
• システムアーキテクチャ設計
• コード実装
• プロンプト設計
• RAG設計
• 顧客との意思決定

これらを一人で理解しているため、担当者が異動・退職すると、

• 「なぜこの設計にしたのか」
• 「このプロンプトは何を意図しているのか」
• 「このAIエージェントはどの業務ルールを反映しているのか」

といった暗黙知が失われやすくなります。

特にAIシステムではリスクが大きい

従来の業務システムでは、コードを読めばある程度動作を理解できます。
しかしAIシステムでは、例えば以下のような要素が絡みます。

• プロンプト
• デル選定
• ツール呼び出し
• RAGの検索設計
• 評価基準
• ガードレール
• 業務ルール

これらはコードだけでは意図を理解しにくく、設計判断の背景が重要です。

先進企業はどう対策しているか

AI企業では、FDEが成果物だけを残すのではなく、「設計資産」を残すことを重視しています。例えば、

• ビジネス要件：どの業務課題を解決するのか
• AI要件：どの判断をAIに任せるのか
• プロンプト設計書：プロンプトの目的や変更履歴
• エージェント設計書：役割、ツール、制約条件
• 評価基準：何をもって「良い回答」とするか
• 運用手順書：モデル更新や障害時の対応方法

こうしたドキュメントを整備し、属人化を防ぎます。

 ビジネスアナリストの役割が重要になる

ここで、ビジネスアナリシスが非常に重要になります。
FDEは実装に強い一方で、業務知識や要求の背景を体系的に整理することは、必ずしも得意とは限りません。そこで、ビジネスアナリストが以下を成果物として残すことで、保守性が大きく向上します。

• ビジネスゴール
• 業務能力（Capability）の定義
• 業務プロセス
• 要求仕様
• 業務ルール
• KPI
• 意思決定モデル

これらがあれば、新しいFDEでも「何を実現すべきか」を理解しやすくなります。

AI時代は「FDE＋BA＋AI運用」の分業が現実的

理想的な体制は、一人のスーパーマンに依存するのではなく、次のような役割分担です。

このように知識を分散し、成果物を標準化することで、FDEが交代しても保守を継続しやすくなります。

FDEをビジネスアナリストの代替ではなく、その実装パートナーとして捉えるのが適切

むしろ生成AI時代には、ビジネスアナリストが「なぜ・何を実現するのか」を構造化し、FDEが「どう実現するか」を設計・実装するという役割分担の方が、保守性・拡張性・人材育成の面で持続可能です。
この観点から見ると、BABOKによる要求分析と、BIZBOKのCapability Mapは、FDEの成果を長期的に維持・改善するための「設計資産」として、これまで以上に価値が高まると言えるでしょう。

やはり、メンテナンスまで考えるとFDEだけでは不足でBAが不可欠になるということです。（清水）

次回（3回）は日本の大手SIerが常駐SEの進化系としてFDEを考えている風潮について考察していきます。当初は予定していなかったのですが、意外と日本市場でも脚光を浴びているようなので気になっています。

最近FDE（Forrward Deployed Engineer）という職種の名称を耳にします。これはどのようなことをする職種なのでしょうか。AI企業で使われているようなので、生成AIに聞いてみました。

**FDE（Forward Deployed Engineer）**とは、

• 顧客の現場（Forward Deployed）に深く入り込み、顧客と一体となって技術的な課題を解決しながら、プロダクトそのものも進化させるエンジニアです。

近年、AI企業やデータプラットフォーム企業を中心に急速に注目されている職種で、特に生成AI時代には非常に重要な役割になっています。代表的な企業としては、Palantir Technologiesがこの職種を広め、その後、OpenAI、Anthropic、Scale AIなどでも採用されています。

FDEを一言で表すと

• 「コンサルタント」と「ソフトウェアエンジニア」と「ソリューションアーキテクト」を一人でこなす人
• 単なるSEでも営業技術でもありません。顧客と一緒に問題を定義し、AIやソフトウェアを組み合わせて解決策を作り、その知見を製品へフィードバックします。

なるほど、AI企業で始まり徐々に広まっているようです。その具体的な仕事内容はどんなものでしょうか（清水）。

典型的な仕事内容

例えば製造業の場合の顧客の要望。
工場長：「設備停止を予測したい」

Forward Deployed Engineerは

• 現場へ行く
• 設備データを見る
• 問題を整理する
• AIを試作する
• APIを書く
• ダッシュボードを作る
• 運用まで支援する
• その経験を製品へ反映する

つまり、顧客専用の開発だけで終わらず、プロダクトも改善することが重要です。

通常のSEとの違い

かなり違いますね（清水）

コンサルタントとの違い

コンサルタントは

• 課題分析し
•   提案書
•   終了

ですが、FDEは

• 課題分析
•   実際にコードを書く
•   AIを組み込む
•   顧客へ導入
•   運用
•   プロダクト改善

つまり提案だけでは終わらないところが最大の違いです。

AI時代になぜ重要か

生成AIでは「AIを入れれば終わり」ではありません。実際には

• 顧客業務
• 業務分析
• ワークフロー設計
• LLM選択
• プロンプト設計
• RAG
• Agent
• 評価
• 改善

これらを全部理解している人が必要になります。これがFDEです。

必要なスキルは次のとおりです

① ソフトウェア開発

• Python
• TypeScript
• API
• SQL
• クラウド

② AI

• LLM
• プロンプト設計
• RAG
• AI Agent
• MCP
• Tool Calling
• Evaluation

③ ビジネスアナリシス

ここが非常に重要です。

• 業務分析
• 要求分析
• KPI設計
• 業務プロセス
• Capability分析

つまりBAの能力が非常に重要になります。

④ 顧客折衝（これもBA能力）

• ファシリテーション
• インタビュー
• ワークショップ
• プレゼン

つづいてBAとの関係はどのようなものになるのでしょうか。

これはユーザーが関心を持たれているテーマとも深く関係します。従来はBAからSEへ要求を渡せば済んでいました。

• Business Analyst
• 要求定義
• SEへ渡す

AI時代では、次の様になります。

• Business Analyst
• AI Agent設計
• FDE
• 実装
• 顧客改善

すなわち、

• Business Analyst ＋　Forward Deployed Engineer

という形で、一人が両方の役割を担うケースも増えています。

AI企業では

• 業務分析
• 要求分析
• AI設計
• PoC
• 実装

まで一人で担当するケースが珍しくありません。

今後のキャリアとしての位置付け

生成AIの普及に伴い、FDEは今後さらに重要になると考えられます。

• Business Analyst
• AI Business Analyst
• Forward Deployed Engineer
• AI Solution Architect

というキャリアパスを描く企業も増えています。

特に、これまで取り組まれているCBAPやBABOKによる要求分析の知識に、AI実装やエージェント設計、クラウド開発のスキルを組み合わせることで、AI導入をビジネス成果につなげる人材として高い価値を発揮できます。

ビジネスアナリストとの関係

現在のFDEは、従来の「要件を聞いてシステムを作るSE」ではなく、ビジネスアナリストの課題発見力とエンジニアの実装力を兼ね備えた職種へ進化しています。AIエージェントの導入が進むほど、顧客業務を深く理解し、適切な業務設計・AI設計・実装を一気通貫で行える人材の需要は高まると考えられます。これは、ビジネスアナリシスとAI技術の橋渡し役として、今後ますます重要なポジションになるでしょう。

しかし、これって一人でできることなのでしょうか。また、FDEが不在（別の顧客に移った場合）の際の製品のメンテナンスはどうするのでしょうか。後半（次回）はその課題への対処方法を考えてみましょう（清水）。

前回3つの新しいハイブリッド職種を紹介しました。

• ワークフォース・アーキテクト(Workforce Architect)。
• ジョブ・リデザイナー / ワークデザイナー。
• タレント・トランスフォーメーション・リード

どちら側から融合領域に入るか:2つの経路が可能です。
この融合領域には、HR 側からも BA/BArch 側からも到達できます。それぞれに強みと課題があります。

HR 側から入る経路。

人と組織への深い理解、変革管理(チェンジマネジメント)、従業員の感情やキャリアへの配慮を強みとして持っています。これらは BA/BArch が苦手とする「人間的な側面」です。課題は、業務プロセスの構造的分析や、AI 技術の理解が弱いこと。ここを補強する必要があります。

BA/BArch 側から入る経路。

業務の構造化、要件定義、AI 活用の設計を強みとして持っています。課題は、人間の感情、モチベーション、キャリア、組織政治といった「人の側面」への理解が浅いこと。AI 前提で業務を設計できても、「その業務を担う人間がどう感じ、どう動機づけられるか」への配慮が抜けがちです。

どちらの経路でも、自分に欠けている側を補強することで融合領域に到達できます。そして、どちらの経路が優れているということはなく、組織には両方の出自の人材が必要です。

日本企業にとっての特別な意味

この融合は、日本企業にとって特に重要な意味を持ちます。

これまでの議論で繰り返し出てきたように、日本企業の AI 変革の最大の障壁は、終身雇用・メンバーシップ型雇用の中での役割変更の難しさでした。「この業務はもう要らない」「あなたの役割は変わる」という結論を、雇用不安を生まずに実現する必要がある。
これは純粋な BA/BArch だけでは絶対にできません。業務を構造的に再設計する力(BA)と、人間の雇用・キャリア・感情に配慮しながら移行を導く力(HR)の両方が、不可分に必要です。
つまり日本企業でこそ、HR と BA/BArch の融合領域を担う人材が、AI 変革の成否を握る決定的な役割になります。欧米企業のように「業務が変わったら人を入れ替える」ことができない日本企業では、「業務変革と人材移行を一体で、丁寧に設計する」能力が、何よりも重要になるからです。

組織としてどう対応すべきか

では、企業はこの変化にどう対応すべきでしょうか。現実的な打ち手を整理します。

1. HR 部門に BA/BArch スキルを注入する。HR 担当者に業務プロセス分析、ケイパビリティ思考、要件定義のスキルをリスキリングする。あるいは、BA/BArch 出身者を HR 部門に配置する。
2. HR と DX 推進部門(BA/BArch がいる)の連携を制度化する。両者をペアで動かす。前回の議論で「DM と BA/BArch のペア制」を提案しましたが、同様に「HR と BA/BArch のペア制」が AI 変革には必要です。
3. ワークフォース・アーキテクト的な役割を明示的に設ける。業務変革と人材変革を統合的に設計する役割を、組織図上に位置づける。CHRO 配下、あるいは CHRO と CDAO の協働領域として設計します。
4. CHRO 自身が BA/BArch 的視点を持つ。前回の議論で「CHRO が AI 時代に進化する必要がある」と述べましたが、その進化の中核が、まさにこの BA/BArch 的な構造設計力の獲得です。

まとめ

• 「人間 + AI の協働設計」は BA/BArch が得意とする領域であり、AI 時代の HR はこの BA/BArch スキルを取り込む必要があります。
• しかし正確には、「HR が BA になる」のではなく、HR と BA/BArch の境界に新しい融合領域が生まれ、その融合領域を担う人材(ワークフォース・アーキテクト等)が AI 変革の鍵を握る、という構図です。
• その融合領域は、業務の構造設計(BA/BArch の強み)と、人間への配慮を伴う変革管理(HR の強み)の両方を必要とします。どちらか一方では機能しません。
• そして日本企業にとっては、雇用の制約の中で業務変革と人材移行を一体で設計する必要があるため、この融合領域の人材が、欧米企業以上に決定的な重要性を持ちます。
• 突き詰めると、これまでの一連の議論で浮かび上がってきたのは、AI-Ready な組織への変革は、技術・データ・業務・人材の境界がすべて溶け合い、統合的に再設計される必要がある、という一貫したテーマです。データマネジメントと BA/BArch の融合、AI とデータの融合(CDAO)、そして今回の HR と BA/BArch の融合 — これらはすべて同じ現象の異なる側面です。AI 時代の組織設計とは、従来分かれていた専門領域を、いかに統合するかという挑戦なのだと言えます。

AI時代には、AIと人間との協働の在り方が重要になります。業務を分析しどの業務をAIに任せ人間は何をするべきかを考えなくてはいけません。業務分析はビジネスアナリスト（BA）やビジネスアーキテクト（BArct）が得意とする分野でありますが、人間の仕事を考えるのは人材開発（HR）です。AI時代におけるHR（人材開発）とBAとの関係はどのようなものになるのでしょうか。

人間とAIとの関係なので、AIと共に考えてみたので紹介します。

AI 時代の HR は BA/BArch のスキルを取り込む必要があり、これは HR という職種の性質そのものを変える可能性があります。ただし「HR が BA になる」のではなく、「HR と BA/BArch が融合した新しい領域が生まれる」と捉える方が正確です。

順を追って説明します。

 なぜ協働設計が HR と BA/BArch の両方に関わるのか

まず、「人間 + AI の協働設計」という仕事が、なぜ両職種の境界に位置するのかを整理します。

この仕事を分解すると、実は2つの異なる設計が含まれています。

• 設計1:業務プロセスの側の設計(BA/BArch が得意) どの業務をどう分解し、どこを AI が、どこを人間が担うか。業務フロー、判断ポイント、エージェントのオーケストレーション。これは業務構造の設計であり、BA/BArch の領域です。
• 設計2:人間の側の設計(HR が得意) その新しい役割を担う人間に、どんなスキルが必要か。どう育成し、どう評価し、どう動機づけ、どうキャリアを設計するか。役割が変わる人をどう移行させるか。これは人と組織の設計であり、HR の領域です。

従来、この2つは別々の専門家が担っていました。BA/BArch が業務を設計し、その後で HR が「では必要な人材を用意します」と引き継ぐ、という分業です。

しかし AI 時代には、この2つを分離できなくなります。ここが本質です。 

なぜ分離できなくなるのか

理由は、AI 時代の業務設計と人材設計が相互依存になるからです。

具体例で考えてみます。あるカスタマーサポート業務を「AI が一次対応し、人間が例外処理と判断を担う」形に再設計するとします。
このとき、「どこまでを AI に任せ、どこから人間が介入するか」という業務設計(BA の領域)は、「人間側にどんなスキルがあるか」「どんな人材を育成・配置できるか」(HR の領域)と切り離せません。人間の能力を無視して業務だけ設計しても機能しないし、業務設計を知らずに人材だけ用意しても噛み合わない。
さらに、AI に仕事を任せた人間が「より高度な判断業務にシフトする」とき、その新しい役割の定義(BA)と、その役割を担えるよう人を育てる仕組み(HR)は、同時に・一体で設計しなければなりません。

つまり、「業務をどう変えるか」と「人をどう変えるか」が一体不可分になる。これが AI 時代の特徴であり、HR が BA/BArch スキルを必要とする根本理由です。 

HR が必要とする BA/BArch スキルとは具体的に何か

では、AI 時代の HR が取り込むべき BA/BArch のスキルを具体的に挙げます。

• 業務プロセス分析・モデリング。業務を構造的に分解し、可視化する力。どの業務がどんなタスクで構成され、どこに AI 適用の余地があるかを見抜く。従来の HR は「人」を見てきましたが、これからは「業務」を構造的に見る力が必要になります。
• ケイパビリティ思考。個別の業務ではなく、組織のビジネスケイパビリティ単位で「この能力をどう人間 + AI で実現するか」を考える視点。BArch の中核スキルです。
• 役割・職務の設計力(ジョブデザイン)。AI 前提で職務を再定義する力。これは従来の HR にもジョブデザインの概念はありましたが、AI 時代には「人間と AI の役割分担」を含む、より動的で構造的な設計が求められます。
• 要件定義と翻訳の力。「この業務にはこういう人材が必要」を、業務要件から構造的に導く力。BA の中核である「要件定義」のスキルです。
• 変革のロードマップ設計。業務変革と人材移行を時間軸で連動させる計画力。BArch のロードマップ設計と、HR の人材計画を統合したものです。

これらは、まさに BA/BArch が得意としてきた領域です。

では「HR が BA になる」のか?

• ここで慎重に考える必要があります。HR がそのまま BA/BArch になるわけではありません。逆方向も同様で、BA/BArch が HR になるわけでもない。
• 正確には、両者の境界に「新しい融合領域」が生まれると捉えるべきです。この融合領域を担う人材は、両方の素養を持ちます。
• 具体的には、次のような役割が立ち上がりつつあります。

• ワークフォース・アーキテクト(Workforce Architect)。直訳すると「労働力の設計者」。人間と AI を含めた「組織の働き方の全体構造」を設計する役割です。BArch が業務構造を、HR が人材を見るのに対し、ワークフォース・アーキテクトは**「業務 × 人材 × AI」を統合的に設計**します。これはまさに HR と BArch の融合です。
• ジョブ・リデザイナー / ワークデザイナー。AI 前提で個別の職務を再設計する役割。BA のプロセス分析力と、HR のジョブデザイン力を併せ持ちます。
• タレント・トランスフォーメーション・リード。業務変革に連動した人材移行を設計・推進する役割。BArch のロードマップ設計と、HR のリスキリング設計を統合します。

これらは、従来の「HR 担当者」でも「BA」でもない、新しいハイブリッド職種です。

続きは次回をお楽しみに。

前回同様に生成AIに、AI-Readyな組織になるために、ビジネスアナリストやビジネスアーキテクトはどの程度重要なのか、を聞いてみました。その回答/解説をご覧ください。

ビジネスアナリスト/ビジネスアーキテクトの重要性

結論から言うと、極めて重要です。AI導入の成否を分ける「隠れたキーロール」と言ってよいほどです。特にAI-Readyへの移行期(Level 2〜4)では、その重要性が顕在化します。

なぜ重要なのか

• AI導入で最も多い失敗は「技術はあるのにビジネス価値が生まれない」ことです。その原因のほとんどは、ビジネス要件とAI技術の間の翻訳・設計が欠けていることにあります。ここを埋めるのがビジネスアナリスト(BA)とビジネスアーキテクト(BArch)です。
• データサイエンティストは「モデルをどう作るか」には強いですが、「どの業務に、なぜ、どのように組み込むか」を設計するのは別のスキルセットです。経営層のビジョンと現場の業務、そしてAI技術の三者を橋渡しする専門家が不可欠になります。

それぞれの役割の違い

• **ビジネスアナリスト(BA)**は、現場寄りで個別プロジェクトレベルの課題定義・要件整理・効果測定を担います。「このプロセスのどこにAIを適用すれば、どんな価値が生まれるか」を具体化する役割です。
• **ビジネスアーキテクト(BArch)**は、より上位で全社・事業レベルのビジネスケイパビリティ、プロセス、組織構造を俯瞰し、AI戦略と整合する形でビジネス全体を設計します。「どのケイパビリティをAIで強化すべきか」「業務プロセスをどう再設計すべきか」を描く役割です。

両者はグラデーションの関係にあり、組織規模によっては兼任されることもあります。

AI文脈での具体的な貢献

1. ユースケース発掘と優先順位付け 現場の業務を深く理解しているBAは、「AIで解決すべき真の課題」を見つけられます。技術起点ではなく、業務課題起点でユースケースを定義できることが最大の強みです。
2. 要件定義とデータ要件の明確化 AIプロジェクトは通常のIT要件定義とは異なり、「何を予測したいのか」「どんなデータが必要か」「精度はどの程度必要か」「誤った場合の業務影響は何か」を定義する必要があります。これはBAの中核スキルです。
3. 業務プロセス再設計(AI-Native Process Design) AIを既存プロセスに「貼り付ける」だけでは効果は限定的です。BA/BArchがプロセス全体をAI前提で再設計することで、初めて大きな価値が生まれます。
4. チェンジマネジメント(変革管理) AI導入は必ず業務の変化と人の抵抗を伴います。ステークホルダー調整、現場への浸透、新しい働き方の設計はBA/BArchの得意領域です。
5. ROI・効果測定の設計 「PoC疲れ」を避けるには、最初から効果測定の仕組みを組み込む必要があります。ビジネス指標とAIパフォーマンス指標を結びつけるのもBA/BArchの役割です。
6. ガバナンスとリスク設計 どの業務でAIを使ってよいか、人間の判断をどこに残すか、といった設計はビジネス理解なしには不可能です。

成熟度段階ごとの重要性

特に**Level 2→3への移行(PoCから本番運用へ)**で失敗する組織が多く、ここでBA/BArchの不足が致命傷になります。

日本企業で特に重要な理由

日本企業の多くは、次のような事情からBA/BArchの重要性がさらに高まります。

• 業務が属人化・複雑化しており、AIを適用する前に業務の可視化・整理が必要
• 部門間のサイロが強く、横断的に設計できる人材が不足しがち
• 「まずツール導入」で現場が混乱するケースが多い
• データガバナンスやプロセス標準化が欧米企業に比べ遅れている傾向

実務上の示唆

• 組織としては、次のような打ち手が有効です。
• 既存の業務改善・BPR経験者をAI文脈でリスキリングする、データサイエンティストとBA/BArchをペアで配置する、CoE(Center of Excellence)にBA/BArch機能を明示的に組み込む、外部コンサルに丸投げせず内製のBA/BArch能力を育てる、といったアプローチです。

まとめ

AI-Readyな組織における人材構成で、データサイエンティストやAIエンジニアは「エンジン」ですが、BA/BArchは「ハンドルと地図」に相当します。エンジンだけあっても目的地には辿り着けません。AIの民主化が進むほど、逆に「何にAIを使うべきか」を設計する人材の希少価値が高まる、というのが現在の潮流です。

いかがでしょうか。ここまで明確に指摘されると納得せざるを得ないのではないでしょうか。（清水）