스퀘어 에닉스의 프로젝트가 실패하지 않기 위한 관리술

특이한 프로젝트 관리술이 있기에 아래에서 퍼옴
http://naridy.egloos.com/4652893

개똥으로 유명한 FF14의 리빌딩 프로듀서를 맡고 있는 분의 강연이라 꽤나 현실감 있는 내용이 많습네다

예전에 꽤나 재밌게 봐서 언제 소개 해봐야겠다...고 생각하던 물건인데...

텍스트가 너무 많아서 차일피일 미루다가, 계속 냅두고 있으니 똥 싸고 안 닦은 기분이 자꾸 들어서 말이죠.

그래서 어떻게 대충 정리해서 올립니다.

PPT 위주의 강연이라 PPT 번역이 중요한데, PPT 문서를 내가 새로 베껴 만들긴 귀찮고, 그렇다고 빼자니 의미가 없고, 일본어 파일 그대로 올리기도 뭐하고...

결론은 그냥 PPT 문서 들어가는 위치에 그대로 번역... =ㅠ=

큰 문자로 강조된 부분은 일본어 PPT 문서가 들어가는 부분이니깐, 그 부분 참고해 가시며 읽으시면 될 듯.

아래 뉴스 사이트의 기사를 그대로 번역한 거라, 기자가 직접 강연 들으며 요약한 거니까 얼추 이해는 되겠지만...




［SQEXOC］プロジェクトを失敗させないためには？　スクウェア・エニックスで実施されているプロジェクト管理術公開


  10월 8일, 도쿄 신주쿠에서 개최된 「스퀘어 에닉스 오픈 컨퍼런스 2011」에서, 스퀘어 에닉스의 CTO / 테크놀러지 추진부 담당 코퍼레이트 이그젝티브 겸 제너럴 매니저 / 신세대 게임엔진 Luminous Studio 프로듀서 겸 테크니컬 디렉터 / 리얼타임 테크놀러지 데모 Philosophy 프로듀서 겸 통합 디렉터 / FINAL FANTASY XIV 테크니컬 디렉터인 하시모토 요시히사 (橋本善久) 씨에 의한「게임 개발 프로젝트 매니지먼트 강좌」를 다룬 강연이 있었다.

 

  그의 직함에서도 알 수 있듯이 하시모토 씨는 여러 가지 프로젝트를 담당하고 있다. 그런 그에 의해 스퀘어 에닉스에서 실제로 사용되는 프로젝트 매니지먼트 수법이 소개되었다.

 

서두에 하시모토 씨는 「어째서 프로젝트는 실패하는가?」라고 묻고, 프로젝트 실패 포인트를 6종류  들었다. 즉,

ㆍ스코프의 문제 (사양 변경)

ㆍ품질의 문제

ㆍ코스트의 문제
ㆍ시간의 문제

ㆍ리소스의 문제 (멤버 등)
ㆍ비지니스의 문제

다. 이 포인트들이 복잡하게 얽히면서 프로젝트 예정에 오차가 생기기 시작한다.

프로젝트 실패 포인트의 사례

ㆍ예상보다 매상이 적다
ㆍ계획보다도 비용이 더 들었다
ㆍ발매시기가 늦었다
ㆍ발매일을 맞추기 위해 내용이 빠졌다
ㆍ유저의 평가가 나쁘다
ㆍ오작동이 발생
ㆍ개발진의 만족도가 낮고, 고장난 사람이 발생



  위와 같이 프로젝트의 실패라는 것엔 이런저런 경우가 있는데, 강연에선 주로 시간적인 실패에 집중한 이야기가 전개되었기에, 이후 기본적으로 시간적인 문제에만 신경 써서 읽는 편이 알기 쉬우리라.


  본론으로 돌아가자. 그럼 그 오차가 얼마가 되는가, 라고 하시모토 씨는 계산을 시작했다. 상당히 간략화된 예지만, 우선 변동요인을 8개 들어 각각의 분야에서 에러가 발생할 경우 아래 도표와 같이 쌓이기 시작하고, 그 누계가 10배의 오차를 만들어낸다고 지적했다. 2년으로 개발할 예정인 물건이었다면, 20년이 걸린다는 계산이다. 물론 이러한 요인이 죄다 곱절로 돌아오는 상황이 될 리는 없을테지만, 상당히 큰 변동이 생길 가능성이 있는 건 틀림없으리라.

계획의 주된 변동요인

ㆍ스코프의 변화
    -사양의 추가, 변경

ㆍ태스크 분해의 에러 
    - 이미 정해진 사양에 대해 태스크 나눈 게 빠진 게 있을 경우

ㆍ견적 설정의 에러
    - 태스크 소화에 들어가는 시간을 잘못 계산했을 경우

ㆍ하루당 작업시간을 잘못 계산한 에러
    - 회의 같은 것으로 생각한 것보다 작업시간을 확보하지 못한 경우

ㆍ인원계획의 에러
    - 생각보다 인원을 늘릴 수 없다
    - 생각보다 능력이 없다

ㆍ품질 매니지먼트의 에러
    - 품질이 오르지 않으니 다시 만들기

ㆍ기술 매니지먼트의 에러
    - 프로그램적으로 실현이 어려워서 다시 만들기

ㆍ그 밖의 기타 등등...

변동요인별 변화폭의 사례

ㆍ사양 추가로 스코프 변경 → 1.5배
ㆍ태스크 분해의 에러 → 1.4배
ㆍ견적 설정의 에러 → 1.3배
ㆍ하루당 작업시간을 잘못 계산한 에러 → 작업시간 -20% = 1.25배
ㆍ인원계획의 에러
    - 생각보다 인원확보를 할 수 없었다 → -20% = 1.25배
    - 생각보다 능력이 없었다 → -30% = 1.4배
ㆍ품질 매니지먼트의 에러 → 1.3배
ㆍ기술 매니지먼트의 에러 → 1.3배
ㆍ그 밖의 기타 등등...

1.5 × 1.4 × 1.3 × 1.25 × 1.25 × 1.4 × 1.3 × 1.3

≒ 10배!!

  그럼 어떻게 대처하는가? 사양의 축소, 인원추가투입, 개발기간연장, 품질의 타협 등을 해도 아직 부족하다. 최종적으론 노동시간을 대폭 늘리는 것으로 스케쥴에 맞추는 경우가 많은 것은, 소프트웨어 업계 공통의 문제라 할 수 있으리라.

  이러한 비극, 각 항목에서의 견적 판단 에러에 의해 발생하는 것이지만,  「프로젝트의 정확한 예상 따위 불가능하다」라고 하시모토 씨는 이야기한다.

대처 1

사양을 35% 삭제

→ 1.54배의 대책효과



대처 2

인원을 60% 추가투입

→ 1.6배의 대책효과

※물론 인원을 충원한다고 인원수 만큼의 효과가 나는 건 아닙니다만 간략계산으로 가겠습니다.

대처 3

기간을 50% 연장

→ 1.5배의 대책효과



대처 4

품질을 30% 타협한다

→ 1.43배의 대책효과

※품질을 낮춤으로서 작업수를 줄인다는 의미로 계산하고 있습니다.

1.54 × 1.6 × 1.5 × 1.43

≒ 5.64배의 대책효과


음~ 아직도 10배의 대책효과는 내지 못 하고 있습니다

대처 5

1달 노동시간을

160시간에서

290시간으로 한다

→ 1.8배의 대책효과

1.54 × 1.6 × 1.5 × 1.43 × 1.8

≒ 10배의 대책효과


이제야 대책을 세울 수 있게 되었습니다!!

대처 1  사양을 35% 삭제
대처 2  인원을 60% 추가투입
대처 3  기간을 50% 연장
대처 4  품질을 30% 타협한다
대처 5  월 노동시간을 80% 늘린다


아주 멋진 죽음의 행진의 완성입니다.

꽤 자주 보는 풍경 아닙니까?

결국 프로젝트의

정확한 예상 따위

아무도 할 수 없습니다.

  그럼 프로젝트 매니지먼트에 의미가 없는가 하면, 그런 게 아니라 프로젝트는 불확실한 것이라는 걸 전체로 한 프로젝트 관리가 중요하다는 게 하시모토 씨의 설명. 그리고 그는 그 요점을「능동적인 대응」이라고 정의한다. 사전대처형 진행을 함으로서 프로젝트의 제어가 가능하다는 듯 하다.

프로젝트란

불확실한 것이다

라는 사실을 받아들이고 리액티브한

사후대처형(일단 일이 터지면 그때 대처)에서

프로액티브한 사전대처형으로

적응함으로서 프로젝트를 제어할 수 있습니다.

불확실성을 이겨낸다

ㆍ불확실성을 제어하는 방법은 몇 개정도 있습니다

   - 사후대처형
     ㆍ꼬리를 물고 일어나는 문제를 조기발견해, 어린 싹일 때 대처를 한다
          - 이터레이션을 돌린다

   - 사전대처형
     ㆍ불확실성을 줄인다
           - 잘 파악되지 않은 부분의 조사나 검증/실험을 제대로 한다
           - 작업 데이터를 얻어 피드백 해나감으로서 예측정밀도를 올린다
           - 계획규모를 작게 한다
           - 설계를 최대한 자세하게 한다
           - 리스크 높은 요소를 미리미리 최대한 줄인다

     ㆍ불확실해도 좋은 걸 한다
           - 리스크 높은 요소를 없애더라도 성립될 설계를 해둔다



  이렇게 불확실성을 전제로 한 사전대책법으로는

● 불확실성을 줄인다

● 불확실해도 괜찮은 걸 한다

  는 2가지 방향성을 제시했다. 「불확실성을 줄인다」는 것은 프로젝트의 전체 파악을 좋게 해, 견적의 정밀도를 올리고, 처음부터 리스크가 적은 사양으로 만든다는 것. 「불확실해도 괜찮은 걸 한다」는 것은 조금 알기 힘든 것이지만, 강연에선 사양을 정할 때 있어 RPG에서의  「마을」이 사례로 꼽혔다. NPC나 모델링 데이터가 많아 구현이 간단하지 않을 경우, 최악의 상황에선 마을이 없어도 게임의 진행에 문제가 없도록 사양을 정해둔다는 것이다. 이러한 걸 간단히 종합해보면 (흔한 얘기이긴 하지만) 「Agile 방법론을 활용하자」는 게 된다.

 

  애자일 방법론으로는 이런저런 게 있지만, 거의 모든 것에 공통되는 것이 단기간에 소규모개발 iteration (계획 - 설계 - 검증의 반복)을 해나간다는 부분이다. 이 메리트에 대해 예를 들어가며 해설되었지만, 상당히 일반적인 내용이니 여기선 생략한다. 한 마디로 「궤도수정하기 쉽게 한다」는 것이다.
  그럼 이터레이션을 자주, 많이 반복하면 모든 게 해결되는가 하면, 그렇지만도 않다고 한다. 하시모토 씨는 개집을 만드는 것과 고층빌딩을 건설하는 경우를 예로 들어, 대규모개발에선 세밀한 계획을 세워 작업해 가는 게 불가피하다고 설명한다. 완벽한 설계와 사양책정을 한 뒤 개발을 시작하는 수법이, (이터레이션이 필요한 경우가 많은) 폭포수 형태 개발인 관계로, 공업분야에서는 상식적인 것인데 소프트웨어 개발에선 어째서인지 소홀시되고 있다고 한다. 대규모개발에서 애자일 방법론을 활용한다고 해서, 폭포수 형태에 필요한 세밀한 조사ㆍ설계ㆍ계획으로부터 자유로워지는 것은 아니라는 걸 강조했다.

  이후엔 스퀘어 에닉스 테크놀러지 추진부에 도입되어 있는 프로젝트 매니지먼트 수법의 해설이 행해졌는데, 대규모개발에서의 개발 세부에 스크럼을 베이스한 것이라 생각되는 애자일 방법론을 융합한 독특한 것이었다.

  하시모토 씨는 프로젝트 매니지먼트의 요점으로서 아래 4개를 들며, 이번엔 계획과 제작 부분에 맞춰 스퀘어 에닉스의 대처방법을 소개하며 대규모 게임개발 프로젝트의 진행법에 대해 해설했다.


 

프로젝트 매니저먼트의 요점

ㆍ조사한다
ㆍ설계한다
ㆍ계획한다
    - 태스크를 뽑아낸다
    - 견적설정을 한다
    - 우선도를 정한다
ㆍ제작한다 (이터레이션을 돌린다)
    - 스프린트, 아침회의, 태스크 관리 보드, 태스크 관리 시트
    - 정기적으로 돌아보며 문제를 조기발견
    - 정책을 조율한다
        ㆍ설계의 수정 (게임사양, 아트, 프로그램 등의 수정)
        ㆍ계획의 수정 (태스크 추가 및 변경, 견적의 변경, 우선도의 변경)
        ㆍ리소스의 수정 (인원의 추가나 포지션 변경 등)

  업무의 열거에는 유저 스토리를 기반으로 항목을 만들어간다.

  「유저 스토리」란 「게임에서 실현하고 싶은 걸 문장으로 표현한 것」으로, 특징으로는 어미가 「할 수 있다」로 되는 게 많은 것. 요점이라면 빼먹는 부분이 없는 게 중요하며, 내용적으로는 중복되는 건 상관없으니 가능한 많은 요소를 뽑아내야 하는 듯 하다. 많은 사람이 리스트를 갖고 가져오면 마인드맵 툴 등을 이용해 종합하면 된다고.

유저 스토리란? ①

ㆍ그 소프트웨어 (게임 포함) 에서 표현하고 싶은 걸 「문장으로」 표현한 것입니다
ㆍ유저 스토리와 도해를 조합해 「사양서」로 사용해도 좋습니다
ㆍ일례
    - 100km 공간의 필드를 자유롭게 산책할 수 있다
    - 플레이어도 적도 건물을 파괴할 수 있다
    - 플레이어는 라이프가 0이 되면 죽어서 리스타트 포인트로 귀환한다
    - 적 캐릭터는 50명 동시에 화면에 등장한다
    - 플레이어는 포복 전진해서 좁은 틈새를 빠져나갈 수 있다
    - 연막은 캐릭터를 비틀거리게 하는 움직임을 시킨다
    - 스위치를 밟으면 문이 열린다

  이어서 「피쳐」라는 것은 유저 스토리를 실현하기 위해 제작해야만 하는 기능 등을 열거한 것이다. 「~~ 시스템」 등의 명사형이 되는 경우가 많다고 한다. 작업상으론 큰 작업 덩어리로서 취급되며, 똑같은 피쳐로 복수의 유저 스토리를 실현하는 경우도 적지 않다고 한다.

피쳐란? ①

ㆍ제작할 기능이나 대상을 의미합니다
ㆍ유저 스토리를 분해하며 열거합니다
ㆍ○○ 기능, ○○ 시스템 등의 「명사로 끝나는」 경우가 많습니다
ㆍ일례
    - 라인 묘화 기능
    - 플레이어의 점프
    - 플레이어의 포복 전진
    - 화염공격
    - 메모리 관리 시스템

피쳐란? ②

ㆍ「커다란 태스크」라 말해도 좋습니다
ㆍ각각의 스토리를 분해해 보면, 똑같은 피쳐가 나오는 게 보통입니다

  피쳐를 개인의 개인의 작업단위로까지 분할한 것을 「태스크」라 부른다. 하루에 1, 2 태스크를 할 수 있는 작업량이 될 때까지 분해해간다. 다만 모든 작업을 일괄적으로 태스크로 분할한다는 것은 현실적이지 않기 때문에, 태스크 분할은 작업을 진행해 가며 LOD(Level of Detail)적으로 해가면 된다고.

 

태스크란?

ㆍ각 멤버가 작업을 하는 관리 단위입니다
ㆍ피쳐를 분해한 것입니다
ㆍ하루 당 1 ~ 2 태스크 정도의 사이즈까지 분해합니다
ㆍ일례
    - 스코어 표시의 페이드인, 페이드아웃 처리
    - 포복 전진 모션
    - 문 열고 닫기

  자 그럼, 이 태스크를 실제로 진행해가는 작업은, 태스크의 열거(태스크 분할시 끝나있음), 태스크의 견적, 태스크에 우선도를 매긴다는 3단계로 이뤄지며, 태스크에 우선도를 선정한 시점에서 이미 스케쥴이 만들어지는 것이라고 하시모토 씨는 설명했다.

 

  우선 견적에선 1점 견적 설정과 2점 견적 설정이 있다고 소개한 뒤 2점 견적내기의 메리트를 해설했다. 1점 견적 설정이란 「마감은 4일 뒤」란 느낌으로 마감기한을 설정하는 것. 2점 견적 설정은 「마감은 빠르면 3일 뒤, 최악의 경우 5일 뒤」란 느낌으로 기간을 설정해두는 타입을 가리킨다.

 

  1점 견적 설정이라면 일단 완성이 될 경우 그 이상의 작업을 하지 않지만(파킨슨 법칙), 마감 아슬아슬할 때까지 손을 안 댄다(학생증후군), 일단 마감을 넘겨버리면 그 뒤는 아무리 늦어도 같은 거라 생각한다(뜨거운 걸 삼키면 잊어버리는 법칙)이라는 문제가 발생하기 쉽다고 한다.

 

  2점 견적 설정이라면 심리학적으로 제시되는 문제는 둘째 치고, 통계적으로 대략 4일 정도면 완성되는 경우가 많다는 듯 하다. 참고로 2점 견적 설정의 마감 설정은, 각각 확률 20% 정도로 설정하면 좋다고 한다. 「굉장히 순조롭게 진행되면 3일이면 되겠지만, 그 확률은 20% 정도겠지」 「잘 안 풀리면 5일은 걸릴지도. 이럴 확률 20% 정도」는 느낌으로 견적 설정을 하는 것이다.

1점 견적 설정의 문제점과
2점 견적 설정의 메리트

ㆍ작업일수의 견적 설정은 하나의 태스크에 대해 하나의 마감일로 설정하는 1점 견적 설정이 일반적
ㆍ하지만 이 방식은 문제나 단점이 많다
    - 파킨슨 법칙
    - 학생증후군
    - 뜨거운 걸 삼키면 잊어버리는 법칙
ㆍ2점 견적 설정은 심리적인 작용도 포함해 스케쥴 실적 정밀도가 향상되는 마법의 방법



  처음에 언급된 프로젝트의 오차를 적게 해 궤도수정을 빠르게 한다는 목적을 생각해보면, 이러한 견정 성정 부분의 정밀함이 매우 중요해진다는 건 간단히 이해할 수 있다. 어떻게 이 부분의 정밀도를 올리느냐에 대해선, 재밌는 방법이 사용되고 있었다. 담당자와 상관을 비롯한 몇 명이 「견적 포커」라고 불리는, 마감날짜가 적힌 카드를 갖고 모여 각자가 적당하다고 생각되는 2점 견적 설정 날짜를 동시에 제출한다는 듯 하다.

 

  당연히 서로가 생각한 마감일이 다르게 튀어나오겠지만, 어째서 기간이 더 필요하다고 생각하는가, 어째서 기간을 단축할 수 있다고 생각하는가 등에 대해서 의견을 교환한 뒤, 다시 마감일을 적은 카드를 펼친다. 이걸 몇 번 반복하면 마감 기간이 타협되기 시작하고, 태스크를 반복해가면서 정밀도도 올라가게 된다고 한다.

스퀘어 에닉스 명물 「견적 포커」용 카드

 

  견적을 통해 스케쥴이 나온 단계에서 실제 제작에 이행한다. 그리고 개발 부분의 이터레이션에 대해선, 「스프린트」라는 스크럼용어가 사용되고 있다. 

스프린트

ㆍ4주일 고정인 이터레이션 기간
ㆍ휴일 같은 게 있으니 대략 18 ~ 20 영업일
ㆍ스프린트 첫날은 해당 4주일 분량의 태스크를 중장기 태스크 리스트 (견적 설정 완료) 에서 가지고 옵니다
ㆍ태스크 분해나 견적 설정의 정밀도가 대충일 경우엔 이 시기에 세밀하게 정리합니다
ㆍ스프린트 최종일엔 데이터 분석 등을 하며 돌아 봅니다

  하시모토 씨가 사용하는 수법에서의 스프린트 기간은 4주일로 고정된 듯 하며, 일반적인 애자일 방법론을 생각하면 길게 느껴지는 경향이 있다. 스프린트 첫 날엔 태스크나 견적 설정의 세분화 등을 하며, 마지막 날엔 그 과정을 돌아본다. 매일 아침 회의에서 시작해, 하루 단위, 주 단위의 계획을 세우는 등, 스프린트 기간은 짧지만 상당히 세부적으로 매니지먼트되고 있다. 스프린트의 끝에 성과물 발표회가 치뤄지게 되지만, 성과물이라는 형태로의 발표가 없는 경우도 있다고 한다. 애자일 방법론에 따르면 반드시 성과물을 내는 걸 중시하도록 되어 있지만, 이 부분은 유연한 구성을 한 듯 하다. 

계획에 대하여

ㆍ마일스톤 계획 (중장기 계획)
ㆍ매 스프린트 계획
    - 목표성과물의 계획
    - 스프린트 첫 날에 그 스프린트의 태스크 계획
ㆍ매주의 계획
    - 월요일 아침회의에 그 주의 태스크 계획
ㆍ매일의 계획
   - 매일 아침회의에 해당 일의 태스크 계획

견적 설정 정밀도

ㆍ(현재의 실적 - 최소 견적) / (최대 견적 - 최소 견적) × 100 = 견적 설정 정밀도
ㆍ견적 설정 정밀도의 평균이 0%에 가까울 경우, 또는 0%를 밑돌 경우 → 견적 설정이 어설프니 다음 스프린트부터 견적 일자를 약간 타이트하게 수정
ㆍ견적 설정 정밀도가 100%에 가까울 경우, 또는 100%를 넘어선 경우 → 견적 설정이 너무 타이트한 거니 다음 스프린트부터 견적 일자를 조금 너그럽게 수정
ㆍ견적 설정 정밀도는 40 ~ 50% 정도로 유지하는 편이 이상적
ㆍ30% 이하를 녹색, 30 ~ 70%를 노란색, 70% 이상을 빨간색으로 해 태스크 관리 보드 위의 포스트잇에 표기해둔다

  태스크의 진행상황은 게시판에 포스트잇을 사용해 태스크 관리 보드에서 일람할 수 있도록 했다고 한다. 견적 기간에 대해서도 빨리 끝난 것은 파란 포스트잇, 통상적인 것은 노란 포스트잇, 늦은 것은 빨간 포스트잇을 사용한다는 느낌으로 한 눈에 상황을 알 수 있다. 다른 회사의 매니지먼트 사례에서도 보드를 사용하는 경우는 많지만, 이런 부분에서 굳이 전자화 하지 않는 것이 일반적인 듯다.

되돌아보기

ㆍ매일 돌아보기
    - 아침회의
ㆍ매주 돌아보기
    - 주간보고
ㆍ매 스프린트 중간 돌아보기
    - 스프린트 중간보고
ㆍ매 스프린트 돌아보기
    - 스프린트 보고
ㆍ프로젝트 돌아보기

태스크 견적 설정 미스와 작업 열거 누락

ㆍ계획의 오차엔 두 가지 요소가 있으며, 구별할 필요가 있다
    - 수치 견적  미스
    - 작업 열거 누락

ㆍ수치 견적 미스는 2점 견적 설정을 대처할 수 있다
    - 견적 버퍼
         ㆍ최대 견적과 최소 견적의 차이 합계를 시간적 버퍼라고 본다

ㆍ작업 열거 누락엔 전용 버퍼를 준비
    - 피쳐 버퍼
         ㆍ작업 내용의 추가전용기간을 설정해 둔다



  이렇게 프로젝트 매니지먼트를 도입한 결과로서는 역시 프로젝트의 전체 파악이 쉬워졌다는 것이나 궤도 수정이 간단해졌다는 것 등을 들었다. 참가 멤버도 잔업의 프레셔에서 해방되어 멘탈적인 부분에서도 좋은 영향을 보였다고 한다.

  이번에 소개된 수법은 하시모토 씨의 독자적인 방법이지만, 자세한 내용에 대해선 하시모토 씨가 현재 책을 낼 준비를 하고 있으니 흥미가 있는 사람은 기다려 보자.

프로젝트 매니지먼트를 하며 얻은 효과

ㆍ불확실성을 제어
    - 전체파악이 된다
    - 조기에 문제 발견
    - 계획수정도 쉽다

ㆍ멘탈 효과
    - 자신의 작업과 기간이 파악되어 근거는 없지만 잔업을 해야만 할 거 같다는 프레셔에서 해방됨 → 잔업, 주말출근이 줄어듬
    - 서로의 업무를 알게 됨
    - 즐거워진다


 
  이번 강연에선 프로젝트 관리의 중요성과 애자일 방법론의 유효성에 대해 소개되었지만, 약간 소화불량인 듯한 사람이 있을지도 모른다.

 

  약간 심술궂은 시점으로 바라보자.

 

  초반에 제시된 사례와 같이 100명의 인원이 필요하다 견적나온 것이, 파국을 맞이해 나중엔 결국 1000명짜리 프로젝트가 되었다는 사례가 있을 경우, 그 1000명짜리 프로젝트의 성과물과 제대로 된 프로젝트 매니지먼트로 완성된 100명짜리 성과물이 과연 똑같은 것인가?는 의문이 남는다. 물론 다른 물건이 나오는 게 보통이다. 일반적인 소프트웨어 산업의 경우, 사양만 만족시키면 프로젝트는 성공하게 되지만, 게임업계의 경우 꼭 그런 것만도 아니다.

 

  만약 최종적인 성과물이 똑같은 것이 된다면, 아마도 들어간 코스트도 거의 동일. 마감지옥일 때도 산더미 같은 잔업을 회피하는 행복한 매니지먼트라면, 개발기간이 당연히 늘어나게 될 텐데 이건 용서받을 수 있는 것일까? 초반 사례에서 80% 늘어난 노동시간 대신, 180%의 작업효율이 나온 것일까?

  80%는 어쨌든 작업효율 자체는 아마도 향상되었으리라 생각하지만, 매니지먼트 수법의 도입으로 의해 늘어나는 작업량이라는 것도 존재한다. 앞서 이야기한 것처럼 잔업 없이 만들면 다들 까먹게 될 무렵 게임이 완성되는 스케쥴이 될 가능성도 있다. 또한 사양에서 리스크를 철저히 배제하면서 개발하면, 별로 획기적인 부분이 없는 게임이 만들어진다는 건 굳이 이야기하지 않아도 되리라.

 

  그럼 이렇게 시시콜콜하게 하는 프로젝트관리에 의미가 없는가 하면, 그렇지는 않다. 큰 리스크를 회피하기 위해선 매우 실용적이며, 프로젝트의 파악을 쉽게 하는 것도 중요한 일이다. 그리고 더욱 개발효율을 올리는 방법과 리스크가 높은 개발이 용납되는 부분이 더해짐으로서 프로젝트 관리는 큰 의미를 갖게 된다. 즉, Luminous Studio의 개발과 연구개발부분의 존재이유이다.

 

  Luminous Studio에 의해 고품질의 게임이 적은 노동력으로 만들어질 것이 기대받고 있다. 그리고 사운을 건 대형 타이틀에 신규개발기술을 잔뜩 직업넣으려고 하는 건 무모하므로, 연구개발부분에서 기술적인 부분을 파악해가며 장차 도입해간다는 흐름이 되면, 적은 리스크로 대형 프로젝트를 진행하는 것도 가능해지리라. 현재 스퀘어 에닉스는 이러한 부분을 잘 활용함으로서 게임개발체제를 근본부터 바꿔가려 하고 있다고 보여진다. 실제로 이러한 매니지먼트가 효과를 발휘하는 것은 좀 더 시간이 걸릴 지도 모르지만, 빛을 보게 되면 일본게임업계에 있어 혁명적인 일이 되리라. 스퀘어 에닉스의 앞으로 동향에 주목하고 싶다.

 

 

끄, 끝났다...

저도 쪼렙이다 보니 프로젝트 매니지먼트라는 좀 큰 업무는 잘 몰라서 이것저것 찾아보며 번역했습니다.

나름 공부 되었네요.

어쨌든 꽤 괜찮은 강연이었으니, 일본어가 되시는 분은 스퀘어 에닉스에서 직접 올린 해당 강연의 PPT 문서를 직접 보시는 것도 좋을 듯 합니다.


http://www.square-enix.com/jp/info/library/dldata/PM/PM.pdf


.............300페이지 좀 안 되는 분량이지만, 문자가 큼직큼직해서 볼 만 합니다. =ㅠ=

그러고 보니 FF14 리빌딩이 끝나서 내년 1월부터 유료로 서비스한다고 하던가?

이러한 강연하는 사람이 어떻게 게임을 다시 만들었을지 좀 궁금하긴 하군요. ㅎㅎ

오늘의 짤방. 옛날 게임처럼 우당탕 만드는 게 안 통하는 시대라 관리하는 게 큰일이죠, 요즘 시대는