위키북스 IT Leaders 시리즈 21권. 이 책은 여러 IT 분쟁 사례를 비롯해 저자가 IT 기술자였던 시절과 컨설턴트 시절에 겪은 경험을 바탕으로 프로젝트의 실패 원인을 분석하고 해결책을 고민해 정리한 책이다. '아리스카와 도코'라는 가상의 IT 전문변호사를 중심으로 시스템 개발 중에 발생하는 각종 문제를 이야기 형식으로 풀어 구성했으며, 책에서 제시한 해결 방안은 실제 IT 소송이나 현장의 분쟁 사례를 근거로 했다.

머리말
이 책이 전제로 하는 개발공정
등장인물

▣ 1장: 요구사항 정의 (말했다 VS. 안 했다, 하기로 했다 VS. 안 했다)
CASE 1 발주자가 요구사항을 계속 추가할 때
CASE 2 요구사항 정의란 도대체 무엇인가?
CASE 3 발주자가 요구사항 정의를 벤더에게 전담할 때
CASE 4 소프트웨어 패키지의 함정 ①
CASE 5 소프트웨어 패키지의 함정 ②
CASE 6 확정되지 않은 요건은 어떻게 처리할까?
CASE 7 벤더가 멋대로 성능 요건을 제외했을 때
CASE 8 요구사항 변경의 영향 범위를 파악할 수 없을 때
CASE 9 발주처 담당자가 벤더와 친할 때
CASE 10 요구사항 정의 없이 개발했을 때
CASE 11 업무 요건에 누락된 요소가 있을 때
CASE 12 시스템 개발 범위는 어떻게 정할까?
DATA
요구사항 정의서 체크리스트
비기능적 요구사항 개요
요구사항 추적 매트릭스 예시
COLUMN 1
IT 분쟁 판결까지 얼마나 걸릴까?

▣ 2장: 프로젝트 계획과 관리 (일정표 체크만이 관리는 아니다)
CASE 13 프로젝트 위험 관리는 어떻게 할까?
CASE 14 벤더는 발주자 측 위험요소를 어떻게 관리해야 할까?
CASE 15 벤더가 진척도를 거짓으로 보고 했을 때
CASE 16 발주자가 위압적인 태도를 보일 때
CASE 17 발주자의 참여의식을 높이려면 어떻게 해야 할까?
CASE 18 핵심 팀원이 병으로 쓰러졌을 때
CASE 19 벤더를 변경했는데 프로젝트 관리자까지 퇴사했을 때
CASE 20 프로젝트 계획서는 어떻게 써야 할까?
DATA
프로젝트 계획서 기재항목 예시
프로젝트 관리 계획 기재항목 예시
WBS(Work Breakdown Structure: 작업분류체계)와 EV(Earned Value: 획득가치)
COLUMN 2
사회적 통념에 따른 판결

▣ 3장: 설계 (벤더와 발주자가 협의할 사항)
CASE 21 산출물을 객관적으로 검토할 수 있는 사람은?
CASE 22 체크리스트는 어떻게 활용해야 할까?
CASE 23 발주자가 만든 요구사항 정의서에 누락된 사항이 있을 때
CASE 24 검수한 시스템에서 설계 오류가 발견됐을 때
CASE 25 설계서에도 저작권이 있을까?
CASE 26 설계 단계에서 소프트웨어 패키지가 부적합하다고 밝혀졌을 때
CASE 27 소프트웨어 패키지의 결함은 어떻게 평가할까?
DATA
설계서 체크리스트
COLUMN 3
조정을 신청하면 손해 볼 일은 없다?

▣ 4장: 프로그래밍 (작동만 하면 끝이 아니다)
CASE 28 프로그래밍 순서는 어떻게 정할까?
CASE 29 사소한 버그를 내버려두면 큰 손해를 입는다
CASE 30 문제 해결 우선순위는 어떤 기준으로 판단할까?
CASE 31 보안 정보는 어디까지 파악해야 할까?
CASE 32 프로그램 품질을 어떻게 개선해야 할까?
DATA
소스코드 체크리스트
COLUMN 4
조정위원을 얕보지 마라

▣ 5장: 테스트 (뭘 테스트해야 하는지 아는가?)
CASE 33 테스트를 효과적으로 하려면 어떤 준비가 필요할까?
CASE 34 프로젝트 완료는 무엇을 기준으로 판단할까?
CASE 35 발주자는 산출물의 품질을 어떻게 평가해야 할까?
CASE 36 컴퓨터 시스템 검수란 무엇일까?
CASE 37 검수 후 오류가 발견되면 어떻게 해야 할까?
CASE 38 불특정 다수가 사용하는 시스템은 어떻게 테스트해야 할까?
DATA
개발용 SLA(Service Level Agreement: 서비스 수준 협약) 사례
검수 계획서, 테스트 시나리오 체크리스트
COLUMN 5
IT 변호사란?

▣ 6장: 계약과 프로젝트 완료 (뭘 약속했지?)
CASE 39 프로젝트 책임자의 역할은? ①
CASE 40 프로젝트 책임자의 역할은? ②
CASE 41 시스템 개발 계약서에는 어떤 사항이 들어가야 할까?
CASE 42 개발 규모가 원래 산정했던 견적보다 커졌을 때
CASE 43 계약서 없이 프로젝트를 진행하면 어떤 문제가 생길까?
CASE 44 프로젝트 관리의 중요성
CASE 45 가발주서만 접수하고 작업을 시작했을 때
CASE 46 프로젝트에 외부 자문인력이 꼭 필요할까?
CASE 47 도코가 보낸 메일
CASE 48 「발주자의 신의성실의 원칙」이란?
CASE 49 프로젝트 성공 모델은?
DATA
소프트웨어 계약 시 포함해야 하는 조항
COLUMN 6
IT 분쟁을 피하려면?

도쿄지방재판소 민사 조정위원(IT 사건담당) 겸 IT 전문위원. 도쿄고등재판소 IT전문위원. 1964년 가나가와 현 출신. 릿쿄 대학 경제학부 졸업. NEC 소프트웨어 주식회사에서 금융 정보 시스템과 네트워크 시스템 개발, 운용. 2005년부터 2012년까지 일본 IBM 주식회사에서 시스템 개발, 운용 업무 품질 향상 컨설팅. 이밖에 수많은 IT 벤더와 IT 기업의 프로세스 개선 컨설팅. 2007년 세계적으로도 몇 안 되고, 일본에도 수십 명밖에 없는 IT 사건 담당 민사 조정위원으로 추천돼 취임. 현재까지 많은 IT 분쟁 해결에 이바지하고 있다. 이러한 경험을 토대로 얼터너티브 블로그에 「IT 분쟁 이모저모」를 연재 중으로, '왜 시스템 개발만 하면 싸워댈까?'가 첫 저서다.