На производстве Toyota сварочный робот внезапно остановился посреди операции. Тайити Оно, отец Производственной системы Toyota, разобрал случай пятью последовательными «Почему?»: робот остановился, потому что перегорел предохранитель от перегрузки цепи; цепь перегрузилась, потому что подшипники были недостаточно смазаны и заклинило; смазки не хватило, потому что маслонасос качал недостаточно; насос качал недостаточно, потому что забился заборник; заборник забился металлической стружкой, потому что на нём не было фильтра. Только на пятом «Почему?» команда нашла системный пробел — отсутствие фильтра, — устранение которого предотвращает весь дальнейший каскад отказов, а не просто чинит сгоревший предохранитель.
Метод «5 Почему» — не про магическое число пять, а про дисциплину не останавливаться на первом удобном ответе (обычно — «виноват конкретный человек») и идти дальше, к системной, процессной причине, которую можно устранить так, чтобы проблема не повторилась.
Происхождение и исследовательская база
Технику приписывают Сакити Тоёде, основателю Toyoda Automatic Loom Works (предшественника Toyota) — он применял последовательные вопросы «почему?» для разбора производственных проблем ещё в 1930-х годах. Формализовал и сделал технику центральной частью Производственной системы Toyota (TPS) Тайити Оно в 1950-х — именно его версия с примером сварочного робота стала наиболее цитируемым каноническим изложением метода. Международную известность техника получила в 1980-1990-х вместе с распространением бережливого производства (Lean) за пределами Toyota.
«Основа научного подхода Toyota — повторяя „почему" пять раз, проясняется и природа проблемы, и её решение» — Тайити Оно.
Формализовал технику как систематическую практику Тайити Оно, архитектор Производственной системы Toyota, в книге «Toyota Production System: Beyond Large-Scale Production» (впервые издана в Японии в 1978 году, английский перевод — 1988). Именно из этой книги происходит хрестоматийный пример со сварочным роботом, который открывает эту статью, — Оно использовал его как учебную иллюстрацию для инженеров Toyota.
Ключевые идеи и принципы
Принцип: данные и факты, а не предположения
Каждый ответ на «Почему?» должен опираться на проверяемый факт — что реально произошло, а не на то, что кажется правдоподобным объяснением. Ответ-догадка на одном из шагов рвёт всю цепочку причинности, и итоговая «корневая причина» оказывается таким же предположением, как и промежуточные шаги.
В производственной системе Toyota этот принцип формализован отдельным термином — genchi genbutsu (現地現物, «пойди и увидь сам»): прежде чем спрашивать «почему», ответственный обязан лично прийти на место события — к станку, на склад, на встречу с клиентом — и зафиксировать факт, а не полагаться на пересказ через несколько рук. Оно связывал именно с этим принципом надёжность всей последующей цепочки «Почему?»: недостоверный факт в основании делает бессмысленной сколь угодно логичную цепочку рассуждений над ним.
Принцип: процесс, а не человек
Цепочка вопросов должна вести к системной, процессной причине (отсутствие фильтра, отсутствие регламента, отсутствие проверки), а не к имени конкретного сотрудника. «Иванов ошибся» — не корневая причина, а точка, где чаще всего останавливаются преждевременно: если бы на месте Иванова оказался кто угодно другой, столкнулся бы он с той же процессной дырой?
Принцип: логическая связность на каждом шаге
Каждый переход обязан проверяться на прямую причинно-следственную связь: если причина А, то обязательно ли следствие Б? Ответ, который звучит тематически близко, но логически не следует из предыдущего шага, обрывает цепочку так же, как и ответ без опоры на факты.
Принцип: пять — ориентир, а не жёсткий лимит
Количество «Почему?» не магическое число ровно пять — иногда корневая причина обнаруживается на третьем шаге, иногда требуется семь. Пять — эмпирический ориентир Оно, подсказывающий, что для настоящей системной причины обычно требуется больше одного-двух шагов вглубь, а не жёсткий протокол, который обязательно нужно выполнить до конца независимо от того, где реально найден корень.
Ограничения, слепые зоны и критика
Главное методическое ограничение — метод предполагает единственную линейную цепочку причин, тогда как у многих реальных проблем несколько независимых или переплетающихся причин одновременно; линейные «5 Почему» плохо справляются с такими случаями и рискуют выбрать только одну из нескольких настоящих причин, оставляя остальные неустранёнными.
Второе ограничение — качество результата целиком зависит от предметных знаний участников: если команда не знает процесс достаточно глубоко, она либо остановится на поверхностном ответе, либо предположит правдоподобную, но фактически неверную причинно-следственную связь, и метод не содержит встроенного способа это обнаружить.
Третье — метод не задаёт формального критерия остановки: команда сама решает, когда причина стала «достаточно корневой», и это решение может оказаться преждевременным (человеческий фактор вместо процессного) или избыточным (уход в причины, находящиеся вне зоны контроля организации).
Ещё одна задокументированная слепая зона — метод систематически подвержен предвзятости подтверждения (confirmation bias): команда, начав цепочку с определённой гипотезы, неосознанно подбирает такие ответы на «Почему?», которые ведут именно к ожидаемому выводу, и не замечает противоречащие факты. Отсюда же вытекает известная проблема невоспроизводимости результата — разные команды, разбирающие один и тот же инцидент методом «5 Почему», регулярно приходят к разным «корневым причинам», и каждая цепочка при этом выглядит логически связной сама по себе.
Показательный пример границ метода — история с Мемориалом Джефферсона в Вашингтоне, регулярно приводимая в литературе по анализу первопричин: команда обслуживания искала, почему памятник разрушается быстрее соседних монументов, и цепочка «Почему?» привела от частой мойки фасада к птичьему помёту, от помёта — к обилию пауков, от пауков — к мошкаре, слетавшейся на подсветку монумента по вечерам, и в итоге к решению заменить лампы на менее привлекательные для насекомых. История популярна именно как учебная иллюстрация «5 Почему», но по официальным отчётам конца 1980-х реальная картина была сложнее одной линейной цепочки: на состояние памятника одновременно влияли расход воды при мойке, химические моющие средства, кислотные дожди, загрязнение воздуха и поведение туристов. Это не опровергает метод, а прямо иллюстрирует его собственное ограничение: реальные инциденты редко имеют единственную линейную причинно-следственную цепочку, а красиво звучащая версия из пяти шагов может быть проще, чем действительность.
Из-за этого ограничения специалисты по анализу первопричин рекомендуют не использовать «5 Почему» как единственный инструмент для сложных, многофакторных инцидентов: метод хорошо подходит для быстрого разбора относительно простых, линейных проблем, но для ситуаций с несколькими параллельно действующими причинами (как в примере с Мемориалом Джефферсона) его стоит дополнять диаграммой Исикавы (fishbone diagram), которая изначально строится как разветвлённая структура факторов, а не одна цепочка.
Типовые ошибки
Ошибка 1: Останавливаться на симптомах.
Первое «Почему?» получает ответ вроде «потому что сотрудник ошибся» — и на этом цепочка обрывается, хотя это симптом, а не причина.
Как избежать: Проверять каждый ответ вопросом «это уже то, что можно изменить в процессе, чтобы проблема не повторилась, или это ещё одно следствие чего-то более глубокого?» — и продолжать, пока ответ не станет процессным.
Ошибка 2: Искать виноватого, а не процессную причину.
Цепочка вопросов явно или неявно сводится к «кто виноват», а не «что не так с процессом» — даже если формально доходит до пятого «Почему?», по факту решение — наказать человека, а не изменить систему.
Как избежать: На каждом шаге, где ответ называет конкретного человека, спрашивать следующее «Почему?»: «а что в процессе позволило/вынудило его так поступить?» — и идти дальше именно оттуда.
Ошибка 3: Не проверять логическую связность цепочки.
Ответы на последовательные «Почему?» звучат тематически близко, но не следуют друг из друга напрямую — итоговая «корневая причина» логически не объясняет исходную проблему.
Как избежать: На каждом шаге явно проверять: «если бы этой причины не было, случилась бы проблема?» — если ответ не очевидное «нет», связь недостаточно строгая.
Ошибка 4: Отвечать предположениями вместо проверенных фактов.
Ответы формулируются как правдоподобные версии («наверное, дело в загрузке команды»), а не как факты, установленные проверкой процесса или данных.
Как избежать: Для каждого ответа спрашивать: «откуда мы это знаем?» — если единственный источник это чьё-то мнение, факт нужно сначала проверить, а не сразу продолжать цепочку.
Ошибка 5: Найти корневую причину и не довести до решения.
Команда доходит до системной причины, фиксирует её и на этом останавливается — конкретное действие, устраняющее причину, не формулируется и не внедряется.
Как избежать: Обязательно завершать разбор конкретным решением с ответственным и сроком, и отдельно продумывать, как проверить, что проблема действительно перестала повторяться.
Главное, что нужно знать
«5 Почему» (Сакити Тоёда, 1930-е; формализовано Тайити Оно в Производственной системе Toyota, 1950-е) — последовательные вопросы «почему?», ведущие от симптома к системной, процессной причине. Классический пример Оно — сварочный робот, остановившийся из-за отсутствия фильтра на маслонасосе, обнаруженного только на пятом шаге. Число «пять» — ориентир, не жёсткий протокол: важна не точная глубина, а дисциплина не останавливаться на первом удобном ответе, обычно указывающем на человека, а не на процесс. Каждый шаг обязан опираться на факты и логически прямо следовать из предыдущего — иначе итоговая «корневая причина» окажется такой же догадкой, как и промежуточные шаги.
План внедрения
Неделя 1: сформулировать проблему фактами
Чётко и без обвинений описать, в чём проблема — как её видит команда, как её видят клиенты, каковы наблюдаемые симптомы. Собрать команду людей, реально знающих процесс.
Неделя 2: пройти цепочку «Почему?» до процессной причины
Последовательно задавать «Почему?», на каждом шаге проверяя логическую связность (если причина А, то следствие Б?) и фактическую опору ответа, пока причина не станет процессной, а не человеческой.
Неделя 3: сформулировать и проверить решение
Определить конкретное изменение процесса, устраняющее найденную причину. Проверить: устранение действительно предотвратит повтор, а не только смягчит текущий случай.
Неделя 4: внедрить и проконтролировать
Реализовать изменение процесса и убедиться, что проблема не повторяется — по факту, а не по ощущению.
Далее: закреплять как привычку команды
Использовать технику при каждом значимом инциденте регулярно, а не как разовое мероприятие — дисциплина цепочки вопросов вырабатывается практикой.
Как реализовать этот план с помощью фрейма «5 Почему» в OrgDevTools
Фрейм — две вкладки: «5 почему» и «Итоги» с вычисленным вердиктом.
На вкладке «5 почему»: карточка «Проблема (факты, без обвинений)» — сюда вносится формулировка из недели 1 плана; затем пять последовательно расположенных карточек «Почему 1»–«Почему 5», визуально соединённых стрелками — каждая заполняется ответом на предыдущий шаг (неделя 2 плана); далее карточки «Корневая причина» и «Решение» рядом (неделя 3).
Вкладка «Итоги» вычисляет вердикт по стадиям заполнения: проблема не сформулирована → предложение начать с нее; проблема есть, цепочка не начата → предупреждение начать цепочку; часть «Почему?» заполнена → фрейм явно показывает, сколько шагов из пяти пройдено, и напоминает не останавливаться на симптоме (прямая защита от ошибки 1); цепочка пройдена, но корневая причина не сформулирована → отдельное предупреждение; причина найдена, но решения нет → предупреждение (прямая защита от ошибки 5); все поля заполнены → зелёный вердикт с текстом решения. Кнопка «Создать задачу →» формирует задачу на внедрение решения корневой причины — соответствует неделе 4 плана.