ワークフローサンプル: 第572話：プロセス改善物語（Webメディア編２）

業務：校閲・校正

記事の校閲に「他のライター」も参加させる業務フローに変えた。（第571話：プロセス改善物語（Webメディア編１）、参照）

「誤字・脱字」や「名称まちがい・日付まちがい」といった『ミスの修正指摘』もさることながら、、、「起承転結についての意見」や「見出しやタイトルについての対案」といった『スキルアップにも通じるコメント』が、ライター同士で行われるようになった。

「編集者」は校閲やライター指導に費やしていた時間が減り、「新しい特集」について考えたり、「勉強会」を開催したりする時間が持てるようになった。

ちなみにその「勉強会」では、現実に発生した校正例が報告される。たとえば、「決済日」はお客さんが入金した日で「決裁日」は上司が判断した日ですねーとか、、、"過去" を償うことが「補償」で "未来" を約束することが「保証」で "砦" （障壁/障子）を築いて守り続けることが「保障」ですねー、国家や保険会社による安全保障・社会保障・生活保障といったケースでしか使われませんねー、、、といったディスカッションが行われている。地道なスキルアップこそ「生産性向上」だ。

課題：長時間の滞留

しかし「ライター」からすれば、他人記事の校閲という業務が増えたことよりも、差し戻し修正しなければならないタイミングも増えたことが問題だったりする。

特に新人ライターの場合、複数の記事が同時に『2x.記事修正』の工程に舞い戻ってくる、といったケースも発生してしまうようになった。そして、そういったケースには「他のライターが書いた記事を校閲する時間」が取れなくなるという事態になる。。。

うーむ、『3.一次校閲』には締切日時を設定し、その締切日時をもって強制的に次工程に進捗させる、、、つまり滞留を許さない、ようにした方が良いと思うに至った。

[記事の校閲フロー-打ち切り有り]

解決：打ち切り時刻の設定

業務フローの途中に「アウトプット品質を向上させる工程」を配置するケースは、よくある業務改善です。

この例における『校閲』というヒューマン工程も、(1)記事自体が修正改良される、という改善効果だけでなく、(2)校閲を通じて各ライターのスキルアップが図られる、といった効果があると言えます。

しかし、長時間滞留させてまで対処すべき、とは言えません。

つまり、もしその工程が「必須とまでは言えない」のであれば、締切期限をもって次工程に進捗させる仕組みを検討すべきかも知れません。（タイマー境界イベントによる打ち切り）

この例の『3.一次校閲』では、締切時刻は「この工程に到達してから18時間後」（このタスクが作成されてから18時間後）と設定されており、そのタイミングで作業が打ち切られる設定になっています。つまり、むやみに「マイタスク」が増えてしまう事態を避けています。

考察：締切時刻の自動設定

ヒューマン工程を

A. 「必ず実施されなければならない処理工程」と
B. 「実施されなくても構わないが実施された方が良い処理工程」

に大別し、後者Bについて打ち切り時刻を設定する手法は、大量滞留を回避する方法として有力です。

ただし、「一定時間経過」をルールとした場合に、たとえば「意図的に金曜日の夕方にB工程に流してB工程をスキップを目論む」といったケースが発生するようになれば、それは業務プロセスの設計趣旨に反するといえます。

そのような場合には、「打ち切り（締切）までの時間を長く設定する」、「勤務ルールに合わせた締切時刻の算出スクリプトを開発する」といった工夫が必要なのかも知れません。（M230 自動工程: 業務データの複雑なデータ加工が自動実行されるように設定する、参照）

※ もちろん「校閲者は、たとえ土日であってもスマホ経由で軽くチェックする」といった勤務ルールが許されるのであれば、シンプルに「到達後18時間」で構わないと言えます。

[記事の校閲フロー-打ち切り有り：「3.一次校閲」画面]