業務標準化のための業務マニュアル作成

原則か現実か

業務マニュアルには原則を書くべきなのか現実を書くべきなのかと聞かれることがありますが、その場合は「原則です」と答えるようにしています。

原則を書くということは、つまり標準を示すということです。 すると、標準が決まっていないのになぜマニュアルができるのかと思われるかもしれません。決まっていなくても、決めるために先に作るのです。そして決まったら再度作り直せばいいのです。大事なことは「まず作ってしまうこと」です。

なぜ原則と現実が乖離するのか

さて、業務における「原則」とは、"ある時点"において定められた"あるべき姿"を実現するための考え方や方法と言えます。 原則と現実が乖離してきた場合、原則は「正」なわけですから、本来は業務側を正しい方向に是正すべきでしょうが、現場には「そうも言っていられない事情がある」ためギャップが埋まらなくなります。例えば、以下のような事情です。

思想と体制の矛盾

サニテーションや品質保証の業務についてよく見られることですが、理念に照らしてマニュアルが整備されたとしても、一方で時短を迫られたり、人を減らされたりする、その中で原則に則ろうとすると物理的に無理が生じてしまいます。 この場合、もし会社が存亡をかけて品質を保証するなら、要員を増やして体制を整えないといけません。これはつまりはコスト増ということで、あるべき論を追求すると事業が成立しなくなってしまうというジレンマがあります。

状況の変化

取引形態が広がって例外が増えたり、取引先の標準に合わせざるをえないこともあります。特に不況期は、従来の社内のしくみに乗らないような受注形態が増えるかもしれません。このような場合は、例外処理のほうが量的に標準になってしまうことがあります。あるいは、法令の改定や国策の影響で処理を変えないといけないことも起こるでしょう。そのように状況が変わった場合、旧来のシステムを使用しながら対応するためには、本来的でない処理をせざるをえない、ということも起こります。

目的のすり替わり

いつの間にか目的がすり替わって原則に反してしまう場合もあります。もともと安全性を重視してダブルチェックをするのが原則だったのに、いつの間にか効率化が優先されてシングルチェックになっていたなどということが、部門単位でも担当者単位でも起こりえます。例えば「○○業務に要する時間を10％削減」という目標を設定し、安全よりも削減に焦点が合ってしまうようなケースです。さらにこのようなズレは、引き継ぎが行われるたびに強化されてしまう傾向があります。

ローカルルールの存在

ローカルルールが多すぎて、原則がわからなくなっている例もあります。特に管理・間接業務は、複数拠点で同じ業務を行っていることが多く、拠点の数だけルールが存在します。それぞれの現場の人にとっては、自分が行っている現実が真実なのであって、何が原則なのか、どこまでが全社共通でどこからがローカルルールか、などといったことは意識されないでしょう。

管理・間接部門における"見える化"の難しさ

さて、"諸般の事情"を抱えていびつになった業務は、ある時期において原則を見直し、標準的な処理を決めないといけなくなります。
原則を変えるか、原則に戻すか？その判断をするためには、まずは現状が"見える"必要があるのですが、実はここが難関です。
業務処理の"見える化"というと、内部統制を進めるための業務フローや業務手順書が想起されるかもしれません。これらは業務の骨格を把握するための参考にはなります。しかしあくまで監査のために作成された文書であり、業務の運用を表すものではありません。業務は骨の周りについた肉や血管を含めたものです。そこを鮮明にする作業はレントゲンでなくMRIで輪切りにしていくようなものです。これにはどうしても現場の人の協力が必要になります。

しかし現場の業務のあぶり出しは、現場の人にとって必ずしも簡単な仕事ではありません。なぜなら業務にはグレーな部分が多いからです。
もしシステム設計ならば、処理基準を白黒はっきりさせておかないとシステムは動きません。しかし業務はグレーな解釈のままでも動きます。臨機応変にやれてしまう、それが必ずしも悪いとはいいませんが、標準化を進めるためには、白は白、黒は黒、グレーはグレーのままで、その状態を鮮明にする必要があるのです。

ところで意外なことですが、白黒明確なシステムのごく基本的な処理についてすら、現場での認識が間違っていることがよくあります。実際にこれまでに関わった企業のほぼすべてにおいて、現場の人は何らかの誤解をしていました。マニュアルもあり、操作処理も合っているので問題は表面化しないのですが、設計思想や情報構造についての解釈が違っているので、正しいデータは取れていなかったはずです。そして多くの場合、担当者はそのことに気づいていません。システムは正しく動いていたとしても業務が正しく動いているわけではないという例です。

業務マニュアルは2度作る

"見える"状態にするといっても、認識できていないことを見える化するのは困難です。さらに、標準化とは判断をすることですが、目に見えないことに対して判断することはできません。そのため、標準となる業務マニュアルを先に作ってしまうのです。
業務を見直す場合、「現状分析→改善→標準化→マニュアル化」と考えるのが普通で、マニュアル化は改善工程の川下にあるものと捉えられています。しかし製造現場ではともかく、管理・間接部門の業務については「標準化してから......」などと言っているとマニュアル化まで行き着かないだろうと思うのです。
そのため「マニュアル化→仮説検証→改善→標準化→マニュアル化」と、業務マニュアルを2度作るという工程をお勧めします。
マニュアル化の内訳を正しく言うと、1回目はモデル作りで2回目は本番です。1回目の業務マニュアル作成では70点をめざします。このとき100点をめざさないようにしてください。不完全でも速くやることのほうが重要ですし、エネルギーは2回目までにとっておかないといけないからです。
とはいえ50点でもだめです。現場から「使えるものができそう」「見てみよう」という期待感が得られないとまじめに検証してもらえません。現場の人たちに「自分たちのもの」と受け止めてもらえることが大切です。

標準のモデルをどう作るか？

では、標準の決まっていない中で何を元に業務マニュアルを作るのか、それは何でもかまいません。

弊社では仕様書や資料などからある程度書き起こしてしまいますが、社内の人が現業を抱えながらそれをするのは困難だろうと思います。多少古くなってしまったマニュアルがあればそれを元にしてもいいでしょう。もし複数拠点で同類の業務を行っている場合は、特定の拠点をモデルにして作ってしまいます。

注意すべきことは、担当者の所業をあばく作業ではないということです。あくまでもモデルですから必ずしも現実通りでなくて構いません。作りながら多少のバージョンアップはやってしまいましょう。これが70点の範囲です。

もし最初から100点をめざすと、全拠点の関係者すべてにヒアリングして、関連通達もすべてチェックして......となり、あげくの果てに収集がつかなくなって途方にくれるのが落ちです。人も時間もたっぷりかけられる余裕があるならそれもいいかもしれませんが、あまりに非効率です。

さて、1回目の業務マニュアルができたら現場で実際に使ってもらい現状を洗い出します。 ここで大事なのは、モデルが正しいかどうかでなく、現場の人が「標準と現実にズレがある」と認識できることです。そこではじめて「そんなことをしていたのか、それは問題だ」とか「うちではそんな処理は無理」などの議論が生まれます。このように先に標準を示すことによって業務が見えてくるのです。

そして2回目に完成をめざしますが、このときは100点ではなく130点をめざしてください。現在の実態と矛盾がない状態を100点とするならば、 30点分は未来への対策です。業務マニュアルはできあがった瞬間から古くなります。今後起こりうることや問題になりそうなことにできるかぎり手を打っておくのです。また、今後の改定について最小限の労力で済むよう、作り方も工夫しておきましょう。

システムやWebサイトなどの開発を請け負う場合は、いかに仕様を固めて手戻りを少なくするかが重要と言われます。これは社内で開発する場合も言えることでしょう。しかし「業務」という性質は、システムやWebサイトとは違います。完全に後工程としての「業務マニュアル作成」だけを目的とするなら、手戻りはないにこしたことはありません。でも業務の標準化に取り組むのであるなら、むしろ手戻り覚悟で一歩でも前に進めることが大事な気がします。一歩前に進むことでグレーだった部分が少し晴れる、そしたらその地点に立ってまた一歩進む、そうした根気のいる作業が必要なのだと思います。業務マニュアルを標準化の後工程ととらえるだけでなく、一歩進めるための原動力にしていただきたいと思います。

＊標準化の進め方についてはTips53「業務の体系化、標準化はマニュアルを作りながら」も参考にしてください。