事例研究：BPMNワーキンググループの電子メール投票プロセスの最適化　文脈と課題 - Go TOGAF Japanese

BPMN（ビジネスプロセスモデルと表記）ワーキンググループは、BPMN標準の継続的な保守および進化を担当している。このグループの重要な機能の一つは、提案された変更事項について投票することである。明確化、および新機能である。ワーキンググループのメンバーが世界中に分散していることと、提案の複雑さを考慮すると、投票プロセスは一度の同期会議で行うことはできない。同期会議では行えない。

歴史的に、グループは、臨時の電子メール投票プロセスに依存していた。しかし、このプロセスはいくつかの重大な問題を抱えていた：

参加率の低さ： しばしば、候補者が投票の電子メール通知を逃したり、議論に参加しなかったため、定足数に達しなかった。
合意形成の欠如： 複雑な問題はしばしば最初のラウンドで明確な過半数を得られず、無限に続く電子メールスレッドが発生した。
プロセスの停滞： 合意形成または参加が失敗した場合、プロセスが停止することがあり、ワーキンググループの議長による手動介入が必要となり、議論を再開または再設定しなければならなかった。
不明確さ： 低参加率について誰が警告されたのか、あるいは特定の決定が最終的に採択された理由が明確な監査記録として残っていなかった。

これらの課題に対処するために、ワーキンググループは、BPMN 2を用いて電子メール投票プロセスを形式化・標準化することを決定した。0. 目的は、これらの複雑な状況に対応できる、透明性があり、効率的なモデルを構築することであった。應任者による継続的な手動監視を必要とせずに、複数当事者間のシナリオに対応する。

BPMNソリューション

結果として得られるプロセスは、図（image_3.png）に可視化されており、複雑な協働モデルであり、問題リスト管理者（プロセス管理者）と作業グループメンバー（投票者）の責任を明確に分離している。このモデルは、問題のライフサイクル全体を処理するように構成されており、問題の特定から最終合意までをカバーする。特定の、プロセスの一般的な障害を処理するための自動化された保護機構（ループ）を備えている。

詳細なプロセス分析

プロセスは開始イベントによって開始される：問題が特定された。フローはその後、4つの主要フェーズに構成される。これらは図中の番号付きループに対応する。

フェーズ1：議論サイクル（サブプロセス）
- 役割： 問題リスト管理者。
- 活動： 管理者は、電子メールのスレッドを調整し、会議を実施することで議論を開始する。複雑なトピックでは単純な賛否投票では不十分なため、これが重要である。
- ループメカニズム： このサブプロセスの終了時に、管理者は「議論の進捗を評価する（問題リスト管理者）」というタスクを実行する。このタスクは変数DiscussionOver == TRUE または FALSE.
- レジリエンス： 議論が未完了と判断されたり、新たな問題が提起された場合、プロセスは「メール議論の調整」活動の最初に戻る。これにより、問題が成熟する前に投票へと急いでしまうことを防ぐ。
フェーズ2：参加警告ループ
- 役割： 問題リスト管理者およびワーキンググループメンバー。
- 活動： 議論が終了したら、管理者は「投票対象の問題を発表する」というタスクを実行することで、投票を開始する。
- ループメカニズム： プロセスはメンバーの投票を待つ。重要なステップはゲートウェイ「十分なメンバーが投票したか？」である。 (>= 86%)”. 信頼できる結果を確保するために、高い定数（86％）が必要である。
- レジリエンス（警告システム）： 定数が達成されない場合（「いいえ」の場合）、プロセスは特定の例外経路に従う。
  - 投票していないメンバーには「参加状況の警告を確認する」タスクが割り当てられる。
  - 同時に、管理者のプールは「参加状況の警告を確認する」タスクを発動し、透明性を確保する。
  - このフローは「投票対象の問題を発表する」タスクに戻る。重要なのは、このループは一度だけ発生可能である. メンバーのプールには「再検討の承認」タスクが表示されます。その後、ゲートウェイが続きます。これにより、メンバーが警告を受けた後も投票を行わなかった場合に、警告を受けた後警告を受けた後次のサイクルではそのメンバーの投票が棄権として記録されます。警告の無限ループを防ぎます。このループは責任を問うための重要な機能です。
フェーズ3：複数ラウンド投票ループ
- 役割： 問題リスト管理者およびワーキンググループメンバー。
- 活動： 候補者が定数に達した場合、投票は「投票収集サブプロセス」内で集計されます。
- ループメカニズム： 集計後、ゲートウェイ「過半数を獲得していない問題？」が、提案が必要な支持を得たかどうかを確認します。ゲートウェイ「過半数を獲得していない問題？」が、提案が必要な支持を得たかどうかを確認します。
- リジリエンス（選択の精錬）： 問題が過半数を獲得していない場合、プロセスは精錬ループに入ります。管理者のプールには「精錬された選択肢を分析する」タスクが表示され（通常、初期投票のフィードバックに基づいて）、メンバーには「修正された投票を提出する」ことが求められます。これにより、グループは選択肢を絞り込むことができます（例：5つの選択肢から上位2つに絞る）例： 5つの選択肢から上位2つに絞り、再投票する）問題を単に失敗させるのではなく、このループは、議論全体を再開せずに、複雑な好みの問題を解決することを目的としています。
フェーズ4：議論サイクルの再開
- 役割：問題リスト管理者。
- 活動： これは、譲れない問題に対する最終的な例外パスです。
- ループメカニズム： 「複数ラウンド投票ループ」が終了した後、ゲートウェイ「2ラウンドの投票で失敗したか？」は、2回の完全な投票ラウンドの後に合意に至らなかったかを確認します。
- リジリエンス（完全リセット）： 答えが「はい」の場合、プロセスフローがリセットされます、終了されるのではなく。メッセージフローにより、このゲートウェイは「1.」の開始部分に戻されます。議論サイクル」サブプロセス。これにより、グループは再び原点に戻り、問題を再定義し、新しい文脈で議論フェーズを完全に再開します。これにより、プロセスが「未解決」状態で終了するのを防ぎ、明確な、スケーリングのための文書化された経路を提供します。

BPMN電子メール投票プロセスの詳細な説明

提供されたBPMN図は、BPMNワーキンググループ内の問題を解決するために設計された構造的で協働的なワークフローを表しています。このモデルは、2つの主要な参加者、すなわち「プール」間の協働として定義されています：問題リストマネージャ および ワーキンググループメンバー.

プロセスフローは、グループが合意に至るか、参加に関する問題を効果的に管理できるようにする、4つの明確で複雑なループによって制御されています。

1. 議論サイクル内部ループ

プロセスは「議論サイクル」サブプロセスから始まり、これは新しい問題を管理するための主な活動です。

メカニズム：このサブプロセス内では、問題リストマネージャが「議論の進捗を評価する」タスクを実行します。
ロジック：このタスクは、議論終了変数をTRUEまたはFALSEのいずれかに設定する。
ループアクション: 変数がFALSEに設定されている場合、サブプロセスがループを発動し、電子メールのモデレートと会議電話の全サイクルを繰り返す必要があり、議論が完了したと見なされるまで続ける。

2. 参加警告ループ

このループは、投票フェーズの終盤に投票率が低くなることを防ぐための安全装置として機能する。

メカニズム: プロセスは、「十分なメンバーが投票したか？」という判断ポイントに達する。承認には、投票メンバーの2/3以上の過半数が必要である。
ループアクション: 応答が「いいえ」の場合、システムはメンバーがすでに警告を受けたかどうかを確認する。まだ警告を受けていない場合、プロセスは「投票用問題の発表」タスクに戻り、警告を添付した第二の投票サイクルを開始する。

3. 複数ラウンド投票ループ

最初の投票で過半数に達しなかった場合、このループはメンバーが選択できる選択肢を洗練する仕組みを提供する。

メカニズム: 初回投票後に「過半数に達しない問題があるか？」という状況が発生した場合、サブプロセスが実行され、可能な解決策を最も人気のある2つの選択肢に絞り込む。
ループアクション: 投票者は、洗練された選択肢に基づいて投票を変更するよう求められ、プロセスは「投票を集計」サブプロセスに戻り、より焦点を絞った第二のラウンドに移行する。

4. 議論サイクルの再開

これは、複数回の試行の後でも投票プロセスが解決策を生み出せない場合に用いる最終的かつ究極のループである。

メカニズム: 複数ラウンド投票ループがすべて使い果たされても成功した合意が得られなかった場合、プロセスは2回の失敗した投票サイクルが発生したかどうかを確認する。
ループアクション: 終了するのではなく、プロセスは完全にリセットされ、初期の「議論サイクル」サブプロセスに戻り、議論フェーズを再開する。

使用された主要なBPMNコンセプトの概要

コラボレーションプール: 図は、責任を次の間で分離している。問題リスト管理者（プロセスを調整する者）と、作業グループメンバー（議論や投票に参加する者）。
同期：このモデルは、タイマー、メールの承認、会議など、並行するパス間の活動を同期するために、これらの4つのループを使用しており、管理者が問題の状態を明確に把握できるようにしています。
回復力：これらのループを使用することで、合意が得にくい、または参加が不十分な「異常な」ビジネス状況に対処でき、プロセスが未完了の状態で停止するのを防ぎます。

結論

BPMNを用いたこのプロセスの形式化により、BPMNワーキンググループの運用が大きく変化しました。モデルは、明確な役割を備え、明確なメッセージフローを備え、 4つの明確な例外ループを備え、グローバルな協働のための堅固なフレームワークを提供しています。

これらのループをプロセス定義に直接埋め込むことで、グループは以下の成果を達成しました：

参加の増加：自動警告ループにより、定足数を逃すことはほとんどありません。
より高品質な意思決定：複数ラウンド投票ループにより、複雑な、複数選択肢のある問題の解決が可能になります。
効率性：プロセスはもはや停止しなくなりました。合意に進むか、自動的に以前の、より適切な段階（たとえば議論）に戻ります。
透明性と監査可能性： すべての行動、警告の送信からサイクルのリセットまで、すべてが形式的なプロセスモデルの一部であり、すべての意思決定に対して明確な監査証跡を提供しています。

この事例研究は、BPMNが運用ワークフローのモデリングにとどまらず、複雑な、合意に基づく協働活動の構造化と管理にも使用できることを示しています。合意に基づく協働活動の構造化と管理にも使用できることを示しています。