LTSコラム

ビジネスプロセスの教科書のこぼれ話 第8回:ビジネスアナリシスの歴史

こんにちは、LTS執行役員の山本政樹です。

「ビジネスプロセスの教科書のこぼれ話」の第8回はビジネスアナリシスの歴史を紐解きます。ビジネスアナリシスが最近注目されていて、IT系のウェブコラムやIT系業界団体の報告資料でも「ビジネスアナリシス」や「ビジネスアナリスト」という言葉が目立つようになりました。今回のコラムでは「ビジネスアナリシス」という言葉が生まれる前に遡って、手法が生まれた歴史を説明してみたいと思います。

 

なおビジネスアナリストについてはこちらのコラム「よく分かるビジネスアナリスト 第1回:ビジネスアナリストとは?」をご覧いただけると幸いです。

ビジネスアナリシスの源流はソフトウェア要求分析

「ビジネスアナリシス」は2000年代に入ってから普及し始めた言葉です。普及団体であるIIBA(International Institute of Business Analysis・・・※)が設立されたのは2003年、日本支部が設立されたのが2008年です。

※ カナダに本部を置く世界的なビジネスアナリシスの普及団体で、ビジネスアナリシスのノウハウ集であるBABOKの刊行や、CBAPやCCBAといったビジネスアナリスト資格の認証を行っています。

 

しかしビジネスアナリシスの歴史は2000年以前に遡ります。その源流はソフトウェア工学における要求分析で、これはユーザーがソフトウェア技術者に提示する要求仕様の在り方に関する研究分野です。1980年代あたりから企業にIT化の波が押し寄せました。同時にトラブルプロジェクトも多発し、「デスマーチ」などという言葉も生まれました。

 

このため世界中でトラブルプロジェクトの原因追究が行われますが、数ある研究の中でも有名なものが1995年に報告された「カオスレポート(THE CHAOS REPORT)」です(※)。この報告では数々の事例から企業における情報システム開発の成否を分析していますが、その結果は驚くべきものでした。

※ 米国のコンサルティング会社スタンディッシュグループが実施した調査で、当時MIS(Management Information Systems:経営情報システム)と呼ばれていた企業の基幹システムの開発をターゲットとして、365人の回答者にプロジェクトの成否をヒアリングしています。

 

当初目指した期間やコスト、要求機能の実装を満たした「成功」と呼べるプロジェクトはたったの16.2%で、52.7%のプロジェクトは期間超過やコスト超過といった問題を引き起こしており、31.1%のプロジェクトは中止や中断に至っているというのです。

 

プロジェクト失敗の原因として挙げられたものの大半はソフトウェアの技術的な問題ではなく、「ユーザーからの情報が不足」「要求や仕様が不完全」「要求や仕様が変化」といった業務側からの要求に関するものでした。このような研究結果もあり要求分析はソフトウェア開発を成功させる上で大きな注目を集めるようになったのです。

 

企業が開発する業務用ソフトウェアにおいて「要求を明確にする」とは、その企業の業務の状況をしっかり把握し、適切な将来像を描くことに他なりません。こうなるともはや純粋なソフトウェア技術とは性格の異なる研究分野となり、2000年代に企業の業務分析を担う活動「ビジネスアナリシス(=業務分析)」として確立されました。

 

ソフトウェア要求工学の名著に「ソフトウェア要求(Karl.E.Wiegers著)」という書籍があります。2003年(=IIBAが設立された年)に刊行された第二版には要求アナリシスや要求アナリストという言葉が登場しますが、2014年に刊行された第三版ではこれらはビジネスアナリシスやビジネスアナリストに直され、記述の内容もBABOKバージョン2.0と整合がとられたものになりました。この言葉の変化が、ビジネスアナリストの歴史を端的に示しているとも言えます。

 

BPR&BPMに代表されるプロセス志向の流れ

 

要求分析がビジネスアナリシスに発展していった同時期に、企業の業務構造の考え方に大きな革命がありました。マイケル・ハマー氏が1993年に提唱したBPR(Business Process Reengineering)という手法です。

 

BPRでは業務の構造を、「顧客に価値を提供する流れ(=プロセス)」と言う観点から捉えます。一般に企業は「販売」「生産」「経理」といった機能別組織から成り立っていますが、これらの組織が狭い視野で活動してしまうと企業内に非効率を生み出してしまいます。例えば販売部門と生産部門が連携しなければ、需要以上の製品を生産してしまいますし、財務部門と販売部門とが適切に情報連携しなければ、企業業績をタイムリーに予測することは出来ません。このように部門を横断した業務や情報の流れを再整理して、劇的な業務改革を行うのがBPRです。

 

BPRは1990年代から2000年代初めにかけて大きなブームとなりましたが、その後は一旦、下火になります。業務構造を劇的に変えることはリスクも高く、このような取り組みを主導できる優秀な人財も限られていました。結果、「BPR」と呼ばれるプロジェクトの7割近くは目立った効果がないか、失敗に終わったという調査結果もあります。また仮に成功させたとしても、外部環境は変化し続けますから、BPRによって生み出した優位性は長くは続きません。

 

しかし、業務のプロセスに着目する「プロセス志向」の考え方自体が価値を失ったわけではありません。その後、BPRは他の手法も取り込んでBPM(Business Process Management)という手法に発展しました。BPRはプロジェクト型の(一過性の)大改革でしたが、BPMはビジネスプロセスを構築し、KPIなどを通じた管理からその改善点を見つけ出し、また新たなプロセスを構築(再設計)するというサイクルを定常的に回し続けます。これによりビジネスプロセスを外部環境や企業戦略の変化に対して着実に適応させていくのです(※)。

※ 今ではBPRはBPMのサイクルの中で大きな変革を推進する手法としてBPMを構成する要素として捉えられています。

 

BPMには“カイゼン”に代表される日本の製造業の品質管理や効率改善の手法も影響しています。米国に渡った“カイゼン”はTQM(Total Quality Management)やシックスシグマなどと呼ばれる手法として体系化されました。この「関係する人や組織が協力して改善サイクルを回し続ける」という考え方がBPMにも受け継がれているのです。

 

プロセス志向がビジネスアナリシスに合流する

 

前述のようにビジネスアナリシス(業務分析)はソフトウェア開発における要求分析が源流です。ただ、企業のソフトウェア開発の多くは業務変革のために行われるわけですから、業務分析の役割を広げていくと自然とBPMとの境界が曖昧になります。

 

このような流れの中で2015年にリリースされたBABOKバージョン3.0では、これまでのソフトウェア開発の上流工程中心のビジネスアナリシスからスコープを大きく広げ(※)、企業における業務構造の定常管理や、継続的業務改善といった考え方を盛り込みました。これによりBPMやビジネスアーキテクチャ(Business Architecture)という考え方もビジネスアナリシスの一部となったのです。

※ BABOKバージョン2.0でもBPMやソフトウェア開発以外のソリューション導入も対象とは謳っていますが、内容的にはまだソフトウェア開発中心のものでした。

境界が曖昧になるビジネスアナリシスとEA(エンタープライズアーキテクチャ)

 

BPMやビジネスアーキテクチャがビジネスアナリシスに取り込まれたことで、ビジネスアナリシスとエンタープライズアーキテクチャ(EA)の境界も曖昧になりつつあります。

 

EAはもともとITを全社最適で導入するために開発された手法です。企業構造を業務の構造(ビジネスアーキテクチャ)、アプリケーションの構造(アプリケーションアーキテクチャ)、情報の構造(データアーキテクチャ)、技術基盤の構造(テクニカルアーキテクチャ)という四階層に分けて設計し、全体最適でのIT導入の在り方を検討します。個別のソフトウェア開発プロジェクトを運営するための方法論ではなく、プロジェクト間で目的や機能の重複や矛盾が生じないよう、プロジェクト間で最適な範囲(スコープ)を調整するための方法論とも言えます。

EA_図

【EAの考え方】

 

ビジネスアナリシスがIT導入における要求分析であった頃、EAとの住み分けは比較的明確でした。EAは企業全体という大きな視点から無駄なくシステムの配置を行う構造設計に力点を置いています。ですから個別のシステム導入における詳細な要求分析方法は明確にしていません。EAによって切り出された各プロジェクトでの実践的な要求分析はビジネスアナリシスが担っていたのです。

 

ところがビジネスアナリシスが企業レベルの業務構造管理に範囲を広げたことで、二つの手法の境界は微妙になりつつあります。ビジネスアナリシスはEAの四つの階層の中でももっぱらビジネスアーキテクチャに主眼を置いてはいますが、ソフトウェアの支援のない業務などほとんどなく、アプリケーションアーキテクチャやデータアーキテクチャに関しても考え方が重複します。現状では企業全体を大きな視野から切り取るアーキテクチャレベルに関してはEAが、個別のプロジェクトの運営手法についてはビジネスアナリシスの方がより深い内容となっていますが、それぞれの研究が進めばビジネスアナリシスとEAの融合は一層進むのではないかとも思われます。

 

まとめ

ここまでビジネスアナリシスの歴史を振り返ってきましたが、いかがだったでしょうか。ビジネスアナリシスの流れを一つの図で表現すると以下のようになります。

ビジネスアナリシスの歴史_図

【ビジネスアナリシスの歴史】

一つお断りしておくと、この歴史はあくまでもビジネスアナリシス側から見たものです。決してBPM、EAといった手法がビジネスアナリシスに統合されてなくなったというわけではありません。BPMやEAに関しても、多くの団体が啓蒙や普及、手法高度化のための活動を行っています。どちらかと言えばビジネスアナリシスがその対象範囲を広げてBPMやEAの考え方を取り込み、他の手法との境界に進出しているというのが正しい見方かもしれません。

 

これは決して悪いことではありません。それぞれの手法の対象領域が重なることで、より多面的な見方から手法の進化に向けた議論が生まれます。また議論を通じて各手法の連携方法も明確になります。似た観点で幾つも違う手法があることは、活用する側からしても混乱します。ですからそれぞれの手法が視野を広げて隣接する手法とのあり方を模索することは大変重要なことです。

 

BPMやシェアドサービスへの業務移管のような、非IT領域での業務変革案件も担うLTSとしては正直なところ以前のBABOKは使いにくいものでした。しかし、バージョン3.0からその視野が広がったことで、とても使いやすいものになってきました。このような手法の進化はビジネスアナリシスに限らず、他の手法でも日々進んでいます。これらをタイムリーに学びつつ、プロセス変革を効率的に進めて行きたいものです。

 

関連書籍のご紹介◆

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

※Amazonで購入する。

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

お気軽にお問い合わせください

03-5312-7010

お電話でのお問い合わせ受付時間 9:30〜18:00