ユーザー企業側にビジネスアナリスト（BA）が必要な理由
加藤桂子
多くの企業で見られるのが、ユーザー企業側にビジネスアナリスト（BA）が不在のまま進むプロジェクトです。
開発ベンダーは要件定義フェーズから参画することが多いと思いますが
しかしその前段階――
- ニーズの引き出し
- 課題の整理
- 優先順位の検討
が十分に行われないまま、プロジェクトが始まることがあります。
その結果、現場から上がってくる「要望」が、
検討されないまま「要求」になり、
さらにそのまま「要件」として扱われていきます。
要望・要求・要件の区別が曖昧なまま進むプロジェクトは途中で迷走しやすくなります。
■家を建てるときの話
家を建てるとき、いきなり建築士に「設計してください」と依頼することはありません。
まず家族で話し合います。
- なぜ家を建てたいのか
- どんな暮らしを実現したいのか
- 譲れない条件は何か
- あったら良いものは何か
- 予算はいくらか
- 場所はどこか
これらを整理せずに設計に進めば、希望はぶつかり合い、設計変更が繰り返され、
最終的には予算を超えてしまうかもしれません。
■ITプロジェクトも同じ構造
ITシステム導入も本質は同じです。
- なぜこのプロジェクトを行うのか
- どんな状態を目指すのか
- 譲れない条件は何か
- 制約は何か
- 予算はどこまでか
これらを整理せずに「プロジェクトを進めたい」と開発ベンダーに依頼すれば、
各部門からの要望が積み上がり、スコープは膨らみ続けます。
結果として、予算超過やスケジュール遅延につながります。
■だからこそユーザー企業側にBAが必要
BAは、下記の役割を担います。
- 要望をそのまま要件にしない
- 背景にあるニーズを問い直す
- 優先順位を整理する
- 制約条件を明確にする
家づくりでいえば、家族の考えを整理し、「本当に大切なこと」を言語化する存在です。
その整理があって初めて、要件定義は意味を持ちます。
■開発ベンダー任せではなく、主体的に整理する
「ニーズ整理は、要件定義の中で開発ベンダーが行うもの」と考える企業も少なくありません。
もちろん、開発ベンダーが整理を支援することは可能です。
外部の視点は、むしろ有効に働くこともあります。
しかし、自社の文化や業務の実態、暗黙知を最も深く理解しているのはユーザー企業自身です。
だからこそ、ニーズ整理を“自社の責任として行う”ことに意味があります。
その整理があって初めて、開発ベンダーと実施する要件定義が機能し、
その後の設計・開発がぶれずに進むのです。
■まとめ
要望がそのまま要件になってしまう組織では、プロジェクトは迷走しやすくなります。
目的を整理し、優先順位をつけ、価値につながる形に翻訳する。
その役割が存在しているかどうかが、プロジェクトの質を左右します。
それが、ユーザー企業側におけるビジネスアナリストの意味です。
