「BABOK」の版間の差分
ナビゲーションに移動
検索に移動
(ページの作成:「==BABOK== *http://www.atmarkit.co.jp/im/carc/serial/babok/01/01.html ==BABOKとは?== *“本当に使えるシステム”を作り上げるためには、顧客…」) |
|||
1行目: | 1行目: | ||
− | ==BABOK== | + | ==[[BABOK]]== |
*http://www.atmarkit.co.jp/im/carc/serial/babok/01/01.html | *http://www.atmarkit.co.jp/im/carc/serial/babok/01/01.html | ||
− | == | + | ==[[BABOK]]とは?== |
− | * | + | *“本当に使えるシステム”を作り上げるためには、顧客の[[業務]]内容に基づいて、発生している問題や課題、ニーズといった「背景(=Why)」をしっかりと理解し、顧客から本当に必要とされる「有用な機能(=What)が何なのか?」を明らかにする必要があります |
− | * | + | *[[システム開発]]者は、システムを「どのように(=How)作るか?」にかけてはプロフェッショナル |
*しかし、必要なことは、理由や原因に基づいた「真に有用な機能を明確にしていく作業」「Why」と「What」 | *しかし、必要なことは、理由や原因に基づいた「真に有用な機能を明確にしていく作業」「Why」と「What」 | ||
− | * | + | *“使えないシステム”ができ上がってしまう原因の多くは、システムの作り方にあるのではなく、「顧客の[[業務]]を分析して背景を理解し、それに基づいて本当に必要な解決策を追求することができていない点」にある |
===ビジネスアナリシス(BA)=== | ===ビジネスアナリシス(BA)=== | ||
− | * | + | *企業や組織が抱える問題・課題を解決し、さらに[[業務]]を良い方向へ持っていくために、その構造や思想、[[業務]]内容を理解・共有するためのさまざまな活動や技術をまとめ、総称したもの |
− | * | + | *顧客にとって本当に価値のあるもの、必要とされていることを[[業務]]の関係者と一緒に背景から掘り起こし、明確にしていく作業 |
*システム要件定義の手前、システム企画時などに適用される活動 | *システム要件定義の手前、システム企画時などに適用される活動 | ||
− | === | + | ===ビジネスアナリシスを体系立ててまとめた「[[BABOK]]」=== |
*[http://www.theiiba.org/ IIBA(International Institute of Business Analysis)]によってまとめられ、発表されているものが「BABOK(Business Analysis Body of Knowledge)」 | *[http://www.theiiba.org/ IIBA(International Institute of Business Analysis)]によってまとめられ、発表されているものが「BABOK(Business Analysis Body of Knowledge)」 | ||
*ある単一の手法を指すものではなく、世界中のビジネスアナリシスの実践者たちが培い、その有用性が確認されたさまざまな活動や技法が、体系としてまとめられたもの | *ある単一の手法を指すものではなく、世界中のビジネスアナリシスの実践者たちが培い、その有用性が確認されたさまざまな活動や技法が、体系としてまとめられたもの | ||
20行目: | 20行目: | ||
*技法(Technique) | *技法(Technique) | ||
===KA(Knowledge Area:知識領域)=== | ===KA(Knowledge Area:知識領域)=== | ||
− | * | + | *関連する情報や活動をまとめた[[カテゴリ]] |
− | * | + | *[[BABOK]]バージョン2.0は7つのKAによって構成 |
*7つのKAのうち「基礎コンピテンシ(Underlying Competencies)」だけは特殊なKAで、ビジネスアナリスト(ビジネスアナリシスを実践する人)に求められるスキルや能力がまとめられている | *7つのKAのうち「基礎コンピテンシ(Underlying Competencies)」だけは特殊なKAで、ビジネスアナリスト(ビジネスアナリシスを実践する人)に求められるスキルや能力がまとめられている | ||
====7つのKA==== | ====7つのKA==== | ||
#ビジネスアナリシスの計画とモニタリング(Business Analysis Planning & Monitoring) | #ビジネスアナリシスの計画とモニタリング(Business Analysis Planning & Monitoring) | ||
#引き出し(Elicitation) | #引き出し(Elicitation) | ||
− | # | + | #要求のマネジメントと[[コミュニケーション]](Requirements Management & Communication) |
#エンタープライズアナリシス(Enterprise Analysis) | #エンタープライズアナリシス(Enterprise Analysis) | ||
− | # | + | #要求アナリシス([[R]]equirements Analysis) |
#ソリューションのアセスメントと妥当性確認(Solution Assessment & Validation) | #ソリューションのアセスメントと妥当性確認(Solution Assessment & Validation) | ||
#基礎コンピテンシ(Underlying Competencies) | #基礎コンピテンシ(Underlying Competencies) | ||
42行目: | 42行目: | ||
*http://www.xmind.net/share/piroto/babok/ | *http://www.xmind.net/share/piroto/babok/ | ||
===ビジネスアナリシス=== | ===ビジネスアナリシス=== | ||
− | ==== | + | ====[[BABOK]]ガイド==== |
*広く認められたベストプラクティス | *広く認められたベストプラクティス | ||
*プロジェクトの開始前、ライフサイクル全体、運用後までを網羅 | *プロジェクトの開始前、ライフサイクル全体、運用後までを網羅 | ||
====定義==== | ====定義==== | ||
− | * | + | *組織の構造とポリシー[[業務]]運用について理解を深める |
*ステークホルダー間の橋渡しとなるタスクとテクニックをまとめたもの | *ステークホルダー間の橋渡しとなるタスクとテクニックをまとめたもの | ||
====ビジネスアナリスト==== | ====ビジネスアナリスト==== | ||
74行目: | 74行目: | ||
##リーダーシップ | ##リーダーシップ | ||
##ファシリテーション | ##ファシリテーション | ||
− | #コミュニケーション(情報伝達)のスキル | + | #[[コミュニケーション]](情報伝達)のスキル |
− | ## | + | ##プロジェクト失敗の最大の原因は[[コミュニケーション]]不足 |
− | ===== | + | =====[[プロジェクトマネージャ]]ーとの対比===== |
− | * | + | *プロジェクト初期には、[[プロジェクトマネージャ]]ーがビジネスアナリストの仕事をすることが多い |
*ビジネスアナリシスのチームもプロジェクトのリソースの一部 | *ビジネスアナリシスのチームもプロジェクトのリソースの一部 | ||
*対立の可能性がある領域 | *対立の可能性がある領域 | ||
− | * | + | *ステークホルダーとの[[コミュニケーション]] |
*計画 | *計画 | ||
====主要なステークホルダー==== | ====主要なステークホルダー==== | ||
88行目: | 88行目: | ||
#実装のSME | #実装のSME | ||
#運用サポート | #運用サポート | ||
− | # | + | #[[プロジェクトマネージャ]]ー |
#テスト担当者 | #テスト担当者 | ||
#帰省者 | #帰省者 | ||
105行目: | 105行目: | ||
##引き出しの結果を文書化 | ##引き出しの結果を文書化 | ||
##引き出しの結果を確認 | ##引き出しの結果を確認 | ||
− | # | + | #要求のマネジメントと[[コミュニケーション]] |
##ステークホルダーに要求を伝達する方法を定義 | ##ステークホルダーに要求を伝達する方法を定義 | ||
##タスクとテクニック | ##タスクとテクニック | ||
184行目: | 184行目: | ||
*検証された | *検証された | ||
====プロジェクトへの適用==== | ====プロジェクトへの適用==== | ||
− | * | + | *[[BABOK]]ガイドの原則やベストプラクティスをプロジェクトにマッピング |
*ビジネスアナリシスの作業 | *ビジネスアナリシスの作業 | ||
==ビジネスアナリシスの計画とモニタリング== | ==ビジネスアナリシスの計画とモニタリング== | ||
213行目: | 213行目: | ||
#変更管理 | #変更管理 | ||
#計画プロセス | #計画プロセス | ||
− | # | + | #ステークホルダーとの[[コミュニケーション]] |
#要求アナリシスと要求マネジメントのツール | #要求アナリシスと要求マネジメントのツール | ||
#プロジェクトの複雑性 | #プロジェクトの複雑性 | ||
222行目: | 222行目: | ||
##割引キャッシュフロー | ##割引キャッシュフロー | ||
##正味現在価値(NPV) | ##正味現在価値(NPV) | ||
− | ##内部収益率( | + | ##内部収益率(I[[R]][[R]]) |
##平均収益率 | ##平均収益率 | ||
##回収期間 | ##回収期間 | ||
247行目: | 247行目: | ||
====ステークホルダー分析を主導==== | ====ステークホルダー分析を主導==== | ||
====ビジネスアナリシスのアクティビティを計画==== | ====ビジネスアナリシスのアクティビティを計画==== | ||
− | ==== | + | ====ビジネスアナリシスの[[コミュニケーション]]を計画==== |
====要求マネジメントプロセスを計画==== | ====要求マネジメントプロセスを計画==== | ||
====ビジネスアナリシスのパフォーマンスをマネジメント==== | ====ビジネスアナリシスのパフォーマンスをマネジメント==== | ||
255行目: | 255行目: | ||
*ビジネスアナリシスへのアプローチ | *ビジネスアナリシスへのアプローチ | ||
*要求マネジメント計画 | *要求マネジメント計画 | ||
− | * | + | *ビジネスアナリシスの[[コミュニケーション]]計画 |
*ビジネスアナリシスのパフォーマンスのアセスメント | *ビジネスアナリシスのパフォーマンスのアセスメント | ||
===コントロールされた開始の終盤になっているべき状態=== | ===コントロールされた開始の終盤になっているべき状態=== |
2020年2月16日 (日) 04:22時点における最新版
目次
- 1 BABOK
- 2 BABOKとは?
- 3 構成要素
- 4 メモ
- 5 ビジネスアナリシスの計画とモニタリング
BABOK
BABOKとは?
- “本当に使えるシステム”を作り上げるためには、顧客の業務内容に基づいて、発生している問題や課題、ニーズといった「背景(=Why)」をしっかりと理解し、顧客から本当に必要とされる「有用な機能(=What)が何なのか?」を明らかにする必要があります
- システム開発者は、システムを「どのように(=How)作るか?」にかけてはプロフェッショナル
- しかし、必要なことは、理由や原因に基づいた「真に有用な機能を明確にしていく作業」「Why」と「What」
- “使えないシステム”ができ上がってしまう原因の多くは、システムの作り方にあるのではなく、「顧客の業務を分析して背景を理解し、それに基づいて本当に必要な解決策を追求することができていない点」にある
ビジネスアナリシス(BA)
- 企業や組織が抱える問題・課題を解決し、さらに業務を良い方向へ持っていくために、その構造や思想、業務内容を理解・共有するためのさまざまな活動や技術をまとめ、総称したもの
- 顧客にとって本当に価値のあるもの、必要とされていることを業務の関係者と一緒に背景から掘り起こし、明確にしていく作業
- システム要件定義の手前、システム企画時などに適用される活動
ビジネスアナリシスを体系立ててまとめた「BABOK」
- IIBA(International Institute of Business Analysis)によってまとめられ、発表されているものが「BABOK(Business Analysis Body of Knowledge)」
- ある単一の手法を指すものではなく、世界中のビジネスアナリシスの実践者たちが培い、その有用性が確認されたさまざまな活動や技法が、体系としてまとめられたもの
- BABOKガイドバージョン2.0IIBAのWebサイトから入手可能(会員以外でも29.95米ドル)
構成要素
- KA(Knowledge Area:知識領域)
- タスク(Task)
- 技法(Technique)
KA(Knowledge Area:知識領域)
- 関連する情報や活動をまとめたカテゴリ
- BABOKバージョン2.0は7つのKAによって構成
- 7つのKAのうち「基礎コンピテンシ(Underlying Competencies)」だけは特殊なKAで、ビジネスアナリスト(ビジネスアナリシスを実践する人)に求められるスキルや能力がまとめられている
7つのKA
- ビジネスアナリシスの計画とモニタリング(Business Analysis Planning & Monitoring)
- 引き出し(Elicitation)
- 要求のマネジメントとコミュニケーション(Requirements Management & Communication)
- エンタープライズアナリシス(Enterprise Analysis)
- 要求アナリシス(Requirements Analysis)
- ソリューションのアセスメントと妥当性確認(Solution Assessment & Validation)
- 基礎コンピテンシ(Underlying Competencies)
タスク(Task)
- 目的を達成するためにビジネスアナリストが実践すべき活動
- ある特定の具体的なプロセスを記述したものではない
技法(Technique)
- タスクを実行して成果物を作成する際に、ビジネスアナリストが利用できる具体的な実行方法・手法の例
メモ
ビジネスアナリシス
BABOKガイド
- 広く認められたベストプラクティス
- プロジェクトの開始前、ライフサイクル全体、運用後までを網羅
定義
- 組織の構造とポリシー業務運用について理解を深める
- ステークホルダー間の橋渡しとなるタスクとテクニックをまとめたもの
ビジネスアナリスト
役割
- ソリューションの定義と妥当性確認に関与
- ステークホルダーと連携
- プロジェクト要求を引き出す
- ビジネスを理解
- ソリューションを推進
分類
- ゼネラリスト
- スペシャリスト
- ハイブリッド
必要スキル
- ビジネス、技術、ドメインの知識
- マネジメント、人間関係、ビジネス、問題解決
- 分類
- 分析的試行と問題解決
- 行動特性
- 誠実さ、強い性格
- ビジネスの知
- ビジネスとテクノロジの橋渡し
- ソフトウェアアプリケーションの活用
- マネジメントのためにアプリケーションを利用
- 人間関係のスキル
- チームプレー
- リーダーシップ
- ファシリテーション
- コミュニケーション(情報伝達)のスキル
- プロジェクト失敗の最大の原因はコミュニケーション不足
プロジェクトマネージャーとの対比
- プロジェクト初期には、プロジェクトマネージャーがビジネスアナリストの仕事をすることが多い
- ビジネスアナリシスのチームもプロジェクトのリソースの一部
- 対立の可能性がある領域
- ステークホルダーとのコミュニケーション
- 計画
主要なステークホルダー
- 顧客
- ドメインのSME(当該分野の専門家)
- エンドユーザー
- 実装のSME
- 運用サポート
- プロジェクトマネージャー
- テスト担当者
- 帰省者
- スポンサー
- サプライヤー
知識エリア
- フェーズではない
- 順序不問
- 反復、連続可
6つの知識エリア
- ビジネスアナリシスの計画とモニタリング
- 引き出し
- タスク
- 引き出しを準備
- 引き出しのアクティビティを手動
- 引き出しの結果を文書化
- 引き出しの結果を確認
- 要求のマネジメントとコミュニケーション
- ステークホルダーに要求を伝達する方法を定義
- タスクとテクニック
- ソリューションのスコープと要求をマネジメント
- 要求のトレーサビリティをマネジメント
- 再利用に備えて要求を保守
- 要求パッケージを準備
- 要求を伝達
- エンタープライズアナリシス
- 問題の定義と分析を通じてビジネスニーズを識別し、プロジェクトを推進する
- ビジネスとして実行可能なソリューションスコープの定義
- タスク
- ビジネスニーズを定義
- 能力ギャップをアセスメント
- ソリューションアプローチを決定
- ソリューションスコープを定義
- ビジネスケースを定義
- 要求アナリシス
- ステークホルダー要求とソリューション要求を精緻化し優先順位付け
- タスク
- 要求に優先順位をつける
- 要求を体系化する
- 要求の仕様化とモデリング
- 前提条件と制約条件を定義
- 要求を検証
- 要求を妥当性確認
- ソリューションのアセスメントと妥当性確認
- タスク
- 提案ソリューションをアセスメント
- ステークホルダー要求とソリューション要求を割り当てる
- 組織の準備状況をアセスメント
- 移行要求を定義
- ソリューションの妥当性を確認
- ソリューションのパフォーマンスを評価
知識エリアの構成
- タスク
- インプット
- 要素
- アウトプット
- テクニック
- ステークホルダー
要求
- 要求の定義と文書化を通して、ステークホルダーが何を必要、期待しているかを定量化し文書化
- アプローチの決定
- 要求マネジメントプロセスの定義
- 要求の分類方法
- ブレークダウンの程度と種類
ブレークダウンの視点
- ビジネス概要要求
- ユーザー要求
- システム要求
- ソフトウェア要求
- 上位レベルの要求を詳細化
要求の分類
- 要求開発アプローチのどこかの時点ですべてに対応
スキーム
- 3つのC
- 能力(capabilities)
- 条件(conditions)
- 制約(constraints)
- 要求とは、問題を解決して目標を達成するためにユーザーが必要とする能力
- 条件は可能な結果を決定するための表現
- 制約は特定の機能または能力に対する制限あるいは限界値
要求状態マシン
- 要求が時間とともに変化する
状態
- 割り当てられた
- 分析された
- 承認された
- 伝達された
- 保守された、かつ再利用可能
- 優先順位つき
- 表明された
- 表明された、確認された
- 表明された、未確認
- トレースされた
- 妥当性確認された
- 検証された
プロジェクトへの適用
- BABOKガイドの原則やベストプラクティスをプロジェクトにマッピング
- ビジネスアナリシスの作業
ビジネスアナリシスの計画とモニタリング
焦点
- 作業にアプローチする方法を計画
- 他のビジネスアナリシスのタスクを統括
- パフォーマンスをモニタリング
タスク
ビジネスアナリシスへのアプローチを計画
- プロセス
- タスクの実行方法と実行時期の決定
- 使用するテクニックの合意
- 作成成果物の決定
- アプローチ
- 計画駆動
- 変化駆動
- 小さいイテレーション(反復)を繰り返す
- タスク
ビジネスアナリシスへのアプローチを計画
インプット
- ビジネスニーズ
- 専門家の判断
- 組織のプロセス資産
要素
- 作業のタイミング
- 成果物の公式度と詳細度のレベル
- 要求の優先順位付け
- 変更管理
- 計画プロセス
- ステークホルダーとのコミュニケーション
- 要求アナリシスと要求マネジメントのツール
- プロジェクトの複雑性
テクニック
- 決定分析
- 異なる決定をするとどうなるか結果を予測
プロセスモデリング
構造化ウォークスルー
アウトプット
ビジネスアナリシスへのアプローチ
- チームの役割と責任
- ビジネスアナリシスの成果物
- ビジネスアナリシスのテクニック
- ステークホルダーとのやり取りのタイミングと頻度
- ビジネスアナリシスのプロセスの要素
ステークホルダーの分析を主導する
インプット
- ビジネスニーズ
- エンタープライズアーキテクチャ
- 組織のプロセス資産
要素
- ステークホルダーの識別
- ステークホルダーの複雑性
- ステークホルダーの態度と影響力
- ビジネスアナリシス作業に対するステークホルダーの権限レベル
ステークホルダー分析を主導
ビジネスアナリシスのアクティビティを計画
ビジネスアナリシスのコミュニケーションを計画
要求マネジメントプロセスを計画
ビジネスアナリシスのパフォーマンスをマネジメント
成果物
- ステークホルダーのリスト、役割、責任
- ビジネスアナリシス計画
- ビジネスアナリシスへのアプローチ
- 要求マネジメント計画
- ビジネスアナリシスのコミュニケーション計画
- ビジネスアナリシスのパフォーマンスのアセスメント
コントロールされた開始の終盤になっているべき状態
- ソリューションスコープが最終決定されている
- ビジネスケースが作成され、ビジネス上の正当性が明確になっている
- 概要レベルのビジネスアナリシス計画が作成されている
- ビジネスアナリシスチームが作業を開始する準備が整っている
© 2006 矢木浩人