BPMNはプロセスを記録する。
memodyaはプロセスを動かす。
BPMNの図は、ハンドブックや監査のために一度描かれ、やがて古くなります。memodyaは同じ業務を、実際の入力、出力、ツール、人を持つメソッドとしてモデル化し、チームはそのモデルの中で毎日仕事をします。
並べて比較
同じプロセス。 2つのモデル。
アーキテクチャ定義の同じ4ステップを、BPMN 2.0で描いた場合とmemodyaでモデル化した場合。
BPMN 2.0で作図
- 1 ドキュメントは、レーンやフローをまたぐ点線にぶら下がっているだけ。誰もチェックしません。
- 2 ロールはスイムレーンになります。Clemensはアーキテクト兼レビュアーなので、彼のタスクは2回描かれます。
- 3 BPMNにはツールを表す記号がありません。結局、自由記述のメモに書かれます。
- 4 監査のために描かれ、最後に開いたのは数か月前。もう古くなっています。
memodyaでモデル化1234
要件の収集
要件エンジニア 定義
完了第38週
アーキテクチャ草案
アーキテクト 設計
完了第41週
アーキテクチャレビュー
レビュアー 検証
進行中62%
IF仕様の公開
アーキテクト リリース
予定第44週
要件
ストーリー
アーキテクチャ
承認済み アーキテクチャ
指摘事項
IF仕様
Jira
Draw.io
Modeler
ModDoc
Confluence
Anna
Stefan
Clemens
Clemens
レビュアー
Stefan
- 1 各メソッドの出力が次のメソッドの入力に。要件が変われば「アーキテクチャ草案」にも伝わります。
- 2 Clemensは担当する両方のメソッドに割り当てられます。レーンも重複もありません。
- 3 ツールは、それを使うメソッドに配置されます。
- 4 各メソッドにリアルタイムのステータスとスケジュールを表示。チームが毎日使います。
詳細
エンジニアリングチームにとって BPMNが行き詰まる理由。
1. 入力と出力
BPMN
緩いデータ関連付け
データオブジェクトは任意の点線で関連付けられるだけです。タスクがどのバージョンの要件を使ったのか、要件が変わるとどのステップが影響を受けるのかは示されません。
memodya
宣言され、接続された依存関係
すべてのメソッドが入力と出力を宣言します。接続は実際の依存関係なので、要件が変更されると、影響を受ける下流のメソッドがすべて表示されます。
2. ロール
BPMN
スイムレーンが人を押し出す
各タスクはちょうど1つのレーンに配置されます。実際の協働ではフローがレーン間をジグザグに行き来したりタスクが重複したりし、組織変更のたびに図を描き直す必要があります。
memodya
人はレーンではなく、仕事に紐づく
人、ロール、AIエージェントはメソッドそのものに割り当てられます。1つのステップに複数の担当者を置くことができ、チームが変わってもレイアウトは変わりません。
3. ツール
BPMN
数百の記号、ツール用はゼロ
BPMN 2.0には膨大な記号がありますが、CAD、シミュレーション、テストベンチ、エンジニアが実際に使うモデリングツールを表す記号はありません。
memodya
5つの構成要素
メソッド、入力、出力、ツール、ロール。表記法のトレーニングなしで、チームの誰もがモデルを読み、編集できます。
4. 文書化か、日常利用か
BPMN
プロセスの「絵」
BPMNモデルは、ハンドブック、プロセスポータル、監査のために作られます。業務中に開かれることはほとんどないため、チームの実際の働き方からずれていきます。
memodya
モデルがそのままワークスペースに
ステータス、スケジュール、担当者は各メソッドに紐づいています。チームはモデルの中で仕事を計画・追跡するので、使われ続ける限り最新の状態が保たれます。
選び方
適材適所の ツール選び。
BPMNが今も適している場面
ワークフローエンジンが図を実行する場合や、購買承認やオンボーディングのような安定した定型業務には、BPMNは確かな標準です。プロセスがほとんど変わらず、機械が実行するならBPMNを使い続けましょう。エンジニアが実行し、数週間ごとに変わるプロセスなら、memodyaでモデル化しましょう。
- ワークフローエンジンが図を実行する
- 購買承認やオンボーディングのような安定した定型業務
- 監査人や契約でBPMN 2.0が求められている
memodyaがより適している場面
エンジンではなく人が仕事をし、プロセスが変わり続ける場合です。memodyaはモデルと日々の業務を1か所にまとめるため、チームが使うことで地図が常に正確に保たれます。
- 数週間ごとに変わるエンジニアリングや研究開発の業務
- 人、ロール、AIエージェントなど、複数の担当者が関わるステップ
- ステップの依存先や、変更による影響範囲を把握したい
- チームがモデルを文書化するだけでなく、その中で仕事を計画・追跡する