社会・産業のデジタル変革

システム構築はビジネス分析から始まる

公開日:2026年3月23日

独立行政法人情報処理推進機構
デジタル基盤センター デジタルエンジニアリング部
ソフトウェアエンジニアリンググループ

  • SLCPを知る、学ぶ、国際規格SLCPの進化とそのポイント

概要

SLCP国際規格の2015年版(JISでは2020年版)から「ビジネス又はミッション分析プロセス(Business or Mission Analysis process)」が追加されています。このプロセスは、開発前の概念段階の初期に相当する超上流段階において、ビジネスまたはミッション上の問題または機会(“機会”はJISの用語であるが、分かり易く言えばビジネスのチャンス)について分析するものです。その結果として、問題を解決又は機会を活用するための複数の方策案を評価し、それらを実現するためにシステム構築の検討に入ることになります。要するに、ビジネスに関わる問題やチャンスを見つけ、それを解決したり活かしたりする方法を考えるプロセスということになり、システム構築の始まりに位置づけられます。SLCPの「ビジネス又はミッション分析プロセス」の実施に際しては、ビジネス分析について体系的に解説しているビジネスアナリシスの知識体系(BABOK)ガイドが参考になります。本稿では、BABOKを参考にしたビジネス分析の一例を紹介します(注釈1)。

目次

1. ビジネス分析プロセスの重要性

デジタル時代が進み、ITが経営(ビジネス)に占める割合はますます高まっています。経営が求める価値をITによってどのように実現するかを方向づけるために、ビジネス分析を行います。すなわち、ビジネス分析はどの企業も当然行うべき普通のことなのです。

ビジネス分析は、ITの分野においては主に超上流工程にあたるもので、ビジネスの目標・戦略からITへの要求を導くためのプロセスです。ITシステム開発がうまくいかない主要な理由として、要件定義の不十分さや要件決定の遅延にあると言われ続けています。たとえば、次のような事例が聞かれます。

  • システム設計の途中で、ある要求の実現方法がシステム導入効果に見合わない多大なコストを要することが判明した
  • システム開発のテスト段階で業務の実態と合わないことが判明した
  • 開発したシステムを導入した後でもビジネス目標達成の見通しが得られないために調べてみると、現行の機能・性能では不十分であることが判明した
  • 特定の利害関係者のチャンスに関わる分析と対応を十分に行わなかったことから、その利害関係者はせっかくのビジネスチャンスを逃してしまった

このような問題を起こさないように要件定義を適時適切に行うためには、ITへの要求を的確に把握することが重要です。すなわち、ITを導入する目的、IT導入により創出したい価値という真のニーズを系統的に明らかにする必要があります。そのための主要な活動がビジネス分析です。なお、現在のITシステム開発では、ユーザー企業/ベンダー企業の役割に境界を設けることが必ずしも適切でない状況もあり、1つのプロジェクトチームの中にビジネスアナリストを含む体制も考慮されるべきでしょう。

2. ビジネス又はミッション分析プロセスの概要(注釈2)

「ビジネス又はミッション分析プロセス」は、ビジネスに関する次の事項を目的とします[参考文献1]。

  • どのような大きな問題やチャンスが存在しそうなのかを明確化すること
  • その問題を解決できそうな/チャンスを活用できそうな方法の方向性を整理すること
  • 実際に役立ちそうな解決/活用策を一つ以上見つけること

そして、同プロセスでは、次のアクティビティ及びタスクを実施します。

a) ビジネスやミッション分析の準備をする

  1. 組織の「ミッション(使命)」「ビジョン(将来像)」「ゴールや目標」を踏まえ、どのような問題やチャンスがあるかを確認する
  2. 分析をどのように進めるか、その進め方の戦略を決める
  3. 分析を助けるために必要なシステムやサービスを見つけ、準備する
  4. 必要なシステムやサービスを実際に手に入れる、または使えるようにする

b) 問題やチャンスの範囲を決める

  1. 問題やチャンスを、コストや効果などのトレードオフを考えながら分析する
  2. 解決すべき問題や活かすべきチャンスを、ミッションやビジネスの観点から明確化する
  3. 他のビジネス上のニーズと比べ、どの問題やチャンスを優先するかを決める

c) 解決策の方向性を整理する

  1. システムがどう動くか、ライフサイクルの基本的なイメージを作る
  2. 実現できそうな解決策の種類を広げ、いくつかの代替案を見つける

d) 複数の解決策を評価する

  1. 見つけた代替案を一つずつ評価する
  2. その中からより良いと思える解決策を選ぶ
  3. 選んだ解決策を、組織の戦略やライフサイクルの考え方に反映させる

e) ビジネスやミッション分析を管理する

  1. 分析の中で行った重要な決定やその理由を記録に残す
  2. 分析の内容と選んだ解決策の間につながり(トレーサビリティ)を保つ
  3. 今後の基準(ベースライン)として使えるように、重要な成果物をまとめて提供する

3. ビジネスアナリシスの知識体系(BABOK)ガイド

ビジネス分析(ビジネスアナリシス)を進めるための実践知識を体系化したグローバル標準として「BABOK(Business Analysis Body of Knowledge)Guide」[参考文献2]があります。BABOKガイドは、国際的な非営利団体であるIIBA(International Institute of Business Analysis)により発行され、最新版はv3.0(2015年公開)となっています。

3.1 BABOKの概要

BABOKガイドによれば、「ニーズを定義し、ステークホルダーに価値を提供するソリューションを推奨することにより、エンタープライズ(企業)に変革(チェンジ)をもたらす専門活動」をビジネス分析と定義しています。すなわち、企業の抱える問題や潜在するチャンスを客観的に分析し、的確な根拠に基づいた解決/活用策を提案・実行支援する活動、ということになります。表現は異なりますが、SLCPの「ビジネス又はミッション分析プロセス」の目的と同様です。

BABOKガイドでは、ビジネス分析に関する6つの基本概念を「ビジネスアナリシス・コアコンセプトモデル(BACCM:Business Analysis Core Concept Model)」として定めています[参考文献3]。このモデルには、ビジネス分析とは何であるかとともに、ビジネス分析のタスクの実践者の観点や、属する業界、実践する方法論、組織中の位置付けにかかわらず、実践者にとってビジネス分析が何を意味するかが含まれています。

  • チェンジ:
    • ニーズに対応して変える(トランスフォーメーション)行為
  • ニーズ:
    • 対処すべき問題または機会(チャンス)
  • ソリューション:
    • あるコンテキストにおいて、一つ以上のニーズを満たす具体的な方法
  • ステークホルダー:
    • チェンジ、ニーズ、ソリューションと関係を持つ個人やグループ
  • 価値:
    • あるコンテキストにおける、ステークホルダーに対する値打ち、重要性、有用性
  • コンテキスト:
    • チェンジに影響を及ぼし、チェンジから影響を受ける状況。これによりチェンジを理解することができる周囲環境

3.2 BABOKの知識エリアとタスク概要

BABOKでは、上記のコアコンセプトの定義を明らかにし、ビジネスのチェンジを進めていくために必要な6つの知識エリアに、ビジネス分析の専門的で具体的な知見をまとめています。それぞれの知識エリアのタスク概要を紹介します。

  • ビジネスアナリシスの計画とモニタリング:
    • ビジネスアナリストとステークホルダーの活動を整理し全体を計画する。また、ビジネスアナリシス作業をマネジメントしモニタリングする。
  • 引き出しとコラボレーション:
    • ステークホルダーやその他の情報源から要求やデザインに関する情報を引き出し、その結果を確認する。また、ビジネスアナリシス活動全体を通じてステークホルダーに情報を伝達し、継続的にコラボレーションする。
  • 要求のライフサイクル・マネジメント:
    • 要求とデザインの情報を発生から廃棄までマネジメントし、維持する。また、関係づけられている要求とデザインに対して変更が生じる場合は評価・分析・合意形成を行う。
  • 戦略アナリシス:
    • 現状を分析し、ビジネスニーズに対処するために必要な将来状態とそれへの移行状態を定義する。
  • 要求アナリシスとデザイン定義:
    • 引き出された要求を構造化・整理し、要求やデザインを仕様化・モデル化し、情報を検証して妥当性を確認する。ビジネスニーズを満たすソリューションの実現方法を特定し、それぞれの潜在価値を見積もる。
  • ソリューション評価:
    • ソリューションのパフォーマンスを実際に測定し、提供する価値を評価し、価値実現を妨げる障壁や制約条件の除去を推奨する。

3.3 BABOKのタスク

6つの知識エリアには、下記に示す複数のタスクが組み込まれています。ここでのタスクとは「ビジネス分析の一環として公式または非公式に実行される、ビジネス分析を構成する個々の業務」とされています。

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

「ビジネスアナリシスの計画とモニタリング」は、ビジネスアナリストとステークホルダーのビジネスアナリシス作業を連携させるために行います。タスクのアウトプットは、ビジネスアナリシス全般のガイドラインとして使われます。

  • ビジネスアナリシス・アプローチを計画する
  • ステークホルダー・エンゲージメントを計画する
  • ビジネスアナリシス・ガバナンスを計画する
  • ビジネスアナリシス情報マネジメントを計画する
  • ビジネスアナリシス・パフォーマンス改善策を特定する
(2) 引き出しとコラボレーション

「引き出しとコラボレーション」により、ステークホルダーや他の情報源から要求やデザインに関する情報を発見し、アナリストとステークホルダーがビジネス分析のための情報を相互に理解して合意点を見い出せるようにします。

  • 引き出しを準備する
  • 引き出しを実行する
  • 引き出しの結果を確認する
  • ビジネスアナリシス情報を伝達する
  • ステークホルダーのコラボレーションをマネジメントする
(3) 要求のライフサイクル・マネジメント

「要求のライフサイクル・マネジメント」は、ビジネス、ステークホルダー、ソリューションの要求とデザインを整合させて、ソリューションがそれを確実に実現できるようにするために行います。

  • 要求をトレースする
  • 要求を維持する
  • 要求に優先順位を付ける
  • 要求変更を評価する
  • 要求を承認する
(4) 戦略アナリシス

「戦略アナリシス」は、戦略的または戦術的に重要なビジネスニーズを特定してエンタープライズがそのニーズに取り組めるようにし、その結果から得られるチェンジ戦略を上位及び下位の戦略に整合させるために行います。

  • 現状を分析する
  • 将来状態を定義する
  • リスクをアセスメントする
  • チェンジ戦略を策定する
(5) 要求アナリシスとデザイン定義

「要求アナリシスとデザイン定義」は、ビジネスニーズを満たし最大の価値を生み出す最適なソリューション選択肢を推奨するために行います。ビジネスアナリストがニーズ、要求、デザイン、ソリューションをモデリングすることは、他のステークホルダーとのコミュニケーションに役立ちます。

  • 要求を精緻化しモデル化する
  • 要求を検証する
  • 要求の妥当性を確認する
  • 要求アーキテクチャーを定義する
  • デザイン案を定義する
  • 潜在価値を分析しソリューションを推奨する
(6)ソリューション評価

「ソリューション評価」は他の知識エリアと異なり、部分的であっても実際のソリューションに対して行います。これはベネフィットの実現を支援するもので、チェンジ開始前、ソリューション開発中、開発後いずれの段階においても適用され得ます。

  • ソリューション・パフォーマンスを測定する
  • パフォーマンス測定結果を分析する
  • ソリューションによる限界を評価する
  • エンタープライズによる限界を評価する
  • ソリューションの価値を向上させるアクションを推奨する

4. ビジネス分析の実施

以上の情報を前提とし、BABOKガイドを参考に、ビジネス分析を行う際のヒントを記します。

4.1 SLCPのアクティビティ・タスクとBABOKのタスクとの関係(注釈3)

ここでは、BABOKガイドが示すタスクを実施することにより、SLCPのビジネス分析プロセスを遂行することを検討します。そのため、JIS X 0170:2025 (ISO/IEC/IEEE 15288:2023) の6.4.1 「ビジネス又はミッション分析プロセス」のアクティビティ・タスクと、BABOKガイドの各知識エリアのタスクとの対応付けを試みます。

両者は分類の観点が異なることから、SLCPの各タスクはBABOKガイドの複数の知識エリアにまたがって対応しています。一例として、JIS X 0170:2025 のアクティビティとBABOKガイドの知識エリア・タスクとの対応関係の例を以下に示します。

JIS X 0170:2025 のアクティビティとBABOKガイドのタスクとの対応関係例
JIS X 0170:2025  6.4.1
アクティビティ/タスク
BABOKガイドv3
知識エリア/主な関連タスク例
a)ビジネス又はミッション分析の準備を行う
(1)ビジネスアナリシスの計画とモニタリング
(2)引き出しとコラボレーション
a-1)組織戦略・運用概念の変化をレビューする
(2)引き出しとコラボレーション
-引き出しを準備する
-引き出しを実行する
-引き出しの結果を確認する
a-2)分析戦略を定義する
(1)ビジネスアナリシスの計画とモニタリング
-ビジネスアナリシス・アプローチを計画する
-ステークホルダー・エンゲージメントを計画する
-ビジネスアナリシス・ガバナンスを計画する
-ビジネスアナリシス情報マネジメントを計画する
a-3)必要なイネーブリングシステム/サービス
を識別し計画する
(対応無し)
a-4)イネーブリングシステム/サービスを入手
/アクセスを取得する
(対応無し)
b)問題又は機会の空間を定義する
(4)戦略アナリシス
(3)要求のライフサイクル・マネジメント
b-1)問題・機会を分析する
(4)戦略アナリシス
-現状を分析する
b-2)問題・機会を定義する
(4)戦略アナリシス
-将来状態を定義する
b-3)問題・機会を優先付けする
(3)要求のライフサイクル・マネジメント
-要求に優先順位を付ける
c)ソリューション空間を特徴付ける
(5)要求アナリシスとデザイン定義
c-1)予備的な運用概念・ライフサイクル概念を
定義する
(5)要求アナリシスとデザイン定義
-要求アーキテクチャーを定義する
c-2)代替ソリューションのクラスを識別する
(5)要求アナリシスとデザイン定義
-デザイン案を定義する
d)代替ソリューションのクラスを評価する
(5)要求アナリシスとデザイン定義
d-1)各代替ソリューションをアセスメントする
(5)  要求アナリシスとデザイン定義
-潜在価値を分析しソリューションを推奨する
d-2)好ましい代替ソリューションを選定する
(5)要求アナリシスとデザイン定義
-潜在価値を分析しソリューションを推奨する
d-3)戦略レベルのライフサイクル概念へフィー
バックする
(対応無し)
e)ビジネス又はミッション分析をマネジメントする
(1)ビジネスアナリシスの計画とモニタリング
(3)要求のライフサイクル・マネジメント
e-1)決定と根拠を記録に残す
(1) ビジネスアナリシスの計画とモニタリング
-ビジネス  アナリシス情報マネジメントを計画する
e-2)トレーサビリティを維持する
(3)要求のライフサイクル・マネジメント
-要求を維持する
-要求をトレースする
e-3)ベースラインのための作成物を提供する
(3) 要求のライフサイクル・マネジメント
-要求を承認する

上表から、SLCPの6.4.1 「ビジネス又はミッション分析プロセス」は BABOKガイドの知識エリアを横断的にカバーした形になっており、特に「戦略アナリシス」「要求アナリシスとデザイン定義」「要求のライフサイクル・マネジメント」が対応していることが分かります。

4.2 BABOKを参考にしたビジネス分析

SLCPの6.4.1 「ビジネス又はミッション分析プロセス」がプロセスフレームワーク(枠組み)を提供するのに対し、BABOKガイドはビジネス分析を実践するための詳細な手法・知識体系(具体的なやり方)を提供することから、両者は相互補完的な関係にあります。すなわち、両者のタスクは1対1には対応しないものの、異なる多様な視点からのタスク実施と確認が可能となります。

したがって、たとえば、上記で例示したタスク対応関連表をチェックリストのような形にして利用することにより、次のような効果が期待できます。

  • SLCPの「ビジネス又はミッション分析プロセス」の各アクティビティを実施する際に、対応するBABOKガイドのタスクを漏れなく確認できる
  • プロジェクトのレビューや監査時に、「どのタスクを実施したか」のチェックが可能になる

5. おわりに

ビジネス分析は、一般に、全社レベルと各事業部レベルなど複数の階層で行われます。したがって、「ビジネス又はミッション分析プロセス」は各階層で再帰的に適用されます。ただし、ビジネス分析においては、各階層内に閉じた議論・検討のみならず、階層間のコミュニケーションがより重要となります。

また、「ビジネス又はミッション分析プロセス」と関連の深いSLCPの「利害関係者ニーズ及び利害関係者要件(要求事項)定義プロセス(stakeholder needs and requirements definition process)」、「システム要件(要求事項)定義プロセス(system requirements definition process)」、「システムアーキテクチャ定義プロセス(system architecture definition process)」などの適用の結果として、相互にフィードバックがよく行われます。すなわち、これらのプロセスは反復的に適用されることになります(注釈4)。より具体的には、ビジネス分析は、ユーザー企業の経営部門、ITシステム部門、及びベンダー企業の三者が共通に実践すること(common practices)であり、この三者が1回のサイクルでビジネス分析を完了とするのではなく、何度も分析サイクルを繰り返すことが必要となります。

注釈

  1. (注釈1)
    本稿では説明しませんが、BABOKの他に、次の文書も同様に参考にすることができます。
  2. (注釈2)
    現場の担当者が容易に理解できると共に、読みやすいものとなることを考慮し、平易な表現とするためにCopilotの支援を得ました。ただし、より厳密に知りたい場合には、原文を確認願います。
  3. (注釈3)
    タスク間の対応付けにはCopilotの支援を得ました。
  4. (注釈4)
    たとえば、「ビジネス又はミッション分析プロセス」の実施後に「利害関係者ニーズ及び利害関係者要件(要求事項)定義プロセス」で利害関係者を識別した後、再び「ビジネス又はミッション分析プロセス」を実施して、特定の利害関係者に関わるチャンスについてより精緻に分析するケースが想定されます。このようなケースにおいて十分な分析を怠ると、「1. ビジネス分析プロセスの重要性」に記した最後の事例のような問題が発生することになります。

参考文献

  1. JIS X 0170:2025システムライフサイクルプロセス(ISO/IEC/IEEE 15288:2023), 日本規格協会.
  2. BABOK®ガイドv3 日本語版, IIBA日本支部.
  3. BA(Business Analysis)とは, IIBA日本支部.

お問い合わせ先

IPA デジタル基盤センター
デジタルエンジニアリング部 ソフトウェアエンジニアリンググループ

  • E-mail

    disc-infoアットマークipa.go.jp

更新履歴

  • 2026年3月23日

    公開