メディア

視点を分けて業務システムを可視化：上流モデリング研修（1）

複雑な物事は、着目する視点を分けて単純化すると理解しやすくなります。まずは業務要求をとらえてから、論理的にシステム要求を導きます。業務とシステムを共通の視点で可視化し、全体の整合性を検証します。

» 2005年04月19日 12時00分公開

[竹内正治，株式会社豆蔵　BS事業部]

　間違った業務システムを効率的に開発しても、そのシステムへの投資は無駄になってしまいます。無駄な投資を抑えるためには、業務から論理的にシステム要求を導かなければなりません。

　そのためには、業務を可視化すること、すなわち、モデリングが必要です。業務を可視化する手立てと進め方があれば、現場のコミュニケーションが活性化し、使われる、使えるシステムを開発できるようになります（図1）。

図1 業務の構成要素としてシステムを開発する（クリックすると拡大）

　モデリング技能を磨くためには、実際に自分で手を動かしてモデルを作成することが必要です。そのため、この連載では架空の会社を取り上げ、一連のシナリオに沿った演習問題の形式で、具体的にモデリングを解説していきます。

モデリングでは着目する視点が重要

　モデリングでは、着目する視点を考えることが重要です。なぜなら、業務システムは複雑で、複雑な物事を複雑なまま扱うことは困難だからです。ですから、着目する視点を分けて単純化し、理解しやすくします。例えば、地図を考えてみましょう。地図は、縮尺によってレベルが分かれています。また、道路地図や鉄道路線図など、主題に応じた種類があります。このように視点が分かれていることで、複雑な物事が理解しやすくなるのです。

　本連載におけるモデリングの枠組みを着目する視点に分けて説明します（図2）。この連載におけるモデリングとは、業務システムを特定の側面からとらえて、特定の表記法に従って図解表現することです。

図2 モデリングの枠組みを着目する視点で説明する

まずは業務レベルとシステム（*1）レベルに視点を分けます。なぜなら、システムは業務の手段にすぎませんので、システム要求は業務要求から論理的に導かれなければならないからです。まずは業務で実現すべきこと、すなわち、業務要求をとらえることが重要です。業務レベルでは、システムを捨象することで、業務要求をとらえやすくします。システムレベルは、業務の構成要素としてシステムをとらえるレベルです。ただし、システムの実装技術であるプラットフォームは捨象します。なぜなら、システムで実現すべきこと、すなわち、システム要求をとらえることが重要だからです。

*1：この連載では基本的に業務用途のコンピュータシステムの意味に限定してシステムという用語を使用します。

　業務レベルでもシステムレベルでも、着目する視点の分け方は共通です。共通の視点は、目的、プロセス、エンティティ、アプリケーション、インフラです。

　目的とは、業務システムが果たすべき働き（機能、役割、サービス）です。プロセスとは、業務システムが目的を果たすための手順です。エンティティとは、業務システムの情報要素です。アプリケーションとは、業務システムのソフトウェア機能です。インフラとは、業務システムのハードウェア資源です。

　本来、広い意味での「システム」とは、複数の要素が全体としてある目的を果たすように動作すると人間が解釈した対象のことです。そもそも「システム」という解釈には、目的（働き）、動的な振る舞い、静的な構造という視点があります。

　動的な振る舞いとは、時間軸を考慮した、「システム」の移り変わりに着目する視点です。静的な構造とは、時間軸を無視した、「システム」を構成する要素の普遍的な関係に着目する視点です。一般的に要素は、情報とソフトウェア、ハードウェアという視点で分類します。複雑な物事をこのような視点でとらえると、理解しやすくなることが経験的に知られています。

　その意味では、業務も「システム」として考えることができます。ですから、業務レベルでもシステムレベルでも、着目する視点の分け方は共通にすることができるのです。

　視点を共通にすることで、業務要求からシステム要求を論理的に導きやすくなります。

モデルは複数の図で構成される

　モデルの構成について、目的レベルを縦軸、着目する視点を横軸にして分類した表を示します（図3）。

図3 モデリングの枠組み

　業務の目的モデルとしては、プロジェクトコンテキスト図、業務コンテキスト図、目的構造図があります。プロセスモデルとしては、業務フロー図、状態遷移図、業務情報フロー図があります。エンティティモデルとしては、業務概念オブジェクト図と業務概念図があります（*2）。アプリケーションモデルとしてはシステム構成図、インフラモデルとしては組織図があります。

*2：概念という言葉は、一般的には抽象度のレベルが高いことを意味していて、静的な構造だけを意味しているわけではありませんが、本連載では、業務のエンティティモデルを概念モデルと呼びます。

　システムの目的モデルとしては、アクター図、ユースケース図、要求項目があります。システムのプロセスモデルとしては、システム化業務フロー図、状態遷移図、ユースケースデータ図があります。システムのエンティティモデルとしては、データ図、データ容量見積図、データ項目定義があります。システムのアプリケーションモデルとしては、コンポーネント図、アーキテクチャ図があります。システムのインフラモデルとしては、インフラ図があります。

　これらの図の具体的なイメージを持っていただくために、これらの図の大部分を活用したサンプル提案依頼書（RFP：Request for Proposal）を作成しました。詳細は、こちらをご覧ください。

それぞれの図にも視点がある

　モデルを構成するそれぞれの図の視点を簡単に説明します。

　プロジェクトコンテキスト図は、プロジェクトの利害関係者、すなわち、要求の発生源を漏れなく洗い出します。業務コンテキスト図は、考察の対象とする業務の範囲を明確にします。目的構造図は、コンテキスト図で洗い出した利害関係者の目的とその構造を明確にします。

　業務フロー図は、業務における作業の流れを明確にします。状態遷移図は、業務の状態の遷移を明確にします。業務情報フロー図は、業務における作業と情報の流れを明確にします。

　業務概念オブジェクト図は、業務のある瞬間における状況を具体的に説明するために必要な概念オブジェクトを明確にします。業務概念図は、業務を説明するために必要な概念を明確にします。概念モデルは、関係者間の合意を形成する用語辞書になります。

　アクター図は、業務関係者がシステムを利用する際の役割（アクター）を明確にします。ユースケース図は、システム化範囲を明確にします。要求項目は、実現すべき要求を明確にします。要求項目は属性を持ちます。要求項目の属性とは、根拠と重要度、難易度とリスク、優先度です。

　システム化業務フロー図は、業務の手段としてシステムの利用方法を明確にします。ユースケースデータ図は、ユースケースとデータの関係を明確にします。

　データ図は、システムで取り扱うデータを明確にします。データ容量見積図は、システムで取り扱うデータの規模感（最大件数）を見積もります。データ項目定義は、システムで取り扱うデータの項目を定義します。

　コンポーネント図は、システムのアプリケーション構造を明確にします。アーキテクチャ図は、システムのソフトウェア構造を明確にします。

　インフラ図は、システムのインフラ構造を明確にします。

各モデルの間には依存関係がある

　各モデルは視点が異なるだけで、そもそもの対象はある1つの業務システムですから、各モデルの間には依存関係があります。各モデル間の代表的な依存関係について説明します（図4）。

図4 各モデル間の代表的な依存関係（クリックすると拡大）

　業務フロー図は、業務コンテキスト図におけるプロセスを詳細化しています。業務情報フロー図の作業主体者は、業務コンテキスト図の利害関係者に含まれます。業務情報フロー図の情報は、業務概念図のオブジェクトに含まれます。システム化業務フロー図のシステム利用者は、アクター図のアクターに含まれます。システム化業務フロー図のユースケースは、ユースケース図のユースケースと同じです。ユースケースデータ図のユースケースは、ユースケース図のユースケースと同じです。ユースケースデータ図のデータは、データ図のデータと同じです。このように、業務レベルでもシステムレベルでも、視点は共通ですから、同じような依存関係があります。

　これらの依存関係を利用して、整合の取れたモデルに洗練していきます。

各モデル内の図にも依存関係がある

　各モデル内の図は、ある1つの業務システムを対象にしたモデルの構成要素ですから、依存関係があります。各モデル内の図の代表的な依存関係について説明します。

　プロジェクトコンテキスト図の利害関係者は、業務コンテキスト図の利害関係者をすべて含みます。なぜなら、考察の対象としている業務の関係者はすべてプロジェクトの利害関係者だからです。逆に、業務関係者ではない利害関係者も存在します。目的構造図の目的は、プロジェクトコンテキスト図の利害関係者が発生源になります。上位目的を持たない目的は、必ず利害関係者を発生源として持ちます。要求項目は、目的構造図の下端に位置します。アクター図のアクターは、業務コンテキスト図の作業主体者がシステムを利用する際の役割です。ユースケース図のユースケースは、必ずいずれかの要求項目を実現します。

　業務情報フロー図は業務フロー図に情報の流れを追加したものです。業務フロー図をすべて含みます。業務フロー図は、作業状態に着目した特殊な状態遷移図とも考えられます。システム化業務フロー図は、業務情報フロー図にシステムのユースケースを追加したものです。ユースケースデータ図のユースケースは、システム化業務フロー図のユースケースと同じです。

　業務概念オブジェクト図は業務概念図を展開したインスタンス（実例）です。業務概念図はすべての業務概念オブジェクト図をまとめて一般化したものです。データ図は、業務概念図において、システムで取り扱う概念を具体化したものです。

演習の架空会社は自動車販売会社

　この連載の演習で取り上げる架空の会社について説明します。

　会社の事業内容は自動車販売にしました。会社の規模感としては、資本金が10億円、売上高が500億円、従業員数が500人、販売店が全国に50店ぐらいをイメージしてください。フランチャイズ方式で全国に販売店を展開しています。主要な販売店は直営していますが、各販売店で独自に営業しています。

　システム化の状況としては、販売店ごとの独自システムとなっていて、システム化されている販売店は少数、ということにします。

　次回からは、この架空会社を取り上げ、一連のシナリオに沿って、演習問題の形式で個々のモデリングを解説していきます。どうぞお楽しみに。

「上流モデリング研修」バックナンバー

SpecialPR