前回同様に生成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 http://kbmanagement.biz/?p=6710 http://kbmanagement.biz/?p=6710#comments Tue, 17 Feb 2026 05:17:54 +0000 admin http://kbmanagement.biz/?p=6710 SaaSの死とは

2026年2月になってから、「SaaSの死」という物騒な話が話題になっています。「SaaSの死（SaaS is Dead）」という言葉は、従来の SaaS（Software-as-a-Service）モデル、すなわち

• 月額ライセンス
• 人間がログインして使うアプリケーション
•  ID × seat（人数）課金

というモデルが、AIエージェント（特にAnthropicの Cowork のようなツール）に置き換わる可能性があるとして投資家や市場で語られている現象です。具体的に言うと：

• AIエージェントがいくつものSaaSを「まとめて自動化」できる
• 複数のSaaSを横断して作業を完結できる
• UIを使って人間が操作することなく、AIがワークフローを完結する

このような変化が市場に衝撃を与えているのです。

https://note.com/snowflake_note/n/n0f3bf503fbd3?utm_source=chatgpt.com

報道によれば、

• Anthropic が業務AIエージェント Claude Cowork に、法務・財務・データ分析などを自動化するプラグインを多数追加した発表を行いました。
• これを受けて、SaaS銘柄やIT株が大規模に売られ、市場全体で数千億ドル規模の価値が蒸発したという報道が出ています（いわゆる「Anthropicショック」と言われています）。つまり、AIエージェントが複雑な業務を自動で処理するようになると、従来の個別SaaSに掛けられていた支出や株式評価が不要になる可能性があるという投資家の認識変化が引き金になっているだけ。

しかも「SaaSが完全に消滅する」と断言されているわけではありません。多くの専門家は、これは議論を喚起する**象徴的な表現（キャッチコピー/マーケットセンチメント）**であり、SaaSが役割を変える、統合/再定義されるという見方です。

たとえば、

• SaaSの伝統的な座席課金モデルは挑戦を受けるが
• SaaSとしてのアプリケーションや深い業界最適化はまだ価値がある

という見方があり、単純な「SaaS＝死」というわけではないのです。ですから、「SaaSの死」をあまり気にする必要はないかもしれません。

Coworkの他の業務への影響

しかし、CoworkなどのAIエージェントのインパクトはSaaSだけの話なのでしょうか。むしろそれ以外の影響の方が大きいのではないでしょうか。

SaaSはこれまで：

• UIに人間がログイン
• ワークフローを人が操作
• seat課金モデル

という前提でした。しかし Cowork 型AIは：

•  SaaSのUIを使わない
• APIや画面をエージェントが操作
•  複数SaaSを横断して処理

つまり、アプリケーション」という単位が意味を失い始めるということではないでしょうか。言い換えると、業務が標準化されていればCoworkはSaaSだけではなく、業務そのものを代替できるのではないでしょうか。

ですからCoworkの本当のインパクトは、

• 「SaaSの死」 → 単なる表層であって、本当のインパクトは：
• 「人間が操作する業務プロセス」の変革にあると思います。

なぜなら、Iエージェントが置き換えるのは

•  UI
•  画面操作
• 入力作業

ではなく

• 判断
• ルール適用
• データ横断処理
• 業務フロー制御

だからです。

標準化された業務と Cowork

では、業務が標準化されていればどうなるのでしょうか？

ここが重要で、標準化された業務とは次のことを意味します。

• 入力が定義されている
• 判断基準が明確
• 例外が整理されている
• データ構造が安定している

これは実質的に「業務がアルゴリズム化されている」という状態です。その場合、AIエージェントは：

• APIでデータ取得
• ルール適用
• 他システムへ連携
• レポート生成

を自律的に実行できます。つまりSaaSを置き換えるのではなく、「業務担当者」を置き換える可能性があるということです。特にAIが置き換えやすいのは次の場合です。

• 判断型プロセス
• データ主導業務
• ルールベース業務

すなわち、オペレーション層の多くは影響を大きく受けることになりそうです。ですから、「SaaSの死」より重要なのは、「業務の単位がアプリからエージェントに移る」という構造の変革です。

これが起きると次のことが起きるのではないでしょうか。

• ソフトウェア市場の再編（SaaSの死）
• 業務設計の再設計
• 組織構造の再編
• 職務定義の崩壊

つい半年位前にDevinやWindsurfによるSW開発専用のAIエージェントが話題になり、近い将来プログラマーが不要になる、そのためコンピュータサイエンス系の学生の就職難が話題になったばかりでした。

今度は特定の職務（プログラマー）にとらわれない、きわめて多くの業務がインパクトを受けることになりそうです。

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

事の本質は「業務の実行主体が人間からエージェントに移る」ことです。

これは業務の改善/改革のレベルではなく、まさに「業務の革命」と言うべきものです。

次回をお楽しみにしてください。

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

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

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

APQC PCFに関する詳細は以前のコラムを参照してください。

• DXにおける業務プロセス変革（1）
• DXにおける業務プロセス変革（2）
• DXにおける業務プロセス変革（3）

そこで、従来のAI（生成AI：タスクベース）とAIエージェントの違いをご覧ください。

表ように、「AI主導」と「AIエージェント主導」は似て非なるもので、自律性・文脈理解・他システムとの連携能力において決定的な差があります。

 AIエージェントは、PCFでいう「Level 4アクティビティ」単位の自動化を超え、Level 3プロセスの統合実行レベルにまで拡張します。

例「6.2.3　顧客苦情管理」プロセスでは

これは生成AIはレベル4のアクティビテイ単位で仕事をするのに比べて、AIエージェントはレベル3プロセス全体を自律的に実行してくれることを意味します。つまり、顧客対応業務が、**「指示型（AIにやらせる）」から「任せ型（AIが動く）」**に変わるのです。

PCF（左）→ AIエージェントによる自動化（中央）→ 人間の監督・承認（右）という流れを示しています。AIが生成・最適化を担い、人間が承認・モニタリングを行う協働モデルを表しています。

 PCF階層における拡張マッピング

まとめ：AIエージェント導入による業務の再構成

• AIの活動単位が「作業（Activity）」から「目的（Goal）」へ拡張しています
• PCF上では、Level 3をまたぐプロセス横断的な自律運用が可能になります
• 人間は「実行者」から「モニタ／オーナー」へ役割が転換します
• 業務標準化（PCF）＋知識化（BABOK/BIZBOK）＋データ構造化（BPMN/DMN）が統合に必須です

結論：業務のAI化の前段階としてAPQC PCFによる**業務の可視化・標準化**が不可欠です

ＢＡ不在の組織において、全社員のDXリテラシーを底上げさえすれば、ＤＸが実現できるのでしょうか。
ビジネスアナリシス（BA）機能が存在しない組織では、いくら全社員のDXリテラシーを底上げしても「真のDX」には到達できません。以下で、体系的にその理由と構造を整理します。

① 「DXリテラシー向上」と「DX実現」の間にある構造的ギャップ

 DXリテラシー向上が意味するものは、

社員一人ひとりが以下を理解し、ツールを活用できるようになる状態です：

• デジタル技術の基礎理解（データ・AI・クラウドなど）
• 業務のデジタル化・自動化スキル（ローコード/ノーコードなどによる）
• 現場レベルでの課題発見・改善提案能力

つまり、**「個人の理解・スキル向上」**までです。しかしDXの本質は、「組織として価値創出モデルを変革すること」ではないでしょうか、その「構造変革」を設計・推進する役割を担うのが**ビジネスアナリスト（BA）**となります。

② BAがいない組織で起きる典型的な“DXの壁”

→ 結果として、「DXの芽」は出ますがビジネス変革にまでは至りません。

③ 真のDXを実現するために必要な“BAの接続構造”

 3層構造モデル（DX成功組織の中核） を考えます。

この**中間層（BA）**が存在しないと、上層の「戦略」と下層の「実行」が乖離し、DXが“単なる改善活動の寄せ集め”に終わりそうです。いくら改善の数が多くても改革とは程遠いものです。

④ DXリテラシー教育だけでは変革が起きない理由

1. リテラシーは「理解」止まり、変革は「構造設計」から

•  社員教育は「デジタル理解」を高めますが、「業務・価値連鎖の再設計」はできません。
• BAはこの「理解」を「設計・実行」に変える変換装置です。 

2. ツール活用と価値創出の間をつなぐ存在

• 現場がAIやローコードを使えても、「それが企業価値にどう寄与するか」を測る設計者が必要。
• それがBAの役割。

3. 合意形成とトレーサビリティの中心

• DXは組織横断的。BAがいないと利害調整や要件統合が進まず、プロジェクトは分断されてしまいます。

⑤ DXリテラシーとBA内製化の「補完関係」

結論：DXリテラシーは必要条件、BA内製化は十分条件。

DXを「組織の成果」に変えるには、BAという“変革設計者”が不可欠。

⑥ 提案：DXリテラシー＋BA内製化の統合モデル（全社導入例）

いかがでしょうかビジネスアナリシス（BA）不在の組織では、いくら全社員のDXリテラシーを底上げしても「真のDX」には到達できないことが明確になったと思います。

 ①DXリテラシー向上の必要性

1. DXは一部門の業務改革ではなく、全社文化の変革

• DX（Digital Transformation）は単なるIT導入ではなく、「デジタルを活用してビジネスモデル・業務・組織文化を変革する」ことです。
• そのためには、経営層から現場までが共通の“DX言語”を理解し、同じ方向を向いて変革に参加できる状態が不可欠です。

2. 全社員がデジタルを「使う側」から「活かす側」へ

ツール操作の習熟ではなく、デジタルを使って価値を創出する視点が必要です。
具体的には：

• 「なぜこのデータを集めるのか」
• 「どんな意思決定を支援するのか」
• 「どうすれば顧客価値を最大化できるのか」
• といった“ビジネス視点のデジタル理解”が求められます。

3. BA内製化の前提条件としての「共通理解基盤」

• BAが業務変革をリードするには、現場がデータ・プロセス・KPIの概念を理解している必要があります。
• DXリテラシーの底上げは、BAとの連携をスムーズにし、全社一体での変革推進力を生みます。

②DXリテラシー向上の実現計画（全社展開モデル）

1.ステップ別ロードマップ

全社展開するためには次の様なロードマップが有効です。5つのフェーズにまとめてみました。

2.役割分担イメージ

続いて各役割毎の分担を考えます。経営層、人事/教育部門、部門リーダー、IT部門/BA、一般社員の各役割です。

3.施策の具体例

具体的な施策です。単なる教育・研修だけでなく、リテラシー向上のための体験と仕組みが重要です。そして動機付けを強化するために、人事評価にDXスキル指標を加えることを忘れてはいけません。

③ 成果モデル（BA内製化との連動）

まとめ：全社員DXリテラシー向上 × BA内製化 = 「変革自走型組織」

ビジネスアナリスト（BA）を外部委託ではなく内製化（社内育成・配置）することには、企業の変革力やDX推進力を高める大きな戦略的意義があります。そのメリット、内製化のステップ（手順）、そして成功のポイントを説明します。

 ビジネスアナリスト内製化のメリット

1. 事業戦略とIT施策の一貫性向上

• 外部ベンダーBAは一時的なプロジェクト志向になりがちですが、内製BAは企業の戦略・文化・業務構造を理解したうえで継続的に橋渡しできます。
• → 結果：戦略意図が確実に要件へ翻訳され、プロジェクト成果が経営成果へ直結。 

2. 業務知識とデータ資産の蓄積

• BAが社内に常駐することで、業務モデル・課題・改善施策・成功失敗の知見がナレッジ化されます。
• → ベンダーに依存しない「業務アーキテクチャの資産化」が可能。 

3. DX推進のスピードと柔軟性の向上

• DXの初期段階ではPoCやアジャイル開発が多く、スピーディな要件整理と意思決定支援が求められます。
• 内製BAがいれば、現場と経営の間で即時に分析・合意形成を行え、外部調整の時間ロスを削減。

4. コスト最適化と外部委託リスク低減

• ベンダーBAは高コストなうえに契約期間で離脱しますが、内製BAは継続的スキル成長＋組織学習を実現し、長期的にはROIが高くなります。 

5. 組織変革力（Change Enablement）の内在化

• BAは「変革の媒介者（enabler）」です。内製化により、変革を外部任せにせず、自社のDNAとして定着させることが可能になります。

 内製化の手順（ステップ）

成功のためのポイント

1. 経営層の支援と位置づけの明確化

• BAは「戦略×業務×IT」を橋渡しする職能であり、単なる“要件定義担当”ではない。経営層が明確に支援することが前提。

2. 「プロセス標準化」＋「ナレッジ共有」基盤の整備

• 　APQCのPCF（Process Classification Framework）などを活用し、共通言語・標準テンプレートを整備することでBA業務の品質を均質化。

3. アジャイル開発・DXプロジェクトとの接続

• BAが単独で動くのではなく、プロダクトオーナー・PM・データ分析チームと連携するハイブリッド体制を構築。

4. AI／ツール活用による効率化

• ChatGPTなどの生成AIや、要件管理ツール（JIRA、Confluence、Enterprise Architectなど）を組み合わせ、分析・文書化の生産性を高める。

まとめ（外部委託BAと内製BAとの比較）

SWエンジニアのキャリアパスとしてのビジネスアナリスト

1. 背景と問題認識

（1）生成AI・AIエージェントによる構造変化

• 「AIコーディング支援（Copilot, Devin, Windsurfなど）」の進化により、コード生成・単体テスト・デバッグ・ドキュメント生成が自動化されます。そして、
• エンジニアの生産性は劇的に上がる一方で、「指示されたものを作る人材」の価値は相対的に低下します。その結果
• 企業は「何を作るか（What）」を定義できる人材＝「ビジネスアナリスト（BA）」の重要性を再認識するようになりました。

（2）SWエンジニアに迫るDisruption

 2. キャリアパス転換の方向性：SWエンジニア → ビジネスアナリスト

（1）BAが有望な理由は次のとおりです。

1. まず、ビジネスアナリシスは生成AIに置き換えられにくい活動領域と言えます。
   －問題の定義・価値の可視化・ステークホルダー調整など、非定型・意味的作業がメインだからです。
2. DX・AI導入の上流工程で需要の拡大が見込まれます。
   －ビジネス部門と技術部門の橋渡し役として、全産業でBAのニーズが増加しています。
3. SWエンジニアとBAでは各々のスキルの相互補完性が強いです。
   －エンジニアの論理思考とシステム理解は、BAの「分析力・モデリング力」に直結します。

（2）SWエンジニアからBAへのスキル変換の対応です

その結果、SWエンジニアからビジネスアナリストへ意外とスムーズにのキャリア変換されることが予想されます。

3. 育成手順（ロードマップ）

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

4. 教育プログラム例（KBマネジメント想定） 

5. 成功要因と推進施策

6. 今後の方向性

• AIエージェント×BA連携モデル：要件定義・分析・文書化を自動化する次世代BA支援。
• BA職種の再定義：「Human-in-the-loop」型AI共創職。
• SWエンジニアの再評価軸：
• “Coder” → “Analyzer” → “Business Designer”。