TOC의 특징(?), 기본 이론(?)은 무엇일까요?

[gyehong park]

좋은 아침입니다. : )

그 동안 홍진님이 TOC를 IT쪽에 적용하고 싶다는 이야기는 많이 들었었는데, 그게 의미하는 것이 무엇인지는 잘 몰랐었습니다. 어제 홍진님과의 대화에서야 간신히 감을 잡았습니다. 

제가 알아들은 것은 TPS에서 나온 린 생산방식을 린 소프트웨어 개발로 가져올 수 있었는데, 왜 TOC는 TOC 소프트웨어 개발같은 것으로 만들어진 것이 없는가? 내일 발표도 이런 내용에 대한 홍진님의 생각을 담고 있는듯 보입니다.

TOC를 소프트웨어 개발에 적용하려고 할 때, 저에게는 애자일과 상당히 동떨어져 있는 것으로 보이고 있습니다. 저도 좀 당황스럽습니다. 저는 TOC 이론을 개발자가 꼭 알고 있어야 기본 이론으로 생각하고 있습니다. ^^;;; 그런데 막상 보다 적극적으로 도입하려고 하니, 많은 부분이 충돌하는 것처럼 보이고 있습니다.

지금 저는 TOC를 IT에 적용하기 위해서는 TOC의 특징과 기본 이론이 무엇인지를 분명하게 찾아내고, 이를 이해하는 것이 중요하다고 보고 있습니다. 이는, 어쨌든 저에게는 상당히 거리가 있어 보이기 때문에, 기본적인 것을 확실히 이해한 후에 많은 응용이 필요하다고 보이기 때문입니다.

일단 4가지가 일단 눈에 들어옵니다.

1. 전체 최적화를 해야한다.
2. 제약이론 : 제약 요소가 1~2가지가 있고, 이를 개선하는 것으로 전체가 개선된다.
3. TP
4. 전체 버퍼
5. 룰을 같이 바꾸어야 한다.

이중에서 TP와 전체버퍼는 구체적인 방법론의 하나이고 나머지는 이론적인 것입니다. 이들 각각을 IT에 적용하려고 해보니, 토론할 것들이 상당히 많이 있어 보이네요.

전에 어딘가에서 "애자일 개발 방법론에는 새로운 방법론이 없다. 있다면 TDD 정도다."라는 글을 읽은 적이 있습니다. 약간은 동의를 하는데, 이것이 애자일이 관점이 조금은 다른 부분이 있고, 특징이기도 한 느낌입니다. 그래서, 저는 XP를 "책임을 지는 개발"쪽에 무게를 두고 있기도 합니다. 

비슷하게 TOC를 IT에 적용할 때도 애자일 동맹 선언서 같은 정도밖에 되지 않는듯한 느낌입니다.

TOC의 특징이라고 알고 있는 것들이 있으면 알려주시면 좋겠습니다. : )

좋은 하루는 기본~ ^^*

[송홍진]

제가 제약이론을 배우고 IT 업계에 적용하기 위해서 고민하면서 부딪힌 딜레마는 아래와 같습니다.

제약이론은 말 그대로 제약을 찾고 제약을 해결함으로써 개선을 이루어 내는 것을 목적으로 하는 이론입니다.

모든 것이 제약에 초점이 맞추어져 있죠. 그 제약을 찾고 개선의 방향을 찾는 방법이 TP로 구성되어 있고 그런 과정을 거쳐 만들어진 것이 DBR이나 CCPM으로 알려진 것들입니다.

그런데 이 제약이 확실히 발목을 잡는 것 같습니다. 제약이란 이미 무엇인가가 진행되고 있는 상태에서 도출되는 것이기 때문입니다.

즉, 방법론이나 프로세스를 처음 구축할 때 과연 제약이론을 사용할 수 있는 어떤 여지가 있는가? 그것이 제가 고민하는 부분입니다.

무엇인가를 처음 시작할 때에 과연 우리가 제약이 될 것을 인지하고 그것을 극복할 수 있도록 할 수 있는 것일까? 라는 의문입니다.

패턴의 도움을 일정 받을 수도 있을 것 같지만 개인적인 생각으로는 제약이론만으로는 조금 힘들지 않을까? 싶습니다.

그렇다면 다른 것들에게서 개념이나 방법들을 끌어와야 할텐데.. 기존에는 제약이론이 다른 것을 흡수한다기보다는 다른것들이 제약이론을 흡수하는 양상이었다고 봅니다.

저는 그것을 반대로 뒤집에서 제약이론이 다른 것들을 흡수해서 하나의 방법론 처럼 만들어보고 싶습니다.

대표적으로 린 소프트웨어 개발에 제약이론이 흡수되어서 린 소프트웨어 개발을 개선하는 시도는 이전부터 꾸준히 있어 왔습니다. 하지만 그러한 작업의 결과는 린 소프트웨어 개발로 불립니다. 누구도 그 안에 제약이론이 녹아 있다는 것을 알아차리기 힘들죠.

전 그걸 반대로 뒤집어서 제약이론만으로 구축된 방법론을 개발해보고 싶습니다.

여러분은 어떠신가요?

2010/1/13 gyehong park <gyeho...@gmail.com>

--
Murian Song

SW Testing Evangelist & Consultant / TOC Evangelist & Consultant

Mobile: +82-010-2226-7894

Email: y2k0...@gmail.com

Blog: http://murian.textcube.com

Twitter: http//twitter.com/murianwind

Facebook: http://www.facebook.com/profile.php?id=100000007703089

Skype: y2k001hj

[gyehong park]

하고 싶은 말들이 좀 있었는데... 나중으로 미루어야 겠네요. ㅎㅎ

암튼. 저는 "전체 최적화"라는 것에 더 촛점을 맞추고 있습니다. 제약이론은 이를 위한 수단으로 봅니다. 단지, 제약이론이 있기 때문에 "전체 최적화가 가능하다."라고 말 할 수 있게 된 것에 주목하고 있습니다. 그래서 문제가 전체로 넘어옵니다. 최적화는 제약이론으로 가능한 거죠.

전체는 무엇인가? 전체의 목적은 무엇인가? 등등의 의문이 생기고 있습니다. 

그리고, 제약이론을 확장할 수도 있습니다. 예를 들어, 제약이론을 "전체 최적화를 위해서는 1~2가지만 개선하면 된다"라고 본다면, 1~2가지 요소가 꼭 제약일 필요가 없게 됩니다. 이렇게 될 경우 제약을 개선하는 것이 아니라 장점을 개선할 수 있겠죠.

일단 여기까지. : )

2010/1/13 송홍진 <y2k0...@gmail.com>