業務プロセスのデザインで使ったチャートが良かった話

業務を改善するときに思いつくのは、ユーザーストーリーマッピングやバリュー・ストリーム・マップを描いて、業務を設計したり、現行の業務を可視化することでボトルネックを洗い出して改善点を見つけるなどの方法を取ると思われる。

先だって、業務の根本的な見直しをしようと集まってそれに取り組んだ際に取ったアプローチは少し変わっている。そのアプローチも結果的にというか偶然そうなったのであるが、その場の出席者にはその進め方で良かったらしい。

最終的な業務イメージ
作業の成果として、最終的な業務フローは次のようなチャートを描くイメージ。作業の列に対応して、行の項目になんらかを記入する。

　　　[作業A]　[作業B]　[作業C]　[作業D]　…
input　　inputは、各作業で参照する定義されているもの。
who　　whoは、作業の主体者。組織の場合は主管部門。
what　　whatは、作業をする目的。
how　　howは、outputを作成する手続き。加工、導出、判断などの言葉を含む。
output　outputは、作業で加工（作業）した結果を格納するもの。帳票やDB的なものがあれば加工する項目の扱いを描く。

このチャートをいきなり描けることはない。作業Aなどの作業ごとに誰がどんな作業をしているかを洗い出し、その作業の必要性、つまり、コストを掛ける価値が見合っているかなどを揉んでいる。

そういう意味では、前述のチャートは最終的な取りまとめでしかないので、前段で作業Aなどの作業ごとに行の項目を事細かく、明らかにしておく。曖昧なままで放置してしまうと最終的なチャートが後になって崩れてしまう。それではこの作業をやっている意味がなくなってしまうので、その辺りはこういった場に入る前に潰しておく。

業務の見直しでは、新規、改善に関わらず、同じ作業を関係する人が繰り返し行っても、同じ結果を得られるように作業プロセスをデザインするのであるから、作業の中で作業者が考え込んだりするようなことがあってはいけない。

範囲を限定したり、区分を設けたり、種類を例示したりすることで自然と選択可能なものは制限され、適切な範囲で適合するものを選び、記録できなければならない。

そういうことができれば、チャートは何を使っても良いし、独自で作ってもいい。

そうした作業の結果は、新規業務や改善後の業務の素材であるから、この結果を文書などにつなげていくのである。これはエンジニアの開発プロセスでも同じである。