約束した日に終わらないかもしれない。でも原因も完成日も、まだはっきりしない。そんな段階でも、いまの状態と必要な相談は先に共有できます。
先に結論
- 完了・残作業・期限への影響を伝える。完全な原因分析や回復時刻が出るまで待たない。
- 現状と、決めてほしいことを分ける。期限・範囲・支援のどこを調整したいか示す。
- 次に状況を返す時点を決める。完成の約束とは区別し、未確認でも続報する。
題材は、問い合わせ管理へ必須・1〜100文字の件名を追加する架空の改修です。以下の期限や時刻も説明用で、実際の予定や成果の報告ではありません。
「80%」より、完了と残作業を伝える
「進捗80%」が「もうすぐ渡せる」なのか「コードはほぼ書けた」なのかは、人によって違います。割合を使うチームでも、それだけで終えず、次の情報を添えます。
- 終わったこと：件名の入力・保存・一覧表示の実装。
- 残作業：境界条件の確認、レビュー指摘の修正。
- 止まっていること：既存データの件名をどう扱うかの仕様確認。
- 影響：予定した検証担当への引き渡しが難しい。
- 相談：仕様の決定者への確認と、引き渡し予定の調整。
この例なら、実装の手伝いより、仕様を判断する人につなぐ支援が必要だと分かります。調査不足か資料不足かを決めきる前でも、どこで止まっているかは伝えられます。
三つの場面の報告例
遅れそうだが、残作業は見えている
記入例｜遅れの予兆
- 現状・残作業：明日午前の引き渡しが難しくなりそうです。件名追加は実装済みですが、100文字・101文字の確認と、レビュー修正箇所の再確認が残っています。
- 前提の変化：本日予定した検証環境が使えず、確認開始が後ろへずれています。
- 相談：環境の利用枠を調整できるか相談したいです。難しい場合は、引き渡し時点の変更が必要です。
- 次の報告：本日16時に、環境の利用見通しと残作業を改めて共有します。
まだ期限前でも、予定の前提が崩れたら伝えます。「明日は無理」だけでなく、何を調整すれば見通しが変わるかを示します。
完了時点を見通せない
記入例｜仕様確認で止まっている
- 確認した事実：件名が空の既存データを更新すると、保存できないことを確認しました。
- 現状：新規登録の確認は進められますが、既存データの扱いが決まらず、改修全体の完了時点は見通せていません。
- 相談：既存データを補うか、更新時に入力を求めるかで対応が変わります。仕様の判断担当者に確認したいです。
- 次の報告：本日15時までに確認先との連絡状況を共有します。これは完成の約束ではなく、次の状況報告の時点です。
完成日を出せないときは、何が分かれば見積もり直せるかを書きます。原因調査が必要なら、次に調べる対象と結果を共有する時点を決めます。
すでに期限を過ぎている
記入例｜期限超過
- 現状：本日午前の引き渡し予定を過ぎており、未完了です。予定どおり渡せず申し訳ありません。
- 完了・残作業：入力・保存・一覧の実装と新規登録の確認は完了しています。既存データの扱いの確認と、その結果に応じた修正・再確認が残っています。
- 影響・相談：引き渡し可能な時刻は確定できません。検証担当への影響を含め、予定を調整したいです。
- 次の報告：本日14時に、仕様確認の結果と改めた見通しを共有します。
期限を過ぎた事実は、曖昧にせず冒頭へ置きます。謝罪が必要でも、それだけを長く続けず、相手が判断できる影響と調整事項を伝えます。
期限・範囲・支援を相談する
原因が見え始めたら、予定を延ばす、独立して渡せる範囲に分ける、判断や確認を手伝ってもらう、といった案を比べます。人を増やせば進むか、判断待ちの解消が先かも残作業から考えます。
必要な入力チェックや権限確認は、勝手に外しません。何を渡せば目的を満たすか、欠かせない条件は何かを決定者と揃えます。優先順位も一人で変えず、ほかの仕事への影響を示して調整します。作業量と引き受ける条件の相談例も使えます。
変化がなくても、約束した時点で戻る
「確認でき次第」だけでは、相手はいつまで待てばよいか分かりません。確認先の返答時点が不明なら、回答期限を勝手に約束せず、「その時点までの連絡状況を返す」とします。
相談と続報の例
部分的な確認を相談する：
一覧の表示確認は先に進められますが、件名を変更する操作の確認は仕様決定後になります。先に表示だけ確認していただく形に意味があるか、検証担当と相談したいです。
回答待ちのまま続報する：
予定していた時点になりましたが、仕様の回答はまだ得られていません。確認先へ連絡済みです。先に進められる表示の確認を行っています。別の判断者へ相談する必要があるか、確認をお願いします。
部分確認の提案を機能全体の完成に見せず、未解決でも判断が必要な場所を共有します。合意した予定や、誰が何をいつ判断するかは、会話だけでなく予定表・作業管理の記録にも残します。
ここに注意｜障害の第一報とは分ける
この記事は開発作業の遅れを報告する例です。利用者に影響する障害は、チームの障害連絡先・手順を優先してください。通常の進捗報告を待たず、分かっている現象と影響を伝えます。
Spring Bootの500エラーなど、原因未特定の段階での情報整理は、ログの確認順と原因未特定時の連絡例を参照できます。
報告を送る前のチェック
- 終わった作業・残作業・止まっている箇所を分けたか。
- 遅れの予兆か、見通し不明か、期限超過かを明示したか。
- 期限への影響と、決めてほしいことを書いたか。
- 次の状況報告の時点を、完成の約束と区別したか。
- 約束した時点には、変化がなくても続報できるか。
理由を説明しきれなくても、いまの状態は共有できます。まず報告文に、残作業と決めてほしいことを一行ずつ足してみてください。
