LTSコラム

よく分かるビジネスアナリスト 第3回:欧米のシャドーITならぬ、シャドーBA問題
2016.11.15

こんにちは、LTSのコンサルタントの大井悠です。先日ビジネスアナリシスの国際団体IIBA(International Institute of Business Analysis)が主催する国際カンファレンス「BBC2016」に参加してきました。このカンファレンスではビジネスアナリシスを巡る最新動向や、ツール、人材育成など幅広いテーマのセッションが開催され、北米を中心に世界43か国から1400人以上のビジネスアナリスト(以下BA)が参加します。私もいくつかセッションに参加したのですが、その中で「シャドーBA」という、ともて興味深いテーマのセッションがありました。「シャドーIT」は日本でもよく聞きますが、「シャドーBA」とは何者でしょうか?前回のコラムのテーマ「潜在BA」とも絡めて、本コラムで「シャドーBA」を紹介したいと思います。

シャドーITプロジェクトの裏にシャドーBAあり

「シャドーIT」と言う言葉をご存知でしょうか?シャドーITとは、ユーザー部門が情報システム部門を通さずに、独自にソフトウェアやクラウドサービスを自部門に導入してしまうことを指します。シャドーITが発生すると、情報システム部門が社内全体の情報システムを把握しきれず、部分最適の仕組みになってしまったり、セキュリティリスクを抱えたりするので、日本でも問題視されています。シャドーITは海外先進国でも日本同様かそれ以上に問題視されているのですが、北米では、それとセットで「シャドーBA」が問題になっているようです。

シャドーBAとは耳慣れない言葉ですよね。私もセッションの初めにこの言葉を聞いたときに「なんだろう?」と思いました。シャドーBAを理解するには、まず北米企業のBA事情を理解する必要があります。数多くのBAが活躍する北米では、例えばファイナンス部門(日本で言う経営企画部門のような部門)、営業や生産管理などの各ビジネス部門、IT部門など、社内の複数の領域にBAチームがあります。各チームのBAには、それぞれ担当領域に応じたビジネスプロセスの維持管理やプロジェクトが割り当てられており、関係部門やIT部門のPMと協力しながらビジネスプロセスの変革に向けて働いています。このようなBAが北米だけで10万人以上存在していると言われています。

そんな北米企業のBAチームを悩ませているのがシャドーBAです。企業に情報システムを導入すると大なり小なりビジネスプロセスに影響が生じます。そのため、北米では情報システム導入の際には、社内BAが要件定義や導入後のビジネスプロセスの変更管理等を行い、ビジネスプロセスの健全性を維持しています。セッションによると、そんなビジネスプロセスがしっかりと統制された北米でも日本と同様にシャドーITが発生してしまうことが少なくないようです。どんなに小規模でも情報システムを導入する以上、そこには要求を切り出して仕様に落とし込む=BAの役割を果たす人が必ずいます。そんなシャドーITにおけるBAの役割を担う人、それが「シャドーBA」です。セッションの中ではシャドーBAの見つけ方として以下のような例が提示されていました。

  • Assumed role by skillset (SelfIdentified)・・・※
    ⇒(自称も含めて)スキルセットが実質的にBAであることを示す人を見つける
  • Assigned role by Project / Management
    ⇒プロジェクトや部門などでBAに似た役割が割り当てられている人を見つける
  • Performing the role unaware of the skillset
    ⇒スキルセットがどうあれBA的な役割を担っている人を見つける
  • BA role absorbed by another role
    ⇒PMなど他の役割の一部としてBAを行っている人を見つける
    (引用:Bob Hill『Embraing the BA in the shadows』より)
※Skillsetという言葉が登場しますが、欧米では明確なジョブディスクリプション(職務記述書)に基づく採用が一般的で、ここに職務上必要な役割やスキルが明記されています。また応募者も自らのスキルを明確にアピールして応募してきます。ですからBA部門が公式にBusiness Analystという職種で採用した人員以外で、ジョブディスクリプション上の記述がBAのスキルセットを示している場合や、応募者本人がCBAPのようなビジネスアナリシス資格を保持している場合などはシャドーBAの可能性があるということと推測されます。

シャドーBAの何が問題かというと、彼らはそもそも自分が社内のビジネスプロセスマネジメントの一翼を担っているという自覚がありません。そのため、社内の公式なBAチームとコミュニケーションを取らずに勝手にプロジェクトを進めてしまいます。その結果、社内BAのあずかり知らぬところで部分最適な情報システムが導入されていたり、いつの間にかビジネスプロセスが変更したりすることがあります。そうなると、社内BAが守ってきた全体最適なビジネスプロセス・アプリケーションのアーキテクチャが崩れてしまいます。また、社内のBAチーム間で統一させてきたビジネスプロセスを巡る言葉の定義や機能の標準化が崩れることもあるようです。

参加したセッションは「シャドーBAに対して正規の社内BAはどう対応すればよいか?」がテーマだったのですが、参加者はシャドーBAに手をこまねいている社内BAばかりで、スピーカーが話し終わらないうちから次々と質問や相談が飛び交い、大盛り上がりでした。その熱気から、シャドーIT問題のもたらす影響の深刻さを感じました。

前回のコラムで「潜在BA」という言葉を使って、日本企業において一時的にBAのような立ち回りをする社員のお話をしましたが、北米で問題になっているシャドーBAは、まさにこの潜在BAそのものです。そして、社内BAが存在しない日本の状況はまさにこのシャドーBAによる弊害の宝庫なのです。社内で業務に関する言葉の定義がバラバラ、個別最適なシステムが散在している、そもそも全社のアークテクチャを可視化すらされていない(組織図、業務分掌、アプリケーションリストがあるのみ)等…。セッションに参加して、日本のBA事情は北米のBA事情に対して2周も3周も遅れているのだなと痛感した次第です。

シャドーBAへの対応策にヒントがある?

スピーカーであるBob Hill氏はセッションの中で、シャドーBA対策として社内BAが為すべきこととして3つの施策を紹介していましたので、そちらも簡単に紹介したいと思います。1つは、まずは社内の各部門などでシャドーITが計画されていないか、また起きていないか検証する機会を設けて発生そのものを防ぐこと。2つ目は、もしシャドーBAを見つけたら、「あなたは今、BAの仕事をしているのよ」とマメに話しかけ、彼らにBAの役割を担っていると自覚してもらうこと。そして最後に、シャドーBAと社内BA間は肩書きのあるなしに関わらず、同じBAの役割を担う者同士として信頼関係を築くことでした。こうしたステップを踏むことで、シャドーBAと社内BAが互いにアクセスしやすい環境ができ、会話がうまれ、そこでナレッジや状況を共有できます。その結果、シャドーBAは社内BAのアイデアやナレッジを活用して、ビジネスプロセスの全体最適なアーキテクチャや共通言語を壊すことなく、自身の仕事を全うできます。

このシャドーBAへの対処が、私にはそのまま日本のBA事情に対する示唆のように聞こえました。前回のコラムでお話しした通り、日本には限定的ではあるものの、ビジネス部門、情報システム部門を問わず、BAのような役割を担う人が社内に沢山います。社外のITベンダーのSEやコンサルタントも含めると、より多くの人が潜在的なBAとして働いていることになります。BAという役割そのものがまだ認知されていない状態ではありますが、BAの認知度が向上して「自分はビジネスアナリストだ」と自覚する人が増えたら、日本のBA事情も変わってくるのではないでしょうか。いつか日本でも社内BAが定着し、周回遅れでシャドーITならぬシャドーBAが問題になる日が来るかもしれませんね。

 

関連書籍のご紹介◆

ビジネスプロセスの教科書

※Amazonで購入する。

BPO(ビジネスプロセスアウトソーシング)の効果が出なかったり、システム開発がトラブル続きだったりと、ビジネスプロセスマネジメントが上手くいっていないと多くの課題を引き起こします。
2015年7月に刊行した『ビジネスプロセスの教科書―アイデアを「実行力」に転換する方法』では、このような問題を解決するために、ビジネスプロセスとは何か、どのようにマネジメントすれば良いのか等をわかりやすく解説しています。また、著者がこれまでにお客様企業の現場で経験してきたビジネスプロセス変革の事例も多く紹介しています。ユーザー企業側で組織変更、情報システム導入、アウトソーシング活用といったビジネスプロセス変革を行う予定のある方はもちろんシステム開発やアウトソーシングベンダーの担当者の方も必見です。