なぜ会社は問題を解決する時間を確保できないのか？

朝、出社するとメールが届いている。

確認している途中で電話が鳴る。取引先から納期の問い合わせだ。

担当部署に確認しようとすると、今度は別の社員から声をかけられる。

ようやく昼になった頃、予定していた仕事にはほとんど手をつけられていない。午後には会議がある。議題は業務改善だ。

誰も反対しない。むしろ全員が賛成する。

ところが、具体的な作業の話になると、こんな言葉が出てくる。

そして翌月も、その次の月も、忙しい。

こうして会社は、問題を解決する必要性を理解しながら、問題を解決しないまま仕事を続けていく。

なぜだろう。

私は、これは単なる時間不足ではないと思う。

会社が、目の前の仕事を終わらせることと仕事の仕組みを改善することを同じ土俵で判断できていないからではないだろうか。

頼れる人がいるほど改善は後回しになる

この問題を考えるきっかけになった記事がある。

丹羽大規さんの「頼れる人がいる職場ほど、なぜ危ういのか」だ。

丹羽さんは、PagerDuty株式会社が公表したシステム障害対応に関する調査を紹介している。

従業員1,000名以上の企業で障害対応を担う316名を対象とした調査だ。

その結果が興味深い。

障害対応に余裕がないという回答は93.7%。判断や知識が3人以下に集中している職場は39.9%。

中心となる担当者が不在になると対応水準が低下したり、対応が遅れたりするという回答は68.0%だった。

さらに、後回しになっている仕事として、システム改善が50.3%、手順書の整備が44.9%、再発防止策が40.5%と報告されている。

丹羽さんは、この状況について、目の前の対応に追われるほど、知識を個人から仕組みへ移す仕事が先送りされる構造を指摘している。

そして、上司ができることとして、積み残した仕事の可視化、二番手の配置、手順書を書く時間の確保を提案している。

いずれも実践的な対策だと思う。

ただ、私はここで、もう一つの疑問を持った。そもそもその上司は改善のための時間を確保する権限を持っているのだろうか。

担当者を二人に増やすにも、通常業務から人を外すにも、何らかの判断が必要になる。

改善の必要性を理解していることと、それを実行できることは違う。この違いに、組織の問題が潜んでいるように思う。

改善をしない方が今日の仕事は終わる

例えば、ある会社の物流部門を考えてみよう。

毎日100件の出荷がある。そのうち10件で、在庫確認や伝票の修正などの追加作業が発生している。

担当者は、その都度電話をかけ、Excelを確認し、必要な修正を行っている。

一件当たり15分かかるとすれば、毎日150分。年間240営業日なら600時間になる。1時間当たりの人件費を3,000円と仮定すると、年間180万円相当の労働時間だ。

もちろん、これはそのまま180万円の現金損失を意味するわけではない。

固定給の社員であれば、作業時間を減らしても給与が自動的に減るわけではないからだ。

しかし、別の仕事に使えるはずの600時間が、同じ問題への対応に使われている。

では、この問題を解決するために、在庫データの整合性を改善し、出荷処理を標準化するとしよう。

担当者二人が、それぞれ40時間ずつ作業する必要があるとする。合計80時間。人件費換算で24万円だ。

改善によって追加作業がすべて解消されるなら、単純な時間換算では年間156万円相当の余力が生まれる。

現実には改善後の維持費や例外処理も必要だろう。それでも、十分に検討する価値がある。

ところが、現場の上司はこう考える。
「二人を改善作業に回したら、今週の出荷が間に合わない」

そこで改善は延期される。翌週も出荷がある。翌月も出荷がある。

結果として、80時間の改善作業を避けるために、毎年600時間の追加作業を続けることになる。

これは必ずしも現場の上司が非合理的だからではない。

上司が評価されるのは、今日の出荷を止めなかったことかもしれない。

一方、将来の600時間を削減しても、その成果が評価されるとは限らない。今日の業務を止める損失は明確だが、改善を先送りする損失は見えにくい。

だから、今日の業務が優先される。

Googleは、なぜ運用作業に上限を設けるのか

この問題を考えるうえで、GoogleのSRE（Site Reliability Engineering）という考え方が参考になる。

SREとは、ソフトウェアエンジニアリングの手法を使って、システムの信頼性を維持・改善する取り組みだ。

GoogleはSREの考え方を公開しており、その中で「toil（トイル）」という言葉を使っている。

トイルとは、サービスの運用に伴って発生する、反復的で、自動化可能な手作業などを指す。

例えば、毎日同じログを確認する。決まった手順で障害を復旧する。定型的な設定変更を繰り返す。

こうした作業は、システムを維持するために必要なこともある。

しかし、サービスが拡大するたびに運用作業も同じように増えていくなら、いずれ担当者の時間は運用だけで埋まってしまう。

そこでGoogleのSREでは、トイルを含む運用業務がSREの時間を過度に占めないよう、原則として50%を上限とする考え方を採用している。

残りの時間は、システムの改善、自動化、信頼性向上につながるエンジニアリング作業に使う。

ここで重要なのは、50%という数字そのものではない。

問題に対応する仕事と問題を減らす仕事の両方を、最初から業務の中に位置づけていることだ。

通常の職場では、日々の運用が終わってから改善に取りかかろうとする。しかし、運用業務には終わりがない。

問い合わせも、障害も、例外処理も、完全にはなくならない。

だから、改善時間を余った時間として扱えば、改善はいつまでも始まらない。

GoogleのSREの考え方は、その順序を逆にしている。

改善のための時間を確保すること自体を、サービスの信頼性を維持するための仕事として扱うのである。

もちろん、すべての企業が業務時間の半分を改善に充てるべきだという話ではない。業種によっても、業務内容によっても、適切な割合は違う。

重要なのは、改善活動を個人の善意や余裕に任せず、組織として時間を配分するという考え方だ。

なぜ普通の会社では同じことができないのか

では、なぜ多くの会社では改善時間を確保できないのだろう。

例えば、営業部門の社員が、毎日2時間を社内の確認作業に使っているとする。

顧客からの問い合わせに答えるために在庫を確認し、納期を調べ、見積書を修正する。

こうした作業を減らすために、業務の仕組みを見直そうという提案が出る。

しかし、上司はこう答える。
「今月は売上目標が厳しいので、来月にしてほしい」

翌月になると、また売上目標がある。さらに翌月も、同じだ。売上目標がなくなる月など、通常は存在しない。

ここで重要なのは、改善に反対している人がいるとは限らないことだ。むしろ改善の必要性は誰もが理解している。

それでも実行されない。

なぜなら、改善のために通常業務を減らすことを、誰も正式に決定していないからだ。

営業担当者は売上目標を持っている。
物流担当者は出荷件数を管理されている。
経理担当者は月次決算の期限を守らなければならない。

それぞれの部署には、達成すべき目標がある。

しかし、部門をまたぐ非効率を解消する仕事には、明確な責任者も予算も与えられていないことがある。

すると、誰も反対していない改善が、誰にも実行されないまま残る。

改善活動が重要であることと改善活動が業務として成立していることは、別の問題なのである。

問題を解決する人がなぜ評価されないのか

もう一つ考えたいことがある。会社の中には、目に見える成果と、目に見えにくい成果がある。

営業担当者が1,000万円の売上を獲得した。これは比較的分かりやすい。
物流担当者が100件の出荷を完了した。これも分かりやすい。

では、ある社員が業務の仕組みを改善し、年間600時間の確認作業をなくしたらどうだろう。

その600時間は、誰の成果になるのだろうか。

営業担当者の残業が減った。物流担当者の問い合わせ対応が減った。経理担当者の照合作業が減った。

複数の部署に効果が分散すると、改善を実施した本人の成果として把握しにくくなる。

さらに、改善された状態が日常になると、以前どれだけ手間がかかっていたかも忘れられていく。これには皮肉なところがある。

優れた改善ほど改善されたこと自体が見えなくなる。

一方、改善を行わず、毎日の問題を処理し続ける人は、常に忙しく働いている。周囲からも頼られる。

上司からは「よく頑張っている」と評価されるかもしれない。

もちろん、日々の問題を処理する仕事も必要だ。

しかし、問題を処理した回数だけを評価していたら、問題が発生しなくなる仕組みを作る動機は弱くなる。

これは個人の意欲の問題というより、評価の設計の問題だろう。

経営者は改善を何と比較しているのか

経営者が改善活動のために人員や時間を確保しようとすると、必ず費用が見える。

「担当者を二人、今月は改善に回します」
「外部の専門家に依頼します」
「新しいシステムを導入します」

いずれも、必要な費用や時間を説明しなければならない。ところが、改善しない場合の費用は、どうだろう。

毎日の問い合わせ。Excelの照合。手戻り。承認待ち。例外処理。こうした作業は、既存の人件費の中に埋もれている。

追加の請求書が届くわけではない。

だから、改善に100万円かかるという提案に対して、「費用が高い」と判断することはできても、改善しなければ毎年いくらの労働時間を使い続けるのかは、十分に比較されないことがある。

本来、比較すべきなのは「改善費用」と「ゼロ円」ではない。

改善した場合の総費用と改善しなかった場合に発生し続ける総費用である。

例えば、先ほどの物流部門の例なら、改善に必要な80時間と、改善しなければ毎年発生する600時間を比較する必要がある。

さらに、誤出荷や顧客対応の費用、従業員の負担、将来の取扱量増加への対応なども考慮すべきだろう。

これができなければ、会社は目に見える改善費用を避けるために、目に見えにくい非効率を払い続けることになる。

改善する時間を確保するのは誰の仕事なのか

ここまで考えると、改善活動の本当の難しさが見えてくる。

現場の担当者は、目の前の仕事を終わらせなければならない。
上司は、部門の目標を達成しなければならない。
経営者は、会社全体の利益を確保しなければならない。

それぞれの立場には、それぞれの合理性がある。

しかし、その合理性を積み重ねた結果、会社全体としては非合理的な状態が生まれることがある。

例えば、営業部門が顧客対応を優先する。物流部門が出荷を優先する。経理部門が月次決算を優先する。それぞれの判断は間違っていない。

だが、部門間の情報連携を改善する仕事は、どの部署にとっても最優先ではない。

結果として、会社全体では毎年何千時間もの確認作業が発生し続ける。ここに、経営者が担うべき仕事がある。

部門ごとの目標を達成させるだけではなく、部門をまたぐ問題に対して、誰が、どれだけの時間と予算を使うのかを決めることだ。

そして、改善活動を優先したことで一時的に通常業務の処理能力が下がるなら、その影響をどこまで許容するのかも判断しなければならない。

改善の必要性を現場に説くだけでは足りない。改善するために何を減らすのかを決めることこそ経営の仕事なのである。

会社は、今日の仕事を終わらせるためだけに存在するのか

冒頭の光景に戻ってみたい。

毎日、問い合わせが来る。
毎日、数字を確認する。
毎日、例外を処理する。

社員たちは懸命に働き、何とか仕事を終わらせている。会社は今日も営業を続けている。

だから、経営者は安心する。
「問題はあるけれど、何とか回っている」

しかし、そこで考えるべきことがある。

その会社は、明日も同じ問題を処理するつもりなのだろうか。

来月も、来年も、同じ問い合わせに答え、同じ数字を照合し、同じ例外を修正し続けるのだろうか。

もちろん、すべての問題を解決する必要はない。改善にかかる費用が効果を上回るなら、現状を維持することも合理的な判断だ。

しかし、その比較をしないまま「忙しいから改善できない」と言い続けるのは、合理的な判断とは言いにくい。

丹羽さんの記事が示していたのは、頼れる人がいることで、組織が知識の偏りを抱えたまま仕事を続けられてしまうという問題だった。

私はそこから、もう一つの問題を考えた。

問題を解決するための時間を確保しない会社は、問題が繰り返されることを事実上の経営判断として受け入れているのではないか。

改善しないことも、一つの選択である。ただし、その選択には費用がある。

そして、その費用を把握しないまま現状維持を選ぶことと、費用を比較したうえで現状維持を選ぶことは、まったく違う。

会社に必要なのは、社員にもっと頑張ってもらうことだけではない。

今日の仕事を終わらせながら、明日の仕事を減らしていくための判断である。

その判断を誰が行い、何を基準に決めるのか。そこにこそ、経営の役割があるのではないだろうか。

あわせて読みたい

丹羽大規さん「頼れる人がいる職場ほど、なぜ危ういのか」

PagerDutyの障害対応調査をもとに、知識の属人化と改善活動の先送りを論じた記事です。

本稿は、その問題を経営の資源配分という別の角度から考えました。

だっく「優秀な人が辞めても、会社はなぜ困らないのか？」

優秀な人が担っていた組織機能を、会社がなぜ引き継げないのか。人材の退職と経営責任の関係を考えます。

だっく「便利になったはずなのに、なぜ私たちの仕事は増えていくのか？」

効率化が進んでも仕事が減らない理由を、業務の構造から考えます。

参考文献・資料

• 丹羽大規「頼れる人がいる職場ほど、なぜ危ういのか」note、2026年10月14日。

• PagerDuty株式会社「AI時代のシステム障害対応に関する現場実態調査」2026年10月9日公表。https://prtimes.jp/main/html/rd/p/000000035.000101675.html

• Google, Site Reliability Engineering, Chapter 5, “Eliminating Toil.” https://sre.google/sre-book/eliminating-toil/

• James G. March, “Exploration and Exploitation in Organizational Learning,” Organization Science, 1991.

#経営 #組織論 #マネジメント #業務改善 #組織開発 #生産性 #DX