忙しいのに、成果が出ていない人へ。「抱えている量」を成果と勘違いする会社の病気

以前、「部下はいらない。必要なのは『仕事が勝手につながる構造』だった」という記事を書いた。

そこで考えたのは、人を増やしたり、自分がすべてを抱えたりするのではなく、仕事そのものが人から人へ流れていく構造を作ることだった。

では逆に、仕事が「つながらない会社」では、何が起きているのだろう。その一つが、今回考えたい「忙しさ」と「滞留」の問題だ。仕事をたくさん抱えている人は、一見すると会社にとって重要な人に見える。

でも、その人のところで大量の仕事が止まっているとしたら、それは本当に「成果」なのだろうか。

「今ちょっと忙しくて」

会社で、これほど便利な言葉はない。返事が遅くても、仕事が止まっていても、資料や確認が終わっていなくても「忙しいなら仕方ないですね」で終わる。

しかも、忙しい人ほど「仕事をしている人」に見える。会議、メール、電話、依頼が多く、常に誰かから声をかけられている。

だが、ここで少し嫌なことを言う。その忙しさ、本当に成果なのだろうか。仕事を大量に抱えることは、大量の仕事を止めることでもある。

「抱えている」は「進めている」ではない

自分のところに案件が10件あると「10件の仕事をしている」ような気がする。

しかし、8件が止まっているなら、その人は8件分の仕事をしているのではない。8件分の仕事を滞留させている。

工場で仕掛品が山積みなら、「生産性が高い」ではなく、「どこかで詰まっている」と考えるだろう。

ところがオフィスでは、未読メール、確認待ち、自分しか判断できない案件が増えるほど「あの人は忙しい」「重要人物だ」「仕事が集中している」と評価される。

いや。それ、ボトルネックになっているだけかもしれない。

忙しい人が「偉く見える」会社

会社には、忙しさを価値に変換する文化がある。

「今日は会議が6本あった」
「メールが100通来た」
「朝からずっと問い合わせ対応だった」

こういう話は、妙に仕事をした感が出る。だが、会議やメールの本数自体に価値はない。

それによって、何が決まり、何が減り、何が速くなり、何が再発しなくなったのか。価値があるのは、そちらだ。

それなのに「どれだけ大変だったか」が「どれだけ価値を出したか」にすり替わる。この瞬間から、会社はおかしくなる。

本当に仕事ができる人ほど、暇に見えることがある

仕事ができる人は、必ずしも忙しそうではない。

判断基準や担当を決め、テンプレートを作り、例外条件を整理し、承認を減らし、情報の置き場所を統一する。

すると、自分のところに仕事が来なくなる。質問も確認も会議もメールも減り、結果として暇そうに見える。

だがそれは、仕事をしていないから暇なのではない。仕事が流れる仕組みをつくったから暇なのだ。ここを評価できない会社は危ない。仕組みを作った人より、火消しをしている人のほうが目立つからだ。

仕組み化して成功した会社の具体例

仕組み化の価値は、理屈だけではない。個人の頑張りに依存せず、仕事の流れを変えて成長してきた企業の事例がある。

代表例の一つが、トヨタ自動車の「トヨタ生産方式」だ。

トヨタ生産方式では、異常を検知した際にラインを止めて原因を確認し、再発防止につなげる。目先の生産量より、問題を早く発見し、工程を改善する仕組みを重視している。

「止めないこと」が優秀なのではない。問題を見えないまま流さず、再発しにくい工程に変えることが優秀なのだ。

Amazonも、仕組み化の事例として挙げられる。

商品検索、注文、決済、配送状況の確認などを、担当者の個別対応だけに頼らず、システムと標準化されたオペレーションで処理している。注文履歴や配送状況、返品手続きなどを顧客自身が確認できる仕組みも、その一例だ。

もちろん例外対応には人の判断が必要だ。しかし、通常業務を仕組みに移しているからこそ、大量の注文を扱える。

これは、忙しい人が一件ずつ頑張った成功ではない。「毎回人が対応する仕事」を「仕組みが流す仕事」に変えたことが、規模の拡大を支えている。

マクドナルドも同様だ。

調理手順、分量、衛生管理、接客、教育方法などを標準化し、経験の浅いスタッフでも一定水準のサービスを提供しやすくしている。

店舗や地域、商品、時間帯による違いはある。それでも、特定の職人に依存せず、一定の品質を再現しやすくしている点は重要だ。

ここで重要なのは、仕事を単純化したことではない。品質を個人の能力から工程の設計へ移したことだ。

これらに共通するのは、成果を「誰がどれだけ頑張ったか」ではなく、「どれだけ仕事を滞留させず、再現可能な仕組みに変えたか」で測る点にある。仕組み化とは、単なるマニュアル作成ではない。

個人の記憶、経験、気合いに依存する仕事を、誰が担当しても成果が出やすい構造へ変えることだ。

毎回トラブルを解決する人より、トラブルを消した人

例えば、毎週同じ問題が起き、そのたびにAさんが走り回って解決しているとする。

Aさんは評価される。一方、Bさんは原因を考え、入力ルールを変え、チェックを自動化し、責任者を決めて問題そのものをなくした。翌月から何も起きなくなると、Bさんは目立たない。

事件が起きないからだ。

つまり会社によっては、問題を解決する人は評価されるのに、問題を消した人は評価されない。かなりおかしな話だ。

「私がやった方が早い」は、だいたい罠

忙しい人はよく言う。「説明するより自分でやった方が早い」たしかに一回なら早い。しかし10回目も自分でやっていたら、それはもう違う。

仕組み化を先送りしているだけだ。

毎回5分の仕事を100回やれば500分かかる。一方、30分で手順を作り、誰でも5分でできるようにすれば、次から自分の時間はほぼゼロになる。

それでも「自分でやった方が早い」を繰り返し、半年後に「仕事が多すぎる」「人が足りない」「自分しかできない」と言い始める。少し厳しく言えば自分で忙しさを製造している。

「自分しかできない」は、勲章ではない

「これは○○さんしか分からない」一見、専門性が高そうに聞こえる。もちろん、本当に高度な専門知識が必要な仕事もある。

だが実際には、手順や判断基準がなく、情報が個人のメールにあり、経緯や例外処理を本人しか覚えていないだけのケースも多い。

つまり、「自分しかできない」のではなく、「自分しかできない状態を放置している」だけかもしれない。それを職人芸と呼んではいけない。単なる属人化である。

忙しさではなく「滞留」を見ればいい

見るべきなのは、「どれだけ仕事を持っているか」ではなく、どれだけ仕事を流したか。

例えば、こちらのほうが、仕事の価値を表している。

問い合わせへの回答時間が2日から2時間になった。
承認者を3人から1人に減らした。
毎月発生していた差異をゼロにした。
5人必要だった作業を2人にした。
毎回聞かれていた質問を、聞かれなくした。

重要なのは「頑張った時間」ではなく、仕事がどれだけ軽くなったかなのだ。

会社が見るべきなのは「忙しい人」ではない

本来、管理職が見るべきなのは「誰が忙しいか」ではない。その人の周囲にどれだけ仕事が溜まっているか。なぜそこで止まるのか。なぜ確認が集中するのか。同じ問い合わせや判断を何度繰り返しているのか。

そこを見るべきだ。

もし毎日100件メールが来ているなら「すごいね」ではない。まず、「なぜ100件も来るの？」と考えるべきだ。

「忙しい」は、褒め言葉ではない

仕事には繁忙期もある。突発対応もある。新しいものを作るときには、一時的に負荷が集中する。

問題は、それが常態化しているのに、忙しさそのものを仕事の価値として扱うことだ。

忙しい人を見たら、「頑張っているな」だけではなく、なぜ、この人はこんなに忙しいのだろうと考えてみてもいい。

仕事量が多いのか。仕組みが悪いのか。権限が集中しているのか。情報が整理されていないのか。それとも、本人が仕事を手放していないのか。

一番危険なのは、「忙しい自分」が好きになること

人は忙しくなると、忙しさにアイデンティティを持ち始めることがある。

自分にしか分からない。自分に聞かれる。自分がいないと困る。自分が最後に判断する。必要とされている感じがするからだ。だから無意識に仕事を手放さず、仕組みにせず、権限も情報も渡さない。

すると、さらに仕事が集まる。

そして言う。「忙しすぎる」

いや、忙しさを維持しているのは、自分自身かもしれない。

仕事は、減らすためにする

少なくとも私は、仕事とは「増やすもの」ではないと思っている。

毎日同じ確認をするなら自動化する。
毎回同じ説明をするなら文書化する。
同じミスが起きるなら工程を変える。
質問が集中するなら判断基準を公開する。

仕事とは、仕事を片付けることではない。次から、その仕事をしなくて済むようにすることだ。

だから、忙しい人ほど優秀なのではない。

本当に優秀な人は、昨日100あった仕事を今日80にし、来月50にし、半年後には10にしている。そして本人は、どんどん暇そうになる。

それでいい。むしろ、それが仕事なのだ。

明日、次の3つだけを実行しよう。

明日やる3項目チェックリスト

1. 集中している仕事を1件特定する

   • 行動：直近1週間のメール、チャット、会議招集、承認依頼から、同じ内容が3回以上発生した業務を1つ選ぶ。「誰から」「何を」「頻度」「停止箇所」をメモし、原因を「情報不足」「権限不足」「手順不明」「単なる習慣」に分類する。

   • 指標：対象業務1件、発生頻度、停止箇所、原因分類を記録する。

2. 手順を文書化し、承認を1つ減らす

   • 行動：「目的」「開始条件」「手順」「判断基準」「完了条件」「連絡先」をA4一枚または社内Wikiにまとめ、同僚1人に実行してもらう。不要な承認は自己確認または事後報告に置き換える。

   • 指標：手順書1件を作成し、同僚1人が実行。承認者を1人減らす、または承認工程を1つ短縮する。

3. 減った仕事を数値で記録する

   • 行動：問い合わせ件数、確認メールの往復数、作業時間などを、実施前後で記録する。翌週に再発や負荷の移転、例外時の有効性を確認する。

   • 指標：削減回数、削減時間、関係者数、翌週の再発件数を記録する。

忙しいふりをしているだけの人は、もう十分だ。メールの未読数も、会議の本数も、抱えている案件数も、成果ではない。仕事を止め、周囲を待たせ、属人化を温存しているなら、それは貢献ではなく、組織の渋滞だ。

忙しさを勲章にするな。火消しを英雄譚にするな。自分しかできない状態を、価値の証明だと勘違いするな。

明日一つでも仕事を減らせないなら、あなたは仕事をしているのではなく、仕事に使われているだけだ。

忙しさではなく、仕事を減らし、流れをつくった量で自分と組織を測ろう。

あなたがいなくても回る仕組みを、明日一つ残すのだ。

それでも、仕事が動かないことがある

ここまで書いてきたのは、仕事を抱え込まず、滞留させず、仕組みに変えて流すという話だった。

ただ、もう一つ厄介なことがある。

担当を決めた。会議もした。やることも決めた。それなのに、なぜか仕事が動かない。

会議では誰も反対していなかった。それなのに、後になって「実は納得していなかった」「無理だと思っていた」という話が出てくる。

仕事を流すには、業務を仕組み化するだけでは足りない。「決める」という工程そのものにも、仕事を止める場所がある。

関連記事 

構造に仕事を抽象化できれば、何が必要かがわかる。

次の記事では、僕がそれを「無言の不同意」と呼ぶようになった理由について書いた。

→ 「無言の不同意」は、なぜ会議を止めるのか