プロジェクト進捗報告の自動化：8つの情報源と記入例

この報告で何を判断してよいかを決める

進捗報告は、読み手が次の行動を決めるための文書です。すべてのタスク更新を転記するものでも、別のプロジェクト計画書を作るものでもありません。スポンサーには依存関係の解消や変更承認が必要かもしれません。実行チームには、阻害要因、担当者、次の確認時点が必要です。同じ事実から詳しさの異なる版を作ることはできますが、読み手ごとに事実そのものを変えてはいけません。

Atlassianのプロジェクト進捗報告ガイドは、状況、障害、次の対応を簡潔に伝える報告を説明しています。自動化では、さらに「報告の取り決め」が必要です。どの規則で情報をまとめ、誰の確認を経て発行するかを定義します。

プロジェクトID、読み手、対象期間、タイムゾーン、承認済み計画の版、必須資料、状態の定義、レビュー担当、配布先を書き出します。時間も3つに分けます。状態の基準時点は、いつまでの状態を報告するか。情報の締切は、その版にどこまでの既知情報を含めるか。発行時刻は、確認済み文書をいつ出したかです。同じ時刻である必要はありませんが、混同しないことが重要です。

Microsoftは、プロジェクトの状況報告日が当日と異なる場合を説明しています。ここで追加する情報の締切は、別の問題への対策です。月曜日に届いた金曜日の出来事に関する連絡を、金曜日の発行時点ですでに知っていた情報として扱わないためです。過去の報告を訂正するときも、この違いを残します。

評価する各観点について、赤・黄・緑、すなわちRAGの条件を決めます。この記事のRAGは進捗状態の色分けであり、検索拡張生成を意味しません。適用される情報が欠けている場合には「不明」を追加します。判定には理由、情報源、責任者が必要であり、報告メールの楽観的な語調で決めるものではありません。何日遅れたら必ず黄や赤になるかという一律の正解はありません。プロジェクトに合った基準を合意し、規則の版を残します。

また、報告を準備する権限と、行動を承認する権限を分けます。回復案を掲載しても、その案が承認されたことにはなりません。文章を整える都合で、報告アシスタントが基準計画を変更し、リスクを終了扱いにし、支出を承認し、新しい納期を外部に約束してはいけません。

情報の品質とプロジェクトの状態を別々に確認する

各入力に、情報源ID、責任者、版または出力時刻、対象期間、確認可能な参照先を付けます。異なるシステムで同じ項目名が使われていても、結合前に意味を確かめます。タスクの「完了」は実装作業の終了を指し、マイルストーンの完了には指定責任者による受入結果の確認が必要、ということがあります。

資料の状態は、利用可能で適用範囲内、古いまたは対象期間が不足、不一致あり、未入手、理由付きで適用外、といった区分で管理できます。古い文書が必ず無効とは限りません。変更されていない承認済み計画は有効なままです。逆に、1分前に出力した財務ファイルでも、計上済み取引は前日までしか含まれていないかもしれません。

2つの記録が食い違う場合、新しい方を自動的に優先してはいけません。判断する内容によって、基準となる記録が異なります。受入承認の有無は受入記録、タスクの状態はタスク記録、基準計画の変更は承認された変更記録で確認します。未解決の不一致は、質問、回答責任者、期限を付けた例外リストに残します。

例えば「T04は完了しているが、M2は受入未承認」は、必ずしもデータの誤りではありません。T04の範囲が、失敗も含めてテスト結果を記録することなら、両方が正しい場合があります。問題は、報告が作業終了を成果の受入承認に読み替えることです。どちらかの記録を変更するよう依頼する前に、タスクと成果物の関係を確認してください。

8つの情報源：収集する項目と読み取り方

1. 承認済み計画とベースライン：比較の基準を残す

承認された対象範囲、期待する成果、基準日程、予算、受入条件から始めます。ベースラインとは比較の基準となる計画です。今日の編集可能な計画のコピーだけではなく、そのIDと承認記録を保管します。Microsoftのベースラインに関する説明では、後のプロジェクト情報と比較するための基準値の保存を扱っています。

当初のベースライン、現在承認されているベースライン、現在の予測を別々に記録します。変更案は、必要な権限者が承認するまで意思決定の欄に置きます。そうしないと、週次処理が目標日を予測日に合わせて更新し、毎週「遅延なし」と報告することになりかねません。

正当にスコープが変更された場合には、承認根拠と比較可能性への影響を示します。作業が除外されたことで見かけの進捗が回復したなら、改善をすべて作業速度の向上に帰してはいけません。何が変更され、現在どの計画が有効で、どの過去比較が同条件ではなくなったかを説明します。広く配布する要約に不要な機密商条件を含めないことも必要です。

2. タスク管理：処理件数とプロジェクト完了を区別する

固定のタスクID、スコープ上の所属、状態遷移、担当者、阻害要因との関連を収集します。対象期間の開始時に約束した仕事と、期間内に追加・中止された仕事を分けます。締切時点の状態を保存し、現在のボードを取得して先週金曜日の状態と呼ばないようにします。

完了件数には、分母と数える単位が必要です。当初予定した8件のうち4件が完了したという数字は、その集合の説明です。プロジェクトの工数、受入条件、事業上の便益が半分達成されたことを意味しません。タスクの大きさは異なり、大きな追加作業も件数では1件にすぎないことがあります。

累積完了と今期の完了も分けます。下の例では5件が完了状態ですが、2件は週の開始前に終わっています。「今週5件完了」とすれば、過去の成果を重複して計上します。この期間に実際に完了へ変わった3件を示し、そのうち当初予定分が2件、追加分が1件という内訳を残します。

3. マイルストーンと受入記録：何が承認されたかを見る

各マイルストーンについて、基準日、現在の予測、実際の受入承認時刻、受入条件、承認責任者を収集します。予測は見積もりです。受入実績には根拠が必要です。まだ受け入れられていない場合、予測日を実績欄へコピーせず、実績なしとします。

依存関係を明示します。M2が通るまでM3の受入工程を進められないのであれば、その前提を省いたM3の日付は誤解を招きます。報告処理は依存と担当者の予測を表示できますが、検証済みの工程モデルを実際に実行していない限り、クリティカルパスを計算したと表現してはいけません。

小さな作業が多数終わっていても、遅れているマイルストーンや予測の変更を表示します。受入済みマイルストーンの件数は進捗の位置を示す助けになりますが、重み付けされたプロジェクト完成度とは異なります。組織が加重指標を使う場合は、重みと受入ルールを記録し、承認済みスコープに今も合っているかを責任者に確認します。

4. リスク台帳：不確実性と責任を残す

最新のリスク記述、発生可能性の区分、影響区分、担当者、対応、確認日、エスカレーション条件を使います。有用な記録は、何が起こり得るかと、確認済み対応の後に何が残るかを説明します。「供給元リスクは中程度」だけでは、スポンサーは必要な判断を特定できません。

低・中・高から数値の確率を作り出してはいけません。こうした区分は順序を表すことが多く、そのまま平均できる数ではありません。対応計画が書かれているだけで、対策が有効だったと判断するのも誤りです。計画された対策と、その実施を示す証拠は別の入力です。

リスクと発生済みの課題も分けます。テストが不合格になった事実は課題です。供給元の修正が間に合わない可能性は、関連するリスクとして残せます。両者を関連付け、同じ観測事実を2つの独立した失敗として数えたり、実在する阻害要因を仮定の言い回しで隠したりしないようにします。

5. 課題・インシデント記録：観測された影響を記述する

課題ID、発生・登録時刻、観測された影響、チームの定義による重大度、担当者、暫定対応、次の行動、解消見込みを収集します。起きたことと推定原因を分けます。内部の受入チェックが不合格だっただけでは、顧客障害、データ消失、供給元の責任を立証できません。

課題の性質に合った終了根拠を求めます。「修正済み」という連絡は、パッチが用意されたという意味かもしれず、受入チェックを再実行して合格したとは限りません。マイルストーンを止めている課題なら、受入責任者が必要な結果を確認したかも確かめます。

遅れて届く更新は別扱いにします。送り手が主張する出来事の時刻と、報告担当が知った時刻の両方を残します。月曜日の連絡が「金曜日の締切前に直っていた」と言う場合、金曜日の報告を訂正すべきか検証します。無言で書き換えず、未確認の修正連絡だけからマイルストーンの承認まで推定しないようにします。

6. 予算と実績：対象範囲、期間、会計上の扱いをそろえる

財務責任者に、承認予算、指定日までの実績、契約・発注済み額の未消化分、残りの費用見込みを求めます。通貨、含む費目、計上の網羅性、除外範囲を明らかにします。「コスト」と名付けられた出力が全費用を含むとは限りません。例えばMicrosoftが説明するProject Operationsの特定の人件費追跡ビューには、材料費や経費が含まれません。

合計する前に、契約・発注済み額が実績や残りの見込みとどう重なるかを確認します。契約総額の一部がすでに実績として認識されている場合があります。残りの費用見込みには、未消化の契約額がすでに含まれているかもしれません。3つの総額を足すと、同じ支出を繰り返し数えることになります。

列名から推測した式ではなく、財務責任者が確認した定義を使います。この例では、重複しないと明示された「実績＋残額予測」を使います。学習用の計算であり、会計方針ではありません。実際の報告では、未払・未計上費用、税、為替、認識時点などの扱いを財務の専門担当者が確認する必要があります。計上範囲が不完全なら対象範囲を示し、現在の予算状態を不明のまま残します。欠けた金額を作ってはいけません。

7. 意思決定と依存関係：依頼と確約を区別する

承認された決定、保留中の依頼、決裁者、期限、依存先の確認状況を収集します。人員を依頼したことと配置が決まったことは違います。新しい納期の提案は、承認済みベースラインではありません。こちらが期待する回答日と、供給元がその期限を受け入れたことも別です。

経営側への依頼は回答可能な形にします。何を決めるか、なぜ今必要か、選択肢、判断が必要な最終時点、待つことの影響を示します。候補案と実際の決定記録を分けてください。意思決定ログのテンプレートは、議論を承認に読み替えず、根拠を残すための補助になります。

他チームへの依存には、依頼側と提供側の責任者を記載します。一方しか約束していない場合は「相手側の確認待ち」とします。AIが「納期で合意済み」と滑らかに要約すると、スポンサーが知るべき不確実性が消えてしまいます。

8. 要員と責任者の補足：背景を確認し、感情を推定しない

責任者に、次の期間の対応可能時間、専門スキルの利用可能性、引継ぎ、予測の前提を確認します。個人情報が不要なら、役割やチーム単位の情報を優先します。容量不足には期間と単位が必要です。「来週必要なテスト16時間に対して4時間不足」は行動につながりますが、「チームが疲れていそう」は測定結果ではありません。

メッセージ頻度、返信速度、会議出席から、健康状態、意欲、生産性を推定してはいけません。責任者は私的事情を開示せずに業務上の制約を説明できます。報告には、受け手に必要で、受領権限のある情報だけを含めます。

レビューでは、確認した範囲を明示します。プロジェクト責任者は文章の正確さを確認しつつ、財務が最終日の計上を確認していないことを認められます。その留保を残してください。「確認済み」を「全情報がそろい、結果まで保証された」の略語にしてはいけません。

記入例：資料がそろっていても日程は赤になる

締切と8つの入力

架空のSR079は、社内サポート依頼の振り分けを試すプロジェクトです。対象期間は2026年8月24日00:00から8月28日17:00まで、すべてUTCです。状態の基準時点と情報の締切は8月28日17:00。17:15に草稿を準備し、17:30に報告責任者が発行を確認して、17:45に出します。

ベースラインB1は社内試行を承認し、終了日は9月4日、予算は12,000米ドルです。外部顧客への展開は含みません。B2は9月7日への変更提案で、未承認です。8つの情報源は届いていますが、財務実績は8月27日17:00までで、その後の計上の網羅性は未確認です。

したがって、受領した区分は8/8、現在の基準時点に適用できる範囲が確認された区分は7/8です。後者の87.5%は区分単位のデータ確認値であり、進捗率でも報告が正しい確率でもありません。変更されていない基準計画が適用可能なのは、承認の有効性が確認されているためです。その日の午後に書き直す必要はありません。

完全な資料パックには、架空のタスク10行、マイルストーン4件、リスク2件、課題、費用内訳、意思決定、依存、責任者の更新が入っています。計算を再現するために、非公開の顧客データを別途入手する必要はありません。

要約を書く前に日程と金額を照合する

開始時点の予定タスクは8件で、期間内に2件追加されました。全10件のうち完了は5件、そのうち1件は追加分です。当初の8件では4件が完了しています。どちらも50%ですが、答えている問いは異なります。この期間に新たに完了したのは3件だけです。いずれも試行全体が半分終わった証拠にはなりません。

T04が完了なのは、その仕事がテスト実行と結果記録だからです。M2には6項目すべての合格が必要で、現在は5項目しか通っていません。したがって、T04の終了はM2の受入承認になりません。承認済みマイルストーンは4件中1件で、25%という重み付けのない件数比です。これもプロジェクト全体の完成度とは言えません。

この架空プロジェクトでは、予測終了が承認期限を超えるか、必須の受入が期限までに完了しなければ、日程を赤にします。そのため日程は赤です。これは事例用に選んだ規則で、業界共通の閾値ではありません。前回予測は9月4日、現在は9月7日なので、暦日で3日後ろへ動きました。3営業日ではなく、提案中のB2で差異を消すこともできません。

供給元への契約総額3,000米ドルには、実績計上済みの1,800米ドルが含まれます。未消化の1,200米ドルも、残額予測5,400米ドルの中に入っています。11,400米ドルへ契約総額をもう一度足すと、二重計上で14,400米ドルになります。計算が正しいことと、情報範囲が完全であることは別です。財務責任者が計上範囲の不足を確認するまで、現在の予算状態は不明です。

スポンサーが判断に使える報告

SR079、第1版。2026年8月28日17:45 UTC発行。総合状態は赤。社内試行の受入予測は9月7日で、承認期限の9月4日を超えている。M2は未承認で、必須の振り分けチェック6項目中5項目が合格し、課題I01が受入を妨げている。財務は対象スナップショットに対して11,400米ドルの予測を提示しており、予算は12,000米ドルだが、最終日の計上範囲が未確認のため現在の予算状態は不明。依存関係を確認した上で、8月31日12:00 UTCまでに回復または再計画を判断するよう、DeliveryLeadが依頼している。B2は提案のままである。

今期の成果：T03、T04、追加タスクT09が完了へ移り、M1が受入承認された。T04のテスト実行によって不合格が見つかったのであり、M2の承認を示してはいない。件数だけから全テスト合格と読まれないよう、この説明を成果のすぐ隣に置きます。

次の対応と必要な判断：IntegrationLeadは8月31日12:00までに供給元の修正状況を報告し、回答がなければ未回答の依頼を上位の判断に回す。供給元はこの期限を承諾していない。DeliveryLeadは来週のテスト需要16時間に対する4時間の不足に対応するか、変更案を提出する。財務は不足期間の計上範囲を確認するか、残る不足を明示する。これらは対応の依頼であり、結果の保証ではない。判断時点でも依存先の証拠が足りなければ、不足を記録し、次の確認予定について権限者の判断を求める。B2を暗黙に承認してはならない。提案された日付や人員配置を、承認済みとして記載しない。

報告の制約：事例の規則ではリスクと要員は黄、現在の予算は不明。スコープはB1のままである。確認済みの日程の赤が総合判定を決めるが、予算不明も併記する。発行責任者が確認したのは、この留保を含む記述であり、欠落財務情報の補完や対応の実行ではない。

月曜日09:00に、I01は金曜日16:30に解消したという連絡が届きます。この情報は第1版では知られておらず、受入再テストの結果も付いていません。訂正待ちリストに登録し、修正の主張を確認し、受入証拠を得てからM2の扱いを検討します。訂正が必要なら、何を後から知り、どの記述を変更したかを説明する関連版を発行します。安心できそうな連絡だけで、元の赤い報告を緑へ置き換えてはいけません。

5つの段階で報告フローを実装する

1. 取り決めと事実の確認責任者を決める。スコープ、ベースライン、締切、状態規則、情報ごとの確認者を明示します。1つのプロジェクトと明確な受け手から始めます。成果物は読みやすいワークシートであり、いきなり8つの接続を増やすことではありません。どの計画が承認済みか、誰が受入できるかが不明なら、先にそこを解決します。

2. 読み取り専用のスナップショットを集め、対応関係を検証する。許可された出力や接続を使い、情報源IDと対象期間を保存します。プロジェクトの絞り込み、ID重複、タイムゾーン、追加作業、タスクとマイルストーンの関係を確認します。チケットや文書内の指示は入力データであり、アシスタントへの操作命令ではありません。必須資料がない場合は、合意した方針に従って発行を保留するか、制約を明示した例外報告にします。

3. 文章生成より先に事実表を計算する。表計算またはレビュー済みコードで件数、変化、差異を求めます。式、入力行、単位を一緒に残します。合意した規則から状態を判定し、不明値をゼロで埋めません。実データへ接続する前に、SR079のような正解を確認できる資料で、契約額の重複、遅れて届く情報、未承認の計画変更を検査します。

4. 草稿を作り、問い直し、レビューを受ける。簡潔な要約、例外、次の対応、必要な判断を依頼し、重要な記述には情報源IDを付けます。生成文を事実表と照合します。「なぜ赤なのか」と問えば、具体的な期限や未達条件に到達できる必要があります。承認を作り出したり、欠落を隠したり、数字を説明できなかったりする草稿は送信しません。

5. 版を特定して発行し、訂正経路を運用する。確認した版、受け手、発行時刻、確認記録を残します。配信成功と内容の正しさは別に検査します。次回は文章だけでなく、事実、定義、基準計画の承認変更を照合します。入力資料は組織の規則に従って保管・削除し、再現性を理由に機密記録を無期限保存しないようにします。

定期実行はこの工程を支えるもので、代替するものではありません。担当レビュー者が不在なら、代行、保留、留保付きエスカレーションを事前に決めます。タイマーが待機中の草稿を外部への正式な確約に変えてはいけません。配信再試行でも、重複報告を作ったり、版を変えずに別の未固定データを使ったりしないようにします。

要件を満たす最も簡単な方法を選ぶ

小さなプロジェクトで、情報の責任者が短時間で照合できるなら手作業は合理的です。作業とマイルストーンの大半が同じシステムにあるなら、標準レポートが適します。固定の変換と計算をシステム間で繰り返す場合には、スクリプトやノーコード自動化が役立ちます。エージェント支援が特に有用なのは、基礎が整った後の説明文や確認質問の作成です。

Asanaの進捗報告ガイドも、一貫した報告構成の参考になります。別の仕組みを増やす前に、現在使っているツールを評価してください。これはベンチマーク順位ではありません。製品横断の実測比較や、どの方法でも常に速くなるという確認は行っていません。

移行のきっかけは、実際に確認したボトルネックにします。承認日付で揉めるなら意思決定を整えます。事実に合意できているのに毎回同じ行を転記しているなら、その変換を自動化します。確認済みの変化が何を意味するか説明しにくいなら、草稿支援を試します。

確認済み資料からOpenMaxで草稿を作る

公開文書で確認できる範囲

OpenMaxのOperations文書、ユースケース35には、提供された更新、マイルストーン、リスク、予算から進捗報告を作るプロンプト例があります。週次報告や経営向け要約を求める例です。これを根拠に、確認済み資料を渡して出力を照合する限定的な試行は提案できます。ただし、この記事が利用者の接続、定期配信、承認統制を実測した証拠ではありません。

本稿はOpenMaxブランドの教育コンテンツであり、独立した製品レビューではありません。報告時間の削減率やリスクの早期発見日数は主張しません。独自の事例は説明用に作成したもので、OpenMaxの顧客ワークフローとして実行したものではありません。

範囲を限定した試行用プロンプト

以下の独自プロンプトをワークシートと資料パックに添え、実環境の権限とデータ取扱いを確認した上で使用します。

提供されたSR079資料だけから進捗報告の草稿を作成してください。指定の状態基準時点、情報締切、承認済み計画、報告規則を使います。提供された計算と文章を分け、重要な記述に情報源IDを付けてください。タスク完了から受入承認を推定せず、B2を承認せず、重複する契約額を加算せず、不足費用を見積もらず、締切後に受け取った課題の主張を第1版に含めないでください。現在の予算は不明、根拠のある日程は赤のまま示します。経営向け要約、期間内の成果、未解決の例外、次の対応、必要な意思決定を出力し、最後に各責任者への未回答質問をまとめてください。メッセージ送信、原記録の変更、草稿を承認済みとする表現は行わないでください。

この指示は期待する振る舞いを記述するもので、権限制御を実装したり、信頼性を証明したりはしません。出力を資料と照合してください。「試行は50%完了」「600米ドルを節約」と書く、あるいは計上範囲未確認を省く場合は、実データを使う前に推論を修正して再確認します。

次の一歩は、1つの確認済み版を作ること

8情報源ワークシートから始めます。権限のある1プロジェクトについて手作業で埋め、未定義項目を解消し、架空の資料を正解確認用のテストに使います。レビュー担当が草稿から入力へたどれるようになってから、限定した実データ試行を検討します。手作業の報告経路も残します。

信頼できる標準レポートがすでにあるチームには、新しいアシスタントが不要な場合もあります。資料提供の権限がない場合、試すだけのつもりでアップロードしてはいけません。導入前にOpenMaxまたは管理者へ、アクセス、保存、接続、レビューの実際の仕組みを確認してください。この記事では、それらの統制の存在や動作を検証していません。

自動化が成功したように見える失敗を避ける

整った報告の中で目標だけが動く。承認日を予測日で置き換えると、遅延が消えます。両方の項目と承認記録を別に保ちます。正式にベースラインを変更した場合も、その変更と比較への影響を明記します。

全ファイルを取得したが、財務範囲が足りない。ファイルが届いても、費目や最終日の計上が欠けていることがあります。存在確認だけでなく意味と対象範囲を調べます。会計上の扱いは財務責任者が確認し、報告が不足を埋めるために認識ルールを作らないようにします。

タスク指標が事業成果へ格上げされる。チケットが終わっても受入が止まることはあります。正しい指標名と分母を使い、受入の例外を近くに置きます。件数、工数、支出、期待便益を1つの割合に混ぜないでください。

草稿がそのまま行動になる。供給元への依頼案が、合意済みの約束として送られてしまいます。作成、承認、実行を分離し、プロンプトだけでなく実際のフローで権限を制御します。重要な財務、セキュリティ、プライバシーの判断には、適切な専門性や責任を持つ人の確認が必要です。

受け手が知るべき範囲を超えて開示する。要約が無害に見えても、リンク、画像、抜粋から情報が露出する場合があります。配布先と添付資料のアクセスを確認し、必要最小限にします。作成者の閲覧権限が全受信者への提供権限になるわけではありません。

過去の版を黙って書き換える。遅れて届いた情報で先週の内容が変わったのに、理由が残らない状態です。適用される保存方針に従って元の版を識別可能にし、訂正版を関連付けます。新たに知った事実と検証状況を記録し、報告の訂正を回復行動の実施と取り違えないようにします。

よくある質問

プロジェクト進捗報告は完全に自動化できますか？

データ、権限、項目の対応関係が安定していれば、収集と定義済み計算は自動化できます。文章生成を定期実行することも可能ですが、矛盾した記録の解消や不足する承認の取得まで自動的に済むわけではありません。組織の発行方針に従って人の確認が必要な報告を決め、例外を確定事実として黙って発行しないようにします。

小さなプロジェクトにも8つのツールが必要ですか？

いいえ。8区分は情報範囲のチェックリストであり、8製品の購入要件ではありません。承認された1つのワークブックに計画、マイルストーン、リスク、決定が入っていても構いません。本当に適用外の区分には理由を付けますが、入手が難しいというだけで必須情報を適用外にはしません。

赤・黄・緑はどのように判定しますか？

報告前に、各観点の規則、必要な根拠、総合判定の優先順位を合意します。適用情報が欠ける場合は不明を使います。この架空例では承認期限より遅い終了予測が日程の赤となり、総合でも既知の赤が優先されますが、予算不明も残します。これは事例の規則であり、普遍的な標準ではありません。

後から届いた情報で先週の報告を変更すべきですか？

主張される出来事の時刻と、その情報を知った時刻を両方記録します。検証した上で発行済み版の訂正方針に従います。後から課題が直ったと言われても、それだけでは受入合格を証明できず、元の報告時点で知っていた情報として扱うこともできません。

この例はOpenMaxによる報告時間の短縮を証明しますか？

いいえ。SR079は計算を確認できる架空の学習資料であり、所要時間を測った製品テストや顧客事例ではありません。公開プロンプト例は限定的な草稿試行の出発点になります。時間短縮、精度、接続動作の主張には、ここにはない、定義された実テストと証拠が必要です。

参照資料と関連ワークフロー

資料の確認日：2026年9月5日。ベンダー文書は各リンクに対応する限定的な説明の根拠です。8区分、報告規則、架空の記録、計算は独自の教材です。実案件の会計処理、アクセス、承認条件については、引き続き適切な専門担当者の確認が必要です。

• Atlassian：プロジェクト進捗報告の構成。
• Microsoft：ベースラインと中間計画の基準値。
• Microsoft：プロジェクト報告の状況報告日。
• Microsoft：人件費追跡の対象範囲と計算。
• Asana：プロジェクトの状況更新を準備する。
• OpenMax：Operationsのユースケースと進捗報告プロンプト例。

回復日程を決定として記録する場合は、意思決定ログのテンプレートを使います。成果物が満たすべき条件が未定なら、AI製品要求仕様書のテンプレートを参照してください。進捗報告はこれらの記録をつなぐもので、どちらかを黙って書き換えるものではありません。