文字起こしを読めば、誰が何を言ったかはわかります。しかし、チームが何を決めたのか、なぜそう決めたのか、誰が何をすると約束したのか、どの点をまだ確認する必要があるのかまでは、自動的にはわかりません。
この違いは、数週間たつと厄介になります。検索すると見覚えのある一文は見つかっても、それが決定だったのか、提案だったのか、反対意見だったのかを誰も説明できません。要約はもっともらしくても、その根拠となる発言にはなかなか戻れません。
目指すべきなのは、見栄えのよい文字起こしではありません。由来となった言葉までいつでもたどれる、レビュー可能な小さな知識項目の集まりです。
Table of Contents
要約を書く前に、記録の種類を決める
まず、会議のあとに実際によく聞かれる問いから始めます。
- 顧客は何を求めていたか？
- どんな市場の兆しがあったか？
- どんな製品変更が提案されたか？
- どんな技術的な問題が起きたか？
- なぜこの決定をしたのか？
- 誰かが指摘したリスクは何か？
- まだ確認が必要なことは何か？
- 新しい機会に気づいたか？
- 競合について何を知ったか？
- 次のアクションを誰が引き受けたか？
こうした分類は、一つの長い要約より役に立ちます。それぞれ扱い方が違うからです。コミットメントには担当者と期限が必要です。リスクには影響と、場合によっては対策が必要です。決定には理由を残すべきです。要確認の項目を、いつの間にか事実として扱ってはいけません。
最初から完璧なオントロジーは要りません。明確な10種類と other の待ち行列があれば、チームが実際に何を話しているのかを知るには十分です。
文字起こしを証拠として残す
抽出した項目ごとに、出典へのポインターを残します。次は、実際に動く検証用サンプルに含まれる一項目から、関連するフィールドだけを抜き出したものです。
{
"type": "decision-rationale",
"summary": "Ship an upload-first workflow because it is easier to audit than a live meeting bot.",
"review_status": "manually reviewed",
"source_span": {
"speaker": "Maya",
"start_ms": 22200,
"end_ms": 27500,
"transcript_start_char": 228,
"transcript_end_char": 308,
"text": "We will ship upload-first because it is easier to audit than a live meeting bot.",
"source_hash": "4087a4626f719379ff78971865c9a5e931c1024aea8a24d77116f7f54f956d74"
}
}録音された素材なら、タイムスタンプがあればレビューする人は音声の該当箇所に戻れます。この台本を使った検証用サンプルでは、時間情報は録音から計測したものではなく、あらかじめ設定したものです。文字位置のオフセットは、それでも文字起こし内の正確な言葉を示し、ソースのハッシュは文字起こしの版を特定します。
元の抜粋そのものも保存してください。要約は便利な見せ方ですが、証拠そのものではありません。
観察と解釈を分ける
たとえば誰かが「模擬フィードバックでは、3つのテスト役から、英語と中国語の資料をまとめて検索したいという要望があった」と話したとします。この発言は、この演習の中では市場の兆しとして記録できます。ただし、市場規模や支払い意欲、演習の外にも需要があることまでは証明しません。
この境界が大切です。
source words → reviewed knowledge item → later interpretationこの3層は分けておきます。元の言葉は変えずに残します。レビュー済みの項目では、その内容を扱いやすい種類に整理できます。その後の戦略メモでは、ほかの会議や販売データ、調査結果と比較できます。
3層すべてを一つの生成文にまとめると、証拠が支えられる範囲を越えて、確信だけが独り歩きします。
間違いは消さず、新しい版で置き換える
会議記録には、ときどき間違いが入ります。レビュー中に、「要約パネル」ではなく「証拠ビュー」だったとわかったり、アクションの担当者が別の人だったと判明したりすることもあります。
古い記録を上書きし、最初から存在しなかったことにしてはいけません。新しい改訂版を追加し、以前の版を superseded（置き換え済み）として、その理由も残します。現在の画面には採用された版だけを表示しながら、監査用の履歴は保持できます。
複数の人が同じ会議をレビューするときには、特に役立ちます。修正が「どの書き出しが最終版なのか」をめぐる静かな争いではなく、通常の作業になります。
採用された記録からグラフを作る
ナレッジグラフが役立つのは、記録が安定してからです。会議と意思決定、アクション、リスク、人、製品、後続の会議を結びつけられます。ただし、グラフを別の正解データにしてはいけません。
グラフの各エッジは採用済みの記録につながり、その記録は文字起こしの証拠につながるようにします。決定が変わった場合は、次の改訂版によって現在のグラフ表示を更新しつつ、過去の履歴は削除しません。
すると、次のような短い経路ができます。
project → decision → reviewed record → speaker and timestamp → exact transcript spanグラフは情報をたどる助けになります。証拠の連鎖は、見つけた情報を信頼する根拠になります。
一般的な形式で書き出す
メインの画面が使いやすくても、持ち運べるJSONやSQLiteのエクスポートを残します。安定したID、記録の種類、改訂状態、証拠へのリンク、ソースのハッシュを含めてください。
そして、アプリケーションの外でも試します。短いスクリプトですべての未確認項目を一覧にできるか。別のツールで現在の意思決定ビューを再構築できるか。採用済みのグラフ関係が、すべて元の発言範囲までたどれると証明できるか。
答えが一社の非公開インデックスに依存しているなら、それはデモであって、長く使える社内知識ではありません。
短い会議一つで試す
アーカイブ全体を処理する前に、正解がわかっている5〜10分の会議で試します。少なくとも、決定、アクション、リスク、修正、未確認のまま残すべき項目を一つずつ含めます。
その場にいた人と一緒にレビューし、次の点を確かめます。
- 各項目の種類は正しいか？
- 実際に話された範囲を越えた表現になっていないか？
- 出典リンクを開くと、根拠となる発言が正確に表示されるか？
- 修正しても以前の版を残せるか？
- 採用済みの状態を書き出し、再構築できるか？
レビューにかかった時間と、修正の件数を測ります。会議を「理解した」という曖昧な主張より、この二つの数字のほうが役に立ちます。
実際に動く検証用サンプル
LazyingArtの meeting-to-knowledge 検証用サンプルでは、この構造をプロジェクト側で作成した54.8秒の英語・中国語の文字起こしに適用しています。レビュー済みの10種類の知識項目、話者と文字起こしの正確な範囲、履歴を残した一件の修正、グラフ表示、ダウンロード可能なJSONが含まれます。
この素材は台本として書かれた文章で、録音は添付されていません。示しているのは証拠モデルと手動レビューの流れであり、文字起こし、自動抽出、顧客への導入実績ではありません。
範囲を限定した文字起こしコレクションを利用する権利がある場合、250米ドルのLocal Knowledge Terminalコレクション適合スプリントで、合意したサンプルを既存のマシン上で評価できます。まずは無料の適合確認から始めます。双方が書面の作業範囲に同意するまで、ソースのアップロードも支払いも行いません。
まず、元の言葉を残します。役立つ項目だけを分類してレビューし、すべての修正を残し、各グラフのエッジが会議まで戻るようにします。