自分は悪くない

仕事でトラブルやミスが発生したとき、それも皆さんの仕事ではなく、他人や他部門が原因で被害を被った場合に、どのような反応をしますか？

「また、あいつかよ……」と不満を漏らす。「⁠あの部門がちゃんとやらないから！」と、やはり不満を漏らす。あなたでなくとも、身の回りで思い当たる場面は数えればいくつもあることでしょう。

かく言う筆者も、開発の仕事ですでにほぼ設計が完了していたときに、営業から「顧客から要求変更があり仕様が変わった」の一言で、それまでの設計に費やした時間が振り出しに戻った経験があります。当時は、若気の至りもあり、行き場のない怒りを営業や上司にぶつけて、「⁠もっと早く言え！」と食ってかかったものです。とくに、ハードウェア設計ではプリント板を起こすにはマスク発注だけで数百万円は最低かかることもあります。また、ASIC（Application Specific Integrated Circuit）設計にも長く関わりましたが、こちらはマスクを起こし、セルや配線のレイアウト後でリメイクが発生すると、時に数千万以上が一瞬にしてすっ飛びます。したがって、ミスは絶対に起こすことはできないというプレッシャーの中で、設計やシミュレーションに並大抵ならぬ慎重さで臨んだものです。幸か不幸か、ASICに限って言えば、すべて一発でうまく動作し、一度もリメイクは出したことはなかったのですが。

さて、話を元に戻しましょう。

自分がいくら注意をして、ミスを犯さないように慎重に、何度も確認をしながら仕事を行っていても、自分以外や他部門のミスが原因で、自分や自部門に手直しが発生することがあります。

上流工程を押さえる

大河も最初は一滴の水から始まります。水量が多く、川幅も広い下流をいくらきれいにしても、上流で水質汚染や環境破壊がなされていては、下流での努力は無駄になります。

仕事も同じで、前工程ですでに出来の悪いものが、後工程であるあなたの部門に入ってきたらどうなるか結果は目に見えています。後工程が尻拭いをして手直しをする余計な仕事が増えるか、前工程に「ちゃんとやれ！」と差し戻すかのいずれかです。

どちらにしても、時間・工数の無駄遣いです。そして、後工程から見れば、あなたの部門は前工程です。

製造業に関わっていると、このような工程という概念はごく当たり前のように会話でも登場し、さほど違和感なく使っています。しかし、サービス業などの業種、間接部門や事務業務などの業種では、あまり工程という言葉にはなじみがありません。せっかくですので、本連載を機会に覚えてしまいましょう。

業務改善に着手すると、自部門で自己完結するものもあれば、前工程の部門の改善を行わないと、後工程ではいかんともしがたい場面に直面することは珍しくありません。

これも改善の鉄則ですが、前工程である「上流工程を押さえる」は重要です。

誰（who）が悪いではなく、何（what）が悪いかを問う

冒頭に書いたような「また、あいつかよ……」「⁠あの部門がちゃんとやらないから！」では、問題の解決にはならないですよね。「⁠誰が悪い」「⁠あの部門が原因だ」となり、さらに「自分は悪くない」が加わると、部門内や前工程・後工程との関係が当然ながら、ギスギスしてきます。改善活動にも、協力しようという気すら起こらなくなります。

業務改善では、「誰（who）が悪いのではなく、何（what）が悪いかを問う」の姿勢が大原則となります。

どこ（where）が悪いかを見つける業務フロー

何（what）が悪いかをとことん掘下げ見出すことは、実質的に業務改善のスタートラインと言えます。問題を引き起こしている原因を見出すことは、後の記事でお話します。

ここで考えなければいけないのは、「⁠悪いことが起きている」＝「問題がどこで起こっているか」を掴んでおく必要があります。そのときに、「⁠問題はA部門のBさんが問題…」では困ります。だったら、違う人にしてくれ！となってしまいますし、ほかの人が同じことを行っても、問題が起こる可能性も残っているわけです。

「A部門」の、「⁠A-1業務」の、「⁠A-1-3業務のプロセス」において、こうなっているから問題が発生する。このようなロジックが通るようにならないと、問題を見つけたことにはなりません。

地図をたとえとして考えると、「⁠東京都が問題だ」では広すぎてどこに原因があるのか、さっぱりわかりません。どこ（where）が悪いかをきちんと知るためには、「⁠東京都○区△町A番地A-1丁目A-1-3号」までわからないと、改善の対策は打てなくなります。ピンポイント爆撃のようなものです。

どこ（where）が悪いかを見つけるために、業務フローが不可欠になりますが、業務改善に用いるフローは一工夫、必要となります。

ISO、内部統制の業務フローは業務改善で使いものにならない

「業務フローならすでにあるよ」と言う企業は多いことでしょう。QMS（ISO9001）を取得している企業はもちろん、大企業においては内部統制の3点セットとして、業務フローは備えておかなければならないものです。

結論から言いますが、ISOや内部統制の業務フローは業務改善では使いものになりません。その理由はいくつかありますが、大きなものとしては下記の2つです。

• （1）業務フローが粗すぎる
• （2）現場が書いた業務フローではなく正しくない

（1）は、本連載第5回の「図1　属人業務の例」で示したように、“⁠ほんのちょっとの違い⁠”がまず、見えません。

（2）は、実業務に携わる現場メンバーが書いた業務フローではないからです。ISOの場合は、品質管理部門や標準部門、他推進事務局等が業務フローを作ることがほとんどです。内部統制の場合は、監査法人や専門のコンサルティング以外では、内部監査部門がフローの作成を行ってしまいます。現場は聞かれることに答えるだけです。7割程度は正しいけど、残りの3割は結構いい加減なものです。ただし、いい加減であっても、（⁠1）のように粗いので、細かいところが見えていないだけです。残り3割でミスは起こります。

このように、元々、目的が業務改善のために作られた業務フローではないので、仕方がないと言えば仕方ありません。当社の経験上も、ISOや内部統制の業務フローを用いて、業務改善ができた試しは過去に一度もありません。お客様自身も、「⁠いかに改善に使えないものがよくわかった」という声も多くあります。

これまでの記事で書いてきたように、現場を当事者にするためにも、自分たちで書くということも大事なポイントです。

現状の業務プロセスを正確に書く

業務改善に用いる業務フローは、「⁠細かく正確」なものが必要です。現状の業務プロセスが忠実に業務フローとして書かれていなければ、「⁠どこ（where）で」「⁠何（what）が」はわかりません。

本連載の第5回で書いたように、自分の業務は自分が一番知っています。本連載が対象としている“⁠無関心な現場⁠”では、あの手この手を変えて、自分の業務を書く土俵に上げてしまいます。

先に「誰（who）が悪い」の話をしましたが、そうならないために、ここではもう1つ、業務改善で重要な「考える材料」として業務フローを使います。

無関心に与える「考える材料」

皆さんが業務改善に限定せずに、上司から「職場の問題点を出せ」と言われたら、どのように出して整理をしますか？

一般に、問題点を出せとなると、「⁠あれができていない」「⁠これがダメ」などのように、具体的に挙がる場合もありますが、その中には「A課長が悪い」とか、「⁠B部門がいい加減」など「誰（who）が悪い」状態になるケースがあります。

さらに、「⁠CだからDになっている。だから、Eをすべきだ！」と、正しいか正しくないかは別にして、すでに原因らしきものがわかっていて、具体的にやるべきことももっともらしく答える人も出てきます。無関心な現場では、とくにこの場合のように解決策っぽいことが発言されると、「⁠じゃあ、それを改善でやろう！」となりがちです。つまり、さほど深く考えていないし、考えたくもないわけです。

こうなると、まともな問題点の洗い出しにはならず、その場の会話も空中戦で収束しない「中身の全くない場」になります。

物事を考えるには、何もないゼロベースで考えられる人もいますが、おおよそ、無関心な人が多い職場は、そもそも考えることには慣れていません。

したがって、「考える材料を与える」ことが必要となります。それには業務フローがぴったりです。

「どこ（where）で」「⁠何（what）が」起こっているかを、業務フローを見ながら言い合うわけです。これは行ってみるとわかりますが、それまでの空中戦とは異なり、かなり具体的な問題が出てきます。考える材料となる業務フローが高精度なものであるほど、不具合プロセスの発生箇所の特定ができます。まして、自分たちで書いた業務フローで、人前でも発表させられたものなので、下手をすると自分の仕事のやり方のまずさを露呈することにもなりますので、問題の発生要因も一生懸命考えます。

何気なく見落としている、エラー発生時の出戻りパスの多さに気づいたり、無駄なプロセスを見出したりすることにつながります。

業務フローを用いてできること

ここまでにお話をしたことを図1にまとめます。

業務フローは「問題発見」「⁠問題解決」のツールとして使うことができます。

この図を見てわかるように、内部統制やISOには「業務フローが必須」であり、ないと成り立たない性質のものです。したがって、業務改善や標準化とはスタート時点からして目的を異にします。

ほか、業務プロセスから業務フローを作成する過程を通じ、間接的な効果としてコミュニケーションの促進や部門間の連携が図られるようになることも少なくありません。

なぜなら、業務プロセスは自部門だけで完結するクローズドなループよりも、前工程や後工程とシームレスにつながっているので、業務フローを作る際には、否応なく「前後工程の人、他部門の人とコミュニケーションをとる」ことになるからです。これが後の改善に大きくプラスとして寄与します。

問題整理のポイント

業務フローを見ながら、問題を見出すポイントは以下のとおりです。

（1）場所、時間の特定

• 問題がどこで発生しているか？（業務区分と業務プロセス名称で示す）
• いつ発生しているか？
• いつから発生しているか？
• いつもなのか？たまたまなのか？（特定条件と関連）

（2）特定条件下における発生

• どういう条件で発生しやすいか？

（3）他プロセスへの影響

• 問題が発生すると前工程、後工程にどのような影響を与えるか？
• 他部門、関連会社など、自部門・自社以外からのフィードバックのパスを忘れていないか？

（4）問題の早期顕在化

• 不具合、不備を上流工程で止められなかったのはなぜか？

さて、次回は、現場の視点から一転して、「⁠改善の環境づくり」というテーマで、経営者の役割や活動の位置付けなどをお話します。