トヨタ生産方式（TPS）は、必要なものを滞りなく届ける流れと、異常を見つけた時点で止めて品質を工程内で守る仕組みを組み合わせた考え方です。
単に在庫を減らしたり、カンバンを導入したりするだけでは、TPSを実践したことにはなりません。
製造以外の職場へ応用するときは、工場の用語をそのまま移すのではなく、待ち、手戻り、抱えすぎ、異常の見逃しを自分たちの業務に置き換えます。
以下では、基本用語、導入手順、記録様式、測定方法の順に整理します。
最初に押さえたい要点
- TPSの二本柱は、ジャスト・イン・タイム（JIT）と自働化です。
- JITは、必要なものを必要な時に必要な量だけつくり、工程を連続した流れとしてつなぐ考え方です。
- 自働化は、機械または作業者が異常を検知して工程を止め、不良や問題を次へ流さない考え方です。
- 導入は、現状把握、標準作業、異常の可視化、小さな試行、標準の更新という順で進めます。
- 成果は在庫だけで判断せず、安全、品質、待ち時間、手戻り、再発の有無を合わせて確認します。
TPSを支える二本柱
ジャスト・イン・タイム（JIT）
ジャスト・イン・タイムは、必要なものを必要な時に必要な量だけつくる考え方です。
前工程が見込みで大量につくるのではなく、後工程が使った分を引き取り、その情報を前工程へ返すことで、つくりすぎと滞留を抑えます。
この流れを支えるのが、需要の偏りをならす平準化、需要に合わせた仕事のリズムを示すタクトタイム、補充や着手の合図となるカンバンです。
カンバンは掲示板そのものが目的ではなく、何を、いつ、どれだけ補うかを工程間で伝える信号です。
自働化
自働化は、人の知恵を組み込んだ自動化という考え方です。
設備が異常を検知して自動停止する場合だけでなく、作業者が異常に気づいて工程を止める場合も含みます。
停止は作業を遅らせるためではありません。
問題のある状態を次工程へ送らず、発生場所で状況を確認し、再発防止につなげるために行います。
アンドンは異常を周囲へ知らせる表示や通知、ポカヨケはミスを起こしにくくする、または起きても次へ流れにくくする工夫です。
カイゼンとの関係
カイゼンは、現場で問題を見つけ、対策を試し、結果を確かめて標準へ反映する継続的な活動です。
JITと自働化を一度導入して終えるのではなく、仕事の変化に合わせて育て続けます。
具体的な進め方は、関連記事のトヨタのカイゼンを実践する7ステップでも解説しています。
混同しやすい用語
| 用語 | 平易な定義 | 確認する問い |
|---|---|---|
| タクトタイム | 顧客の需要に合わせて仕事を進めるためのリズム | 求められる量を、どの間隔で完了させる必要があるか |
| 平準化 | 仕事量や種類の偏りをならすこと | 特定の曜日、時間、担当者へ仕事が集中していないか |
| カンバン | 補充、引き取り、着手を伝える信号 | 後工程の必要量が前工程へ正しく伝わっているか |
| アンドン | 異常の発生と支援の必要性を知らせる仕組み | 誰が、何を見て、いつ止め、誰へ知らせるか |
| ポカヨケ | ミスを予防し、流出を防ぐ工夫 | 注意力だけに頼らず誤りを防げるか |
| A3問題解決 | 背景から結果までを一枚で共有する問題解決の型 | 問題、原因、対策、検証結果がつながっているか |
| 5S | 整理、整頓、清掃、清潔、しつけを通じて異常を見つけやすくする活動 | 必要なものが定位置にあり、正常と異常を区別できるか |
タクトタイムと一件あたりの平均処理時間は同じ指標ではありません。
前者は需要から考える仕事のリズムであり、後者は実際の処理にかかった時間です。
両者を分けて見ると、需要に対して能力が足りないのか、待ちや手戻りが処理を遅らせているのかを整理しやすくなります。
製造以外の業務へ置き換える方法
製造現場とサービス業では、扱う対象も品質の定義も異なります。
それでも、仕事が工程を移動し、途中で待ちや手戻りが生じるなら、TPSの問いを改善に利用できます。
| TPSの対象 | 製造 | オフィス業務 | 開発運用 |
|---|---|---|---|
| 仕掛かり | 工程間にある未完成品 | 未処理の申請、稟議、問い合わせ | 未着手のチケット、レビュー待ちの変更 |
| 後工程の引き取り | 使用した分を前工程から補充 | 処理能力に合わせて次の案件へ着手 | 担当者が空いてから次の作業を引き取る |
| 異常の通知 | 設備停止、品質異常、作業遅延を表示 | 期限超過、入力不備、承認停滞を通知 | テスト失敗、障害、レビュー滞留を通知 |
| ポカヨケ | 部品の向きや手順の誤りを防止 | 必須入力、形式確認、確認手順を設定 | 自動テスト、入力検証、権限確認を設定 |
この表は完全な対応関係を示すものではありません。
たとえば、顧客からの問い合わせを物理的な在庫と同じように扱うことはできませんが、件数、滞留時間、処理の優先順位を可視化する手掛かりにはなります。
改善を進める五つの手順
- 対象と価値を決める：一つの業務を選び、誰に何を届ける工程なのか、完了と判断できる状態は何かを言葉にします。
- 現状を観察する：入力、工程、出力、利用者の順に流れを描き、待ち、手戻り、仕掛かり、異常が起きる場所を記録します。
- 標準と停止基準を決める：現在の安全な手順、品質確認、異常時の連絡先、再開条件を明文化します。
- 範囲を限って試す：一つの工程、一つのチームなど影響を管理できる範囲で変更し、実施前と同じ指標で変化を見ます。
- 標準を更新する：効果だけでなく副作用も確認し、採用する対策を手順へ反映します。期待した変化がなければ、原因の見立てへ戻ります。
安全、法令、医療、会計など専門判断が必要な工程では、現場だけで停止や再開の条件を決めず、責任者と専門家を含めて設計します。
そのまま使える三つの記録様式
標準作業票
- 目的：この作業が誰へ何を届けるのか
- 前提：必要な情報、道具、権限、安全上の注意
- 手順：番号を付けた作業と、各段階の確認点
- 合否基準：完了、保留、差し戻しを区別する条件
- 例外：停止条件、連絡先、再開条件
- 改訂履歴：変更理由、確認者、適用日
アンドン運用カード
- 異常の種類：安全、品質、設備、材料、情報、納期
- 発報条件：判断できる具体的な状態
- 発報できる人：役職にかかわらず止められる範囲
- 初動：作業停止、対象の隔離、関係者への通知
- 再開条件：誰が何を確認したら再開できるか
- 記録：発生場所、現象、暫定対応、原因、恒久対策
A3問題解決シート
- 背景：取り組む理由と影響を受ける人
- 現状：観察した事実と基準値
- 問題：あるべき状態と現状の差
- 目標：期限と確認可能な到達条件
- 要因：事実で確かめた原因候補
- 対策：担当、実施時期、確認方法
- 結果：指標の変化と副作用
- 標準化：手順への反映と他工程へ広げる条件
三つの業務で考える導入例
| 業務 | 見えている課題 | 最初に試す対策 | 確認する指標 |
|---|---|---|---|
| 組立 | 最終検査で不良がまとまって見つかる | 異常を発生工程で知らせ、対象を次へ流さない停止基準を決める | 不良の発生工程、手戻り、停止理由、再発 |
| 問い合わせ対応 | 繁忙時に未処理案件が滞留する | 滞留時間と件数を表示し、支援を求める条件と引き取り順を決める | 初回応答までの時間、滞留件数、差し戻し |
| ソフトウェア開発 | 着手中の作業とレビュー待ちが増える | 同時進行数を見直し、空きができた担当者が次の作業を引き取る | レビュー待ち時間、手戻り、緊急割り込み |
これらは効果を保証する実績値ではなく、問題の切り分け方を示す例です。
実際の対策は、現場の安全条件、需要、作業能力、品質基準を確認して決めます。
KPIは安全、品質、流れを組み合わせる
| 領域 | 指標の例 | 読み取る内容 |
|---|---|---|
| 安全 | 危険の報告、停止理由、是正の完了 | 速度を優先して危険を見逃していないか |
| 品質 | 不良、差し戻し、再作業、再発 | 問題を後工程へ送っていないか |
| 流れ | リードタイム、待ち時間、仕掛かり、処理量 | 仕事がどこで滞留しているか |
| 学習 | 標準の改訂、対策の検証、横展開 | 改善結果が次の仕事に反映されたか |
| 利用しやすさ | 操作不能、読めない表示、入力エラー、支援依頼 | 仕組みが一部の人だけを前提にしていないか |
一つの数字だけを追うと、未処理件数を減らすために品質確認を省くなど、別の問題を生むことがあります。
少数の指標を組み合わせ、変更前後を同じ条件で比べます。
導入で起きやすい失敗
- 在庫削減だけを先行する：工程が不安定なまま仕掛かりを減らすと、欠品や待ちの原因を増やすことがあります。まず需要、能力、標準作業を確認します。
- 止めた人を責める：異常を報告すると不利益を受ける職場では、問題が隠れます。停止を個人の失敗ではなく、仕組みを直すための情報として扱います。
- カンバンを作って終わる：作業カードを並べるだけでは、引き取りの条件も同時進行数も変わりません。補充または着手のルールまで決めます。
- A3を事後報告にする：結論を整えて書くだけでは原因を検証できません。現状、原因、対策、結果のつながりを確認します。
- 色だけで異常を伝える：赤、黄、緑だけでは状態を区別できない人がいます。状態名、短い説明、アイコンなどを併用します。
誰でも異常を伝えられる情報設計
アンドンやダッシュボードは、表示できれば十分ではありません。
状態を色だけに依存させず、ラベル、形、アイコン、短い文を併用します。
音を使う場合も、画面上の表示や通知履歴など別の確認手段を用意します。
デジタルな申請、承認、発報の操作はキーボードでも完了できるようにし、見出しと項目の順序を読み上げても意味が通るようにします。
図や写真には、判断に必要な情報を伝える代替テキストを付けます。
設計、実装、運用での確認点は、Webアクセシビリティを実務に組み込むチェックポイントも参考になります。
最初の改善で使うチェックリスト
- 対象を一つの業務、一つの工程に絞ったか
- 誰に何を届ければ完了なのかを決めたか
- 待ち、仕掛かり、手戻り、異常の発生場所を観察したか
- 正常と異常、停止と再開の条件を言葉にしたか
- 影響を管理できる範囲で一つの対策を試したか
- 変更前後を同じ指標で比較したか
- 結果と副作用を標準作業票またはA3へ残したか
結論
TPSの実践は、道具の導入ではなく、仕事の流れと異常への対応を設計し直すことです。
JITで必要量と流れを整え、自働化で問題を次へ流さず、検証した改善を標準へ戻します。
最初から全社へ広げる必要はありません。
一つの工程で待ちと手戻りを観察し、停止基準を決め、小さな変更を同じ指標で確かめるところから始められます。
この記事に関連する株式会社greedenの取り組み
業務の滞留や手戻りを減らすには、現場の流れを可視化し、改善を仕組みに落とし込む必要があります。株式会社greedenは、要件整理から開発、保守・改善まで一貫したWebシステム開発で、その実行を支援します。