短期でのアプリケーション開発を可能とするRAD

短期アプリケーション開発方法論は過去に話題となましたが、現在でも形を変えて使われています。

このRAD（Rapid Application Development：短期でのアプリケーション開発）をBPMで対応しようとすると、その開発における共通点が浮かび上がってきます。ウォータフォール開発の解説の際にも述べましたが、BPMS適用でプロセスを定義する前段で全体の概念的な制約の設定が必要なのです。

RADではそのスパイラルなアプリケーションの開発を行う前に概念設計を行います。その際、主にデータモデルをきっちり固めることがRADのサイクルをスムーズに行うために必要です。

このことはBPMSにおいても同様であり、実際にBPMSを情報システム化する際には実施可能な環境を事前に用意する必要があります。その必要性は、適用するシステムの規模が大きくなればなるほど増してきます。

RADにおいて重要なメンバーの権限と構成

RADの1つ重要な事項として、開発メンバーの権限と構成をあげることができます。RADではその場で判断を行いながら進め、その構成員は次の通りです。

リーダー（プロジェクトマネージャー）
ユーザ責任者（業務要件を決定する人）
設計責任者（システムを設計する人）
製造責任者（設計を受けて即時に製造を行う人）

表2：RADの構成員

ここで重要なことは権限のあるユーザが参画することですが、BPMの開発はそれ以上に権限のあるユーザ主導となることが重要です。そして設計責任者の役割とは、定義されたユーザ要件とサービスとのマッピング設計です。そして製造責任者はアプリケーションの実装なので、必要に応じサービスの追加を行います。

開発のスタイルの変化

システム構築には「インフラ構築」と「インフラの上にのる個々のシステムの構築」という大きな2つの流れがあります。この2つの流れは別々ではなく、まずインフラを構築してから個々のシステムが繰り返し構築されるのです。

BPMSで利用するインフラは従来のインフラとは違います。サービスがインターフェースと同じものなので、サービスインフラといえるでしょう。 BPMSを使ったシステム構築には「システムインフラの構築」「サービスインフラの構築」「ビジネスシステムの構築」という3層の構築が必要となります。

図3：BPMSに必要な3層のインフラ

このようなインフラ自身が安定していない時期の開発方法論として、「ウォータフォールもしくはパッケージ導入によるインフラ構築」と「仕様に対応した業務アプリケーションをBPMSで作ること」があげられます。もし既存のシステムインフラを使うのならば、それを活かす形で新しいシステムを構築する必要があります。

システムインフラの構築が完了すると、当然システムインフラがあることを前提に開発に移りますが、サービスインフラが安定していなければ、サービスインフラ構築をウォータフォール設計で行います。MDAを適用することにより概念的なインフラの設定での並行開発が可能になりますので、実際は並行処理による開発の短縮がはかれます。

サービスインフラが安定してきたなら、RADのようなサービスを再利用しながら本格的なBPMSの構築に移ります。このようにシステムの構築が整理されると、システム基盤の入れ替えでもサービスインフラが緩衝となり、業務システムに影響を与える影響が少なくなります。またBPMSとしてフロー／組織／業務ルールを独立して持つことは、業務の変化がサービスインフラやシステムインフラに与える影響も少なくなります。