ワークフローサンプル: 未解決の製品不具合は何件？がいつでも分かるワークフロー

パッケージソフトウェアの制作やウェブサイトの制作は「完成したら終わり」と言うものではない。むしろ『変更要望』と言う更新業務に追われる日々が「始まる」と言った方が良い。時には「不具合」も報告されるだろう。

以下の業務フロー図は、「不具合報告」や「要望」のステータス管理を効率よく行う事を主眼に置いた設計だ。（※ 社員が全員、ワークフローのアカウントを持つケース）

＜各タスク名＞
1.不具合要望登録、2.回答者指名／優先度設定、3.一次回答、3a. 疑問対応、4.最終回答、5.一次回答確認、6.最終回答確認

[不具合＆要望の受付から回答「2.回答者指名／優先度設定」]

＜各プロセスデータ名＞

件名(text)＜≪不具合要望概要≫＞

▼不具合要望情報▼

選択型：不具合or要望(不具合/要望)
選択型：対応優先度(1/2/3/4/5)
日付型：事象発見日
文字型：不具合要望詳細

▼回答担当および予定▼

選択型：該当範囲(Webアプリ/ミドルウェア/インフラ/その他)
ユーザ型：回答担当者
日付型：一次回答期限
日付型：最終回答予定日

▼フロー制御▼

選択型：回答フラグ(一次回答をする/一次回答前に確認したい事あり)
選択型：ノイズフラグ(OK/ノイズ)

▼コミュニケーション記録▼

文字型：一次回答
文字型：最終回答
掲示板型：通信
数値型：不具合要望登録の貢献度(0-100)

この手のワークフローでは『全プロセス実績』が頻繁に検索される。特に、管理職者は「最終回答予定日を過ぎて、まだ回答されていない登録はナンダ？」、「インフラ領域における改善テーマは何？」などの視点でプロセスを列挙するだろう。社内SNS機能を使って「どうなってんだ、このプロセス？」と催促する様子も、想像に易い。そして、開発チームの各メンバは『マイタスク』にある「自分が回答しなければならない不具合要望」を減らす事に邁進する。

しかし本当に評価すべきは「ナイスな報告」をした人だ。

登録文の読みやすい
致命的な不具合を発見した
誰も気が付かないアイデアを出した

などの「成果」は人事評価においても加味されるべきだ。そのまま考課に使えるかどうかはさておき、タスク『4.最終回答』にて「不具合要望登録の貢献度」を入力させるルールで、このワークフロー運用を開始することを検討したい。「登録文の読み易さ・発見困難度・アイデア度を元に、0～100で評価して下さい」などの備考文をつけておくと尚良いだろう。

＜類似プロセス＞