mark-wada blog

開発手順

おおまかな開発手順は次のようになる。

こうした手順はウォーターフォール的に書いてあるが、実際にはスパイラル的に行なっていく。開発には、ビジネスプロセスをデザインする「ビジネスプロセスデザイナー」、業務コンポーネントの開発部分を担当する「スーパープログラマー」、実装を請け負う「ITアーキテクト」からなる開発部隊とそれを「プロジェクトマネジャー」が統括する形で行なっていく。

人数も少数精鋭で短期に仕上げて行く。また、非基幹系の業務プロセスで高い正確性を要求されないものなどはβ版で公開し、少しずつブラッシュアップするやり方も行なう。

ここで特徴的なのは、エンドユーザのひとたちと対面して開発することである。そのためには、要求が出たらすぐに実装して見せてあげることが必要となる。こうした開発方法をここでは、「対面開発（Face2FaceDevelopment)]と呼ぶことにする。ユーザの要求の”ぶれ”を早期に吸収し、手戻りの発生を防止する効果を期待する。

さて、これまでの述べてきた「ビジネスコンポーネント指向開発」の特徴と優位点についてまとめてみる。

１．ミクロワークフローとマクロワークフローに分けたこと
２．ミクロワークフローは、オブジェクトの状態遷移であると捉えたこと
３．オブジェクトを書類単位とし、それを業務コンポーネントとしたこと
４．業務コンポーネントにオープンソースCMSを適用したこと
５．オープンソースCMSにワークフロー機能とオブジェクトデータベースを内臓した「Plone」を採用したこと（オブジェクトを書類の状態遷移としたため、こうした選択となったが、違った要件では別のCMSでももちろんかまわない）
６．業務コンポーネントをBPMで組み合わせて業務プロセス・サービスにしていくこと
７．BPMはプロセスを構築するための道具と捉え、BPMSの色合いを濃くみていること
８．BPMSとして「SAVVION」を採用したこと（ただし、これも他のBPMSでもかまわない）
９．ユーザ参画型の「対面開発（Face2FaceDevelopment）」により、迅速開発と変更要求対応力を重視していること
結局、役に立つBPMというのは、こうした考え方、技術、方法論により実現できると考える。これらを図示すると次のようになる。