Extended Summary 本文は pp.

1442-1451

An Information System Development Method Connecting

Business Process Modeling and its Experimental Evaluation

Tsutomu Okawa Member ( Mitsubishi Electronic co. Information Technology Center )

Tsukasa Kaminishi Non-member ( Tokyo Denki University，[email protected] )
Yoshiyuki Kojima Non-member ( Tokyo Denki University )
Syuichi Hirabayashi Non-member ( Tokyo Denki University，[email protected] )
Hisao Koizumi Member ( Tokyo Denki University，koizumi @itlab.k.dendai.ac.jp )

Keywords : information system, modeling

Business process modeling (BPM) is gaining attention as a implementation as shown in Fig. 1. The proposal method was
measure of analysis and improvement of the business process. applied to the construction of a parts procurement system, and the
BPM analyses the current business process as an AS-IS model and influence that the method has on the design, and effectiveness of
solves problems to improve the current business and moreover it the method were examined. In the evaluation, comparison with the
aims to create a business process, which produces values, as a case where the system is implemented by the conventional UML
TO-BE model. However, researches of techniques that connect the technique without going via BPM is performed. In each process of
business process improvement acquired by BPM to the analysis, a design, and implementation, the effectiveness of the
implementation of the information system seamlessly are rarely proposal method has been confirmed as the result of comparison.
reported. If the business model obtained by BPM is converted into In an analysis process, the proposal method was able to discover
UML, and the implementation can be carried out by the technique the process bottlenecks and improve them. In the design process,
of UML, we can expect the improvement in efficiency of classes overlooked by the conventional method were not
information system implementation. overlooked by the proposal method. In the implementation process,
In this paper, we propose a system design method that supports re-implementation of the classes overlooked by the conventional
from analysis to implementation seamlessly by performing system was not necessary by the proposal method. From these
business process modeling, carrying out the simulation of the results, it can be said that the effectiveness of the proposal system
process, discovering and improving the bottleneck of business in each process has been confirmed.
before implementation, and performing design by UML and

Business process
modeling
As-Is To-Be Generation of UML
Analysis model model models
of Implementation
business Cancellation Preparation
system Business of for Conversion (java)
process bottleneck conversion
simulation on
business
process

Fig. 1. Procedure of system construction by our method

－21－
 論 文

ビジネスプロセスモデルを用いた情報システム構築法の試作と評価

正 員 大川 勉＊ 非会員 上西 司＊＊
非会員 小島 義幸＊＊ 非会員 平林 秀一＊＊
正 員 小泉 寿男＊＊

An Information System Development Method Connecting

Business Process Modeling and its Experimental Evaluation
Tsutomu Okawa＊, Member, Tsukasa Kaminishi＊＊, Non-member, Yoshiyuki Kojima＊＊, Non-member,
Syuichi Hirabayashi＊＊, Non-member, Hisao Koizumi＊＊, Member

Business process modeling (BPM) is gaining attention as a measure of analysis and improvement of the
business process. BPM analyses the current business process as an AS-IS model and solves problems to improve
the current business and moreover it aims to create a business process, which produces values, as a TO-BE
model. However, researches of techniques that connect the business process improvement acquired by BPM to
the implementation of the information system seamlessly are rarely reported. If the business model obtained by
BPM is converted into UML, and the implementation can be carried out by the technique of UML, we can expect
the improvement in efficiency of information system implementation. In this paper, we describe a method of the
system development, which converts the process model obtained by BPM into UML and the method is evaluated
by modeling a prototype of a parts procurement system. In the evaluation, comparison with the case where the
system is implemented by the conventional UML technique without going via BPM is performed.

キーワード：情報システム，モデリング
Keywords：information system, modeling

ムのボトルネックを解消するようなビジネスプロセスや処
1. はじめに
理方法を探す場合には，UML の分析，設計，プログラミン
情報システムの構築において，構築対象システムの分析， グ，実装の動作確認等の一連の作業を何度か繰り返さなけ
設計でのモデリングの重要性が高まっている。 ればならないという課題がある。
UML(Unified Modeling Language)(1)は，システムの構造と ビジネスプロセスの分析・改善への方策として，ビジネ
振る舞いを，モデルを用いて表現するための標準表記法で スプロセスモデリングが注目されている(2)～(4)。ビジネスプ
あり，多くのシステム分析・設計で使用されている。UML ロセスモデリングは，現状のビジネスプロセスを As-Is モデ
におけるユースケース図は，ユーザの要求仕様をモデルと ルとして分析し，問題点を解明し，業務の改善に結びつけ
して記述し，仕様を図示することが主目的であるが，UML ると共に，更なる価値を生み出す方法を創出することを目
に記述した振る舞いの動作確認は，クラス図，アクティビ 的とする。しかしながら，ビジネスプロセスモデリングに
ティ図等による設計と Java 等のプログラミングを経た実装 よって得られた分析結果を実際にどのようにして情報シス
後に初めて行われる。また，要求仕様を実現する各種のビ テムの構築に結び付けていくかについての研究は殆ど行わ
ジネスプロセスから適切なものを選択する場合や，システ れていない。ビジネスプロセスモデリングによって確認さ
れたプロセスモデルを UML に引継ぎ，あとは UML の手法
＊
三菱電機株式会社情報システム技術センター によって実装して行くことができれば，情報システム構築
〒100-8310 東京都千代田区丸の内 2-7-3
Mitsubishi Electric Co. Information Technology Center, の有効な手段になると考える。
2-7-3 Marunouchi,Chiyodaku, Tokyo 100-8310
＊＊
東京電機大学
筆者らは，これまでにビジネスプロセスモデリングによ
〒350-0394 埼玉県比企郡鳩山町石坂 って得られた分析結果のプロセスモデルを UML モデルに
Tokyo Denki University,
Ishizaka ,Hatoyama ,Hiki ,Saitama 350-0394 変換して情報システムを設計していく手法についての提案

1442 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

を行ってきた(5)(6)。しかしながら，これまでの提案は，モデ ： S e c tio n ： A ttr ib u te

O r g a n iz a t io n a l C om pany

ルを段階的に詳細化していく方式がとられておらず，UML M od el
A tt rib u t e
モデルへの変換方法にも改善すべき点があり，また実装に P rio rity ,
I n fo r m a t io n S y s te m S a le s M a te r ia l N u m ber
of
よる評価は行われていなかった。 s tr a te g icd e v e lo p m e n t s e c tio n s e c tio n P e o p le
s e c tio n s e c t io n
本稿では，業務改善のためのビジネスプロセスやボトル
L in k 1
ネックとなっている業務内容を分析するために，モデリン F u n c tio n M o d e l M a te r ia l
s e c t io n
グ結果を UML モデルに変換し，実装に繋げていく一連の方
法を提案する。本方式においては，まずビジネスプロセス O rder C h eck
E s tim a t e D e liv e r y
m a te r ia ls s to c k
モデリングに関して，段階的に詳細化を行うモデリング方
： S e c tio n
式に従って，企業の活動を組織図，機能図，ビジネスプロ D e t e r m in a t io n o f th e
： F u n c tio n
c o n d itio n s o f h o p in g
セス図の組み合わせによってモデル化し，シミュレーショ L in k 2

ンによってビジネスプロセスのボトルネックを検出する。 B u s in e s s P r o c e s s
E s t im a te M odel
その改善プロセスを見出してシミュレーションによって確 V e r ific a t io n ： F u n c tio n

認する。次に改善したビジネスプロセスモデルを UML モデ E x t r a c t io n
： S ta te
ルに変換し，クラス図を作成した後，プログラミング，実 S u c c e ss o r fa ilu r e
S e le c t io n E s tim a te
装の動作確認を行っていく。 c o m p ila t io n

本方式の評価のため，部品調達システムのプロトタイプ
開発に本方式を適用して，ビジネスプロセスモデリングと 図1 組織・機能・ビジネスプロセスの関連
UML モデルへの変換，及び実装を行った。UML モデルに Fig. 1. Relation of organization, function and
ついては，ビジネスプロセスモデリングを行わず，システ business process
ム仕様からユースケース分析を行い，そこからクラス図を
作成する従来方式との比較評価を行った。 変更がビジネスプロセス図や機能図に反映されるといった
ことが可能となる。
2. ビジネスプロセスモデルを用いた情報システ
〈2･1･2〉 As-Is モデルと To-Be モデル ビジネスプロ
ム構築法
セスモデリングでは一般に，As-Is(現状)モデルを作成し，
〈2･1〉 ビジネスプロセスモデリング As-Is に改善を加えた To-Be(改善)モデルの実現を目指す。
〈2･1･1〉 組織・機能・ビジネスプロセスの関連 ビ As-Is のビジネスプロセスは，図 1 に示すビジネスプロセ
ジネスプロセスモデリングの狙いは，企業の事業環境の変 ス図として表す(To-Be も同じ)。ビジネスプロセス図内のス
化に迅速に対応できる情報システムを構築するために，ビ テート(プロセスの状態)には，プロセス中に行われる処理や
ジネスプロセスを可視化して記述し，分析することである。 イベントを記述する。As-Is のビジネスプロセスモデルは，
加えて，作成したモデルによってビジネスプロセスの有意 現状のプロセスについて分析を行い，ステートをフローチ
性を検証できると共に，モデルの修正，追加，削除などの ャート形式に当てはめることによって作成する。
更新が容易でなければならない。すなわち，企業活動を多 To-Be モデルは，As-Is モデルの分析によって必要となっ
面的視点から分析し，目標やビジネスプロセス，更には組 た追加システムを業務内に組み込み，モデル化し，最適化
織や行動体系などの企業における各種要因もモデル図に書 したものである。To-Be モデルの分析によって改善が見られ
き表し，要因間の関係もモデル化するものである。モデル るまで，分析と修正を繰り返す。
化し，それらのモデルを関連させることで，現状のビジネ 〈2･1･3〉 ビジネスプロセスシミュレーション As-Is
スプロセスの評価，あるべき姿を検討できる。 モデルと To-Be モデルの分析には，ビジネスプロセスに対
組織，システムを実現する機能，ビジネスプロセスに関 してのシミュレーションを用いる。シミュレーション期間，
し，本論文の基盤とする関連図例を図 1 に示す。図中の組 処理の発生回数や各ファンクションの処理時間，分岐の確
織図は，システムに関係のある組織の構成を表現するもの 率など，シミュレーションに必要な情報は，対象とするシ
であり，人員リソースもモデルの属性(内部情報)として記述 ステムの要求仕様から設定する。例えば，シミュレーショ
する。機能図では，システムを構成する機能とそれを扱う ン期間には，定期的な業務期間を時間・日単位で設定する。
部署をツリー形式で表現する。ビジネスプロセス図では， また，処理の発生回数であれば，
“○時間当たり○件の顧客
ビジネスプロセスをフローチャート形式で表現する。各図 を処理できる”といった情報をもとに，シミュレーション
は，相互に関連を持たせ，連携させる。図中の Link が各図 期間当たりの発生回数を設定する。シミュレーションでは，
を関連付ける操作である。図 1 では，Link1 が組織図と機 処理時間の合計のみならず，プロセスが処理を開始するま
能図の「資材部」についての関連を示しており，Link2 が での待ち時間を示す動的待機時間や，各プロセスの実行状
機能図とビジネスプロセス図の「見積」についての関連を 況など，詳細な統計結果が得られる。その統計結果より，
示している。相互に関連付けることによって，組織構成の 一定期間内に実行可能なプロセス数の把握，プロセスに含

電学論 C，127 巻 9 号，2007 年 1443

 ③
Business process Generation of UML ⑦
modeling models
Analysis ① As-Is
of
② ④ To-Be ⑤ Preparation ⑥ Implementation
model model for Conversion
business conversion (Java)
system Cancellation
Business of
process bottleneck
simulation on
business
process
③
図2 本方式によるシステム構築の流れ
Fig. 2. Procedure of system construction by our method

まれる弱点やボトルネックの把握，リソース利用の最適化 なパラメータとなる。
やコストの抑制などについても分析することができる。 UML 変換については，本ガイドラインを遵守すれば，
As-Is モデル作成後の統計結果を基準値として，To-Be モデ UML 変換の際に必要なパラメータをその場で考えること
ルの作成を行う。 なく変換工程を行うことができる。
〈2･2〉 ビジネスプロセスモデルを用いた情報システム 〈2･2･2〉 構築の手順 本方式の流れを図 2 に示す。
構築法 以下，構築手順を述べる。
〈2･2･1〉 ビジネスプロセスモデリングと UML 変換 ①現状を分析する。対象となるシステムに関し，複数の業
本方式では，ビジネスプロセスモデリングによる業務分 務にまたがっているビジネスプロセスを分析する。この
析により業務のボトルネックを検出・解消し，このビジネ 時，分析の対象は単にシステムのビジネスロジックだけ
スプロセスを情報システムで稼動させるため，次のような ではなく，運用・利用する組織や部署の構成，更にそれ
方法で，ビジネスプロセスモデリング及び UML 変換を行 ぞれの組織で扱うリソースまでを含める。
う。 ②分析結果をモデル化する。モデルは図 1 に示したように，
(１) ビジネスプロセスモデリング方式 ビジネスプ 単に作成するだけでなく，相互に関係付けを行う。ここ
ロセスモデリング工程の初めに作成する機能図について で作成されるモデルは As-Is モデルである。モデル化は組
は，機能分割を複数回行い，モデルの規模を大きなものか 織モデル，部署モデル，各部署で行うシステムの機能モ
ら徐々に小さくしていき，分割した各機能図に対して機能 デル，機能を表すプロセスモデル，というように大きな
を記述し，モデルを詳細にしていく。機能分割の際には， モデルから段階的に詳細なモデルを作成していく。また，
プロセスが複数の機能図になるべくまたがらないように分 変換のガイドラインに従い，プロセスで用いる人員など
割を行う。このように規模の大きなモデルを独立した小さ のデータは，必ず各プロセス図に関連付けを記述する。
なモデルに段階的に分割し，詳細にしていくことで，各モ ③作成した As-Is モデルをシミュレーションにより検証す
デルの独立性を高められる。モデルの独立性が高まること る。モデルはビジネスプロセスと組織構成が関連付けら
によって，業務に変更が生じた場合でも，業務に対応する れているので，どの組織のどのプロセスに問題（ボトル
モデルの変更を行うだけで，対処することができる。 ネック）があるかといったことまで検証できる。要求分
(２) UML 変換のガイドライン 本方式における 析に問題があると判断した場合は，検証結果から必要に
UML 変換のガイドラインを述べる。変換のインプットは詳 応じて要求分析をやり直す。
細なプロセスを記述したビジネスプロセス図であり，アウ ④シミュレーション結果から，ビジネスプロセスや組織に
トプットは UML 図である。インプットモデルとアウトプッ 問題があると判断した場合は改善を行う。改善方法とし
トモデルの詳細レベルは同じである。変換の際には，変換 ては人員増減やプロセスの変更などがある。変更後，再
後のアウトプットモデルに必要なデータが何であるかを考 度シミュレーションを行い，問題が改善されたならば，
え，インプットモデルにパラメータとして与える必要があ そのモデルは To-Be モデルとなる。
る。そこで，本ガイドラインでは，インプットモデルの作 ⑤作成した To-Be モデルについて，UML に必要なパラメー
成時に，付加するパラメータの指針となるような要素を後 タを設計者が配置する。パラメータには，②でガイドラ
工程を意識せず盛り込む方法を次のように定めた。 インに従い各プロセスに記述したデータを用いる。
インプットモデルであるビジネスプロセス図の作成にお ⑥パラメータを付加した To-Be モデルを UML のモデル要
いて，図内のプロセスで用いる人員などのデータについて 素に変換する。変換によって生成された要素には，ツー
は，別途データ構造を可視化するモデルを用いてモデル化 ルによってクラス図の関連要素や，ステートチャート図
し，ビジネスプロセス図と関連付けるか，図内のプロセス のトランジションなど，足りないモデルの要素があるた
にどのデータを用いるか直接記述する。このプロセス図に め，設計者がこれを補い，完成させる。
関連付けた，あるいは付加したデータが，UML 変換に必要 ⑦完成させた UML をもとに Java による実装を行う。

1444 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

Supplier company
⑥ Re-estimate
①
① Condition Presentation
of choice ② Condition
Buyer transfer of choice
company ③
Estimate Company A

Server

⑨ ④⑦
⑧ Estimate Company B

………
The supply Distribution of
person-in-charge The estimated estimated data Selection falling
reply which Re-estimate
final selection
is a company
⑤
Re-estimated request
near hope or

..
Omission
notification
⑩ Order in selection
Estimate
Company N
n

図3 部品調達システムのプロトタイプ
Fig. 3. A Parts Procurement Support System

System Use Case Class Diagram and

3. 本方式の試作と評価 specification Diagrams other various kinds
Construction

本方式を部品調達システムに適用し，評価を行う。部品 図4 UML による構築の手順

調達システムは，業務システム面の評価のために作成した Fig. 4. Construction flow with UML
プロトタイプシステム(7) (8)である。
試作は，次の 2 つの方式について行う。 ⑦システムは再見積の選考を行う。
(１) UML に基づいたシステムの構築（従来方式） ⑧選考に残った見積をバイヤーに送信する。
UML だけを用いてシステム構築を行う場合，すなわち，図 ⑨バイヤーの担当者による選考を行う。
2 における①，⑥，⑦の順序で構築を行う場合である。 ⑩最後に残ったサプライヤーを発注対象とする。
(２) ビジネスプロセスモデルからの構築（本方式） 〈3･2〉 従来方式による構築 部品調達システムにつ
ビジネスプロセスモデリングを用いてシステム構築を行う いて，UML を用い，図 4 に示す手順でシステムの設計から
場合，すなわち，図 2 における①から⑦まで行う場合であ 構築までを行った。
る。 UML 図としては，クラス図の他に，ユースケース図，シ
〈3･1〉 部品調達システムの概要と流れ 図 3 に部品 ーケンス図，コラボレーション図，状態遷移図を作成した。
調達システムの概要と業務の流れを示す。このシステムは， (１) ユースケース図の作成 ユースケース図作成に
e-マーケットプレイス上にて逆オークション形式を用いて おいては，アクターとして，バイヤー・サプライヤー・デ
買い手側企業（バイヤー）が調達したい部品の購入希望条 ータベースサーバを挙げた。ユースケースとしては「見積
件を提示し，複数の売り手側企業（サプライヤー）から条 入力」
「選考」
「通知」を挙げた。
件に合った企業選択の支援を行う。本調達システムは 1 回 (２) クラスの選定と図の作成 オブジェクト指向開
目の見積選考の後，選考に残ったサプライヤーに再見積を 発を行う際には，どのようなクラスを用いるかを決める必
依頼し，これらのプロセスを繰り返すことにより適切な業 要がある。分析段階では，本調達システムの流れを記した
者を選択していく。具体的には，以下のようである。 文章からクラスになりそうな単語を抽出した。抽出の結果，
①調達条件を Web で提示する。 〈3･1〉節に示したプロセスのうち，③の登録画面，④の送
②サプライヤーは調達条件を参照する。 信・見積・選考，⑤の電子メール，⑥の再見積がクラス候
③サプライヤーは登録画面からサーバに見積送信する。 補となった。このうち送信と選考は見積クラス内のメソッ
④バイヤーは選考条件をサーバに送信し，システムは見積 ドとし，再見積は見積クラスの利用により除外して，登録，
の選考を行う。ここでは見積書の中の単価・品質・取引 見積，電子メールの 3 つをクラスとした。作成した分析段
実績の 3 つから，見積の良し悪しを判断する。バイヤー 階のクラス図を図 5 に示す。
は選考結果から，良い見積を出したサプライヤーにもう (３) 設計段階でのクラス図の作成 設計段階では，登
一度見積を出してもらうか，各サプライヤーに直接交渉 録画面をバイヤー用とサプライヤー用の 2 種類用いた。更
するかのどちらかを決定する。 にデータベースサーバと電子メールを利用するクラスを設
⑤選考漏れ企業にはその結果を，選考に残った企業には再 置した。見積クラスは変更せずに，データの入出力を行い，
見積依頼を電子メールで通知する。 実際の業務を行うクラスとした。設計はここで終了し，実
⑥サプライヤーは再見積を送信する。 装に入ったところで見積クラスが 2 つ以上の登録画面を受

電学論 C，127 巻 9 号，2007 年 1445

 ④ A p p lic a t io n S e r v e r
B uyer
E s tim a t e ③ W eb (T o m c a t 4 .1 ) S u p p lie r
B row ser HTTP HTTP W eb
C om p any N u m ber R e g is t r a tio n S c r e e n c B row ser
C om pan y N am e
A dd re ss c

T e le p h o n e N u m b e r R e c e p tio n is t()
JD B C
E s ta b lis h m e n t Y e a r
U n it P r ic e D a ta b a se S erv er
⑤ (M y S Q L 3 .2 3 )
D a te o f M a n u fa c tu r e
E -M a il c
T ra ck R eco rd
S e le c tio n R e s u lt
R e g is tr a tio n () C o n te n ts D e te r m in a tio n ()
S e le c tio n () T r a n s m is s io n o f E -m a il()
A c q u is itio n () 図7 構築環境
図5 最初のクラス図 Fig. 7. Construction environment
Fig. 5. Class at the initial design level

Supplier Estim ate

Registration Screen
Corporate Inform ation:String
Registration
Estim ate:String
Selection Selection Result:String
Conditions:String
Receptionist() Data Creation()
Yes-no Decision() Data Acquisition()
Renew al Of Data()

Buyer
Registration Screen

Database Processing
図8 実行画面
The Contents of E-m ail
Fig. 8. An example of execution screen
E-m ail Processing

図6 UML 設計レベルのクラス図 Organizational View Data View

Data Base・The data object
Fig. 6. Class at UML design level showing documents etc.

Function View
Function View
け付けることができないことが判明した。そのため，設計 (Function Tree)

に戻り各登録画面を受け付けるクラスを新たに追加するこ
とにした。見積クラスはデータ管理だけを行う事とし，メ Process View
(eEPC(eEPC
Diagram・Bisiness Process Diagram)
ソッドの一部を新クラスに移した。作成した設計レベルの Diagram, Business Process Diagram)

クラス図を図 6 に示す。 図9 ARIS ビュー(組織図・

システムの動作と各クラスの関係を述べる。登録画面ク 機能図・プロセス図・データ図)
ラスでは，バイヤー及びサプライヤーからの各種データを Fig. 9. ARIS View (Organizational View・Function
受け付ける。見積クラスでは，見積情報の管理を行い，情 View・Process View・Data View)
報の登録，選考や取得作業を行う。メール関連のクラスで
は，サプライヤーへ通知を行う。見積・メール関連クラス べたモデリング方式と UML 変換ガイドラインをもとにモ
は，登録画面クラスに呼び出される形で働き始める。 デリングとモデル変換を行うに際しての，ビジネスプロセ
(４) Web システム 3 層構造での実装 部品調達シス ス図を作成・分析する手段，及びビジネスプロセス図をク
テムは，クライアント，Web サーバ＋アプリケーションサ ラス図，シーケンス図，状態遷移図などに変換する手段と
ーバ，データベースサーバで構成する 3 層クライアント／ して，IDSSheer 社のビジネスプロセスモデリングツール
サーバシステム上に構築した。図 7 にその構成を示す。 ARIS(9)を活用した。ARIS では，ビジネスプロセスを組織
クライアントでは，情報の表示や見積・会社情報の入力， 図・機能図・プロセス図・データ図から記述し，プロセス
結果の通知などが行われる。Web サーバは，クライアント 図が各図を統合する。なお，ARIS においてプロセス図は，
からの情報を受付け，アプリケーションサーバに渡し，逆 eEPC(Extended Event Driven Process Chain)図と，機能
に渡された情報をクライアントに送信する。アプリケーシ 図はファンクションツリーと呼ぶ。図 9 に ARIS で扱う各
ョンサーバは，ビジネスロジックを用いて見積情報の選考 図の相互関係を示す。
や処理を行う。データベースサーバは，クライアントから 図 9 において，ファンクションツリーは，1 つの部署で行
の各種情報や選考結果の管理を行う。プログラム環境は われる処理をいくつかの機能に分け，ツリー形式に階層表
Java を使用した。以上の環境のもとで，見積の募集から選 示したものである。特に，ARIS におけるファンクションツ
考の実行動作を確認した。実行画面を図 8 に示す。 リーではこれらの機能間の関係の表示ができる。
〈3･3〉 ビジネスプロセスモデルからの構築 eEPC 図は，ファンクションツリーで分けられた 1 つの機
〈3･3･1〉 ビジネスプロセスモデリングツールの活用 能を実現する処理の流れをフロー形式で表す。ARIS におけ
本プロトタイピングにおいては，
〈2･2･1〉節(１)(２)で述 る eEPC 図では，
「イベント」及び「ファンクション」の 2

1446 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

つの要素を交互に配置することによってプロセスを表す。
ITLab Organizational View
「イベント」は，プロセスにおける情報オブジェクトの状態
やファンクションの起動を表し，
「ファンクション」は，情 Materials Business

報オブジェクトに対する行為や作業を表す。「イベント」 Confirm Accept

Parts Estimate
は，「ファンクション」実行のためのきっかけとなり，「フ Request
Examine Estimate
ァンクション」の実行は次の「イベント」を生み出す。 Estimate

データ図は，eEPC 図やファンクションツリーで用いるデ Decide

Condition
Report
Result
ータ構造をツリー形式で表すが，特に複雑な構造でない場 Delivery
Interview
Parts
合，各図に用意されているデータ要素を用いて表すことが
Contract
できるため，そのような場合，データ図自体は作成しない。 procedure

〈3･3･2〉 ビジネスプロセスモデリング 図 2 に示し Function Tree

Send
た本方式，及び〈2･2･1〉節に示したビジネスプロセスモデ Estim ate

リング方式と UML 変換ガイドラインに従い，ビジネスプロ Estim ate

Con firm ation
of content
Business

セスモデリング，ビジネスプロセスシミュレーション，及
びビジネスプロセス図からの UML モデル変換を行った。
No problem Problem
(１) モデルの作成 部品調達システムを運用する組 was detected

Estim ate Add to Req uest

Business Estim ate Business
織には，架空の会社である「アイティラボ」を想定し，そ file Estimate file of resubmitting

「営業」の 2 部門を想定する。
の下に「資材」 A dditional
Estim ate file com pletion
Req uest
com pletion

「アイティラボ」が 2 部門しか持たな
組織図については， Estim ate Notification B usiness
of acceptan ce ：Event ：Data
い単純な組織であるため，ファンクションツリーにて代用 completion
：Function Element
N otification com pletion
することとした。よって，作成したファンクションツリー of acceptance com pletion

は，機能図兼組織図である。ファンクションツリーによっ ： Link
eEPC Diagram
てシステムの大まかな機能分割を行い，eEPC 図によってそ
れぞれの機能について段階的なモデリングと詳細化を行っ 図 10 ファンクションツリーと eEPC 図
た。図 10 に ARIS を用いて作成した部品調達システムのフ Fig. 10. Function Tree and eEPC Diagram
ァンクションツリー，及び見積受付の eEPC 図を示す。
ファンクションツリーでは，｢資材｣と「営業」の各部門 告」の 6 つについてである。他の「部品の納入」
「面談」
「契
に，調達を行う機能が計９つ作成された。いずれの機能も 約手続き」は，部品調達システム固有の機能ではないため，
図 3 の部品調達システムの流れから選んだものである。各 モデルを作成しなかった。
機能について，eEPC 図を用いてプロセスを詳細化した。 (２) ビジネスプロセスシミュレーション 作成した
作成した eEPC 図について説明する。例えば，図中の「見 eEPC 図についてシミュレーションを行った。シミュレーシ
積受付」機能の場合では，
「見積が送付される」イベントに ョン期間は 1 週間，勤務時間は AM8：30～PM5：30，休み
よりプロセスが始まり，
「内容の確認」ファンクションが開 時間は PM0：00～PM0：45，プロセスの発生数は 1 日 65
始される。内容の問題有無によりプロセスは２つのイベン プロセス，プロセスの発生頻度は 1 日 4 回として行った。
トのどちらかが起動される。以後，プロセスは進んでいき， eEPC 図を作成しなかった部分のシミュレーションについ
最後の「受付完了の通知完了」か「依頼完了」のどちらか ては，設定した想定処理時間をパラメータとして与え，実
のイベントでプロセスは終了する。ファンクションの横に 行した。今回は「部品の納入」には 2 日，
「面談」
「契約手
線でつながっている楕円は組織・人物を表し，企業の中で 続き」には 2 時間という想定処理時間を設定した。シミュ
誰がファンクションを遂行するかを，またイベント以外で レーション結果から，ボトルネックの検出と，モデルの改
ファンクションに矢印で連結されているモデル要素は，フ 善を行った。図 11 にシミュレーション結果を示す。
ァンクションが扱うデータを表している。図中の分岐点に 図 11 の棒グラフは 2 つの成分から構成されている。左側
ある×印は排他的論理和を示す。 がファンクション(eEPC 図で使用されているファンクショ
ファンクションツリーと eEPC 図の関連については，図 ンであり，図 10 で示したファンクションツリーのファンク
10 の「Link」を示す要素を配置することによって表す。図 ションではない)当たりの延べ動的待機時間であり，右側が
10 では，ファンクションツリーの「見積受付」に Link が 処理時間の合計である。図 11 は，すべての eEPC 図に属す
配置され，Link 先に「見積が送付される」に始まる eEPC るファンクションのうち，特に大きい動的待機時間を記録
図が形成されている。 したファンクションを抽出したものである。すなわち，こ
今回作成した eEPC 図は，図 10 で示したファンクション れら 4 つのファンクションはボトルネックである。図 11 に
ツリーの各ファンクションのうち，「部品の確認」「見積の 表示していない他のファンクションは，動的待機時間・処
検討」「希望条件の決定」「見積受付」「見積依頼」「結果報 理時間とも 0～100(min)の間であった。

電学論 C，127 巻 9 号，2007 年 1447

 Tim e 80 0 Company Number
(m i n) T o ta l o f
70 0 dy n am ic Price Start
s ta n db y t im e b y
60 0 a fun c ti o n Delivery Date
Estimate selecting
T o ta l o f
50 0 pr o c es s in g ti m e Kind of Parts
40 0 Quality
Extract
Compare Materials
30 0
estimate
estimate
20 0
10 0
0 S el ec t io n o f F a x e d th e F a x e d th e F a x e d th e
Estimate
e s ti m a t e r e q u es t f or r e q u es t f or r eq u es t f or Price Extracted Estimate run out , and
r e qu e st q u o ta t io n q u o ta t io n q u ot a t io n
co m p an y to A to B to C estimate Selection was ended
co m p an y co m pa n y co m pa n y Delivery Date Condition
Kind of Parts of Hoping
図 11 シミュレーション結果 Quality Decide next
Compare Materials
Fig. 11. Simulation result judging system
estimate

Company Number
Estimate Comparison
Decided next
T im e 800
( m in ) Pass or Fail completion judging system
700
600 Add
pass or fail Materials Report result
500
400 Additional
：Input Parameter
300 result
：Next Phase Element completion
200
100 図 13 クラスを追加した eEPC 図
0 S e l ec t io n of
e s ti m a t e
F a x e d th e
r e q u e st f o r
F a x ed t he
r e q u e st fo r
F a x ed t he
r e q u e s t fo r Fig. 13. Additional result completion
re qu e st q u o ta t io n q u o ta tio n q u o ta ti on
c o m pa n y to A to B to C
co m pa n y c om p a n y co m pan y

図 12 改善後のシミュレーション結果
Estim ate C ondition of
Fig. 12. Simulation result after improvement H oping

Price Price of H oping

C om pany N um ber D elivery D ata of H oping
ボトルネックが検出された各モデルに対して改善を施し Pass or F ail Q uality of H oping
D elivery D ate K inds of Parts
た。まず，見積依頼書の FAX 送信に関しては，処理を人手 Q uality C om pare Estim ate
K inds of Parts
から自動化した。また，モデルにおいて見積送信が 1 社し Extract Estim ate
か行われないことがある，という不備を発見したので修正 Add Pass or F ail

を加えた。作成した To-Be モデルに対して再度シミュレー 図 14 生成されたクラス図

ションを行った。結果を図 12 に示す。 Fig. 14. Generated Class Diagram
図 12 の結果より，動的待機時間のバーが全体的に短くな
っており，ボトルネックが改善されていることが分かる。 をモデル変換にかけてクラス図を生成した。図 14 に生成し
(３) モデル変換 ARIS のモデル変換機能を利用し たクラス図を示す。
て，作成し改善を施した各 eEPC 図をそれぞれ UML へ変 作成した希望条件と見積の各クラスとその属性，メソッ
換した。図 13 にクラス変換可能状態の eEPC 図を示す。 ドが生成された。ここでは 2 つのクラスについて述べたが，
ARIS によるクラス変換では，ファンクションにメソッド 実際には 6 つの eEPC 図への追加が行われ，クラスが生成
及び属性の指定を行い，クラス要素を追加した eEPC 図を されている。完成したクラス図を元に，図 7 で示した 3 層
用意する。この eEPC 図をインプットとして，追加したク 構造・環境で Java による構築を行い，動作を確認した。
ラス要素はそのままクラス要素として，ファンクションは 〈3･4〉 従来方式と本方式におけるクラスの比較 本
クラス要素のメソッド要素として，それぞれ一対一対応に 方式における eEPC 図からの変換による UML クラスと，
変換される。図中では，点線で囲んだ箇所が追加したクラ ビジネスプロセスモデルを介さない従来方式による UML
ス要素及びメソッド要素となるファンクションである。な クラスとの比較結果を表 1 に示す。
お，今回，本方式において，予め用意するクラス要素であ 表 1 に示す結果は，図 10 で示したファンクションツリー
った属性は，図中のデータ要素であるモデルの属性を参照 の各ファンクションのうち，「部品の確認」「見積の検討」
し，そこからすべて選択したため，変換時に改めて要素を 「希望条件の決定」「見積受付」「見積依頼」「結果報告」そ
一から考える必要はなかった。 れぞれのファンクションを実現するのに要したクラス数を
この図で加えられているクラスは「見積」と「希望条件」 本方式と従来方式で比較したものである。
のクラスであり，それに付属する形で「価格」や「品質」 表 1 より，
「部品の確認」ファンクションを除くすべての
の属性もまた接続されている。1 ヶ所クラスが無いファンク クラスが同数になった。つまり，ビジネスプロセスモデリ
ションもあるが(「結果報告する」は遷移先の eEPC 図を示 ング経由で作るクラス数と手動設計によって作るクラス数
すモデル要素であり，ファンクションではない)，これはシ もあまり変わらないことを示している。しかし，
「部品の確
ステムが直接かかわる部分ではないので除外した。この図 認」ファンクションにおいては手動設計時にはクラスを作

1448 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

表1 ファンクションに関連するクラス数の比較 素の繰り返しで構成される単純なものであり，機械的に記
Table 1. Comparison of class that composes function 述できた。
Function UM L generation by person UM L generation by BPM
本ビジネスプロセスモデリングは，段階的にモデリング
Confirm Parts Off the subject 2
Examine E stimate 2 2 を行い，1 つの機能について順に設計していくという点にお
Decide Condition 2 2 いて，従来の手動設計とは異なり，システム全体のユース
Accept Estimate 2 2
Request Estimate 4 4
ケースの機能を満足するようなクラスをその場で考える必
3
Report Result 3 要がない。このことによって，設計者の判断を 1 つの機能
を実現することのみに注目させることができる。システム
成していなかったが，ビジネスプロセスモデリング経由で 全体の機能の実現度合いはビジネスプロセスシミュレーシ
は 2 個の部品に関するクラスが生成された。この結果より， ョンによって確かめることが可能である。また，シミュレ
手動設計による従来方式ではシステムに必要な部品に関す ーションにおいては，図 11，12 で示したようにボトルネッ
るクラスを見逃してしまった可能性がある。 クの検出と機能追加などの改善が可能である。これらの半
更に，両方式で作成したクラスの属性とメソッドについ 機械的な設計を行う本方式の方が従来方式に比べて，人の
ては，本方式の方が属性は詳細に，メソッドは細かく分割 システムに及ぼす影響が少なくなると考えられる。
されるという結果になった。両方式で作成したクラスのう 〈4･2〉 モデル変換の効用 手動設計による UML 設
ち，表 1 の「見積書の検討」ファンクションを構成するク 計では，システムの流れからクラスを抽出し，属性・メソ
ラスを比較対象として説明をする。対象となるクラスは， ッドを加えていく方法をとったが，ビジネスプロセスモデ
両方式で共通に作成した「見積」クラスである。 リングを経由する方法では各ファンクションからクラスを
図 6 に示した従来方式で作成した
「見積」
クラスでは，
「会 考え出す方法をとる。従来方式によるクラス図の作成には，
社情報，見積情報，結果」という属性であったが，図 14 に ユースケースからクラスになりそうな単語をできるだけ抽
示した本方式で作成した「見積」クラスでは，
「価格，会社 出してから絞り込んでいく関係上，不必要なクラスが出た
情報，合否，納期，品質，部品の種類」とほぼ同じ内容で り，必要なものを削ったり，見落としてしまう可能性があ
はあるが，詳細になっている。メソッドについては，従来 る。
「見積データ作成( )」
方式では， 「見積データ取得( )」
「見積 ビジネスプロセスモデリングにおけるモデル変換では，
データ更新( )」というメソッドであったものが，本方式では， プロセスの流れが明確になっているため，的確で無駄のな
「見積合否結果を加える( )」というものに変わっている。従 いクラス生成が可能になる。更にクラス図作成に関しても，
来方式では，
「見積」クラスでデータの作成・取得・更新を eEPC 図に加えたクラスをそのまま作成エディタに持って
行っていたのだが，データの操作が別クラスに分割され， 来ることができるので，手間が省ける。ファンクションか
本方式の「見積」クラスでは，合否結果のみを取得するよ らクラスとともに属性を決めるが，この属性からクラスの
うになっており，メソッドの機能としてはより細かくなっ 修正するべき点が発見できることも期待できる。また，本
ている。 モデリング方式では，UML モデル変換ガイドラインを策定
しており，本ガイドラインに沿って作成されるビジネスプ
4. 評価と考察
ロセスモデルは，UML クラス変換において付加するパラメ
〈4･1〉 ビジネスプロセスモデリングの効用 部品調 ータの指針となるモデル要素が予め含まれている。パラメ
達システムにファンクションツリーと eEPC 図の 2 種類の ータ設定の際には，すでに作成したモデル要素を対応させ
図にて，本方式のモデリング方式に従い，ビジネスプロセ るのみで工程を進めることができた。
スモデリングを行ってきた。 表 1 に示したクラス数，及びクラスのメソッドと属性の
ファンクションツリーの設計はシステムのファンクショ 相違結果について考察する。表 1 において従来方式で生成
ンを配置するため，UML におけるユースケース図の作成と されなかった 2 個のクラスは，部品の在庫確認を行うクラ
同様の作業であり，ファンクション設計がその後のシステ スである。これらのクラスがないと，バイヤーは現在どの
ム設計を左右する。ファンクションの選択には明確な指針 程度部品を持っており，どの程度更にサプライヤーを選ぶ
がないため，UML のユースケース記述からのユースケース 必要があるのかを把握することが困難になり，そのクラス
抽出が妥当であると考える。ファンクションは，営業部で は実際の利用を考えると，必要なものであり，見落として
は計 5 つ，資材部では計 4 つになり，双方の部署で部品調 いたクラスであったと言える。
達システムが直接関与しないファンクションは（
「部品の納 属性とメソッドについては，本方式では，属性はほぼ同
入」「面談」「契約の手続き」），調達業務の全体の流れを考 じ内容ではあるが，細かく設定され，メソッドは詳細な分
え，外部システムのファンクションではあるが，部品調達 割が行われていることから，本方式の方が細かで業務に適
システムに組み込んだ。結果，システム内外で 9 個のファ した機能分割ができていると言える。従来方式では，本方
ンクションができた。 式におけるビジネスプロセスモデリング工程の機能分割を
eEPC 図の設計は，ファンクションとイベントの 2 つの要 行う段階で各クラスの設計を行うため，設計者は，各機能

電学論 C，127 巻 9 号，2007 年 1449

を実現できると考えられるものを属性やメソッドとして設 (４) 電気学会ワークフロー調査専門委員会：「ワークフローの実際」，日
科技連
定していた。しかし，本方式では，機能分割後，更にその (５) Y. Kojima, S. Kitajima, T. Kaminishi, H. Koizumi, and K. Ban :
機能ごとにビジネスプロセスを記述し，そのビジネスプロ “An Implementation of A Parts Procurement Support System
based on Business Process Modeling and Its Evaluation”, IPSJ
セスから「実際に必要となるデータと業務ファンクション」
IS-90 Report, Vol.2004, No.116, pp.9-16 (2004) (in Japanese)
が属性とメソッドになる。結果として，提案手法で生成さ 小島義幸・北島聡史・上西 司・小泉寿男・坂 和磨：「ビジネスプ
れる属性やメソッドは業務に対応した詳細なものになった ロセスモデリングによる部品調達システムの構築とその評価」，情報
処理学会 IS-90 研究報告, Vol.2004, No.116, pp.9-16 (2004)
と考えられる。 (６) S. Kitajima, Y. Nakamura, T. Kaminishi, H. Koizumi, and K.
〈4･3〉 開発期間への影響 本方式の開発期間への影 Ban : “A Method of Information System Development based on
Business Process Modeling”, IPSJ DPS-119 Report, Vol.2004,
響を比較するため，従来方式と本方式について，モデリン
No.89, pp.15-20 (2004) (in japanese)
グ期間と実装期間の工数的な評価を行った。両方式の構築 北島聡史・中村義幸・上西 司・小泉寿男・坂 和磨：「ビジネスプ
は，UML による設計経験と Java プログラミングの実装経 ロセスモデリングによる情報システム構築の一手法」，情報処理学会
DPS-119 研究報告, Vol.2004, No.89, pp.15-20 (2004)
験を持つ同一人物が行った。 (７) T. Ishikawa, T. Asada, J. Kurihara, I. Nakamura, H. Shiozawa,
構築に要した期間は，下記の通りである。 and H. Koizumi : “A Business Model of Parts Purchasing System
and Its Evaluation on the Implementation”, IPSJ DPS
・モデリング 従来方式：約 3 ヶ月，本方式：約 2 ヶ月
Workshop, pp.133-138 (2001) (in japanese)
・実装 従来方式：約 6 ヶ月，本方式：約 5 ヶ月 石川俊之・浅田孝利・栗原 潤・中村一郎・塩澤秀和・小泉寿男： 「自
モデリング期間の差は，ビジネスプロセスモデリングと 動選考機能を持つ部品調達ビジネスモデルと構築評価」，情報処理学
会 DPS ワークショップ，pp.133-138 (2001)
UML 分析の方式の違いによるものであり，実装期間の差 (８) J. Kurihara, H. Koizumi, T. Ishikawa, and T. Dasai : “A Method
は，従来方式で発生したクラスや機能の見落としによる実 of EC Model Implementation Using Web Service”, T.IEE, Vol.124,
No.1, pp.39-47 (2004-1) (in Japanese)
装工程での後戻りによるものである。クラスの見落としが
栗原 潤・小泉寿男・石川俊之・太細 孝： 「Web サービスを活用し
なく，再設計も生じなかったことから，本方式のビジネス た EC モデルの実装方式」，電学論 D 124, 1, pp.39-47 (2004-1)
プロセスモデリングによる分析設計により，構築期間が従 (９) ARIS IDS Scheer, http://www.ids-scheer.co.jp
(10) M. Yamada : “Introduction to Model-driven Development”, IPSJ
来方式に比べて短縮された効果があったと考えられる。 Vol.45, No.1, pp.3-9 (2004) (in Japanese)
山田正樹：「モデル駆動開発とその周辺」，情報処理学会誌 Vol.45,
5. ま と め No.1, pp3-9 (2004)
(11) S. Kitajima, Y. Nakamura, T. Kaminishi, H. Koizumi, and K.
本稿では，ビジネスプロセスモデルを用いた情報システ Ban : “An Information System Development Method connecting
ム構築法を提案し，部品調達システムのプロトタイプを対 Business Process Modeling with Executable UML and its
experimental evaluation”, IPSJ DPS-121 Report, Vol.2005,
象として評価を行った。本方式は，ビジネスプロセスを段 No.89, pp.1-6 (2005) (in japanese)
階的に機能分割してモデリングし，その結果を UML のモデ 北島聡史・中村義幸・上西 司・小泉寿男・坂 和磨： 「ビジネスプ
ロセスモデリングと実行可能 UML を連結させた情報システム構築
ルに変換し実装に繋げていく開発方式である。本方式に則
法の試作と評価」，情報処理学会 DPS-121 研究報告, Vol.2005,
って，ファンクションツリーと eEPC 図を作成し，そのま No.3, pp.1-6 (2005)
ま UML に変換すれば，以降，UML モデルによる設計を行
うことができた。また，本方式は，従来方式に比べて，ク
ラスの見落としも実装工程での後戻りもなかったことか
ら，開発期間の短縮に繋がった。 大 川 勉 （正員） 1978 年大阪大学基礎工学部情報工学
今後は，次の作業を継続していくことにしている。 科卒業。同年三菱電機（株）に入社，現在に至
(１) 本方式に MDA(Model Driven Architecture)(10)技術 る。ソフトウェア生産技術の研究開発，EOA
技術開発，オブジェクト指向技術開発，情報シ
を盛り込み，BPM 技術と連携させ，実装前にモデルの動作
ステムインフラ（ネットワーク，セキュリティ，
検証を行う方式の研究を進めていく(11)。 アクセス制御，ワークフロー，開発方法論など）
(２) 他の情報システムへの適用を行い，本方式が一般的 の技術開発，基盤システム構築に従事。情報処
に適用可能なものであるかについて，効果を確かめる。 理学会会員。
（平成 18 年 9 月 16 日受付，平成 19 年 3 月 8 日再受付）

上 西 司 （非会員） 1983 年 2 月 6 日生。2005 年 3 月東

京電機大学卒業。同年東京電機大学大学院理工
文 献 学研究科情報システム工学専攻入学。2007 年 3
月修士課程修了。
(１) Object Management Group，http://www.omg.org
(２) 戸田保一・飯島純一：「ビジネスプロセスモデリング」，日科技連
(３) H. Seidelmeier：“Prozessmodellierung mit ARIS”，BNN Inc.
坂和磨（監訳） ：
「ARIS ビジネスプロセスモデリング」，ビー・エヌ・
エヌ新社

1450 IEEJ Trans. EIS, Vol. 127, No.9, 2007

 プロセスモデル活用システム構築

小 島 義 幸 （非会員） 1980 年 5 月 3 日生。2003 年 3 月東 小 泉 寿 男 （正員） 1961 年，東北大・工・通信卒業。同

京電機大学卒業。同年東京電機大学大学院理工 年三菱電機（株）入社。基本ソフトウェア開発，
学研究科情報システム工学専攻入学。2005 年 3 ネットワーク情報システム基盤，大規模応用シ
月修士課程修了。 ステムの開発に従事。1998 年より，東京電機
大学理工学部教授。博士（情報科学）。情報処
理学会，電子情報通信学会，情報処理学会フェ
ロー。

平 林 秀 一 （非会員） 1983 年 8 月 10 日生。2006 年 3 月

東京電機大学卒業。同年東京電機大学大学院理
工学研究科情報システム工学専攻入学。現在，
修士課程在学。

電学論 C，127 巻 9 号，2007 年 1451