Topics
Enterprise Architecture
Kaizen、BPM、アジャイル方式Reza Shafii著
日本の経営哲学である継続的改善は Kaizen としても知られていて、組織による品質と運用効果の改善方法に非常に大きな影響を与えてきました。今日の企業では、より新しいビジネスプロセス管理 (BPM) の概念が、継続的な改善を実現する上で重要な役割を担うようになっています。この記事では、Kaizen 原則の実施形態として BPM をどのように利用できるかについて説明します。また、アジャイル開発方式の基礎概念の一部を応用することで、そのようなソリューションの供給が最適化される理由についても述べます。 Kaizen の実施形態としての BPM経営管理分野で使用されている Kaizen という言葉 (逐語的には「良い変化」を表す) のルーツは、1950 年代日本の産業界に遡ります。現在では、継続的改善と言い換えられることのほうが多いため、ここではそれに従います。継続的改善という経営哲学を詳しく見ていくとなるとこの記事の範囲を越えてしまいますが、手短に言うと次のようになります。継続的改善では大まかに言って、無駄を省いて品質を向上させることに目標を定めて、 検証および適合化という活動の永続的なサイクルを促す一連のアイディアが 1 つに統合されます。 継続的改善の原則の 1 つは、一般事務員であれ本社の役員であれ、プロセスのユーザーには、常に積極的にその作業を分析して改善を提案することが求められるということです。上位レベルでの継続的改善は、次の活動で構成された サイクルと見なすことができます。
ビジネスプロセス管理は、継続的改善という抽象概念のビジネスプロセスレベルでの実施形態と見なすことができます。 つまり、BPM は、組織のビジネスプロセスを繰り返し最適化できるフレームワークを提供します。 ここで、BPM 分野の著名なエキスパートである ブルース・シルバー氏の意見を引用すると、「BPM のベースになっているのは、継続的なプロセス改善のサイクルという考え方です」。 目下のところ、標準的な BPM 方式や圧倒的に普及度の高い BPM 方式というものは存在しませんが、一般的には、上位レベルでの BPM 活動のサイクルには、プロセス分析、プロセスのモデル化、プロセスの実行、プロセスの監視などの要素が認められています。 継続的改善と BPM の活動サイクルを比較してみると、図 1 のようになります。 図 1. 継続的改善と BPM の活動サイクル (画像を拡大するには画像をクリック) 通常、これらの活動は、モデル化するプロセスとその分野に関して直接の知識を備えているビジネスアナリスト要員が行います。 BPM 活動の実行目標が、モデル化されたプロセスのエンドユーザーであるビジネスユーザーの生産性とビジネスエクスペリエンスの強化に置かれることに着目することも重要です。 BPM ソリューションは、BEA AquaLogic BPM Suite などの BPM スイート (BPMS) と呼ばれるソフトウェアによって可能になります。 BPMS ソフトウェアの重要な属性の 1 つとして、それぞれのビジネスアナリストが独立して BPM サイクルの活動を逐次分析できるようにする機能があります。予想通り、このソフトウェアは、継続的改善の重要原則に沿っています。エンドユーザーに権限を与えて、そのアクティブな役割によって扱うプロセスを最適化できるように考慮されているのです。 BPMS の場合、この原則は、既存のプロセスのパフォーマンスに対する可視性、プロセスに加えられる変更の結果を分析するツール、ビジネスアナリストがプロセスを再モデル化して実行できる動的な環境をビジネスアナリストに提供する機能として実現されています。 優れた BPMS ソフトウェア製品とは、このような能力をビジネスアナリストに提供し、しかも最低限の IT 投資だけですむ製品のことです。したがって、そのような製品を使用すると、ビジネスアナリストは、シームレスに BPM サイクルの反復を逐次分析し、作業中のプロセスを継続的に改善することができます。プロセス強化を実現しようとするこのようなたゆまぬ努力を通じて、次のような重要な問いかけが想起されます。 BPM サイクルの 1 回の繰り返しには、その大きさと労力の点でどのようなスケールが妥当なのでしょうか。結果的に、アジャイルソフトウェア開発方式にはこの点で強く引き付ける要素があるようです。 BPM のアジャイルなスタイルアジャイルソフトウェア方式というトピックにはさまざまな内容がからんでくるため、詳しく述べようとするとこの記事の範囲を越えてしまいます。 ただし、 アジャイルマニフェストで概要が述べられている原則を参考にして、アジャイルソフトウェア方式の定義をある程度把握できます。この文書は、多くのソフトウェア開発リーダーによって 2001 年に提唱されました。開発者は、従来のオールインワン形式で、大量な前払い設計のウォーターフォールモデルとは異なる方法を採用し、それぞれのアプローチ間の共通基盤を考案することを試みました。 アジャイルマニフェスト原則の背景となっている主な原動力は、複雑さが基本レベルを越えている 1 つのソフトウェア製品で、すべての顧客要件と関連のソフトウェア設計を最初から正確に定義することは難しすぎる、または不可能かもしれないという考え方です。 このような困難は、製品の納期遅れ、ソフトウェア品質の低下、変化する要求に対応不能などのさまざまな問題を招く可能性があります。この課題に対処するため、アジャイル原則ではまず第一に、ソフトウェアを一度に少しずつ構築する方法が規定されています。また各サイクルで行った作業をその都度評価してプロセスを改善し顧客の期待にさらに応えることが推奨されています。 一般に、アジャイルソフトウェア開発の反復期間は非常に短く、数週間から 2、3 か月程度となっています。それぞれの反復も計画セッションで開始され、レビューセッションで終了します。その間に、チームはそれぞれのパフォーマンスを内省し、次の反復に向けての改善を提案して必要な適合化を行います。 この検証および適合化というアプローチでは、継続的な改善サイクルが提供されるため、アジャイル原則に従う方式は、ソフトウェア開発レベルでの継続的改善の実施形態と見なすことができます。 アジャイル方式は BPM サイクルの反復に十分適合すると推論できる理由が少なくとも 2 つあります。 第一に、すでに検討したように、BPM は BPMS ソフトウェアを通じて行われます。 実行用にモデル化されたそれぞれのビジネスプロセスは、BPMS ソフトウェアプラットフォームの構成と考えることができます。プロセスをモデル化することで、実際、ビジネスアナリストはソフトウェア実行モデルも作成することになります。ちょうど開発者がコードを設計して書く場合と同じといえます。したがって、当然のことながら、最初から一連の要件と設計を正確かつ完璧に考えることの難しさやそれに関連する問題などの、ソフトウェア開発におけるウォーターフォールモデルの失敗から得られた同じ教訓が、プロセスのモデル化にも当てはまるはずだという推論が成り立ちます。 同じように、BPM 向けのアジャイル方式の利用はこのような問題の軽減に役立つと考えることができます。 第二に、この記事の最初のセクションで述べたように、BPM が継続的改善の実施形態の 1 つだとすると、この経営哲学をも内包する方式が要求されるのは当然だといえます。しかも、すでに検討したように、アジャイル方式はこの要件を満たしているのです。 標準的な BPM 方式や広く普及した BPM 方式はまだ存在していません。したがって、アジャイル方式の場合も同じです。 実際は、多くの組織が独自の方式を定義しています。 既存の方式を評価する場合は、 アジャイルマニフェストの原則に合っているかどうかを把握するため、次のように問いかけることが重要です。
その一方で、独自のインハウス BPM 方式を最初から開発する場合は、既存のアジャイルソフトウェア開発方式をベースラインにすることもできます。ただし、そのような道筋に従うときは、ソフトウェア開発のプロジェクト管理という側面がより中心となる既存の方式を選択することが重要です。たとえば、 エクストリームプログラミング (XP) のようにソフトウェア開発自体の固有な原則が重視される方式ではなく、 スクラムなどが候補として考えられます。 アジャイル BPM とソフトウェア開発の相乗作用ここまでの段階で、ビジネスアナリストの活動のみを視野に入れて検討してきました。 BPMS テクノロジの最終目標は、BPM サイクル全体に渡って広い範囲でビジネスユーザーが参加できるようにすることですが、一般に、現在の BPMS プラットフォームには、相当なソフトウェア開発の必要性が伴います。多くの場合、このような開発作業は、適切なプロセスノードとそのターゲットシステムを正しく統合したり、人による対話型操作用にプロセスで使用されるユーザーインターフェースをカスタマイズしたりする場合に必要になります。通常、そのような作業は、少なくとも新しいプロセスの実行フェーズの最初の反復時に要求され、行われた変更のタイプによっては、その後の改善サイクルで必要になる場合もあります。 BPM のプロセス実行フェーズで必要になるソフトウェア開発作業にもアジャイル開発方式を採用した場合は、BPM プロセス実行の反復を BPM サイクルの反復と同期させてこの 2 つの間で相乗効果のあるリズムを生み出すことができます。 図 2 に示すように、そのような同期を行った場合は、BPM 反復でのプロセス分析とモデル化作業を、ビジネスアナリストと開発チームの連携によるプロセス実行作業の基盤にすることができます。 図 2. BPM とソフトウェア開発の反復の同期 (画像を拡大するには画像をクリック) 図 2 の中の青い矢印で示した BPM と開発サイクル間のプロセスモデルの遷移が、ビジネスアナリストとソフトウェア開発チームによる意思疎通の唯一の接点であってはなりません。真のアジャイルの考え方としては、2 つのチームが密接に連携して、詳細なプロセスモデルが正しく実行されるようにする必要があります。プロセス遷移ポイントは、作業中の特定バージョンのプロセスに対する主要な担い手の移行を示します。つまり、この時点で、新しいバージョンのプロセスが、ビジネスアナリスト主導から開発者主導へ、あるいはその逆へと変化します。 BPM と開発サイクルを同期させる上で重要となる 2 つの要素は、責任の遷移のスムーズさと、プロセス実行時のビジネスアナリストと開発者間の連携の簡潔さです。 これらの要素は、どちらのタイプのユーザーでも、共有プロセスモデルを適用する BPMS ツールの能力によって著しく強化できます。この機能があるため、開発プロセス作業からビジネス分析作業への遷移が要求されるたびに、異なる形式間でプロセスを変換する必要がなくなります (この問題の非常に優れた分析については、ブルース・シルバー氏によって投稿された 「Roundtripping Revisited」 を参照してください)。 たとえば、AquaLogic BPMS はそのような統一されたプロセスモデルを実現するので、結果的にユーザーは AquaLogic BPM Studio を使用して、単にクリックするだけで BPM プロジェクトのパースペクティブを「ビジネスアナリスト」プロファイルから「ビジネスアーキテクト」プロファイルまたは「開発者」プロファイルへと切り換えることができます。その場合に、基礎となるプロセスを変換する必要はありません。これらのプロファイルはそれぞれ、ユーザーの役割をモデル化し実装するニーズに適した異なるツールを、ユーザーに提供します。 最後に、改善された新しいビジネスプロセスのバージョンを継続的に本稼動用として配備するには、強力なバージョン管理機能を備えた BPM 製品を使用する必要があるという重要な点を指摘しておきます。 BPMS 製品は、特定バージョンの既存のプロセスインスタンスを問題なく完了するために、プロセスの複数のバージョンを同時に実行できる機能を備えている必要があります。 優れた BPMS 製品としては、同じプロセスの新しいバージョンを間断なく展開できる必要もあります。 もちろん、AquaLogic BPM Studio には、この両方の重要なバージョン管理機能が用意されています。 結論BPM は、組織のビジネスプロセスに応じて継続的改善を行うための強力な出発点にすることができます。アジャイルソフトウェア開発方式は、継続的改善を可能にする BPM 方式を開発する上で、効果的なベースラインとして役立つ可能性があります。また、BPM サイクルの供給作業に参加する主要な 2 つのチーム (ビジネスアナリストとソフトウェア開発者) が対話する場面で重要な相乗作用を生み出すきっかけにもなることでしょう。 参考資料
Reza Shafii氏は、BEA システムズのプロフェッショナルサービスで職務を遂行しています。 |
Printer View