자료는 작성한 6분 후에 구식이 되었다

이전 글에서 교훈 52건을 나열하여 네 가지 유형으로 정리했다고 썼다.

그 후, 기록 전체를 다시 세어보았다. 교훈은 총 71건이었다.

업무와 관련된 것을 제외하고 69건을 재정리하자, 유형은 7가지가 되었다.

실패 사례도 세어보았다. 반년 치 채팅에서 찾아낸 실패는 223건이다.

1건씩 읽고 분류해 보니, 교훈과는 다른 데이터임에도 불구하고, 똑같은 7가지 유형이 나타났다.

그리고 가장 많았던 유형은 '쓰여 있는 내용과 실제가 다르다'였다.

41건이다. 223건의 18%를 차지하며 2위와는 9건 차이가 났다.

덧붙이자면, 이전 글에서 '제38판'이라고 썼던 인수인계 문서는 현재 제49판이 되었다.

교훈은 52건에서 71건으로 늘었고, 하지 않기로 결정한 것은 11건에서 25건으로 늘었다.

'아마 완성하지 못할 것 같다'고 썼던 대로가 되었다.

유형이 늘어난 것이 아니다. 수가 늘어나서 보인 것이다. 52건으로는 네 가지밖에 보이지 않았다.

첫 번째 글에서 이렇게 쓴 적이 있다.

자료에는 '인터넷에 연결하지 않는다'고 쓰여 있었는데, 실제로는 외부 통신이 3개 계통 있었다는 내용이었다.

그것은 이 41건 중 2건에 불과했다.

나머지 39건은 외부 통신과는 관련이 없다.

인수인계 자료, 절차서, 프로그램 내부 주석, 남은 태스크 목록, 기록에 쓰여진 건수, 줄 수, 날짜 등.

그 모든 것이 실제와 어긋나 있었다.

그 글을 쓸 때, 나는 그것을 사건이라고 생각했다. 유형이었다.

자료 3점 모두에 '표준 라이브러리만으로 구축'이라고 쓰여 있었다.

실제로는 외부 라이브러리를 2개 사용하고 있었다. 표준은 21종이다.

왜 그렇게 썼을까. 실제 코드를 확인하지 않고, 이전의 기술 문서를 그대로 인계받고 있었던 것이다.

발각 계기는 AI에게 예상 질문을 만들게 한 것이었다.

'사용하는 라이브러리 목록은?'이라는 질문이 나왔고, 답변하려다 깨달았다.

설명 당일에 물어봤다면, 그 자리에서 모순점을 지적당했을 것이다.

수정 방법은 모든 소스 코드에서 로드 선언을 기계적으로 추출하여 실측하는 것으로 했다.

기술 자료의 '기록 기능 설명 한 곳 수정'만 할 예정이었다.

전체를 읽어보니, 데이터 보관 장소가 이사 전 오래된 장소로 그대로 쓰여 있었다.

구현 완료된 기능이 '미구현' 상태였다. 실제로는 존재하지 않는 파일이 2개나 적혀 있었다.

당초 수정할 예정이었던 곳은 4곳이었다. 실제로 발견된 오래된 기록은 20곳이었다. 그중 중요도가 높은 것이 3건이다.

왜 이렇게 될까. 기능을 개수할 때, 자료를 그때마다 고치는 운영이 아니었다.

개수는 기록을 남긴다. 자료의 업데이트는 누구도 독촉하지 않는다.

부분 수정 대신 전체 개정으로 전환했다.

부분적으로 고치면, 수정한 부분과 오래된 부분이 섞여서 '어디가 최신인지 알 수 없는 자료'가 되기 때문이다.

개정된 절차서에는 화면에 없는 버튼 이름이 2개 적혀 있었다. 화면 명칭도 달랐다.

실제 화면을 보지 않고, 구 버전의 기술 문서를 그대로 인계받았기 때문이었다.

스크린샷 8장을 받아서 하나씩 대조하며 고쳤다.

3건 모두, 자료를 작성한 사람은 거짓말을 하지 않았다.

작성 시점에는 정확했거나, 정확하다고 믿고 있었던 것이다.

정리할 대상으로는 3일분・7항목이 목록에 나열되어 있었다.

실제로 남아있던 것은 1일분・2항목이었다.

치워야 할 것이 목록에서 사라지지 않았다.

다른 목록에는 '2권 보관'이라고 쓰여 있었지만, 실재는 1권이었다.

개정 리스트에 있는 항목만 고칠 생각으로 자료를 열었다.

전체를 읽어보니, 목록에 없는 차이가 자료마다 여러 곳에서 발견되었다.
운영 인계서에 9건, 절차서에 2건, 다른 절차서에 2건. 총 13건.

개정 리스트는 '이전에 발견한 것'의 모음이었다.
자료 전체의 일관성을 보장하는 것은 아니었다.

인수인계 자료에는 '최신 버전은 현행 폴더에서 관리'라고 쓰여 있었다.

그 폴더는 존재하지 않았다.

자료 목록에는 16종류가 적혀 있었지만, 그 계층에는 0건이었다.

절차서는 3주 전 버전 그대로였고, 인수인계 자료는 18판이나 오래된 것이 놓여 있었다.

자료에 운영 규칙을 쓰면서, 실제 폴더에 적용하지 않은 채 판본을 쌓아 올리고 있었다.

재고 조사 목록에서 빠진 자료를 찾아보았다. 발견한 것은 이름만 비슷한 다른 물건이었다.

만든 것은 기억하고 있었다. 현존하는지 확인하지 않은 채, 확인 사항으로 계속 인계받고 있었던 것이다.

목록은 만든 순간의 실태를 담고 있다. 그 이후의 실태는 담고 있지 않다.

여기까지는 아직 알 수 있다. 시간이 지나면 구식이 된다.

알 수 없었던 것은 다음 이야기였다.

인수인계 기록에 '자료 B는 완성 완료・빈칸 없음'이라고 쓰여 있었다.

그 기록が作られた 6분 후에, 자료 B가 추가 수정되었다.

파일 이름은 바뀌지 않았다.

그래서 파일 이름만 보고는, 기록과 실물의 어느 것이 최신인지 판단할 수 없다.

알아차린 것은, 전후 화면에 찍힌 파일 크기와 업데이트 시각을 대조해 보았기 때문이다.

26KB가 31KB로 바뀌어 있었다. 업데이트 시각은 11시 43분에서 12시 31분이다. 기록이 작성된 것은 12시 25분이다.

6분.

인수인계 문서에 이렇게 쓰여 있었다.

'7개 항목 중 3개 항목은, 같은 날 오전에 수정으로 처리되었을 가능성이 높다'.

실물을 열어보니, 3개 항목 모두 미대응이었다. 7개 항목 전부가 남아있었다.

자료가 잘못된 것이 아니었다.

같은 날 오전에 올바르게 수정한 내용이, 오후 작업에서 구식이 되어 있었다.

오전 시점에 올바르게 작성한 버전 표기가, 오후 교체로 올라갔다.

오전에 한쪽 챕터만 고치고, 나머지 부분까지 손을 댈 여유가 없었다.

오전에 '복구할 방침'이라고 쓰고, 오후에 '복구하지 않음'으로 방침을 바꿨다.

교훈으로 한 줄 추가했다. '대응했을지도 모른다'는 것은 반드시 실물로 확인해야 한다.

인수인계 문서에는 전송된 메일 문안이 옮겨 적혀 있었다. 그것을 보고, 독촉 메일 초안을 만들었다.

자료의 참조 페이지가 5곳, 작성 및 서명 부분에 2곳.

실제로 보낸 것과 총 7곳이나 달랐다.

옮겨 적었을 당시에는 정확했다. 그 후에 자료 버전이 바뀌고, 기록만 구식으로 남아 있었다.

그대로 보내면, 받는 쪽에서 자료를 열어도 해당 위치를 찾지 못했을 것이다.

전송된 메일의 실물 파일을 받아서 거기서 다시 만들었다.

체크리스트 서문에 '표시가 된 4개'라고 쓰여 있었다. 표 아래 주석에도 '4개 항목'.

표 실물을 세어보니, 표시는 5개나 있었다.

그리고, 인수인계용 문서가 이 잘못된 숫자를 그대로 베껴 적었다.

기록은, 쓰여진 순간부터 구식이 되기 시작한다.

'언젠가 구식이 될 것'의 이야기가 아니다. 작성한 6분 후에는, 이미 달라져 있는 것이 있을 수 있다.

설정 파일을 다시 만들기 위해 실물을 읽었다.

절차 주석이 '이 파일을 수정하고 재시작하면 반영됩니다'로 끝나 있었다.

그대로 하면, 툴이 열리지 않는다.

운영을 '재시작 후 수동으로 프로그램을 실행하는' 방식으로 바꿀 때, 설정 파일 쪽 코멘트를 고치지 않았다.

절차를 4단계에서 8단계로 다시 썼다.

자료 확인을 위해 프로그램을 읽어보니, 그 코멘트에도 존재하지 않는 파일로부터의 시작 방법이 쓰여 있었다.

구현된 창구 3개가 목록에서 빠져 있었다.

어떤 함수의 코멘트에는 '복사하지 않음'이라고 쓰여 있었다. 실제 코드에서는 복사되어 있었다.

인수인계 문서에 '절차서 버튼 이름이 잘못 적혀 있다'는 전달 사항이 있었다.

실물을 확인하니, 절차서는 원래부터 정확했다. 잘못된 것은, 전달 사항 쪽이었다.

코드 코멘트는 코드의 일부처럼 보인다. 자료와 똑같이, 구식이 된다.

41건의 '왜 발생했는지'를 나열해 보았다. 나온 것은 대략 이 5가지였다.

• 가장 많았던 것은,
  실물을 보지 않고, 이전 기술을 인계한 것-
  다음은,
  일부만 고친 것. 슬라이드와 대본, 챕터와 챕터, 자료와 자료-
  개수정할 때,
  자료를 고치는 운영이 없었던 것-
  쓴 순간부터 구식이 된다는 것. 6분 후와, 오전과 오후의 경우. 건수는 적지만, 이것이 가장 찾기 어려운 것-
  '완료'의 정의가 통일되지 않았던 것. 개정은 끝났으나 배포가 남아있는 것을 '완료'라고 부를지 말지

공통된 것은 1가지였다.

쓴 사람은, 작성 시점의 실태를 쓰고 있다. 실태는 그 후에 움직인다. 자료는 움직이지 않는다.

어긋나는 것은, 자료가 나빠서가 아니다. 시간이 흘렀기 때문이다.

이전 기사에서 '쓰여진 것을 의심하라'고 썼다.

의심해야 할 상대는, 자료가 아니었다. 자료를 작성했을 때의, 자신이었다.

41건의 '어떻게 고쳤는지'에서 반복적으로 나온 것을 5가지.

① 고치기 전에, 전체로 읽고 세어보기 개수정 목록 항목만 보지 않는다. 단어 출현 건수를 세어서 파악한 후 고친다. 목록 외의 13건은 이것으로 나왔다.

② 기록으로는 만들지 않는다. 실물을 받는다 메일 문안, 버튼 이름, 라이브러리 목록. 기록은 실물의 복사본이지, 실물이 아니다.

③ 파일 크기와 업데이트 시각을 본다 파일 이름은 거짓말하지 않지만, 아무것도 말해주지 않는다. 6분의 차이는, 시각으로만 발견할 수 있었다.

④ '대응했을지도 모른다'는 현장에서 확인하라 오전과 오후로 달라진다. 기억은 근거가 될 수 없다.

⑤ 고치지 못하는 것은 '특정 불가'라고 적어 남겨라 수정 전 파일이 덮어쓰여져서 무엇이 사라졌는지 알 수 없었던 경험이 있다.

확인된 8점을 쓰고, 삭제된 부분은 특정할 수 없다고 명시했다.

모르는 것을 모른다고 쓰는 것도 기록의 일부다.

위 다섯 가지 모두 자료를 올바르게 작성하는 방법은 아니다.

자료가 어긋나 있다는 전제하에, 그 어긋남을 빨리 찾아내는 방법이다.

이전 글에서 '오류가 없는 실패'를 썼을 때와 같은 결론에 다른 경로로 도달했다.

41건을 나열해 보니, 자료는 완성되지 않는다는 것이 아니었다.

완성되는 순간부터, 오래된다.

그래서 자료를 의심하는 것을 그만두고, '이 자료가 언제의 실태를 담은 것인가'를 먼저 보게 되었다.

이전 글의 마무리는 '대화를 남기지 말고. 결정을 남겨라'였다. 그것은 변하지 않는다.

다만, 결정을 남긴다 해도, 결정은 나중에 바뀐다.

남긴 결정에 날짜를 붙여라. 그것만으로도 의심해야 할 순서를 알 수 있다.

자료는 작성한 사람의 기억보다 빨리 오래된다. 6분 만에.

이 글은 Zenn에도 게재되어 있습니다.