R&D 과제 계획의 단위 — 무엇을 온톨로지의 클래스로 잡을 것인가

현장의 질문들 - 29

과제 계획을 세울 때 해야 할 일들을 늘어놓습니다. 그것이 활동이고, 각각에 담당과 일정이 붙습니다.
그런데 그 활동을 어느 크기로 자를지에 기준이 없습니다.
어떤 사람은 처방 개발 하나로 여섯 달을 잡습니다. 어떤 사람은 스무 개로 쪼개 놓습니다. 같은 회사, 같은 양식인데 그렇습니다.
그리고 이건 성의 문제가 아닙니다. 어디까지 나눠야 하는지를 아무도 정해 주지 않았기 때문입니다.
이 글은 그 기준에 대한 이야기입니다.

크게 잡으면, 잘게 쪼개면

둘 다 문제가 생깁니다. 다만 다른 문제입니다.

크게 잡으면 상태가 안 보입니다

처방 개발이 여섯 달짜리 활동이면, 그 여섯 달 동안 알 수 있는 것은 "진행 중" 뿐입니다.
지금 배합을 짜고 있는지, 안정성을 보고 있는지, 아니면 막혀서 멈춰 있는지가 안 보입니다. 물어봐야 압니다.
그리고 나중에 되짚을 수도 없습니다. 무슨 일이 있었는지가 하나의 덩어리로만 남습니다.

잘게 쪼개면 아무도 못 채웁니다

반대로 스무 개로 나누면 연구원이 채워야 할 칸이 스무 개가 됩니다.
시작하고 끝낼 때마다 상태를 바꿔야 하고, 계획이 조금만 바뀌어도 전부 다시 짜야 합니다.
세분화할수록 시스템 운영 부담이 늘어납니다. 그리고 부담이 넘으면 안 채웁니다. 안 채우면 시스템이 비고, 빈 시스템은 관리가 되지 않습니다.

기준은 기능입니다

그러면 무엇을 기준으로 자를까요.
기간도 아니고 담당자 수도 아닙니다. 기능입니다.
과제를 수행하려면 반드시 해야 하는 일들이 있습니다. 배합을 설계하고, 시험하고, 안정성을 보고, 규제를 확인합니다. 그 하나하나가 기능이고, 활동은 그 기능을 관리 단위로 놓은 것입니다.
기능이 다르면 나누고, 같으면 합칩니다.

이 기준으로 보면

처방 개발 하나로 여섯 달을 잡은 것은 여러 기능이 한 덩어리에 섞여 있는 것입니다. 배합을 짜는 일과 안정성을 보는 일은 다른 기능입니다. 나눠야 합니다.

반대로 1차 배합, 2차 배합, 3차 배합으로 쪼갠 것은 세 가지 기능이 아닙니다. 같은 기능을 세 번 한 것입니다.
기능이 늘어난 것이 아니라 수행이 늘어난 것입니다.

그러면 활동을 셋으로 만들 것이 아니라, 하나의 활동에 차수가 쌓이게 하면 됩니다. 관리해야 할 활동은 하나입니다.

담당자가 여럿 붙는 것은 기준이 아닙니다. 그건 자원 배분이지 기능의 문제가 아닙니다.

기준이 없어도 됐던 이유

그런데 지금까지 이 기준이 없어도 크게 문제가 되지 않았습니다.
과제는 대개 연구책임자에게 통으로 맡깁니다. 그리고 계획을 검토할 때 보는 것은 주요 일정과 최종 성과입니다. 중간에 무엇을 어떻게 할지는 잘 안 봅니다.

이게 잘못된 것이 아닙니다.
연구소장과 연구책임자는 경험이 많고 서로의 판단을 인정합니다. 그런 사이에서는 말로 하는 것이 빠릅니다. 문서로 만드는 쪽이 오히려 낭비입니다. 중간 상황은 회의나 오가며 공유되고, 그걸로 충분했습니다.
묻는 사람이 있었고, 답할 사람이 있었기 때문입니다.

다만 그 방식이 덮는 범위가 있습니다

두 사람이 아는 것은 두 사람 사이에서만 유효합니다.
셋째가 들어오거나, 한 사람이 옮기거나, 몇 년 뒤에 되짚어야 할 때는 다릅니다.

그리고 여건이 빨리 바뀝니다. 규제가 바뀌고 고객사 요구가 바뀝니다. 그러면 계획도 자주 바뀝니다. 말로 전한 것은 그때 한 번입니다. 바뀔 때마다 다시 말해야 하고, 몇 번 돌면 누가 어디까지 알고 있는지 모르게 됩니다.

관계가 문제인 것이 아니라, 그 관계로 덮이지 않는 범위가 늘어나고 있는 것입니다.

디테일은 서술이 아니라 구분입니다

여기서 계획의 수준이 무엇인지가 달라집니다.
흔히 계획서를 얼마나 자세히 썼는가를 디테일이라고 부릅니다. 글의 양입니다.

그런데 실제 디테일은 기능을 어디까지 갈랐느냐입니다.
처방 개발 하나로 적은 계획과, 배합 설계·안정성 평가·규제 검토·관능 평가로 나눈 계획은 글자 수가 비슷해도 수준이 다릅니다.
앞은 무엇을 할지 아직 안 정한 것이고, 뒤는 정한 것입니다.

그리고 여기서 전달되는 지식이 정해집니다

처방 개발을 했다는 다음 사람에게 아무것도 주지 않습니다.
안정성 평가를 이런 조건으로 했고 이런 결과가 나왔다는 줍니다.

기능이 갈려 있어야 그 자리에 지식이 붙습니다. 갈리지 않으면 붙일 자리가 없습니다.
그래서 기능을 어디까지 갈랐느냐가 곧 전달할 수 있는 지식의 크기가 됩니다.

데이터가 아니라 그릇입니다

여기까지 오면 연결의 문제로 넘어갑니다.
지난 과제를 참고한다는 것은 같은 기능의 다른 수행을 보는 것입니다. 그러려면 같은 기능이 같은 이름으로 남아 있어야 합니다.

같은 일이 안정성 평가, 안정성 시험, 저장 안정성 확인으로 제각각 들어가면, 같은 기능인지 알 수 없습니다. 알 수 없으면 묶이지 않고, 묶이지 않으면 참고할 것도 없습니다.

두 층이 있습니다

기능은 미리 정해 두는 것이고, 수행은 일하면서 생기는 것입니다.
세분화가 부담이 되는 이유가 여기 있습니다. 차수마다 활동을 만들면, 수행으로 둬야 할 것을 기능으로 만드는 것입니다. 기능은 누가 정의하고 유지해야 합니다. 수행은 저절로 생깁니다.

온톨로지 용어로 말하면

이 두 층을 클래스(Class)와 인스턴스(Instance)라고 부릅니다. 기능이 클래스이고, 실제 수행이 그 클래스의 인스턴스입니다.

그런데 일반적인 온톨로지에서 클래스는 대개 명사입니다. 제품, 원료, 문서, 특허. 사물의 종류입니다.
온톨로지가 일을 다루지 못하는 것은 아닙니다. 다만 실제로 만들어지는 것은 대부분 사물 중심입니다.

차이는 마지막 줄입니다.
사물에는 속성이 붙습니다. 일에는 시점과 주체와 판단이 붙습니다. 언제 했고, 누가 했고, 무엇을 보고 다음으로 갔는지.

그래서 갈림길은 여기입니다

제품과 원료를 이어 두면 "이 원료가 어느 제품에 들어갔나"는 나옵니다.
그런데 "왜 그 원료를 골랐나"는 안 나옵니다. 그건 사물이 아니라 일에 붙어 있기 때문입니다.

무엇을 클래스로 잡느냐가 갈림길입니다. 사물을 잡으면 결과가 이어지고, 기능을 잡으면 과정이 이어집니다.
그리고 그 클래스를 정하는 일이 곧 과제 계획의 단위를 정하는 일입니다.

관련 글

[현장의 질문들] 연구과제관리 시스템은 무엇을 관리합니까
[현장의 질문들] 중소기업 연구소의 수주형 개발 관리
[현장의 질문들] 지식관리시스템은 왜 대부분 실패했습니까