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

 Part1では,モデリングの意義や,そもそもモデリングとはどういうことかなど,モデリングに関する一般的なことを解説しました。

 Part2では,演習編に向けての準備として,本講座で実施するモデリングの全体像を説明します。また,本講座では,モデリングの具体的な成果物として,RFP(Request For Proposal:提案依頼書)を取り上げますので,RFPの入門的な知識も解説します。

 Part1でも説明したように,RFPはユーザーが作成するものですが,本講座で想定しているレベルのRFPは,実質的にはベンダーのITエンジニアが作成していることが少なくないので,多くのITエンジニアに参考にしていただけると思います。

着目する視点を考える

 モデリングでは,着目する視点を考えることが重要です。業務システムは複雑で,そのまま理解することは困難なので,着目する視点を分けて単純化し,理解しやすくします。ただし,業務システム自体が単純になったわけではなく,単に着目する部分を絞っているだけです。業務システム自体が複雑であることに変わりはありませんので,注意が必要です。

 例えば,地図を考えてみましょう。地図は,縮尺によってレベルが分かれています。また,道路地図や鉄道路線図など,主題に応じた図があります。このように縮尺や主題といった視点があることで,複雑な物事が理解しやすくなります。

 それでは,本講座におけるモデリングの枠組みを,着目する視点に分けて説明します(図1)。個々の視点は一般的なものですが,この枠組み自体は,本講座におけるモデリングの全体像を説明するために,筆者が記述したものです。

図1●モデリングの枠組み<br>着目する視点で分類したモデルの構成を示します。モデルは複数の図で構成されます
図1●モデリングの枠組み
着目する視点で分類したモデルの構成を示します。モデルは複数の図で構成されます
[画像のクリックで拡大表示]

まずは業務要求をとらえる

 まず業務レベルとシステムレベルに視点を分けます。システムは業務の手段に過ぎませんので,システム要求が業務要求から論理的に導かれるようにモデルを利用します。

 業務レベルでは,システムを考慮しないことで,業務で実現すべきこと,すなわち業務要求をとらえやすくします。

 システムレベルでは,業務の構成要素としてシステムをとらえます。ここではシステムで実現すべきこと,すなわちシステム要求を把握することが重要なので,システムの実装技術であるプラットフォームは考慮しません。

 業務レベルの方がより上位の目的レベルになりますので,図1ではシステムレベルの上に記述しました。

共通の視点でとらえる

 業務レベルでもシステムレベルでも,着目する視点は共通です。われわれは,目的,プロセス,エンティティ,アプリケーション,インフラの5種類に分けています。レベルによらない共通の視点ですので,図1では横方向に分類しています。

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

 本来,広い意味での「システム」とは,複数の要素が全体としてある目的を果たすように動作する,と人間が解釈した対象のことです。そのとき人間はその対象を,働き(目的),動的な振る舞い(プロセス),静的な構造(エンティティ)という視点でとらえています。

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

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

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