多くの新学士課程学生は、「ビジネス アナリストはビジネス学士ですか、それともソフトウェア学士ですか?」とよく質問します。実際の答えは次のとおりです。どちらも BA ですが、範囲とアーティファクトの深さが異なります。
この 2 つの役割を誤解すると、間違った学習が発生しやすくなります。多くの Jira ツールを学びすぎても、ビジネスを理解していない人もいます。非常に優れたビジネス プロセスを作成する人もいますが、ソフトウェア チームに参加した時点では、SRS、API、UAT、欠陥トリアージが何なのかを知りません。
この記事は、より明確に理解するのに役立ちます。
＃＃１．BAとは何ですか？
3 つの業務は ビジネス上の問題に重点を置いています:
- ビジネスはどのような問題に直面していますか?
- 現在のプロセスはどこで止まっていますか?
- 主な利害関係者は誰ですか?
- どのようなポリシー、規制、KPI が決定に影響しますか?
- そのソリューションは真の価値を生み出しますか?
たとえば、保険会社は、請求処理時間を 5 日から 2 日に短縮したいと考えています。 BA は現在の請求プロセスを分析し、事件処理スタッフにインタビューし、ボトルネックを見つけ、将来のプロセスを定義し、改善の方向性を提案します。
一般的なアーティファクト:
| アーティファクト | 何を使うか |
|---|---|
| ステークホルダーマップ | 誰が影響を及ぼし、誰が決定し、誰に質問する必要があるかを知る |
| 現状 / 将来の状態 | 現在のプロセスと目的のプロセスを比較する |
| ビジネス事例 | 投資すべき理由を説明する |
| 能力マップ | キャパシティが不足している組織を確認する |
| ポリシー/ルールカタログ | レコード事業規制 |
2. ソフトウェアBAとは何ですか?
ソフトウェア BA は、ビジネス ニーズを構築可能でテスト可能なシステム要件に変換します。
ソフトウェア BA はビジネスを理解する必要がありますが、もう 1 つ上のレイヤーに進む必要があります。
- システムはどのように動作するべきですか?
- ユーザーストーリーと受け入れ基準は十分にテスト可能ですか?
- パフォーマンス、セキュリティ、可用性、アクセシビリティに関する NFR はありますか?
- どの API/データが影響を受けますか?
- エラーの場合と許可の場合は明確ですか?
- UAT はどのようなシナリオを検証しますか?
たとえば、上記の保険の問題では、ソフトウェア BA は請求受付モジュールの SRS を作成します。これには、記録入力画面、不足している書類を確認するためのルール、記録ステータス、通知、顧客情報を取得するための API、記録を表示する権限、監査ログ、および UAT シナリオが含まれます。
一般的なアーティファクト:
| アーティファクト | 何を使うか |
|---|---|
| SRS | ソフトウェア要件仕様 |
| ユーザーストーリー + AC | アジャイル バックログに要件を含める |
| BPMN/UML | フロー モデリングとシステム インタラクション |
| RTM | 要件をストーリーとテストケースまでトレースする |
| UATプラン | 企業に受け入れられたテスト計画 |
| API/データに関するメモ | 統合と検証を指定する |
3. 簡単な比較
| 基準 | ビジネス学士 | ソフトウェア BA |
|---|---|---|
| フォーカス | ビジネスの成果、プロセス、ステークホルダー | システムの動作、要件、テスト容易性 |
| たくさん働く人 | ビジネスオーナー、オペレーション、コンプライアンス、PM | PO、UX、開発、QA、アーキテクト、データ |
| 主要なアーティファクト | ビジネスケース、プロセスマップ、ルールカタログ | SRS、ユーザー ストーリー、AC、RTM、UAT |
| 知っておくべきテクニック | ファシリテーション、プロセス分析、戦略 | SDLC、API/データの基礎、NFR、テスト |
| よくある質問 | 「なぜ変える必要があるのか？」 | 「この状況でシステムは何をすべきでしょうか?」 |
重要な点: ソフトウェア BA は事業を辞めることはできません。ビジネス目標を理解していなければ、ただチケットを書いているだけになってしまいます。最終的なソリューションがデジタル製品である場合、ビジネス BA もソフトウェアを避けるべきではありません。
4. 勤務日の例
ビジネス BA
朝:
- ビジネスオーナーと一緒に運用KPIをレビューする
- ボトルネックについて運用チームにインタビューする
- 現在のプロセスを描画し、問題点をマークします
午後：
- 改善オプションを選択するためのワークショップを促進します
- 1 ページのビジネス ケースを作成する
- 関係者の懸念事項と仮定のログを更新する
ソフトウェア BA
朝:
- PO、開発、QA でユーザー ストーリーを洗練する
- 受け入れ基準とエッジケースを明確にする
- Tech Lead と API/データへの影響を確認する
午後：
- SRS、RTM、変更ログを更新
- UAT シナリオを作成する
- QA およびビジネス関係者との欠陥のトリアージ
＃＃５ まずどちらの方向から勉強するべきでしょうか？
まったく初めての場合は、次の順序で学習してください。
- ビジネス分析の基礎: 問題の枠組み、利害関係者、ビジネス プロセス。
- 要件エンジニアリング: BRD、SRS、ビジネス ルール、受け入れ基準。
- SDLC とアジャイル/スクラム: 要件がソフトウェア チームを通過する方法。
- モデリング: BPMN、UML、ワイヤーフレーム、データ フロー。
- 技術リテラシー: API、基本的な SQL、NFR、セキュリティ/プライバシー。
- 納品: バックログの改善、UAT、欠陥のトリアージ、リリースの準備。
- 評価: KPI、ダッシュボード、利益追跡。
QA または開発出身の場合は、ソフトウェア BA において有利です。ビジネス分析の基盤を追加して、チケット レベルの考え方に囚われないようにします。
運用またはビジネス ドメインの出身であれば、ビジネス上の利点があります。 SDLC、SRS、API/データ、テストを追加して、ソフトウェア チームとシームレスに連携します。
6. 練習問題
「オンライン診療予約をする」など、使い慣れた機能を選択します。
2 つの部分を書きます。
ビジネス BA の視点
- 問題の記述
- ステークホルダーマップ
- 現状のプロセス
- 将来の状態プロセス
- 成功指標
ソフトウェア BA の観点
- 5 つのユーザー ストーリー
- 各ストーリーの受け入れ基準
- 5つのビジネスルール
- 5 NFR
- 5 つの UAT シナリオ
この演習を終えると、2 つの異なる、しかし補完的な役割があることがわかります。
7. よくあるエラー
エラー 1: BA は単に議事録を作成しているだけだと考えている
BA は関係者の発言を記録するだけではありません。 BA は分析し、競合を検出し、再質問し、オプションを提案し、チームの意思決定を支援する必要があります。
エラー 2: 思考ソフトウェア BA はディープ コーディングを知っている必要があります
開発者のようにコーディングする必要はありません。ただし、明確な要件を記述するためには、API コントラクト、データ フィールド、エラー コード、権限モデル、およびテスト アプローチを十分なレベルで読んで理解する必要があります。
エラー 3: ビジネス価値を追跡せずに要件を作成している
それぞれの要件は、どのような目的に役立つのか、どのユーザーにどのような指標を提供するのか、に答えることができる必要があります。
エンドツーエンドの例: オンライン相談をスケジュールする
会社に財務コンサルティング チームがあるとします。顧客はホットラインに電話して予約を取り、スタッフはそれを Google シートに手動で入力します。問題は、スケジュールが重なっていること、顧客がスケジュールを忘れていること、そしてマネージャーがノーショウ データを持っていないことです。
ビジネス BA の成果
| パート | 良い書き方の例 |
|---|---|
| 問題文 | 顧客がホットライン経由で予約を入れるまでに平均 12 分かかります。スケジュールの 18% が誤って入力されたり、複数回変更されたりしたため、顧客サービスの負荷が増大し、相談参加率が低下しました。 |
| 事業目標 | 3 か月間、スケジュール設定に関連するホットライン通話が 40% 削減されました。ダブルブッキングを 1% 未満に削減します。出席率は 62% から 75% に増加しました。 |
| ステークホルダー | 顧客、カスタマー サービス、コンサルタント、セールス マネージャー、コンプライアンス、IT サポート。 |
| 現在のプロセス | 顧客はホットラインに電話する -> 顧客サービスチェックシート -> コンサルタントに問い合わせる -> スケジュールを入力する -> 手動でメールを送信する。 |
| 今後のプロセス | 顧客はウェブ上でコンサルタント/スロットを選択 -> スロット保持システム -> 電子メール/SMS を送信 -> カスタマーサービスは例外のみを処理します。 |
| ポリシー | 予約時間の少なくとも 4 時間前までに予約を変更できます。 4 時間未満のキャンセルはホットラインに電話する必要があります。 |
ソフトウェア BA の出力
| アーティファクト | 例 |
|---|---|
| ユーザーストーリー | 顧客として、ホットラインに電話せずにスケジュールを設定できるように、空いている相談枠をオンラインで予約したいと考えています。 |
| 合格基準 | 空のスロットが与えられた場合、顧客が予約を確認すると、システムは予約を確認済み状態で作成し、確認メールを送信します。 |
| ビジネスルール | BR-001: 確認されたスロットは他のお客様には表示されません。 BR-002: ゲストは予約時間の少なくとも 4 時間前にのみスケジュールを変更できます。 |
| データフィールド | 予約 ID、顧客 ID、コンサルタント ID、スロット ID、ステータス、チャネル、確認コード、作成済み番号。 |
| タッチポイント API | POST /appointments、 PATCH /appointments/{id}/reschedule、 GET /consultants/{id}/slots。 |
| エラーケース | スロットが他の人によって予約されたばかりの場合は、返却してください SLOT_UNAVAILABLE 3 つの代替スロットが表示されます。 |
| UAT シナリオ | お客様は正常に予約され、4 時間前に再スケジュールされました。4 時間未満で再スケジュールしてみてください。コンサルタントは今日のスケジュールを確認します。 |
注目すべきポイント: ビジネス BA は、組織が 問題、価値観、プロセス を統合するのに役立ちます。ソフトウェア BA は、構築チームが 動作、データ、ルール、API、エラー、テストを統合するのに役立ちます。
参照元
- IIBA BABOK ガイド: https://www.iiba.org/standards-and-resources/babok/
- 実務者向けの PMI ビジネス分析: https://www.pmi.org/shop/p-/book/business-analysis-for-practitioners-a-practice-guide/00101570601
- スクラムガイド 2020: https://scrumguides.org/scrum-guide.html
結論
Business BA は、組織が適切な問題を選択できるように支援します。ソフトウェア BA は、チームが適切なソリューションを構築できるように支援します。デジタル製品の優れた BA は、間違った方向に構築しないようにビジネスを十分に理解することと、要件を展開、テスト、運用できるようにソフトウェアを十分に理解することの両方を通過する必要があります。