案件の終了時に、Teams の会話・議事録・課題管理表から、うまくいったこと・問題・次に生かす教訓を振り返りの資料にまとめる

処理の起点を決める

案件の検収が終わったことを起点にします。 検収の前に作ると、最後の受入の問題が入りません。検収から2週間以内に下書きを作り、1か月以内に振り返りの会を開きます。

エージェントは案件ごとに作ります。 知識に指定するチャネルと会議は案件ごとに違うので、1つのエージェントで全案件を扱うことはできません。PMO は、指示の文面、振り返りの様式、教訓の書き方の決まりの3つを用意しておき、 PM はそれを使って、知識の指定だけを自分の案件に合わせます。作る手間は十数分です。

エージェントは、資料を PMO に出した後に削除します。 案件の記録は残りますが、エージェントを残しておくと、案件のメンバーでない人に共有されたときに、埋め込んだファイルに基づく応答が見られてしまいます。

入力データを集める

質を決めるのは、4行目の課題管理表です。 会話と議事録からは、問題が「いつ、どう話されたか」は分かっても、影響の大きさと対応の結果は課題管理表にしか残っていません。 課題の番号を根拠に付けられれば、PM はそこから経緯を確かめられます。

会議は5つまでなので、選びます。 毎週の定例をすべて入れることはできません。キックオフ、要件の確定、設計のレビュー、受入の判定、最も問題の大きかった回の5つを選び、定例の内容は議事録のフォルダから拾います。

教訓の書き方の決まりは、次のように書きます。

【教訓の書き方の決まり】
- 「条件」と「行動」で書く。条件は、次の案件の立ち上げで確かめられること（顧客側の担当の人数、
  既存システムからの移行の有無、受入テストを顧客が行うか、など）。
- 行動は、いつ・誰が・何をするかが分かる形で書く。
- 使わない言葉：「密に」「丁寧に」「早めに」「意識する」「徹底する」
- 個人の名前を書かない。役割（PM、顧客側の窓口、開発リーダー）で書く。

データの取得方法を決める

チャネルと会議は、必ず個別に指定します。 公式のページでは、「My Teams chats and meetings」を選ぶと、すべての会議の文字起こしと予定表全体を探すとされています。PM は複数の案件を掛け持ちしていることが多く、別の案件の会話が教訓に混ざります。

会議の文字起こしは、すべてが使えるとは限りません。 公式のページでは、過去の文字起こしの大きさによっては、エージェントがすべての文字起こしにアクセスできないことがあるとされています。会議の内容は議事録にも残し、根拠が会議にしか無い記述は、PM が録画で確かめます。

リストは、絞り込みやグループ化のビューではなく、リストそのものの URL を指定するとされています。課題管理表の「未完了」のビューを指定すると、完了した課題が抜け、解決した問題が振り返りから消えます。

「Only use specified sources」を有効にします。 この設定は指定した知識を優先させるもので、一般的な知識を完全には止めないとされています。指示の側でも、一般的なプロジェクト管理の知識で補わないよう明記します。

AIへ渡す前に整形する

1. 議事録のファイル名に日付を入れる … 「2026-04-15_定例_第3回.docx」のようにします。時期で区切るときの手がかりになります
2. 課題管理表の本文の列に経緯を書く … 添付のファイルは根拠に使われないので、原因と対応を本文の列に書いておきます
3. 案件の時期の区切りを決める … 要件定義、設計・開発、テスト・移行の開始日と終了日を、PM が指示の冒頭に書きます
4. チャネルを分けておく … 顧客との連絡と社内の開発を同じチャネルにしないことで、顧客側の要因と社内の要因を分けて拾えます
5. 知識の準備を待つ … 新しく指定した SharePoint のファイルは「Preparing」と表示され、準備が終わるまで応答に使われないとされています。指定した翌日に下書きを頼みます

2番目は、案件の始めから決まりにしておく必要があります。 終わってから書き足すのは、読み返しと同じ手間です。PMO が課題管理表のひな形に「原因」「対応」の列を設け、空のまま完了にできないようにしておきます。

AIに処理させる

させるのは、記録に書かれた出来事を、時期ごとに決まった欄に根拠付きで並べることと、問題から教訓の候補を条件と行動の形で出すことです。

1行目と2行目がいちばん大事です。 会話の記録には、誰が何を言ったか、誰の返事が遅れたかが残っています。エージェントが「開発リーダーの確認が遅れたため」と書けば、それは事実でも、資料に残すと人の話になります。 主語を役割と仕組みに置き換えるのではなく、「何が決まっていなかったために遅れたか」を書かせます。

書き方の違いを例で示すと、次のようになります。

【人の話になった書き方】
受入テストで顧客側の窓口の確認が遅れ、本番の切り替えが1週間延びた。

【事象と仕組みの書き方】
受入テストの開始の条件（テスト環境の引き渡しの日、テストのケースの承認者）が
計画書に書かれておらず、顧客側でテストの準備が始まったのが引き渡しの後だった。
本番の切り替えが1週間延びた（課題No.41）。

後者からは、「受入テストを顧客が行う案件では、計画書に開始の条件を書く」という教訓が出ます。 前者からは、「窓口に早めに確認する」しか出ません。事象の書き方が、教訓の質を決めます。

指示内容を固定する

エージェントの指示として Agent Builder に書いておく内容です。 PMO が用意し、PM は案件の名前と時期の区切りだけを書き換えます。

あなたはシステム開発の会社のプロジェクトマネージャーを手伝い、
終わった案件の振り返りの資料の下書きを作る立場です。
知識に指定した案件のチャネル、会議、議事録のフォルダ、課題管理表、
埋め込んだ振り返りの様式と教訓の書き方の決まりだけを見てください。
一般的なプロジェクト管理の知識や、指定していない案件の情報で補わないでください。

【案件】{project_name}
【時期の区切り】要件定義 {d1}〜{d2}／設計・開発 {d3}〜{d4}／テスト・移行 {d5}〜{d6}

【書き出すこと】頼まれた時期の範囲だけで書いてください。
1. 問題：事象、時期、影響（遅れの日数、追加の工数、顧客への影響）、対応
2. 原因の確度：記録で確かめられた／推定／記録に無い
3. うまくいったこと：記録の中で効果があったと書かれている取り組み
4. 教訓の候補：問題ごとに1つ、教訓の書き方の決まりに従って「条件」と「行動」で

【書き方】
- すべての記述に根拠を付けてください（チャネルの名前と投稿の日付、議事録のファイル名、課題の番号）。
  根拠を示せない記述は書かないでください。
- 影響の数字は、記録に書かれたとおりに写してください。計算したり推し量ったりしないでください。
- 原因は、記録で確かめられたと言える場合だけ「確かめられた」としてください。迷ったら「推定」です。

【厳守事項】
- 個人の名前を書かないでください。役割（PM、顧客側の窓口、開発リーダーなど）で書いてください。
- 問題の主語を人にしないでください。「何が決まっていなかったか」「何が無かったか」で書いてください。
- メンバーや顧客の担当者の仕事ぶり、態度、能力について書かないでください。
- 教訓に「密に」「丁寧に」「早めに」「意識する」「徹底する」を使わないでください。

「頼まれた時期の範囲だけで」を書いているのは、時期ごとに区切って頼むためです。 PM は「要件定義の時期の振り返りを作って」「設計・開発の時期を作って」と3回に分けて頼みます。範囲を指示に書いておかないと、毎回、案件の全体から拾い直します。

教訓に使わない言葉を並べているのは、何も言わなければ使うからです。 「顧客との認識合わせを丁寧に行う」は、文としては正しく、どの案件の教訓にも見えます。 言葉を禁じると、エージェントは条件と行動を書かざるを得なくなります。

出力形式を固定する

エージェントには、表の形で返させます。 資料は振り返りの会で読む文書なので、JSON ではなく、PM がそのまま Word の様式に移せる表にします。

【問題（要件定義の時期）】
| 事象 | 時期 | 影響 | 原因の確度 | 対応 | 根拠 |
| 帳票の追加の要望が、要件の確定の後に顧客側の別の部署から届いた | 5月第2週 | 設計の開始が8営業日遅れ（課題No.27） | 推定：要件の変更の窓口が決まっていなかった | 変更の要望として受け、追加の見積を出した | 顧客連絡チャネル 5/12、2026-05-14_定例_第7回.docx、課題No.27 |

【うまくいったこと】
| 取り組み | 効果として書かれていること | 根拠 |
| 画面の試作を週1回顧客に見せた | 「画面の手戻りが前の案件より少ない」 | 2026-06-04_定例_第10回.docx |

【教訓の候補】
| 条件 | 行動 | 元になった問題 |
| 顧客側で要件に関わる部署が2つ以上ある案件 | キックオフの時点で、要件の変更の窓口を顧客側に1人決めてもらい、議事録に残す | 課題No.27 |

1つ目の理由は、根拠の列で確かめる先が決まることです。 PM は課題の番号と議事録のファイル名から記録を開き、事象と影響が記録どおりかを確かめます。

2つ目は、教訓の候補が「元になった問題」とつながっていることです。 振り返りの会で教訓を絞るときに、どの問題から出た教訓かが分かれば、問題の重さで優先を決められます。

3つ目は、教訓集にそのまま登録できる形であることです。 教訓集のリストは「条件」「行動」「元の案件」「元になった問題」の列で作っておき、PMO は会で決まった教訓を表から写すだけで登録できます。

システムへ連携する

エージェントは記録を読むだけで、どこにも書き込みません。 教訓集への登録は、振り返りの会でチームが決めた後に PMO が行います。

人が確認する

この構成では、全件を人が確かめます。 資料は案件の記録として残り、教訓は次の案件の進め方を変えるからです。

1. 根拠を開いて事象と影響を確かめる … 課題の番号と議事録から、遅れの日数や工数が記録どおりかを見ます
2. 原因の確度を確かめる … 「確かめられた」とされた原因が、本当に記録で確かめられているかを見ます
3. 人の話になっていないかを見る … 主語が人になっている記述、特定の人を指すと分かる記述を直します
4. 計画と実績の数字を足す … 案件管理の表から、期間・工数・費用を写します
5. 振り返りの会で教訓を絞る … 教訓の候補から、次の案件で確かめられるものを2〜5個に絞ります

3番目を省かないでください。 役割で書いていても、「顧客側の窓口」が1人しかいない案件では、誰のことかが分かります。事象の書き方まで、仕組みの言葉になっているかを見ます。

目標は、1件あたり45分です。 会話と議事録を読み返す時間が、根拠を開いて確かめる時間に置き換わります。

振り返りの会では、下書きを事前に配り、会の時間を教訓の絞り込みに使います。 会の冒頭で「問題の表に抜けている出来事は無いか」を5分だけ聞き、記録に残らなかった出来事（口頭で決めたこと、顧客先での立ち話）をメンバーから足します。 エージェントが拾えるのは記録に残ったことだけなので、この5分が下書きの抜けを埋めます。

例外に対処する

5行目は、顧客の承諾を得てから行います。 顧客の側の記録を自社の知識に入れることになるので、契約と顧客の情報の扱いの取り決めを確かめます。

1行目のチャネルの選び方は、案件の始めに決めておくと楽です。 案件のチームを作るときに、PMO のひな形でチャネルを「顧客連絡」「開発」「テスト・移行」の3つ程度に決めておけば、終わったときに知識の上限の5つに収まり、選ぶ手間がかかりません。

記録を残す

• 知識に指定したチャネル、会議、フォルダ、リストの一覧
• 時期ごとの下書きの全文
• PM が直した箇所 … 原因の確度を変えた、人の話を直した、教訓の候補を外した
• 振り返りの会で決まった教訓と、外した教訓
• PMO に出した資料の最終版と、教訓集への登録の記録

下書きは Word のファイルとして案件のフォルダに残します。 エージェントは資料を出した後に削除するので、会話の履歴に頼りません。

3行目の「人の話を直した」の件数は、指示を直す材料になります。 件数が減らなければ、厳守事項の書き方を PMO が見直します。