아웃소싱 회사가 본격적인 Web 서비스를 개발 · 운용하기 위해 노력했다 10 일

붸루쿠라는 회사는 기본적으로 아웃소싱 기업인데 평행하고 자사 서비스에 최선을 다하고 있습니다.

현재 클라우드 기반 업무 · 경영 관리 시스템 'board'라는 서비스를 제공하고 있으며, 사업으로 어느 정도 궤도에 왔기 때문에 지금까지 종사했다는 것을 소개하고 싶습니다.

전회, "도크 푸 딩하면서 서비스를 개발하는 장점과 조심하는 것" 이라는 기사를 게시했습니다. 그래서 개발 부분뿐만 아니라 전체를 듣고 싶은 소리를 받았으므로, 그쪽에 대해 먼저 "임한 10 일"로 정리 기사에서 게시 할 수 있으면이라고 생각합니다.

수탁 개발 회사가 자사 서비스에 종사 해당하는 과제

당사의 경우, 나 자신을 포함하여 계속 수탁 개발을해온 멤버 였기 때문에 자사 서비스를 개발 · 운영하는데있어서 몇 가지 과제가있었습니다.

1. 아웃소싱의 경우 기본적으로 고객이 기획과 요구 사항을 결정하기 위해 스스로 처음부터 기획을 생각하고 요구 사항을 결정 간다는 경험이 없었다

2. 수탁 개발의 경우 만든 시스템의 마케팅을 자신들이 할 일은 없습니다. 마케팅 PR 등 분야는 전혀 미경험이었다

3. 기본적으로 아웃소싱을 기본으로하고 있기 때문에 위탁이 바빠지는 아무래도 자사 서비스의 개발이 멈춰 버린

기타 세부 과제는 여러 가지가 있지만 크게 위와 같은 문제가있었습니다.

아웃소싱을하면서 자사 서비스를 개발하는데 임했다 "10 일"

전술 한 바와 같은 과제가있는 상태에서 서비스를 시작해 사업으로 궤도에까지 임했다 "10 가지 '를 소개하고자합니다. 이번에는 개요 편에서 다음번 각각 세세한 이야기​​를 쓰고 싶다고 생각합니다.

1. 브레스트 기획

수탁 개발 작업은 처음부터 기획을 생각하거나 브레스트에서 아이디어를 보태거나하는 경험이 거의 없습니다. 따라서 "아이디어를 낸다」는 것이 골칫거리였습니다.

거기서 「하나 테마를 정해 1 시간 내에 100 개의 아이디어를내는 "라는"교육 "을 여러 번하고 아이디어의 좋은 · 나쁜 아니라 '아이디어를 발설 것"에 익숙해 노력을합니다 했다.

2. 프로토 타입

린 스타트 업이 유행 뒤였다라고하기도 최대한 번거 로움없이 검증하기 위해, 3 일 정도 프로토 타입을 만들고 개념이 잘못되지 않았는지 등의 확인을 실시했습니다 .

프로토 타입을 만들고 검증하는 것도 수탁에별로없는 방식 이네요. 종이 프로토 타입인지, 실제로 움직이는 것인가. 그리고 어디까지 만들 것인가,하는 것이 매우 중요 했습니다.

3. 독 푸 딩

자사 서비스의 경험치가 적은 상태에서 자신이 관계없는 분야의 서비스를 성공시키는 것은 매우 허들이 높다고 생각합니다.

독 푸 딩 (개발 한 서비스를 개발자 자신이 사용자로서 일상적으로 사용) 할 수 있다면 스스로 요구를 파악하고, 사용성을 검증 할 수도 있습니다. 따라서 "독 푸 딩 수"에 한정하여 추진하기로했습니다 .

board의 경우 자신의 과제 (업무와 경영의 효율화)을 해결하기 위해 개발을 시작하고 "수탁 사업 (= 안건 단위로 일을받는 것) '를 타겟 있습니다.

4. 단계적인 공개

board는 사내 α 판 → 폐쇄 β 판 → 공공 β 버전 → 정식 릴리즈 형태로 2 ~ 3 개월 정도의 기간에 하나씩 진행갔습니다.

이것은 저희에게 매우 효과적이었습니다.

자사 서비스를 공개하는 것에 익숙하지 않았기 때문에, 단계적으로 공개하여 조금씩 운용 경험이 있고 사용자들의 문의 대응에 잘 적응할 수있었습니다 .

5. 마케팅 · PR · SEO

현재에도 여전히 과제이지만, 위탁을하고 있던 회사에 알려지지 않은 분야에서하고 우리와 같은 지명도가 높지 않은 회사라면 꽤 고생합니다.

당사의 경우 "수탁로 벌어 들인 돈을 자사 서비스 개발에 돌리 '라는 자세 때문에 광고에 대량의 자금을 투입하는 같은 수 없으며 지명도가없는 회사라고 언론 보도가 늦게 단번에 서비스가인지되는 것은 상당히 어렵습니다.

따라서 큰 불꽃 놀이를 노리는 것이 아니라, 지속 가능한 비용과 자원 거는 방법으로 자신들에 있던 마케팅 · PR 방법을 모색하고 있습니다 .

또한 검색에서의 유입은 어느 정도 안정된 신규 획득시킬 수 있으므로 처음부터 힘을 넣어 왔습니다. 기본적으로 콘텐츠 마케팅을 중심으로 노력하고 있습니다 .

엔지니어 집단이 임한 디지털 마케팅은 하나 하나이면서도 지속적인 개선을 거듭하는 것으로 적지 않은 인바운드 획득까지 이르렀습니다.

6. 수탁 및 자사 서비스의 균형

처음에는 꽤 고생했습니다.

수익은 수탁에 의존하고 있기 때문에, 아무래도 수탁가 바빠지는 자사 서비스의 개발이 속도 다운 버립니다.

"자사 서비스를 궤도에"는 각오하에 계속 가능한 자원 배분에서 "우선 자사 서비스 자원을 확보"하고 그것을 전제로 위탁 영업 및 스케줄링을 할 수 있도록하고는 안정 균형을 유지할 수있게되었습니다. 이 균형 유지 방법은 많은 수탁 회사 씨에게 도움이 될 것이라고 생각합니다.

7. 요구 대응의 정리 방법과 판단 기준의 확립

요구 대응의 판단 기준은 수탁과 180도 다르기 때문에 처음에는 꽤 고생했습니다.

아웃소싱의 경우, 고객의 요구를 구현하게되는 경우가 대부분이지만, 클라우드 서비스에서 저 자세로 할 수 없습니다.

그래서 현재는 다음 사항을 자문 자답하고 우선 순위를 정리하고 있습니다.

· 자신이 그 기능을 원하는지 (가장 중요) 
· 자신이 사용하지 않는 기능의 경우 납득이 있는지 (사용하지 않는 입장에서 그 필요성을 이해할 수 있는가) 
· 자사 서비스 (board)의 방향성 답게 있는지

또한 요망의 정리에 Trello를 사용하고 있습니다 만, 자세한 내용은 연재의 제 7 탄 정도의 타이밍에 쓰고 싶습니다.

8. 개발 로드맵 공개

board는 정식 출시 때부터 개발 계획을 블로그에 게시 할 수있게되어, 2015 년 초부터 정식으로 개발 로드맵으로 공개하고 있습니다 .

로드맵 공개는 일반적이지는 않습니다 그리고 "경쟁에 볼 수있는 것은?"질문을받는지만, 경쟁에 보이는만큼 아직 퍼져 있지 않았다입니다, 그것보다 사용자 씨에 이점이 크다고 생각했습니다.

실제 로​​드맵을 공개하고, 그 자세를 평가 해 사용해 주실 분 등도 꽤 호평이었습니다. 제 8 탄은 장점과 개선 사항에 대해 알려드립니다.

9. 개발자 자신에 의한 사용자 지원 및 즉시 레스 대응

사용자 지원은 모두 나 자신이 대답하고 있습니다 만, 기획자 · 개발자 자신이 직접 사용자 지원을하면 사용자가 어떤 점에서 어려움을 겪고 있는지, 무엇이 이해하기 어려운 것인지 등 피부로 느낄 수 수 아주 좋은 입니다.

또한 기본적으로 협의에 들어가있을 때를 제외하고는 즉시 레스하도록하고, 또한 차 답변 시간을 공개 (12 월 6 분!)하는 등 개방적인 자세로 임하고 있습니다.

규모 적으로 콜센터를 정비하거나 독점 서포트 멤버를 넣어 같은 수 없지만 자신들 나름대로있는 것으로, 사용자 지원의 퀄리티를 올리도록하고 있습니다. 채팅 Intercom.io를 사용하고있어서, 이쪽도이 기사의 타이밍 당에서 소개하고 싶습니다.

10. 쓸모없는 물건을 만들지 않는다

쓸모없는 물건을 만들지 않는다는 것은 당연히 그렇게 싶습니다 매우 어려운 것이기도하다 생각합니다.

지금 현재에도 수탁과 병행하여 board의 개발을 진행하고있는 것도있어, 개발 자원이 매우 제한되어 있습니다.

따라서 쓸데없는 것을 만들지 않기위한 궁리로 "○○의 기능을 만드는데 얼마나 시간이 필요하다"라는 자세가 아니라 "이 시간에 뭘 할 수 있는지"라는 관점에서 생각 하여 가능한 한 개발하는 기능을 날카롭게하고 불필요한 것을 만들어 버리지 않도록 맡고 있습니다.

수많은 도전에서 실패도 많이있었습니다. 이번에 소개 한 「10 일」은 그 도전 중에서도 "수탁 회사가 해결할 수, 효과적으로이었다"고 생각하는 것입니다.

이번에 소개에서 소개시켜 주셨습니다 만, 다음번에서 각각의 항목을 깊이 파고 쓰고 싶다고 생각합니다. 자사 서비스의 개발에서 궤도에 오를 때까지 모든 것을 洗いざらい 이야기합니다. 하나라도 많은 기업에게있어 팁이 되었으면합니다.