フレームワーク活用ガイドひとことで言うと#
問題を見つけた人が誰でもすぐにラインを止められる仕組み。トヨタの製造現場で生まれた「アンドン（行灯）」の考え方を、ソフトウェア開発やサービス運営にも応用できる。問題の先送りを防ぎ、品質と心理的安全性を同時に高める。
押さえておきたい用語#
- アンドン（行灯）
- 工場の生産ラインで異常を知らせる表示板のこと。もともとは物理的なランプだが、現在では異常検知の仕組み全般を指す。
- ラインストップ
- 問題が発生したときに作業を一時停止する行為。止めることで不良品の流出を防ぎ、根本原因の特定に集中できる。
- ジドーカ（自働化）
- 異常が起きたら機械が自動的に停止するトヨタ生産方式の原則。人が異常を検知して止めるアンドンコードは、この思想の人間版にあたる。
- 心理的安全性
- チーム内で「問題を指摘しても罰せられない」と感じられる状態。アンドンコードが機能するための前提条件である。
アンドンコードの全体像#
こんな悩みに効く#
- 問題に気づいていたのに、誰も声を上げなかった
- 小さな不具合が放置され、大きな障害に発展してしまった
- 「止めたら怒られる」という空気がチームにある
基本の使い方#
どんな異常が起きたらラインを止めるのか、具体的な基準をチームで合意する。基準が曖昧だと「止めていいのかわからない」状態になる。
- 例: 本番エラー率が1%を超えた / テストが3件以上失敗した / 顧客からの同一クレームが2件来た
- 基準は「迷ったら止める」側に寄せる
止めたい人が迷わず行動できるよう、手段を用意する。
- Slackの専用チャンネルに
/andonコマンドを設定 - 物理的な赤ボタンやカードをデスクに置く
- インシデント管理ツールに「アンドン」カテゴリを追加
止めた瞬間から復旧までの手順を決めておく。アドリブは混乱のもと。
- 5分以内に関係者が集まる
- 原因の仮説を立て、暫定対処を実施
- 根本原因と再発防止策をドキュメントに記録
具体例#
状況: 従業員25名のアパレルEC。月2回のリリースで、以前は不具合が出ても「次のリリースで直す」と先送りしていた。ある日、決済エラーが3時間放置され、売上 約180万円 を失った。
導入したアンドンの仕組み
- リリース後30分間は全員がSlackの
#release-watchチャンネルに張りつくルール - エラー率が 0.5% を超えたらDatadogからSlackに自動通知
- 誰でも
/andonコマンドでロールバック判断会議を召集できる
3か月後の効果: リリース起因の障害復旧時間が平均 3時間 → 18分 に短縮。止めた人には週次ミーティングで「ナイスキャッチ」として紹介する運用を始め、報告件数が月4件から月11件に増えた。
状況: 従業員180名の自動車部品メーカー。組立工程の不良率が 2.3% と業界平均（1.0%）を大きく上回っていた。現場作業者は「止めると生産ノルマに響く」と感じ、異常があっても流していた。
改善施策
- 各工程にアンドンランプ（赤・黄・緑）を設置し、黄色点灯でチームリーダーが即駆けつけるルール
- 「ラインを止めた回数」を減点評価ではなく品質貢献として加点評価に変更
- 月間で最も多くの異常を発見した作業者を「品質MVP」として表彰（賞金1万円）
| 指標 | 導入前 | 6か月後 |
|---|---|---|
| 不良率 | 2.3% | 1.1% |
| アンドン発動回数 | 月3回 | 月22回 |
| 顧客クレーム | 月5件 | 月1件 |
止める回数が増えたのに不良率が下がるという、一見矛盾する結果が出た。早期発見が後工程への流出を防いだためだ。
状況: 社員12名のSaaSスタートアップ。エンジニア6名全員がデプロイ権限を持つが、「先輩が書いたコードにケチをつけにくい」雰囲気があり、コードレビューが形骸化していた。
導入した仕組み
- GitHubのPRに「アンドンラベル」を追加。誰でも貼れて、ラベルが付いたPRはマージがブロックされる
- 週次で「アンドン振り返り」を5分実施。止めた理由と結果を共有
- CTOが率先して自分のPRにアンドンラベルを貼り、「自分のコードこそ止めてほしい」と宣言
導入2か月で、入社3か月目のジュニアエンジニアが認証周りの脆弱性を発見してアンドンを発動。本番リリース前に修正でき、想定被害額 約500万円 の情報漏洩リスクを未然に防いだ。
やりがちな失敗パターン#
- 止めた人を責める — 一度でも「なんで止めたんだ」と言われると、二度と誰もコードを引かなくなる。止めた行為自体を常に肯定する文化が前提
- 基準を作らずに導入する — 「何かあったら止めて」では判断できない。具体的な閾値やシナリオを事前に決めておく
- 止めた後のフローがない — 止めること自体が目的になり、原因究明や再発防止につながらない。対応手順とドキュメント化をセットで設計する
- 形だけ導入して放置する — 仕組みを作っても使われなければ意味がない。最初の1か月は「止める練習」として、あえて軽微な問題でも発動させてみる
まとめ#
アンドンコードの本質は「止める勇気」ではなく「止めても安全な環境」を作ること。問題を早く見つけて早く直す文化は、仕組みと心理的安全性の両方が揃って初めて機能する。導入の最初の一歩は、リーダー自身が率先して止めてみせることだ。