Comments
Description
Transcript
ビジネスアナリスト : 将来極めて重要となる IT の役割
ビジネスアナリスト : 将来極めて重要となる IT の役割 要約 変化が当たり前のことになり、熾烈な競争が推進力に なっている現在、無駄のない思考が求められています。 情報技術（IT）はやっと真価を認められ、今ではコスト の浪費ではなく、価値をもたらすものと見なされていま す。またリスクの高まりとともに、IT 組織はさまざまな プレッシャーにさらされるようになっています。たとえ ば、増収、コスト削減、節税、生産性向上、従業員の退 職率の低下、リスク低減などです。企業にとっての競争 優位性は、素早く IT ソリューションを配置できる能力と、 ビジネスニーズの進化に応じてシステムを変更する能力 に直結しています。IT プロジェクトは、高品質のプロダ クトを迅速かつ低コストで引き渡す（従来のプロジェク トマネージャの責任）だけでなく、収益にプラスの影響 を与えることができるよう（プロジェクトマネージャ、 プロジェクトスポンサ、ビジネスアナリストの連帯責任）、 厳しく監視されます。 はじめに プロジェクトは、今日の組織の成長と存続に欠かせ ません。プロジェクトを通じて、ビジネス環境の変 化に応じたビジネスプロセスの改善やプロダクト/ サービスの新規開発を行い、価値を創出することが できます。データと情報は、ほぼすべてのビジネス プラクティスに欠かせないため、IT プロジェクトは 多くの場合、組織のビジョンと戦略を実現するため の主要なメカニズムとなります。経営陣は IT ポート フォリオに目を向け、自らが（1）正しい組み合わせ のプロジェクトに投資し、（2）リソースを最適化し、 （3）完璧な引き渡しが可能となる専門能力を開発し、 （4）期待されるビジネスの付加価値を把握している ことを確認します。新たな IT プロダクトやサービス に対する需要はとどまることを知らないように思わ れるため、各層の経営陣は IT プロジェクトがビジネ スにもたらす価値を増大させるために、優れたビジ ネスアナリシスのプラクティスを採用しようとして います。プロジェクトマネージャと技術者の才能、 能力、決断力だけでは、組織に価値をもたらすこと はできません。ビジネスニーズと目標を、企業に富 をもたらす革新的なソリューションに変換するため には、ビジネスコミュニティと技術コミュニティの 連絡を強化する必要があります。 プロジェクトパフォーマンス パートナーシップ IT プロジェクトが社内で行われるかアウトソースさ れるか、COTS（既製品）を購入するかカスタマイズ するか、あるいは複雑なシステム統合であるか否かに かかわらず、すべての IT プロジェクトには特別な要 求管理が必要です。コスト効果が高い、最適な革新的 ソリューションを決定するため、ビジネスアナリスト は、パフォーマンスの高いチームを目指して、専門知 識を持ったプロジェクトマネージャや、最も優れた開 発者、洞察力のあるビジネス関係者と連携します。こ のようなコアチームが形成されると、世界の偉大な チーム（例 : タイガーチーム、特殊作戦チーム、プロ スポーツチーム、パラメトリックチーム）に匹敵する ような、プロジェクトパフォーマンスパートナーシッ プが出現します。チームの中心には、プロジェクトマ ネージャとビジネスアナリストという行動的な 2 名 の人物が据えられます。1 名はプロジェクトの管理に 気を配り、もう 1 名はビジネス要求の管理に集中し ます。賢明なプロジェクトマネージャであれば、この ようなチーム構成の傾向を歓迎するはずです。要求に 関する情報が不十分だと見積もりが不完全になり、時 間とコストの管理が実質的に不可能になるということ を理解しているからです。 不十分な要求に直接起因しているからです（The Standish Group、1998）。ビジネスニーズを理解す ることによって、引き渡されるソリューションがそ のニーズを満たし、確実に収益に価値をもたらすた めに、システム要求ライフサイクル全体を管理する のがビジネスアナリストです。当然のことながらビ ジネスアナリストは、単に要求フェーズだけでなく、 ビジネスソリューション開発ライフサイクル全体を 通じて重要な役割を果たします（このホワイトペー パーの最終ページの図3「ビジネスソリューションラ イフサイクルとシステム要求ライフサイクルの対応」 を参照）。 技術チームは、ビジネスアナリストのリーダーシッ プを通じて、ソリューションの設計/実装の前に要求 を把握して完全に理解します。ビジネスアナリスト は、プロジェクトライフサイクル全体を通して、ビ ジネスコミュニティと技術ソリューションプロバイ ダの間の連絡係として機能します。プロジェクトの 規模が拡大し、複数の部門にまたがったり、グロー バルになったり、複雑化するにつれて、組織は要求 管理のスキルが必須であるということに気づきます。 現在、IT 開発をアウトソーシングする傾向が強まっ ているため、IT 環境におけるビジネスアナリストの 役割はさらに重要になっています。 プロのビジネスアナリストに なる 広範囲に及ぶイノベーション、最先端の技術、急成 長を続ける IT 専門職などについて耳にするとき、 アーキテクチャと開発に関する優れた能力という点 だけを考えていないでしょうか。技術的スキルをア ウトソースするのは比較的容易ですが、ビジネス要 求の管理を他人に任せることはできません。ほぼす べての組織において、ビジネスアナリストという極 めて重要なリーダーシップの役割が、IT の将来を左 右し始めています。瞬きしている間に、一世一代の IT の好機を見逃してしまうかもしれません。 重要な IT プロジェクトのポートフォリオが経営陣に よって作成されると、プロジェクトを完璧に遂行し、 組織にもたらされる価値を最大化することに焦点が 移ります。しかし多くの場合、IT プロジェクトの成 功は難しいものです。プロジェクトは遅延し、予算 を超過し、引き渡しさえできない場合もあります。 また、作業が不完全であったり、要求や期待を満た していなかったり、投資に対して組織が期待した利 益や見返りを得られないといったことも起こりえま す。このような惨たんたる実績に甘んじることは、 もはやできません。 引き渡しのパフォーマンスを改善してビジネスの期待 を満たすために、経営陣はどのような組織的能力を構 ビジネスアナリストが、将来の中心的な IT 能力とし 築する必要があるでしょうか。プロジェクトを成功さ て浮上している理由は何でしょうか。IT システム工 せるためには、次のような能力が欠かせません。 学において要求は重要な役割を果たしており、プロ ジェクトが失敗する上位 8 つの理由のうちの 5 つは、 3 ビジネスアナリストが、将来の中心的な IT 能力として浮上 している理由は何でしょうか。ビジネスニーズを理解する ことによって、引き渡されるソリューションがそのニーズ を満たし、確実に収益に価値をもたらすために、システム 要求ライフサイクル全体を管理するのがビジネスアナリス トです。 • ターゲットを絞った効果的なプロジェクトマネジメ ントと、システム工学のプロセス、ツール、手法 • 主要なコントロールゲートにおける経営陣の適切な 意思決定 • 特別なプロジェクトリーダーシップと高パフォーマ ンスのチーム • ビジネスコミュニティと IT コミュニティの間の共 同作業と敬意 • 顧客のビジネスニーズおよび情報ニーズ全体を開発 チームに明確に把握させるための、ビジネスアナリ シスプロターゲットを絞った効果的なプロジェクト マネジメントと、システム工学のプロセス、ツール、 手法 ビジネスコミュニティと技術コミュニティの橋渡しが できる優れたビジネスアナリストは、どこにいるので しょうか。プロジェクトマネジメントの分野が戦略的 なビジネスプラクティスへと成熟を遂げているため、 ビジネスアナリストも戦略的な変革リーダへと進化す る必要があります。 本物のビジネスアナリスト とは 通常、ビジネスアナリストにとって、プロジェクトの 技術領域に関する専門知識は必須となります。この場 合、ビジネスアナリシスは技術分野の一部として扱わ れます。プロジェクトが繰り返し困難に遭遇するのは、 技術的な専門知識の欠如によるものではなく、ビジネ ス要求を収集、理解、分析、管理し、有用なシステム 仕様書に変換できないことに起因します。IT チーム のメンバがビジネスニーズを明確に理解する前にプロ ジェクトが開始されてしまうケースは多く、ソリュー ションの設計と構築も先に進められてしまいます。多 くの場合、技術的な不具合はなかなか許容されず、変 化を続ける不十分な要求には寛大であるという傾向が あります。たいていは、「とりあえずコーディングを 始めてみて、どうなるか見てみよう」という風潮によ り、IT プロジェクトは要求のクリープに見舞われま す。アジャイル開発を行う際にはこの手法が適してい る場合もありますが、複雑なビジネスシステムの構想 においては不十分です。 ビジネス要求分析は、ビジネスにもたらされる価値 の向上だけを重視するという点で、従来の情報シス テム分析とは異なります。特にプロジェクトマネー ジャは、プロジェクトの詳細な目標の提示、ビジネ スニーズ分析、構造化された明確かつ有用な要求、 トレードオフ分析、要求実現可能性およびリスク分 析、費用便益分析の支援において、ビジネスアナリ ストに依存します。ビジネス部門と IT 部門間の主要 な連絡係がいないと、要求定義が不十分になり、結 果として IT 部門の構築物と、ビジネス部門が必要と するものの間に断絶が生じます。 この問題に対処するため、技術的に熟練したエンジ ニアが、プロジェクトマネジメントとビジネスアナ リシスの分野に移行することを求められます。この ようにして、技術リーダ、プロジェクトマネージャ、 およビジネスアナリストが、プロジェクトにおける 3 つのリーダーシップの役割を引き受けます。高レベ ルな要求を把握し、プロジェクト計画が開始された 後は、必然的に技術的アクティビティに注意の大半 が注がれがちです。このような場合、要求管理やプ ロジェクトマネジメントが困難になり、イニシア ティブは手におえない状態になってしまいます。 アナリストからプロジェクト リーダへ 技術的な知識は必要ではあるものの、現在一般的と なっている、企業規模の複雑かつミッションクリ ティカルなプロジェクトにおいては、技術的な知識 分野だけでは要求管理を成功させることができない という事実が次第に明らかになっています。ビジネ スリーダが多方面に熟練しつつ戦略的な焦点を絞ら 4 図1 ビジネスアナリストの知識/ スキルに関する要求 技術 分析 ビジネス リーダーシップ システム工学のコンセプトと 原則 ビジネスアナリシスの基礎 ビジネスプロセスの改善と リエンジニアリング プロジェクトマネジメントの 基礎 複雑なモデル化手法 コンセプト立案能力と創造的思 考力 ビジネスに関する戦略計画立案 ビジョンを明確に表現する能力 非技術系ユーザへの技術的 コンセプトの伝達 要求を計画、文書化、分析、 追跡、管理する手法 技術系ユーザへのビジネス コンセプトの伝達 組織変更管理、権限と組織内 政治の管理 テスト、検証、妥当性確認 要求リスクの評価と管理 ビジネス成果の考慮 問題解決、交渉、意思決定 技術文書作成 管理、分析、報告のスキル ビジネス文書作成 チームの管理、リーダーシップ、 指導教育、円滑化 ラピッドプロトタイピング 費用便益分析 ビジネスケース開発 信頼性、倫理観、誠実さ 技術ドメインの知識 時間管理と自己管理 ビジネスドメインの知識 顧客関係管理 なければならないのと同様に、ビジネスアナリスト には広範なリーダーシップのスキルが必要です。ビ ジネスアナリストは今やリーダの役割を担っていて、 企業においては短期間で上級職へと昇進しています （ビジネスユニットでも IT ユニットでも同様）。IT 部 門の役割が効率からビジネスにおける有効性に移行 している現在、"バイリンガル"、つまりビジネス用語 と技術用語の両方を使用できるビジネスアナリスト は、プロジェクトチームの中心的存在となりつつあ ります。この極めて重要な役割を果たすためには、 ビジネスアナリストは広範な知識とスキルを持って いる必要があります。 Monster.com に掲載されていた、5000 件以上の ビジネスアナリストの求人を総合すると、次のよう な職務として規定されていることが明らかになりま した。 「この役割の主な目的は、ビジネス要求を満たす革新 的なソリューションを設計して仕様を定め、ビジネ ス上の利益を獲得できるようにするとともに、シス テムアナリストチーム内の標準と品質に関する期待 について、部門間のコミュニケーションと認識を促 進することにあります」。 ビジネスアナリストの他にも、ビジネスシステムア ナリスト、ビジネスシステムプランナ、主席ソ リューションアーキテクトなどの多くの職種も特定 されています。肩書きに関わらず、IT プロジェクト を成功させるためには、有能で経験豊かなビジネス アナリストは必須です。簡単に言えば、十分な理解 のもとに文書化された要求のベースラインがなけれ ば、プロジェクトの目標を達成することはほぼ不可 能です。ベースラインとは、プロジェクトチームが 特定のリリースで実装を約束した、機能要求および 補足要求の集まりです（Wiegers、2003）。IT 組織 において、プロジェクトのパフォーマンスを改善す るためにリソースと予算を投入できるのが単一のラ イフサイクル領域のみである場合、要求定義/管理領 域に投入すべきであると言われています。組織にお ける責任と地位のレベルに応じて、ビジネスアナリ ストは以下のような義務を担います。 • ビジネス上の課題と、提案したソリューションが組 織の運用に与える影響を識別し、理解する • 分析とモデル化の統合的な手法によって、プロジェ クトスコープ、目標、付加価値、利益に関する期待 といった複雑な領域を文書化する • 分析とモデル化の強力なツールを使って、ビジネス の目標をシステム要求へと変換させる • 顧客のビジネスニーズを評価して、情報システム/ 技術の方向性に関する戦略計画立案に貢献する • 組織の戦略的方向性の決定を支援する • 新しいプロダクト/サービスの予備的なインストー ルおよびテスト期間において、主要な顧客との連絡 係となる • 高品質なビジネスソリューションを設計/開発する ビジネスアナリストは、ビジネスの世界においては 短期間で比較的高い地位に昇進しますが、従来はそ れは中∼低レベルの役割と考えられてきました。最 近のアンケート調査により、広範なビジネスアナリ シス機能を実行できる上位の人員に対して、需要が ますます高まってきていることがわかりました。ビ ジネスアナリストはビジネスと IT の両方に関係する ため、さまざまな分野の出身者がビジネスアナリス トになっています。プログラマ/アナリスト出身者も いれば、IT トレーニングを受けた従来型のビジネス 専門家もいます。ビジネスアナリストの役割を果た すためには、技術的スキル、分析的スキル、ビジネ ススキル、リーダーシップスキルという独特の組み 合わせのスキルを使いこなす必要があります（図 1 「ビジネスアナリストの知識/スキルに関する要求」 を参照）。 5 ビジネスアナリシスの実際 要求の検出と定義においては、要求は非常に高いレ ベルで決定され、文書化されます。要求収集プロセ スでは、特定のプロダクトの選択にこだわることな く、ソリューションについて研究します。要求定義 は、ユーザ、顧客、ステークホルダ、開発者の共同 作業として実施すると最も効果的です（Hadden、 2003）。要求の定義、分析、文書化は極めて創造的 かつ反復的なプロセスであり、システムがどのよう に動作するかではなく、システムが何をするのかを 示すために存在します。したがって、文章と図式で 表現した要求はシステムのモデルを表し、ビジネス ニーズとソリューション設計の間の中間ステップと して機能します。 要求開発プロセスは通常、ビジネスニーズ特定、ス コープ定義、引き出し、分析、仕様作成、文書化、 妥当性確認、管理、保守、機能強化からなります。 こうした下位分野には、要求の収集、評価、文書化 に関連するすべてのアクティビティが含まれていま 。 す（Young、2001） ビジネスニーズ 構想を選択するときに、プロジェクトスポンサとプ ロジェクトマネージャが新しいプログラムおよびそ れをサポートするプロジェクトに割り当てられます。 このプロジェクト前分析は、戦略目標の達成に最も 適したソリューションを決定するために必要です。 アクティビティには、ビジネスニーズの詳細分析、 実現可能性調査、ソリューションのトレードオフ分 析、高レベルのビジネス要求の開発が含まれます。 これらの分析の結果は多くの場合、実現可能性調査、 ベンチマーク調査、競合分析レポート、ニーズ分析、 高レベルのビジネス要求の記述書に収められます。 ビジネスドメインのスコープ定義 最初の要求定義は、通常、プロダクト記述書を作成 するプロジェクトの初期フェーズで行い、可能であ れば、立ち上げ時に作成するビジネスケース、プロ ジェクト憲章、または作業範囲記述書に内容を盛り 込みます。要求はすべて、これらの要求元まで追跡 できなければなりません。要求引き出しの前に、ビ ジネスアナリストとプロジェクトマネージャが協力 して、次のアクティビティに関する最初の計画立案 とスコープ設定を行います : （1）顧客、ユーザ、ス テークホルダのニーズと環境に関する観点を得る、 （2）ビジネスケース、プロジェクト憲章、作業範囲 記述書（または類似のスコープ定義書）をレビュー するか、存在しない場合は作成する、（3）新規シス テムやシステムの変更に関するビジネスのビジョン、 推進要因、目標、目的を理解する、（4）主要なビジ ネスおよび技術のステークホルダからなる要求チー ムを作り、教育する、（5）プロジェクトのスコープ を理解して文書化する、（6）作成する文書とモデル を定義し、要求管理計画の策定を開始する、（7）要 求のアクティビティ、成果物、スケジュールの チェックリストを定義/改良する、（8）ライフサイク ル全体を通じた変更を計画する。 要求の引き出しと検出 プロジェクトの最初の段階では、要求は不明確であ るのが通例です。段階的詳細化のプロセスを経て、 要求は成熟していきます。要求引き出しでは、顧客、 ユーザ、ステークホルダと共に最初の要求収集セッ ションを実施し、文書化プロセスを開始します。要 求の収集手法には、検出セッション、インタビュー、 アンケート調査、プロトタイピング、既存のシステ ムおよびビジネス文書のレビュー、および顧客、 ユーザ、ステークホルダからの情報収集とフィード バックループなどがあります。 ビジネス要求は、システムによってサポートしなけ ればならない、企業の最も重要なアクティビティで す。ビジネス要求は、ビジネス目標に由来します。 ビジネス要求を把握する方法として効果的なのが、 ビジネスシナリオの作成です。システムがどの程度 ビジネス要求を満たし、組織のビジネス目標達成を 促進するかが、開発後のシステムの価値を決定付け る重要成功要因です。引き出しと検出のアクティビ ティには次のようなものがあります。 • 要求収集プロセスにだれが関わるべきかを決定する ために、顧客、ユーザ、ステークホルダを特定する • 組織の目標のサポートに欠かせないユーザタスクを 特定するために、ビジネス目標/目的を理解する • 優れたシステムはビジネス要求を満たし、組織の目 標達成を促進する • ユーザ、顧客、ステークホルダのニーズを理解する ために、要求を特定して定義する。顧客、ビジネス ユーザ、ステークホルダから見ると、これはター ゲットシステムに対するビジネス要求を把握するア クティビティとなる。ビジネス要求とは、企業に とって、組織の目的を満たすために実行しなければ ならない重要なアクティビティであり、ソリュー ションからは独立した関係にある。ビジネスシナリ オ（使用シナリオとも呼称される）は、ビジネス要 求を確実に理解するための手法として使われる場合 も多い • ビジネス要求記述書と要求管理計画は、このアク ティビティの主要なアウトプットとなる 要求分析 要求は、最初は簡単な言葉で表されますが、次の段 階では、これを分析および分解して具体化していき ます。要求分析は、要求情報の分類、目標品質に関 する要求の評価、各種形式による要求の表現、高レ ベルから詳細レベルへの要求の細分化、優先度の交 渉などのプロセスです。さらに、要求分析には、必 要な機能特性およびパフォーマンス特性、実装環境、 ステークホルダによる制約、効果測定方法や妥当性 確認基準などを決定するアクティビティが含まれま す。分析プロセスでは、要求を分解し、文章と図の 6 組み合わせで表現します。分析は、要求と設計との 妥協点を表します（Ambler、2005）。分析アクティ ビティは次のとおりです。 • 要求が、技術面、運用面、経済面で実行可能かどう かを決定するために、要求の実行可能性を調査する • 実行可能性の最も高い要求の代替案を決定するため に、要求のトレードオフ分析を行う • 要求のリスクと制約を分析し、特定したリスクを軽 減するために要求を修正することによって、要求の 実行可能性を評価する。この目標は、初期の妥当性 確認プロトタイピング手法を通じて要求リスクを軽 減することにある • 要求をモデル化し、再記述や明確化を行う。モデル 化は、適切な使用、プロセス、詳細構造の各レベル で実行する • ビジネスニーズが新たに判明したら、追加要求を導 出する • すべての要求がビジネスに等しい価値をもたらすわ けではないということを考慮して、要求の優先度設 定を行う。優先度設定は、"緊急"、"高"、"中"、"低" といった区分を使用する。優先度が最も高い機能を 最初に提供するために必要となる、作業/予算/時間 レベルを決定する際には、優先度設定は必須となる。 優先度の低いニーズは、その後のシステムリリース でも対処できる 要求仕様作成 要求仕様作成では、要求を詳細化し、構造化するこ とにより、属性がすべて設定された要求リポジトリ を作成します。この段階的詳細化プロセスで、要求 チームは定義が十分に詳細でない分野を見つけるこ とがよくあります。この分野の対処を怠ると、シス テム要求が無秩序に変更される可能性があります。 仕様作成アクティビティでは、各要求を正確に表す すべての属性を特定します。このプロセスによって、 各品質属性の相対的な重要性を把握できます。要求 分析プロセスのアウトプットは、システム仕様書ま たはシステム仕様データベースです。 属性は、説明、選択、フィルタリング、妥当性確認 など、さまざまな目的で使用します。さらに、属性 を使用すると、データをオブジェクト、テーブル マーカ、テーブルのセル、モジュール、プロジェク トに関連付けることができます（Stevens、Brook、 Jackson、Arnold、1998）。属性は、ユーザが定義 するものでも、システムが定義するものでもかまい ません。要求チームは、属性を使用することで、情 報を要求の個別のグループまたは関連するグループ に関連付けることができるため、一般に、フィルタ リングやソート処理を使って要求分析プロセスを簡 略化することができます。要求に対する典型的な属 性は、次のとおりです。 • 一意の識別子 : これは変更されることはありませ ん。要求が移動、変更、削除されても、参照番号は 再利用されません。 • 受け入れ基準 : 要求が満たされたということを顧 客、エンドユーザ、ステークホルダに対して提示す る、テストの特性を記述します。受け入れ基準は通 常、「この要求が満たされたと納得するには、どの ような評価が必要か」という質問をエンドユーザに 行うことによって把握します。 • 作者 : 要求の記述者。 • 複雑性 : 要求の実現がどの程度困難であるかを表し ます。 • オーナーシップ : 当該要求を必要とする個人やグ ループを指定します。 • パフォーマンス : 要求の適合度合いを表します。 • 要求の優先度 : ある時点における要求の相対的な重 要性を表します。 • 要求元 : 要求の起案者を特定します。要求はすべて、 定義する権限を持った要求元から発せられます。 • 安定性 : 要求の成熟度を示します。作業を開始でき る程度まで要求が確実かどうかを判断するために使 用されます。 • 要求のステータス : 提案済み、承認済み、ユーザと の検証済み、実装済みのうち、要求がどの段階にあ るかを表します。 • 緊急性 : 要求の必要性の緊急度を表します。 要求の文書化 要求記述書は、事実上プロジェクトの全員が使用する ため、明確かつ簡潔であることが必要です。要求の中 には、法務要求、安全性要求、セキュリティ要求のよ うに、専門用語を使用して正式な形で表さなければな らないものがあります。よりわかりやすい要求に戻す のであれば、これは許容の範囲内です。しかし、大部 分のシステム要求は、文書化するときにできるだけ専 門用語を避けるべきです。図を使用すると、構造や関 係を文章よりもわかりやすく表現できます。一方、概 念を正確に定義するには、明確な文章のほうが図より も適しています。したがって、システム要求を完全な 形で表すには、文章表現と視覚表現のどちらも不可欠 です。視覚的に表した要求を文章に変換すると、技術 部門以外のチームメンバにとって、よりわかりやすく なります。これは、システムライフサイクルの中で、 重複が望ましい数少ないケースの一例です。 要求は、要求元と適用性に応じていくつかのタイプに 分類されます。要求のタイプを理解すると、要求を分 析して優先度設定を行う際に役立ちます。要求の中に は必須のものもあれば、必須ではないものもあります。 また、要求のタイプを理解することによって、技術 チームがトレードオフ分析を行い、システムのコスト とスケジュールを見積もり、期待される変更のレベル をより効果的に評価できるようになります。最後に、 要求のタイプのリストをレビューすることで、ビジネ スアナリストはさらなる調査が必要な領域を特定する ことができます。要求は通常、大きく分けて機能要求 または補足要求（機能外要求とも呼称される）に分類 されます。 7 多くの場合、効果的に管理された IT プロジェ クト要求にも、致命的な欠陥があります。要 求が一度定義されたら、ビジネスソリュー ションライフサイクルを通じて要求変更を管 理する必要があります。 • 機能要求にはシステムが遂行できる能力を振る舞い または動作（特定のシステムアクション、応答）の 観点で記述する。機能要求の最もよい表現は動詞を 使用した表現であり、ソリューションが不必要に制 約を受けないように文書化する。それによって、シ 認します。要求の妥当性確認によく使用される分析 手法は、プロトタイピングです。 要求管理 • 補足要求は、物理的特性、パフォーマンス特性を規 プロジェクトの主要なコントロールゲートレビュー は、要求フェーズを終えて要求管理へ移行する際に 行います。正式なコントロールゲートレビューセッ ションでは、レビューおよび承認の対象となる要求 け入れ可能なソリューションオプションが制限され る。制約には、あらかじめ決められた言語やデータ の継続的投資を行うかどうかの決定に必要となる重 要な情報を提供するために、プロジェクトのスケ る。さらに、リソース利用、メッセージサイズやタ ジネスケースが再び取り上げられます。継続の承認 ド/データ要素の最大数/最大長などの制限も含まれ ベースライン化し、正式な要求変更コントロールプ ステムアーキテクチャに対する堅固な基盤が提供さ れる 定し、システム能力の制約となる。制約により、受 の提示が含まれます。この時点で、プロジェクトへ ベースの使用、特定のハードウェアの使用などがあ ジュール、コスト、スコープ見積りが更新され、ビ イミング、ソフトウェアサイズ、ファイル/レコー が確保できた場合は、ビジネスアナリストは要求を る。ビジネス制約には、予算的制限、作業人員、利 用できるスキルセットなどの制約が含まれる。技術 的制約には、システムが準拠すべきエンタープライ ズアーキテクチャの標準が含まれる ロセスを導入し、ソリューション設計作業を支援す 文書化アクティビティでは、すべてのステークホル ダが理解できる用語を使用して、収集した要求を要 求仕様書および要求モデルに文書化します。通常、 要求文書化には、かなりの時間と労力を費やします。 これは、各ステークホルダによって、要求に関する 専門知識、視点、および期待が異なる可能性がある ためです。 要求の妥当性確認 要求の妥当性確認は、要求記述書、モデル、属性を 評価するプロセスであり、これらがビジネスニーズ を満たし、技術チームがシステム設計およびシステ ム開発を開始するのに十分な完全性を持つかどうか を判断します。要求全体を当初のドキュメント（ビ ジネスケース、プロジェクト憲章、作業範囲記述書） と比較し、完全性を確認します。完全性の確認の他 にも、妥当性確認アクティビティでは、要求を評価 して、システム開発に追加資金が投入される前に、 要求に関連する設計リスクが最小限であることを確 る要求管理アクティビティへと移行します。 要求管理の責任は誰が負うのでしょうか。多くの場 合、効果的に管理された IT プロジェクト要求にも、 致命的な欠陥があります。要求が一度定義されたら、 ビジネスソリューションライフサイクルを通じて要 求変更を管理する必要があります。要求の管理に加 えて、プロダクトスコープとプロジェクトスコープ の間の相互関係を理解し、管理しなければなりませ ん。たとえば、定型的なプロジェクトでは文書化と 分析の必要性はかなり低いものの、重要なプロジェ クトでは多くの場合、正式かつ綿密で時間のかかる スコープ設定アクティビティが必要となります。ビ ジネスアナリストとプロジェクトマネージャは協力 して、プロダクトスコープとプロジェクトスコープ を定義/管理します。要求管理アクティビティは、次 のとおりです。 • 要求の割り当て（分割） : システムの各サブシステム またはサブコンポーネントに要求を割り当てます。 ハードウェア、ソフトウェア、手作業、トレーニング など、システムアーキテクチャで定義されたコンポー ネントには、トップレベルの要求を割り当てます。 8 • システム設計/開発期間を通しての要求の追跡 : 各 はそうでなくなる場合があります。 要求がシステムのどこで実現されているかを追跡し ます。要求を設計書に変換するとき、関連するビジ ネスニーズを満たすことができるように、要求記述 書、モデル、仕様書、設計書が厳密に関連していな ければなりません。 • IT システム開発におけるすべてのものは、要求に • システムの変更と機能強化の管理 : 要求の管理で ため、評価が困難である : IT システムの特性は無形 であるため、真の価値を予測することは困難です。 は、プロジェクトの全フェーズを通して、要求の追 加、削除、変更を実行できます。 • ビジネスアナリストは、プロジェクト全体を通して、 要求の妥当性確認と検証を継続的に促進します。検 証と妥当性確認を行うのは、システムが要求だけで なく、その要求が課した仕様や条件を満たすように するためです。 • 要求の妥当性確認 : ユーザ参加型のテスト、デモ、 インスペクション手法によって、設計されたソ リューションが要求を満たすことを証明します。最 後に行う妥当性確認は、ビジネスアナリスト主導で 行われるユーザ受け入れテストです。 • 要求の検証 : テスト、インスペクション、デモ、分 析によって、設計されたソリューションが要求仕様 を満たすことを証明します。 依存している : 要求は通常は固定的ではないという 仮定からも、ベースライン計画は変更される可能性 があるということがわかります。 • IT プロジェクトは基本的に研究/開発の活動である 要求の定義および管理の難しさを認識し、ビジネス アナリシスのプラクティスについて記述すると同時 に、アジャイル開発、要求生成/システム開発（特に ソフトウェアに重点を置いたシステム）の反復的特 性、スケーラビリティ要素という 3 つの付加的なコ ンセプトを検討する必要があります。 アジャイル開発 ここ数年、アジャイル（"ライトウェイト" とも呼ば れる）手法への関心が急速に高まっています。IT 開 発からわずらわしいお役所仕事的な作業を排除する アプローチ（Fowler、2003）、またはハッキングの ライセンスなどとも呼ばれるアジャイル手法は、IT 業界全体から関心を集めています。 IT ソリューションを引き渡し、稼働すればビジネス アナリストの仕事が終わるわけではありません。ビ ジネスアナリストは、引き続き、次の領域で重要な 責任を担います（Mooz、Forsberg、Cotterman、 2003） 。 アジャイル手法で重視されるポイントは、伝統的な 重々しい工学手法とは大幅に異なります。最も顕著 な違いは、文書指向が弱まっていることであり、通 常はタスクの文書量が少ないことが重視されます。 また多くの場合、アジャイル手法は文書の主要部分 としてソースコードに注目します。さらに、次のよ うな 2 つの基本的な違いがあります。 • 保守 : IT システムの欠陥を予防し、修正するために • アジャイル手法は計画重視型ではなく、適応性に優 システムの保守と機能強化 提供するサービス。 • 機能強化 : システムがビジネスにもたらす価値を高 めるための変更。 • 運用および保守 : ビジネスのためにシステムを運用/ 保守するフェーズ。このフェーズで作成する文書に は、システム妥当性確認手順書、システム妥当性確 認レポート、保守レポート、年次運用レポート、運 用停止計画書、運用停止手順書があります。ビジネ スアナリストは、システムの機能強化の管理や、シ ステムの入れ替え時期、つまり運用停止時期の決定 において大きな役割を果たします。 要求工学に関する検討事項 控えめに言っても、要求工学はリスクが高く困難な 作業です。要求の開発前に明確な全体像を把握して、 要求に対する顧客の承認を獲得し、承認後の要求変 更を制限する手順を設定するのが理想的です。しか し、要求工学において注意を払っても、要求は次の ような状況によって変化していきます。 • ビジネス環境が動的である : 今日の経済では、基礎 となるビジネスの原動力に応じて、システムフィー チャの価値が急速に変化してしまいます。現時点で は優れた要求であっても、数か月または 1 年後に れている : 工学手法では、ソリューションの大部分 を非常に詳細に立案し、プロジェクトを通して変更 を管理します。アジャイル手法は、変更に適応し、 進化していきます。 • アジャイル手法はプロセス指向ではなく、人間指向 である : 工学手法の目標は、再現可能で開発チーム に依存しないプロセスを定義することにあります。 一方、アジャイル手法では、開発チームのスキルに 焦点をあて、チームの作業をプロセスによって厳密 にサポートします。 アジャイル分析では、ビジネスアナリストがプロ ジェクトチームのコミュニケーション指導者/コーチ になることが求められます。このためには、プロ ジェクトライフサイクル全体を通じたステークホル ダのアクティブな参加という、アジャイル開発の信 条の 1 つが守られなければなりません。顧客が望む ものを見つけ出そうとする試みから、顧客が望み、 かつ必要としているものを特定できるよう支援する ことへと焦点が移ります。ビジネスと開発のチーム を同じ場所に設置することで、ステークホルダのア クティブな参加が可能になります。しかしビジネス コミュニティは、フルタイムで開発チームと協力で きるように、重要なリソースを自由に解放できるわ けではありません。この場合、ビジネスアナリスト 9 は、ビジネスコミュニティの環境でインタビューと ワークショップを行い、開発チームの主要メンバが 「顧客の声」を聞けるようにします。 アジャイル分析とは何でしょうか。ビジネスアナリ ストは、次の特性を取り入れながら、上述したプラ クティスを実施します（Ambler、2005） 。 • 豊かなコミュニケーション : 分析では豊かなコミュ ニケーションが行われ、文書や電子メールを介した 対面会合や遠隔会議が重視されます。 • 高い反復性 : アジャイル分析は反復性が高く、分析 と設計のアクティビティは相互に依存し、実際には 反復を経て成熟していきます。見積もりは分析の一 部であるため、ソリューション設計について何も知 らずにソリューションのコストを見積もることは不 可能です。 • 絶え間ないフィードバック : アジャイル分析は非常 に段階的であるため、開発への追加投資を決定する 前に、顧客のフィードバックに応じてソリューショ ンのコンポーネントを実装できます。したがって、 要求の段階的な見積もりと優先度設定が必須になり ます。このアプローチによって、顧客側ではトレー ドオフ分析と重要な意思決定が促進されます。 • 過不足がない : アジャイル分析は、程々がよいとい う前提に従っています。ちょうどよい、適度な厳密 さが適用されます。 Ambler は、アジャイル分析を次のように定義してい ます。 「アジャイル分析は極めて反復的かつ段階的なプロセ スであり、ドメインを理解し、構築する必要のある ものを特定し、その機能を見積もり、機能の優先度 設定を行うため、開発者とプロジェクトのステーク ホルダが活発に共同作業を行う。このプロセスでは、 かろうじて合格というアーティファクトを随時作成 する」。 では、アジャイル手法はいつ使うのが適切でしょうか （Fowler、2003） 。現在のところ、次の条件が満たされ た場合に使用すべきだと考えられています。このうち 1 つまたは複数の条件が欠けている場合は、アジャイ ルアプローチ適用にはリスクが伴う可能性があります。 • さらに厳密な手法への移行 : 「コードを作成しては 修正する」という方法に従っている場合、アジャイ ル手法を利用することによってプロセスにいくらか の秩序が適用されます。アジャイル手法では、より 厳密な手法に比べて、気軽に実施できるという利点 があります。アジャイル手法の利点の多くは、軽量 であることに由来しています。過去にプロセスを採 用したことがほとんどない場合、より簡単なプロセ スが採用されがちです。 • コアチームが小規模 : 開発チームの規模が小さく、 パフォーマンスが高く、フルタイムで活動し、スキ ルが高く、ほとんどのプロジェクトの決定権限を 持っている必要があります。 • 要求が不明 : アジャイル手法は、要求が不明確また は変化しやすい場合に適しています。論理的に言え ば、要求が不安定な場合、安定した設計は不可能で あり、計画されたプロセスに厳格に従うこともでき ません。 • ステークホルダが多額の投資をしている : 要求が変 化する場合は計画的なプロセスに従うのは危険だと いうことを、顧客が理解することが重要です。さら に顧客は、全開発プロセスに積極的に関与する必要 があります。 • インクリメンタル開発 : アジャイル手法は、反復的 かつ段階的に作業を進める場合にうまく機能します。 反復 ビジネスアナリストのプラクティスの説明では、ス テップは逐次的に見えますが、必ず反復的に実行さ れます。予測できないプロセスをコントロールする には、反復が最善の対応策となります。ビジネスア ナリストは、要求と開発の状態を明らかにするため に、率直なフィードバックを頻繁に受ける機構を構 築する必要があります。 このフィードバックで重要なのは、要求生成に関す る反復的なアプローチです。要求フェーズでは、IT アーキテクトはソリューション設計において早期に 反復作業を行っています。ビジネスアナリストが要 求トレードオフ分析を行うように、アーキテクトは ソリューションのオプションについて同様の作業を 行います。したがって、プロトタイピングが反復型 開発における最初のステップとなります。 インクリメンタル、進化型、段階的、スパイラルと いった手法は、いずれも本質的には反復型の手法で す。初期のプロトタイプが作成され、その後、要求 されたフィーチャの一部を含む最終的システムの段 階的作業バージョンが作成されます。これらの作業 サブシステムには限定的な機能しかありませんが、 システム要求は忠実に反映されています。反復型開 発の価値は、定期的な顧客レビューと、各反復作業 後のフィードバックにあります。 要求が満たされていることを確認する最良の方法は、 テスト済みの統合システムを用意することです。文書 とモデルには多くの場合、未検出の欠陥が含まれてい ます。ユーザが実際にシステムで作業すれば、問題が 明らかになり、それがシステムの欠陥によって生じた のか、要求の誤解によるものかがわかります。 プロジェクトマネージャにとっては、新しい計画立 案手法が必須になります。ローリングウェーブ計画 法は、今日の時流に沿った手法です。短期計画に関 しては、1 回分の反復作業のみを扱った極めて詳細な 計画が策定されますが、以降の反復については高レ ベルな内容のみが計画されます。反復型開発によっ て、各インクリメントにおいて強固な基盤が形成さ れ、それがその後の計画の基礎となります。 10 図2 プロジェクトのサイジング表 図2 プロジェクトのサイジング表 プロジェクト属性 リスク低（小規模） リスク低∼中（中規模） 重要でリスク高（大規模） 見積もり期間 6 か月未満 6∼12 か月 12∼24 か月 コアチームの規模 6 人以下 7∼12 人 13 人以上 コスト 75 万ドル未満 75 万∼100 万ドル 100 万ドル超 スケジュール スケジュールは柔軟 軽微な変動は認められるが、締 切は厳密 締切は厳守で、変更も不可能。 スケジュールに柔軟性がない 複雑性 問題とソリューションは簡単に 理解できる。ソリューションは 容易に達成可能である 問題の理解が困難でソリュー ションが不明確、あるいは ソリューションの達成が困難 問題とソリューション双方に 関して定義/理解が困難であり、 ソリューションの達成も困難 戦略的重要性 内部的関心のみ ある程度、ビジネスに直接的な影 響を及ぼす。または、優先度が低 いイニシアティブに関連している 主要な戦略的イニシアティブに 関連している 変更のレベル 単一のビジネスユニットに影響 を及ぼす 複数のビジネスユニットに影響 を及ぼす 企業全体に影響を及ぼす 依存関係 主要な依存関係なし、または相 互に関連するプロジェクトなし いくつかの依存関係と相互に関 連するプロジェクトがあるが、 リスクは低い リスクの高い主要な依存関係や 相互に関連するプロジェクトが 存在する 重要で高リスクのプロジェクト 低∼中リスクのプロジェクト 低リスクのプロジェクト 変更のレベルが "企業全体に影響 を及ぼす"、または "大規模" の列 で 2 つ以上の項目に該当する "中規模" の列で 4 つ以上の項目 に該当するか、"大規模" の列で 1 つかつ "中規模" の列で 3 つ 以上の項目に該当する 残りの組み合わせ 反復型/アジャイル/インクリメンタル開発は、IT の 比較的リスクの高い分野には、正式かつ構造化され な結果がもたらされる可能性があります。ビジネス グ表」を参照してください。関連するサイジングの 成果を追求する最新の手段です。これにより、劇的 にとっての価値は、より迅速かつ低コストで得られ るようになります。顧客は持続的な進歩を実感でき ます。頻繁なフィードバックによって柔軟性と変化 がプロジェクトに取り入れられるため、プロジェク トを常にビジネスニーズに適合させることができま す。価値ベースの優先度設定によって、ソリュー ションの最も重要なフィーチャを最初に実現するこ とができます。フィードバックが重要である理由は、 迅速な作業ではなく、迅速な理解が可能になること にあります。 スケーラビリティ 使用される方法が軽量型であろうと重量型であろう と、前述のすべてのアクティビティが実行されます。 こうしたアクティビティは、プロジェクトのほぼ最 初の段階で実行され、プロジェクトがライフサイク ルをたどるにつれて段階的に詳細化されます。小規 模で理解しやすい単純なプロジェクトの場合、要求 記述書とモデルの量を最小限に抑えたほうが適切で す。実際、チームの規模が小さいほど、文書化は正 式でなくてもかまわないことになっています。しか し、重要で複雑性があり、高リスクのプロジェクト の場合、すべての要求記述書を揃え、承認を受けま す。低∼中程度のリスクのプロジェクトの場合は厳 密に文書化する量を適宜調整し、プロジェクト内の た文書を作成します。図2「プロジェクトのサイジン 式は、表の後にあります。 プロジェクト成功のレシピ The Standish Group International, Inc.のレポート 『Unfinished Voyages: A Follow-up to the CHAOS Report』（1999年）を基に考案された "成功のレシ ピ" に従ってプロジェクトを調整すると、ビジネスア ナリストは必ず成功を収めることができます。これ は、プロジェクトの特性を問いません。メッセージ は明確で、サイズこそが重要であるというものです。 プロジェクトや主要なプロジェクトフェーズを構造 化する場合、プロジェクトマネージャとビジネスア ナリストは、プロジェクトのリスクを軽減するため に次のガイドラインに従うよう努めます。 材料：最小化、コミュニケーション、標 準プロセス 材料と混ぜる：関与するプロジェクトス ポンサが率いるフルタイムの中心的チー ムメンバ（ビジネスアナリスト、プロ ジェクトマネージャ、ビジネス関係者、 アーキテクト/開発者） 11 焼く：半年以内に 6 人以下で予算 75 万 ドル以下で仕上げる ビジネスアナリストの課題 ビジネスアナリストの役割について議論する場合は、 この困難かつ重要な機能を満たす際に陥りやすい過 ちについて、検討する必要があります。ビジネスア ナリストに期待されるのは、システムのスコープ設 定、開発者へのビジネスニーズの伝達、ビジネス部 門担当者への技術的問題の伝達、要求のモデル化/文 書化、コミュニケーションの仲介、政治的な助言者 としての役割、ソリューションのテストと妥当性確 認（一般的には、顧客、ユーザ、ステークホルダの 代弁）などですが、この役職が過大な権力を行使す ることもあります（Ambler、2005）。多くの組織で は、上級ビジネスアナリストの導入によって、要求 の引き出しと文書化が大幅に改善しています。しか し、頻繁に発生する問題もあります。ビジネスアナ リストは、次のような落とし穴に注意する必要があ ります。 • 知識とスキル : 有能な技術者に管理職の地位を押し 付けるという IT 部門の慣行によって、ビジネスア ナリストが必要なスキルを備えていないというケー スが多々あります。 • 障壁と橋渡し : ビジネスアナリストが、プロジェク トの決定に対して過大な影響力を行使する場合があ ります。技術コミュニティとビジネスコミュニティ の対話を促してファシリテータ/実現要因として機 能するのではなく、両者の間に立ちはだかってしま うビジネスアナリストもいます。こうした場合、ビ ジネスアナリストはコミュニケーションの橋渡しで はなく、障壁になってしまいます。 • ビジネスと技術に対する洞察力の低下 : ビジネスア ナリストは速やかに、ビジネスと技術の両方の領域 における能力を身につけます。両方のコミュニティ との信頼関係を維持するには、技術的進歩とビジネ スの傾向の両方に関して、時流に乗り遅れないよう にする必要があります。 • 分析麻痺 : ビジネスアナリストは、反復ではなく分 析期間を延長することによって、過剰な分析をして しまう傾向があります。すべてを網羅した分析を 1 回だけ行うよりも、ビジネスと技術の両方のコミュ ニティからのフィードバックに応じて何度か反復す るほうが価値があります。分析麻痺によって、ビジ ネスアナリストは、実際にはうまく機能しない理論 モデルに基づいて約束をしてしまう場合もあります。 ビジネスアナリストの トレーニング IT 組織は、ビジネスコミュニティと技術コミュニ ティの橋渡しをするために必要な優れたビジネスア ナリストを、どのように育成すればよいのでしょう か。他のリーダーシップの役割と同様に、教育やト レーニングを受け、指導や指南を進んで求め、当該 分野を積極的に学ぶことによって、その能力を得る ことができます。ビジネスアナリストの役割にはビ ジネスと技術の両方の専門知識が必要なので、ビジ ネスアナリストの正式な資格には、伝統的なビジネ ス管理コースに加えて、コンピュータや管理情報シ ステムの学習が含まれます。さらに、ビジネスアナ リストの教育、トレーニング、実際の経験には、以 下の項目が含まれている必要があります（Sodhiおよ びSodhi、2003） 。 • 要求生成プロセス全体に関する知識 • 要求開始 • システム要求引き出し • 要求のタイプ • 要求を適切に記述する方法 • 要求の文書化 • 要求定義 • システム要求記述書 • 要求実現可能性と要求信頼性 • 費用便益分析 • 代替ソリューション分析 • 実現可能性と信頼性のリスク分析 • システム要求の管理 • ツールと手法 • 技術仕様書 • テスト計画書 • 要求追跡可能性プロセス • 要求とシステム開発 • 要求とシステム工学プロセス • システム工学計画立案 • 要求管理コントロール • ITシステムに対する要求分析 • 要求の機能分析と割り当て • 要求とシステム設計 • 要求とシステム実装 ビジネスアナリスト開発プロ グラムの計画 パフォーマンス向上、ベストプラクティス、プロ ジェクトの結果に焦点を絞ってビジネスアナリシス のトレーニングを実施するための、最先端の教材を 探します。コースは、確固たるシステム工学の原理 に基づき、リーダーシップと円滑化のスキルを重視 し、無駄のない思考やアジャイルツールセットを備 えている必要があります。また、実際の IT の状況を 対象として、アウトソーシングの課題を強調し、小 ∼中規模のプロジェクトから、大規模でリスクの高 いプロジェクトまでを調整する手法を幅広く提供し ているようなものが理想的です。 12 コース教材は、IT システム要求の記述、定義、分析、 管理にすぐに役立つ実践的なガイドラインとスキル を提供できるように設計されている必要があります。 ビジネスアナリスト向けのコースでは、実際の経験 とケーススタディに基づいて、実践的な戦略、十分 にテストされた方法、要求管理手法を導入するため のツールを提供します。 キャリアアップを図っている個人であれ、組織の IT ビジネスアナリシスの能力向上を目指しているマ ネージャであれ、先進的なビジネスアナリシスを通 じてプロジェクトがもたらす価値を高められるよう な、教育教材や指導素材を選択してください。また、 組織にすぐに影響を与えるような最良の構成のコー スと強化戦略の選択を支援してくれる、コンサルタ ントを探します。 最後に 技術、手法、ツールにおけるギャップは、プロジェ クト失敗の根本的な理由ではありません。プロジェ クトの失敗はむしろ、多くの場合、リーダーシップ の欠如と不適切な選択に由来しています。ビジネス アナリストとプロジェクトマネージャが、将来の IT 務とスキルを適合させ、パフォーマンスを追跡し、 適切な報酬を与えることによって、ビジネスアナリ ストにとって魅力のあるキャリア管理計画を作成し ています。 以前とは異なり、組織が危機的状況の後あるいは主 要な再編成と同時に専門的なトレーニングや指導を 開始する際には、IT 組織は課題に対処しながら、技 術よりもビジネスとリーダーシップに特化した能力 を重視するようになってきています。推進要因が何 であれ、卓越した専門的なビジネスアナリシスの キャリアプログラムには、既製の正式なカスタムト レーニング、指導および実地トレーニング、教育/テ スト/経験に基づく昇進、評価と報酬の定義済みプロ セス、適切な肩書きと昇進の機会といった構成要素 のほとんどが含まれています。 Kathleen B. Hass、PMP プロジェクトマネジメントおよび ビジネスアナリシスプラクティスリーダ Management Concepts 8230 Leesburg Pike Vienna, Virginia 22182 プロジェクトリーダへと進化していることは明らか です。しかし、チームのリーダーシップは従来の管 理とは異なり、チームも従来の運用業務グループと は異なります。重要な問題は、コントロールと管理 にあるのではなく、コラボレーション、合意、リー ダーシップにあります。 チームリーダは、チームの機能とチーム開発のダイ ナミクスを理解しなければなりません。また、高パ フォーマンスのチームを構築するための特別なスキ ルを身につけることも必要です。ソフトウェアに重点 を置くシステムの開発では、管理が不適切なチームに 比べて、適切に管理されているチームのほうが短時間 に多くの仕事をこなしています（Bechtold、1999）。 適切なトレーニングと指導を行わなければ、従来のビ ジネスマネージャと技術リーダが効果的なチームリー ダになれない可能性もあります。チームのビジネスア ナリシスリーダの役割は、尽きることがありません。 スポンサ、プロモータ、トレーナ、指導者、チームメ ンバ、発明者、起業家といった役割を一手に担うビジ ネスアナリシスリーダは、IT 管理に新しい波をもたら すという人もいます。 先端を行く研究者や学者は、プロジェクトの成功を、 組織的成功を確実にする方法として捉えています。 逆に、重要なプロジェクトの失敗が企業の消滅につ ながることも多々あります。先端的な組織は、ビジ ネスアナリストを効果的にトレーニングして配備す ることによって、プロジェクトのパフォーマンスを 改善しています。ビジネスアナリストを上級職へと 昇格させる特定のキャリアパスは、重要な才能を維 持しつつ、新しい人材にトレーニングを行うための 戦略の 1 つとなっています。公営企業や民間企業に おける見識のある組織では、潜在能力を開発し、任 13 参考文献 Ambler, S.（日付なし） 『Agile Analysis』Ambysoft Web サイトから 2005 年 4 月 8 日に取得 （http://www.agilemodeling.com/essays/agileAnalysis.htm） Ambler, S.（日付なし） 『When Does(n't) Agile Modeling Make Sense?』Ambysoft Web サイトから 2005 年 4 月 8 日に取得（http://www.agilemodeling.com/essays/whenDoesAMWork.htm） Bechtold, R.（1999） 『Essentials of Software Project Management』Vienna, VA: Management Concepts Fowler, M.（2003） 『The New Methodology』martinfowler.com Web サイトから 2005 年 4 月 8 日に 取得（http://www.martinfowler.com/articles/newMethodology.html） Hadden, R.（2003） 『Leading Culture Change in Your Software Organization』Vienna, VA: Management Concepts Mooz, H.、Forsberg, K.、Cotterman, H.（2003） 『Communicating Project Management: The Integrated Vocabulary of Project Management and Systems Engineering』Hoboken, NJ: John Wiley and Sons Sodhi, J. および Sodhi, P.（2003） 『Managing IT Systems Requirements』Vienna, VA: Management Concepts The Standish Group（1999） 『Unfinished Voyages: A Follow-up to the CHAOS Report』The Standish Group Web サイトから 2005 年 4 月 8 日に取得 （http://www.standishgroup.com/sample_research/unfinished_ voyages_1.php） Stevens, R.、Brook, P.、Jackson, K.、Arnold, S.（1998） 『Systems Engineering: Coping with Complexity』Indianapolis, IN: Pearson Education、Prentice Hall PTR Wiegers, K.（2003） 『Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle（ソフトウェア要求―顧客が望むシステムと は）』第 2 版 Redmond, WA: Microsoft Press Young, R.（2001） 『Effective Requirements Practices (Addison-Wesley information Technology Series)』Boston: Addison-Wesley 14 図3 ビジネスソリューションライフ サイクル ビジネスソリューションライフサイクル システム要求ライフサイクル 成果物 戦略計画 戦略目標 ビジネスケース 高レベルの プロダクト記述書 プロジェクト憲章 作業範囲記述書 ユーザクラス分析 要求管理計画書 フィーチャ優先度 設定マトリックス 要求記述書 要求実現可能性 代替案調査 要求ベースライン 開発のアウトソースの決定 提案依頼書（RFP） 要求変更管理計画書 要求追跡マトリックス テストのアウトソースの決定 提案依頼書（RFP） テスト計画書 テストケース テストシナリオ 開発されたコードに 基づくテスト スキルと手法 戦略計画立案 エンタープライズ分析 ビジネスニーズ ビジネスドメインの スコープ定義 要求 引き出し 分析 仕様作成 文書化と 妥当性確認 設計 割り当ておよび追跡 価値管理手法 円滑化スキルとコンセンサス形成スキル 競合管理スキル 意思決定手法 重要業績評価指標の策定 ステークホルダ管理スキル 要求提示スキル 要求収集ツール 要求円滑化スキル 要求作成スキル 早期要求検証手法 要求の分割および分解 リスク対処計画立案手法 リスク識別手法 リスク分析およびリスク対処計画立案 ツール プロトタイピング手法 実現可能性および代替案分析手法 変更管理ツール 要求割り当て手法 リスク軽減 構築 トレードオフ分析 リスク監視およびコントロールツール プロトタイプ プロトタイピング手法 変更管理 追跡 機能テスト 補足テスト ユーザ受け入れテスト システムの引き渡し システム実装後の運用サポート システムの保守と 機能強化 テスト テスト 引き渡し 引き渡し 運用および保守 運用および保守 検証手法 妥当性確認手法 ユーザのアンケート調査および インタビュー 変更管理ツール 運用停止 15 © 2008 本教材は、Management Concepts, Inc. が開発し、同社が著作権を保有しています。本教材の顧客提供は、Hewlett-Packard Development Company, LP に認可されています。 本契約書の内容は予告なく変更される可能性があります。HP の製品ならびにサービスの保証は、同社製品ならびにサービスに付属する保証 書に明示的に規定された保証のみとします。本契約書のいかなる部分も、追加保証として解釈されないものとします。HP は、本契約書の技 術上ならびに編集上の誤りならびに抜けに対して責任を負わないものとします。 4AA1-5102ENE、2008 年 1 月