株式会社アイテックは、ビジネスアナリシスの国際的な知識体系として普及が進んでいるBABOK(R)（ビジネスアナリシス知識体系）の概要を解説するWeb講座「BA概説講座」の販売を開始します 株式会社アイテック(以下アイテック、東京都中央区、代表取締役：土元 克則、www.itec.co.jp ) は、ビジネスアナリシスの国際的な知識体系として普及が進んでいるBABOK(R)（ビジネスアナリシス知識体系）の概要を解説するWeb講座「BA概説講座」の販売を開始します。 ビジネスアナリシスはビジネス分析に基づいた要求を引き出し、プロジェクトへのインプットとして提供するとともに、要求が適切に情報システムに反映され、ビジネスに貢献していることをモニタリングする一連の流れを行う活動のことです。 企業のビジネスプロセスにITの活用が浸透し、経営戦略の実現に情報システムの重要度が増す中で、企業が求めるビジネ

今回の連載で何度か繰り返しているが、情報システム部門の使命は、ビジネスに役立つ情報システムを構築し、運用することである。しかし、“ビジネスに役立つ”ことにこだわりすぎると、自社の実力以上のシステムを構築しようとして、失敗してしまうことがある。自社の能力、リソース、資金力などに適した情報システムを企画することが必要である。 この「ビジネスに役立つ」と「身の丈にあったシステムを作る」ということのバランスを保つことが難しい。ほとんどの会社で、一度はシステム開発プロジェクトの失敗を経験しているのではないだろうか。その大きな原因として、バランスの取れた企画がなされていないことがある。 例えば、既にメインフレームやオフコンといった古いIT基盤でシステムを構築している会社で、再構築をする場合、以下のような理由で、特に難易度が増す。 （1）既にシステムが存在しているため、事業部門から見れば、再構築すること

前回、システム化を構想・企画するときに、最低限の認識が必要ではないかということで、“要求”に関して認識を一致することを提案した。ただし、最終的に抜けのない、きちんとした企画書を作るためには、構想・企画フェーズのプロセスや技法、成果物が決まっていることが望ましい。 しかし、現状はそうなっていない。情報システム部門の年度計画の時点で記述されている大まかな情報システムの構想書から、事業部門およびシステム部門の担当者が中心になって、できる範囲で提案依頼書（RFP）を作成する。そして、RFPに基づいて提案を提出してくれたベンダーの中から、最も良いと思われる開発提案を選び、選んだベンダーと一緒にシステム開発を行うことが一般的な進め方である。 このような進め方で、本当にビジネスに役に立つ情報システムを構築することができるのだろうか。構想・企画のフェーズにおいて、各担当者の進め方に任せてしまうと、どうして

IT業界で“超上流工程”と呼ばれている、システム化を構想・企画フェーズの作業について、情報システム部門やベンダーの人たちと話していると、認識が一致することはほとんどない。ある人は、事業部門のニーズや要望を、そのまま引き受けて、システムの機能になるべく取り込むことだと考える。ある人は、複数のベンダーから提案をもらって、その中から選択することだと考える。システム開発の予算取りのために、既存のシステムを良く知っている運用担当者が、短期間に企画をまとめることだと考える人もいる。 そもそも構想・企画フェーズで何を決めて、何を実行するのかについて、一般的な合意があるわけではない。企業や組織の経営方針、規模、情報システム部門の位置づけなどによっても変化するものである。このように全てが曖昧な状態で、担当する個人の考え方や経験に依存してしまっているのが現状である。このような現状で、良い企画書を作ることは大変

今回、改まってBA（ビジネスアナリシス）を語るにあたり、大学を卒業して、ユーザー企業の情報システム部に配属された1980年代から、今日までを振り返ってみた。80年代から90年代にかけて、BAという言葉は一般的でなく、IT業界では、業務分析という表現を使っていた。業務分析は、システム開発の上流工程で上級SEが行う作業であった。 ちなみに、当時の上級SEは今のプロジェクトマネジャー、ビジネスアナリスト、ITアーキテクトの仕事を兼ねた仕事をしていた。上級SEの中でも特に優れたSEをスーパーSEと呼び、憧れると共に、将来はスーパーSEになりたいと思ったものである。 当時から、中期計画とそれに基づく年度計画の中で、情報システム部門の方針は決められていた。しかも、コンピュータは最新の技術であり、コンピュータによる業務の効率化のニーズが旺盛であったため、目的、要求を突き詰めて考える必要があまりなかった。

P社経営企画のH氏とS君は、社長の指示を受けて、ビジネスアナリシスを開始し、プログラムの承認を得るところまで来た。　プログラムの立ち上げは、プログラムマネジャーにすっかり依存していた。　事務局としては多忙ではあったが、ビジネスアナリストとしては、特に立ち上げに際して、何もすることはなかった。 プログラムの進行にともない、企画段階でも、ある程度、種々の要求は抑えたつもりだが、それだけでは、システムやプロセスの構築はできない。　再度、それぞれのプロジェクトで、要求に関して、うまくコミュニケーションし、マネジメントする必要がある。　もちろん、要求をより明確、具体的なものにして、システムやプロセスに実装してゆくために、要求アナリシスも必要だ。 これらのプロジェクトと、それぞれの各レベルの要求を、どうマネジメントしてゆこうか、H氏は途方に暮れ始めた。　情報システム部長がよく言う「上流が大切」という意

P社経営企画のH氏は、イノベーション2011プロジェクトの企画書づくりに、BABOKを参照しつつ、適当にカストマイズしている。　ソリューションの範囲の詰めを行うために、自分で作った、ソリューション・スコープのテンプレートに埋めている。サマリーとしては、添付の内容だが、これ以外にも詳細内容は作成している。 詳細内容としては、スケジュールの詳細、業務フローのたたき台、主要なデータ項目とその入手先、費用、便益も洗っている。　企画書、つまり、ビジネスケース作成に必要な情報、データは、ここで、全部あらっておかないといけない。　これは、タスクメンバーで分担したとはいえ、1週間でできる作業ではなかった。　しかし、だらだらやってもキリがない。2週間と限って、できる範囲の内容に絞った。 スコープ・サマリー例1 H氏は、ソリューションアプローチの選択として、このタスクの中で決定するかどうか迷ったが、費用につい

中堅製薬会社P社の経営企画H氏は、自称ビジネスアナリスト、社長からの乱暴な指示にもめげず、説得力ある戦略案への転換、ケイパビリティギャップの分析、ソリューションアプローチの設定など、BABOKを参考にしながら進めてきた。　ソリューション案のスコープをより具体的、詳細に定義して、祭私有的な決定まで、スピードアップを図った。 ソリューションスコープは、簡単なテンプレートを用意し、タスクメンバーである、営業部長、研究開発部長、人事部長、情報システム部長に、それぞれ、分担して、詰めることを依頼した。 ただ、ソリューションごとに、依頼したら大きすぎるので、ソリューションアプローチをそのまま、ソリューション・コンポネントと理解してもらい、コンポネントごとに、依頼した。　簡単なフレームは作ってそれに埋めてもらうことにしたが、H氏はやはり不安である。　だいぶ人によって、濃淡がでめだろうと。 依頼後、早速、

BABOKバージョン2を解説する本連載の最終回となる今回は、「基礎コンピテンシ」の知識エリアを紹介するほか、ビジネスアナリシスの資格認定制度などを紹介する。 本連載が開始された2009年夏から比べるとBABOK（Business Analysis Body Of Knowledge）に対する注目度も高くなり、さまざまなメディアで目にすることが多くなってきました。 さて、最終回の今回は、本連載で紹介する最後の知識エリア（Knowledge Area）である「基礎コンピテンシ」とビジネスアナリシスに関わる資格認定について、ご紹介したいと思います。 ビジネスアナリストが備えるべき能力「基礎コンピテンシ」 これまで紹介してきたとおり、BABOKではビジネスアナリシスを遂行するために重要な諸活動を、「知識エリア」として定義しています。ただし、ビジネスアナリシスは広い知識や経験を必要とする活動であるた

ソリューション・アプローチとして、いくつかの候補案がある。　しかし、これらの候補案を、たとえば全て実施したら目標は達成されるのだろうか。　それとも、どれかの候補案で実現可能なのだろうか。　また、これらの候補案は、そもそもＰ社の戦略に適っているのだろうか。 Ｈ氏は、経営陣に戦略を作ってと求めることはしない。　それは、経営企画として求めるものではなく、自ら創り出して、最終的な選択と決定のみを経営に求めたいと考えているからだ。　もちろん、経営主導で出された戦略を具体化することも自分の仕事である。　しかし、ビジネス・アナリストにそこまで期待するのはむずかしかろうとも、考えている。 一般に経営戦略、事業戦略と簡単に言うが、どちらもそんなに簡単にでてくるものではない。　当社の戦略はこれこれだ、などとは、あまり言わないものだ。　戦略と言う言葉を使うのは、外に説明するとき、或は、外から説明されるときで、Ｐ

自称ビジネス・アナリストのH氏は、課題の一覧、ミニ要求ワークショップ、そして、ビジネスニーズから、なんとか、ソリューションおよびアプローチ案をまとめた。　期間と費用の見積もりは、それぞれオーナーと思しき部長から、えいやっとした数字をもらった。　もうすこし、詳細に検討しないと、ソリューションの選択は上にあげられない。 それぞれのソリューションアプローチについて、費用だけでなく、さらに詳細に、詰めるべく、担当を分けた。　そして、ソリューションスコープをどらふとしてもらうこととした。 トップダウンに慣れていれば、このあたりで、かなり絞って、その結果をつめるのだが、P社の社風か、H氏の性格か、はたまた日本企業の特徴か、ぎりぎりまで絞らずに、選択肢を多く保っている。　案外、BABOKのソリューション・アプローチの考え方も、それほど遠くないかもしれない。 さて、 BABOKでは、アプローチモモスコープ

H氏は、ビジネス・アナリシスの肝として、このケイパビリティ・ギャップをとらえている。　ビジネス・アナリシス、或は、BABOKについて、要求開発・要求アナリシスに力点をおく人が最近多いが、そうではなく、H氏は、ここがポイントだと思っている。 ポイントは、ビジネス・ニーズを実現するために、組織にどういう”能力”が必要か挙げること。　”能力”、ケイパビリティには、いろいろな側面、つまり、○○についての能力、という内容・種類がある。　BABOKでも、ビジネスプロセス、機能、LOB、組織構造、スタッフのコンピテンシー、知識、スキル、トレーニング、施設、システム、インフラ、ツール・・など、挙げられている。 このやり方では、網羅的に見るには良いが、かなり発散してしまい、同じような内容の項目がいろいろなところに出てきて煩雑になってしまう。 "ビジネス・ニーズを実現するため" といっても、"ビジネス・ニーズ