문제 정의 · 프레이밍

문제 정의란?

문제 정의가 실제로 바꾸는 것은 아이디어의 질이 아니라 예산과 담당 부서입니다. '영업 실적이 나쁘다'를 역량 문제로 규정하면 교육팀이 받고, 리드 부족으로 규정하면 마케팅팀이 받으며, 가격 경쟁력 문제로 규정하면 상품기획이 받습니다. 같은 숫자를 놓고도 누가 책임지고 무엇으로 성과를 측정할지가 이 문장 하나에서 갈립니다. 회의 첫 30분에 정의를 합의하지 못하면 남은 두 시간은 각자 다른 문제를 푸는 시간이 됩니다.

정의 문장은 유형을 나눠 보면 다루기 쉬워집니다. 증상형('클레임이 월 18건'), 격차형('목표 대비 12%p 미달'), 기회형('경쟁사가 못 가진 데이터가 우리에겐 있다')이 있는데, 실행 조직에 넘길 문서라면 격차형이 가장 잘 굴러갑니다. 기준선과 목표치가 문장 안에 들어 있어 언제 끝났다고 말할지가 정해지기 때문입니다. 폭도 한 번은 시험해 봐야 합니다. 같은 문제를 한 단계 위로 올려 적고 한 단계 아래로 내려 적어 보면 현실적으로 손댈 수 있는 층이 어디인지 드러납니다.

인접 도구와의 경계도 정리해 두는 편이 좋습니다. 5 Whys는 이미 정해진 문제의 원인을 파고드는 도구이고, 이슈 트리는 정의된 문제를 쪼개는 도구입니다. 프레이밍은 그보다 앞서 어느 구덩이를 팔지 고르는 단계입니다. 'How Might We' 형식으로 후보 문장을 여러 개 써 보는 이유도 여기 있습니다. 한 문장에 정답이 들어 있어서가 아니라, 문장을 바꿀 때 따라 나오는 해답의 목록을 눈으로 비교하려는 것입니다.

현장에서 가장 흔한 사고는 해답을 문제로 위장하는 일입니다. '교육을 늘려야 한다', '시스템을 바꿔야 한다'는 이미 답이라서, 이렇게 적힌 기획서는 검토 단계에서 대안이 한 건도 나오지 않습니다. 반대로 재정의를 취미처럼 반복하다 착수가 두 달씩 밀리는 팀도 있으므로 후보 문장 3~5개, 한 세션으로 끊고 채택한 정의를 문서 첫 줄에 박아 두는 편이 낫습니다. 경영진이 던진 문제를 그대로 받아 적는 것도 위험합니다. '이 정의로 풀면 무엇이 빠지는지'는 한 번쯤 되물어야 합니다.