URL：　http://www.bptrends.com/resources/bp-manifesto/

オリジナル（英語）を含め、ポルトガル語、リトアニア語、スペイン語、ロシア語、イタリア語、ポーランド語、オランダ語、アラビア語、フランス語、ノルウェー語、デンマーク語、そして最後に日本語が掲載されています。今まで12か国だったのですが、13番目の翻訳として日本語版が追加されました。A4版とレター版の2種類（内容は同じ）があります。どちらでもお好きな方をご覧ください。

ビジネスプロセス・マニフェストについての解説です。

• 解説　ビジネスプロセス・マニフェスト 1
• 解説　ビジネスプロセス・マニフェスト 2
• 解説　ビジネスプロセス・マニフェスト 3

【画像クリックでビジネスプロセス・マニフェストがダウンロードできます】

プロセス名に関して：理想的なビジネスプロセス名はあいまいさがなく、ビジネス上親しみがもて、一貫して使用される。

• ビジネスプロセスはただ一つの名前を持つべきである。
• ビジネスプロセス名はアクションを反映する能動態で記述するべきであり受動態で記述するべきではない。
• ビジネスプロセス名は、そのビジネスプロセスの意図するビジネス結果を明確に表現するべきである。
• ビジネスプロセス名は、内外のビジネス・ステークホルダーによって明白に一貫して理解されなければならない。
• すべてのビジネスプロセス名とすべての分割レベルにおけるアクティビティ名の記述は、ただ一つだけの命名方法を使用するべきである。
• ビジネスプロセス名は、どこでそれが実行されるのか、誰が何を使って実行するのか、またはどのように実行するのかを記述するべきではない。

【解説】
プロセス名の付け方の注意事項です。最初の項は明確です。同じプロセスで複数の名前を持つべきではありません。

2項目はうっかりすると間違えますので注意しましょう。動詞または動詞句を用い、受動態ではなく能動態で記述します。そういえば、ビジネスアナリシスの知識体系BABOK（R）も、すべてのタスク名はアクションを示す動詞で記述されています。また、プロジェクトマネジメントのPMBOK（R）も原文（英語版）は全てのプロセス名が動詞表現です。ただ、PMBOKの日本語訳はなぜか、名詞句（体言止め）になっています。

3項目はさらに一歩踏み込んで、ビジネス結果（アウトプット）まで表現することを推奨しています。例えば、「新製品を開発する」プロセスのビジネス結果は「新製品」ですね。このプロセスのアウトプット、すなわちビジネス結果が明確です。BABOK（R）の多くのタスクも同様です。「ビジネスニーズを定義する」タスクのアウトプットは「ビジネスニーズ」。という具合です。

4項目、は問題ないと思います。

5項目は命名法ですが、複数の命名法を用いると誤解されやすくなるので避けましょう。

最後の項ですが、プロセス名には場所、人、モノ、実行方法（人的作業、IT）を入れるべきではありません。プロセスを記述したのちに、どこで、誰が何を使って実行するのか、また人的作業で実行するのか、ITで自動化するのかを決めるのです。それにはいくつかのトレードオフや予算もあり、十分な吟味が必要です。

プロセスを見える化することと、

モデルに関して：ビジネスプロセス・モデルは多角的な視点（パースペクティブ）、表記法（ノーテーション）、図（ダイアグラム）を可能にする。

• ビジネスプロセス・モデルは、ビジネスプロセスとその環境について記述するのに必要なすべての情報を含む。
• ビジネスプロセス図は、特定のコミュニティーによって要求されるビジネスプロセス・モデル上の視点（パースペクティブ）を提供する。
• 表記法は、そのビジネスプロセス・モデル上の特定の視点を表現し、伝えるために使用する構築物のセットである。表記法はビジネスプロセス・モデルではない。
• モデルの特定の側面と対話したり実行する個人は、自分の目的に適している表記法で図（ダイアグラム）を見ることができるべきである。
• ビジネスプロセスおよび任意の分割レベルにおけるその構成要素のアクティビティは、すべて共通のテンプレートを使用して記述されるべきである。

【解説】
いかなるビジネスプロセスも外部環境と内部環境があります。それが記述できなければいけません。そして、同じビジネスプロセスでも、視点（パースペクティブ）の異なる複数の表記方法があります。どの表記方法を用いるかは求める視点を最適に表現できる表記方法を使えばよいのです。バリューチェーンを表現するのに、箱（アクティビティ）と矢印（フロー）を用いたプロセスのフローモデルを使っても構いません。また、プロセスのライフサイクルモデル（例えばバリューストリームマップ）を使っても構いません。自分たちに都合の良い視点（パースペクティブ）を表現してくれるモデルを使います。そして、第4項目にあるように、プロセスを実行する個人は自分の目的に適している表記方法で図（ダイアグラム）が見れて、そのプロセスを改善できることが重要です。

[図をクリックで拡大表示]

最後の項では、ビジネスプロセスを下位に分割したときのアクティビティは上位プロセスを表現するテンプレートと同じものを使うことを推奨しています。つまり、上位プロセスがBPMNで記述してあれば、下位のアクティビティもBPMNにしましょう。上位プロセスがDFDなら下位プロセスもDFDで、ということです。

ユニークさに関して：ビジネスプロセスは、他の組織資産を利用するユニークな組織資産である。

• 組織の他の資産にはビジネスプロセスとは異なる特性がある。
• ビジネス・イベントはビジネスプロセスとそのアクティビティを開始する、または終了する。
• ビジネスポリシーとビジネスルールはビジネスプロセスを制御する。
• 人材、テクノロジーおよび物的資産は、ビジネスプロセスの実行を可能にする。
• 組織は複数のビジネスプロセスのセットを持つべきではない。組織の中のプロセス・モデルはすべて単一のビジネスプロセスのセットに統合されるべきである。

【解説】
他の組織資産として、ビジネスイベント、ビジネスポリシーとルール、人材/テクノロジー/物がありますが、ビジネスプロセスはそれらを活用するという意味でユニークな組織資産という事です。

前項の視点を見てください。イベント、ルールは視点でもありました。イベントモデルとしてイベントをモデル化したものが一つの組織資産です。同様に組織のビジネスポリシーとルールを体系化したものを総合ルールブックマネジメントと言い、これも立派な組織資産です（ただ日本では総合ルールブックマネジメントを徹底している組織はまだわずかなようです）。
ビジネスプロセスの実行を可能にするのは人的資産やIT資産です（リソースに関して、を参照ください）。
このように、ビジネスプロセスはそれ自体が組織資産ですが、その中で他の組織資産も活用し、かつ実行を可能にするのも他の組織資産（人材、IT）という、ユニークな点に注目してください。

先週は、ビジネスプロセス・マニフェストの日本語版の完成に時間をとられ、説明に十分時間を使えませんでした。今週は解説の前に、日本語化に至った経緯について少し触れたいと思います。

2013年11月にラスベガスで開催されたBBC2013カンフェランスに参加したのがきっかけです。このカンファレンスはビジネスアナリシスの国際団体であるIIBAと、ビジネスプロセスをグローバルにリードしているBPTrends、そしてビジネスルールを主導するBusiness Rule Solutionsの3者が共催する世界最大規模のビジネスアナリシス/プロセス/ルールのカンファレンスです。

弊社はビジネスアナリシスの教育・コンサルティングの専門会社なので、当然ビジネスアナリシスの最新動向そして、最近台頭しているビジネスルールの知識習得を目的に参加していました。ビジネスプロセス（BPM）は日本でもお馴染みなので、ラスベガスでなくても日本で十分に情報は得られる（得ている）と思っていました。
またBPMNでモデル化しソフトウェアで自動化しても経営/ビジネスへの効果が十分に得られないため、残念ながら日本でBPMの普及が十分でないことを把握していましたので、正直関心の程度はあまり高くありませんでした。

しかし、BPTrendsのロジャー・バートンのキーノートスピーチは筆者のBPMの認識を一変してくれました。日本のBPMとは本質的に異なるやり方で、「組織・戦略」～「ビジネスプロセス」～「実装（ITと人材）」の3層構造ですべてを上から下までリンクするというものです。それはBABOKでいう要求の分類「ビジネス要求」～「ステークホルダー要求」～「ソリューション要求」に見事に対応します。さらにすべての要求を上から下までトレースする（「要求のトレーサビリティを管理する」）のと同等なことをビジネスプロセスのKPI/メジャーで実現しているのです。これが本場（本物）のBPMだったのです。日本でのBPMはソフトウェアでいう下流工程に重きが置かれているようで、実装の（プロセスをソフトウェアで自動化する）部分しか強調されていません。これでは上流工程の不備が指摘されているソフトウェア開発と同じことで、ビジネスへの貢献には程遠いものであることまで妙に納得できます。
（右の図はロジャー・バートンのプレゼンスライドの一部です。3層構造をご覧ください。画像クリックで拡大表示。）

ロジャー・バートンに接触すると、ビジネスプロセス・マニフェストの存在を教えてくれ、なんと10か国語以上の翻訳までできているといいます。内容を見ると彼のキーノートスピーチの内容に沿った、本物のビジネスプロセスの基本中の基本がマニフェストとしてまとまっています。これはまず、日本語化し、日本のビジネスアナリシスやビジネスプロセスを扱っている人々に周知させる価値が十分にあると思い、正式に日本語化の許可を得ることになった次第です。事務的手続きが終了し、正式に許可を得ましたのでこのたび日本語版を発行できることになりました。

ビジネスプロセス・マニフェスト日本語版のダウンロード　→　　こちらから　または右図をクリック

尚、この日本語版は近々BPTrends.comサイトにも掲載される予定です。

それでは、先週の続きを解説しますが、原則の前に、このマニフェストで取り扱う範囲、スコープです。本来なら、先週原則を始める前に解説するべきものでした。

ビジネスプロセス・マニフェストのスコープ

スコープ内：

• ビジネスプロセスに関連する原則と定義。
• ビジネスプロセスのビジネスモチベーション。
• 何がビジネスプロセスなのか、また何がそうでないのか。
• ビジネスプロセスと他の関連する分野との関係。

スコープ外：

• 特定のビジネスプロセス・モデリング表記法。
• 特定のビジネスプロセス・メソドロジーおよびテクニック。
• ビジネスプロセス・モデリングまたは実行用の特定テクニック。
• ビジネスプロセスのマネジメントおよびガバナンス用の特定の組織的役割および責任。
• 他の当該分野に関する原則。ただしそれらがビジネスプロセスと相互作用する場合、もしくは関連付けられる場合を除く。

【解説】
スコープ内は特に問題ないと思います。全て、このマニフェストの中で記述してあることです。

スコープ外は少しご注意ください。
マニフェストですから、具体的なモデリングの表記法、例えばBPMNやUMLは扱いません。また、特定のメソドロジーやテクニック、またモデリングそのものとその中で扱うテクニックも対象としていません。ただし重要なことは、ビジネスプロセスをモデル化するためには、メソドロジーやテクニック、表記法、すべてが必要です。
4項目の「特定の組織的役割および責任」も同様です。BPMを促進するための特定の組織はマニフェストの対象ではありませんが、ビジネスプロセスをマネジメントするためには、企業横断的に取りまとめるための組織（BPMグループとかBPMセンターオブエクセランスなど、組織の名称にはこだわりません）が必要不可欠です。

この辺りの事情はビジネスアナリシスの知識体系BABOKやプロジェクトマネジメントの知識体系PMBOKでも共通です。BABOKではビジネスアナリシスの特定のメソドロジーは扱いませんが、ビジネスアナリシスを実践するためには特定のメソドロジーやテンプレートを組織のプロセス資産として持っている必要があります。また、プロジェクトマネジメントを促進するためには特定の組織として、例えばPMO（プロジェクトマネジメントオフィス）の存在が不可欠です。

続いて、原則の続きです。

原則（続き）

リソースに関して：ビジネスプロセスは、様々な組織あるいは組織単位の中のリソースの組み合わせによって行われる。

• あるビジネスプロセスは、業務の人的側面を実行できる人材によって行なわれるべきである。
• あるビジネスプロセスは、業務の技術的側面の実行が可能なITリソースによって行なわれるべきである。
• あるビジネスプロセスは、業務の物理的側面を支援する器材を備えた施設によって行なわれるべきである。
• ビジネスプロセスの実行に関与するすべての人材は、業務の最適なパフォーマンスを達成するのに必要な実用知識にアクセスするべきである。
• ビジネスプロセスの実行に要するすべてのリソースは、明確に役割と責任を定義されるべきである。

【解説】
ビジネスプロセスはいくつかのリソースで実行されます。自動化されてIT(ソフトウェア)で実行されるプロセスもあれば、人手により実行されるものもあります。また製造業ではモノづくりは工場の設備（ロボットなど）で実行されます。また、それらの組み合わせでも実行されます。
IT（ソフトウェア）で実行されるものはあまり多くありません。前述の「厳密に構造化された繰り返し業務」のみです。「緩やかな構造で様々な形態をとる」非定型業務は、現在のBPMの大きな課題です。ラスベガスのBBCカンファレンスでは新しい潮流としてケースマネジメントのセッションがいくつかありました。今後の展開が楽しみな分野の一つです。
第4項目と第5項目では、プロセスを担当する人材のナレッジと職務記述について述べています。見落とされがちな人材能力ですが、このマニフェストはそこまで明確にしています。上図のロジャー・バートンのスライドの下位層（インプリメンテーションレベル）の左側の部分です。

コンテキストに関して：ビジネスプロセスは定義されたビジネス・コンテキスト内に存在する。

• ビジネスプロセスは明白に境界のある組織あるいは組織グループの中に定義されるべきである。
• ビジネスプロセスは、外部の顧客とステイクホルダー、また組織内の他のビジネスプロセスから入力を受け取り、それらに出力を提供する。
• ビジネスプロセスは、一つ以上のイベントが開始のトリガーをかけた時、スタートする。
• ビジネスプロセスは意図した結果が達成された時、あるいは意図した結果の達成を打ち切る決定がされた時、終了する。

【解説】
ビジネス・コンテキストはあまり聞きなれないかもしれませんが、最初の2つの項目を意味していると理解すればよいでしょう。対象とする組織とその業務がおかれている環境で、例えばある企業におけるサプライチェーン、ある保険会社の保険業務、ある銀行の銀行業務．．．

そして開始条件となるイベントによりスタートし、終了条件（意図した結果）で終了します。

モチベーションに関して：ビジネスプロセスのゴールと目標は、ビジネスの戦略的ゴールと目標を支援する。

• ビジネスプロセスは、組織のビジネスミッション、ビジョン、ゴール、パフォーマンス目標によって公式、非公式にかかわらず、ガイドされるべきである。
• ビジネスプロセスは組織の原則および価値観によってガイドされるべきである。
• ビジネスプロセスは、そのビジネス上の意思決定をガイドするために組織のビジネスポリシーおよびビジネスルールを使用するべきである。
• ビジネスプロセスに関連するすべての人材のインセンティブとモチベーションを有効に活用し、そのビジネスプロセスの期待する成果を強化するべきである。
• すべてのビジネスプロセスは、それらが運用される組織文化に支援されるべきである。

【解説】
極めて重要な原則です。

ビジネスプロセスのよりどころは、その組織のミッション、ビジョン、目標です。それらと整合しないビジネスプロセスは良い成果が生まれません。いかにビジネスプロセスを組織のビジネスミッション、ビジョンなどに整合させるかが最も重要なことです。価値観も同様です。

同じ業界で似たビジネス（例えば家電製品）を提供している組織でも、ビジョン、目標、価値観により、高性能・高価格な製品を提供する組織のビジネスプロセスと、中機能・低価格の製品を提供する組織のビジネスプロセスは同じとは限りません。顧客に提供する価値の違いによりビジネスプロセスも異なることになるでしょう。そして、前述のパフォーマンスインジケーターでビジネスのミッション、ビジョン、目標とトレースします。

ビジネスポリシーとビジネスルールも重要です。ビジネスポリシーはプロセスに指示を与えますが、直接アクションを導きません（のでルールと言わずポリシーと言います）。ビジネスルールは具体的アクションに結びつく指示です。例えば、ビジネスポリシーとして「販売価格を値引きする場合、適切な管理者の承認を必要とする。」はプロセスへの指示ですが、これだけでは誰に承認をもらえばよいかわかりません（アクションを導きません）。その下のビジネスルールで「5%未満の値引きは課長承認、5%～10%未満の値引きは部長承認、10%以上の値引きは部門長承認とする。」と決めるのです。これなら具体的アクション（承認をもらう相手）が決まります。プロセスは当然ながら、このような組織のポリシーとルールに従います（ポリシーとルールを使います）。細かい表現ですが、「ビジネスポリシーとビジネスルールを使用するべき」とあることも少し注意してください。ビジネスポリシーとビジネスルールは、ビジネスプロセスとは独立に定義しておく（定義してある）ものです。ビジネスプロセスの解説なので、これ以上深入りしませんが、ビジネスルールに関しては別の機会に解説したいと思います。

人材のインセンティブとモチベーションは、人材が実行するビジネスプロセスに大きな影響を与えます。ビジネスプロセスのパフォーマンスはそれを実行する人材次第です。プロセスを担当する人材のやる気、態度がビジネスの成功に影響します。これもロジャー・バートンのスライド（上図）の下位層の左側の部分です。

日本語訳に当たり：

昨年11月のラスベガスのBBCカンフェランスで知った、ビジネスプロセス・マニフェストです。発行元の BPTRends, LLC から正式な翻訳権を得ましたので、マニフェストの日本語訳とその解説を連載でお届けします。BPMの本場、北米でのビジネスプロセスの考え方がよくわかります。

日本でのBPMの扱い方は、BPMN（ビジネスプロセス・モデリング表記法）からソフトウェアを自動作成することに重きが置かれているようです。いくら自動的にソフトウェアがプロセスを実行してくれても、ビジネスや経営に貢献するビジネスプロセスになっていないと効果が出ないばかりでなく、余計にコストがかかってしまうことになりかねません。はたして、どのように経営に貢献するビジネスプロセスを特定するのでしょうか。BPMNをいくら学習してもその解は得られないようです。

（画像をクリックするとマニフェスト日本語版がダウンロードできます）

本場のBPMはビジネス/経営に直結するビジネスプロセス変革/改革やプロセス再設計が中心です。ソフトウェアで実践することはずっと下流の工程です。このビジネスプロセス・マニフェストにより、本場のBPMに対する基本的な考え方を知ることができます。

それはまさにBABOKでいう、要求の階層構造（ビジネス要求、ステークホルダー要求、ソリューション要求）そのものです。「ビジネスアナリシスの扱うソリューションはITのみならずビジネスプロセス、．．．」というBABOK®のフレーズを思い出しながらお読みいただけると幸いです。

ビジネスプロセス・マニフェスト日本語訳全文

（クリック後15カ国語の中からJapaneseを選択してください）

以下、解説です。

ビジネスプロセスの運用上の定義

• 組織のビジネスプロセスは、顧客および他のステイクホルダーに価値ある結果の作成に関与するすべてのリソースによって行なわれる業務について明確に記述する

実は、辞書の上では、運用に耐えうるようなビジネスプロセスの定義はありません。マニフェストでは、上記のように定義しています。大変シンプルで平易な定義です。読者の皆さんにも違和感はないのではないでしょうか。

つづいて、このマニフェストでは下記のように8つの原則を掲げています。

 原則

• 業務に関して：ビジネスプロセスは組織の業務について記述する：
• 価値創造に関して：ビジネスプロセスは、そのビジネスプロセスの顧客および他のステイクホルダーの価値を創造する：
• リソースに関して：ビジネスプロセスは、様々な組織あるいは組織単位の中のリソースの組み合わせによって行われる。
•  コンテキストに関して：ビジネスプロセスは定義されたビジネス・コンテキスト内に存在する。
• モチベーションに関して：ビジネスプロセスのゴールと目標は、ビジネスの戦略的ゴールと目標を支援する。
• プロセス名に関して：理想的なビジネスプロセス名はあいまいさがなく、ビジネス上親しみがもて、一貫して使用される。
• モデルに関して：ビジネスプロセス・モデルは多角的な視点（パースペクティブ）、表記法（ノーテーション）、図（ダイアグラム）を可能にする。
• ユニークさに関して：ビジネスプロセスは、他の組織資産を利用するユニークな組織資産である。

それでは、各々の原則に関して解説を続けます。

業務に関して：ビジネスプロセスは組織の業務について記述する：

•  ビジネスプロセスの中で行なわれる業務は、物理的入力または情報入力を出力に変換する。
•  ビジネスプロセスはアクティビティのセットで構成される。各々のアクティビティもまたその下位のアクティビティのセットで構成される場合がある。
•  組織のビジネスプロセスの完全なセットは、その組織によって行われるすべての業務について記述する。
•  ビジネスプロセスは、厳密に構造化された繰り返し業務で構成される場合と、緩やかな構造で様々な形態をとる場合がある。

【解説】
最初の項目は特に問題ないと思います。入力（インプット）を何らかの出力（アウトプット）に変換するのがビジネスプロセスですから。

2番目の「各々のアクティビティもまたその下位のアクティビティのセットで構成される」がポイントです。要するにビジネスプロセスは階層構造を持つことを明確に謳っています。単なる業務フローだけを言うのではありません。

3番目も特に異論はないと思います。

4番目の前半の「厳密に構造化された繰り返し業務」が通常のプロセスです。あえて言えば定常業務を表しています。ウォーターフォール型の業務と言っても差し支えありません。後半の「緩やかな構造で様々な形態をとる」業務は非定型な業務です。例えば営業の業務は緩やかな構造で、相手（顧客）により同じアクティビティ（例えば訪問）を何度も繰り返す場合もあれば、スキップ（訪問せずにメールだけですま）して次のアクティビティ（例えば見積もり）に移行したりします。また、マネジメントの意思決定のプロセスも大まかな手順はあるかもしれませんが、特に決まっているわけではありません。アジャイル型のソフトウェア開発も緩やかな構造と言えるでしょう。などなど、その形態は様々です。そのどちらもビジネスプロセスとして扱います。

のっけからいきなり、ビジネスプロセスの本質に迫ってきていますね。

価値創造に関して：ビジネスプロセスは、そのビジネスプロセスの顧客および他のステークホルダーの価値を創造する：

• ビジネスプロセスは、顧客および他のステイクホルダーの具体的なニーズおよび期待を満たす成果を出し、測定可能な価値を創造するべきである。
• ビジネスプロセスによって生成される価値は、一つ以上のパフォーマンス・インジケーターによって測定されるべきである。
• ビジネスプロセス内のすべてのアクティビティのパフォーマンス・インジケーターは、その上位のビジネスプロセスのパフォーマンス・インジケーターにトレースされなければいけない。
• ビジネスプロセスのパフォーマンスは、有効性を評価し、かつ改良の機会を識別するためにそのビジネスプロセスのライフサイクル全般にわたり定期的に測定されるべきである。
• ビジネスプロセスのパフォーマンス・インジケーターはそのビジネスプロセスが運用されるすべての場所において経時的に、かつ場所横断的に測定され比較されるべきである。

【解説】
最初の項目と2番目の項目で、ビジネスプロセスが生成する具体的な価値を、パフォーマンス・インジケーターによって測定することを明確にしています。さらに、3番目の項目では、そのインジケーターが上から下までトレースされなければいけないと言っています。これはBABOKのトレーサビリティに対応するものですが、組織の全レベルのビジネスプロセスのパフォーマンスを最上位階層のビジネスプロセスのパフォーマンスに整合させることを意味します。これにより、最上位階層のパフォーマンスを改善/改革するために、どのレベルのどのビジネスプロセスが影響するのかがわかるようになります。

さらに4番目と5番目の項目では、パフォーマンスをビジネスプロセスのライフサイクル全般に定期的に測定し、かつロケーションごとに測定し、比較し、改善ポイント（ロケーションによる違い、時間的なパフォーマンスの違い、など）を見つけて、PDCAを回すことを主張しています。単に自分の担当するプロセスを改善するのではありません、最上位階層のパフォーマンス（それが経営数字に直結します）を改善/改革するためのPDCAです。

ビジネスプロセスをここまで厳密に測定している組織が日本にどれだけあるのでしょうか。また、日本のBPMよりはるかにレベルが高いと思います。

ビジネスプロセス・マニフェストがこれだけ高尚なレベルの内容なことに、感銘を受けるのは筆者のみではないと思います。

次回は引き続き、原則の解説です。「リソースに関して」、「コンテキストに関して」、「モチベーションに関して」を解説します。