日本の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を考えている風潮について考察していきます。当初は予定していなかったのですが、意外と日本市場でも脚光を浴びているようなので気になっています。

最近発行された「ビジネスアナリシス標準」では、マインドセットが大幅に強化されましたのでご紹介します。

マインドセットとは

• 「マインドセット」とは、人がさまざまな状況にもたらす確立された一連の態度や習慣。

マインドセットがなぜ重要なのか？

• すべての状況は独自（ユニーク）であり、決まりきったビジネスアナリシスのアプローチといったものはありませんので、そのコンテキストに応じて、タスク、テクニック、ツールを様々な組み合わせで活用する必要があります。
• 特に最近は変化の激しいVUCAの時代なので、変化に惑わされずに、自信を持ってアプローチするには、習慣、態度、行動、実践において、正しいマインドセットをもつ必要があるわけです。

ビジネスアナリシス・マインドセットの源泉は次の2つです。

• ビジネスアナリシスの6つのコア・コンセプト
• 人々が持つ共通の価値観

まず、6つのビジネスアナリシスのコア・コンセプトがあります。BABOKの最重要な概念です。

• ニーズ
• チェンジ
• 価値
• ソリューション
• ステークホルダー
• コンテキスト

このコア・コンセプト・モデルについては下記URLのITmediaエグゼクティブのコラムで紹介していますので、そちらをご覧ください。

https://mag.executive.itmedia.co.jp/executive/articles/2404/16/news026.html

 共通の価値観は次のとおりです。

•  敬意（人を信頼し尊重する）
•  勇気（変革への勇気）
•  コラボレーション
•  継続的な学習と改善
•  顧客重視
•  価値の最大化

上記共通の価値観ですが、アジャイル分野では常識のものではないでしょうか。そうです、このマインとセットはビジネスアナリシスのコア・コンセプトとアジャイルでの価値観を組み合わせたものと考えられます。

このマインドセットを開発するために、次のことに焦点を当てたビジネスアナリシスの活動をすることが奨励されています。

• 価値：　まずはビジネスアナリシスにより生み出される価値を考えましょう。
• 成果：　そして、生み出される成果をどのように考えるか
• ビジネスアナリシス原則：　（後述しますので少しお待ちください）
• ビジネスアナリシス・タスクへの取り組み方
• 基礎コンピテンシーの積極的な開発
  →　特に「倫理」「信頼感」「リーダーシップ」「チームワークと影響力」、「共感」、「システム思考」、「ファシリテーション」などです。
• いくつかの基本的なテクニック（特に引き出しのテクニック）を使用しましょう。そしてステークホルダー・エンゲージメントを得ることが重要です。

上記を実行することにより、ビジネスアナリストは次の能力が身に付きます。

• 価値提供に優先順位を付ける（価値と成果、「優先順位を付ける」タスクが有効です）
• 影響を受けるステークホルダーに共感する（基礎コンピテンシー「共感」を使いましょう）
• チェンジを起こすために仲間を作り協働する（ステークホルダー・エンゲージメントを高めます）
• コンテキストを評価し、現実に適応する（ビジネスアナリシス・コア・コンセプト）
• 常にステークホルダーから学ぶ（ステークホルダー・エンゲージメントが有効です）
• 知識の構築と共有を簡素化する
• フィードバックを反映して適応する
• 質の高い成果を生み出すよう努める（上記「成果」そのもの）
• 測定可能な価値を迅速に提供する

柔軟で順応性のあるマインドセットにより、次の様な活動が可能になります。

• 戦略に影響を与える
• 真の顧客に共感すること
• ビジネスプロセスを変革すること
• ビジネス・エコシステム内のステークホルダーに真剣に取り組んでもらうこと（エンゲージメント）
• 事実に基づくフィードバックと学習の推進
• 必要なチェンジを実装し、支援するためにテクノロジーを活用すること（DXにつながります）

 ビジネスアナリシスの原則

次の原則は、効果的なマインドセットのために重要です。

• 全体を見る
• 顧客として考える
• 価値あるものは何かを決めるために分析する
• 例を使って真実を得る
• 実行可能なものは何かを理解する
• コラボレーションと継続的改善を促進する

もとはBABOKのアジャイル拡張版に記載されていたものですが、アジャイルのみならずビジネスアナリシス全般における原則に昇格しました。以下に解説です。

全体を見る

• – 全体像のコンテキストでニーズを分析し、チェンジが必要な理由を特定する。
• – 望ましい成果は、コンテキスト、ソリューション、およびステークホルダーを理解することによって生み出される。

顧客として考える

• 顧客体験上のニーズを理解して、そのニーズに対応するソリューションを構築する。
• チームは、顧客ニーズの概要把握から始め、それを分解して詳細な理解を得て、新たなソリューションを進化させるのに利用する。

自分が顧客だったら何が欲しいだろうかと、自問自答しましょう。

価値あるものは何かを決めるために分析する

• 提供される価値を最大化するために、作業を継続的に評価し、優先順位を付ける。
• チェンジにおける価値は、コンテキスト、ニーズ、ステークホルダー、ソリューションの可能性を理解することで生まれる。

例を使って真実を得る

• 実例を評価することは、ニーズと、ソリューションがそのニーズをどのように満たすかについて共通の理解を構築するために重要となる。
• 例を使用して、受け入れ基準を導き出し、ソリューションのデザインを支援し、ソリューションをテストするための基盤を提供することもできる。

具体的なものを見たり聞いたりすると、自分が欲しかったものが分かりますね。「あっ、これが欲しかった」。

実行可能なものは何かを理解する

• ニーズと、優先順位付けされたニーズを満たせるソリューションを継続的に分析することにより制約条件の下でソリューションを提供する方法を理解する。
• また、ソリューションが意図した価値を確実に提供するために、運用環境内での制約条件を考慮する必要がある。

実行可能ですからチェンジ可能なものが分かります。使い物になっているかどうかは重要です。

コラボレーションと継続的改善を促進する

• すべてのステークホルダーが継続的に価値に貢献する環境の構築を支援する。
• 継続的なフィードバックを使用して、提供価値を高めるソリューション自体と、開発プロセスを適応させる。

ムダを省く

• 付加価値のある活動とそうでない活動を特定する。
• ニーズを満たすことに貢献しない活動を排除する。

マインドセットの効用としてUNLOCK

DXを実現する際に大きな障壁となるのが、従来の常識や制約にとらわれた、いわゆるLOCKされた心理的状況です。これを打破するためにはこの心理的状況を解放（UNLOCK）する必要があります。ビジネスアナリストがLOCKされた状況ではDXを実現することは難しいでしょう。まずビジネスアナリストがUNLOCKされる必要があります。

上記の価値観やマインドセットがUNLOCKに大きく貢献するのではないでしょうか。

　　Lockされた状況　　　　　　　　　　　　　        　UNLOCKする価値観やマインドセット

• 目的を考えるのは自分の仕事ではない　　　　　　　　戦略に影響を与える
• 組織では上司の意見に従うべき　　　　　　　　　　　勇気
• 予算がかかるものはやれない　　　　　　　　　　　　勇気
• 残業しないわけには行けない　　　　　　　　　　　　勇気
• 効率化しても残業代が減るからやりたくない　　　　　勇気
• 改善しても問題が出ると嫌だから提案しない　　　　　価値の最大化
• 言われたことをきちんとやることが自分の仕事　　　　真の顧客への共感
• 他の部門との調整が必要なことはしない　　　　　　   コラボレーション
• これはシステム会社の仕事ではなく事業会社                    必要なチェンジを実装し、支援するためのテクノロジーの活用
  （親会社）のやること　　

マインドセットをしっかり持つことの重要性を認識しましょう。

世の中DX流行の真最中ですね。毎日のようにDXに関する、製品紹介、セミナー、事例紹介の案内が届いています。

DXをITと置き換えても何も違和感のないものばかりです。DXとはITを言い換えたに過ぎないと思えるぐらいです。特にクラウド、AI、IoT、AWSなどを活用することがDXであるかの如くですね。

そのような風潮の中ですが、デジタルトランスフォーメーションを実行するためにはビジネスアナリシスが不可欠なことは言うまでもないところですが、まだ一般にはそれが周知されていないのも事実のようです。そこで、このメルマガのブログにおいて少し具体的にビジネスアナリシスがどのようにDX実現に貢献できるのかについて解説していきたいと思います。

概ね10回程度の連載になる予定です。（改訂版：2021/2/3）

1. 　デジタルトランスフォーメーションとは何か
2. 　顧客経験の変革
3. 　戦略アナリシスとエンタープライズ・アーキテクチャ
4. 　ビジネスモデル・キャンバス（現状）
5. 　ビジネスモデル・キャンバス（将来像）
6. 　将来像のEA
7. 　DX後に必要な商品・サービス
8. 　EAモデルの詳細化
9. 　DX実行戦略
10. 　まとめ

DXの定義

第1回の今週はまず、冒頭のタイトルの「デジタルトランスフォーメーションとは何か」について考えます。

2018年に経産省から「2025年の崖」が発表されてから、DXに火が付いたような気がします。その中ではIDC（有名なコンサルティング会社）の次の定義が引用されています。

• “企業が外部エコシステム（顧客、市場）の破壊的な変化に対応しつつ、内部エコシステム（組織、文化、従業員）の変革を牽引しながら、第３のプラットフォーム（クラウド、モビリティ、ビッグデータ／アナリティクス、ソーシャル技術）を利用して、新しい製品やサービス、新しいビジネス・モデルを通して、ネットとリアルの両面での顧客エクスペリエンスの変革を図ることで価値を創出し、競争上の優位性を確立すること”

さらに翌年2019年7月の経産省の「DX推進指標とそのガイダンス」では

•  「企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立する」

となっています。

そうです、重要なことは

• 「．．業務そのものや、組織、プロセス、企業文化・風土を変革」することです。

しかしその前提としてさらに重要なことはIDCの定義にはありますが

• 「．．顧客エクスペリエンスの変革を図ることで価値を創出」することです。この部分が何故DXを行うべきなのか（WHY）に対する回答になります。これを抜かすと単に自己満足的なDXがはびこってしまいますので注意が必要です。

このブログでのDXを次のように定義します。

• 「デジタルを前提にして、エンタープライズのビジネスモデル（例：BMキャンバス）全体を変革し、かつ顧客経験（CX）も画期的に変革し、社会に大きく貢献すること。」

いくらビジネスモデルやプロセスを変革してコストダウンで競合優位なったとしても顧客に価値を提供できなければDXとは言えません。ここではDXの目的を顧客経験の変革としました。決して競争優位という内部的な目標（提供側の都合）ではありません。あくまでも外部の顧客経験が重要で、その結果として競争優位になりうるのです。既存企業ですから永続性（サステナブル・グロース）が重要で、その基本は顧客中心です。

ちなみに、企業といわずエンタープライズとしています。ビジネスアナリシス的には単に民間企業にとどまらず、もう少し広い意味合いでとらえています。例えば政府機関も立派なエンタープライズです。最重要なステークホルダーは国民です。

 DXの進化過程

もう一つ別の観点で見てみましょう。やはり何事も進化過程を無視するわけにはいきません。DXも同様です。いきなりデジタルトランスフォーメーションといっても物事はなかなか進みません。DXを実現するためにはデジタイゼーション、デジタライゼーション、デジタルトランスフォーメーションと段階を追って進化していくしかないのも事実ではないでしょうか。その進化の過程を見ておくことも重要です。既存ビジネスとしてアナログ主体の業界の場合はデジタイゼーション～デジタライゼーションとそしてDXと時間がかかると思います（むしろかけるべきです）。デジタル化する部分とデジタル化できない（してはいけない）部分（それこそが競争優位なコア・コンピタンス）をしっかり見極めることも重要です。

ここではデジタルの進化過程を次の5段階で表してみます。

レベル０：

アナログなビジネス

レベル１：

商品（製品・サービス）がデジタル化された状態（例：ラジカセからCDプレイヤー：プロダクトイノベーション）

レベル２：

プロセスがデジタル化されている（デジタライゼーション、もしくはプロセスイノベーション）

レベル３：

企業内の組織・文化が変革し、プロセスも変革し、顧客経験も変革し価値を提供している。いわゆるDXが実現している状態。（ビジネスモデル・イノベーション）

レベル４：

一企業にとどまらず業界全体がトランスフォーメーションし、劇的な顧客経験の変革を提供している（業界イノベーション）

レベル５：

複数の業界が連携して変革し、社会全体にイノベーションが行き届いている（社会イノベーション）

尚、レベル１とレベル２はどちらが先とも言い切れません。業態によってプロセスのデジタル化の方が早いことも多いようです。プロダクト（やサービス）そのものはデジタル化しようがないものもあります。例：一次産業やエアーラインなど）

しかし農業を例にとってみると、IoTを活用して季節・天気に応じた肥料・配水などデジタルを活用して作物の生育を最適化するプロセスを実現し質の良い作物を実現することもできますし、流通過程では温度・湿度まで管理するサプライチェーンのプロセスが利用できます。

ベンチャー企業ではレベル１、レベル２はすでに到達していることも多いと思います。

ここでは、レベル３以上のものをデジタルトランスフォーメーションとして扱うことにします。レベル５はいわゆるSociety5.0を意識したものになります。

第１回はこの辺までとします。DXの議論の初めにはその言葉の定義からスタートしました。