改善できる組織は何が違うのか─転職して初めて見えた改善の条件

私は昨年、同じ製造業の同業他社へ転職しました。

会社規模も業種も近く、扱う製品も大きくは変わりません。
それでも実際に働いてみると、組織の雰囲気や仕事の進め方は驚くほど違っていました。

前職では、トラブル対応や納期対応が最優先で、改善活動は後回しになることが少なくありませんでした。
一方、現職では改善活動そのものが日常業務の一部として扱われ、AIやDXの活用、良好事例の共有、勉強会などにも継続的に時間が使われています。

最初は、「会社の考え方が違うのだろう」「ITリテラシーが高いのだろう」と思っていました。
しかし両方の組織を経験した今、違いはもっと根本的なところにあると感じています。

改善を受け入れる文化があること。
そして、その改善を実行するための時間や人員、つまり余力があること。

どちらか一方だけでは改善は続きません。
改善を歓迎する文化があっても、実行する余力がなければ前に進めない。
逆に余力があっても「今まで通りでいい」という文化では改善は定着しません。

この記事では、改善できる組織と改善できない組織の両方で働いた経験をもとに、その違いを整理してみたいと思います。

前職は“まず回せ”が最優先

前職はとにかく「今を回す」ことが最優先でした。
毎日のようにトラブルが起きる。

• 設備不具合

• 工程遅延

• 部品不良

• 人不足

それを、人が吸収して回していく。
当時は月の平均残業時間が50-60時間ほどありました。
土曜日の臨時出勤も多く、実際は月2回ほど出勤していましたが、毎週木曜くらいにならないと出勤要否が決まらない状態でした。
そして出勤しない土曜も、誰かが出勤しているので問題があると電話がかかってきます。

現場を止めるわけにはいかない。
納期もある。
客先もある。
だからまず回す。

この判断自体は、短期的には正しい。
問題は、その状態が何年も常態化していたことです。
この状態だと、さまざまなものが属人化していきます。

過去記事でも書きましたが、

👉XPでしか動かない試験システムの話
20年以上稼働しているシステムをWindows10対応に改修したが、本質解決していない話

👉人が頑張るとDXは進まない
朝6時に出社し、サービス残業で紙のチェックシートを整理する人の話

さまざまな属人化が存在していました。
こういった問題が発生していても、改善に時間を使えない。

なぜなら、今の仕事を回し、出荷に間に合わせるだけで手いっぱいだからです。
そのために、とりあえず動くように直す。応急処置！
とりあえず目の前の書類の山を片付ける。
改善は時間ができた時にやる。
でもその時間は永遠に来ない。

というループに入っていました。
トラブル対応を優先するのは、現場としては自然な判断かもしれません。
ただ転職して別の会社を見たことで、それが長期的にはかなり危険な状態だったと分かりました。

“まず回せ”で残業時間が増える理由

現職では、私の毎月の残業時間は10-20時間程度に抑えられています。
それでも成果は出ているのですが、冷静に前職と現職を比較すると、前職で残業時間が増えたのは至極当然と思える理由がありました。

先ほど書いたように、前職では20年以上前の試験システムが使われていました。
いくら問題を訴えても人も予算もつかず使い続けられ、私はこのシステムは壊れるまで誰も改修できないのだろうな、と思っていました。

当然壊れれば地獄、トラブル対応で残業時間は爆増するでしょうが、放っておいたらいつかは壊れるのが当たり前です。

現職ではこれほど古いシステムは使われていません。
なぜなら、計画的に更新されているからです。

そのための人員や予算も確保されています。
今も試験システム更新の担当業務を持っている人がいて、淡々と計画を進めています。

もう１つ例を挙げた、紙のチェックシート電子化は、現在私が進めています。
かなり難しいため、私自身はこの仕事にほぼ専任、通常の試験やトラブル対応は殆ど担当していません。

このような改善を担当している人がいて、別で通常の仕事をしている人もトラブル対応をしている人もいる。
全体として徐々に良くなりつつ、残業時間も押さえて働き続けられているわけです。

改善を推奨する文化とは

長期的に見ると、古い業務を更新せず回し続けることは非合理的です。
一方で今年の利益を考えると、更新コストを抑制する方が合理的にも見えます。

金と時間を今年捻出するか、壊れてから払うのか。
この違い、改善業務が認められているかが、働きやすさを大きく分けているように感じます。

このような改善は、管理職が問題を見つけて指示する類のものではありません。
担当者が問題を発見し、こうすればいいのではないか？と探索しながら答えを探していかないと進まない類の仕事です。

こういった探索・改善・提案が、業務として認められ、推奨されているか。私はその判断の差が積み上がって、最終的に前述のような働き方の差が生じたと考えています。

ほかにも改善提案の制度にも違いがありました。
前職にも現職にも改善提案の募集はありましたが、前職の場合は提案後の良好事例の横展開が一切無かった。

現職は、他の良好事例をパクった改善の方が評価が高くなります。
また直接関わりが無い部門の改善も含めて、様々な改善事例を簡単に探すことが出来ますし、良好な事例の共有も定期的に行われています。

改善できる組織の３つの共通点

ここまで見てきて、改善できる組織には３つの共通点があると感じています。

• 改善を歓迎する文化があること

• 改善へ投資する意思決定があること

• その改善を進めるための人と時間が確保されていること

改善できない組織では、このどれかが欠けています。

改善を提案しても評価されない。
改善したくても人も時間もない。
結果として通常業務やトラブル対応が優先され、改善は「いつかやる仕事」になってしまう。

当期利益だけを見れば、この判断は合理的に見えるかもしれません。
しかしその判断が何年も積み重なることで、同じ規模の会社でも働き方や組織文化に大きな差が生まれていくのだと思います。

私は転職するまで、これが当たり前だと思っていました。
しかし現職と比較して初めて見えてきたのは、会社ごとの文化ではなく、「改善を継続できる力」の違いでした。

その違いが、数年後の働き方や組織文化の差となって現れるのだと思います。

改善には「時間への投資」が必要

ここまで、改善できる組織には「改善を歓迎する文化」と「改善へ投資する意思決定」があることを書いてきました。

ただ、それだけでは十分ではありません。
改善には、時間が必要です。

改善は、「やれ」と言って担当者を決めれば進む仕事ではありません。
新しい仕組みを定着させるには、教育し、試行錯誤し、良い事例を共有しながら少しずつ広げていく必要があります。

例として、前職でも現職でも導入されていたTeamsを紹介します。
両社とも導入されていましたが、前職ではほとんど使われていませんでした。

私自身は前職でTeamsの活用を広げようとしましたが、「Teamsとメール、どちらで連絡するのか統一してほしい」「Teamsで連絡した後、ちゃんと電話したのか？」といった否定的な反応が相次ぎ、担当レベルで導入促進は無理と諦めてしまいました。

一方、現職ではきちんと使われています。
理由を聞くと、導入の進め方そのものが違っていました。

• 特定部署で先行導入し、良好事例を共有しながら横展開する。

• 導入部門を拡大し、教育資料を整備し、勉強会を繰り返し実施する。

• 管理職に部門毎のチーム立ち上げの指示が出る

このように単にツールを配るのではなく、「現場で使える状態になるまで」時間とコストをかけていたのです。
振り返ると、この違いはITリテラシーではありません。

改善に時間を投資するという意思決定があったかどうか。
その違いだったのだと思います。

AIやDXも同じです。
ツールを導入しただけでは何も変わりません。

• 利用ルールを整備する

• 教育する

• 良好事例を共有する

• 改善点を集める

• 運用を見直す

こうした仕事は、すぐに成果が見えるものではありません。
最初は「なぜ使わなければいけないのか」という反発もあるでしょう。

それでも時間をかけて定着させるからこそ、ようやく改善効果が現れます。

改善とは、ツールを導入して終わりではありません。
改善に時間を投資し続けることなのだと思います。

改善しない組織は、なぜ苦しくなり続けるのか

ここまでで、改善には人も時間もコストも必要だと整理しました。
では、それらを後回しにすると何が起きるのでしょうか。

最初に述べた通りで、前職は長時間残業が常態化していました。
私も最初は、「忙しい会社なんてこんなものだ」と思っていました。
しかし、この状態が何年も続き、安全面にも影響が出始めた頃から、強い違和感を覚えるようになりました。

例えばクレーンで吊っている製品を他の製品にぶつけるような物損事故が、数ヶ月おきに発生していました。

原因は、押し込み生産によって現場に製品が滞留し、作業スペースが圧迫されていたことだと私は考えています。

私は「安全のためにも現場の物量を減らすべきだ」と何度も提案しました。しかし返ってくる答えは、決まって「それでは納期に間に合わない」でした。

背景にあったのは、「工程を止めた人が責任を負う」という文化です。

私は品質部門として、工程を止めなければ安全も残業も改善しないと上司へ説明し、工程会議でも提案しました。

しかし会議では「納期遅延の責任は取れるのか」と問われます。
品質部門の立場で工程全体の責任までは負えません。結局、問題を認識していても工程は止められませんでした。

その文化を象徴していたのが、現場で運用されていたカンバン方式です。

トヨタ生産方式のカンバン方式は、本来は異常が発生したら工程を止め、問題を顕在化させて改善するために考案された仕組みです。

ところが実際には工程が止まってカンバンが尽きそうになると、現場を止めて原因調査をするのではなく、工程担当者が新しいカンバンを発行して工程を動かし続けていました。

つまり、改善のための仕組みが、「止めないための仕組み」として使われていたのです。
その結果、現場には製品が滞留し、平日残業・夜勤・土日出勤で対応する状態が続きました。

問題は「工程を止めたら責任を取らされる」「止めずに納期を守ることが評価される」文化でした。

この環境では誰も改善を起こせず、忙しい状態を解消する手段そのものが失われていました。

私は最終的に退職を決断しましたが、このような環境では、

• 現場を回せる人、長時間残業できる人が残る

• 改善できる人ほど辞めていく

• 残った人へさらに仕事が集中し、改善余力が失われる

という負のループが生まれます。

改善できない組織は、突然壊れるわけではありません。
改善する力を少しずつ失いながら、静かに弱っていくのです。

会社の外を見る意味

私が前職の違和感をここまで言語化できるのは、現職との比較があるからです。
しかし退職を決断した当時は、その比較はまだできませんでした。

それでも「このまま働き続けることは出来ない」と思えた理由があります。
会社の外に接点があったことです。

当時所属していた趣味の団体では、数年前に連絡手段をメールからSlackやDiscordへ移行していました。

連絡ツールを変更する大変さも、便利さも実際に経験していたからこそ、会社でTeamsを使おうともしたし、広がらないことに違和感を持てたのです。

働き方についてもそう。
平均残業時間50-60時間は一般的な働き方ではない、と分かったのは趣味の仲間と話し、働き方を聞いたからに他なりません。

１つの組織に所属していると、その働き方が正しいのか、おかしいのか、判断がつかなくなります。
私自身も前職の何が問題だったのかを言葉にできるようになったのは、退職して一年以上経ってからでした。

まとめ

転職して私が最も驚いたのは、AIでもDXでもありませんでした。
残業時間が抑えられていても、収益が上がる事。
その背景として改善活動そのものが仕事として認められ、そのための時間や人員が割り当てられていたことです。

振り返ると、改善できる組織には共通点がありました。

• 改善を歓迎する文化があること。

• 改善へ投資する意思決定があること。

• 改善に取り組む時間と人が確保されていること。

AIやDXのツールは、その結果として定着していたに過ぎません。

改善は、気合いや個人の努力だけでは続きません。
組織として改善を認め、時間を使い、失敗しながら積み重ねていく。
その積み重ねが、数年後には働き方や組織文化そのものの違いとなって現れるのだと思います。

改善できる組織とは、優秀な人が多い組織ではありません。
改善することを許容し、そのために時間を投資できる組織なのだと思います。

もし自分の会社が改善できる組織か知りたいなら、

• 新しいツールや仕組みが導入して終わりではなく「定着」しているか

• 改善の担当者が組織表に明記され、改善の時間が確保されているか

• 改善事例が共有され、他部署の取り組みを簡単に参照できるか

この3つを見てみるといいと思います。
私は転職して、その違いに初めて気付きました。

あとがき

この記事を書きながら改めて感じたのは、改善できる組織と改善できない組織の差は、一つの大きな出来事で生まれるわけではないということです。

「今年は見送ろう。」
「今回だけがんばってくれ！」
「とりあえず現状維持でがんばろう。」

その小さな判断の積み重ねが、数年後には大きな差になります。

人は自分がいる環境しか知らなければ、その環境を当たり前だと思ってしまいます。
私もそうでした。

転職し、趣味のコミュニティに参加し、他社の事例を見るようになって初めて、「改善できない組織」が当たり前ではなかったと気付けました。

このnoteを書き続けているのも、自分自身の「当たり前」を更新し続けるためです。

改善とは、仕事を変える前に、自分たちの「当たり前」を更新し続けることなのかもしれません。