Contents
감수의 글
그 강력함과 즐거움은 어디에서 올까? 바꿔 말해, 도요타 방식, 린 방식의 핵심이 무엇인가?
도요타 생산방식의 아버지 중 한 사람인 오노 바이이치는 직원들의 지속적인 프로세스 개선을 촉구하며 이런 말을 했다고 한다. "한 달 동안 표준을 바꾸지 않으면 회사에서 돈을 훔치고 있는 것이다." 명백히 도요타의 표준은 따르라고 있는 것이 아니고 개선하라고 있는 것이다.
그런데 대부분의 회사는 도요타의 표준을 따르려고만 한다. 도요타 방식의 초보들은 도요타 방식이 뭐냐는 질문에 '재고를 없애는 것'이라고 답한다고 한다. 칸반, 포카요케, 안돈 등의 널리 알려진 기법들을 언급하면서 말이다. 하지만 고수들은 '끊임없이 문제를 해결하고 개선하는 것'이라고 답한다고 한다. 실제로 도요타 방식 도입에 실패한 회사들은 그 철학적 수용보다 형식적이고 외형적인 수용에 집중했다. 칸반 방식이 눈에 띄네. 저 인프라를 도입하면 성공하겠지? 많은 회사가 이런 식으로 도요타 방식을 베끼려고 노력했지만 대부분 실패했다.
도요타에서 1년간 구현되는 개선 아이디어 개수는 1백만 개라고 한다. 제안되는 아이디어 개수가 아님에 주의하자. 하루에 3000개의 개선 아이디어가 실제로 구현된다. 동종 업계의 10배에서 1000배 수준이라고 한다. 칸반 시스템을 얼마를 들여 도입하냐가 중요한 것이 아니다.
도요타 방식의 핵심은 문제를 빨리 드러내고 계속 개선한다는 것이다. 어떻게 문제를 드러내는가? 불필요한 것들을 제거한다 (예컨대 재고를 줄여서 흐름이 민첩하고 슬림해지도록 한다). 그러면 문제가 발생할 때 쉽게 알 수 있다. 깨지기 쉬운 것fragile이 애자일agile한 것이다. 도요타는 이런 식으로 문제가 쉽게 노출되도록 하고 끊임없이 개선과 문제 해결을 해나간다.
서론
이 책은 7장으로 구성되어 있으며, 각 장은 7가지 린 원칙과 각 원칙을 애자일 실천방법으로 바꾸는 사고 도구를 주제로 다룬다.
1. 낭비를 제거하라
낭비는 제품에 가치를 부가하지 못하는 모든 것을 일컫는데, 이때 가치란 고객이 인지하는 것을 말한다. 린 사고에서 낭비의 개념은 높은 장애물이다. 만약 컴포넌트가 먼지가 쌓인 채 선반 위에 놓여 있다면 그것이 바로 낭비다. 만약 개발 주기에 따라 요구사항을 책으로 정리했는데 거기에 먼지가 쌓인다면 그것도 낭비다. 개발자가 당장 필요한 기능보다 많이 코딩한다면, 그것도 낭비다. 제조 과정에서 제품을 이리저리 끌고 다니는 것도 낭비다. 제품 개발에서 개발 과정을 한 집단에서 다른 집단으로 넘기는 것도 낭비다. 이상적인 것은 고객이 원하는 바를 알아내고 정확하게 그들이 원하는 것을 개발, 생산해서 거의 즉시 전달해 주는 것이다. 무엇이든지 고객의 필요를 빨리 만족시키지 못하게 방해하는 것은 모두 낭비 요소다.
2. 배움을 증폭하라
개발이 새로운 발견을 연습하는 과정이라면 생산은 변동 줄이기를 연습하는 과정이다. 이런 이유 때문에, 개발을 하기 위한 린 접근법은 린 생산 실천방법과는 꽤 차이가 있다. 개발이 조리법을 만드는 것이라면 생산은 요리를 만드는 것과 같다. 조리법은 어떤 것이 동작하는지에 대한 감각과 상황에 맞게 재료를 이용하는 능력을 갖춘 숙련된 주방장에 의해 만들어진다. 하지만 위대한 주방장조차새로운 조리법을 반복해 보면서 여러 가지 변형을 시도하는 과정을 거쳐 맛이 더 좋고 요리하기 쉬운 조리법을 만든다. 주방장도 처음 시도에서 완벽한 조리법을 기대하지 않는다. 그들은 배우는 과정의 일부분으로 한 가지 테마에 대해서 몇 가지 변형을 일으켜 본다. 소프트웨어 개발은 개발팀이 크고 결과가 조리법에 비해 훨씬 복잡하다는 도전이 있긴 하나, 이와 유사한 학습 과정으로 생각하는 것이 좋다. 소프트웨어 개발 환경을 개선하는 가장 좋은 방법은 배움을 증폭하는 것이다.
3. 가능한 늦게 결정하라
결정을 늦추는 개발 실천방법은 불확실성을 포함하고 있는 영역에서 효과적이다. 왜냐하면 이 방법은 선택에 기반을 둔 접근방법을 제공하기 때문이다. 불확실성에 마주하여 대부분의 시장경제는 미래가 가까워지고 예측하기 쉬워질 때까지 투자자들이 결정을 늦출 수 있또록 여러 가지 옵션을 개발한다. 추측이 아닌 사실이 바탕이 될 때 더 나은 결정을 할 수 있기 때문에 결정을 늦추는 것은 유용하다. 진화하는 시장에서는 설계의 선택사항을 열어놓는 것이 빨리 결정해 버리는 것보다 가치가 있다. 복잡한 시스템을 개발할 때, 결정을 늦추는 핵심적인 전략은 변화할 수 있는 능력을 시스템에 주는 것이다.
4. 최대한 빨리 납품하라
최근까지 소프트웨어를 신속히 개발하는 것은 가치가 없었다. 조심스럽게 진행해서 실수하지 않는 것이 더 중요해 보였다. 그러나 지금은 알려진 통념들 목록에 '품질이 더 가치 있다'와 함께 '속도가 더 가치 있다'도 넣어야 할 시점이 되었다. 신속한 개발은 장점이 많다. 속도 없이는 결정조차 미룰 수 없다. 속도 없이는 신뢰성 있는 피드백도 없다. 개발에서 발견 주기는 학습하는 데 매우 중요하다. 주기는 설계, 구현, 피드백, 개선으로 이루어진다. 이 주기가 짧을수록 더 많은 것들을 배울 수 있다. 속도는 고객이 어제 원했던 것이 아니라 지금 원하는 것을 얻도록 해준다. 또한 고객이 진짜로 원하는 것에 대해서 더 많이 알 때까지 결정을 미루도록 해준다. 가치 흐름을 가능한 한 압축하는 것이 낭비 요소를 줄이는 기본적인 린 전략이다.
5. 팀에 권한을 위임하라
가장 좋은 실행은 구체적인 사항이 제대로 되느냐에 달려 있으며, 그 일을 실제로 하는 사람이 그 누구보다도 구체적인 사항들에 대해 더 잘 알고 있다. 기술과 관련된 구체적인 결정을 할 때 좋은 성과를 내기 위해서는 개발자와 함께 해야 한다. 일선에 있는 사람들은 세세한 구체적인 지식과 많은 의견을 결합시킨다. 이들은 필요한 전문지식을 갖추고 리더의 지도를 받으면 기술에 관한 결정이나 프로세스에 관한 결정을 내릴 때, 누구보다 더 나은 능력을 발휘할 것이다. 결정은 늦게 내려지고 실행은 빠르기 때문에, 중앙에서 작업자들의 활동을 조정하는 것이 불가능하다. 따라서 린 실천방법은 작업을 계획하는데 당김 기법pull techniques을 사용하고 국지적으로 신호를 보내는 메커니즘local signaling mechanisms을 사용하여 작업자들이 어떤 것이 완료되어야 하는지 서로 알게 한다. 린 소프트웨어 개발에서, 당김 메커니즘은 일정한 간격으로 작업 소프트웨어를 점점 발전된 버전으로 만들기 위한 것이다. 현지 의사소통은 눈에 보이는 표, 일일 회의, 잦은 통합 그리고 포괄적인 테스트를 통해 하게 된다.
6. 통합성을 구축하라
사용자가 '그래! 이게 바로 내가 원하던 거야. 누군가가 내 마음에 들어왔다 간 것 같군!'이라고 생각할 때, 시스템은 통합성을 갖추었다고 인식된다. 시장 점유율은 제품의 인식 통합성perceived integrity을 나타내는 대략적인 수치이다. 왜냐하면 시장 점유율은 시간에 따른 고객의 인식을 측정하는 것이기 때문이다. 개념 통합성conceptual integrity은 시스템의 중심 개념이 유연하면서 총체적으로 응집력 있게 작동하는 것을 의미하며, 그것은 통합성을 인식시키는데 필수적인 요소이다. 소프트웨어에는 시간이 지나도 유용성을 유지해야 하는 추가적인 통합성이 요구된다. 소프트웨어는 전형적으로 미래에 적응하면서 품위 있게 진화해야 한다. 통합성을 지닌 완전한 소프트웨어는 구조가 일관되고, 목적에 대한 유용성과 적합성에서 높은 점수를 받으며, 유지보수가 가능하며 적응성과 확장성이 좋다. 한 연구에 따르면 통합성은 현명한 리더십과 적절한 전문적인 기술, 효과적인 의사소통, 그리고 건전한 규율에서 온다는 것을 보여준다. 프로세스, 절차, 측정으로는 충분히 대신할 수 없다.
7. 전체를 보라
복잡계에서 통합성이 있으려면 다양한 분야에 걸친 깊은 전문지식을 갖춰야 한다. 제품 개발에서 가장 처리하기 힘든 문제 중 하나는 어떤 분야(예를 들어 데이터베이스 혹은 GUI)라도 전문가는 전체 시스템의 성과에 초점을 맞추기보다는 자신의 전문성을 잘 보여주는 부분에 성과를 최대화하려는 경향이 있다는 점이다. 만약 자신의 분야에만 관심을 가지고 고집을 부리다 보면 개발 프로젝트 자체가 고전을 면치 못하기도 한다. 개인 혹은 조직이 전체적인 성과 대신 그들의 특화된 기여도에 따라 평가된다면, 부분 최적화suboptimization가 결과일 것이다. 이 문제는 두 조직이 서로 계약을 맺을 때 더 두드러진다. 왜냐하면 사람들은 본래 자기 회사의 성과를 높이고 싶어하기 때문이다. 큰 조직에서 부분 최적화를 피하는 방법으로 실행하는 것은 힘들고, 계약이 뒤엉킬 때에는 그 크기의 정도에 따라 더 어려워진다.
1장. 낭비를 제거하라
린 사고의 기원
도구 1: 낭비 찾아내기
도구 2: 가치흐름도 작성
상황 연습
2장. 배움을 증폭하라
소프트웨어 개발의 본질
도구 3: 피드백
도구 4: 반복
도구 5: 동기화
도구 6: 집합 기반 개발 방법
상황 연습
3장. 가능한 늦게 결정하라
동시 개발
도구 7: 대안적 사고
도구 8: 책임이 따르는 마지막 순간
도구 9: 의사결정
상황 연습
4장. 최대한 빨리 납품하라
도구 10: 당김 시스템
도구 11: 대기행렬 이론
도구 12: 지연 비용
상황 연습
5장. 팀에 권한을 위임하라
과학적 관리법을 뛰어넘어
도구 13: 자기결정권
도구 14: 동기 부여
도구 15: 리더십
도구 16: 전문 지식
상황 연습
6장. 통합성을 구축하라
통합성
도구 17: 인식 통합성
도구 18: 개념 통합성
도구 19: 리팩터링
도구 20: 테스트
상황 연습
7장. 전체를 보라
시스템적 사고
도구 21: 측정
도구 22: 계약
상황 연습
8장. 사용설명서와 제품보증서
주의-지시대로만 사용하시오
사용설명서
문제 해결 지침
제품보증서