| 2009年2月23日 
   【BABOK®(ビジネスアナリシス知識体系)】の解説です。 以下のような目次で解説しています。   1. BABOK®とは(全体像)   1.1 背景   1.2 ビジネスアナリシスとは   1.3 同じ分野の資格・制度との違い   2. BA資格   2.1 CBAP®試験   2.2 EEP™   3.BABOK®の内容(概要) 3.1 6つの知識エリア 3.2 基礎スキル(Underlying Competencies)   4. BABOK®の社会的意義   5. スキル標準との関係   6. その他   
 
   1.1.2 ITベンダーの状況 こちらも以前のメルマガの振り返りです。   ITプロジェクトの失敗または赤字プロジェクトの話題が多い昨今です。その要因を調べてみると明らかに「要求定義」フェーズでの問題が浮かび上がってきます。 日経コンピュータ(2003, 11, 17)のデータです。すでにご存知の方も多いと思います。それだけ有名な資料です。  
 
   プロジェクトにおいての問題です。 ・   品質問題  53.6% ・   納期遅延  45.1% ・   コスト超過 23.8%  3種のいずれか、もしくはその複合したものもあります。  3種の各失敗の中でも因果関係があるようです。 そして、成功しているプロジェクトはなんと、わずか26.7%だそうです。   では、品質問題と納期遅延の原因はどのようなものでしょうか。これも同じ日経コンピュータです。   システムの品質問題の原因 
 
  | 社内の開発体制に問題 | 13.9% |  
  | ベンダーの選択に問題 | 10.6% |  
  | 要件定義が不十分 | 35.9% |  
  | システムの企画が不十分 | 18.7% |  
  | システムの設計が不正確 | 19.1% |  
  | システムの開発作業の質が悪い | 13.1% |  
  | テストが不十分・移行作業に問題 | 21.9% |  
  | エンドユーザへの教育が不十分 | 19.1% |  
  | 運用計画が利用形態に沿っていない | 7.5% |  
  | その他 | 27.7% |               (有効回答数:498件) なんと「要件定義」が35.9%と圧倒的にナンバー1です。 それでは、納期遅延はどうでしょうか。   プロジェクトの遅れを招いた原因 
 
  | 要件定義が計画より長引いた | 37.7% |  
  | 企画作業が長引いた | 22.7% |  
  | 設計作業が長引いた | 25.6% |  
  | 開発作業が長引いた | 36.2% |  
  | テストが長引いた | 22.1% |  
  | その他 | 9.7% |                (有効回答数:621件) こちらも「要件定義」がナンバー1です。   もうひとつ重要なことがあります。それは手戻りのコストです。 かねてから、東西の有識者から指摘されていますが、その代表的なものは以下のとおりです。 ・  手戻りは、全開発費の30~50%を消費する(Boehm and Papaccio, 1988) ・  要求の誤りは手戻りコストの70~85%を占めている(Leffingwell ,1997) ・  プロジェクトが進んでからわかった欠陥を修正する費用は、早期に修正する費用よりはるかに多額である(Grady,1999) 手戻りの中でも、特に要求定義フェーズでの欠陥の後工程での修正コストの大きさが指摘されています。   どうしてこんなに、「要求定義」に問題があるのでしょうか。 もう少しデータをご覧ください。 日経IT
Proのデータをご紹介します。    
 
   ユーザ側の要求そのものが確定しづらいことも大きな要因です。 開発側とのコミュニケーションに問題があります。 そもそも、ユーザは自分の要求を明確に認識しているのか、と疑いたくなります。 かなり怪しいユーザが多いのも事実のようです。 しかも、開発側がコミュニケーションをあまり得意としないエンジニアだったとしたら、どんなことが起きるのでしょうか。  
 
   
 1.1.3 背景のまとめ 
 いかがでしょうか。今まさに上記のことが発生している状況ではないでしょうか。まとめると、次のようになると思います。 
  -ユーザー側は自分自身の要求を明確に認識することができず、それをまとめる能力が欠落している  -その結果、RFPも自分で書くことができない状況に陥っている(約50%のユーザー)
  -情報システム部要員に「商品・サービスの創造」や「顧客の確保・拡大」を期待しても、その期待に応えられていない
 -「ビジネスイノベーション」を推進する人材が育成できていない -開発プロジェクトの失敗の原因の大半は「要求定義」工程であり、改善できていない
  -開発側(ITベンダー)はコミュニケーションスキルが不足していて、ユーザー要求を引き出すことができない
 
   数年前に赤字プロジェクトの解消や、システムトラブルを解決するために、プロジェクトマネジメント能力の向上が叫ばれ、PMBOK(プロジェクトマネジメント知識体系)が注目されました。PMP資格の取得が大いに奨励され、多くのプロジェクトマネージャ(日本だけで2万人以上、全世界では25万人)がこの資格を取得しています。また、PMO(プロジェクトマネジメントオフィス)が多くのITベンダーで導入されました(今でもこの流れは続いています)。  では、優秀なプロジェクトマネージャ(及びソフト開発者)がいれば、上記の問題は解決できるでしょうか。残念ながらいくら優秀なプロマネがいても解決できないことが明確になってきました。 それは、基となるシステム仕様が正しくなければ、間違った仕様のものを正しく作ってしまうことになり、良い結果が出るわけがないからです。 いままでプロジェクトマネジメントにおいて、正しく作るやり方「HOW」を追求してきたのですがシステム仕様そのもの、つまり「WHAT」が間違っているかもしれないことにやっと気がついたのです。この「WHAT」を明確に定義する能力(ユーザー側も開発側も)の重要性が注目されています。さらに「WHAT」のみならず、なぜそのシステム/プロジェクトが必要なのか。つまり「WHY」(そのプロジェクトへの投資の根拠)はそれ以上に重要なのです。   上記の課題を解決するために今世界中で話題になりつつあるのがビジネスアナリシスであり、その知識体系としてのBABOK®です。これから、ビジネスアナリシスとは何かを考えていきます。   
 
 
 
    
 
 
 
 
 
  
 
 
 
 
 
 |