前回の問いの続き
前回のInsight「『通じない』が変革を止める」では、SaaSの安易な導入がもたらす泥沼と、ビジネス部門とシステム部門の間に走る構造的な断絶について論じた。ビジネス部門は「解決手段」で語り、システム部門は「仕様」で受け取る。バリューチェーン全体の視点が抜け落ちたまま導入が決まり、使われないシステムが量産される。
あの記事で残した問いがある。この断絶を、個人の努力ではなく組織の構造として埋めるには、何が必要なのか。
答えは明快だ。ビジネスとITの間に立ち、双方の言語を翻訳し、「本当に解くべき課題は何か」を定義する専門的な役割 ── それが組織に存在しない。存在しないから、断絶が埋まらない。
欧米にあって日本にないもの
欧米では、この役割に明確な名前がある。ビジネスアナリスト（BA）だ。
国際的な専門団体IIBAが策定したビジネスアナリシスの知識体系「BABOK」は、ビジネスアナリシスを「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズにおけるチェンジを可能にする専門活動」と定義している (IIBA, 2015)。
この定義の中に、すでに本質がある。ビジネスアナリストの仕事は「システムを作ること」ではない。「何を解くべきかを定義し、最適な解き方を推奨すること」だ。その解き方がシステム開発の場合もあれば、業務プロセスの見直しの場合も、運用ルールの変更の場合もある。手段を選ぶ前に、課題を正しく定義する。まさに前回のInsightで「あの時すべきだった」と述べたことの担い手が、ビジネスアナリストなのだ。
欧米では2000年前後からこの職種が企業内に定着しており、LinkedInの調査でもビジネスアナリシスは需要の高いスキルとして上位にランクインしている。一方、日本ではどうか。この役割を担う専門職が、組織図の中に存在しないことがほとんどだ。
日本企業では、ビジネスアナリストが本来果たすべき機能が、上流SE、プロジェクトマネージャー、コンサルタント、あるいは「詳しい人」に断片的に分散している。誰かが片手間にやっている。あるいは、誰もやっていない。この「不在」が、ビジネス部門とシステム部門の乖離を構造的に放置している最大の原因だ。
日本で「橋渡し役」が育たない3つの理由
理由① ── 「作る/使う」の二項対立が根深い
日本のIT推進は、長年「作る人（システム部門・ベンダー）」と「使う人（ビジネス部門）」という二項対立の構造で進んできた。この構造の中には、「何を作るべきかを定義する人」の居場所がない。
ビジネス部門は「こういうものがほしい」と要望を出す。システム部門は「それをどう作るか」を考える。この間に入って「本当にそれを作るべきですか。この課題の本質は別のところにありませんか」と問い返す役割は、どちらの部門のミッションにも含まれていない。結果として、この「間」は誰のものでもない空白地帯になる。
理由② ── ベンダー依存が「問い」を外部化してきた
DXレポート2.1が指摘したユーザー企業とベンダー企業の「低位安定」(経済産業省, 2021) は、課題定義の力を企業の外に流出させてきた。ベンダーやコンサルタントが課題を定義し、ソリューションを提案し、システムを作る。ユーザー企業は「発注者」として受け取る。この関係が長年続いた結果、「自社の課題を自社で定義する力」そのものが組織から失われている。
ビジネスアナリストは本来、組織の内部にいるべき存在だ。自社のビジネスモデル、バリューチェーン、データの流れ、現場の実態を日常的に理解しているからこそ、外部からの提案 ── SaaSベンダーの華やかなデモを含めて ── に対して「本当にそれが最適か」を問い返せる。この機能を外部に委ね続けてきたことが、前回のInsightで述べた「ビジネス部門がベンダーの提案をそのまま採用してしまう」構造を生んでいる。
理由③ ── 「ビジネスもITもわかる」の育成パスがない
ビジネスアナリストに求められるのは、ビジネスの文脈を理解し、技術の可能性と制約を把握し、双方の言葉で対話できる能力だ。しかし、日本企業の人材育成は縦割りだ。ビジネス部門の人材はビジネススキルを磨き、システム部門の人材は技術スキルを深める。両方の領域を横断する育成パスが設計されていない。
経済産業省とIPAが策定した「DX推進スキル標準」(2022年策定、2024年改訂) は、DXを推進する重要な人材として「ビジネスアーキテクト」を定義している。これはまさにビジネスアナリスト的な役割を日本の文脈で再定義したものだ。しかし、名前を定義することと、その人材が組織の中に実際に存在することの間には、大きな溝がある。IPAの「DX動向2025」が示す「85.1%の日本企業がDX人材不足」(IPA, 2025) という数字は、この溝の深さを物語っている。
ビジネスアナリストが組織にいたら、何が変わるか
前回のInsightで描いた場面を、ビジネスアナリストがいる場合で書き直してみよう。
SaaSベンダーからの提案をビジネス部門の部長が受ける。部長は社内のビジネスアナリストに連携する。ビジネスアナリストは、まずビジネス部門の課題を構造的に整理する。表面的な「この業務が不便」の裏にある業務フロー全体を可視化し、課題の本質を特定する。
次に、バリューチェーン全体への影響を評価する。この部門でSaaSを導入した場合、前後の工程のデータの流れはどうなるか。既存システムとの整合性は。他部門への波及は。ビジネスアナリストはシステム部門と対話し、技術的な制約と可能性を確認する。
その上で、選択肢を提示する。「この課題は業務プロセスの見直しで7割解決できる。残り3割はSaaSの一部機能で対応可能。全面導入は不要」。あるいは「SaaS導入は妥当だが、まず営業部門の受注管理に絞って導入し、成果を確認してから他部門に展開すべき」。
これが、ビジネスアナリシスの本質だ。手段を決める前に、課題を定義する。全体を見てから、部分を決める。
BABOKが掲げる6つの知識エリアの最初が「ビジネスアナリシスの計画とモニタリング」であり、「要求のライフサイクルマネジメント」が中核に位置するのは、まさにこの順序 ── 課題定義が先、手段選択が後 ── を体系化したものだ (IIBA, 2015)。
「専門職」でなくても始められる
ここで現実的な問いに向き合う必要がある。「ビジネスアナリストを採用しましょう」と言うのは簡単だが、日本の労働市場でBA人材を外部から調達するのは極めて難しい。 では、どうするか。
まず「機能」を置く、肩書きは後でいい
ビジネスアナリストという専門職を一朝一夕に組織に作ることは難しい。しかし、ビジネスアナリシスという「機能」を意思決定プロセスに組み込むことは、明日からでもできる。
具体的には、SaaSを含むIT投資の意思決定の前に、「課題定義レビュー」のステップを設ける。このレビューでは、ビジネス部門が抱える課題の本質は何か、その課題を解く手段としてシステム化は最適か、バリューチェーン全体への影響はどうか、を検討する。この機能を担うのは、専任のビジネスアナリストでなくてもいい。ビジネス部門とシステム部門から1名ずつ、「橋渡し」の意志を持つ人材を選び、共同でレビューを行う。
「問いを立てる筋力」を育てる
ビジネスアナリシスの最も重要なスキルは、高度な技術知識でもフレームワークの暗記でもない。「それは本当に解くべき課題ですか」と問い返す力だ。
これは研修で一朝一夕に身につくものではないが、実践の中で鍛えることはできる。プロジェクトのキックオフで「この施策が解決する課題は何か」を必ず言語化する。ベンダーの提案を受けたら「この提案が前提としている課題定義は正しいか」を確認する。要件定義の冒頭で「要件を定義する前に、この要件が解くべき課題を定義しよう」と提案する。
こうした小さな実践の積み重ねが、組織全体の「問いを立てる筋力」を育てる。BABOKが体系化しているのは、まさにこの「問いの立て方」のベストプラクティスだ。
外部の伴走者を活用する
自社内での育成には時間がかかる。その間、外部のビジネスアナリシスの知見を持つパートナーに伴走してもらいながら、徐々に内製化するというアプローチも有効だ。
ただし、ここで注意すべきは、外部パートナーに「課題定義の丸投げ」をしないことだ。それでは、ベンダー依存の構造を別の形で再現するだけになる。外部パートナーは「魚をくれる人」ではなく「釣り方を教えてくれる人」でなければならない。伴走しながら社内人材にビジネスアナリシスの考え方を移転し、最終的には自社の力で課題を定義し、意思決定できる組織を作る。これが、持続的な変革能力の構築だ。
経営層への問い ── この役割に投資する覚悟はあるか
ビジネスアナリストの不在は、日常的には「困っている」と認識されにくい。プロジェクトが遅延しても「要件が複雑だったから」で説明される。SaaSが使われなくても「現場の理解が足りなかったから」で片づけられる。不在がもたらす損失は、見えにくい。だからこそ放置されてきた。
しかし、その見えない損失は積み上がっている。使われないシステムのライセンス料。手戻りによる開発コストの増大。二重入力が生む工数。データ不整合がもたらす意思決定の遅延。ビジネス部門とシステム部門の相互不信。これらを合算すれば、ビジネスアナリスト一人の人件費を大幅に上回るはずだ。
経営層に問いたい。「課題を正しく定義する」という仕事に、組織として投資する覚悟はあるか。 ビジネスアナリストという名前でなくてもいい。「橋渡し」の機能を組織に埋め込み、育て、守る意志があるか。この問いへの答えが、DXの成否を静かに、しかし決定的に分ける。
まとめ ── 橋は、人が架ける
ビジネスとITの間の断絶は、ツールでは埋まらない。プロセスだけでも埋まらない。その間に立ち、双方の言語で対話し、課題を定義し、選択肢を提示する「人」がいて、初めて橋が架かる。
欧米ではビジネスアナリストとして確立されたこの役割を、日本企業はこれまで「誰かが片手間にやるもの」として扱ってきた。その結果が、SaaSの泥沼であり、DXの停滞であり、ビジネス部門とシステム部門の終わりなき摩擦だ。
テクノロジーだけでは、組織は変わらない。変革の起点は、正しい課題定義にある。そして正しい課題定義は、ビジネスの文脈と技術の文脈の両方を理解する人がいて初めて可能になる。橋は、人が架ける。その人を組織にどう位置づけ、育て、活かすか ── それ自体が、最も重要な組織変革の課題なのかもしれない。