엔지니어·개발 팀 일일 보고 쓰는 법: 작업 기록으로 끝내지 않고 예상과의 차이와 막힌 곳을 다음 한 수로 잇기

엔지니어나 개발 팀의 일일 보고는 '검색 기능 구현', '리뷰 대응', '회의'처럼 그날 손댄 작업 이름을 늘어놓기만 하는 것이 되기 쉽습니다.

작업의 기록은 중요하지만, 그것만으로는 '왜 예상보다 시간이 걸렸는가', '어디서 막혔고 다음에는 어떻게 피할 것인가'가 남지 않습니다.

게다가 개발 현장에는 작업은 티켓 관리 도구에, 코드 변경은 버전 관리 이력에, 일상적인 대화는 채팅에, 이미 기록하는 곳이 많습니다.

그래서 일일 보고는 같은 내용을 한 번 더 옮겨 적는 일로 보이기 쉬운 것이 실정입니다.

집중해서 작업한 뒤 퇴근 직전에 서둘러 쓰고, 읽은 사람에게서 답도 없으면, 쓰는 쪽은 '진행 있음' 정도의 한마디로 끝내게 됩니다.

PDCA로 말하면 실행(D)의 기록에서 멈추고 평가(C)와 개선(A)이 빠져 버린 상태입니다.

이 글에서는 일일 보고를 '작업 기록의 사본'에서 '그날의 예상과의 차이나 막힌 곳을 돌아보고 다음 한 수와 팀의 배움으로 잇는 도구'로 다시 자리매김하는 쓰는 법을 생각합니다.

누군가를 탓하는 이야기가 아니라 구조에 관한 이야기로 읽어 주십시오.

엔지니어의 일일 보고에 넣을 항목은 다음 정도로 좁히면 계속하기 쉬워집니다. ① 오늘의 목표(어떤 작업을 어디까지 진행할지).

② 예상 시간과 실제 시간의 차이(차이의 크기보다 이유를 한마디로. 사양 확인 대기, 예상하지 못한 기존 코드, 환경의 문제 등). ③ 막혀 있는 일과 누구에게 무엇을 묻고 싶은지.

④ 시도해서 알게 된 것·배운 것. ⑤ 리뷰나 회의에서 정해진 일 중 내 작업과 관련된 것. ⑥ 내일의 첫 한 수.

포인트는 티켓이나 코드 변경 이력에 이미 있는 '무엇을 했는가'를 일일 보고에서 되풀이하지 않고, 차이와 이유, 막힌 곳, 배운 것으로 좁히는 것입니다.

반대로 '설계의 전제를 확인하지 않고 쓰기 시작해서 중간에 되돌아가는 작업이 생겼다', '선배에게 로그 보는 법을 물었더니 10분 만에 오류가 해결됐다' 같은 알아차림은 티켓에도 변경 이력에도 남지 않습니다.

이는 일일 보고에서만 건져 올릴 수 있는 정보입니다. 칸을 너무 늘리면 쓰는 시간이 길어지고 빈칸이 늘어납니다. 처음에는 5개 안팎으로 시작해 팀의 의견을 들으며 더하고 뺍니다.

일일 보고 PDCA의 형식은 P(오늘의 목표)·D(실제로 한 일)·C(알아차림)·A(다음에 어떻게 할지)와 다음 날의 P, 이렇게 다섯 가지입니다.

기능 개발을 맡은 엔지니어를 예로 들어 보겠습니다(설명을 위한 가상의 예입니다). P는 '검색 화면의 필터 기능을 리뷰에 낼 수 있는 단계까지 진행한다'.

D는 '구현은 끝났지만 기존 목록 표시와 정렬 순서의 사양이 맞지 않아, 확인과 수정에 예정보다 2시간이 더 걸렸다. 리뷰에는 내지 못했다'.

C는 '정렬 순서의 사양을 쓰기 시작하기 전에 확인하지 않았다. 티켓의 설명만 보고 진행한 것이 원인'.

A는 '화면과 관련된 작업은 착수 전에 사양에서 헷갈릴 만한 점을 3개 적어 두고, 담당자에게 먼저 확인한다'. 다음 날의 P는 '오전 중에 리뷰에 낸다.

다음 작업은 확인할 점을 적어 둔 뒤에 시작한다'. 다음 날의 P로 잇는 요령은 A를 '다음에 할 구체적인 한 가지'로 쓰는 것입니다.

'확인을 철저히 한다'가 아니라 '착수 전에 헷갈릴 만한 점을 3개 적는다'라고 쓰면, 다음 날의 일일 보고에서 했는지 못 했는지를 확인할 수 있습니다. 각 칸은 1~3줄이면 충분합니다.

입사한 지 얼마 안 된 엔지니어나 경험이 적은 멤버의 일일 보고는, 막힌 곳을 혼자 끌어안지 않고 일찍 꺼내는 자리도 됩니다(설명을 위한 가상의 예입니다).

P는 '테스트 환경에서 재현되는 버그의 원인을 찾는다'.

D는 '오전 내내 원인을 찾았지만 특정하지 못했고, 오후에 리더에게 상담하니 설정을 읽어 들이는 순서가 잘못되어 있었다는 것을 알았다'. C는 '혼자 조사하는 시간을 정해 두지 않았다.

물어보면 빠르다는 걸 알면서도 조금만 더 하면 알 것 같아서 말을 걸 때를 놓쳤다'. A는 '조사를 시작하고 1시간이 지나도 실마리가 없으면, 무엇을 시도했는지 적어서 상담한다'.

막힌 곳을 쓰는 것은 못 하는 일을 보고하기 위해서가 아니라, 팀이 빨리 손을 빌려줄 수 있게 하기 위해서입니다.

읽는 쪽의 리더나 선배가 상담해 준 것을 먼저 한마디로 받아 주고, 다음에 조사할 때의 실마리를 하나만 돌려주면, 멤버는 안심하고 막힌 곳을 쓸 수 있게 됩니다.

막힌 곳을 썼다는 이유로 탓하는 답은 피합니다.

개발 현장에는 작업의 진행 상황을 관리하는 티켓, 코드 변경 이력과 리뷰 기록, 장애나 버그의 대응 기록, 근태 기록 등 이미 정해진 기록이 있습니다.

이것들은 회사의 규칙이나 정해진 절차에 따라 각각의 자리에 남기는 것입니다. 일일 보고는 그것을 대신하지 못합니다.

일일 보고에 장애의 경과를 써도 정식 대응 기록으로 다룰 수 없다고 생각해 주십시오.

선 긋기의 기본은, 작업이나 버그마다의 사실은 티켓 같은 정해진 기록에 정해진 절차대로 남기고, 일일 보고에는 우리 자신의 움직임과 알아차림, 다음 한 수를 쓰는 식으로 나누는 것입니다.

일일 보고에서 그 기록들을 언급할 때는 티켓 번호나 '대응 기록에 기입 완료'라는 한마디를 덧붙이면 충분합니다.

이 선을 처음에 그어 두면 같은 내용을 두 번 쓰는 부담이 줄고, 일일 보고가 '중복된 진행 보고'가 아니라 '돌아보기의 자리'로 남습니다.

어떤 기록을 어디에 남길지는 회사의 규정과 책임자의 판단을 따라 주십시오.

일일 보고의 C 칸에는 '운영 환경의 동작이 평소보다 느린 것 같았다', '설정 파일에 인증 정보가 그대로 적혀 있는 것을 발견했다' 같은 내용이 나올 때가 있습니다.

이런 일은 일일 보고에 쓰고 끝내지 말고, 회사나 팀이 정한 대응 절차로 잇습니다.

장애가 의심되거나 보안과 관련된 일을 알아차렸을 때는 일일 보고를 쓸 때까지 기다리지 말고 그 자리에서 리더나 책임자에게 알리고, 회사의 절차와 책임자의 판단을 따라 주십시오.

원인이나 영향 범위를 일일 보고 안에서 단정하지 않는 것도 중요합니다.

또 비밀번호나 키, 접속을 위한 정보, 사용자의 개인 정보나 거래처에서 맡은 데이터는 일일 보고에 쓰지 않는 운영을 해 두면 안심입니다.

일일 보고는 '알아차렸다'는 입구이지 대응 그 자체가 아닙니다. 일일 보고에 '리더에게 보고 완료'라고 한마디 써 두면, 읽는 쪽은 정식 대응으로 이어졌는지를 확인할 수 있습니다.

리더는 멤버의 일일 보고를 매일 읽게 됩니다. 전부를 꼼꼼히 읽으려 하면 계속하기 어렵습니다.

그러므로 A(다음에 어떻게 할지)부터 읽고, 이어서 C(알아차림)와 막힌 곳의 칸에서 도와야 할 일이나 오늘 안에 정해야 할 일이 없는지 확인합니다.

돌려주는 코멘트는 사실을 한마디로 받아 주고, 질문이나 다음 한 수를 하나만 덧붙이는 형태로 하면 계속하기 쉬워집니다.

예를 들어 '착수 전에 헷갈릴 만한 점을 적어 두는 방안, 좋네요. 내일 작업에서 몇 개가 나왔는지 알려 주세요' 같은 답입니다.

재택근무가 많은 팀에서는 일일 보고를 작업 시간을 감시하는 데 쓰지 않고, 막힌 곳을 빨리 건지기 위한 도구로 다루는 것이 솔직하게 써 주기 위한 전제가 됩니다.

일주일에 한 번은 한 주의 일일 보고를 나란히 놓고 돌아봅니다.

KPT(계속할 것·문제·시도할 것)의 형식으로, 같은 종류의 되돌아가는 작업이나 예상과의 차이가 반복되고 있지 않은지, 시도한 궁리가 어땠는지를 이야기합니다.

그러면 한 사람의 알아차림이 팀의 일하는 방식의 개선으로 이어집니다. 일일 보고 PDCA의 주간 요약을 쓰면 한 주 분량의 알아차림을 한꺼번에 돌아볼 수도 있습니다.

제출하지 않은 날이 있어도 먼저 탓하지 말고 이유를 묻고, 칸이나 쓰는 시각이 개발의 진행 방식에 맞는지를 다시 살펴봅니다.

일일 보고 PDCA에서 AI는 일일 보고의 초안, 돌아보기를 돕는 질문, 주간 요약을 거드는 보조 역할입니다. 개발 팀에서도 이 선은 달라지지 않습니다.

멤버의 짧은 메모를 다듬거나 한 주의 일일 보고에서 반복되는 막힌 곳이나 되돌아가는 작업을 골라내는 식으로 쓸 수는 있습니다.

하지만 작업의 우선순위를 어떻게 바꿀지, 예상을 어떻게 고칠지, 누구에게 어떤 일을 맡길지 같은 판단은 리더나 책임자가 합니다.

비밀번호나 키, 사용자나 거래처의 정보처럼 회사 밖으로 낼 수 없는 정보는 일일 보고에 쓰지 않는 운영을 해 두면 안심입니다.

일일 보고 PDCA는 일일 보고 데이터를 이용하시는 기업, 곧 독자 여러분의 회사 자신의 Google 드라이브(스프레드시트)에 기록하는 설계입니다.

당사 쪽에 정보를 쌓아 두지 않는 최소 데이터 보유의 사고방식을 따르고 있습니다. 정해진 기록과 역할을 나누고, 짧은 형식으로, 답이 돌아오는 일일 보고를 계속한다.

그 축적이 매일의 작은 막힘과 배움을 다음 한 수와 팀의 개발 방식 개선으로 바꾸는 토대가 된다고 생각합니다.