プロセスモデル

提供: miniwiki
移動先:案内検索

プロセスモデル: process model)とは、何らかのプロセス(過程、工程)の模型(モデル)である。 化学工学はプロセス産業と呼ぶように、プロセスモデルが処理モデルである。 ビジネスプロセスモデルとは、企業の仕事の仕方のモデルである。 コンピュータでは、処理方法がプロセスモデルである。並列処理の方式などがある。 ソフトウェアプロセスは、ソフトウェアを設計し、利用し、廃棄する流れの一つの視点を提供するものであり、人の作業とコンピュータの処理を含む。

コレット・ローランド[1]はプロセスモデルを次のように定義している[2]:

同じ性質を持つプロセスは1つのプロセスモデルに分類する。つまり、プロセスモデルはプロセスの抽象記述である。プロセスモデルが抽象的であるとすれば、個々のプロセスは実体化したものである。

プロセスモデルは様々な開発に繰り返し利用するため、その実体は多数存在する。 […] プロセスモデルは「物事をどのようにするか(するべきか/しなければならないか)」を記述したものである。

プロセスモデルは、プロセスがどのようになるかを仮定し、予測するものである。仮定を立てるためには、前提条件が必要となり、時間的な条件、論理的な条件または空間的条件を設定する。時間的条件には初期条件,終了条件がある。論理的な条件には事前条件,事後条件,不変条件がある。空間的条件には、境界条件がある。 プロセスがこうあるべきだという方針は、常に状況(前提条件の変化)に応じて改善していくものである。

主な目的

  • 記述的な目的
    • プロセス内で実際に何が起きるかを順次記述する。
    • プロセスを外部の視点から見て、そのプロセスをより効率的にする改善点を見出す。
  • 規範的な目的
    • ある目標を達成するためのプロセスを定義し、どのようにすべきかを示す。
    • 規則、ガイドライン、行動パターンなどに帰着してプロセスの改善を促す。厳密な規則から柔軟なガイダンスまで様々である。
  • 説明的な目的
    • プロセスの原理を説明する。
    • 原理に基づいてとりうるコースを探索/評価する。
    • プロセス間および満たすべき要求との明確なリンクを確立する。

用途

「理論的観点では、プロセスメタモデルでは開発プロセスで何がどういう理由で発生するかといったことを記述するための鍵となる概念を説明する。実施側の観点では、プロセスメタモデルは技術者や開発者に一種の手引きを提供する。」[Rolland1993][3]

ビジネスプロセスのモデリングでは、プロセス改善の必要性を予測したり、改善すべき問題点を指摘したりする。これは必ずしも情報技術の導入を意味しないが、情報技術の導入がビジネスプロセスのモデル化のきっかけとなることが多い。変革管理プログラムによってプロセスが実行に移される。技術革新とともに、ビジネスプロセスモデル(BPM)の重要性が増してきている。サポート技術として、統一モデリング言語(UML)、モデル駆動型アーキテクチャサービス指向アーキテクチャなどがある。

プロセスモデリングは企業ビジネスアーキテクチャのプロセス的側面を明らかにし、最終的にエンタープライズアーキテクチャの構築につながる。ビジネスプロセスと企業のその他の側面(システム、データ、構造、戦略など)の関係を明らかにすることで変革の分析と計画に寄与する。例えば、企業の合併においては、両社のプロセスを詳細に把握することで冗長となる部分が明らかとなり、合併がスムーズに進むことになる。

プロセスモデルはビジネスプロセス・リエンジニアリングの鍵であり、シックスシグマにおける継続的改善の鍵でもある。

プロセスモデルの分類

適用分野による分類

[Dowson1988][4] は、以下の4つの異なる意味でプロセスモデルという用語が使われているとした:

  • 活動指向: ある製品を定義する目的の下で関連する活動群。目標達成までの半順序的ステップ群。[Feiler1993][5]
  • 製品指向: 製品を目標のレベルにするための一連の活動。
  • 決定指向: 特定の製品定義のために必要な決定の集合。
  • 文脈指向: 製品の改良をもたらす一連の文脈(コンテキスト)の集合。

レベルによる分類

ローランドによれば[2]、プロセスは以下のように分類され、それぞれモデル化手法が異なる。

  • 戦略的プロセス
    • 代替案を検討し、それを実行する計画を立案することもある。
    • 高度な活動であり、代替案の選択も重要な選択となる。
  • 戦術的プロセス
    • 計画の実行を支援する。
    • 実際の計画実行により近く、計画の詳細化を行う。
  • 実装プロセス
    • 最も下位のプロセス。
    • 計画を実施するための詳細を扱う。

粒度による分類

粒度[6]とは、プロセスモデルの詳細さのレベルを意味する。

「粒度は提供すべき手引き、説明、手順の種類に影響を与える。粒度が粗い場合、あまり具体化しない。粒度が細かい場合、より詳細なものを提供する。必要とされる粒度は状況に依存する」[Rolland1998][2]

顧客や経営者は粗い粒度のプロセス記述を要求する傾向があり、意思決定のための概略的情報を必要とする。一方、ソフトウェア技術者やユーザーは細かい粒度のプロセスモデルを必要とし、それによって具体的手順を知ったり、個々の人々の依存関係が明らかになる。

細かい粒度のモデル記述法もあるが、粗い粒度のモデル記述法の方が古くから存在する。プロセスモデルは理想的にはあらゆる粒度に対応できるのが望ましい(例えば、Process Weaver [Fernström1991][7])[Rolland1998][2]

柔軟性による分類

プロセスモデルは何らかの予測を行うが、実際に起きることは予測通りではない[Rolland1999][8]。従って、フレームワークを実際の状況に合わせて修正することでモデルの価値が向上する。このようなフレームワークの研究を Situational Method Engineering と呼ぶ。

方式を構築する手法は柔軟性の低いものから高いものまである[Harmsen1994][9]

技法

ローランドはプロセス表現技法として、「文書」、「プログラム」、「ハイパーテキスト」の3つのスタイルを挙げた[Rolland1998][2]。これをまとめたのが以下の表である:

プロセス表現スタイル
パースペクティブ 文書 プログラム ハイパーテキスト
利用法 人間同士の間で対話的に用いる マシンが実行する プロセスの異なる観点(製品の部品、決定、論点、課題)を結びつけたネットワーク
特徴 非決定性がある 事前に決めた範囲でのプロセスの可変性をサポート
応用範囲 規範的目的で使用(柔軟な手引き) 規範的目的で使用(厳密な規則) 記述的および説明的目的で使用

ローランドによれば、自然言語や非定型的な図が情報システムのプロセスモデルを表現するために使われてきた。また、ソフトウェア工学においては、より形式的なプロセスモデルが使われてきた。これについては、[Armenise1993][10]、[Curtis1992][11]、[Finkelstein1994][12]でも解説されている。そのような形式的プロセスモデルはプログラミング言語と関連しており、次のような対応がある:

ビジネスプロセスモデリング

ビジネスプロセスモデリング: business process modelingBPM)は、企業のプロセスの現状と将来を表現する活動であり、それにより現状のプロセスへの理解が深まり改善が生み出される。BPM はアナリストやマネージャがプロセスの効率化や高品質化を目指して行う。BPM によるプロセスの効率化にはITが関わる場合が多い。

改善されたビジネスプロセスを実施に移行させる際には変革管理が必要となる。技術革新とともに、BPMによるモデルを完全に実行可能にできる可能性が高まってきている。

ビジネスプロセスモデリングはビジネスプロセス管理 (BPM) において、重要な役割を担う。どちらも同じ頭字語(BPM)となるため、両者を混同することがある。

BPM で使われる標準モデリング言語には以下のものがある[15]

モデル駆動型アーキテクチャサービス指向アーキテクチャといった技術がビジネスプロセスモデリングと関連している。

BPM はエンタープライズアーキテクチャのプロセス的側面を扱う。企業全体のシステム(データアーキテクチャ、組織構造、戦略など)におけるビジネスプロセスは企業改革に大きな意味を持つ。例えば、企業の合併において、両企業のビジネスプロセスを詳細に分析することで業務上冗長な部分を効果的に特定できる。ビジネスプロセスモデリングはビジネスプロセス・リエンジニアリング (BPR) にとっても、シックス・シグマのような継続的改善手法にとっても重要である。

関連項目

外部リンク

脚注

  1. : Colette Rolland
  2. 2.0 2.1 2.2 2.3 2.4 C. Rolland. A Comprehensive View of Process Engineering. Proceedings of the 10th International Conference CAiSE'98, B. Lecture Notes in Computer Science 1413, Pernici, C. Thanos (Eds), Springer. Pisa, Italy, June 1998
  3. C. Rolland. Modeling the Requirements Engineering Process, 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases, Budapest, Hungary, June 1993.
  4. M. Dowson. Iteration in the Software Process, Proc 9th Int. Conf. on Software Engineering, 1988.
  5. P. H. Feiler, W. S. Humphrey. Software Process Development and Enactment: Concepts and Definitions, Proc. 2nd Int. Conf. on "Software Process", 1993.
  6. : granularity
  7. C. Fernström, L. Ohlsson, Integration Needs in Process Enacted Environments, Proc. 1st Int. Conf. on the Software Process, IEEE computer Society Press, October 1991.
  8. C. Rolland, N. Prakash, A. Benjamen. A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4. Springer-Verlag London Ltd , 1999
  9. A. F. Harmsen, J. N. Brinkkemper, J. L. H. Oei; Situational Method Engineering for information Systems Project Approaches, Int. IFIP WG8. 1 Conf. in CRIS series: Methods and associated Tools for the Information Systems Life Cycle (A-55), North Holland (Pub. ), 1994.
  10. P. Armenise, S. Bandinelli, C. Ghezzi, A. Morzenti, A survey and assessment of software process representation formalisms Int. Journal of Software Engineering and Knowledge Engineering, Vol. 3, No. 3, 1993.
  11. B. Curtis, M. Kellner, J. Over, Process Modeling, Communications of ACM, vol 35 n°9, september 1992, pp 75-90.
  12. 12.0 12.1 12.2 12.3 A. Finkelstein, J. Kramer, B. Nuseibeh (eds). Software process modelling and technology. Wiley, New York, 1994
  13. L. Jacherri, J. O. Larseon, R. Conradi, Software Process Modelling and Evolution in EPOS, in Proc. of the 4th Int. Conf. on Software Engineering and Knowledge Engineering (SEKE'92), Capri, Italy, 1992, pp574-589.
  14. V; Ambriola, M. L. Jaccheri, Definition and Enactment of Oikos software entities, Proc. of the First European Workshop on Software Process Modeling, Milan, Italy, 1991
  15. Business Modeling FAQ”. . 2007閲覧.