Categories: companyJapan

일본회사에서 중요한 “나제나제”의 작성법 완벽 정리

나제나제(なぜなぜ) 분석법은 문제의 근본 원인을 철저히 파악하여 재발을 방지하는 강력한 문제 해결 기법입니다. 이번 포스팅에서는 나제나제의 개념, 효과적인 작성 방법, 그리고 실무 적용 시 주의할 사항을 자세히 정리해 드리도록 하겠습니다.

Toggle

나제나제 분석이란

먼저 일본어로 ‘나제(なぜ)’라는 단어는 ‘이유(Why)’라는 의미입니다.

단어의 의미를 보시면 아시는 바와 같이 나제나제 분석 기법은 도요타 생산 시스템(TPS)에서 유래한 문제 해결 방법론으로, 현상의 표면적 원인에 대한 질문을 반복하여 심층적 근본 원인을 규명하는 데 목적을 둡니다. 이는 단순한 문제 해결을 넘어 시스템 전반의 개선을 도모하며 질문을 5회 반복함으로써 문제의 핵심을 찾아내는 분석 방법입니다.

나제 나제 작성 방법

이론상으로 이유(나제)를 5회 반복해서 물어보면 되니 간단하다고 방심하시는 분들도 많은데 현상에 대해서 개선해야 되는 포인트까지 찾기 이유(나제)위해서 를 반복해서 묻는 것은 의외로 너무너무 어려운 일이므로 초반부터 아래의 주요한 작성 방법들을 참고하시고 작성해 주시기 바랍니다.

“문제점”의 설정

먼저 가장 중요한 것은 분석 타깃이 되는 “문제점”을 정의하는 부분으로 문제점을 정의할 때 반드시 구체적으로 정의해야 합니다.

예를 들어 ‘실수했다’, ‘낮다’, ‘나쁘다’등 추상적인 표현이 아닌 무엇이 어느 정도 였는지를 구체적으로 정의 하지 않으면 이후에 정확한 분석과 연결이 되지않을수 있는데 구체적인 예시로는다음과 같습니다.

안 좋은 예시	– 고객사에 보내는 자료를 깜빡했다 – 작년 판매가 목표대비 낮았다 – 팀의 분위기가 나쁘다
잘된 예시	– 고객사 A사에 메일로 보낸 BB자료에 문제가 있었다 – 작년 판매가 목표 AA엔에 대비 하회했다 – 최근 2년간의 팀내의 퇴직율이 전체 평균보다 높았다

위의 나쁜 예시들을 기준으로 공통적으로 언급할 수 있는 부분은 구체성이 부족한 부분입니다. ‘무엇을 어떻게 깜빡했다라든지’, ‘목표가 어느정도 낮았는지’, ‘나쁜 분위기라는 것이 구체적으로 어떤 상태인지’ 등으로는 이후에 구체적인 원인 파악이 어려우므로 구체적으로 잘된 예시와 같이 구체적으로 정의해주시기 바랍니다.

개선 가능한 근본 원인을 찾아냄

설정한 ‘문제점’의 원인들은 개수에 상관없이 모두 도출해야 하는데 요인을 리스트업 할 때에는 단순한 요인들을 나열하고 있는 것은 아닌지를 주의를 해야 합니다.
어떠한 원인이 있었기 때문에 문제현상이 발생했었다는 관계를 유지하며 논리적으로 요소들을 분석해야 하는데 예시로 “아이스크림으로 손이 더러워짐”이라는 ‘문제점’을 기반으로 분석한 근본 원인 전개는 다음과 같습니다.

위와 같이 전개해 가면서 개선책과 이어지는 원인을 작성해 나가야 하는데 즉 문제 현상의 요인이 되는 요소를 발굴하고 또 그 이유와 요소를 발굴하는 식으로 반복해서 개선이 가능한 근본 원인을 찾아나가는 것입니다.

해결책 제시가 목표

‘이것이야 말로 문제점의 원인이다!’라고 말할 수 있는 요소가 모였으면 이제 해결책을 고민해야 합니다.
해결책을 제시할 때는 “그것을 하면 정말로 문제 현상이 해결되는지?”, “특정한 사물/사람에 의지 하는 해결책은 아닌지?”등을 유념한 해결책 제시를 목표로 해야합니다.

나제나제 분석시의 NG모음

나제 나제 분석법에 많은 시간을 투자했음에도 불구하고 요령을 제대로 파악하지 못하면 정확한 해결책을 도출하는 데 어려움을 겪을 수 있습니다. 이러한 실수를 피하기 위해서 일반적으로 자주 발생하는 작성 시 오류와 그로 인한 실패 사례를 아래와 같이 정리해 보았습니다.

문제점 정의가 애매한 경우

먼저 ‘문제점’을 정의하는 시점에서 해결해야 하는 문제를 얘매하게 정의하면 깊이 파고들 수가 없습니다. 무엇이 어느 정도로 어떻게 잘못된 것인지의 ‘문제점’이 발생한 현상을 정확하게 정의하고 나서부터 분석을 시작해야 합니다.

1)’문제점’ 정의의 잘못된 예시
문제점 → “거래처에 보내는 자료를 잘못 보냈다”

2) 잘못된 포인트
거래처가 어디인지?
송부방법이 무엇이었는지?
어디를 어떻게 잘 못했는지?

3) 잘못된 포인트 정정 후의 문제점 정의
A협회에 우편으로 보낸 영수증을 다른 B협회의 영수증으로 잘못 보냈다.

원인과 결과의 관계로 되어 있지 않은 경우

왼쪽의 ‘문제점’에 대해서 오른쪽의 요소가 원인의 형태로 되어 있지 않으면 단순한 브레인스토밍 같은 토론 형태가 되어 문제의 해결이라고 하는 중요한 방향성은 놓쳐 버리게 됩니다.

반드시 원인이 있었기 때문에 ‘문제점’이 발생했다고 하는 논리구조가 무너지면 본질적인 원인을 찾을 수가 없게 되므로 한 개 한 개의 요인을 작성할 때는 신중한 작성이 필요한데 특히 아래와 같이 구체적이지 않은 원인은 사용 금지입니다.

1) 원인 결과 관계가 잘못된 예시
문제점 : 메일의 수신처에 실수가 있었다 →(나제1) 일반적으로 작성자는 이전부터 실수가 많았다

2) 잘못된 포인트
일반적인 경향은 ‘문제점’과는 관계없고 구체적인 요인이 아님

3) 잘못된 포인트 정정 후의 문제 현상
문제점 : 메일의 수신처가 잘못되었다 →(나제1) PC에 있는 이전 정보를 복사 후 붙여 넣기 하였다

사람을 원인으로 규정해버리는 경우

‘사람을 의심하기 전에 장치나 구조를 의심해라’라는 말이 있습니다.
무엇인가 문제가 일어났을 때는 원인을 “OO 씨의 업무태도가~”등의 사람의 문제로 원인을 결정해 버리는 경우들이 종종 있습니다. 만일 그렇게 되는 경우 특정인의 사과로 문제는 마무리되고 실제 조직적으로는 아무것도 성장하지 않습니다.

“완벽한 조직 내에는 반드시 완벽한 장치나 시스템들이 존재합니다.”

예를 들어 마트의 계산원이 손님으로부터 건네받은 돈을 직접 금고에 먼저 넣어버리면서 건네받은 금액을 알 수 없게 되고 문제가 발생될 수 있습니다. 그런데 이런 대책으로 작업자에게 매뉴얼을 보여주고 주의를 시킨다고 하더라도 재발의 가능성 막을 수는 없을 것입니다.

위와 같은 경우의 해결책으로서 만일 손님에게 건네받은 돈을 두는 트레이 등의 장소를 정하고 계산 시 계산원이 그곳에 돈을 두는 등의 절차를 정한 절차서를 금고 주변에 붙여 놓는 경우 조직 구조 적으로 해결이 가능한데 이런 해결책을 제시해야 하고 다른 예제는 다음과 같습니다.

1) 특정인을 원인으로 하는 잘못된 예시
문제점 : 메일의 수신처에 실수가 있었다 →(나제1) 작업자가 주의를 게을라했다.

2) 잘못된 포인트
사람이 아닌 시스템에 문제가 없는지를 분석할 것

3) 잘못된 포인트 정정 후의 문제 현상
문제점 : 메일의 수신처에 실수가 있었다 →(나제1) 메일 수신처 선정에 대한 가이드가 없었다.

문제점 현장을 고려하지 않은 경우

문제점의 정의부터 해결책 설정까지 현장에 전혀 있지도 않았고 검증도 되지 않았다만 작성자가 정확하게 나제나제를 분석할 수 없습니다. 그렇기 때문에 반드시’문제점’이 발생한 상황을 검토 및 재현할 수 있는 상태에서 분석을 해야 합니다.

1) 현장을 고려하지 않은 잘못된 예시
문제점 : 팀의 이직률이 높다 →(나제1) 채용 목표 설정이 잘못되었다

2) 잘못된 포인트
현재 사원들의 실정에 대해서 파악을 하지 못했다

3) 잘못된 포인트 정정 후의 문제 현상
문제점 : 팀의 이직률이 높다 →(나제1) 타 팀 대비 연봉이 낮았다

나제나제 분석 적용 예제

다음과 같이 “어느 회사 내에서 프로젝트 마감 기한이 자주 지켜지지 않는다”고 하는 문제현황을 상정하고 다음과 같이 나제나제분석을 전개하고 근본원인을 정리해 보았습니다.

문제점	나제1/원인	나제2/원인	나제3/원인	나제4/원인	나제5/원인
“회사 내에서 프로젝트 마감 기한이 자주 지켜지지 않는다.”	왜 프로젝트 마감 기한이 자주 지켜지지 않는가?	왜 개발 일정이 자주 지연되는가?	왜 예상보다 많은 버그가 발생하는가?	왜 초기 설계 단계에서 요구사항이 명확하지 않은가?	왜 기획팀과 개발팀 간의 의사소통이 부족한가?
“회사 내에서 프로젝트 마감 기한이 자주 지켜지지 않는다.”	개발 일정이 자주 지연되기 때문이다.	개발자들이 예상보다 많은 버그를 수정해야 하기 때문이다.	초기 설계 단계에서 요구사항이 명확하지 않아서, 개발 도중 자주 변경되기 때문이다.	기획팀과 개발팀 간의 의사소통이 부족하고, 사전 조율이 충분히 이루어지지 않기 때문이다.	프로젝트 초기에 명확한 요구사항 정의 회의가 없고, 문서화도 제대로 이루어지지 않기 때문이다.