連載
【改訂版】初歩のUML

第11回
UMLモデリングの開発過程
（ビジネスモデリング編）

萩本順三　株式会社豆蔵
2003/11/15

　第10回「開発プロセスの上手な組み合わせ」では、開発プロセスと開発フェイズ（注1）について説明しました。さて、開発フェイズが進んでいくうちに、UMLベースのモデルはどのように変化するのでしょうか。その変化とは、詳細化のための変化でしょうか、それとももっと別の変化なのでしょうか。今回は、UMLを使ったビジネスモデリング手法の基礎を説明します。特にビジネスモデリングにおけるアクティビティ図の利用法について詳しく説明していきます。そして、次回は開発段階におけるモデリング手法についての説明を行う予定です。

　いよいよ「初歩のUML」もクライマックスを迎えます。もう一息でゴールです。頑張って読み進めてください。

（注1）　分析、設計、実装、テストのようないわゆる工程。UP（Unified Process）、RUP（Rational Unified Process）では、ワークフローまたは「Discipline＝ディシプリン」と第10回で説明しましたが、ここでは説明を簡略化するためにフェイズと表現します。

モデルは進化する

　UMLベースのモデルはソフトウェアとして動作可能な構造に進化していきます。ここで、進化という言葉が正しいか分かりませんが、UMLのモデルはそれぞれのフェイズの目的に合わせて作成されます。そして、そのモデルは、次のフェイズに進む際に、次のフェイズの目的に合わせて進化していくのです。ここで、進化という表現をあえて使う理由を述べましょう。

　UMLのモデリングの最終ゴールには、実行可能なソフトウェアを作成するためのソフトウェア構造を示すことが求められます。よって、この最終ゴールに適応できるようにモデルが徐々に変化していくのですが、その変化の各過程でも、ソフトウェア開発にさまざまな効果をもたらします。開発フェイズが進んでいくうちに、UMLモデルが徐々に詳細化されるというとらえ方だけではモデリングという行為の正しい理解につながりません

　進化という表現の意図は、各過程において状況に適応するようにモデルの作成意図、対象、内容が変化していくということを理解していただくために使っています。これは、単に情報を増やす（詳細化する）ことが目的ではないというわけです。各フェイズの中で定義された目的に合わせてモデルで表現する内容を変化させる必要があります。もちろん、それぞれのフェイズ内において、モデルは徐々に詳細化されていきます。しかし、次のフェイズに移り変わると同時に、そのフェイズの目的に合わせて、対象領域と取り上げるモデルの内容が変化することを理解しなければなりません。

　ただし、よくできた開発プロセス（または方法論）の各フェイズの目的と観点は、「ビジネス分析、要求分析、システム分析、システム設計、実装、テスト（注2）」といった流れに沿って、徐々に、実装アーキテクチャに最適な実装構造を表現するモデルへと自然と誘っていけるよう設計されています。

（注2）　実装テストでは、モデルを反映させたプログラムコードが対象となり、モデルは参照されます。

　下記の表は、開発フェイズのモデルと目的・観点を対応させた表です。

フェイズ名	ビジネス分析	要求分析	システム分析	システム設計	実装・テスト
作成モデル	ビジネスモデル	ユースケースモデル	分析モデル	設計モデル	×
観点	Why	What	What→How	How	How
目的	ビジネスの現状把握 とIT化戦略分析	要求の理解	要求の概念構造の理解	設計構造の理解 最適な実装構造の表現	動作可能
表1 開発フェイズとUMLモデル

　図1は、フェイズが遷移する中、どのようにモデルが変化するかを示しています。この図は開発にかかわるすべてのモデルを示すものではありませんが、特に注目してほしい個所があります。それは、ユースケースの使われ方です。ユースケースからクラス図を作るという手法を学んでいる読者も多いと思います。しかし、実はユースケースを作成する前、つまりビジネス分析の段階から、クラス図を使ってビジネスの中に存在する重要な概念構造を表していく必要があります。

図1 フェイズの遷移とモデルの変化

　このような方法から、システム開発で使われるユースケース（注3）を見ると、 その働きは、システムの要求の範囲を明確にすることです。これにより、ビジネス分析時に現状理解から理想的な概念構造を理解するという目的で作成されたクラス図の中から、システムの開発対象になる部分を抽出することです。そうして作成されるクラス図がシステム分析のアウトプットとなります。

（注3）　ここでは取り上げていませんが、システム開発で使われるユースケースのほかにビジネスユースケースというものがあります。ビジネスユースケースは、ビジネス全体のサービスと、ビジネスを関与するアクターの関係として記述するものです。

　この考え方を理解していないと、ユースケースから分析モデル（システム分析に おけるクラス図）を作成することになりますので、ユーザーから見た利用事例単位に分析モデルが出来上がってしまいます。これでは、対象問題の概念把握というクラス図の目的から外れ、かなりいびつなものとなってしまいます（注4）。

（注4）　【ユースケースから作成される分析モデル】
ユースケース単位に作成されるクラスは、VOPC（View Of Participating Classes）と呼ばれます。このようなクラス図は、ユースケースの説明を機能的に行うのではなく、概念構造に照らし合わせて行う場合には有効となるでしょう。しかし、さらにVOPCを有効に利用するには、1つのユースケースではなく、問題領域の概念を中心にいくつかのユースケースをまとめて説明するという工夫が必要となります。

　ビジネスの現状把握やビジネスアイデアを含んだ理想のモデルを考えないうちに正しい要求など出せるはずがありません。ユースケースモデルを作成する前に、ビジネス分析モデルのクラス図があるというのはごく自然なことなのです。つまり、ビジネス分析で作成されたクラス図からユースケースという要求範囲のスコープを通して分析モデルを作成するという手順を理解する必要があります。そうすることで、ITビジネスにとって理想的なモデルから、予算・コスト・期間を考慮した分析モデルに移し変えることができます。

フェイズの説明

　さっそくですが、ここからは各フェイズの中でどのようにモデルが進化するのか、その中身をのぞいていきましょう。今回はビジネスモデリング編ですので、開発を行う前のフェイズ「ビジネス分析フェイズ」に着目します。

◎ビジネス分析フェイズ

　物事は単純化しない限り本質が見えないものです。では、ビジネスを分析するということを単純化したらどうなるのでしょうか。ここでは、オモチャを母親におねだりする子どもを例に、このことを考えてみましょう。

（A）まずは、オモチャの値段と自分の財布を調べ、お金が足りないことを知ります。

（B）次に、足りないお金を、お母さんにオネダリすることを考えます。

（C）また、お母さんにどういえば足りないお金をもらえるか考えます。

（D）お母さんに「出世返しするのでお金ちょうだい！」と頼みます。

（E）お母さんは買いたいオモチャのカタログを見て、もう少し安いものにしたら「ン百円」出してあげるといいます。

（F）子どもは、仕方なく自分のお金とお母さんからもらったお金で安い方のオモチャを買うことを考えます。

表2 子どものオモチャ・オネダリモデル

　この子どもの話は、ビジネス分析の過程を単純に表しています。まず、子どもは自分が何をやりたいのか、また、現状ではそれができるのかという状況を把握します（現状分析：Aの部分に該当）。次に子どもはどのようにしてオモチャを買うかという理想的な戦略を立てます（戦略分析：B〜D）。ところがどっこい、お母さんから難題を突きつけられます。結局この子どもは、安いオモチャを買うことで、自分の目的を果たすことになります。この表のEとFは期間コストを考慮してシステムの要求を抽出するという部分（要求分析）に該当します。

図2 子どものオモチャ・オネダリモデル

　いかがでしょうか。この話は、子どもがオネダリする際の思考・行動過程を書いたものですが、この中にソフトウェア開発における重要なフェイズのヒントを見つけることができます。

　そのヒントとは、人が行動する際の汎用的かつ理想的なモデルとは、「現状を理解し、戦略を立て、そして最後に財布（や能力）と相談する」ということにほかならないということです。

　ビジネス分析は、「現状を理解し、戦略を立て、財布（能力）と相談する」という思考行動過程の中の「現状を理解し、戦略を立てる」という部分に該当します。このような話をすると、「現状の分析をして戦略を立て、要求を抽出するなんて、なんて大変だ！」と思われる方がほとんどでしょう。しかし、子どもでも無意識にやっていることです。ここであえて子どものオモチャ・オネダリモデルを使って説明をした意図は実はここにあります。「現状を理解し、戦略を立て、財布（能力）と相談する」は、たとえ3分でも、1時間でもできるもの、いや、やるべきことなのです。だから大変だと思わずに思考テクニックとして習慣づけすることから始めてください。

　上の話で説明したように、ビジネス分析フェイズには、現状分析と戦略分析という2つの過程があります。では、ここで現状分析と戦略分析の説明をしていきます。

■現状分析フェイズ

　このフェイズの目的は、自分たち（開発対象）のビジネス（業務）の現状をしっかりと理解することです。従って、ここで作成されるモデルは、「現状理解」が目的となります。現状分析においても、UMLモデリングは大変役に立つものです。その利用法はさまざまです。最近ではビジネスモデリングに関する書籍も多く出ていますが、ここで、最も重要なモデリングおよび、その手法について少しだけ紹介しましょう。

　まずビジネスの現状を理解するには、どのような役割の人がどのような業務処理をどのようなタイミングで行っているかをとらえる必要があります。このような業務の流れをとらえるには、アクティビティ図が使われます。

＜アクティビティ図＞

　アクティビティ図とは、業務や処理のフローを記述するための図のことです。アクティビティとは1個以上の業務処理を意味のある単位にグルーピングしたものです。「フォーク」は並行処理、「分岐」はどちらかに制御が流れます。「フォーク」は、「ジョイン」で並行制御の同期が取られ、分岐はマージで分岐された制御が集まります。

図3 アクティビティ図

　アクティビティ図には、図4のように「レーン」を使って、業務をロール（役割）別に分けて記述します。図4には自動車専門部品販売店（RacingObjective社）についてのアクティビティを示しています（あくまで説明用に簡略化しています）。RacingObjective社はとても小さな会社でマニアの人向けの部品を販売しているお店です。もちろん架空の会社です。この図は、アクティビティ図の意味と書き方をかなり細かなレベルからガイドラインとしてまとめ、それをもって、店長にしっかりと指導した後、店長自ら描いてもらった図です。このようにビジネスモデリングは、ユーザー主導で行うことが重要です。ユーザ主導で行うためには、IT技術者がUMLを指導しながら、IT技術者もその中で現状を理解して いくのがよいでしょう。しかし、この時、IT技術者の観点でビジネスモデリングをやっ てはならないということを「ユーザー主導」という表現で表しているのです。あ くまで、ビジネスモデリングは、ビジネスをやっている人が主役なのです。その人たちのナレッジを如何（いかん）に吸収するかというところにこだわりを持つことが重要です。

図4 RacingObjective社のアクティビティ図（現状分析-初期）

　さて、これで現状分析が終わったかというと、そうではありません。現状分析の最も重要なことはビジネスの現状の理解にほかなりませんが、理解したものを利害関係者間（ここでは店長・店員・開発者）で共有することが重要となります。よって、現状分析におけるモデリング作業として以下のことを行います。

（1）アクティビティを標準化する

　例えば、RacingObjective社にはほかのビジネスとしてカーアクセサリ部門があります。そこのビジネスでは発送は行いませんが、自動車部品とは別管理にて、在庫管理と売り上げ管理が存在しています。カーアクセサリ部門のアクティビティ図には、「売り掛けを計上する」ではなく「売り上げを計上する」となっていました。しかし、売り掛けを計上するということは、すなわち売り上げを計上することですので、両業務に統一的なアクティビティ名として「売り上げを計上する」にまとめることにしました。ただし、もし現金売りがあるとするならば、両者をまとめることはできません。

　このように、アクティビティの標準化は、ビジネスを利害関係者の間でしっかりと理解するためには最も重要なこととなります。よくあるケースが、アクティビティをビジネスの中で標準化せずにアクティビティ図を描くことです。この場合、アクティビティ図のモデル要素がそれぞれ異なる用語で記述されているために、モデリングをやった成果が明確に感じられないものとなります。

（2）アクティビティを概念化する

　これは先に挙げたアクティビティの標準化よりもさらに高度で、効果の高いモデリングです。オブジェクト指向は、問題領域の概念を仮想世界のモデルとしてオブジェクト化し、利害関係者に共有、理解させるためのテクニックです。これによって、問題領域に存在する普遍的な概念構造を理解することができます。

　この方法を、アクティビティ図にも採用するのです。これは、筆者流に定義すると「アクティビティを概念化する」です。

　「さあ、これからアクティビティを概念化しましょう」というと何か難しく感じられてしまい、皆さん2、3歩引いてしまうのではないかと心配になります。しかし、そんなに難しいものではありません。もし、本当に難しいのならユーザーに使ってもらえません。要は、業務機能をグループ化したアクティビティという単位をオブジェクトとして考えてみるのです。例えば、「売り上げを計上する」というアクティビティをクラス（オブジェクト）として考えてくださいということです。そうすることで、さまざまな業務部門から出てきたさまざまな粒度、異なる視点で作成されたアクティビティを整理できずに悩んでいた人たちを助けることができるようになるでしょう。

　では、皆さんもRacingObjective社の一員となったつもりで次の問題を考えてください。

　まず、図4を見てください。この図の中に、「商品在庫を確認する」というアクティビティがありますが、RacingObjective社全体のビジネスモデリングを行っている中で、図5のような意見が出てきたとしましょう。A氏は、図4の「商品在庫を確認する」というアクティビティを抽出しました。しかし、それ以外の人は、図5のように同じ「商品在庫を確認する」部分なのに、アクティビティを抽出してしまったのです。この原因は何でしょうか。実際のビジネスモデリングでは、このような問題に遭遇することはよくあります。では、どのように対処すべきなのでしょうか。

図5 まちまちなアクティビティ

　それぞれの意見を聞いてみると、「商品在庫を確認する」をより具体化したものが、B氏、C氏、D氏のアクティビティであることが分かります。そこで、「商品在庫を確認する」を詳細化したものが、B氏、C氏、D氏のアクティビティであると整理し、アクティビティの標準化のために「商品在庫を確認する」はA氏の選択した図4の方に統一する方向で説得することにしました。しかし、A氏以外の人たちから、それでは大ざっぱすぎるという意見が返ってきたのです。B氏は、そもそも自分たちの業務は、A氏の業務とは異なり、自社在庫の確認と本社在庫の確認を表現しないと意味がないという主張です。また、C氏とD氏は、アクセサリ在庫と自動車部品在庫とは別の方法で管理されており、それを明示しないと意味がないという主張です。

　「商品在庫を確認する」というアクティビティで統一化を図ろうとしていたのですが、粒度の異なるアクティビティを共存させなければならないという状況に陥りました。さあ、この問題をどう解決しますか。長くなりましたが、これが皆さんに考えていただきたい問題です。

　では、この問題に対する1つの解法を説明しましょう。まずは、このように粒度の異なるアクティビティを共存させるには、それなりの根拠が必要となります。そこで、図5のそれぞれのアクティビティの関係構造を考えます。一見、A氏以外の人たちのアクティビティは、「商品在庫を確認する」を詳細化したアクティビティのように思えますが、それだけでは弱すぎます。つまり詳細化の視点が異なることをしっかりと分析しなければならないのです。これを説明するために図6を示します。この図によると、B氏はA氏のアクティビティを分解したもの、C氏とD氏は具体化したものといった具合に、単に詳細化したように思えていたアクティビティを分解と具体化という2つの視点で考察すると、結構意味が分かりやすくなります。

図6 分解したものと、具体化したもの

　「初歩のUML」を最初から読まれている読者は、もう分かりましたよね。そうです、この構造は、「汎化」と「集約」で説明できるのです。そこでクラス図を書いてみましょう。図7を見ると一目瞭然（りょうぜん）ですね。分解したもの（集約）と、具体化（逆から見ると汎化）したものが奇麗に整理されています。

図7 アクティビティをクラス図で表す

　もちろん、これを説明するためには、クラス図を使ったビジネスモデリングについて、しっかりとユーザーに教えておく必要がありますが、そもそもクラス図は、このような使い方もでき、とても効果があることを理解していただけると思います。

　さて、これでおしまいということでは、まだまだモデラーの自己満足でしかありません。ユーザー教育に成功し、この話をユーザーに理解させれば、皆さんはユーザーから一目置かれるようになるでしょう。また、あなたがユーザーの立場であっても同僚から尊敬されるでしょう。しかし、どのような効果があったか、もっと明確にする必要があります。そのためには、企業の中で標準化されたアクティビティ説明書を作成することです。この説明書には、アクティビティ名、「商品在庫を確認する」のような親アクティビティがあるのならその名前、また、親との関係（汎化、または集約）、アクティビティの説明などを書きます。そうすることで、粒度の異なるアクティビティを共存させつつ意味的関係を保っておくことができるようになります。このような作業により、アクティビティは企業の中ではっきりとした概念として生き続けていくことができます。

（3）必要ならば思い切ってアクティビティ図を拡張する

　ビジネスモデリングにおいては、UML＋アルファが必要になることもあります。アクティビティ図も多少拡張しないと使いづらい面があります。ビジネスモデリングでは、必要性を感ずるなら思いきってアクティビティ図を拡張すべきです。図8には、拡張したアクティビティ図を示しています。

　この図には、レーンに、業務で使われる（ユーザーが意識している）システムをおきます（図中�@）。このときにパッケージを置くこと、パッケージからアクティビティへ伸びる参照・点線矢印（図中�A）、参照・更新用実線双方向矢印（図中�B）、参照系で利用される帳票ロゴ（図中�C）などが拡張点です。また、業務上の工程を明らかにすべきものは、横に点線を引き、それを業務工程として表現することも効果があります（図中�D）。このように工程を明示することで、アクティビティを配置する場所に意味付けすることができ、その工程についても企業レベルで標準化を図るようにするのです。「自動車在庫を確認するアクティビティ」には、スーパークラスとなる「商品在庫を確認する」をステレオタイプで明示化します（図中�E）。こうすることで粒度の小さなアクティビティの補足説明代わりに使っています。これは、先ほど「アクティビティを概念化する」で説明しましたね。

図8 拡張されたアクティビティ図

＜概念のモデリング（クラス図）＞

　次は、「初歩のUML」では幾度となく取り上げてきたクラス図を使って概念モデリングを行います。ここではクラス図の説明は割愛します。もしクラス図にあまり自信がないという方は、少なくとも下記を読んでおくと、この後の内容を理解することができます。

【改訂版】初歩のUML 第1回 まずはUMLのクラス図を書いてみよう
【改訂版】初歩のUML 第2回 クラス図の詳細化とその目的
【改訂版】初歩のUML 第3回 モデリングにおける「汎化」と「特化」
【改訂版】初歩のUML 第4回 関連クラスと集約、コンポジション

　現状分析フェイズにおけるクラス図の役割は、現状のビジネスの概念構造をとらえることです。よって現在のRacingObjective社のありのままの姿を表します。この際に、システム開発のことを考える必要はありません。いまビジネスがどのようになっているのか概念構造を的確にとらえ、それをシンプルに説明するための図として描いていきます。図9は、RacingObjective社の現状分析フェイズにおける概念モデルです。この概念モデルでは、取り扱う在庫商品として、自動車部品とアクセサリがあり、それら在庫は支店ごとに管理されており、注文についても支店ごとに管理されています。そして本社には、各支社の在庫状況をひと目で見ることができるような仕掛けがあることを示しています。

　このように、現状分析フェイズの概念モデルは、現状を理解するためのモデルであるので、いかに分かりやすく簡潔に現状ビジネスの概念構造を人に説明できるかということでモデルの良しあしが決まります。

図9 RacingObjective社の現状分析フェイズにおける概念モデル

■戦略分析フェイズ

　現状が理解できたら、IT化を前提とした戦略的要素を含んだモデルを考えていくフェイズに移ります。戦略分析というと誤解される方も多いかと思いますので、前もっていっておきますが、これは企業戦略の大方針を打ち立てる作業ではありません。それらはもっと前のフェイズで行われていると思ってください。企業戦略の大方針をここで紹介するUMLベースのやり方で立てていこうと考えると、おそらく失敗することになるでしょう（コラム参照）。

【コラム】 企業戦略の大方針決定作業にUMLを使うと失敗する？

UMLは、ビジネスやシステムの構造を、モデルとして具体化するための道具です。これは、仮想世界を視覚化し利害関係者に認知させるという大事な目的を持っています。しかし、残念ながらアイデアを出す過程においては、あまり効果を発揮しません。むしろアイデアが出た後、そのアイデアの構造を表すことを得意とします。よって企業戦略の立案過程においては、別の手法（SWOT分析・Five Forces分析）を使うことになるでしょう。実際に筆者もそのようにしています。でも本当は、このような分析手法より「電車の中でボーッと考える法」「お風呂で沈み考える法」などがとても有効です（笑）。 　UMLによるモデリングで、やりたい事を整理し、明確化することで、新たにやりたい事が見つかるということはあります。また、ユーザーとモデリングを行っている間のコミュニケーションにおいて重要な問題点やアイデアが聞けるということもあります。しかし、UMLでモデリングしている間にアイデアが浮かぶのではという過剰な期待は持たない方がよいでしょう。つまりUMLでモデリングする際には、すでにやりたい事、やるべき事、といったアイデア創出は先にやっておくということが重要なのです。最近、よく耳にする言葉として、“UMLは思考の道具である”というものがあります。これを否定するものではありませんが、だからといってアイデアを出すための道具ではありません。UMLは、“アイデアを形にするための道具”なのです。 　これは開発段階におけるユースケース図やクラス図にも当てはまります。ユースケース図やクラス図は、よい要求や、よい設計を作り出すためのものではありません。よい要求や、よい設計をモデルに組み込んで人に説明するための道具なのです。私は、アイデアを出す過程では一切UMLベースのモデリングを利用していません。しかし、アイデアが具現化してきたころに、いったん頭の整理をするために初めてUMLベースのモデリングを使います。 　しかし、いずれはUMLにも、戦略を立案するためのモデリング手法に基づく表記法が追加されるかもしれません。実際、私もそのようなモデリング手法を5年ほど前から考え出して実践しています。この話はまた機会があれば、ご紹介したいものです。いずれにせよ、現段階のUMLに多大な期待をしないでください。もちろん現段階でも非常に優れたビジュアルモデルを提供してくれているのは事実ですので、そのおいしいところだけをしっかりと学んでいきましょう。

　戦略分析フェイズは、すでに企業戦略の大方針が明確化された後に、現状分析で作成されたモデルをベースに、企業戦略の方針を含めたものをモデルとして表し、利害関係者間で理解するためのものです。しかし、このフェイズにて新たな企業戦略が発見されることも事実です。それは、現状分析フェイズの成果物となる現状分析モデルを構築する過程によって、モデリングに参加するメンバーらの頭の中に共通のビジネスモデルがイメージされ、そのモデルによって新たな問題個所が発見されるというパターンです。

　では、実際に戦略分析フェイズでは、どのような点に着目して、どのような作業を行うのか、さっそくRacingObjective社を例に取り実践していきましょう。戦略分析の観点を簡潔に説明すると、下記のようになります。

（1）ビジネスの流れに問題のある個所はないか？ （ビジネスアイデアの反映）

　実は、RacingObjective社は、客から注文を受け付けた後に、在庫確認をしていました。図8を参照してもらえば、そのことが明確に分かリます。このような方法を取っていたため、客から注文を受けても、その商品を発送する時期を事前に知らせることはおろそかにしており、そのために苦情が何度か出ています。そこで受注工程にてシステムを利用して、在庫確認をスピーディに行い、商品発送時期を客に事前に連絡する方法を採用したいと考えました。

　また、RacingObjective社では、ユーザーからの入金前に商品を発送していました。これはビジネスを始めたころはあまり問題になりませんでしたが、最近では、売上金の回収ができないケースが何件か出てくるようになりました。そこで、多少サービスの犠牲を払ってでもこのリスクを減らしたいという意図で、商品を客が入金後発送するという方法に変えることにしました。

　以上の2点を図8に反映したのが図10です。図10では、もはや在庫確認工程はなくなり、受注工程にてシステムを利用することで在庫確認を済ますようにしています。また、入金を確認した後に注文された商品を発送するように変更しています。このようにビジネスが自動化されているものか否かにかかわらず、まずビジネスの流れにどこか問題がないかをチェックすることが重要となります。これは、現状分析フェイズの間から意識しておく必要があります。

図10 商品を客が入金後発送する

（2）コンピュータシステムにより最適化できる個所はないか

　（1）の例でもそうでしたが、コンピュータシステムによって最適化が図れる個所はほかにないかを考えます。また、コンピュータシステムとアクティビティの関係がある個所の最適化が図れないかを考えます。例えば、図10では、客からの入金が確認された後、商品発送までの流れがシステム化されていません。よって、客から入金があったにもかかわらず商品を発送するのが遅れてしまうという問題が出ています。そこで、入金された注文商品や、発想予定日を過ぎても入金がされない注文商品にマークを入れ在庫センターで確認できるようなシステムを考えることにしました。この考えを反映したものを図11に示します。

図11 コンピュータシステムによるビジネス最適化

◆

　ビジネスモデリング編、いかがでしたか。ビジネス分析については、まだまだ書くべきことがたくさんあります。ビジネスモデリング編だけでも1冊の書籍ができてしまいます。しかし、基本は「現状を理解し、戦略を立て、そして最後に財布（や能力）と相談する」ですので、その基本さえ守っていれば何も怖いことではありませんし、時間をたくさんかけることでもありませんので、どんどん実践を積み重ねてください。また、モデリング・ガイドラインを作成すると効果的です。その中で、モデリングを行う際の基本的なパターンをしっかりと説明しておきましょう。モデリング・ガイドラインについてもまた機会があれば取り上げていきたいと思います。さて、次回は開発モデリング編です。皆さん、お楽しみに。

IT Architect 連載記事一覧