業務分析のお作法─業務棚卸しで失敗しないためのティップス

　業務分析は、とても大切である。
　システム構築・リニューアル、業務改善など、業務分析が必要とされるシーンは多い。
　業務分析とは、現状を知り、プロジェクトのスタート地点を定めるプロセスである。

　業務分析は、業務の棚卸し、業務の標準化という二つのプロセスに大別される。よりスタート地点に近いのは、業務の棚卸しである。ここでつまづくと、後で手痛いしっぺ返しを食らうこともありえる。

　業務分析の、とりわけ業務棚卸しの失敗は、絶対に避けたい。
　本稿では、そのために必要な業務棚卸しの基本的な取り組み方法と、取りこぼしのない業務棚卸しを行うためのヒントを考えていこう。

業務の基本構造と、棚卸しが厄介な理由

　業務の基本構造は、以下のとおりである。

　● インプット
　　業務の基点となる情報や材料
　● 加工
　　課されたルールや制約、もしくは業務遂行にあたる当事者の技術レベルに従い、
　　人や設備が、インプット対象に対し、何かしらの処理を施す
　● アウトプット
　　製品、サービス、情報など

　企業内では、この基本構造を持つ業務が複雑怪奇に絡まり合い、日常的に遂行されている。
　業務の棚卸しとは、絡まりあった業務同士の関係性を明らかにするとともに、必要な最小単位となる業務に分解し、この基本3構造を明らかにする作業となる。

　業務の棚卸しが難しい理由のうち、本稿のテーマに関係する部分をピックアップしよう。

　1．業務は、複数の人（登場人物）によって分割されていること。
　2．同じ業務を対象としても、登場人物によって理解が異なるケースがあること。
　　 例えば、物流担当者にとっての製品出荷は、営業担当者にとっては売上確定につながる
　　 検収の前段プロセスであるなど。
　3．業務分析の目的は仕組みづくりではあるが、実際の業務においては、仕組みづくりに
　　 何ら寄与しないノイズのような業務が含まれていること。

　3.について補足しよう。
　仕組みとは、「（一定の知識、技能レベルを満たした）人であれば、いつ、何度やっても同じ成果（アウトプット）を生み出せること」である。
　ところが本来仕組みとして行われていた業務も、何度か繰り返されるうちに、本来は必要のないノイズ業務が、どうしても蓄積されてしまう。

　筆者が経験したケースをご紹介しよう。
　ある倉庫会社では、請求書と合わせて、入出庫品目の明細票を発行していた。問題は明細票の中身である。同社の請求担当者は、荷主からの出庫依頼伝票をたぐり、そこに記載されている意味不明な番号（荷主の社内のみで通用する管理番号のようなものらしい）を手入力していたのだ。

　「手間がかかるんですよね」と嘆きつつ、それまで請求担当者は、問題の番号を明細票に記載する意味を考えてこなかった。そこであらためて調べてみたところ、以前は請求内容の突き合わせを行うため必要な番号だったが、現在はEDIによって突き合わせを行うことができるようになったため、不要となっていたのだ。

　これは極端な例ではあるが、実際に業務の棚卸しを行う際には、膨大なボリュームとプロセスの業務の中から、真に必要な業務を見極め、ピックアップする必要がある。

業務棚卸しの例──観察や作業ログ取得による方法

　業務棚卸しでしばしば行われるのが、第三者の観察による業務把握である。
　作業者の傍らにコンサルタントなどが立ち、ひたすら作業者の行う作業を観察・記録していく方法である。物理的なアクションを伴う業務、例えば製造や物流の現場では、こういった目視による観察を行う必要がある。

　PCを用いた業務の場合、作業者の使うPCから操作ログを記録する方法もある。

　だがいずれの方法も、膨大な作業ログから業務の基本3構造を抽出しなければならないため、膨大な手間がかかる。また、作業ログから業務の棚卸しを行うのは、それなりに経験を積んだ人でないとできない。
　作業者によっては観察されることがストレスとなり、普段どおりの業務を再現できないこともある。

　そこで最近注目されるのが、プロセスマイニングツールの利用である。

　プロセスマイニングツールとは、業務遂行の過程で利用されるさまざまなシステムやアプリケーションにおける「申請」「受理」「承認」などのアクティビティログをツールを用いて取得することで、対象となる業務の処理パターンを可視化するアプリケーションである。

　ただし、プロセスマイニングツールが使えるのは、アクティビティログを出力するアプリケーションだけである。Excelのように、ログを発生しないアプリケーションには向かない。
　プロセスマイニングツールは普及しつつはあるものの、利用には数千万円の投資を必要とするものもある。利用できる企業は限られるだろう。

業務棚卸しの例──作業者による自己申告

　業務を行う作業者自身に、業務内容を自己申告して貰う方法もある。
　業務の名称、内容、プロセス、目的などを書き出してもらい、業務棚卸表を作成するのだ。

　この方法は、業務棚卸しに掛かる工数を大幅に軽減してくれるというメリットを持つ反面、業務棚卸し情報の質が、作業者本人に依存するというデメリットを持つ。
　このデメリットは、時として致命的になる。
　作業者の言語化能力、業務に対する理解力、分析能力が劣っている場合、業務棚卸しを行っても、まるで役に立たないことすらありえる。

　自己申告による業務棚卸しの欠点を補う方法として考えられたのが、KJ法とマインドマップを使う方法である。

　「KJ法とマインドマップ」とは言ったが、これは本来のKJ法、マインドマップの使い方とは少々異なる。その手法を、作業者自身の考え方をまとめるためのブレインストーミングとして真似て使うのだ。

　1．メモ紙や付箋紙（以下、便宜上メモ紙とする）を用意する。
　2．作業者は、業務内容をメモ紙に書き出す。
　3．業務内容は、なるべくシンプルな表現でメモ紙に書き出していく。
　4．関係する業務内容は、新たなメモ紙に次々に書き出していく。
　　例えば業務内容が「入金確認処理」の場合、以下のようなメモ紙が考えられる。
　　○ 入金処理
　　○ 通帳記帳
　　○ 請求書の確認
　　○ 突き合わせ
　　○ 過不足の確認（相手先）
　　○ 過不足の確認（入金金額）
　　○ 突き合わせ結果一覧の作成
　5．業務内容は、前述のとおりインプット、加工、アウトプットの基本3構造に
　　 分かれている。
　6．基本3構造を意識しながら、実際のプロセスにそってメモ紙を並べていく。
　　 ここまで実施すると、メモ紙が樹形図状（マインドマップ状）に並ぶはず。
　　 出来上がったマインドマップを俯瞰的に眺め、情報として過不足がないかどうか、
　　 再確認を行う。
　7．上記2.～6.を何度も繰り返し、精緻な業務棚卸しを完成させる。

　なお、本方法の実施にあたっては、作業者の迷いを解き、必要な助言を行うファシリテーターが必要となる。ファシリテーターは、行程6.において作業者が作り上げたマインドマップを確認し、欠けていると予想されるピース（情報や手順など）を作業者に尋ねることで、作業者のブレインストーミングを手助けすることもできる。

　実際には、メモ紙を使わずとも、マインドマップアプリケーションを用い、PC上で業務棚卸しを行うこともできる。
　一方で、複数の作業者が共同で業務棚卸しを行う場合には、メモ紙を使った方が、お互いの情報を補足しながら業務棚卸しを進めることができる。

業務棚卸しに失敗したプロジェクト

　以下は、かつて私が在籍していたシステム開発会社で発生した業務棚卸しの失敗例である。

　クライアントは、健康食品の会員制通販を生業とする会社（以下、A社とする）であった。
　それまでファックスと電話で注文受付を行っていたA社は、ECサイト構築を行った。しかし、完成したECサイトに対し、A社は次々にクレームを挙げてきた。

　「これまで行ってきた優待会員向けの割引サービスが反映されていない」
　「○○という販促キャンペーンの処理方法が違う」

　A社は、「私たちは、『これまでファックスと電話で行ってきた通販のプロセスをECで再現したい』とお願いしただけ。なぜそれができないのか!?」と怒り心頭だった。
　一方で、ECサイト開発を行ったSEたちは、「私たちは、A社に言われたことはすべて再現した。問題になっているのは、私たちが知らないサービスや業務プロセスばかりだ」と不満を隠さなかった。

　実は、筆者がこのシステム開発会社に入社したのは、ECサイトが完成してからである。入社してすぐ、私はA社のクレーム処理と、顧客の言うところの「理想のECシステム」構築を目指すこととなった。

　そこで私は、この問題の原因を探り始めた。

● 業務全容を把握している人が、A社内にいなかった。
● A社では、営業がそれぞれ勝手に独自の販促キャンペーンを立案実施していた。
　例えば、「２」のつく日には、ポイントが倍になるキャンペーンなど。
　しかもこういった勝手なキャンペーンを会社に報告する習慣がなかった。
● A社側のプロジェクト責任者は、会社に報告されていた販促キャンペーンや
　処理プロセスだけをECサイト化すれば良いと思い込み、
　営業にヒアリングしていなかった。
● A社では、業務にかかわる登場人物を把握していなかった。
　例えば、営業B氏の販促キャンペーンに対する在庫引当処理は、何故か
　人事部の事務員D氏が行っているといった不可思議なプロセスがまかり通っていた。

　要は、会社も把握しきれていない隠れ業務がたくさんあったわけである。

　システム開発会社としての前提に立てば、業務棚卸しをしっかりと行うことができなかった責任は追求されてしかるべきだ。
　一方で、クライアントであるA社も、自分自身が把握していない業務内容を、「私たちは、『これまでファックスと電話で行ってきた通販のプロセスをECで再現したい』とお願いしただけ」などと丸投げするのは、無責任と言える。

業務棚卸しの遂行では、性悪説に立つことが必要

　私の在籍していたシステム開発会社のSEは、性善説に立ち、クライアントの言うことを頭から信じ込んだ。これがそもそもの間違いである。
　クライアントの申告を鵜呑みして、正確な業務棚卸しなどできるわけがない。それはクライアントを信用する・しないの問題ではない。クライアントは、業務分析、もっと言えば業務棚卸しのプロフェッショナルではない。システム開発のプロフェッショナルであるシステム開発会社の責任でありプライドとして、業務分析のプロセスや品質をクライアントに委ねたことは、恥と思うべきである（業務分析を請け負っているかどうかは、また別の話である）。

　業務棚卸しの過程において必要なことを列記しよう。

● 業務フロー図を作り、クライアントとともに、論理的な漏れ・抜けがないかどうかを
　検証する。もちろん、検証をクライアントに丸投げするのは言語道断。
● 顧客申告の漏れ・抜けを推理し、言い当てることも、優秀なコンサルタントや
　ディレクターの条件と覚悟すべき。

　契約によって、クライアントとの間で同意事項を積み重ねていくことも必須である。

● 業務の棚卸しを行い、業務調査書を作成したら、必ず両社押印し、
　「これ以上の業務はないこと」をエビデンスとして残すこと。
● 業務棚卸しに問題があり、プロジェクト遂行途中で再び業務棚卸しに
　立ち返る必要が発生した場合の再契約義務や、ペナルティについても、
　契約書で縛ることが必須。

経営の役目

　本稿のテーマである業務分析から少し話が拡散してしまうのだが、より良いシステム構築、業務改善などのプロジェクトを遂行するためには、経営陣のサポートも重要である。
　プロジェクトをより良いものにするためには、「なぜ、○○というプロジェクトを行うのか？」という理由を、経営の責任として、企業の理念やビジョンからブレイクダウンして、社内に下知してもらうことが大切だ。

　これは、業務分析（業務棚卸し）の質にも関わる。
　一例を挙げよう。

　倉庫内で出荷作業を行う際に、フォークリフトのオペレーター（倉庫作業員）がヘルメットを被るというルールであり、プロセスがあったとしよう。

　もし、プロジェクトのミッションが、安全品質の向上であった場合、ヘルメットの着用は、標準プロセスとして必ずドキュメンテーションされなければならない。

　一方、プロジェクトのミッションが、ECビジネス構築であれば、標準プロセスとしてドキュメンテーションされるのは、「倉庫作業員による配送トラックへの積み込み作業」であり、ヘルメット着帽はもちろん、極論フォークリフトの有無も書く必要はない。

　このように、経営の責任としてプロジェクトのミッションを定めないと、業務棚卸しの範囲が広がりすぎたり、もしくはピントがずれる、あるいは対象業務が標準化すべき内容なのかどうかの判定すらできないケースも起こりうる。

　冒頭に申し上げたとおり、業務分析は、システム構築・リニューアル、業務改善などのスタート地点を定める、とても大切なプロセスである。
　手間は掛かるが、だからといって手を抜けば、手痛いしっぺ返しを食らうことは、既に述べたとおりだ。

　常にクライアントと情報と進捗を共有し、プロジェクトのミッションと合致した、必要十分な業務棚卸しを行うように心掛けたい。