不足書類：必要な証拠を依頼し、解決まで確認する

「書類が不足しています」は依頼に見えますが、受け手に問題をもう一度探させています。不完全な書類を解決するには、何を確認できないのか、どの作業がそれに依存するのか、どんな証拠があれば続行できるのかを書きます。この3点は1つの記録に収まります。メッセージのたびに案件全体を説明し直す必要はありません。

このガイドは、管理業務に届く、不完全・矛盾・アクセス不能な書類の調整を扱います。テンプレートは税務上や契約上の有効性を判断しません。読める画像があっても、あらゆる用途に十分な証拠になるわけではありません。得られるものは限定的です。別の人が、なぜ作業を再開できたのか確認できるようにします。

依頼する前に不足を特定する

ファイルを開き、不足箇所を具体的に探します。「正しくない」には、必要な回答が異なる複数の意味があります。別のコピーを求めても、2つの版の矛盾は解消しません。数値を手書きしてもらっても、欠けたページは戻りません。

必要な情報自体がまだ分からないなら、状態は要明確化です。まず作業を実行する人に確認します。「あるものを全部送ってください」は依頼を広げ、問いに答えない不要な情報を集める可能性があります。

事業者と会計担当・事務所の連携（英語）では、この記録は1つの入力と、その確認完了条件を扱います。項目ごとに記録を作る必要はありません。同じ書類の不足で、同じ担当者がまとめて確認できるなら一緒に扱います。

文脈を残す1つの記録

関係者だけがアクセスできる共有記録を使います。複数の経路でコピーを転送する代わりに、元の資料への参照を残します。識別子は依頼、回答、確認をつなぎます。氏名や個人情報を含める必要はありません。

不備ID: [DOC-001]
案件と保留中の作業: [参照 / 行動]
情報源: [制限付きリンク / 版 / 日付]
観察: [欠落 / 判読不能 / 矛盾 / アクセス不能]
依頼: [必要な具体的証拠]
解決条件: [確認者が確かめること]
提供者 / 調整者: [確認済みの担当者]
直近の依頼: [日付 / 経路 / 参照]
次回確認: [合意した日付 / 時刻 / タイムゾーン]
続行可能 / 保留が必要: [作業]
状態: [要明確化 / 依頼済み / 受領・確認待ち / 解決済み / 保留]
回答: [参照 / 版 / 日付]
確認: [担当者 / 日付 / 条件 / 結果]
次の行動: [担当者 / 開始条件]
再開: [理由 / 新しい版 / 前回の解決]

現在の状態とは別に履歴を残します。回答と検証のたびに、日付・版・結果・理由を含む記録を追記し、却下した版も残してください。以前の証拠を上書きしてはいけません。

複数人が情報を提供する場合でも、調整者を1人決めます。その人がすべて解決する必要はありません。依頼を最新に保ち、3人の同僚が同じものを別々の期限で催促するのを防ぎます。提供担当者が実際に証拠を入手できるか確認してください。名前を書くことは、本人が仕事を引き受けたことを意味しません。

相手が回答できる3つの文例

送信前に角括弧を置き換えます。これは文章の提案であり、送信済みのメッセージでも、相手に課した期限でもありません。

最初の依頼：「[参照]では、[観察内容]のため[情報]を確認できません。[作業]を進めるには、[具体的証拠]を[許可された経路]で受け取る必要があります。ご提供いただくか、保有者を教えていただけますか。[日付・時刻・タイムゾーン]に状況を確認しますが、その時点までの返信を前提とするものではありません。」

再確認：「DOC-001は引き続き[証拠]待ちです。[独立した作業]は進められますが、[依存する作業]は保留です。次回確認は[合意した日付]のままとします。入手できない場合はお知らせください。[担当者]と代替策を判断します。」

解決：「[日付]に[版]で[条件]を確認しました。DOC-001は[具体的作業]について解決済みとし、[担当者]が[行動]を再開します。[別の不備があれば記載]は未解決です。この確認は、書類の他の用途を承認するものではありません。」

Atlassianのインシデント連絡テンプレートには、調査とその進捗を伝える例があります。このガイドの3つのメッセージは、解決の文例も含め、書類の依頼に向けた独自の編集案です。技術的な手順を移植したり、同じ応答時間を約束したりするものではありません。

例：ファイルは届いたが、解決していない

実在の書類や人物を使わない学習用の例です。 受領記録R-017の2ページ目が欠けています。管理担当は案件をレビューに回す前に、合意した参照番号と受領個数を照合する必要があります。待つ間に他のファイルを整理できますが、この個数を確認済みにはできません。

調整者はDOC-001を作り、R-017の該当ページを依頼します。最初の回答は「6個でした」。返答は届きましたが、求めた証拠はありません。状態を「受領・確認待ち」にし、条件を満たさない理由を記録してから「依頼済み」に戻します。メッセージは消しません。

2回目の回答では2ページ目を含む版2が届きますが、参照番号はR-018です。ページは存在し、読めます。それでもR-017を完成させるものではありません。調整者は同じ記録に食い違いを書き、相手が改変したなどと決めつけず、該当する書類を依頼します。

版3はR-017に対応し、個数を確認できます。確認者は版、日付、結果を記録します。ここで初めてDOC-001をその確認について終了し、作業を担当者に戻せます。案件の他の情報が不足しているなら、この不備の解決済み表示で隠してはいけません。

通知だけでなく版を確認する

ツールの「承認済み」だけでは、各人がどの変更を見たかは分かりません。例えばGoogle Driveは、設定に応じて編集で承認がリセットされる場合と維持される場合があると説明しています。この機能は対象となるアカウントに限られます。本手法に必要なのは確認した版の明記だけです。承認システムを購入したり有効化したりする必要はありません。

その後ファイルが変わったら、変更が確認済みの条件に影響するか判断します。影響するなら不備を再開し、以前の解決とのつながりを残します。アクセスが問題なら確認者のアカウントで試します。所有者が開けるリンクでも、チームが開ける証明にはなりません。

返信がない場合、何を待たせるかを決める

確認予定日は、状態をもう一度見る時点です。沈黙を承諾には変えません。その日になったら停止している作業を伝え、権限のある担当者に、待つか、順序を変えるか、その作業に適した別の証拠を探すか判断を求めます。リストを空にするために推測で項目を埋めてはいけません。

短い会話で、曖昧な依頼を明確にできることもあります。その後、結論を記録に残します。領収書読み取りのワークフロー（英語）から届いた情報なら、結果を確認する前に原本へ戻ります。納品準備中の人に影響する保留なら、依存関係を見積もりで合意した範囲（英語）と照らし合わせます。

実際に残っている不備を1つ選び、次のメッセージの前に観察内容と解決条件を書いてください。別の人がその記録を読み、何が足りず、誰が提供し、どう確認するか説明できれば、解決可能な依頼になっています。