現場にはさまざまな業務がありますが、それぞれについて分岐処理や例外処理が派生していると思います。ここでは、それを『場合分け』と呼ぶことにします。また『場合分け』の派生に伴い判断のグレーゾーンも存在することでしょう。標準化を進める際にはこの『場合分け』や判断基準をどう線引きするかがポイントとなります。
そこで今回は、現場の『場合分け』を整理するための切り口をご提案したいと思います。
基本型を切り出しておく
"場合分け"を考えるには、それを照らし合わせるための基本型が必要です。どの部分についての分岐なのか、例外なのか、を明らかにするために、仮でもよいので幹と大枝くらいは決めておかないといけません。
例えば「販売管理事務」という範囲で考えてみます。一般に、見積／受注／仕入／納品／売上／請求／回収などといった業務から構成されているかと思います。まず、これらの業務についてあらかじめ定義づけをしておいてください。
例えば「受注業務」なら、「顧客から『注文書』を受取り、注文内容をDBに登録すること」。「納品業務」なら、「受注した商品（種類と数量）を、期日までに指定先に届けること」などのように、その業務が果たす機能を明示しておきます。
そして、１つひとつの業務ごとに、以下の視点から"場合分け"の処理を位置づけていきます。
パターンの違いか？
さて、1つの業務はいくつかの手順がセットになって構成されていると考えます。それをパターンと呼ぶことにします。いわば業務を構成する枠組みです。手順の組合せにより、1つの業務には通常1〜複数のパターンが存在します。
例えば「納品業務」であれば、自社倉庫からの配送、メーカーからの直送、顧客の来社引取り......などがあるかもしれません。例えば「請求業務」であれば、自社フォーマットの請求書発行のほか、客先指定請求書を使用する場合もあるでしょうし、EDIの場合もあるでしょう。過渡期的にワークフローシステムも混在するかもしれません。
まず、このようにパターンとしての"場合分け"がいくつ存在するかを洗ってみます。そして、どのパターンまでを通常業務の範囲ととらえ、どのパターンを例外とするかを判断します。
バリエーションの違いか？
それぞれのパターンにバリエーションが存在する場合があります。洋服でいうと、同一のデザインにカラーバリエーションがあるというイメージです。
請求業務であれば、顧客指定フォーマットにバリエーションがあるでしょう。納品業務であれば、配送手段を宅配にするか、郵送にするか、などはバリエーションとなりえます。
その"場合分け"がパターンの違いなのかバリエーションの違いなのかは、基本的な業務の枠組み（手順のセット）が同類かどうかで判断します。同じ枠組みの中で、処理の対象として並列的な位置づけのものや代替手段となりうるものは、バリエーションととらえます。
業務内容の変更か？
パターンやバリエーション以外に、そもそも業務内容を変えてしまうような"場合分け"も存在します。本来の定義から外れたことをする、ということです。
納品の例でいうと、「分納」といわれるものはそれに該当するかもしれません。 もし、分納の意味が「複数個所に納品する」ということで使われており、業務手順が1箇所への納品の場合とほとんど変らないのであれば、納品のバリエーションととらえてよいでしょう。
しかし「顧客の都合で、一部だけを納品して残部を預かっておく」という意味の場合は、前述した定義とは異なる処理になります。納品の範疇を超えて、保管という新たな業務が発生しますし、会計処理にも関係してきます。
事業として保管サービスも同時に行っているような場合は別として、このように本来の定義から外れるような"場合分け"は特に注意が必要です。それを認めるのか禁止すべきか、という判断を慎重にしなければいけません。
手順の追加・変更か？
業務のパターンを構成する手順に対して、部分的に追加・変更が発生するという"場合分け"もよく見受けられます。業務の変更とは違って小さなアレンジです。
例えば納品時に、「顧客が作成した送付状を同梱する」などは、手順を一部追加する処理になります。「顧客の専用封筒を使用して納品する」などは、手順を部分的に変更する処理になるでしょう。これらは、いわゆるルーチンには乗らない個別対応で、現場で日々発生する可能性があり、都度判断していかなければならない性質のものです。顧客との関係維持のためには、できるだけ対応したいところかもしれません。
ただ注意しないといけないのは、ほんのわずかな違いのように見えて、実は影響が大きい場合があるということです。営業が引き受けてしまったものの、その処理だけがシステムに乗らないために、管理データの数字が正しくとれないとか、他の業務がいったんストップしてしまう、などということもありえるのです。
また、1件だけなら大した処理ではないけれど、その量や頻度が増えると無視できません。そのような場合は、たとえ些細な手順の違いであっても別パターンとしてとらえ、対応するならばルーチンに組込むべきでしょう。部分的な手順の追加・変更であっても、全体への影響を考えて判断する必要があります。
ところで、弊社の場合もそうなのですが、受託開発や業務請負型の事業は特に"場合分け"が多くなります。"場合分け"というよりも、むしろ案件ごとに"個別対応"となるのが通常です。ですから一言に「標準化」といっても、その難しさは重々承知です。
しかし最初から個別対応を前提として業務を組んでしまうと、事実上基準が存在しないのと同じことになってしまいます。アウトプットは「一品もの」、それを支える業務については徹底的に標準化、何とかこれをめざしたいものです。
ただし、"場合分け"が増えること自体は問題とは思っていません。いったん標準化しても時が経てばまた枝が分かれ、グレーゾーンも広がるでしょう。それは成長発展していく上では健全な姿であり、むしろそうならなければ組織として問題だろうと思います。
収束の方向だけでなく、やるべきことをどんどんやっていく、そのためにも上記の視点はお役に立てるのではないかと思っています。
author：上村典子
