BABOKの4つの要求

BABOKの4つの要求について考えたことをメモ。

【参考】
BABOKで“超上流”を強化する - Part2　4種類の要求を区別する：ITpro

（2/4）BABOKで“超上流”を強化する - Part3　“超上流”の標準化にBABOKを活用する：ITpro

要求の分類方法について｜ザ・プロジェクトマネジャーズ

【プロジェクトマネジメントを成功に導くビジネスアナリシス】（その1、2）

BABOKR2.0　知識エリア：　要求アナリシス

【1】発注者がベンダーにシステム開発を依頼する時、RFPにシステムの要求や要件を載せる。
しかし、RFPに何をどこまで書くべきか、あいまいな時が多い。

最悪な発注者は、自分たちが欲しいシステムの要求をRFPに書けない。
その理由は、色んな利用部門の要望を収集するうちに、どんなシステムを作るべきか、「システムのあるべき姿」を想像できないからだ。
たくさんの利用部門の要望を集めただけの要求一覧は、スコープクリープを引き起こし、コスト超過と納期遅延の結果に終わる。

そして、「システムのあるべき姿」は、発注企業の経営戦略に大きく依存する。
システムを使って何を実現したいのか、を理由付けなければ、「動かないシステム」を作るだけ。

では、それら要求をどのようにまとめればよいのか？

【2】BABOKには、4つの要求の種類がある。

・ビジネス要求
・ステークホルダー要求
・ソリューション要求
・移行要求

理解するために、絵にまとめてみた。

Babokの4つの要求 from akipii Oga

【2－1】ビジネス要求は、組織全体としてのビジネス目標、ニーズ、戦略目標。
プロジェクトを開始した理由、プロジェクトを達成しようとする目標、成功度を測定するメトリクスなど。
例：来年度の第1四半期末までに、販売管理業務のコストを2割削減したい

【2－2】ステークホルダー要求は、利用部門などのステークホルダーの個別のニーズ。
ステークホルダーのニーズとソリューションとの関わり。
例：取り扱い品目の変更に伴う作業の手間を減らしたい

【2－3】ソリューション要求は、機能要求と非機能要求がある。

・機能要求
ビジネス要求やステークホルダー要求を具体化するのに必要な機能、業務、システムが実現すべき機能。
例：すべての社内システムの品目マスターを一括変更できるようにしたい

・非機能要求
ビジネス要求やステークホルダー要求を具体化するのに必要な機能、業務、システムが実現すべきキャパシティ、性能、セキュリティ、可用性、ユーザビリティなど。
例：毎週月曜日の朝9時に、前日まで1週間分の売り上げや在庫のデータを分析できるようにしたい

【2－4】移行要求は、現状(AsIs)からあるべき姿(ToBe)への移行を円滑に進めるためにソリューションが満たすべき条件。
ソリューションのアセスメントと妥当性確認を通じて作成し、定義する。
スケジュールに関する要求が多い。
例：今年度の第3四半期中に組織の体制を見直し、第4四半期に新しい業務とシステムを試行する

【3】RFPに書くべき要求は、ビジネス要求とステークホルダー要求だ。
経営戦略に基づくビジネス要求が根本にある。
ビジネス要求を満たすべく、ステークホルダー要求やソリューション要求などがある。

そして、利用部門や情報システム部などの各ステークホルダーからの要求は、ステークホルダー要求にまとめる。
但し、何でもかんでも乗せると、見積りが高くなってしまい、予算をオーバーしがち。
いかにスコープを確定して、ステークホルダー要求を絞り込むか、が必要になる。

システムで実現すべきソリューション要求、現状の業務を新システムへ移行する移行要求は特に書く必要はない。
但し、移行スケジュールを提示するなら、移行要求は書いた方が、ベンダーもスケジュールに沿った見積を作ってくれる。

要求を4種類に分けて書くように意識したら、RFPも書きやすくなるような気がする。

【3】4種類の要求のうち一番難しいのは、ビジネス要求だ。

BABOK　2.0　エンタープライズアナリシス

(引用開始)
ビジネスアナリシスの真骨頂です。この知識エリアがBAの価値を決めると言っても過言ではありません。
ソリューションを開発する真の理由（ビジネスニーズをベースにしたものでWHYに相当します）を明確にします。
ビジネス機会（または課題/問題）を明確にし、競合との差別化、理想の状態（ToBe）と現状（As_Is）とのGAP、GAPを解消するソリューション、ビジネスの収入増、コスト（ソリューション開発による）、そして最終利益を明確にし、ソリューション開発の最終判断の材料（をまとめたものをビジネスケースといいます）をスポンサーに提供します。
そしてスポンサーは必要なソリューションへの投資を決断するのです。
どれだけ魅力的なビジネスケースを書けるかはビジネスアナリストの腕前次第と言えます。

他の知識エリアとの決定的な違いがあります。
他の知識エリアのタスクは、一定以上のレベルのビジネスアナリストなら似た結果が出てきます。
しかしこの知識エリア（エンタープライズ分析）では、ビジネスアナリスト個人への依存度がかなり高いという特徴があります。
同じ現状を分析した結果、効果予測が収益30%増のソリューションもあれば、100%増のソリューションもありえます。必要な投資額も異なります。
スポンサー/組織にもよります。
ハイリスクハイリターンを好むスポンサー/組織もあれば、ローリスク・ローリターンを好む堅実的なスポンサー/組織もあります。
スポンサー/組織によってソリューション内容（アプローチを含めて）を柔軟に考える必要があります。ビジネスアナリストはそれらに柔軟に対応できなければいけません。
(引用終了)

組織が目指すべき経営戦略とその実現方法には、たくさんの観点がある。
どれが正しいというわけでもない。
ハイリスクハイリターンを好む組織もいれば、ローリスク・ローリターンを好む組織もいる。
スタートアップ企業やWebサービス企業なら全社だろうし、製造業や農業のような業界なら後者が多いだろう。

すると、その経営戦略に基づくビジネス要求も変わってくる。
ハイリスクハイリターンならば、最新の技術にチャレンジするやり方を取る時もあるだろう。
ローリスクローリターンならば、枯れた技術で安く仕上げるやり方を選ぶ時もあるだろう。

ビジネス要求を見定めるのは、アナリストの腕で相当に変わってしまうわけだ。