BABOK®ガイド V3 パブリックレビュー版 第11章 パースペクティブ 情報技術(IT)

情報技術(IT)パースペクティブ(専門領域)のビジネスアナリシスです。従来のBABOKガイドはIT寄りの記述が多くあったのですが、バージョン3の本体(知識エリアの部分)はITに特化した部分は記述されていません。すべてのビジネスアナリシス活動に共通な部分だけが記述されています。そしてITに関する部分はすべてこのパースペクティブに記述されるようになりました。例えば、要求でも、ソリューション要求までは共通ですが、機能要求、非機能要求はこのITパースペクティブの中だけで記述されています。少し長いのですが、お付き合いください(清水)。

11.3 情報技術(IT)パースペクティブ

  • 情報技術組織のコンテキストの中で試みられる時、あるいは情報技術システムが変革案によって影響を受ける場合、情報技術パースペクティブは、ビジネスアナリシスの特性を発揮する。
  • 情報技術分野おいては、広範囲の複雑さおよび幅広いスコープでビジネスアナリストが活躍できる。イニシアチブはバグフィックスやシステム拡張程度の小規模のものから、リエンジニアリングと同じくらい拡張エンタープライズのための情報技術インフラストラクチャー全体を含む大規模なものまである。ビジネスアナリストはこの種々のレベルのステークホルダー間の知識とスキルと彼らの情報技術ニーズに、価値あるソリューションをデリバリするために働くように要求される。
  • ビジネスのビジョンおよびニーズを技術的なステークホルダーに有効につなげることは、情報技術分野におけるビジネスアナリストの成功の中心となる。ビジネスアナリストは、積極的にビジネス・ステイクホルダーと開発チームに協力し、ニーズが理解され、整合されることを確実にする。ビジネスアナリストは、しばしばビジネスと技術のステークホルダーが互いのニーズ、制約、コンテキストを理解するのを助ける翻訳者の役割を果たす。
  • 情報技術環境で働くビジネスアナリストは、次の3つの主要因に照らして自分のタスクを考慮する:
    ・ソリューションの影響: ビジネスに対するソリューションの価値とリスク
    ・組織の成熟度:     組織的な変革プロセスの公式度と柔軟性
    ・変革スコープ:     変革案の幅、深さ、複雑さ、コンテキスト
  • 情報技術変革イニシアチブはしばしばアジャイルなアプローチを利用する。
  • 当パースペクティブは情報技術変革イニシアチブへの非アジャイルなアプローチにフォーカスする。情報技術変革イニシアチブ内のアジャイルなアプローチに関する情報技術に関しては11.1アジャイルパースペクティブを参照のこと。

11.3.1 変革スコープ

  • 情報技術システムの変革はいくつかの理由で始められる。
  • 次のトリガーの各々は情報技術変革イニシアチブに結びつく場合がある:
    ・新しい組織的な能力を創出する:組織を変容するために実行することができる。これらのタイプの情報技術イニシアチブは、非情報技術の変革をアドレスする、より大きなプログラムの生成をドライブするかもしれないが、ビジネス環境を変革する技術に集中する。
    ・既存の能力の増強により組織目標を達成する: 定義されたニーズを満たすより大きな変革の一部として。規制要求を満たすか、あるいは特定のビジネス目標を可能にするための変革を含む。これらのタイプの情報技術イニシアチブは、しばしば既存の情報技術システムを修正するが、新しい情報技術システムの実装と統合を要求することもある。
    ・運用上の改良を促進する: 組織的な効率を改善するかあるいは組織的なリスクを減らすことを確実にする。この変革がプロジェクトとして管理されても、変革スコープ、組織的な成熟度、ソリューション影響度は継続的改善の活動の一部として実施される。
    ・既存の情報技術システムを維持する: 既存の情報技術システムの滑らかなオペレーションを保証することを確認する。変革スコープに依存するが、メンテナンスはプロジェクトまたは通常の業務活動として管理される。これは、ベンダーによる技術サポートの中止、購入したパッケージ・ソフトの予定されたリリースやアップグレード、アーキテクチャー戦略を支援するのに必要な技術的な修正など、技術的理由による変革である。
    ・故障した情報技術システムを修理する: 予想通りにパフォーマンスを発揮していない情報技術システムが機能障害を修正するために変革される場合。緊急の修理は、一般に引き起こされた混乱のレベルに基づく。ある場合には、修理努力の範囲が非常に大きい。その場合、修理活動はプロジェクトとして管理される。

 

.1 変革の広さ

  • 情報技術イニシアチブは単一のシステム、または互いに対話する多重システムに注目する。いくつかの情報技術システムは組織内で開発され維持されるが、それ以外はシステムを実装するグループとは別の外部の組織によって開発された既製のシステム(COTS)である。
  • 情報技術イニシアチブのスコープは、しばしば狭義のソフトウェアとハードウェア、システム、アプリケーションまたはステイクホルダーの最小のセットに集中する。より大きなイニシアチブでは多数のユーザグループまたはマルチシステムに影響を与え、しばしば、拡張エンタープライズでの協働が必要である。既製品の情報技術システムを実装する場合、しばしば小さな限定的なスコープで変革が始まるが、分析が完了した時点では、当初予想されたものより広いスコープになってしまう。それはほとんど場合、情報技術システムがカスタマイズ、統合化、管理およびトレーニングを常に必要とするからである。多くの場合、情報技術イニシアチブは、既存のアプリケーションへの最初のインスタレーション、実装あるいは増強に制限される。(以下省略)

.2 変革の深さ

  • 情報技術の環境の変化は、しばしば変革によって操作されたか影響をうける個々のデータ要素の定義のような技術的詳細を含む明示的な詳細を定義することをビジネスアナリストに要求する。統合作業は、情報技術システム間のインターフェースを識別し定義する、一方、大きな詳細レベルで分析と定義を要求することができる。これらのタイプのイニシアチブで要求される詳細レベルにより、ビジネスアナリストは、どのように全体として組織が機能し、情報技術システムはどのようにそのオペレーションを支援するかを、引き出し、分析する。これは、発見され文書化された詳細が価値を伝えることに関連するかどうかを理解するためにビジネスアナリストに必要なコンテキストを提供する、情報技術システム変革を始める理由が技術駆動の場合で、ビジネス目的との整合性が十分に明瞭でなく始められる場合、これは特に挑戦となる。

.3 提供される価値とソリューション

  • 情報技術システムは組織的な価値を増加させるために実装されるが、どのように能力およびプロセスを支援するためにシステムを使用するかにある。ビジネスアナリストは、これらのプロセスと能力への情報技術機能を整合させ、かつ情報技術システムがそれらに持つ影響を測定しようとする。(以下省略)

 .4 提供方法

  • 情報技術組織内のビジネスアナリシス活動の提供方法は大幅に変わる。イニシアチブは、単一で短時間のリリーススケジュールで終わる小さなエンハンス作業から、フェーズ化された実装のマルチリリースに及ぶものまである。

 .5 主な前提条件

  • ビジネスアナリストは、しばしば情報技術システムを使用するビジネス能力とプロセスが組織に価値を提供していることを前提とする
  • 他のパースペクティブの仕事を備えたビジネスアナリストの仕事と、情報技術ビジネスアナリストの仕事を統合することができる
  • 情報技術システム変革は通常ビジネスニーズによってドライブされるが、いくつかのイニシアチブは内部の技術開発から始まることもある

11.3.2 ビジネスアナリシスのスコープ

.1 変革スポンサー

  • 情報技術の変革はビジネス組織や情報技術組織によって要求されたり、資金提供されたり、またはコラボレーションされることがある。これらの変革は要求元組織、スポンサー組織にかかわらず、組織戦略やビジネスゴールに整合されるべきである。情報技術グループが技術的戦略と提携し技術的なゴールに達する変革を開始することは可能である。しかし、変革を成功するためには、
  • 組織戦略との全面的な整合を欠かすことができない。
  • 下記は可能な変革スポンサーのリストである:
    ・技術チーム
    ・技術役員
    ・アプリケーション・オーナー
    ・プロセス・オーナー
    ・ビジネス・オーナー
    ・社内のプロダクトマネジャー
    ・本社法務部門の規制者

 .2 変革ターゲット

  • ビジネスアナリストは、変革案によって影響を受ける部門、プロセス、アプリケーション、機能を識別する。ビジネスアナリストはイニシアチブの詳細に注目するだけでなく、より大きなピクチャと変革のビジネス的技術的の両側面の潜在的効果から目を離してはならない。これは、プロセス・ハンドオフと技術的インタフェースの両方に特定の焦点を置くプロセスと機能分析の一つのレベル含む。

.3 ビジネスアナリストの位置付け

  • 情報技術イニシアチブ内のビジネスアナリシス活動は、組織内のいくつかの背景のタイプまたは肩書を持つ人によってなされるかもしれない。このアサインは、必要とされる変革のタイプ、経験のレベル、必要とされる知識、あるいは単に作業ができる人員に依存するかもしれない。人員は下記に述べられた経験によりビジネスアナリシスタスクに割り当てられるかもしれないし、与えられた変革の部分的、あるいはビジネスアナリシス責任のすべてを完成するかもしれない。これらの背景の1つだけを持つ人によって、情報技術プロジェクトのためのビジネスアナリシス作業すべてが終わることもある:
    ・情報技術システムのビジネスユーザーと特に仕事をするビジネスアナリスト
    ・技術チームと、アプリケーションを使用するビジネスグループの間の橋渡しとなる情報技術ビジネスアナリスト
    ・現在のソフトウェア実装の経験を持っているSME(該当分野の専門家)は、ソフトウェアまたは能力とプロセスを支援する経験の深さが必要なために、変革作業を文書化するように求められるかもしれない。
    ・ソフトウェアのユーザは、一般にソフトウェアがどのように使用されるかの毎日の活動の経験を持っているのでユーザビリティにフォーカスできる
    ・システムアナリストはビジネスドメインの経験を持っているが、特定のアプリケーションの経験はない
    ・ビジネスプロセス・オーナーはビジネスの能力やプロセスを備えた経験の深さを持っているが、技術や情報技術経験は持っていない
    ・技術的な経験の深さを持っている技術者は、成功する変革イニシアチブに必要な要求と詳細を文書化してもよい
    ・既製ソリューション(COTS)の担当者はパッケージソリューションのカスタマイズされた実装を可能にし、ベンダーのパッケージについての知識と過去の実装経験を活用する

.4 ビジネスアナリシスの結果

  • 情報技術組織内では、ビジネスアナリストは変革によって影響を受けるビジネスプロセス、そして変革されるシステムによって集められるデータとビジネスインテリジェンス情報など、他の専門領域からの変革作業を考慮するように求められるかもしれない。情報技術の専門領域で専念的に働くビジネスアナリストが変革作業を支援するビジネスアナリシス作業と成果物を計画することは重要である。
  • 利用されている変革アプローチは、ビジネスアナリシスの成果物あるいは結果に直接の影響を及ぼす。多くの情報技術組織は、ある程度、各プロジェクトのマイルストーンで必要な成果物を指示する、定義されたシステムまたはソリューションの開発方法論を持っている。この構造のコンテキスト内でさえ、ビジネスアナリストは変革アプローチか組織特定のプロセスによって要求される以上の追加の成果物を完成しようとし、また変革作業についての包括的な理解を支援する技術を使用しようと努力するかもしれない。
  • 情報技術専門領域で働くビジネスアナリストは、以下の提供に責任を持つ:
    ・定義された要求、テスト可能な要求、完全な要求、優先順位の付いた要求、検証された要求
    ・ギャップ分析
    ・機能分解
    ・シナリオと(または)ユーザストーリー、ユースケースの中の適切なもの
    ・インターフェース分析
    ・プロトタイプ
    ・コンテキストモデルまたはスコープモデル
    ・データモデル
  • どんな要求も、概ね次の2つのカテゴリーのうちのどちらか1つに当てはまる:
    ・機能要求:ソリューションがマネージする振る舞いと情報の観点からソリューションが持たなければならない能力について記述する。
    ・非機能要求:ソリューションが有効か高品質であるために、ソリューションが持たなければならないサービス要求条件の品質について記述する。

お疲れ様です。やっと、機能要求と非機能要求の部分にたどり着きました。IT分野でビジネスアナリシスを担当されている読者から見ると、少しくどい記述が多かったのではないでしょうか。逆に、これだけでIT分野でのビジネスアナリシス活動ができるようになるわけでもありません。他の専門領域のビジネスアナリストにとっては大きな参考になると思います(清水)。

以下は節のタイトル程度です。

11.3.3 メソドロジー

  • 情報技術組織に役に立つ方法論は幅広くある。一般的なソリューションの開発方法は以下の2つの総括的なアプローチである:(以下省略)

11.3.4 基礎コンピテンシ

  • 情報技術専門領域で仕事をするビジネスアナリストは、直接的なソフトウェア開発(プログラミング、データベース作成、システムまたソリューションアーキテクチャの作成などの)、ソフトウェアテスト、他の技術的スキルなどの情報技術開発者と関係するスキルを所有するかもしれない。しかしながら、開発作業に直接関連するスキルや技術的スキルは、ビジネスアナリストが情報技術変革において成功するために必要なものではない。組織のテクニカルアーキテクチャの制約内に技術的に実現可能なことを理解するのと同様に、要求パッケージ内において技術的ソリューションをサポートするのに必要な詳細を十分理解することは、ビジネスアナリストにとって重要である。これらのスキルは、技術チームに技術的ソリューションを設計する柔軟性を与えるビジネスソリューション・フレームワークを設計するすべてのステークホルダーと、ビジネスアナリストが仕事をすることを可能にする。

11.3.5 知識エリアへの影響

  • このセクションは、情報技術における特定のビジネスアナリシス・プラクティスが、どのくらいBABOK®ガイドによって定義されるビジネスアナリシス・タスクとプラクティスに写像されるかを説明する。このセクションでは、知識エリアがそれぞれ情報技術専門領域でどのように適用、修正されるかを説明する。

.1 ビジネスアナリシスの計画とモニタリング

  • ビジネスアナリシスのアプローチは、ビジネスアナリシスの作業に必要なリソースを識別し、かつ分析作業に適切な時間を確実に使用することができる基本のコミュニケーション・ツールである。良く定義されたビジネスアナリシス計画はプロジェクトの統合プロジェクト計画に統合され、ビジネスアナリストにプロジェクト用のビジネスアナリシス活動を定義しスケジュール化する機会を提供する。(以下省略)

.2 引き出しとコラボレーション

  • 情報技術変革は、しばしばソリューションまたは変革と異なる関係を持つ多くのステークホルダーに影響する。変革が情報技術アプリケーションかシステムを含む場合、技術スタッフは要求とソリューションが定義されるシステムまたはプロセスに関する新たな影響を識別することができる専門知識、知見、経験を持っているかもしれない。この理由で、同じ部屋の中に開発またはテクニカル・デザインのスタッフのような情報技術スキルの保有者とビジネスSMEとで、同時に1つ以上の引き出しセッションを過ごすことは有益である。この種の引き出しアプローチは、技術チームとビジネスチーム間の協働のための共通基盤を提供する。そこで、情報技術ビジネスアナリストはプロセスのファシリテーターまたは橋渡しとして役に立つ。(以下省略)

.3 要求ライフサイクルマネジメント

  • 情報技術イニシアチブは、変革を創出する間にしばしば主要な発見を経験する。ビジネスアナリストは調査を通じてソリューションの提供する新しい機能のヒントを得る。情報技術環境における発見のこの感覚は、短周期期間(アジャイルおよび継続改善)、厳密な変革管理(能力成熟度モデル(CMMI)と予測的)、見える化した情報技術(ソフトウェア・アズ・サービス(SAAS)およびクラウド・サービス) の適応に結びつく。(以下省略)

.4 ストラテジーアナリシス

  • 情報技術組織内のストラテジーアナリシスは変革案によって影響を受ける、テクノロジーとシステム、ビジネスユニット、ビジネスプロセス、ビジネス戦略にフォーカスする。変革の影響が組織の他のシステムに波及効果を引き起こすことがあり得る。ニーズと変革案を分析するため、ビジネスアナリストは、変革によって影響受けるかもしれない様々な面をすべて理解しようと努力する。(以下省略)

.5 要求アナリシスとデザイン定義

  • 情報技術専門領域で働くビジネスアナリストにとって用語デザインを理解し明確にすることは重要である。多くの情報技術組織はソフトウェアまたは技術的変革がデザインもしくは青写真に当てはまる場合のみに、デザインについて考える。知識エリア「要求アナリシスとデザイン定義」では、用語デザインはより広くビジネスアナリストの視点から見られる。デザインはソリューションにフォーカスする使用可能な表現で、ソリューションが構築される場合、価値がソリューションによってどのように実現されるかを理解する。
  • 情報技術専門領域で働くビジネスアナリストはビジネス要求と技術的要求を入念に詳細化し、分解し、ステークホルダーニーズを定義し、そして、一旦技術的ソリューションか変革が実装されれば、ステークホルダーによって認識される価値を識別する。ビジネスアナリストは、ビジネス要求とステークホルダー要求を引き出し、定義し、分析する。同様に、ソリューションデザインを定義し、分析し、モデル化する。そしてソリューションデザインの一部として、テクニカルデザインへのインプットとして使用できる技術的な詳細のレベルで要求を定義する。
  • ソフトウェアソリューション用テクニカルデザインを生産するために、情報技術で働くビジネスアナリストは、しばしば他のチェンジ・エージェントに依存する。一連の要求を満たす技術を使用する方法を決定するためにシステムアーキテクト、プログラマ、データベースマネージャあるいは他の技術者の協力がしばしば必要である。情報技術ビジネスアナリストはビジネスプロセス、ビジネスルール、スクリーンフロー、報告レイアウトを定義する。システムプロセスと同様にシステムとビジネスの詳細な機能を含めるために要求を定義することは、ソリューションデザインの重大な部分であり、分析とデザインを分離することはしない。(以下省略)

.6 ソリューション評価

  • ソリューション評価はソリューションコンポーネント、およびそれらが提供する価値に注目する。情報技術コンテキスト内では、これは、変革および周囲の環境内の多重システム間の相互作用への焦点を含む。情報技術専門領域で働くビジネスアナリストにとって、ソリューションと1つのシステムあるいはプロセス内の変更がどのように環境内の他のシステムに影響を与えるかのコンテキストを理解することは、重要である。これらの影響は、マイナスかプラスの価値を他のシステムに加えることができる、したがって変革イニシアチブの価値の全面的な実現に影響を与える。(以下省略)

 

「要求アナリシスとデザイン定義」の部分だけ、詳細に訳しました。従来の分析作業のみならず、一歩デザインにまで踏み込んだ表現になっていることに注意してください。最終的なテクニカルデザイン(恐らく詳細設計の意味)作成には他のSME(システムアーキテクト、プログラマー、データベースマネジャー、その他の技術者)の協力を必要としますが、その作成責任を持つことを示唆しています。ITビジネスアナリストはビジネスプロセス、ビジネスルール、スクリーンフロー、報告レイアウトを定義します。そして分析とデザインを分離しません。ビジネスアナリストと言うより、システムアナリストに近い立場です(清水)。