業務改善プロジェクトの成果報告会で、コンサルタントが誇らしげにA0サイズのフロー図を貼り出す。仕入から支払まで、四つのレーンに整然と並んだ角丸四角、行き交う矢印、色分けされた承認ノード。美しい。会議室の全員が「よくできている」とうなずく。だが三か月後、その図を見返す者は誰もいない。現場の担当者に聞けば「あの図、うちの実際の動きとは違うんですよね」と苦笑いする。図は仕入先が支払サイトを守る前提で描かれていたが、現実には毎月三社が締めに間に合わず、担当者はそのたびに個別に電話し、Excelで手当てし、翌月に付け替えている。その一番手間のかかる部分が、図には一本の矢印としてすら存在しない。
美しいAs-Isは嘘をつく
フロー図が綺麗であればあるほど、それは現実から遠い。理由は単純で、綺麗な図とは分岐と例外を削ぎ落とした図だからだ。標準的な流れ、いわゆるハッピーパスだけを残せば、線は真っ直ぐになり、レーンは整い、見栄えは良くなる。だが業務時間を実際に消費しているのは、そのハッピーパスではない。伝票の不備で差し戻す手戻り、承認者が出張で三日止まる待ち時間、システムに載らない少額取引を手作業で処理する例外。これらは図を汚くする要素であり、だからこそ描き手は無意識に省く。省いた結果、最も改善価値の高い部分が図から消える。
だから狙うべきは美しさの逆だ。汚くて構わない。むしろ分岐が多く、待ちの箱があちこちにあり、「ここで三割が差し戻される」といった注記で埋まった図こそが、正しいAs-Isである。可視化の目的は鑑賞ではなく、時間がどこで溶けているかを見つけることだ。時間が溶けているのは例外処理と待ち時間なのだから、そこを描かない図は目的を達していない。整然としたフロー図に満足したときが、最も危ない。
暗黙知は「隣で一周やらせて見る」まで出てこない
ではその例外処理をどう引き出すか。ヒアリングだけでは絶対に出ない。担当者に「あなたの業務を教えてください」と聞くと、返ってくるのは教科書的な標準フローだ。本人は嘘をついているのではない。日常的に無意識でやっている例外対応は、本人にとって空気のようなもので、改めて言語化する対象にならない。「毎月あの三社は電話しますけど、それは業務ですらないというか、まあ当たり前なので」という感覚だ。当たり前だと思っていることは、質問では出てこない。
引き出す唯一の方法は、実際に一周やってもらい、隣で見ることだ。ヒアリングではなく観察。担当者が実際の月次を回すのを横で見ていると、フローに描かれていない動作が次々に現れる。あるファイルを開いて前月の数字を確認する、特定の仕入先だけ別のフォルダの覚書を見る、システムを閉じて電卓を叩く、付箋に何か書いて画面に貼る。「今、何をしましたか」と一つずつ聞くと、「ああ、これは毎回やるんです、じゃないと合わないので」と、本人も説明できていなかった暗黙知が言語化される。ここで初めて、図に描くべき現実が手に入る。
観察の場では、聞き方も効く。「なぜそうするのか」を問い詰めると、担当者は責められていると感じて身構え、手順を正当化し始める。すると本音の例外処理が引っ込む。だから問うのは理由ではなく事実だ。「今クリックしたのは何のためか」ではなく「今、何をしたか」。淡々と動作を拾い、判断を挟まない。改善の議論はあとでいい。観察のフェーズでやるべきは、良い悪いの評価ではなく、現実の記録に徹することだ。評価を混ぜた瞬間、担当者は自分に不利な例外を隠す。可視化がうまくいくかどうかは、この観察の場で担当者が安心して「実はこうしています」と言えるかにかかっている。犯人探しの空気を出したら、暗黙知は永遠に出てこない。
観察には二つの要点がある。第一に、標準的な月ではなく、荒れる月に見ること。締めがきつい月、月末が休日に当たる月、大口の返品が出た月にこそ例外が集中する。平穏な月を観察しても正常系しか見えない。第二に、複数の担当者を見ること。同じ業務でも人によって手順が違う。その差分こそが、標準化されていない、つまり属人化しているポイントであり、リスクと非効率の巣窟だ。二人が同じ作業を別のやり方でやっているなら、少なくとも一方は最適でなく、両方が最適でない可能性すらある。
観察でもう一つ拾うべきは、待ち時間だ。担当者は動いていないが、業務は止まっている時間。承認者のレスポンスを待つ、他部署からのデータを待つ、システムのバッチ処理を待つ。これらは担当者本人の作業ログには現れないため、ヒアリングでは絶対に出ないし、本人も「待ち」を業務時間とは認識していない。だが業務全体のリードタイム、たとえば締めが何日で終わるかを決めているのは、往々にしてこの待ち時間の総和だ。作業そのものは正味二日でも、待ちが挟まって実際には七日かかっている、という構造は珍しくない。作業を速くする改善は正味二日を一日にするだけだが、待ちを潰す改善はリードタイムを七日から三日にする。桁が違う。だからフロー図には、作業の箱だけでなく、箱と箱の間の待ちも明示的に描く。矢印を一本引いて済ませず、そこに「承認待ち平均三日」と書き込む。待ちを描かない図は、改善余地の大半を隠している。
粒度は「改善したい単位」で切る
観察して例外を全部拾うと、今度は逆の失敗が待っている。細かく描きすぎることだ。マウスのクリック一つ、キー入力一つまで図に落とすと、図は巨大化し、描くこと自体に何週間もかかり、いつしか「立派な図を完成させること」が目的にすり替わる。これは最初の「綺麗な図で満足する」罠の変形で、今度は詳細さで満足してしまう。
粒度を決める基準はただ一つ、そこで改善の意思決定ができるかだ。図を見て「この作業は止められる」「この承認は要らない」「ここは自動化できる」と判断できる粒度まで来たら、それ以上は掘らない。逆にその判断ができないほど粗いなら、もう一段割る。改善の単位と図の単位を一致させる。クリック単位の記述が要るのは、RPAで自動化する直前の設計フェーズだけであって、業務棚卸しの段階でそこまで下りるのは掘りすぎだ。棚卸しは意思決定のための地図であって、施工図面ではない。
実務では、この粒度の判断を一人で抱え込まないことも効く。描き手が「これは一つの箱か、三つに割るべきか」で迷ったら、その業務の責任者に「この単位で改善を語れるか」を問えばいい。改善の意思決定をする当人が納得する粒度が、正しい粒度だ。粒度は図の美観の問題ではなく、誰がその図を使って何を決めるかで決まる。だから描き始める前に、この図を誰が意思決定に使うのかを決めておく。使い手が決まれば、粒度は自ずと定まる。使い手を決めずに描き始めると、詳細を足せば足すほど良い図に見えて、際限なく掘ってしまう。
出口のない可視化はやるな
最後に、そもそも論を言う。可視化そのものには価値がない。図を作った達成感は、成果ではない。可視化が価値を生むのは、三つの出口のどれかにつながったときだけだ。
一つ目の出口は「止める作業の特定」。図の中で価値を生んでいない箱、二重入力、形だけの承認、誰も見ない中間資料に印をつけ、廃止か自動化か省略かを一件ずつ決める。可視化の最大の見返りは、効率化ではなく作業の廃止だ。速くやるより、やらないほうが常に強い。二つ目は「引き継ぎ」。正しく描かれた例外込みのフロー図は、そのまま引き継ぎ資料になり、退職や異動のたびに繰り返される暗黙知の再発掘コストを消す。属人化の解消は、可視化の副産物ではなく主目的に据えていい。三つ目は「採用要件」。この業務を回せる人材にどんなスキルが要るのかは、例外処理まで描いた図があって初めて正確に定義できる。求人票の解像度が上がる。
逆に言えば、この三つのどれにもつながらない可視化は、やる意味がない。「現状を把握しておきたい」というだけの棚卸しは、綺麗な図を一枚作って自己満足して終わる典型だ。着手する前に、この図で何の意思決定をするのかを一行で書けなければ、着手しないほうがいい。可視化は手段だ。手段が目的になった瞬間、A0の紙とインクと、それを描いた数週間が丸ごと無駄になる。描く前に、出口を決めろ。
As-Isを描いたら、To-Beに飛びつくな
もう一つ、実務でよく起きる失敗に触れておく。苦労してAs-Isを描き切ると、多くのプロジェクトが勢いのままに理想形のTo-Beを描き始める。システムを刷新し、承認を電子化し、全社で標準化された、あるべき業務フロー。これが罠になる。理想形は綺麗で壮大で、経営に見せると受けがいい。だが、たいてい実現には大きな投資と長い期間が要り、着手されないまま塩漬けになる。As-Isの汚い現実と、To-Beの美しい理想。その間には深い谷があり、多くのプロジェクトはこの谷を渡れずに、二枚の図だけを残して終わる。
正しい順序は、To-Beを描く前に、As-Isの中から「今すぐ止められるもの」を先に刈り取ることだ。二重入力、誰も見ない中間資料、形骸化した承認。これらはシステム投資を一円もかけずに、来月から止められる。理想形を待たずに、目の前の無駄を今週潰す。この小さな刈り取りを積み重ねてから、それでも残る構造的な問題に対して初めてTo-Beと投資を議論する。順序を逆にすると、止められたはずの無駄を、理想のシステムが来るまで何年も続けることになる。可視化の価値は、遠い理想ではなく、明日止められる作業を一つ見つけることのほうにある。壮大なTo-Beに酔うより、地味な廃止を今週実行するほうが、はるかに効く。
