ワークフローサンプル: 企画１に対し回答がＮ集まる「社内アンケート」のデータ構造

前回に引き続き「社内アンケート業務」とよばれる業務について考えたい。前回は、最大８人に対して「任意のアンケート」を実施できる汎用ワークフローについて考察した。ポイントは、

８人分のスイムレーンを用意し、
８人分の回答データを格納できるように設計した

の２点だ。いつでも色々なアンケートを実施できる所はスバラシイ。

しかし、この方式のワークフローでは50人や100人に対するアンケートは現実的ではない。もちろん、

A. 100のスイムレーンを用意し(!!)、さらに
B. 100人分の回答データを格納できるように定義する(!?!)

と言う拡張を行うのも悪くはないのだが、、、やはり色々な意味でナンセンスだ。中でも特に問題視すべきは、データ集計を行うに「非常に使い勝手の悪いフォーマット」になってしまう点だ。集計という視点に立てば、「アンケート実施」の単位で記録されるのではなく、「アンケート回答」の単位で記録されるようにしたい。

以下の業務プロセス例は、まず「B.データ項目が発散する問題」を解決すべく、「アンケート準備」の業務プロセスと「アンケート回答」の業務プロセスの２つの業務プロセスに分けて定義した例だ。準備が１に対して回答がＮ、、、その「繰り返し単位」の違う業務プロセスをつなげる事で、それぞれ集計しやすいフォーマットになる。

[アンケート準備フロー]

[アンケート回答フロー（ユーザ指定開始）]

[アンケート回答フロー（ユーザ指定開始）：「1.回答する」画面]

この例は、「繰り返し単位」の違う業務プロセスを接続している。（１→Ｎ）

親プロセスモデル『アンケート準備フロー』から子プロセスモデル『アンケート回答フロー（ユーザ指定開始）』を呼び出す形だ。表現を変えれば、「親プロセスモデル」の各案件が「子プロセスモデル」が公開している API (※)に対してデータを送信し、子プロセスモデル上に新しい案件を複数生み出す仕組みだ。

※ プロセスプロセス毎に（プロセスモデル・ローカルに）公開できる API （モデル接続API）

注目すべき点は、処理担当者（ユーザ型データ）が受け渡しされ、誰が回答するか、が指名された形で「新しい案件」が立ち上げられる点と言えるだろう。（スイムレーンはユーザ型データを参照する方式で定義）

これらの仕組みを使えば、多様な社内アンケート（汎用的な社内アンケート）を気軽に実施する事ができる様になる。

＜データ項目一覧画面：アンケート準備フロー＞