ブログを書くことの悩み
前の記事で、来年もよろしく、とか書いていながら直後に更新するのもどうかと思うのですが、一年の締めという感じで蛇足な余談を。
実は昔から、マジカ！に関することをブログなどで書くのは根本的なところで悩み続けていたりします。マジカ！は基本的に素人さんでもスラスラと自分の仕事を書き出せて、その結果として業務フローが手軽に作れるというのを目論んで作ってあります。ですから、何がどうこうみたいな話はせずに済むのが本来のあるべき姿だと言えます。
一方で、マジカ！がターゲットにしてるのは、そうは言っても業務フローです。で、業務フローって決して単純でも簡単でもありません。単純で簡単なら別にマジカ！なんていらないのですｗ ややこしくて面倒だから、せめてそれを書くくらいはもう少し敷居が低いほうが良いよね、ってことでマジカ！を作ってます。ですから業務フローに関する話は、どうしても複雑で大仰な感じになってしまいます。
でもそういうのを読んじゃうと、あぁやっぱり業務フローって難しいんだな、可愛いイラストとかついてても所詮はそういうもんなんだ、自分たちには関係ないな、みたいに思われちゃうんじゃないか、というか、俺ならそう思うわな〜、みたいな気分がどうしてもあって、書くのを躊躇いがちになります。
そういう、私自身としては割とヘビーな、まぁ傍から見ればささやかな葛藤を抱えながら、それでもやはり人生の結構な時間を仕事に使う人が大半なわけですから、それが報われる一助になればいいなぁと願いつつ、引き続き書いていこうと思っていたりします。
では改めて、来年も引き続きよろしくお願いいたします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をとやかく言うつもりはないのです。ですが、プロジェクトとしてリソースとプロセスをセットにして考慮されているのと異なり、シングルリソース（個人）をマルチプロセスにアサインしてるのが当たり前なのが、ホワイトカラーのルーティンワークなのです。そこを無視してはいけない。これは例えば営業事務や総務の人などに普通に見られる現象です。別名「私はあなたの彼女じゃない」です。というわけで、ようやくデッドロックの話に多分つながります。締め切りの話とデッドロックの話は実は密接に関係があるのです。個人の心理という点で。そのへんを引き続き掘り下げてみます。
次回は年明けになるかと思います。皆様、良いお年をお迎えください。来年も引き続きよろしくお願いいたします。
業務フローと滞留
業務フローを書いて業務改善しましょうとは、よく言われる話です。ですが、現実問題として業務フローの何をどうすれば業務改善が出来るのかというと、割と微妙です。
フロー図は大抵の場合、箱と矢印の連なりで書き表されています。で、目指すところは長さを縮めること、というのが大半です。ですから箱すなわち個々人の作業を減らすということが改善のための方策とされます。
ところが、実際にマジカ！での例を膨大に見てきて感じるのは、それぞれの箱つまり作業そのものに必要な時間というのは、実はさほどでもないのです。そして、矢印でつながっている箱のそれぞれの作業時間を全部足しても、そんな膨大な時間にはなっていません。例えば次のようなフローがあるとします。
開始○→[5分]→[5分]→[5分]→○終了
当然、合計所要時間は15分のはずです。ところが現実には開始から終了までに3日かかってますとか、下手すると2週間かかってますとかいうケースが多く見られます。では、これを「フローを短縮しましょう」と言って、箱を減らしたとして所要時間が10分になるのかというと、あんまり期待できそうにありません。つまり、実は業務改善においてフローそのものをいじることで得られる効果というのは、実はさほどでも無いということになります。
現実問題として、箱を減らそうとしても昨今のコンプライアンス（J-SOXやISOやISMSなど）対応をちゃんとすると、必然的に削れない仕事ばかりになります。1980年代の牧歌的なOAブームの頃ならいざしらず、現代においては「やらざるを得ない」事というのが山ほどあるのですし。
では何をどうすればいいのか。実は見るべきは「滞留」ということになります。矢印で受け取ったら即時でその作業に着手してるのかというと実はそうではなくて、大抵の場合はそれを各自が溜め込んでしまうというところに問題があります。ボールを受け取ったらさっさとパスを出せばいいのに、自分がずっと持ち続けてるわけですね。
では何故さっさと着手しないのか。持ち続けるのか。結果としてフローを滞留させているのか。そこに、以前に「いつか書く」とだけ宣言してそのままの、業務フローのデッドロックとシステムダイナミックスの関係というのが出てきます。そこら辺の話を考えていくと、個人と業務フローの関係や、業務フローの重要性をみんなに理解してもらう、という話につながっていきます。
肝は「滞留の解消」。では何故、滞留するのか。言い換えると「何故人は物事を先送りするのか」というところが、本当に直視すべき問題の本質なのです。
この話、まだまだ続く…と思う。多分ｗ
個人と業務フロー
先の記事で「書きます」と言った小難しい話題はそれはそれとして、ちょっと別の切り口の話題を。
マジカ！のダウンロードページには、業務フローに関する悩み事・困り事についてお聞かせくださいという欄があります。書くの面倒くさいと思うのですが、割と皆さん結構な分量の内容をお書き頂いてて、なるほどなぁと参考にさせて頂いております。
そんな悩み事の中で代表的なものはというと「業務フローが上手く書けない」というものです。まぁ、だからマジカ！に興味を持つということで、納得のお話です。お役に立てればいいなぁと思っております。そしてもうひとつ代表的なものとして「業務フローの必要性をなかなか理解してもらえない」というものがあります。これ、なかなかに切実なお話だと思うのですね。
では、どうして業務フローって必要なのでしょうか。誰が必要としてるのか・何故必要としてるのか・いつ必要としてるのか…、何か面倒くさい話ですけど、でも割と本質論だと思うのですね。
この話題を演繹的に考えていくと、もっともらしい話題は並べられると思うのだけど、でも多分そんな話は山ほどしてらっしゃって、でも伝わらないとか、そういうことなのだと思うのです。なのでちょっと、考えの向きを大きく変えてみます。つまり、個人にとって業務フローって何が得なのか？ というところから考えてみたい。ベタですけどｗ
で、個人にとってのメリットってことを考えるにおいて、さらに思い切って「ひとりしかいない仕事でも業務フローって役に立つのか？」ということを考えてみたいのです。組織の中の個人という話の延長で業務フローの是非論を語ると、世間一般の「あるべき論」の枠の中のままだと思うので。
例えば個人事業主として、まぁ何でもいいのですけど、例えばWebデザイナーさんみたいな職業をしてるとします。プログラマとかでもいいのですけど。そうすると、ひとりですから営業もすれば事務もしますし、あれやこれやと本業と自分が考えたいこと以外のやるべき事が山積みです。割と普通にテンパったりしますｗ ではそれを解決するのに業務フローを書くとすると、どれだけ効果があるのだろうか。
実は現在の弊社は2名だけの小ぢんまりした状態なので、個人事業と殆ど変わりません。その状態で業務フローを書くとどうか。…実はあんまり変わりません(^^; 何かが特に楽になるというわけでも無いのです。役立つのはむしろToDoリストとかタスクリストと呼ばれているようなものです。備忘録とでも言うのでしょうか。仕事をパスする相手がいないのですから、当然といえば当然です。
当然なのですけど、ここには物凄い真理が秘められている気がするのです。プロセスと呼びフローと呼ぶ。あるいはプロシージャなりプロトコルとも呼ばれる。その時々で色んな言葉を当てはめられている業務フローですが、実は業務フローとは「複数人における受け渡し」なのですね。ですから業務「フロー」というよりも業務「パス」と呼んだほうがいいのかもしれない。ここでいうパスとはサッカーにおけるパスを連想していただくのが、一番近いと思います。手戻り・差し戻しなどはバックパスなのかもしれません。
では、ひとりで完結する仕事の場合の業務フローを明示するメリットとは？ …別にイラネーヨｗ とか書いちゃうと、そもそもの「業務フローの必要性を理解してもらえない」という悩み事へのソリューションにつながっていかない気もするので、この話題も引き続き掘り下げてみたいと思います。
…って、ペンディングばっかり増やしてどうするんだろ、俺ｗ
to be continued
先日の機能と構造の話とその延長線上として、業務フローの本質がメッセージパッシング（に伴うイベントドリブンモデル）であるという話と、業務フローのデッドロックとシステムダイナミックスの関係という話をしたいと思ってるのですが、書き始めたところで別件が立て込んじゃったので、日を改めて書くという決意だけ記しておきますｗ
構造としての業務フロー
業務フローというのは、構造にあたります。骨組みのようなものです。一方で、以前にも書いたように、業務フローという「モノ」がしっかりと存在するのではなく、あくまでも未来に対する期待・願望・指針でしかありません。つまり触れないし見えない「コト」なのです。
ちょうど先日、サッカーのワールドカップ予選がありました。サッカーでは個々人のプレイヤーやボールそのものは見えますが、プレイヤーの間を受け渡しされるボールの軌跡そのものは見えません。そして実はこの軌跡が業務フローに相当します。
例えば練習のときに、セットプレイではここにAさんが立っていて、こっちからBさんがこのようにパスを出して、のように練習します。しかし本番のときに全く同じように再現できるかというと、決してそうではありません。これは事務作業でも似ていて、ルーティンワークの名前とは裏腹に、実際にはその場その場のアドホックなアドリブが必要となったりします。
ですから、「今後、我社の業務フローはこのようにします」と絵に描いたとしても、それはサッカーの練習のときと同じであって、本番での精緻な再現を保証しません。正に絵に描いた餅なのです。あくまでも、「こういう風に綺麗にパスがつながればいいなぁ・つなぎたいなぁ・つなぎましょうね」という期待・願望・指針でしかないのです。
一方で、その見えない構造の中で、個々人はプレイヤーとしての機能を果たすことになります。機能＝ファンクション＝関数、つまり入力に対して何らかの処理をして出力をします。ボールを受けてドリブルをしてパスを出す、みたいなものでしょう。こちらは目に見えます。指さしして指摘をすることが可能です。ですから「業務フローを改善しましょう」と言いながら、実際には個々人の機能改善に終始していまうケースが殆どになってしまうのです。ITを導入してもその恩恵に浴せないというのは、パス回しが変わらないからというのが大半です。
機能と構造という観点で考えることが大切であり、業務フローとは構造の話なのです。この話続く…かな？
