Kakusillで議事録を要件定義へ｜5つの整理

はじめに

「前回の打ち合わせで決まったはずです」。開発会議でこの一言が出た瞬間、参加者は議事録を検索し始める。ところが、残っているのは発言の要約だけだ。誰が承認したのか。例外時はどうするのか。未決のまま持ち越した条件は何か。実装に必要な答えが見つからない。

議事録は会議を振り返る記録であり、要件は開発判断に使う約束である。似ているようで役割が違う。AIに議事録を短くまとめさせても、この差は埋まらない。むしろ、要約の過程で少数意見や保留事項が消えることもある。

Kakusillでは、会議メモや既存資料を取り込み、業務フローや要求のたたき台へ整理できる。ただし、AIに文書を渡してボタンを押せば要件定義が終わるわけではない。決定、根拠、未決、影響範囲を分け、人が合意する工程が要る。ここでは「10万円以上の申請は部長が承認する」という発言を追いながら、実装へ渡すための5つの整理を紹介する。

議事録を要件定義へ変えるなら要約と分ける

議事録には、決まったことだけでなく、質問、反論、雑談、仮説も混ざる。一方、要件には対象範囲、利用者、正常時の動き、例外、受け入れ条件が必要だ。「申請を簡単にしたい」という発言だけでは、実装者は画面も権限も決められない。

JUASの生成AIを使った要求・要件定義研修でも、音声からの議事録作成と、要求分析、機能要求、非機能要求の整理は別の工程として扱われている。この切り分けは重要だ。音声認識の精度と、要件の妥当性は同じ指標ではない。

他の要件定義支援サービスでも、議事録の構造化や曖昧さの検出が重視されている。CoBrainの機能紹介は、議事録などの関連文書から構造化した要件文書を作り、曖昧さ・抜け漏れ・矛盾を確認する流れを示している。また、会議メモをAIで要件へ変える実践例は、要約よりも「抽出」と「分類」にAIを使う考え方を紹介している。

では、何を分類すればよいのか。実務では次の5つに分けると扱いやすい。

1. 発言を「事実・要望・決定・未決」に分ける

最初から要件文に整えようとすると、AIが行間を補いやすい。先に発言の性質を分ける。

• 事実：現在は紙の申請書を総務が転記している
• 要望：スマートフォンから申請したい
• 決定：承認は課長と部長の2段階にする
• 未決：部長不在時の代理承認者は決まっていない

この4区分なら、「要望」を「決定」と誤認する事故を減らせる。例の発言は決定候補だが、「10万円は税込みか」「誰の承認を得たか」がまだ分からない。運用上は、元発言の時刻や発言者も記録しておきたい。Kakusillへ取り込む情報の範囲と保持方法は、導入時に確認が必要である。根拠へ戻れなければ、きれいに整った文章ほど修正が難しいからだ。

正直なところ、雑談を完全に消す必要はない。「毎月末だけ申請が集中する」といった一言が、性能要件の手がかりになることもある。ノイズと断定せず、要件候補へ昇格しなかった発言として残しておく。

2. 決定事項を業務フローの位置へ置く

要件は単独の箇条書きでは動かない。誰が、いつ、何を受け取り、次に誰へ渡すのか。業務フロー上の位置が決まって初めて、前後の条件が見える。

例の発言を、申請、課長承認、部長承認、経理連携の流れへ置く。10万円未満は課長承認から経理へ進み、10万円以上だけ部長承認を通る分岐になる。すると、差し戻し先、代理承認、承認後の取消、連携失敗時の再実行が質問として浮かぶ。Kakusillで作る場合も、箱を並べるだけでなく、担当、入力、出力、例外を結び付ける。

KakusillでTo-Be業務フローを作る際の5項目では、到達点と開始・終了条件、廃止・統合・自動化、例外、責任・承認、効果の確認を扱っている。議事録から抽出した決定をこの枠へ置くと、言葉だけでは見えなかった抜けが見つかる。

3. 未決事項を「確認質問」に変える

未決事項は欠陥ではない。隠したまま実装へ渡すことが問題だ。「代理承認者は未定」と記録したら、担当者、期限、決定に必要な選択肢を付ける。

質問は具体的にする。「金額で承認を分けますか」では弱い。「10万円は税込みか。申請1件の金額か、月間累計か。ちょうど10万円を含むか」まで分ける。回答が得られなければ、金額分岐を初回リリースの対象外にする判断もできる。

AIに質問を作らせるときは、原文にない答えを埋めないよう指示する。出力は「確認済み」「回答待ち」「今回対象外」の状態で管理する。この状態がなければ、翌週の会議で同じ論点をまた話すことになる。

4. 要件を受け入れ条件まで具体化する

会議で合意した言葉を、そのまま開発要件にしてはいけない。「素早く表示する」「使いやすくする」「必要に応じて通知する」は、人によって解釈が変わる。

例の発言を申請機能へ落とすなら、次のように確かめられる形へ変える。

• 税込金額が100,000円未満なら、課長承認後に経理連携へ進む
• 税込金額が100,000円以上なら、課長承認後に部長承認へ進む
• 金額を変更して再申請した場合は、承認経路を再判定する
• 部長が差し戻す際は理由を必須にし、申請者へ通知する
• 承認経路の判定結果と承認者を監査記録に残す

ここまで書けば、設計者は処理を分解でき、テスト担当者は合否を判定できる。AIが読める仕様書の7項目で紹介した目的、入力、処理、出力、例外、制約、受け入れ条件にもつながる。

もちろん、すべてを1回の会議で確定させる必要はない。未確定の値には仮の数字を入れず、「測定後に決定」と明示する。もっとも危ないのは、AIがもっともらしい数値を補い、それが合意済みに見える状態である。

5. 原文・変更・承認を一本で追えるようにする

最後の段階は文書生成ではなく、追跡性の確保だ。要件ごとに、元発言、関連する業務フロー、変更理由、承認者、承認日を結ぶ。

たとえば、金額の境界を10万円から20万円へ変更したとする。最新版だけ残すと、なぜ変更したのか分からない。「10万円以上では部長の処理件数が多すぎる」という試行結果が根拠なら、変更理由と影響するテスト条件まで記録する。元発言、変更理由、承認者、承認日は推奨する管理項目であり、実際にどこまで自動で保持できるかは導入時に確認する。

Kakusillの公式ページでは、要求・設計・テストをつなぎ、変更の影響範囲を追う考え方を紹介している。議事録を入口にする利点は、会議の記録を保存できることではない。判断の出発点から実装、テストまでを辿れることにある。

1つの会議に絞って試す

いきなり過去の議事録を全部取り込むと、確認作業が膨らむ。直近の会議を1件だけ選び、次の順で試す。

1. 決定、要望、事実、未決を抽出する
2. 決定を業務フローへ配置する
3. 未決を確認質問へ変える
4. 重要な要件を受け入れ条件まで書く
5. 元発言と承認者へ戻れるか確認する

評価するのは文章の美しさではない。未決事項の見落とし数、確認に戻れた割合、要件から元発言へ辿る時間を見る。比較記事で紹介される「作成時間」だけでは、後工程の手戻りを測れない。

AIに任せる範囲、人が決める範囲

AIは大量の発言から候補を抽出し、同じ形式へそろえる作業が得意だ。一方、利害が衝突する場面の優先順位、法務・セキュリティ上の許容、予算との引き換えは決められない。

AIに任せる範囲は、抽出、分類、重複検知、質問案、文書の初稿まで。人が担うのは、スコープ決定、例外の採否、数値目標、責任者の指名、最終承認である。この境界を先に決めると、AIの誤りがそのまま仕様になるのを防げる。

要約ではなく、合意の履歴を作る

議事録を要件定義へ変える目的は、長文を短くすることではない。決まったこと、決まっていないこと、その根拠を、次の判断に使える形で残すことだ。

Kakusillを試すなら、まず直近の会議1件から始めてほしい。元発言へ戻れるか。未決事項が質問になっているか。受け入れ条件で合否を決められるか。この3点を確認するだけでも、単なるAI要約との差が分かる。

会議記録や既存仕様が散らばり、要求整理の進め方から設計したい場合は、Kakusillの導入相談で現状を聞かせてほしい。資料の集め方、業務フローへの落とし方、実装へ渡す仕様の粒度まで一緒に整理できる。