最近は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を使うべきか」を設計する人材の希少価値が高まる、というのが現在の潮流です。

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

最近「AI-Readyな組織」という言葉をは良く耳にします。どのような組織のことを言うのでしょうか。AIに深く関係しますので、生成AIに聞いてみました。以下生成AIによる大変興味深い解説です。

• AI-Readyな組織とは、AIを導入するための技術・データ・人材・組織文化・ガバナンスが整い、AIを継続的に活用して価値を生み出せる状態にある組織のことです。単に「AIツールを使っている」のではなく、業務プロセス・意思決定・戦略の中にAIが自然に組み込まれている組織を指します。

AI-Readyになるために必要な5つの柱

1. データ基盤： データが整理・統合され、品質管理されていること。サイロ化したデータはAIの最大の阻害要因です。
2. 技術・インフラ： クラウド環境、API連携、MLOps、セキュアなAIプラットフォームなど、AIを運用し続けられる技術基盤。
3. 人材・スキル：データサイエンティストやAIエンジニアだけでなく、現場の従業員全体がAIリテラシーを持つこと。
4. 組織・文化 ：経営層のコミットメント、部門横断の連携、失敗を許容する実験文化、データドリブンな意思決定。
5. ガバナンス・倫理： AI利用のルール、リスク管理、プライバシー・セキュリティ、責任あるAI(Responsible AI)の原則。

AI成熟度モデル(5段階)

Level 1: 認識期(Aware)

AIへの関心はあるが、散発的な利用にとどまる段階。

• 一部の個人がChatGPT等を試している
• データはサイロ化、戦略なし
• やるべきこと: 経営層のビジョン策定、AIリテラシー教育の開始、現状アセスメント

Level 2: 実験期(Experimenting)

個別部門でPoC(概念実証)を実施する段階。

• 限定的なユースケースで試行
• データ整備が部分的に進む
• やるべきこと: ユースケースの優先順位付け、小さな成功事例の創出、AI倫理ガイドライン策定

Level 3: 運用期(Operational)

特定業務でAIが本番運用されている段階。

• 複数の業務でAIが活用され、KPIで効果測定
• データガバナンスが確立
• やるべきこと: MLOps導入、部門横断のCoE(Center of Excellence)設置、スケール戦略の策定

Level 4: 統合期(Systemic)

AIが基幹業務に組み込まれ、全社展開される段階。

• 意思決定プロセスにAIが組み込まれる
• 全従業員がAIツールを日常的に利用
• やるべきこと: プラットフォーム化、継続学習の仕組み、ガバナンスの高度化

Level 5: 変革期(Transformational)

AIが競争優位の源泉となり、ビジネスモデル自体を変革する段階。

• 新規事業・製品がAIを前提に設計される
• AIがイノベーションを生み出し続ける
• やるべきこと: 業界・エコシステムへの貢献、継続的な自己変革

AI-Readyになるためのロードマップ(実践ステップ)

1. Step 1: 現状診断 — 5つの柱について成熟度を評価し、ギャップを可視化する。
2. Step 2: ビジョンと戦略策定 — 経営層が「AIで何を実現するか」を明確にし、全社に浸透させる。
3. Step 3: Quick Winの創出 — 効果が見えやすく、リスクが低い領域(例: 社内ドキュメント検索、議事録要約)から着手し、成功体験を作る。
4. Step 4: データ基盤とガバナンスの整備 — データの統合・品質管理、AI利用ルール、セキュリティ体制を構築。
5. Step 5: 人材育成 — 全従業員向けAIリテラシー研修、専門人材の採用・育成、CoE設置。
6. Step 6: スケールと定着 — 成功事例を全社展開し、業務プロセスを再設計。KPIで効果を継続測定。
7. Step 7: 継続的進化 — 技術・規制の変化に追随し、継続学習とアップデートを仕組み化。

よくある失敗パターン

• 技術導入を先行させて目的が曖昧になる「PoC疲れ」、経営層の関与不足、データ品質の軽視、現場の巻き込み不足、ガバナンス・倫理の後回し — これらを避けることが、AI-Readyへの近道です。
• 特に重要なのは「AIは道具であり目的ではない」という認識です。何を解決したいのかを明確にした上で、組織・人・データ・技術を段階的に整えていくアプローチが現実的です。

いかがでしょうか。AI-Readyの状態は理解できたのではないでしょうか。よくある失敗パターンはAI-Readyに限らずDXを含めて「あるある」ではないかと思います。

つづいてビジネスアナリストとの関係を明かしていきます。次回までお待ちください。

「SaaSの死（SaaS is Dead）」という言葉は、いまIT業界や投資家の間で非常にホットな議論になっています。

これは、SaaS（クラウド経由でソフトウェアを利用する仕組み）そのものが消えてなくなるという意味ではなく、「人間が画面をポチポチ操作してデータを入力・管理する」という、これまでのSaaSのあり方が終わるという予測を指しています。

なぜそう言われているのか、主な理由は以下の3点に集約されます。

1. AIエージェントへの主役交代（最大の理由）

Microsoftのサティア・ナデラCEOが「AIエージェントの時代には、従来のSaaSという概念は崩壊する」といった趣旨の発言をしたことが大きなきっかけです。

• これまでのSaaS: 人間がCRM（顧客管理）や会計ソフトを開き、自分で数字を入力したりボタンを押したりしていました。
• これからの世界: AIエージェントが、わざわざソフトの画面を開かなくても、指示一つで裏側にあるデータベースを書き換えたり、複数のアプリをまたいで仕事を完了させてくれます。
• つまり、「アプリの画面（UI）」という存在が不要になり、AIという「窓口」ひとつで済むようになるということです。

2. 「月額課金（ID課金）」モデルの限界

多くのSaaSは「1ユーザーあたり月額◯◯円」という料金体系をとっています。しかし、AIが人間の仕事を肩代わりするようになると、「利用する人間の数（座席数）」が減るため、従来のビジネスモデルが立ち行かなくなるという懸念があります。

3. AIによる「内製化」のハードル低下

これまでは「自分たちでソフトを作るのは大変だからSaaSを借りる」のが常識でした。しかし、今はAI（生成AI）を使えば、プログラミング知識が乏しくても、自社専用のツールを安価に作れるようになりつつあります。「わざわざ使いにくい汎用SaaSに高い金を払うより、自社専用ツールをAIで作ったほうが早い」という動きが出てきています。

本当に死ぬのか？

専門家の間では、**「死ぬのではなく『変態（メタモルフォーゼ）』するのだ」**という見方が有力です。

• SaaS（Software as a Service）
  • ソフトウェアをサービスとして提供する
• SaaA（Service as an Agent / Service as AI）
  • AIエージェントがサービスそのものとして機能する

現在は、Salesforceなどの大手SaaS企業も「AIエージェント」を軸にした仕組みへ急速に舵を切っています。

まとめると、「人間が頑張って操作しなければならない、面倒な道具としてのSaaS」は死に、AIが勝手に働いてくれる「自律型のサービス」へと進化しようとしている、というのがこの話題の本質です。

CoworkとSaaSの死の関係

1. 「道具」から「同僚（Coworker）」へ

従来のSaaSは、人間が効率よく作業するための「道具」でした。ExcelやSalesforceを「操作」するのは常に人間です。 しかし、これからはAIが**「自律的に動く同僚（AIエージェント）」**として隣に座るイメージになります。

• SaaS: 人間がAIを使ってレポートを作る。
• Cowork: 人間が「来週の会議用にレポートが必要だ」と口頭で伝え、AIが必要なデータを集め、グラフにし、Slackで関係者に共有するまでを勝手に終わらせる。

このように、AIと一緒に仕事を進める（Coworkする）ことが前提になると、人間が操作するための「SaaSの画面（UI）」はもはや不要になります。これが「SaaSの死」と呼ばれる理由の一つです。

2. 「座席（Seat）」ではなく「成果（Outcome）」への課金

Coworkの進展は、SaaS企業のビジネスモデルを直撃します。 これまでのSaaSは「何人がそのツールを使っているか（ID数/座席数）」でお金を取っていました。しかし、AIが同僚として働くようになると、**「人間10人分の仕事をAI1人がこなす」**といった状況が起こります。

• ユーザー（人間）の数が減るため、ID課金モデルは崩壊します。
• 代わりに、AIがどれだけ仕事（Cowork）を完遂したかという**「成果報酬型」や「従量課金」**へシフトせざるを得なくなります。

3. Cowork OS という考え方

「SaaSの死」の後に来るものとして、特定の機能（会計、人事、営業など）に特化したアプリではなく、AIが組織全体を横断してサポートする**「Cowork OS」**のようなプラットフォームが注目されています。

今までは「経費精算はAというSaaS」「顧客管理はBというSaaS」と、人間が各ツールをハシゴしていましたが、Coworkの世界ではAIが全てのツールのハブとなり、人間は一つの窓口（チャットや音声）を通じてAIと協働するだけで良くなります。

まとめ

• SaaSの死： 「人間が画面を開いてポチポチ入力する作業」がなくなること。
• Cowork： 「AIが自律的なパートナーとして人間と共にタスクを遂行する」こと。

つまり、SaaSという「箱」が死に、AIとの「共働関係（Cowork）」という「体験」がそれに取って代わるという関係性にあります。これまでSaaS企業が提供していた価値は、AIというエージェントの中に溶け込んでいく（インビジブル化する）と言い換えることもできます。

事の本質が「業務の実行主体が人間からエージェントに移る」であることは、業務の改善/改革のレベルではなく、まさに「業務の革命」と言うべきものです。

ただしその前提としてとして、業務が標準化されていることが必須です。部門や地域ごとにバラバラなプロセスを標準化する必要があります。PCFは、統一されたプロセス分類を提供するため、社内のプロセス整備や共通基盤の確立に役立ちます。日本の伝統的な現場の創意工夫による部分最適を改善することができます。例えば同じ業務でも東京と大阪では担当者レベルでプロセスが異なる場合、それを統一した（標準化した）プロセスにしてシステム化するなどが必要です。

そこで、以前から紹介しているAPQC PCFを考えてみます。

このPCFは組織全体の業務を13のカテゴリー（レベル1）に分類し、さらにその下位に、

• プロセスグループ（レベル2：72個）
• プロセス（レベル3：329個）
• アクティビティ（レベル4：1,200個以上）
• タスク

業務を階層構造化したもので組織全体の業務を網羅している参照モデルです。

PCFの詳細は以前のコラムを読んでいただきたいのですが、

業務のAI化と業務プロセス参照モデル（PCF）

もし業務が：

• PCFで標準化され
• データ構造が整理され
• 判断ロジックが明確化され

ているなら、AIエージェント導入の準備が整っているということになります。逆に言えば、BAが業務を明確化した瞬間にAI化可能性が顕在化するということです。これはいったい何を意味しているのでしょうか。

前回話題のSaaSの死は「序章」でしかすぎません。本質は「業務の実行主体が人間からエージェントに移る」ということですから、標準化が進んでいる組織では、影響はSaaSに留まりません。「業務設計」そのものに及びます。それはまさしく「業務革命」と言えるのではないでしょうか。

「業務設計能力を持つ組織」と「持たない組織」の分断が始まるような気がします。そしてその中心にいるのが PCFを熟知して業務の標準化を実現できるビジネスアナリスト（BA） です。

Cowork時代の本質

Anthropic の Cowork が示しているのは以下のことです。

• ソフトウェアを操作するAI
• 業務を横断するAI
• ワークフローを自律実行するAI

しかし、AIが実行できるのは：「定義された業務」だけです。つまり、業務が構造化（かつ標準化）されていない組織ではCoworkは無力なのです。

これからの競争を図示すると

つまり、「業務標準化能力 ＝ AI活用能力」になります。

BAの地位も大きく変わります。

これまでのBAの主な役割は以下のようでした。

• 要件定義
• 業務整理
• システム導入支援

これからのBAは役割です。

• AI実装設計者
• 業務アルゴリズム化責任者
• 自律化ガバナンス設計者

言い換えると：BAは「業務革命の立役者」そのものになります。

具体的には、AIエージェントの活用が進むことで、BAは以下のようなより高次元で戦略的な役割を果たすようになります。

AI活用の戦略的パートナー:

単にAIツールを導入するだけでなく、どの業務にAIを適用すべきか、AIがどのようにビジネス価値を生み出すかを戦略的に設計する役割を担います。

AIエージェントに「何を」「どう判断させ、どう行動させるか」を定義するための、業務の言語化・構造化能力がますます重要になります。

ビジネスとテクノロジーの架け橋（進化版）:

従来のシステム開発における橋渡し役を超え、最先端のAI技術をビジネス課題解決にどう応用するかを探求し、経営層や現場、IT部門との議論をリードします。AIエージェントの能力と限界を理解し、人間とAIが最も効果的に協働できるビジネスモデルやプロセスを設計します。

変革推進とチェンジマネジメントの専門家:

AIエージェントの導入は組織と業務プロセスに大きな変革をもたらします。BAは、この変革を推進し、従業員がAIと共存し、新しい働き方を受け入れられるよう支援する役割を強化します。

つまり、AIはBAの業務の一部を「代替」するのではなく、BAがより「人間力を必要とする、戦略的で創造的な業務」に集中できるよう「支援」し、その役割を高度化させる存在となると考えられます。BA自身も、AI技術を学び、使いこなすことで、その専門性と市場価値をさらに高めることができるでしょう。

]]> http://kbmanagement.biz/?feed=rss2&p=6723 0