プロセス指向は正しいのか

業務フローに関わっていると、業務フローは大切なものだと思ってますから業務フローを中心に考えましょうということになります。業務フローが図示してるのはプロセス（過程）ですから、つまりはプロセス指向で物事を考えましょうということになります。ですが実際問題として、本当にそれが正しいことなのか。いかにももっともらしいのですけど、本当か？　と。

前回「パス回し」ということを書きました。例えばサッカーの試合などをテレビで見てると、素人目には「何でそこでわざわざ後ろに戻すねん！」などと突っ込みたくなるときがあります。プロの試合でもあるのですから、これが小学生同士などとなると、そりゃもう言いたい放題です。

外から客観的に見ると、無駄なパスを回してるように見えることがあります。ですが現場の当人からすると、わざと無駄なことをしようとしてるわけではなく、やむにやまれず・必要に迫られて、というのが実態でしょう。業務フローにおいても、何でこんなところでこんな矢印があるのかと思っても、事情を聴くと「あーそりゃ仕方ないわな」ということが殆どです。人はわざわざ自分の仕事を劣悪にするほど仕事熱心ではありませんｗ

ですが実際には以前に書いたような滞留も含めて諸問題が生じています。それをどうすれば解決するのかというときに、プロセス＝業務フローばかり見ていても駄目な気がするのです。では、何を見ればいいのか。それはゴールです。

子供向けのサッカーで、コーチが子供たちに「サッカーで一番大切なのは何か？」という話をしてるのを見たことがあります。「それはシュートを打つことだ」と。シュートが打てないなら、打てるようにするためにパスやドリブルをする。でも全てはシュートするためだ、と言うのです。これは単純になるほどなぁと感じました。いくらパスやドリブルが上手で90分間ボールを巧みに操っても、1本もシュートしなければ確かに意味がありません。

実際の業務においても、一発でケリがつくならそのほうがいいのです。ですがそう上手くは行かないからパスを回すことになる。そのときに「何がゴールなのか」ということを知らずに、いくら効率よくパスをさばいても効果的な流れにはなり辛いのでしょう。

フローって何だ？　実はパス回しだ。んじゃそもそもパス回しって必要なのか？　いや、ゴールを決められるならそれでいいんだよね。じゃあゴールって何だ？　…というわけで、プロセス指向ではなくてゴール指向であるべきだ、とした上で、でもサッカーなどと違って、業務におけるゴールって何なのかというところに、焦点を当ててみる必要があるように感じるのです。

この話、更に続く。。。

業務フローは果たしてフローなのか

前回、業務フローの本質は「流れの構造」だと書きました。ただ、本当に「流れ」なのだろうか、というのが実は割と本気で疑問だったりしています。というのは、以前に「シゴトのおきて」ということも書きましたが、要するに「Aさんからxxという依頼があったら、これをする」「これをし終わったら、Bさんに確認の依頼をする」というような掟＝ルールの集合を個々人がこなしていくのを後追いすれば、それが結果として一筋の流れになっている＝フローがあるように見えるだけではないのか、と。

これは、フローというレールがあってその上に乗っかってるのではなくて、色んなやり取りの軌跡がフローになってる、つまり、フローがある、ではなくて、フローになる、なのではないか、と感じたりするのです。これが以前にも書いた「業務フローは獣道である」という話になります。

実際問題として、実に様々な表記法が存在しますが、全てのケースを書ききれるものが実は存在しません。マジカ！の場合は割り切っていて、「こちらへカード」という、コンピュータのプログラミング言語においてはGoToに該当する、要するにジャンプさせることで、色んなケースについて別出しして記述する方針を採用しています。

ホワイトカラーのルーティンワークは実は結構アドホックだ、というのは、このやり取りが実に臨機応変に切り替わるからで、ワークフローのメタファの元となっている工場のベルトコンベアや、あるいは鉄道のレールなどと比較すると、まったくもって規定されてないかのような動きをします。これは正にサッカーなどのチーム球技におけるパス回しのようです。そして実際には、バックパスに該当するケースが非常に多かったりします。

前回、業務フローとはメッセージパッシングだということも書きました。そう、パッシング、パスをするということです。メッセージをパスする、パスするというのはやり取りをするということです。メッセージをやり取りする。ここでいうメッセージとは「意図」と読み替えていただいて良いかと思います。

この「パスを回す」ということを考えると、回し方のルールの集合だと思えば網羅的に表現は可能です。但しそれは図表現では難しい気がしています。ITに落としこむことを考えると、一般的なルールエンジンにおけるルール記述のほうが適していると感じます。それでも尚、俯瞰的な図表現にこだわるなら、実はそれはネットワーク表現になるように感じるのです。つまり個々人の間のやり取りということになります。

というわけで、もう少しこの話続きます。

メッセージパッシングと業務フロー

業務フローが欲しいと思うのは、複数の人が相互に関わりあう場合です。個人だけに閉じていれば、タスク管理とスケジュール管理の範疇で収まってしまうことが大半だからです。だから個々人にとっては業務フローを作成する有難味が見え辛いという話から、滞留とそれを解消するための順位付けをする道具としての業務フローという話をしてきました。

それはそれとして残件を残しつつも一区切りついた（ことにしたｗ）ので、ちょっと違う切り口で別件のペンディング分にも踏み込みたいと思います。個人ではなくてやはり俯瞰的に全体を見たときに、業務フローの本質って何なのか。逆に言うとタスク管理やスケジュール管理の範疇を超えるのはどういうものか。それは実は「やり取り」であり、格好良く言うとメッセージパッシングを表現するということなのだろうと考えています。

業務には機能と構造があり、業務フローとは構造を表すのだということを以前に書きました。

　構造としての業務フロー - 業務フローがスラスラ書ける魔法のカード「マジカ！」
　http://magica.hatenablog.com/entry/2011/11/17/010356

んじゃ機能に該当するのは何かというと、それが個人レベルでのタスク管理なのだと言えます。その個人レベルの機能を脇に置くと、業務フローの本質は「流れの構造」であり、ここでいう流れとは「やり取り」なわけです。

ということは、機能の話を別出しにしてしまうなら、業務フローで表現するのは「やり取り」だけで良いという気もしてきます。コラボレーション図やシーケンス図のようなイメージでしょうか。

この「やり取り」ということについて、しばらく続けてみたいと思います。

業務フロー間の優先度と個人

前回の話を受けての続きとなります。前回というのは、これです。

　プロセス間の優先度付け - 業務フローがスラスラ書ける魔法のカード「マジカ！」
　http://magica.hatenablog.com/entry/2012/01/05/030736

前回の例では、Aさんが3つの依頼
　・Bさん：提案書送付
　・Cさん：旅費仮払い
　・Dさん：請求金額確認、
を同時に受けて、さぁどれからやればいいのだろうか？　という話を踏まえて、個別のプロセスが幾ら整理整頓されてても、複数のプロセス間の関連性が整理されて無ければ、同時にかち合ったときに困ってしまう。それを解消するには、各プロセスの優先度が設定されてないと駄目だという話になりました。

では、果たしてプロセスの優先度をつけることが出来るのか。身も蓋もない言い方をすると、ぶっちゃけプロセス間の順位なんて決められないと思うんです。でも、そうすると、個々人の裁量に任せるといえば聞こえはいいですけど成り行き任せですよね。

実はこれが、個人と業務フローの関係を考えたときに、個人にとって業務フローを作成することの意義だと思うのです。…って唐突な感じですね(^^;　えっと、この話からの続きになります。

　個人と業務フロー - 業務フローがスラスラ書ける魔法のカード「マジカ！」
　http://magica.hatenablog.com/entry/2011/11/21/154905

色んな仕事をする上で、やるべきタイミングも締め切りも重なってしまうことがある。でも一人がやれることは同時にはひとつでしかない。自ずから順位を決めて何かを優先することになる。何かを優先するということは、逆に言うと何かを先送りすることに他ならないわけです。ではその順位付けを放置するとどうなるか。毎回悩むことになって、結果として滞留になるわけですね。

なので、迷わないように事前に仕事を整理して、重なったときの順位付けをしておく必要がある。ここ重要なのでもう一度書きます。

・仕事が重なったときに迷わないように、順位付けをする必要がある。
・順位付けをするためには、そもそもどんな仕事があるのかを整理する必要がある

この二点を実現するためには何をすればいいのか。そうです。業務フローを書くということが必要になるのです。逆に言うと、順位付けをしないようでは恐らく個々人のレベルでは、業務フローの有難味を実感することは恐らく無いはずです。ですから仮に業務フローを書いてプロセス改善が実現されたとしても、個々人の日常においては実感が伴うことは少ないでしょう。

というわけで、長々と続けてきたこの話題もここで一区切りとなった気がします。業務フローを書いて各プロセスの順位付けをすると、個々人のレベルでいいことがあるんですよ、と。具体的には、重なったときにどれを先送りしてもいいのかということをみんなで明確に決めることが出来ますよ、ということですね。

とはいえ、じゃあ具体的にどうやって順位付けをすればいいのか、順位付けをしたとして、それを日常的な仕事の中でどう活かすのがというテーマが出てくるわけですが、それはまた別のお話として改めて考えてみたいと思います。そうそう、重ならないのに滞留してるというのは、それはサボってるというのが暗黙の前提ではありますね。そのあたりも考える必要があるかと思います。

そんなこんなと未決の話はありますが、まずはここで一区切りということで。

プロセス間の優先度付け

年が明けて2012年を迎えました。皆様いかがお過ごしでしょうか。
本年もよろしくお願いいたします。

…さて、前回は滞留の原因として、同じ人に複数の仕事が重なったときにどうしても先送りしてしまう仕事が発生してしまい、それが業務フロー上の滞留となってしまうという話を書きました。カタカナで書くと、リソース（この場合は人）のデッドロックが生じるわけです。

では、そのデッドロックをどう解消すればいいのかということになるのですが、実はこの論点でビジネスプロセスあるいは業務フローが論じられることは殆どありません。どれくらい無いかというと、例えば2つの業務フローを書いたとして、その両方にAさんという人（リソースですね）が登場するとき、2つの業務フローの重要度あるいは優先度は、どちらが上か下かということを書くことがありますか？　ということでわかります。まずもってそのような例を見かけません。

つまり、業務フローなりビジネスプロセスなり、どちらでもいいのですけど、それらは結局いつも単独で検討されていて、複数の業務フロー同士の重なりあい・関わり合いというものを考慮されてはいないのですね。

しかし現実には重なることが頻繁にあります。わかりやすいのは、女性が受け持つことが多い事務職です。仮に彼女をAさんとして、営業事務を受け持っているとします。今は16時過ぎとしましょう。営業のBさんが「この提案書をコピーしてxx社の某さんに郵送しておいて」と依頼します。その直後に今度は別の営業のCさんが「明日さ、急に札幌のお客さんのところに行くことになっちゃったんで、交通費の仮払いお願い！」と申請書を持ってきます。そこに更に別のDさんが「今、お客さんから電話が入って、先月末の請求書の金額が違うんじゃないのって言われたんで至急確認してよ」と駆け込んできました。

さて、自分がAさんだとして、この3つの依頼、Bさん：提案書送付・Cさん：旅費仮払い・Dさん：請求金額確認、どれを最優先するでしょうか。結構難しいんじゃないでしょうか。あれこれてんてこ舞いしてるうちに、それぞれが「さっきの件どうなった？　え？　まだなの？」なんて言ってきたりしたら、「私はあんただけの彼女じゃない！」と切れられても仕方ない気がします。でも依頼した側からすると、他の依頼があることがわかりませんしとにかく自分の関わってる分にさっさとケリを付けて欲しいとしか思ってません（それは自然なことです）から、Aさんの困りごとには気づかなかったりします。

この場合はいずれも緊急度が高いように感じられるのでAさんも何とか定時までにこなそうと思うのでしょうけど、強いて言えばBさんの提案書のコピーをして郵送というのは、翌日でも大丈夫かな、と先送りされそうな気がします。これも一種の締め切り効果ですね。でもそれを咎めるのもどうかという気がします。

このようなケースが非常に多いのが実態で、これを解消する取り組みが無ければ、幾ら業務フローを個別に綺麗にしても実は部分最適化でしかないのです。というよりも、全体最適化なんてそもそも可能なのか、という気がしてきます。

というわけで、個別のプロセスの最適化もさることながら、それ以上にプロセス間の優先度・重要度の定義・設定をしないことにはどうしようもないんじゃないの？　という問題提起になってきます。この話まだまだ続く、、、と思う。きっと。多分ｗ

ブログを書くことの悩み

前の記事で、来年もよろしく、とか書いていながら直後に更新するのもどうかと思うのですが、一年の締めという感じで蛇足な余談を。

実は昔から、マジカ！に関することをブログなどで書くのは根本的なところで悩み続けていたりします。マジカ！は基本的に素人さんでもスラスラと自分の仕事を書き出せて、その結果として業務フローが手軽に作れるというのを目論んで作ってあります。ですから、何がどうこうみたいな話はせずに済むのが本来のあるべき姿だと言えます。

一方で、マジカ！がターゲットにしてるのは、そうは言っても業務フローです。で、業務フローって決して単純でも簡単でもありません。単純で簡単なら別にマジカ！なんていらないのですｗ　ややこしくて面倒だから、せめてそれを書くくらいはもう少し敷居が低いほうが良いよね、ってことでマジカ！を作ってます。ですから業務フローに関する話は、どうしても複雑で大仰な感じになってしまいます。

でもそういうのを読んじゃうと、あぁやっぱり業務フローって難しいんだな、可愛いイラストとかついてても所詮はそういうもんなんだ、自分たちには関係ないな、みたいに思われちゃうんじゃないか、というか、俺ならそう思うわな〜、みたいな気分がどうしてもあって、書くのを躊躇いがちになります。

そういう、私自身としては割とヘビーな、まぁ傍から見ればささやかな葛藤を抱えながら、それでもやはり人生の結構な時間を仕事に使う人が大半なわけですから、それが報われる一助になればいいなぁと願いつつ、引き続き書いていこうと思っていたりします。

では改めて、来年も引き続きよろしくお願いいたしますm(_ _)m

滞留と締め切り効果

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

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

　　業務フローと滞留 - 業務フローがスラスラ書ける魔法のカード「マジカ！」
　　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日現象が、大の大人であっても日常茶飯事として発生しているということになります。あんまり子供に偉そうに言える立場じゃないですねｗ　あ、何となく自分の心が挫けそうになりました(^^;

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

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

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

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