「育てましょう」の先にある現実
前回のInsight「なぜ日本企業には『橋渡し役』がいないのか」では、ビジネスとITの間に立つビジネスアナリスト（BA）の不在が、SaaSの泥沼やDXの停滞を構造的に生んでいることを論じた。結論は明快だった。この役割を組織に埋め込まなければ、断絶は埋まらない。
しかし、「ではBA人材を育てましょう」と言ったところで、翌月から橋渡し役が機能し始めるわけではない。BABOKを読ませて研修を受けさせれば完成する類の人材ではない。ビジネスの文脈を理解し、技術の制約と可能性を把握し、双方の言語で対話し、「本当に解くべき課題は何か」を問い返せる力。この力は、座学では身につかない。
では、どうやって育てるのか。本稿では、理想論ではなく、日本企業の現実的な制約の中で、橋渡し役をどう育てるかを掘り下げる。
前提 ── 「完成品」を求めない
最初に、育成の前提を整理する。
ビジネスアナリストの理想像は高い。BABOKが定義するコンピテンシーは、分析的思考、コミュニケーション、交渉、ファシリテーション、ビジネス知識、IT知識と多岐にわたる。この全てを高いレベルで備えた人材が労働市場にいるなら、採用すればいい。しかし前回述べた通り、日本ではこの職種自体が確立されていない。外部からの調達は現実的ではない。
だからこそ、「完成品」を最初から求めてはいけない。必要なのは、組織の中にすでにいる人材が、段階的に橋渡しの力を身につけていくための設計だ。100点のBAを一人作ることではなく、60点の橋渡し力を持つ人材を複数育てることの方が、組織全体への効果は大きい。
誰を育てるか ── 候補者の見極め
「両方に足を踏み入れたことがある人」を探す
BA候補に最も適しているのは、すでにビジネスとITの両方の世界に何らかの接点を持っている人材だ。たとえば、ビジネス部門でシステム導入プロジェクトのユーザー側リーダーを経験した人。システム部門で要件定義のためにビジネス部門に深く入り込んだ経験のある人。事業企画部門でデータ分析に基づく提案をした経験のある人。
重要なのは、専門性の深さではなく、「相手の世界に踏み込もうとした経験」があるかどうかだ。ビジネス部門にいながら「システムの制約を理解しようとした」人。システム部門にいながら「なぜこの業務がこうなっているのか」を知ろうとした人。この「越境の意志」こそが、BA人材の最も重要な素養になる。
避けるべき選び方
逆に、避けるべき選び方もある。「ITに詳しいから」「ビジネスに強いから」という片方の専門性だけで選ばないことだ。ITに極めて詳しいがビジネスの文脈に興味がない人材は、技術の言語でしか語れない。ビジネス感覚に優れていてもITを「誰かに任せるもの」としか捉えていない人材は、問いを立てる相手がわからない。
また、「調整が上手い人」を選びがちだが、これも注意が必要だ。BAに求められるのは利害の調整ではなく、課題の再定義だ。ステークホルダー間の「落としどころ」を探る調整型の人材と、「そもそもこの課題設定は正しいですか」と問い返せる人材は、似ているようで本質的に異なる。
何を育てるか ── 3つの筋力
BA人材の育成を、知識の詰め込みではなく「3つの筋力」を鍛えるプログラムとして設計する。
筋力① ── 課題を構造化する力
ビジネス部門が「この業務をシステム化したい」と言うとき、その裏にある業務フロー全体を可視化し、課題の本質を特定する力。表面的な「不便」の裏にある構造的な問題を見抜く力。
これは座学だけでは身につかない。実際のプロジェクトの中で、業務フローを一から書き起こす経験が最も効果的だ。BABOKが示すテクニック ── プロセスモデリング、ルート原因分析、ステークホルダーマップ ── は、ツールとして有用だ (IIBA, 2015)。しかしツールの使い方を学ぶことと、現場でそのツールを使って課題を構造化する経験を積むことの間には、大きな差がある。
育成のポイント: 次のプロジェクトで、BA候補者に「この施策が解決しようとしている課題を、A3一枚で構造化してください」という宿題を出す。正解を求めるのではない。課題を構造的に捉えようとする思考の訓練が目的だ。
筋力② ── 「それは本当か」と問い返す力
ベンダーの提案に対して「本当にこのソリューションが最適か」、ビジネス部門の要望に対して「本当にそれが解くべき課題か」、システム部門の制約に対して「本当にその制約は動かせないのか」。あらゆる前提を疑い、問い返す力だ。
これは最も育てにくく、最も重要な筋力だ。日本の組織文化では、上位者やスポンサーの意見に疑問を呈することはリスクを伴う。だからこそ、「問い返す」ことが推奨される環境を意図的に作る必要がある。
育成のポイント: プロジェクトのレビュー会で「この施策の前提を3つ挙げ、その前提が崩れた場合どうなるかを検討する」というアジェンダを定例化する。問い返すことを個人の勇気ではなくプロセスの一部にすることで、心理的安全性を担保する。
筋力③ ── 双方の言葉で翻訳する力
ビジネス部門には技術の制約を「業務への影響」として伝え、システム部門にはビジネスの要望を「技術的な要件」として伝える。同じ事象を、相手の文脈に合わせて再構成する力だ。
BABOKが定義する「要求」のライフサイクル ── 引き出し、分析、仕様化、妥当性確認 ── は、この翻訳プロセスを体系化したものだ (IIBA, 2015)。ビジネスの言葉で語られたニーズを引き出し、構造的に分析し、双方が合意できる仕様に変換し、その仕様がビジネスニーズを本当に満たすかを確認する。
育成のポイント: BA候補者に「同じ内容を、ビジネス部門向けとシステム部門向けに、それぞれ別の説明資料として作成する」という課題を出す。何を残し、何を変え、何を補足するか。この作業自体が、翻訳力の訓練になる。
どう育てるか ── 実務の中で鍛える仕組み
OJTのデザイン ── 「見習い」から始める
最も効果的な育成は、実際のプロジェクトの中で、BA的な役割を段階的に担わせることだ。いきなり「課題を定義してください」と任せるのではなく、まずは経験者の横で「見習い」として同席し、課題定義のプロセスを観察する段階から始める。
段階的なステップの例を示す。
ステップ1 ── 観察する。 要件定義の会議に同席し、ビジネス部門とシステム部門のやり取りを記録する。「どこですれ違いが起きたか」「どんな問いが会話を前に進めたか」を振り返る。
ステップ2 ── 補助する。 議事録の作成や論点整理を担当する。ただし、単なる記録ではなく「この会議で合意されたこと」「未解決の論点」「確認が必要な前提」を構造化して整理する。
ステップ3 ── 一部を担う。 小規模なテーマ（たとえば一つの業務プロセスの改善）について、課題定義からソリューション提案までを自分で担当する。経験者がメンターとして伴走し、随時フィードバックを返す。
ステップ4 ── 主導する。 プロジェクト全体の課題定義レビューをリードする立場を任せる。ビジネス部門とシステム部門の双方に対して、問いを立て、選択肢を提示し、合意を形成する。
このステップを1～2年かけて段階的に踏むことで、座学では得られない実戦的な橋渡し力が育つ。
越境経験の設計
BA人材の育成に最も効くのは、自分が所属していない世界を体験する機会を意図的に設計することだ。
システム部門のBA候補者を、3か月間ビジネス部門のプロジェクトに参加させる。ビジネス部門のBA候補者を、システム部門のスプリントレビューに定期的に参加させる。単発のイベントではなく、一定期間、相手の世界に身を置く経験が重要だ。
この越境経験は、知識の獲得以上に「相手にも相手の合理性がある」という体感的な理解をもたらす。ビジネス部門がなぜ「すぐにほしい」と言うのか。システム部門がなぜ「それは難しい」と言うのか。相手の立場で考えられるようになることが、翻訳力の基盤になる。
外部知見の活用 ── 「丸投げ」ではなく「移転」
社内だけでの育成には限界がある。BABOKに精通した外部パートナーの知見を借りることは合理的だ。ただし、前回のInsightでも述べた通り、外部に「課題定義の丸投げ」をしてはいけない。
外部パートナーの役割は「魚を渡す」ことではなく「釣り方を教える」ことだ。最初のプロジェクトでは外部パートナーが主導し、社内のBA候補者がそのプロセスを横で学ぶ。次のプロジェクトではBA候補者が主導し、外部パートナーがレビュアーとして伴走する。3つ目のプロジェクトではBA候補者が自走し、外部パートナーは必要に応じてスポットで助言する。
この段階的な移転の設計が、持続的なBA能力の内製化につながる。外部依存を減らし、自社の力で課題を定義し続けられる組織を作る ── これ自体が、組織変革のゴールだ。
育成を阻む壁 ── そしてその越え方
壁① ── 「で、その人の所属はどこなの」
BA人材の最大の組織的課題は、ビジネス部門にもシステム部門にも所属しにくいことだ。ビジネス部門に置けば「ITのことがわからない人」と見なされ、システム部門に置けば「開発しない人」と見なされる。どちらの評価軸にもフィットしない。
解決策は、BA機能を特定の部門に閉じず、プロジェクト横断的なポジションとして定義することだ。経営企画部門やDX推進室の中に設置するのが最も自然だが、重要なのは場所よりも「この役割の価値を経営層が理解し、評価基準を明確にする」ことだ。BAの成果指標は「作ったもの」ではなく「定義した課題の質」と「防いだ手戻り」にある。この評価軸が組織として認められなければ、優秀な人材はBA的な役割を引き受けようとしない。
壁② ── 「忙しくてそんな余裕ない」
BA候補者は、たいてい現部門のエースだ。ビジネス部門とシステム部門の両方に足を踏み入れた経験があり、越境の意志がある。そういう人材は当然、現在の役割でも重宝されている。「育成のためにプロジェクトに参加させたい」と言っても、「今のプロジェクトを回すのに手一杯で出せない」という反応が返ってくる。
これは経営層のコミットメントなしには解決しない壁だ。BA人材の育成を「あれば嬉しい投資」ではなく「DXの成否を分ける戦略投資」として位置づけ、育成に必要な工数を正式にプロジェクト計画に組み込む。これは現場のマネージャーの判断ではなく、経営層の意思決定の領域だ。
壁③ ── 「問い返すと嫌われる」
BA的な役割を担い始めた人材が最初にぶつかるのが、「本当にそれで正しいですか」と問い返すことへの組織的な抵抗だ。特にビジネス部門が強い組織では、ビジネス部門の意思決定に疑問を呈すること自体がタブー視される。
ここで必要なのは、問い返すことを「抵抗」ではなく「品質管理」として定義し直すことだ。製品の品質検査と同じように、意思決定の品質を検証するプロセスは不可欠だ。BAが問い返すのは「反対しているから」ではなく「投資のリターンを最大化するために、前提を確認しているから」だ。この再定義を経営層が明示的に支持し、組織に発信することが、BA人材が機能するための最低条件になる。
まとめ ── 育成もまた、チェンジマネジメントである
BA人材の育成は、研修プログラムの導入ではない。組織の中に新しい役割を作り、その役割が機能する環境を整え、人の行動と組織の文化を変えていくことだ。これはまさにチェンジマネジメントそのものだ。
候補者を見極め、3つの筋力 ── 課題を構造化する力、問い返す力、翻訳する力 ── を実務の中で段階的に鍛える。越境経験で相手の合理性を体感させる。外部知見を「丸投げ」ではなく「移転」の形で活用し、最終的には自社の力で課題を定義できる組織を作る。そして何より、この役割の価値を経営層が理解し、評価し、守る。
テクノロジーだけでは、組織は変わらない。橋渡し役を「置く」だけでも変わらない。橋渡し役が育ち、機能し、組織に根づく環境を設計すること。それが、DXの基盤であり、すべての変革の起点になる。