システム改修の要件ヒアリングの録音から、要件メモと次回の確認質問を作る

処理の起点を決める

ヒアリングの Teams 会議が終わったことを起点に、担当者が Copilot を開きます。 自動で動く仕組みは作りません。会議の後、その日のうちに担当者が指示文を貼り付けて送るのが、この構成のトリガーです。

理由は2つです。担当者が覚えているうちなら、抜き出しを確かめるために文字起こしを開く回数が減ります。 そして、次回の確認質問を早く送れます。 1週間後に問い合わせても、相手も会議の中身を忘れています。

もう1つの前提は、会議を設定する時点で決まります。 Copilot の会議オプションが「会議中および会議後」になっていなければ、会議の後には使えません。管理者のポリシーが既定値のままなら、この設定は開催者が変えられない形で入ります。 ポリシーを変えている組織では、情報政策課の5名に割り当てるポリシーを確かめてください。

入力データを集める

質を決めるのは、3つ目の聴取項目の一覧です。 これが無いと、Copilot は「話に出たこと」を整理するだけで、「話に出なかったこと」を指摘できません。 聞き漏れを減らすという目的は、この一覧を持って初めて果たせます。

画面名は、聞き取りでいちばん誤りやすい部分です。 会議チャットに書いてもらえば、Copilot はそちらも参照します。

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

データの取得に、プログラムは使いません。 文字起こしは、Copilot が会議の中で参照します。会議チャットと［要約］タブのどちらから Copilot を開いても、トランスクリプトが利用可能である限り、Copilot はチャットとトランスクリプトの両方を情報源に使えます。

文字起こしを書き出して別の場所に貼り付けることはしません。 手元にファイルが残り、保存の管理が二重になるからです。

注意が要るのは、定期的な会議で同じヒアリングを続ける場合です。定期的な会議での Copilot との以前の会話履歴は、シリーズの後の会議で文字起こしされた場合、使用できなくなるとされています。2回目のヒアリングでは、前回の要件メモを台帳から開き、前回の未決事項を指示文に貼り付けます。 前回の会話を Copilot が覚えている前提で組まないでください。

AIへ渡す前に整形する

1. 件名を先に書く … 指示文の冒頭に、台帳の受付番号、利用部門、担当者名を書きます。台帳の行と会議を結びつける鍵になります
2. 冒頭で名乗ってもらう … 会議の最初に、参加者に所属と名前を一言ずつ話してもらいます。会議室から複数人が1台の端末で参加する場合、発言者の表示だけでは誰の発言か分からないためです
3. 画面名はチャットに書いてもらう … 対象の画面・帳票の名前は、口頭だけでなく会議チャットにも書いてもらいます
4. 前回の未決事項を用意する … 2回目以降のヒアリングでは、前回の未決事項と確認質問を台帳から写しておきます
5. 雑談の範囲を区切る … 同じ会議で別の相談も話した場合は、どこからどこまでがこの相談かを、指示文で時刻を示して伝えます

2番目を軽く見ないでください。 係員の「それでいいです」と課長の「それで進めてください」は、同じ同意ではありません。 名乗りが残っていれば区別できます。

AIに処理させる

させるのは、文字起こしに書かれている発言を6つの欄に振り分けることと、聴取項目のうち話に出なかったものを挙げることだけです。

最も気をつけるのは「決まったこと」の条件です。 担当者が「対応できると思います」と言っただけでは決定ではなく、相手の「それでお願いします」と担当者の「そのように進めます」という往復があって初めて置きます。 未決事項に入りすぎた行を人が決定に上げるほうが、その逆より安全です。

「対象」を呼び名のまま書かせるのも意図してのことです。 「住民の一覧のやつ」を正式な画面名へ直させると、それらしい別の画面の名前に置き換わることがあります。 対応は担当者が登録時に付けます。

5行目がいちばん起きやすい失敗です。 「帳票に項目を足したい」とだけ話された相談で、出力形式を聞いていないのに「PDFで出力する」と書き足す、というものです。書き足した瞬間、それは聞き漏れではなくなり、次回の確認質問からも消えます。

指示内容を固定する

あなたは市の情報政策課で、利用部門から受けたシステム改修の要件ヒアリングを
記録する立場です。この会議の文字起こしと会議チャットだけを見て、
次の2つの表を作ってください。推測で埋めないでください。

【この相談】受付番号：{受付番号}／利用部門：{課・係}／担当：{担当者名}
【対象とする範囲】{開始時刻}〜{終了時刻}（指定が無ければ会議全体）
【前回の未決事項】{前回の未決事項。初回は「なし」}

■ 表1：要件メモ
列は「欄」「番号」「内容」「発言者」「時刻」「根拠の発言」の6つです。
欄は次の6つだけを使ってください。
  現状の困りごと／やりたいこと／対象／決まったこと／未決事項／次回の確認質問

【欄の振り分けのきまり】
- 「決まったこと」には、利用部門と情報政策課の両方が同意した発言が
  文字起こしに残っているものだけを入れてください。
  片方の発言だけのもの、「検討します」「たぶんできます」「確認します」を
  含むものは「未決事項」に入れてください。迷ったら未決事項です。
- 「対象」には、画面・帳票・データ・権限の名前を、話された呼び名のまま
  書いてください。正式な名前に直したり、似た名前に置き換えたりしないでください。
  会議チャットに名前が書かれていれば、そちらの表記を使ってください。
- 「根拠の発言」には、その行の根拠にした発言を文字起こしから
  そのまま写してください。言い換えないでください。
- 話に出ていない内容を書き足さないでください。一般的な進め方や、
  よくある仕様で埋めないでください。
- 改修するかどうか、優先度、工数、費用は書かないでください。
- 前回の未決事項のうち、この会議で結論が出たものは「決まったこと」に、
  出なかったものは「未決事項」にもう一度入れてください。

■ 表2：聴取項目の点検
列は「番号」「聴取項目」「状態」「時刻」「次回の確認質問」の5つです。
次の10項目それぞれについて、状態を「聴取済み」「一部」「未聴取」から
1つ選んでください。
  1 対象の画面・帳票・データ  2 使う人（課・係・人数）  3 発生の頻度と件数
  4 今のやり方（代わりの手段） 5 困っている理由と問題    6 期限とその理由
  7 権限・閲覧できる範囲      8 他の課・他システムへの影響
  9 出力の形式と項目の並び    10 承認する人
- 「聴取済み」は、その項目について具体的な答えの発言があるものです。
- 「一部」は、話題には出たが、数・範囲・期限などが決まっていないものです。
- 「未聴取」は、話に出ていないものです。
- 「一部」と「未聴取」には、利用部門に送る確認質問を1つずつ書いてください。
  質問は、はい・いいえでは答えられない形にしてください。
- 「聴取済み」の行の次回の確認質問は空欄にしてください。

2つの表のほかには、何も書かないでください。

「迷ったら未決事項です」を明記しないと、決定が増えます。 会議の終わりには「では、そういう方向で」といった曖昧なまとめが入ることが多く、何も言わなければ、そこを根拠に決定として拾います。禁じたいのは、雰囲気で決まったことにする判断そのものです。

「根拠の発言」を写させているのは、担当者の確認を速くするためです。 時刻だけでは、トランスクリプトを開いて探す手間が残ります。根拠の文が表の中にあれば、多くの行は表を読むだけで確かめられます。 写しと元の発言が違っていれば、その行は疑ってかかります。

質問を「はい・いいえで答えられない形」にさせるのは、 「権限は課全体でよいですか」では「はい」で終わるからです。「どの係の何人が見る必要がありますか」なら、数と範囲が同時に返ってきます。

出力形式を固定する

Copilot には、2つの表で返させます。 表の形になっていれば「Excel で開く」が使えるからです。台帳に貼るときの列の定義は、次のとおりです。

{
  "receipt_no": "受付番号",
  "department": "利用部門（課・係）",
  "owner": "情報政策課の担当者",
  "meeting_date": "ヒアリングの日付",
  "memo": [
    { "section": "現状の困りごと | やりたいこと | 対象 | 決まったこと | 未決事項 | 次回の確認質問",
      "no": 1, "content": "", "speaker": "", "time": "", "evidence": "" }
  ],
  "coverage": [
    { "item_no": 1, "item": "対象の画面・帳票・データ",
      "status": "聴取済み | 一部 | 未聴取", "time": "", "question": "" }
  ],
  "verified_by": "決まったことを確かめた担当者",
  "sent_to_requester": "要件メモを利用部門へ送った日",
  "requester_confirmed": "利用部門が確認した日"
}

memo は表1、coverage は表2に当たります。台帳の Excel では、memo を「要件メモ」シートに1行1項目で、coverage を「聴取点検」シートに1行1項目で貼り、どちらにも受付番号の列を付けます。 台帳の本体シートには、受付番号ごとに1行で、決まったことと未決事項の件数、未聴取の件数だけを数式で出します。

1つ目の理由は、欄が固定され、担当者ごとの粒度の違いがなくなることです。 後から読む人は、どの相談でも「決まったこと」の欄だけを見れば足ります。

2つ目は、evidence と time で、決定の根拠を後から確かめられることです。 担当が替わっても、なぜその仕様になったのかを、発言まで遡って読めます。第3章の（d）への答えがここにあります。

3つ目は、coverage で聞き漏れを数えられることです。 未聴取の多い相談は、設計の前にもう一度聞きます。最後の3列は人が埋め、設計に回すのは requester_confirmed まで埋まった相談だけにします。

システムへ連携する

この構成では、台帳への書き込みを自動化しません。 貼り付けるのは、担当者が「決まったこと」を確かめた後です。確かめる前の表が台帳に入る経路をあらかじめ作らないことで、未確認の決定が設計に流れるのを防ぎます。

指示文の最後に「2つの表のほかには、何も書かないでください」と書くのは、前置きの文章が付くと表の形が崩れ、貼り付けの手間が増えるからです。 要件メモを文書で送りたい場合は「Word で開く」を使います。

人が確認する

人が確かめるのは、「決まったこと」の全行と、次回の確認質問の取捨です。 他の欄は流し読みで足ります。

1. 「決まったこと」を1行ずつ確かめる … 根拠の発言を読み、両者の同意があるかを見ます。写しが元の発言と違うもの、片方の発言しか無いものは、未決事項へ移します
2. 「対象」の呼び名に、正式な画面名・帳票名を添える … 台帳の別の列に、担当者が正式な名前を書きます。呼び名の列は消さずに残します
3. 次回の確認質問を選ぶ … 案のうち、本当に聞くものを残します。会議の後に自分で分かったもの、他の課に聞くべきものは外します
4. 利用部門へ送る … 要件メモと確認質問を送り、決まったことに相違がないかを確かめてもらいます
5. 直した行を記録する … Copilot の出力から、どの行をどの欄へ移したかを台帳の備考に残します

1番目を省かないでください。 決定の誤りは、利用部門との約束の誤りです。確かめる前の決定を相手に送ると、AIが作った約束を情報政策課が引き受けることになります。

目標は、1件あたり12分です。 抜き出しの確認に8分、質問の取捨に2分、送信と貼り付けに2分という内訳です。

例外に対処する

上から4行目までは会議の設定の問題です。 会議テンプレートに Copilot の設定を含められるので、ヒアリング用のテンプレートで大半を防げます。

5行目にも注意が要ります。 開催者が参加者にコピーや転送を制限できるかは管理者が選べ、その設定は既定でオンです。 ヒアリングでは制限をかけない、と課で決めておきます。

記録を残す

• 会議の録画とトランスクリプト（OneDrive／SharePoint に録画と一緒に保存される）
• Copilot が返した2つの表の、貼り付ける前の原文（台帳の別シートに日付つきで残す）
• 担当者が直した記録 … どの行を、どの欄からどの欄へ移したか
• 正式な画面名・帳票名と、話された呼び名の対応
• 利用部門へ送った日と、確認が返ってきた日、指摘された相違
• 相談ごとの未聴取の件数と、そのうち次回のヒアリングで埋まった件数

「貼り付ける前の原文」を残すのは、抜き出しの誤りの傾向を見て指示文を直すためです。

トランスクリプトの保存期間は、組織のレコーディングのポリシーで決まります。 文字起こしが自動的に期限切れになるかどうかは、レコーディングのポリシーで管理するとされています。期限が来ると、決定の根拠の発言も消えます。 台帳の evidence 列に根拠の文を写しておくのは、そのための備えでもあります。