ワークフローサンプル: 第575話：プロセス改善物語（SaaSベンダー編２）

業務：デザイン制作

社内から次々と「依頼」が舞い込んでくるデザインチーム。
デザイン制作の「依頼フォーム」（ワークフローの開始工程）を整備したことで、以前より安定して依頼をこなせるようになってきた。（参照：「第574話：プロセス改善物語（SaaSベンダー編１）」）
自動開始イベント（メッセージ開始イベント）も用意したので、『デザイン依頼対応プロセス』が「サブプロセス」として利用されるケースも増えてきた。つまり販売部門や製造部門の業務プロセス図（メインプロセス）に「呼び出しイベント」と「待ち受けイベント」が配置かれ、業務プロセス間の連携が API POST 通信によって自動化されるようになった。（←要は「依頼案件タイトル」や「依頼仕事の作業詳細」といったデータでプロセスが開始され、作業完了と同時に「デザイン報告テキスト」と「成果物ファイル」といったデータが戻される）
さらに「サブプロセス」を呼び出すメインプロセスのサンプルも社内提示したので、今後、様々な部門におけるデザイン業務が『デザイン依頼対応プロセス』に集約されていくハズだ。

課題：スキルアップしない

デザイナごとに「担当案件の数」や「担当総額」が可視化されるようになった。また、ベテランデザイン達が「窓口担当者」として「作業担当者」の作業進捗をコントロールするようになったので、若手デザイナが「ノーチェック納品」（誰もチェックしない納品）してしまうことも無くなった。しかし、デザインは本来、「品質」こそが命だ。この業務プロセスのままでは、社内の満足度が下がっていくような気がする。もう少し、チーム全体として実力を伸ばしていけるような業務プロセスにならないものだろうか？　せっかく「デザイン依頼対応プロセス」として独立性を高めているのだから、単に数をこなすためだけの業務プロセスではなく、スキルアップにつながる仕組みを考えたい。

[デザイン依頼]

[デザイン依頼対応プロセス（レビューあり）]

解決：アンケート形式のレビュー

「デザインの良し悪し」は数値化できるものではありません。仮に、とあるデザインについてデザインチーム内で議論したとしても、三者三様の意見がでてくるでしょう。もし創作者自身が満足している部分について否定的なコメントが出れば、不毛な議論にも陥りかねません。ただ「創作者自身が不安に思っている部分」についてのコメントであれば、否定的な意見でも喜んで受けられるものです。この業務プロセスでは「デザイン担当者」が感じている『デザイン上の反省および不安』、、、たとえば「もう少し明るい色合いの方が良いかも知れない」といった不安について書き込み、同僚に対して『3b.デザインレビュー』を依頼することができる仕組みです。（「デザインレビューお願いしまーす」という声かけをすれば尚良）。依頼を受けた同僚は

そう思う
ややそう思う
あまり思わない
全く思わない
分からない

を選択します。

考察：スキルアップ環境

マーケティング部のデザイナ、製品開発部のデザイナ、営業部のデザイナ。「デザイナが各部に配属されるケース」と「デザインチームを独立させるケース」は、どちらが良いとは言い切れません。それぞれに一長一短があるでしょう。ただ仕事の進め方として、誰にも相談できない／誰にも相談しない、という状況は望むべくもありません。特にデザインアウトプットは、社内ソーシャル（社内SNS）で「いいね！」とクリックしてもらうだけでも、何かの会話につながるものです。特に「組織としてのスキルアップ」を志向するなら、同じスキルを持つ者同士が切磋琢磨できるような、そんな業務プロセス環境を模索し続けるべきだと言えるでしょう。

＜オペレーティング画面 : 3b デザインレビュー＞

＜データ項目一覧画面：デザイン依頼＞

＜データ項目一覧画面：デザイン依頼対応プロセス（レビューあり）＞

＜メインプロセス⇒サブプロセスにおける自動送信設定の例＞

key=${sub-process api key}
title=${デザイン依頼タイトル}
data[1].email=${デザイン依頼者} #ユーザ型
data[6].selects=${デザイン依頼の種類} #選択肢型：アイコン作成/イラスト作成/…
data[7].selects=${デザイン依頼予算} #選択肢型：0-5,000/5,000-10,000/10,000-50,000/…
data[8].input=${デザイン納品希望日} #日付型
data[9].input=${デザイン納品ファイル形式の指定} #文字列型
data[10].input=${デザイン依頼仕事の目的} #複数行文字列型
data[11].input=${デザイン依頼仕事の作業詳細} #複数行文字列型
data[12].upload: ${関連ファイル} #ファイル型
data[2].input=${受信中間イベントURL} #文字列型
data[3].input=$processInstanceId
data[4].input=${受信中間イベントKEY} #文字列型

※ デザイン報告を自動受信したい場合、「接続元プロセスの受信イベントURL」「接続元プロセスの案件ID」「接続元プロセス受信イベントのKey」は必須。その他のデータ項目は、必要な範囲で受け渡し。

＜サブプロセス⇒メインプロセスで自動送信されるデータ＞

key=${（接続元プロセス受信イベントのKey）} #main-process api key
processInstanceId=${（接続元プロセスの案件ID）}
q_reportText=${（デザイン報告）} #複数行文字列型
q_deliverableFile: ${成果物ファイル（接続元プロセスに返す成果物ファイル）} #ファイル型

※ メインプロセス側に、「デザイン報告」を格納する複数行文字列型データ（フィールド名：q_designreport）と「成果物ファイル」を格納するファイル型データ（フィールド名：q_designfiles）が必要。

※ メインプロセスへのデータ送信には、デフォルトのパラメータ書式（例：data[9].input）ではなく、カスタム書式（フィールド名。例：q_reportText）の使用を前提。

[雛形ダウンロード (無料)]