議事録から要求を抽出する
――議事録は記録ではなく、要求の原石
ヒアリングが終わった後、何が起きるか
これまで4回にわたって、ヒアリングの場で起きていることを整理してきました。第1回では要件定義が失敗する3層構造、第2回では要求と要件の違い、第3回では暗黙知の引き出し方、第4回では初級SEが現場で迷うポイントを取り上げました。
これらはすべて、「ヒアリングの最中」の話です。今回は視点を変えます。ヒアリングが終わった後、何が起きるのか。手元に残った議事録を、どう扱うのか、という話です。
ヒアリングを終えると、SEの手元には議事録が残ります。多くの現場では、この議事録は「打ち合わせの記録」として保存され、必要なときに読み返すためのものとして扱われています。
しかし、要件定義というプロセスにおいて、議事録の本当の役割は「記録」ではありません。「要求の原石」です。
この視点の違いが、要件定義の品質に大きく影響します。今回は、議事録から要求を抽出するという作業について、その実態と難しさを整理します。
一般的な議事録と、ヒアリングの議事録は別物です
一般的に「議事録」という言葉を聞いて思い浮かべるのは、会議で決まったこと(決定事項)と、次に誰が何をするか(タスク・宿題)をまとめたものではないでしょうか。
社内の定例会議や、進行中のプロジェクトの打ち合わせでは、この形式が適切です。会議の目的は「物事を決める」ことであり、議事録の役割は「決まったことを記録し、次の行動につなげる」ことだからです。決まらなかった話、検討の過程で出た雑多な発言は、議事録には残されないことが一般的です。
しかし、要求のヒアリングにおける「議事録」は、これとは性質が異なります。
ヒアリングの目的は、「物事を決める」ことではありません。顧客の業務や要望について、できるだけ多くの情報を引き出すことです。ヒアリングの場で「決定事項」として確定することは、ほとんどありません。むしろ、断片的な発言、例え話、補足説明、「ちなみに」で始まる余談——一般的な議事録であれば省略されるような情報こそが、要件定義においては重要な意味を持ちます。
つまり、「決定事項と次のタスクをまとめる」という、一般的な議事録の作法のままヒアリングの議事録を書くと、本来残すべき情報の大半が、最初から記録されないことになります。
このことを理解していないと、「議事録はちゃんと書いている」という自覚があっても、実際には要件定義に必要な情報がほとんど残っていない、という状況に陥ります。
議事録には、何が混在しているか
ヒアリングの議事録を、前述の視点で書くと、そこには様々な種類の情報が、区別されずに並ぶことになります。
「月次レポートを自動化したい」という要求。「承認は部長が行う」という業務ルール。「予算は来年度の上期まで」という制約条件。「以前、似たようなシステムでトラブルがあった」という過去の経緯。「今日は天気が悪くて大変でしたね」という雑談。「この部分はちょっと不安があります」という感想。
これらが、同じ議事録の中に、時系列に沿って並んでいます。
要件定義書を完成させるためには、この中から「要求」を見つけ出し、さらに「機能要件」「非機能要件」「前提・制約条件」「ビジネスルール」「業務」「例外シナリオ」といったカテゴリに分類していく必要があります。
これは、議事録を書いた本人にとっても、簡単な作業ではありません。
議事録を「まとめすぎる」という問題
ここで、もうひとつ注意すべき問題があります。議事録そのものが、すでに「まとめすぎている」場合があるということです。
先ほど、一般的な議事録は「決定事項と次のタスク」をまとめる形式だとお伝えしました。多くのSEは、社内の会議などでこの形式に慣れています。そのため、ヒアリングの議事録を書く際にも、無意識のうちに同じ作法——要点を整理して記録する——を適用してしまうことがあります。
これは効率的な方法であり、一般的な会議であれば間違いではありません。しかし、ヒアリングにおいては、「何が要点か」を判断する力が、要件定義に関するノウハウに依存します。
十分な経験を持つSEであれば、後で重要になりそうな発言を見極めて、議事録に残すことができます。一方、経験が浅いSEの場合、その場では「重要ではない」と感じた発言を、議事録から削ってしまうことがあります。
問題は、削られた発言が、本当に重要ではなかったのかどうかを、後から検証できないという点です。議事録に残っていない情報は、原石そのものが存在しないのと同じです。どれだけ優れた抽出のプロセスを用意しても、原石に含まれていない情報を取り出すことはできません。
第3回でお伝えしたように、顧客が「まあ、基本的にはそうなんですけど」と発言した場合、この一言には例外条件が隠れているサインがあります。しかし、この言葉自体には具体的な情報がないため、議事録をまとめる際に「重要ではない雑談」として削除されてしまうことがあります。すると、後から見返しても、「例外があるかもしれない」という手がかり自体が残っていません。
これは、抽出する側の技術とは別の問題です。抽出の入力となる議事録そのものの質が、最終的な要件定義の品質に直結しています。
抽出という作業の実態
「議事録から要求を抽出する」という言葉を聞くと、シンプルな作業のように感じるかもしれません。しかし実際にやってみると、これは非常に地味で、時間のかかる作業です。
議事録を一文ずつ読みながら、「これは要求か」「これは要件か」「これは単なる前提条件か」「これは雑談か」を、ひとつひとつ判定していく必要があります。
第2回でお伝えしたとおり、要求と要件はそもそも別物です。議事録の中の発言は、要求のレベルで書かれていることもあれば、要件に近いレベルまで具体化されていることもあります。同じ発言の中に、要求と要件が混在していることも珍しくありません。
さらに、ひとつの発言が、複数のカテゴリにまたがることもあります。「A社向けの報告書は承認が必要で、部長が確認してから送付する」という発言には、要求(報告書を出したい)、業務ルール(承認フロー)、例外条件(A社向けは特殊)が、ひとつの文の中に同時に含まれています。
これを正確に分類するには、それぞれのカテゴリが何を意味するのかを理解していることはもちろん、議事録に書かれた言葉の背景にある文脈も理解している必要があります。
自分の議事録が、読めなくなる
私自身、こんな経験があります。
あるプロジェクトで、初回のヒアリングから数週間後、要件定義書をまとめる段階になって、初回の議事録を読み返したことがありました。
そこに書かれていた一文を見て、最初は意味が分かりませんでした。「○○の場合は、従来通りの対応とする」と書かれているのですが、「従来通り」が何を指しているのか、自分で書いたはずなのに思い出せないのです。
ヒアリングのその場では、「従来通り」という言葉だけで十分に理解できていました。顧客の説明を聞きながら、文脈の中でその言葉が指す内容が明確に分かっていたからです。しかし、文脈から切り離されて文字だけが残った議事録を、数週間後に読むと、その言葉は意味を失っていました。
結局、もう一度顧客に確認することになりました。「あの時おっしゃっていた『従来通り』というのは、具体的にはどういう意味でしたか」と。
幸い、このケースでは確認が取れましたが、相手すら「あれ、なんのことでしたっけ」という反応があることもあります。もし確認できなかったら、この一文はそのまま要件定義書に転記され、誰にも理解できないまま残っていたかもしれません。
同じ話が、複数の議事録に散らばっている
もうひとつ、現場でよく起きることがあります。
複数回のヒアリングを行うと、似たような話が、異なる回の議事録に、少しずつ違う言葉で記録されることがあります。
たとえば、1回目のヒアリングでは「月次レポートを自動化したい」という発言があり、3回目のヒアリングでは「毎月の報告書を作る手間を減らしたい」という発言があったとします。これは、おそらく同じ要求について、別の言葉で語られたものです。
しかし、議事録を別々に読んでいると、この2つが同じ要求だと気づきにくいことがあります。気づかなければ、要求一覧の中に「月次レポートの自動化」と「報告書作成の手間削減」という、似て非なる2つの項目が並んでしまいます。
これは単なる重複の問題ではありません。後工程で「この2つの要求は、それぞれ別に対応すべきものなのか、それとも同じものなのか」という確認作業が発生します。あるいは、確認されずにそのまま進み、似たような機能が2つ実装されてしまう、ということも起こり得ます。
複数回のヒアリングを重ねるほど、議事録は積み重なっていきます。その中から、同じ要求の異なる表現を見つけ出す作業は、人間が手作業で行うには大きな負担です。
なぜ、抽出作業は後回しにされるのか
ここまで述べてきたような抽出作業は、本来であれば各回のヒアリングが終わるたびに、こまめに行うのが理想です。記憶が新しいうちに整理すれば、「従来通り」が何を指すかも、すぐに分かります。
しかし実際の現場では、この作業は後回しにされがちです。
理由は単純です。ヒアリングが終わると、次のヒアリングの準備、他のタスク、別のプロジェクトの対応など、やるべきことが山積みになります。「議事録の整理」は、緊急性が低く見える作業です。誰かに急かされるものでもなく、後でまとめてやればいいと考えてしまいます。
そして、後でまとめてやろうとした頃には、複数回分の議事録が積み重なっています。記憶は薄れ、文脈は失われ、似たような発言がどこにどれだけ散らばっているかも分からなくなっています。
この状態で要件定義書をまとめようとすると、抽出作業そのものに、ヒアリングと同じくらいの時間がかかることもあります。そして、時間をかけても、見落としや重複が残ってしまう。
「書く時点」で構造化する、というアプローチの限界
この問題に対して、「議事録を書く時点で、要求・要件・前提条件などに分類して書けばいい」という考え方があります。
これは正しい方向性です。リアルタイムで分類しながら記録できれば、後からの抽出作業は大幅に減ります。
しかし、第4回でお伝えしたとおり、ヒアリングの最中にリアルタイムで「これは要求か、要件か、前提条件か」を判断しながら記録するのは、簡単なことではありません。
顧客の発言を聞きながら、その内容を理解し、適切なカテゴリに分類し、メモに残す。これを会話のスピードに合わせて行うには、ヒアリングそのものをこなすスキルに加えて、分類のスキルも同時に求められます。初級SEにとっては、これは非常に高い要求です。間違えました、初級SEかどうかに関わらず難しいのです。
つまり、「書く時点で構造化する」という理想と、「現実にはそこまでの余力がない」という実態の間には、大きなギャップがあります。
抽出という作業の、4つの難しさ
ここまでの話を整理すると、議事録から要求を抽出する作業には、4つの難しさがあります。
原石そのものの質の難しさ——一般的な議事録の作法をヒアリングに適用してしまうと、本来残すべき発言が、議事録を書く時点ですでに削られてしまいます。これは抽出の精度とは別の問題で、対象そのものが欠けているという、一段階手前の難しさです。
分類の難しさ——ひとつの発言が、要求・要件・前提条件・ビジネスルール・例外シナリオなど、複数のカテゴリにまたがることがあります。正確に分類するには、各カテゴリの定義を理解し、文脈を踏まえた判断が必要です。
重複の難しさ——同じ要求が、異なる回のヒアリングで、異なる言葉で語られることがあります。これを見つけ出すには、複数の議事録を横断的に見比べる必要があります。
トレーサビリティの難しさ——抽出した要求が、どの議事録の、どの発言に基づいているのかを記録しておく必要があります。これがなければ、後で「この要求はどういう経緯で出てきたのか」を確認することができません。
これら4つの作業を、複数回・複数人分の議事録に対して、漏れなく、かつ一貫した基準で行う。これが、要件定義における抽出作業の実態です。
まとめ
「議事録」という言葉には、一般的な会議で使われる意味と、要求ヒアリングにおける意味の、2つがあります。一般的な議事録は「決定事項と次のタスク」をまとめるものですが、ヒアリングの議事録は、要求を見つけ出すための「原石」です。この違いを理解していないと、議事録を書く時点で、本来残すべき情報の多くが失われてしまいます。
原石から有用な情報を取り出すには、分類・重複の検出・トレーサビリティの確保という、地味で手間のかかる作業が必要です。この作業は、ヒアリングの直後にこまめに行うのが理想ですが、現実には後回しにされやすく、積み重なるほど精度が落ちていきます。また、「書く時点で構造化する」というアプローチにも限界があります。リアルタイムでの分類は、ヒアリングそのものと同時に行うには負荷が高すぎるからです。
人間が手作業で行うこの抽出作業を、一貫した基準で、大量の議事録に対して行うことができれば、要件定義の精度は大きく変わります。
次回は、「要件の品質とは何か」を取り上げます。抽出された要求や要件が、そもそも「良い」とはどういう状態を指すのか、その基準を整理します。
この問題に、仕組みで向き合うツールがあります。
AiRee（アイリー）は、要件定義の完了度をスコアで可視化するAIプラットフォームです。「勘」に頼らず、構造的な欠落を検出します。
現在（2026年7月31日まで）、10社限定で無償トライアルを受付中です。
［先行トライアルに応募する →］ ［資料をダウンロードする →］
最後までご覧いただきありがとうございました。
メルマガ登録をしていただければ、コラムが更新された時にお知らせします。
また、AI要件定義プラットフォーム AiRee（アイリー）の情報も合わせてお届けします。