講演 福嶋義弘氏 皆さんこんにちは。わたしは IIBA 日本支部の代表をしております福嶋です。よろしくお 願いします。皆さんのようにアカデミックな議論はなかなかできないと思いますが、わた しからは BABOK の概要と、我々の組織がどのような活動をしているかについて話をさせて いただきます。その後、研究部会担当理事の宗から、BABOK を改訂の話も含め、北米の動向 について話をさせていただきます。よろしくお願いします。 私は人材育成に携わっていますが、BA についてなぜ興味を持ったかを最初に話します。 米国における IT プロジェクトの実態調査によると、成功したプロジェクトは３４％しかな く、５５％は問題を抱え１５％は失敗プロジェクトであるそうです。 その問題というのは、期限／予算が超過するとか、機能未達などです。ベンダー側は納 期を守ろうとすると、例えば、機能を縮小するとかして対応しようとするわけです。 これらの問題の原因としてどのようなものがあるかといいますと、一番は、「不十分な要 求定義」です。このへんは皆さんもよく理解していただけると思います。 その他、「スコープ管理の不備」とか、「リスク管理ができていない」ことが原因にあげ られます。 一つ注目したいのは、コミュニケーション上の問題があることです。技術者は要求工学 の方法論を忠実に守り作業を実行します。先ほどの講演の中で、「標準を順守してそのとお り作っていく」という話がありました、それは非常に重要なことですが、超上流ではそれ だけでは不十分でお客様のニーズが引き出せたか、要求分析／要求定義を合意できたかコ ミュニケーションをとる必要があります。最近わたしは技術だけではなくて人間力が上流 や超上流に必要であると言っていますが、まさにお客さまとのコミュニケーションがうま く行かないことが、多々原因となっているわけです。 今までは米国の例でしたが、日本はどうでしょう。ちょっと古いデータで申し訳ないの ですが、日本もあまり変わってないということです。 こちらは、『日経コンピューター』に載っていたデータです。日本国内でも 26.7％しか成 功していないという調査データがあります。 その理由を見ますと、「情報システム部の発注者としての反省」の調査ですが。「仕様の 定義が不十分」が 44％です。それから「仕様を明確に提示していない」22%という結果です。 一般的に日本でよく言われるのは、ユーザー側は丸投げしベンダー側がそれをフォーロ ーしていると、従来から言われています。 もう 1 件、社団法人 日本情報システムユーザー協会（JUAS）の調査があります。これ は何かと言いますと、ユーザーが「開発ベンダーに対する不満」が何であるか調査したデ ータです。それをまとめた結果をみると、「企画提案力の不足」がダントツです。まさに、 ベンダーは、ユーザーのかゆいところに手の届くような、提案ができていないと言ってい るわけです。
一方、発注者としての反省ですが、ここもやはりダントツです。「システム仕様の定義が 不十分のまま発注した」と反省しているわけです。それから「RFP を明確に提示していない」 と反省があがっています。そこはベンダーが何とかやってくれるだろう、ＩＴシステムは 良く判らない、発注側の要求を理解し提案をしてくれるだろうとの思いもあるかと推測で きます。 別な視点の資料があります。「日本企業における IT 投資と経営目標の不整合」について の調査です。米国と日本企業と比べています。IT 投資と経営目標との整合性が取れている かということです。IT 投資は要求がありこういうシステムを作ろうとか、こんなプロジェ クトを作ろうとか、いづれにしてもその要求は企業として経営の目標と整合性を取られて なければいけないわけです。そこでデータを見てみると、米国では８３％整合が取れてい ます。一方、日本は、３８％の状況です。逆に「IT 投資と経営目標との整合を取ることが 困難か」といった質問では、これが逆転し日本の方が５４％困難であると回答になってい ます。日本では無駄なＩＴ投資の可能性があります。 弊社でも失敗プロジェクト原因分析を行った際、今までお話したような内容の課題や問 題が発生しました。 社内の管理や開発標準は存在するが、それでも失敗プロジェクトは発生する。原因分析 では「要求に対する把握、分析が不十分」、「顧客との完成型の共有ができていない」、「顧 客とのコミュニケーションが不足」との結果になりました。これらの課題や問題を解決す るための施策として「超上流領域の顧客対応力や人材育成推進環境を整備強化」が急務と なり、良策を検索する中で BA および BABOK を知ることとなったわけです。BA／BABOK は弊 社の問題解決の一助になると判断し、この知識体系を社内の管理／開発標準への組み込み ことや社内教育へ展開し超上流を実践できる人材の育成を推進しています。 次に、ビジネスアナリストとは何かと、なぜ、BA が重要かについて話します。その後、 最新のバージョンは BABOK の 2.0 の概要とそれから活用事例について説明します。 ビジネスアナリシスとは、組織の構造のポリシーおよび業務運用について理解を深め、 組織の目的達成に役立つソリューションを推進するためのステークホルダーのリエゾン （橋渡し）となるタスクテクニックをまとめたもので、それを知識体系として構成したも のが BABOK になります。 この話をすると、知識体系は分かった、ではその知識体系を「どうやって使えばよいの か」と聞かれます。そこについては今、プロセスの中にこの知識をどう組み込もうか研究 部会等で検討を行っています。その為にガイドラインを作成、事例やモデル作成しようと 活動しております。ソリューションとかタスクについての定義や意味はこの資料に書いて ありますので後で参照してください。 ＢＡは何をしなければいけないかということですが、プロジェクトが組織の目的に沿っ ているか確認することが重要だということが言えます。この BABOK はどんな人達が作った かといいますと、技術者やベンダー側が作っているのではなくて、ユーザーの人たちが集
まって、自分たちが組織の目標に向け良い方向に改善するためにはどうしたらいいかとい うことで作り上げました。要求を確実に引き出し分析し、定義しそれを改善するために開 発したのが大きな特徴です。 すなわち組織、社内のステークホルダーにプロダクトやサービスを提供するために備え るべき能力を定義すること、組織の目的を定義することです。ですから企業が存続するた めの目的を明確にするのがここに現れているということです。 先ほどのデータですが、プロジェクトの半数は納期遅れ、予算超過、機能不足とかにつ いて、今までいろいろな対策をとって来ましたが、それはあまり役立っていないというこ とです。 次のスライドに移って「要求が妥当であるかどうか判断するためには、何らかの基準が 必要である」、「組織から提示される要求が妥当であるかどうかは、その組織内部で合意が 形成されて、組織に属する人々が納得しているかどうか」何か非常に難しいことが書いて あります。簡単に言いますと、今、ユーザー側にシステムを納品するとします。このシス テムはプロジェクトの中で要求をいろいろ定義して、そのとおりシステムを作ったわけで す。そのできたシステムの機能全てを 100％とすると、実はその中で使われる必要な機能は 約 60%しかないといわれています。後の 40%は、この際、IT 化のためにそれぞれのステーク ホルダーの要求を全て網羅してしまい利用されない機能が組み込まれてしまっているわけ です。それであるならば 60%のシステム規模におさえ、安価に構築した方が品質も上がるの ではないかというような考え方もあるわけです。それには本当に必要な要求が定義されて いるかどうか、ステークホルダー間の合意が形成できているかどうかが重要であります。 ビジネスアナリシスとは、そこをしっかりと要求の妥当の判断基準を持ち、合意させるテ クニックが必要だということになるわけです。 ここにガイドブックがあります。この中でも読んでいただいている方はいらっしゃると 思います。IIBA 本部が公開した BABOK Ｖ2.0 の翻訳本です。IIBA 日本支部のホームペー ジから購入することができます。一冊 6,000 円です。翻訳して出版したのは日本が第１号 です。その他、今、メキシコ、それからドイツ語に翻訳しようと動きがありますが、まだ 日本語版しか発行されていません。
IIBA について説明させていただきますと、IIBA（International Institute of Business Analysis）という非営利団体です。本部はカナダのトロントにあり BABOK の開発／普及、 それから CBAP、それから今年の１月に開始された CCBA という認定資格試験を実施しており ます。更にＢＡの専門家の知識共有と貢献のための様々な活動を推進しています。 会員数は、現在全世界で約２万人です、毎年急激に増えているのが特徴です。支部は約 110 支部あります。ただ支部および会員の大半が北米です。日本は 80 番目に支部として立 ち上がりました。なおこれらのデータは今年の年次総会のデータです。 IIBA は 2003 年に設立されました。その後 2005 年に BABOK1.0 を発表し、2009 年に発表 された BABOK の 2.0 が最新バージョンです。詳細はいえませんが、Ｖ3.0 を、公開に向け改
訂を始めた状況です。 続いて、日本支部の説明をさせていただきます。まず BABOK の翻訳版の出版を世界初で 実施しました。更に、この後説明に立つ宗が、研究部会を立ち上げて、３つの WG が活動し ております。ＷＧでは BABOK のタスクをプロセスにどう組込むかとか、BABOK の研究、事例 やモデルを作る活動をしております。 その他には普及のためのセミナーやカンファレンスを実施しています。今年最大の注力 事業は、CCBA 認定資格の日本語試験を 11 月の下旬に実施することです。現在、本部との調 整、試験問題の翻訳活動を行っております。認定資格は CBAP、CCBA の資格があります。CCBA というのは CBAP の下位資格です。CBAP は全世界で 1,325 名、日本の資格保有者は現在８名 おります。世界の国の中で 10 本の指にやっと入ったところです。保有者の大半はアメリカ、 カナダの人たちで占めています。PMP と比べてかなり難しい資格と認識しています。 IIBA 日本支部は合計 26 社のスポンサー企業の費用でいろいろ活動をさせていただいて います。日本支部の会員は 249 名です。少し伸び悩んでいる状況です。もしこれを契機に BA について活動したいという方がいらっしゃいましたら、是非ご入会ください。 11 月の初旬にはマイアミで IIBA 本部のカンファレンスがあり、視察ツアーを計画中で す。また、日本支部でも 12 月にカンファレンスを計画していますので、是非ご参加くださ いますようお願いいたします。 時間も少なくなってきましたが、これから基本概念について話します。まず要求につい て話をしていきます。要求、requirement ですが、「ある企業の過去、現在、未来における 条件または能力のほか」、「組織構造、役割、プロセス、ポリシー、ルール情報システムな どの記述も要求に含まれる」、「また、企業のある側面の現在または将来の状態を要求とし て記述する場合もある」とか、既存の知識体系では要求はすべて IT システムが前提とされ ていますが BABOK では要求を IT システムのみならず広い意味でとらえています。その企業 の継続的な発展のために必要な目的、それに対する戦略を考えて行くわけですが、それを 考える中でいろいろなソリューションが出て参ります。IT 化だけがソリューションではな く、組織変革をすることもありますし、業務改善を行うこともあります。それら全てが BA の対象範囲となります。 そして、先ほど白坂先生も言っておられましたが、業務をうまく効率化するために自動 化しようとして、IT が関係してくるというような位置づけになってくるわけです。 BABOK では要求を主に３つに分類しています。まずは組織の目的、目標であるビジネス要 求があります。その要求を達成するために、それにかかわる人たちのステークホルダー要 求が個別に出てきます。その要求を実現するためには、いろいろな課題、解決するための ソリューション要求が出てきて、その中に非機能要求ですとか機能要求ですとか、このあ たりは皆さんの得意の範疇かと思います。 それら要求を明確化するために BABOK では、大きく７つの知識エリアを設定しています。 その中の基礎コンピテンシは、その他の知識エリアのタスクを実行するために必要な行動、
特性、知識、資質についての説明です。その他の６つがその要求を明確にするための知識 エリアとなります。 まず大事なのは、「エンタープライズアナリシス」、企業の分析をすることです。分析の 結果課題や問題が判明しその解決のために「要求アナリシス」と「引き出し」により、要 求が何か具現化していきます。 分析して引き出した要求が組織の中で本当に妥当性があるか確認しなければなりません。 それが「ソリューションのアセスメントと妥当確認」です。そしての要求の妥当性を組織 内で合意をとり、実際にそれを改善して行く流れになります。次に、要求を明確化し、合 意するために何をやるか、計画を立て、それがうまく実行できているかとモニタリングを します。これが「要求のマネジメントとコミュニケーション」、「ビジネスアナリシスの計 画とモニタリング」の知識エリアになります。 知識エリアはプロセスを表すものではないですから、あくまでも必要な知識としてタス クで何をやればよいか、つまり機能が示されています。そしてそれに必要なスキルとか、 テクニックが何かとこのガイドブックには記載されています。本日は時間がありませんの で詳しくはガイドブックを参照してください。BABOK は方法論ではありません。これを実際 に使う上では、プロセスの中にうまく組み込んで行く必要が出てくることになります。 ＢＡで特に重要なことは、妥当性を確認した要求をドキュメントとして見える化をする ことになります。その最終的なものが RFP になるかもしれませんが、見える化が要求定義 の確証、評価のチェックリストになります。 プロジェクト各工程に BABOK の知識エリアをマッピングすると資料のようになります。 これは比較的見やすいので資料に入れてあります。プロジェクトの中で、まずは企画フェ ーズでエンタープライズアナリシスのタスクが活用でき、その中から引き出した要求を要 求アナリシスのタスクを定義、設計要求定義及び設計構築フェーズ以降のプロジェクトの 中で活用することになります。そしてその工程での作業の監視することと、構築したシス テムの運用時に解決した要求結果を評価して次の改善につなげるサイクルになります。 BABOK の知識エリアがそれぞれの工程の中で関係つけられる事が理解されたと思います。最 後少し駆け足になりました。 次に現在 BABOK が何処で使われているか紹介します。有名な所では NTT データの標準の 中にこの BABOK が入っています。ＳＬＣＰでいう所のシステム化計画の工程が社内標準に 組み込まれています。 これは少し古いデータですけれども、ＮＴＴデータの社内標準に BABOK のタスクを組み 込んだ図です。その後改訂があったと聞いています。 なぜ BABOK のタスクを組み込んだかは、ここに書いてあります。まずは「特性として、 ソリューション、IT に限定しない業務分析を行うために実践的な知見である。」、「グローバ ルな共通言語である。」、最後は「世界で通用する認定、CBAP と CCBA がある。」です。上流 工程の方法論を統合整理して目的を達成しょうと BA をプロセス中に入れ込んだ活用事例で
す。 それから都庁が各種システムのリプレース時の要求定義を行い、RFP を考える際に BABOK を活用しています。そのために産業技術大学院大学に都庁のシステムにかかわる方々を集 めて BABOK の教育を実施しました。 それ以外に外資系の生命保険、業務の品質向上とＢＡ人材育成の必要観点から BA をプロ セスに組み込んだ例もあります。 後でまた詳しく出てくると思うのですが、アメリカの例としましては、ファイナンシャ ル系、それから損保系、政府系、またエネルギー系などの企業や官庁が、BA を導入してい る実績がこの資料に記載されています。 次は認定試験についてです。認定資格には CBAP、CCBA があります。先ほども話しました が CBAP は上位認定で日本には 8 名の保有者がおります。2008 年よりペーパー試験から CBT に変わりました。難易度が高い認定資格です。CCBA は 2011 年 1 月に開始された下位認定で す。11 月下旬に日本語試験を実施する予定です。 CBAP はよく PMP と比べられます。認定の要件や仕組みが似通っているからです。一番異 なるのは CBAP の場合には 7,500 時間の BA 経験を記述し申請、本部で審査を受けます。そ こが PMP と比較して審査が厳しいところです。日本最初の取得者はこの審査に通るために ３回その申請書を書き直して、４回目に通りました。 次に、後で見ていただければいいと思いますが BABOK と他の知識体系との比較です。 最後にスポンサーになっている企業のリストを紹介します。NEC も近々、ゴールドスポン サーになる予定です。我々の今後の活動で BA や BABOK を普及するためには、特にユーザー 側に広げて行きたいと思っています。 では続きまして、理事の宗が北米の動向と、IIBA 日本支部 研究部会の状況を話します。
