業務フローがスラスラ書ける魔法のカード「マジカ!」

マジカ!のダウンロードは"マジカランド"で検索!

滞留と締め切り効果

滞留という前振りを書いてから、間が開いてしまいました。正にこれが滞留の実例という気分ですw あれこれしてるうちにあっという間に年末になってしまいました。

さて、上記の一文は実は非常に示唆的です。業務の効率化をしようとしてフロー構造をいじっても実はさほど効果が望めなくて、では何故効果が望めないのかというとそれは滞留が発生しているからだ、というのが前回というか前々回の趣旨でした。前回というのは、この記事です。

  業務フローと滞留 - 業務フローがスラスラ書ける魔法のカード「マジカ!」
  http://magica.hatenablog.com/entry/2011/12/01/161528

どうして滞留が発生するのか。担当者が意図的に、悪意を持って、わざと遅らせようとしているのか、滞留を発生させているのか。決してそんなことはありません。業務改善の難しいところは、問題があったとして、それを意図的にやってる人はまずいないという点です。「結果として」そういう問題とすべき事態に「なってしまっている」というのが本当のところです。というわけで、罪を憎んで人を憎まず。まずは仕組みを疑うべきだと思うのです。

では何故滞留が発生するのか、というWhyを追求する前に、そもそも滞留とは何かということを考えてみたいのです。滞留があるからだ、とか言うと(前回言ったわけですが)もっともらしくてそれっぽくて、ともすれば納得と云う名の思考停止に陥りがちです。その罠にはまらないためにも、まずはWhatを考えてみます。

…と考え進めると、はて、滞留って何? となります。滞留の定義って何なのでしょうね。そこで、では逆に考えて、具体的に何がどうなれば「滞留していない」と言えるのかということに目を向けることにします。で、実はこれが甚だ曖昧なのです。

滞留というのは、滞っていつまでもそこに留まってる状態ですから、物事が進んでないということになります。前回の例でいうと本来は5分で終わるはずのことでも実際には凄く時間がかかってるような結果になる。ですが、じわじわと亀の歩みで仕事が進んでいるのかというと、実はそうではない。
つまり本当に止まってるわけです。では本当に止まっているのか。

実のところ、業務フローにおける滞留というのは、そもそも止まってすらいないと思われることが大半です。つまり「やってない」のです。言い換えると「着手していない」。やってないのだから、終わるわけがない。前工程が終わってないのですから、後工程が始まるはずもない。

この観点で業務フローを見ていくと、実は決定的な要素が欠けてるケースが殆んどであることがわかります。それは「締め切り不在」ということです。

大抵のケースでは「所要時間」は明記されていたりします。前回の例を再掲すると各工程に5分と書いてますが、これはそれぞれの所要時間を記載しているわけです。

  開始○→[5分]→[5分]→[5分]→○終了

ですが、これは「やれば5分で終わる」ということを示してるだけであって、開始すべき条件が整ってから開始するまでの時間を示すものではありません。つまり、前工程が終わって自工程を始められるようになったとしても、そこで3日くらい放置してそして慌てて5分で終わらせるということは十分にあるのです。そうすると結果として3日と5分が作業にかかった実績時間となります。

ここで冒頭の一文に戻ります。前回の更新から28日が経過しています。ではその間に私が毎日この記事を地道に書き続けていたのかというと決してそうではありません。「あー、もう随分と放置しちゃってるなぁ〜」と思って、慌てて一気に数10分で書き上げています。でもこれが仮にブログ更新業務という工程であれば、実際の経過時間は28日と数10分になってしまうわけです。

ではどうしてさっさと着手しないのか。何故、放置してしまうのか。その間遊んでるのかというと決してそうではありません。他のあれこれをやっていたりして、結構忙しいのが実際のところです。あ、ブログ更新がどうこうとか私が云々ではなくて、業務フローにまつわる全般的な話として、です。念のため。もとい、すぐに着手すれば5分で終わるのだからやればいいのです。そんなことは多分みんな承知してる。でも現実にはついつい放置してしまいがちです。何故そうなるのか。ここを追求しないでフロー構造だけをいじっても、本質的な問題の解決にはつながらないのです。

着手しない・出来ない、その理由は「他にやることがあるから」ということになります。では何故放置し続けないのか。そうは言っても、いつかは着手しています。ではそれはどういう状態になったときか。それは「ケツに火がついたとき」です。要するに「締め切り間近」になったら、です。TOC理論に基づくCCPMを引き合いに出すまでもなく、学生症候群またの名を小学生の8月31日現象が、大の大人であっても日常茶飯事として発生しているということになります。あんまり子供に偉そうに言える立場じゃないですねw あ、何となく自分の心が挫けそうになりました(^^;

すぐに着手しろといっても、他にやることがあればそうもいかないのが事実。一方で、かといって成り行きに任せると、ぎりぎりの締め切りになるまでバッファを食いつぶしてしまう。そこでCCPMですよ、といかない理由は、ホワイトカラーのルーティンワークはプロジェクトではないからです。その上で、ルーティンワークと言いながらも実際にはアドホックなシチュエーションが多いから、なのです。

  参考:業務フローは獣道 - 業務フローがスラスラ書ける魔法のカード「マジカ!」
     http://magica.hatenablog.com/entry/2011/11/09/094525

いや別に、CCPMをとやかく言うつもりはないのです。ですが、プロジェクトとしてリソースとプロセスをセットにして考慮されているのと異なり、シングルリソース(個人)をマルチプロセスにアサインしてるのが当たり前なのが、ホワイトカラーのルーティンワークなのです。そこを無視してはいけない。これは例えば営業事務や総務の人などに普通に見られる現象です。別名「私はあなたの彼女じゃない」です。というわけで、ようやくデッドロックの話に多分つながります。締め切りの話とデッドロックの話は実は密接に関係があるのです。個人の心理という点で。そのへんを引き続き掘り下げてみます。

次回は年明けになるかと思います。皆様、良いお年をお迎えください。来年も引き続きよろしくお願いいたします。