문서요약 - 원인-결과 다이어그램 by Kniberg

제목: 원인-결과 다이어그램(Cause-effect diagrams)

저자: Henrik Kniberg, 스웨덴

문서유형: 업체(http://www.crisp.se/)의 기술 문서(총 18페이지), 2009년

 

근본 원인 분석을 수행하는 실용적 방법인 원인-결과 다이어그램에 대하여 기술한 자료

---

 

증상이 아니라 문제를 해결하라

• 종종 증상이 나타나는 곳과 실제 원인이 있는 곳이 완전히 다를 수 있음. 더 깊이 파지 않고 단지 증상만을 해결하면 문제가 나중에 또 다른 모습으로 나타날 가능성이 높다.
• 문제의 근본 원인(root cause)을 찾지 않는 한 문제를 수정하려는 대부분의 노력이 헛되거나 심지어 역효과(counterproductive)를 낳음

 

예1) 문제: 내 침실에 연기가 있음

나쁜 솔루션: 창문을 열고 다시 잠을 자러 감

좋은 솔루션: 연기 소스를 찾아서 해결한다(지하실에서 화재가 발생, 불을 끄고 애초에 무엇이 화재를 야기했는지 찾음, 다음에는 일찍 경보가 울리도록 화재 경보기를 설치).

 

예2) 문제: 서버에서 메모리 누수(Memory leak)

나쁜 솔루션: 추가 메모리를 구매함

좋은 솔루션: 메모리 누수의 원인을 발견하고 수정한다. 미래의 새로운 메모리 누수 발견을 위한 테스트를 구현한다.

 

“A3 Thinking” 또는 “Lean Thinking”

• 도요타의 문제 해결 접근 방법인 “A3 thinking”은 문제 해결 노력으로부터 나온 지식을 캡쳐하기 위해 A3 용지를 사용하며, 솔루션을 제안하기 전에 문제의 근본 원인을 분석하고 가시화하는데(A3 용지의 좌측 절반에 표현) 많은 시간을 투자한다.
• 원인-결과 다이어그램은 근본 원인 분석을 하는데 쓰이는 여러 방법 중 하나이며, 가치흐름지도(value stream maps), 이시카와 다이어그램(어골도) 같은 다른 방법들도 존재한다. 아래 A3 샘플은 좌측 상단에 가치흐름지도와 좌측 하단에 원인-결과 다이어그램을 포함하고 있음

[A3 문제 해결 예]

 

원인-결과 다이어그램(Cause-effect diagrams)

• 원인-결과 다이어그램은 근본 원인 분석을 수행하는 간단하고 실용적인 방법으로 모든 종류의 문제(기술적, 조직적)를 이해하고 해결하는데 사용됨
• 원인-결과 다이어그램은 상당히 직관적(intuitive)이고 자명하다(self-explanatory)는 장점을 가짐(특히 어골도와 비교했을 때). 또한 악순환의 강화 루프가 드러난다는 장점도 있음

 

원인-결과 다이어그램 사용의 기본 프로세스

①     문제(신경이 쓰이는 건 뭐든지)를 선정하고 기술한다.

②     비즈니스에의 영향(즉, 해당 문제가 야기하는 가시적인 피해)를 파악하기 위해 “위쪽으로 추적(trace upwards)”

③     근본 원인(들)을 찾기 위해 “아래쪽으로 추적(trace downwards)”

④     악순환(다이어그램에서 원형의 경로)을 식별하고 강조함

⑤     작성된 다이어그램을 정제하고 명확하게 하기 위해 앞 단계들을 여러 차례 반복함

⑥     어떤 근본 원인을 다룰지 그리고 어떻게 다룰지를 결정(즉, 어떤 대책을 구현할지)

 

차후 후속 조치(follow-up)에서는 구현된 대책이 효과를 발휘하는지 확인하고, 그렇지 못한 경우 그 이유를 분석하고, 이렇게 얻어진 새로운 지식에 기반하여 다이어그램을 업데이트하고, 다른 대책을 시도한다.

 

 

 

원인-결과 다이어그램 예1: 긴 출시 사이클(Long release cycle)

 

항상 데드라인을 못 맞추는 문제가 있음(즉, 항상 계획 일자보다 늦게 릴리즈가 일어남)

 

문제는 목표(goal)와 충돌할 때 진짜 문제가 되므로, 먼저 목표를 정의하고 이 목표와 관련 해당 문제의 영향에 대하여 생각함(즉, 가시적 피해를 식별할 때까지 일련의 “so what?” 질문을 던진다). 이 예에서 목표가 고객을 기쁘게 하고 회사 수입을 최대화하는 것이라고 가정하면 아래와 같은 대화가 일어날 수 있다. 

Q: “릴리즈가 지연되면 누가 신경을 쓰나? 그 영향은 무엇인가? A: “지연이 우리의 릴리즈 사이클을 길게 만든다” Q: “그래서?” A: “그게 우리의 수입이 지연되게 하고 이는 현금 흐름을 엉망으로 만든다. 또한 고객을 잃을 수도 있다. 고객들은 참을성이 없고 필요 이상 기다리는 걸 싫어한다.

 

이런 대화가 오가면서 다이어그램에 아래와 같이 상자와 화살표가 추가됨. 일반적으로 문제의 영향(consequences)을 식별할 때 애초의 문제 기술서로부터 위쪽으로 향하지만, 이것이 엄격한 규칙은 아니다.

 

위에서 보다시피 ‘지연된 릴리즈’ 보다는 ‘수입 지연’과 ‘고객 감소’가 진짜 문제임. 이 시점에서 아래와 같은 3가지를 고려해야 함

1.      고객 감소 또는 수입 지연을 야기하는 다른 이슈들이 존재하는가? 존재한다면 지연된 릴리즈가 가장 큰 원인인가 아니면 관심을 주어야 할 또 다른 곳이 있는가?

2.      문제를 정량화할 수 있는가? 얼마나 많은 수입을 잃었는가? 얼마나 많은 수의 고객을 잃었는가? 이 데이터는 해당 문제를 해결하는데 얼마나 많은 노력을 투입할 가치가 있는지 평가하는데 도움을 줌

3.      해당 문제가 해결되었을 때 그걸 어떻게 알 수 있는가? 요란한 춤을 추며 들어온 컨설턴트가 자신이 문제를 해결했노라고 알릴 때 이것이 허풍인지 어떻게 알 수 있는가?

 

문제의 영향을 분석하느라 일정 시간을 보낸 후에는 이제 문제 뿌리를 향해 아래로 파 내려가야 할 차례임. 이는 일련의 “why” 질문을 던짐으로써 수행된다(즉, 잘 알려진 “five whys” 기법) 

Q: “왜 릴리즈가 지연되는가?” A: “범위가 계속 증가하기 때문에” Q: “왜?” A: “고객이 새로운 기능을 가져와 현 릴리즈에 추가해 줄 것을 고집함. 또한 우리가 낮은 우선순위 기능을 대신 제거하려 해도 이를 거부함” Q: “왜? 다음 릴리즈까지 그 기능들을 미루면 안 되는가?” A: “릴리즈 사이클이 너무 길기 때문임. 새로운 요구가 릴리즈가 완성되기 전에 등장”

 

위의 대화는 단지 3개의 why만을 포함하지만 어느 정도 상황 파악은 된 셈. 이 대화로부터 아래와 같은 다이어그램이 구축됨

 

위 그림에서 악순환의 강화 루프가 빨간 화살표로 표시되어 강조됨. 되풀이하여 발생하는 문제는 거의 항상 이런 루프와 관련되지만 이걸 찾아내는데 시간이 꽤 걸릴 수 있음. 이런 루프를 찾아내는 것이 문제를 효과적이고 영구적으로 해결할 가능성을 크게 증가시킨다. 

우리 목표가 해당 문제의 근본 원인을 식별하는 것인데 첫 번째 시도에서는 중요한 원인(들)을 놓치기 십상이므로 다시 돌아가서 추가적인 “why” 질문을 던진다. 

 

Q: “왜 릴리즈 사이클이 긴 것인가? 지연된 릴리즈가 유일한 원인인가?” A: “실제는 지연이 없어도 우리의 계획된 릴리즈 사이클이 꽤 길다.” Q: “계획된 릴리즈 사이클이 얼마나 긴가?” A: “매 분기당 한번씩” Q: “그럼 왜 그렇게 긴 것인가?” A: “릴리즈가 비용이 많이 들고 복잡한 일이므로.” Q: “왜?” A: “각 릴리즈마다 많은 것들이 포함되고 모두가 수작업이므로”

 

 

위 그림 좌측에 또 다른 악순환(빨간 화살표)가 등장함. 릴리즈 간의 시간 간격이 긴 것은 각 릴리즈에 많은 것들이 포함됨을 의미하며(즉, 릴리즈가 어렵고 고비용의 작업이다), 이것이 릴리즈를 자주 하는 것을 주저하게 만든다.

 

아래와 같이 두 개의 근본 원인을 식별하고 그 대책을 제안함

근본 원인(Root cause)	대책(Countermeasure)
릴리즈 자동화 결여	릴리즈 자동화를 구현
낮은 우선순위 기능이 제거되지 않음	고객이 릴리즈에 신규 기능 추가하고자 하면 상응하는 규모의 낮은 우선순위 기능을 제거할 경우에만 이를 허용하는 규칙을 고객과 협상한다.

 

어떤 이슈가 근본 원인인지 결정하는 엄격한 규칙은 없지만 아래와 같은 일부 지표(indicators)는 존재함

• 밖으로 나가는 화살표만 있고 들어오는 화살표는 없는 이슈
• 더 이상 파고드는 것이(즉, 계속 “why” 질문을 던지는 것이) 의미 없는 이슈
• 우리가 다룰 수 있는(그리고 아마도 문제에 긍정적인 영향을 크게 주는) 이슈

 

“five whys” 기법은 통상적으로 약 5개의 “why” 질문을 던지면 근원(root)에 도달할 수 있으므로 그렇게 불림. 우리가 너무 일찍 질문을 중단하는 경향이 있으므로 계속 파고드는 이런 분석이 필요함 

애초에 식별되었던 문제(‘지연된 릴리즈’)는 실제 문제도 아니고 근본 원인도 아니며 단순히 증상(symptom)에 지나지 않음에 주의할 필요가 있음. 이런 증상은 진짜 문제를 찾기 위해 위쪽으로 파고들고 근본 원인을 찾기 위해 아래쪽으로 파고드는 일종의 손잡이(매개체)로 사용됨 

 

이런 타입의 분석 없이는 성급한 결론을 내리고 비효과적이고 역효과를 내는 변경을 실행하게 된다. 예를 들어, 이 문제가 사람 수와는 아무 관계가 없음에도 인력을 추가하거나 또는 현 인센티브 모델과 아무 관련 없음에도 이를 변경함(정시에 릴리즈하면 직원에게 보상을 하고 늦게 릴리즈하면 처벌을 내림).

 

원인-결과 다이어그램 생성 및 유지보수 관련 현실적 이슈

• 혼자 작업: 다이어그램을 혼자 생성할 때는 Visio나 파워포인트 같은 다이어그래밍 도구에 직접 작업하는 것이 간편함
• 소규모 그룹(2~8명)으로 작업: 화이트보드나 플립차트 앞에 모여서 포스트잇에 이슈를 적고 이들을 연결하는 화살표를 그려 넣음(아래 사진 예). 포스트잇 위치를 바꾸면서 화살표를 쉽게 지우고 다시 그릴 수 있는 화이트보드가 선호됨. 오로지 한 사람이 모든 그리기를 하지 않고 모두가 돕도록 해야 함. 회의 후에는 그 결과를 높은 해상도의 사진으로 찍어서 모두에게 전송한다.
• 대규모 그룹(9~30명)으로 작업: 그룹을 작은 팀으로 분할하고, 각 그룹은 하나의 특정 문제에 집중한다. 동일한 문제에 대해 여러 팀이 독립적으로 작업하는 것도 괜찮음(모두 같은 결론에 도달할 수도 있고 또는 다른 결론이 나올 수도 있으며 어느 경우든 흥미로움). 각 팀은 화이트보드/플립차트와 포스트잇을 가지고 작업함. 일정 시간 간격으로 모두를 불러모아 식견을 공유한다.
• 다이어그램의 장기 유지보수: Visio나 파워포인트 같은 도구에 다이어그램을 보관하고, 워크숍이 있을 때 마다 주된 목적이 다이어그램의 발표인지 아니면 업데이트인지를 판단. 발표의 경우 프로젝터를 사용하여 도구에 저장된 다이어그램을 그대로 보여줌. 업데이트가 목적인 경우 도구에 있는 다이어그램을 포스트잇과 화살표로 화이트보드/플립차트 상에 복제함. 이걸 가지고 여러 사람이 효과적으로 협업할 수 있으며, 회의 후에 그 결과를 전자 도구의 다이어그램에 반영하여 맞춘다. 

 

[포스트잇과 화살표로 작성된 원인-결과 다이어그램 예]

 

주의할 사항

• 때때로 너무 많은 화살표와 상자로 다이어그램이 가독이 어려울 정도로 지저분해질 수 있는데, 이 경우 단순화 시켜야 함. 아래와 같은 방법들이 사용됨
  - 중복 상자(즉, 다이어그램에 그다지 가치를 더하지 않는 상자)를 제거함
  - ”넓이 우선(breadth first)” 보다는 “깊이 우선(depth first)”에 집중함. 문제의 모든 원인을 쓰지 말고 가장 중요한 한 두 개만 써서 깊게 파고 들어간다.
  - 불완전(imperfection)을 받아들인다. 이런 다이어그램은 절대 완벽해지지 않음
  - 지금의 문제 영역이 너무 광범위할 수 있으므로 더 좁게 정의된 문제에 한정한다.
  - 다이어그램을 여러 조각으로 분할한다.
• 이런 타입의 원인-결과 다이어그램은 의도적으로 단순하며 얼굴을 맞댄 의사소통을 대체하지 않는다. “완벽한” 다이어그램도 그걸 이해하는데 박사 학위가 요구된다면 별로 쓸모가 없음에 유의하자.
• 문제 해결은 모든 문제가 시스템적 문제(systemic problems)라 여길 때 가장 효과적이므로 특정인을 비난하는 태도를 피한다. 실제 심각한 문제를 초래하는 서투른 사람들이 존재하지만 이 또한 여전히 시스템적인 문제이다(즉, 시스템이 서투른 사람들을 서투르지 않다고 가정하거나, 극도로 서투른 사람들을 안으로 들여보내거나, 서투른 사람들이 덜 서투를 수 있도록 도움을 주지 못하거나 등). 

 

요약: 왜 원인-결과 다이어그램을 사용하는가

• 공통의 이해를 생성함: 팀 기반 문제 해결은 매우 효과적이지만 문제에 대한 공통의 이해를 요구함. 원인-결과 다이어그램은 이를 돕는 매우 실용적인 협업 기법이다.
• 문제가 어떻게 비즈니스에 영향을 주는지 식별함: 이는 가장 중요한 문제에 먼저 집중할 수 있게 해 주고, 주제나 상황을 잘 아는 상태에서 의사결정을 내리게 해준다.
• 근본 원인을 찾음: 이는 특정 변경(changes)의 영향을 최대화할 수 있게 해준다.
• 악순환(부정적인 강화 루프)을 찾음: 이런 악순환을 깨부수거나 또는 긍정적인 강화 루프로 바꿀 수 있게 해준다(즉, 나쁜 것이 더 나쁜 것으로 이어지는 일이 반복되는 대신에 좋은 것이 더 좋은 것으로 이어질 수 있게 함).