2009年5月11日

４．　ビジネスアナリシス（BABOK®）の社会的意義

少し大げさですが、ビジネスアナリシスの社会的意義について考えます。多くは今まで述べてきたことをまとめたものですが、最終結論としては以下の2点です。

①    日本のIT産業が生き延びるために必須の知識・スキル

②    ITをビジネスに活用するユーザー企業にとっても必要不可欠なもの

以下順番に、解説します。

　　－　最近のITを取り巻く環境（４．１）

　　－　解決策としてのビジネスアナリシス（BABOK®）（４．２）

４．１　最近のITを取り巻く環境

最近のITについて以下のようにまとめます。

　　－　ITベンダーの状況と問題

　　－　ユーザー企業の課題

　　－　期待したプロジェクトマネジメントの結果

　　－　「正しく作る（How）」以前の「正しいもの（What）」を決める

　　－　「なぜ（Why）」それが「正しいもの（What）」かを決めるビジネス上の理由

４．１．１　ITベンダーの状況と問題

数年前から、赤字プロジェクトが問題になっています。その赤字の理由は、

－要求や要件定義が不十分なままプロジェクトを実施している

　　　－発注側が自分の要求をまとめてくれない

　　　－ベンダーは正しい提案が出来ていない

というものでした。

そのため、QCDともに問題が発生し、大きな赤字につながっていたのです。

（この辺の事情は弊社Webページに詳しく掲載してありますので、ご覧頂ければ幸いです。）　　
　　URL：　http://www.kbmanagement.biz/sub64.html

４．１．２　ユーザー企業の課題

最近はITがユーザ企業のビジネスに直結する度合いがますます高まってきています。例えば、金融業界では、金融商品などITがビジネスを実行していると言えます。証券業界もデイ・トレードをはじめとして、ほとんどの証券業務はITが実行しています。通信業界もサービス系、例えば携帯電話のXXXプラン（白い犬でお馴染み）をはじめとして多くのサービスはITが実行しています。航空業界では予約、マイレージ、割引き、チェックイン、チケットレスなどです。流通や製造業もいわゆるSCM（サプライチェーンマネジメント）をはじめとして、部品調達、物流管理など多くの業務がITにより支えられていると思います。

では、そのITがいったんトラブルを発生するとどうなるのでしょうか。最近、新聞・マスコミをにぎわせたものだけでも、銀行のオンライン停止、飛行機の運航への影響、電車の改札など、枚挙にいとまがありません。すべてビジネスへの大きな影響が懸念されてきました。売り上げ、収益への影響、品質、さらには企業の信用問題に発展しかねないものばかりです。東京証券取引所のシステムはデイ・トレードの影響（小口取引の爆発的増加）でシステムの処理能力を超えてしまうというものでした。証券取引システムがその処理能力を超えてしまうなど、2，3年前では考えられないことでした。日本の国の信用、とまで言われたことを記憶しています。

そのように重大な影響があるのですが、ユーザー側の開発能力はどうなっているのでしょうか。

JUAS（日本情報システムユーザー協会）のデータをご覧ください。

　【ユーザーのIT開発力は落ちている】

　RFPによる役割分担（JUAS　IT動向調査2004）

　　・RFPはユーザ企業が作成　　　　　　　　　　　　　　　　　　16%

　　・ベースはユーザ企業が作成し、細部の作成はベンダに委託　　　33%

　　・ラフなRFPはユーザ企業が作成、あとはベンダに委託　　　　　41%

　　・すべてベンダが担当　　　　　　　　　　　　　　　　　　　　9%

RFPをユーザーが書き切れていない状況がよくわかります。

さらに、システム仕様の定義が不十分なものや、RFPそのものを提示していない例が多くあります。

1位と2位の数字を合計しサンプル数（n=621）で割ると、aは52%、bは39%となります。

すなわち、システム仕様の定義が不十分のまま発注したのが52%、RFPを提示しなかったのが39%あったということです。これはユーザのIT開発力は落ちていることの証拠です。これではシステムの不具合が増えるのも当然と言えます。

４．１．３　期待されたプロジェクトマネジメントの結果

上記ITベンダー側、ユーザー企業側の課題を解決するために、ここ数年プロジェクトマネジメント（特にPMBOK）に多くの期待が寄せられてきました。PMP（プロジェクト・マネジメント・プロフェッショナル）の資格取得が奨励され、世界中で20万人以上、日本国内でも2万5千人のPMP取得者が誕生しています。また同時にPMO（プロフェッショナル・マネジメント・オフィス）を設立する企業も数多く見受けられます。

最近の調査で明らかになってきたことに、赤字の要因の多くはプロジェクト開始以前の「要求」が不明確なままプロジェクトが進んでいるというものです。赤字を解消するために、プロジェクトマネジメント能力を高めようと必死の努力をしたのですが、元の原因はそれ以前のことだったのです。最初から無理な要求で受注していることがあります。無理な要求があればまだしも、その要求すらないまま受注しているようです。JUASの調査のようにRFPすら出さないまま契約をしているケースが後を絶ちません。

プロジェクトマネジメントに大きな期待をしたのですが、残念ながらプロジェクトマネジメントだけでは解決できていないことが明確になってきたのです。

４．１．４．　「正しく作る（How）」以前の「正しいモノ（What）」を決める

よくよく考えてみると、プロジェクトマネジメントとは、いかに「モノを正しく作るか（How）」に焦点を当てたものです。そのために仕事を細分化しWBSにまとめ、予定内のコストで、品質を保ちながら、期日までに仕上げます。その前提として、作るべきものの仕様、すなわち要求（What）が明確になっている必要があります。「モノを正しく作る（How）」前に、作るべき「正しいモノ（What）」の仕様が必要です。しかしながら、前述のようにユーザー側ではRFPすら出すことができない現状になってしまっているのです。これではいくらプロジェクトマネジメントを充実しても、砂上の楼閣になってしまうのではないでしょうか。「正しくないモノ」をいくら「正しく作って」も、「正しいモノ」はできません。最初の要求が正しくなければ、「間違ったモノ」を「正しく作る」ことになり、その結果やはり「間違ったモノ」が出来上がってしまいます。

だんだん見えてきました。「モノを正しく作る（How）」以前の「正しいモノ（What）」は何かを明確にしなくてはいけないということです。プロジェクトマネジメント以前の「仕様」あるいは「要求」をいかに明確にするかが問われているのです。

４．１．５　「なぜ（Why）」それが「正しいもの（What）」かを決めるビジネス上の理由

もう一つは、なぜそれが「正しいモノ（What）」なのかの理由（Why）も明確にする必要があります。理由が明確でないと、Whatがぶれます。ひと（の価値観の違い）により要求に差が出てしまうからです。Whyに相当するものが「ビジネス要求」と言われるもので、ビジネスニーズから出てくるものです。売り上げの増加、品質の改善、顧客満足の向上など、組織のビジネスニーズを元にします。