議事録の次は、誰が何を引き受ける？

AI 生成の概念イラスト。内容は仮定の例です。

ある顧客会議が終わったあと、アシスタントが三つのアクション項目を整理したとします。金曜日に新版の提案を納品、小林が価格見積もりを担当、来週デモを設定する。議事録は明確に見え、どの項目にも担当者と日付があるように見えます。

しかし会議記録に戻ると、顧客が尋ねたのは「金曜日に先に一版を見せてもらえないか」であり、小林が言ったのは「営業に確認して価格を調べます」であり、デモは顧客がテストデータを用意するのを待つ必要がありました。

この三つをそのままタスクシステムに書き込めば、チームにはまだ承諾していない約束がいくつか増えることになります。金曜日になれば、顧客は提案を待ち、小林には見積もりの催促が届き、デモの招待もすでに送信されています。会議に残っていた不確実性は、整理の過程で消えてしまいました。

会議後の引き継ぎでは、こうした違いを保つ必要があります。アシスタントはタスクを抽出し、文脈を補い、書き込みを準備できますが、各タスクには何がすでに確定していて、何を誰が決める必要があるのかを明記すべきです。

提案・決定・約束を分ける

「別の見積もり方法を試してみてはどうか」は提案です。「今回は月次見積もりを採用する」は決定です。「木曜日に見積もり表を送ります」は具体的な約束を含んでいます。三つの文はすべて見積もりに関係しますが、その後の扱いは異なります。提案は誰かが採用するのを待ち、決定はすでに効力を持ち、約束は相手に予期できる義務の層を与えます。

会議後の整理で三つとも「アクション項目」と書いてしまえば、この違いは消えます。Lindy の議事録ガイドと Viktor の当日中の会議後フォローアップは、それぞれ議事録の書き方とアプリ間のフォローアップから会議後の作業に切り込みますが、ある一文が結局どんな約束を形成したかは、やはり個別に判断する必要があります。

判断の根拠は資料にすでにある証拠です。誰かが採用したか、承認を経たか、約束した本人が発言したか、時間が指定されているか。これらの根拠が見つからない場合は、提案または確認待ちとして扱います。

先ほどの仮定の会議について、次のように整理できます。

会議での表現	現時点で確定できる内容	まだ確認が必要な内容
顧客が「金曜日に先に一版を見せてもらえないか」と尋ねた	顧客は金曜日に初稿を見たいと考えている	チームが受け入れるか、初稿に何を含むか
小林が「営業に確認して価格を調べます」と言った	小林が価格照会の作業を引き受けた	いつフィードバックするか、誰が最終的に価格を決めるか
「テストデータが揃ってからデモをする」	デモには前提条件がある	誰がデータの準備完了を確認するか、その後どうやって時間を設定するか

整理の際は、関連する原文と出典の位置を保持します。文字起こしの段落を特定できるなら段落を添え、元資料にタイムスタンプがあればタイムスタンプを保持します。話者の識別が不明確な場合は、要確認と明記し、発言内容から名前を推測してはいけません。

担当者が欠けているタスクは、一時的に確認待ちの領域に残しておけます。表のすべての欄を埋めることが、引き継ぎの完全さを意味するわけではありません。

担当者は実際に引き受けた作業に対応させる

小林は価格照会を約束したので、「営業に価格を確認する」を小林に任せられます。そこから彼が価格設定、割引の承認、顧客への送信を担当すると推測すれば、元の約束を拡大してしまいます。

ある人が問題を紹介したからといって、その人が問題解決のタスクを引き受けたわけではありません。役職、発言回数、過去の役割分担は、誰に尋ねるべきかを見つける助けにはなりますが、今回の割り当ての直接の根拠にするべきではありません。チームに明確な割り当てルールがあれば、アシスタントはルールに従って割り当てを提案し、根拠を説明できます。

成果物は、引き継ぐ人が判断できる程度まで書く必要があります。「見積もりをフォローアップする」では解釈の余地が大きすぎます。「営業にこの二つの案の価格を確認し、結果を見積もり草稿に追記する」なら、何をするかが分かります。顧客への送信を含むかどうかは、別途明確にします。

日付も同様です。顧客が提示した希望時期、チームが受け入れた締め切り、次に進捗を確認する時期は、それぞれ意味が異なります。会議で「できるだけ早く」とだけ言われたなら、保留のままにします。アシスタントは確認用に日付を提案できますが、提案を会議で承認済みの予定として書いてはいけません。

確認を求める際は、まだ決まっていない部分だけを尋ねる

議事録全体を担当者に送り、「確認してください」と一言添えても、相手は自分で全ての疑点を探さなければなりません。より有用な引き継ぎは、質問を具体的な事項に落とし込みます。

たとえば、アシスタントは次のような確認依頼を準備できます。以下の内容は依然として架空の例です。

顧客は金曜日に提案の初稿を受け取りたいと考えていますが、会議にはチームがその日付を受け入れた記録が見つかりません。プロジェクト責任者は、応じるかどうか、およびこの版に何を含める必要があるかを確認してください。

小林は営業に価格を照会することを約束しましたが、フィードバック時期は未定です。小林さん、予想されるフィードバック時期を補足してください。

デモは顧客がテストデータを提供するのを待つ必要があるため、現時点ではカレンダー招待を作成しません。誰がデータの準備完了を確認するか決めてください。

三つの質問はそれぞれ答えられる人に渡します。すでに確認済みの事項は一緒に待たせる必要はなく、まだ条件が欠けている事項はそのままにします。こうすれば、一回の返信で一つの明確な欠落を解決できます。

確認は、その時点で対応する版の内容にのみ有効です。責任者が「金曜日に初稿を出す」ことに同意した後、成果物が「完全な提案と見積もり」に拡大された場合、この返信は追加された範囲をカバーできません。再確認が必要なのは変化した部分であり、残りは依然として有効です。

タスクを引き継ぐ人が実際に使う場所に書き込む

会議文書は議論の根拠を保存し、タスクシステムは役割分担を担い、対外メールは確認済みの取り決めを説明します。三者は互いにリンクし、それぞれ必要な情報の部分を保持します。

引き継ぎに適したタスクには、通常、成果物、担当者、確認済みの期限または前提条件、および関連する会議記録が含まれます。引き継ぐ人はリンクをたどって約束の由来を見つけられ、会議全体を読み直さなくても始められるべきです。

書き込む前に、この件にすでにタスクがあるか確認します。今週の会議は先週の事項に日付を補足しただけかもしれません。同名のタスクをさらに作成すると、進捗が二か所に分散します。アシスタントは既存のタスクと所属プロジェクトを照合し、更新提案を出すべきです。同一事項か判断できない場合は、候補記録を責任者に確認してもらいます。

対外メールは別途整理します。内部で議論中の割引、まだ承認されていない納品日は、同じ議事録に載っているからといって顧客への返信に入れてはいけません。メール草稿はすでに対外伝達が許可された内容のみを表現し、内部タスクは対応するワークスペースに残します。

タスク作成後は、その場所と割り当て状況を報告できます。担当者フィールドは割り当てを示すだけで、相手がすでに知っている、または開始したことを示すものではありません。相手が引き受けたかどうかは、チームで取り決めた確認方法に従います。

OOMOL で会議資料とタスクシステムをつなぐ

この会議後の引き継ぎで、アシスタントは二種類のことを行います。会議記録と既存タスクから読み取り、タスクシステムとメールに書き込むことです。読み取り部分は提案と約束を区別できるかを決め、書き込み部分は誤判定が直接他人に降りかかるかを決めます。

OOMOL の Connector SDKは、接続済みアプリのアカウントを呼び出す経路を提供します。まず Connections で会議記録を保存しているアプリとチームのタスクツールを接続します。接続前に、各アプリが必要な読み取り、照会、作成、更新の操作を提供しているか確認します。会議の文字起こしは引き続き既存の会議ツールが提供し、アプリを接続することは OOMOL が会議を録音したり話者を識別したりすることを意味しません。

読み取りと書き込みは段階的に有効にします。まず読み取りだけを接続し、アシスタントに引き継ぎ草稿を整理させます。提案と約束の区別が期待どおりであることを確認した後、アクセス制御ガイドに従ってタスク作成、メッセージ送信などの書き込み操作を有効にし、対象アカウント、プロジェクト、受信者、最終内容を確認します。

アプリ接続は読み書き能力を提供しますが、提案と約束の区別、担当者のマッチング、確認記録、タスクの関連付けは、依然としてアシスタントの指示または業務フローで実現する必要があり、具体的なルールはチームの実際のやり方に合わせて設定します。

一つの会議の引き継ぎ草稿から始める

すでに終了し、元の記録を照合できる会議を選び、範囲を今回の議論と対応するプロジェクトに限定します。必要なアプリをすでに接続したアシスタントに、次のリクエストを処理させます。

この会議記録に基づき、確認済みの決定、明確に引き受けたタスク、確認待ちの事項を整理してください。各タスクには成果物、担当者、期限または前提条件を明記し、出典を添えてください。根拠のないフィールドは保留のままにします。指定プロジェクト内の既存の関連タスクを検索し、それぞれ新規または更新の提案を行ってください。まず引き継ぎ草稿を私に渡し、タスクを作成したりメッセージを送信したりしないでください。確認が必要な箇所は、具体的な質問と適切な回答者を書いてください。

レビュー時は、三つの点を重点的に確認します。顧客の願望がチームの約束として書かれていないか、質問した人が担当者として割り当てられていないか、条件がまだ満たされていない事項が前倒しでスケジュールされていないか。

確認後、アシスタントに対応する事項を対象システムに書き込ませ、実際のタスクリンクとまだ決定が必要な内容を返させます。次の引き継ぎ者がタスクを開けば、自分が何を約束し、何を納品する必要があり、どの条件がまだ満たされていないかを知ることができます。