要件定義のテンプレート集 ヒアリングシート・要求一覧・業務フロー・優先順位表・チェックリストの型と使い方

「要件定義書のテンプレートは手に入れたが、そこに書く内容をどう集め、どう整理すればよいかわからない」「ヒアリングで聞き漏らしがあり、後から要件が追加になった」という悩みは、要件定義を担当する発注側の担当者やエンジニアに共通しています。要件定義の品質は、最終成果物である要件定義書だけでなく、そこに至る工程で使う道具の質で決まります。

この記事では、要件定義の工程ごとに使うテンプレートとして、プロジェクト定義シート、ヒアリングシート、要求一覧表と優先順位の基準、業務フロー記述シート、課題管理表・議事録、レビューチェックリストの6種類を、そのまま使える項目と使い方のポイントとともに紹介します。まずは、この記事の要点を表で確認してください。

確認したいポイント	結論	詳細
要件定義書以外にテンプレートは必要？	工程ごとの型があると品質が安定する	目的整理・ヒアリング・要求整理・業務フロー・課題管理・レビューの各工程に型を持つと、抜け漏れと属人化を防げる
ヒアリングで何を聞けばよい？	業務の流れ・例外・課題・要望・制約・非機能	通常の流れだけでなく例外的なケースと困った実例を必ず聞き、発言と解釈を分けて記録する
要求の優先順位はどう決める？	基準表で点数化し責任者が最終判断	目的への貢献度・業務への影響・対象範囲・実現難易度で採点し、判断の根拠を説明できる状態にする
承認前に何を確認する？	業務・情シス・経営・開発会社の観点で点検	業務が回るか、規程に適合するか、投資対効果が説明できるか、設計に進める粒度かを各関係者が確認し記録を残す

この記事でわかること

• 要件定義の工程と成果物の全体像、要件定義書以外にテンプレートが必要な理由
• プロジェクト定義シートとヒアリングシートの項目と使い方
• 要求一覧表の項目と、優先順位を付けるための基準の作り方
• 業務フロー記述シート、課題管理表・議事録の項目と運用方法
• 要件定義書を承認する前のレビューチェックリストと、AI開発で追加する項目

要件定義の工程と成果物の全体像

要件定義というと「要件定義書を書くこと」と捉えられがちですが、実際には目的の整理、関係者へのヒアリング、要求の収集と分析、優先順位付け、文書化、合意形成という一連の工程があり、それぞれに中間的な成果物があります。ここでは、工程と成果物の全体像と、工程ごとにテンプレートを用意する意味を整理します。

要件定義は複数の工程と成果物で構成される

独立行政法人情報処理推進機構（IPA）が公開している「ユーザのための要件定義ガイド 第2版」では、要件定義をビジネス要求定義、システム化要求定義、システム要件定義などの段階に分け、それぞれの段階で作成するドキュメントの種類と作成時の注意点を整理しています。また、要件定義で発生しやすい48の問題と、解決のための128の勘どころがまとめられており、発注側の担当者が工程を設計する際の参考になります。

（出典：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版」 https://www.ipa.go.jp/archive/publish/tn20191220.html）

実務で作成する中間成果物には、目的・体制を整理したプロジェクト定義、ヒアリングの記録、要求の一覧、現状と導入後の業務フロー、未決事項の管理表、レビューの記録などがあります。要件定義書は、これらの中間成果物を統合した最終形であり、中間成果物の質が要件定義書の質を決めます。

工程ごとにテンプレートを用意する意味

要件定義書のテンプレートだけを用意しても、そこに書く情報を集める方法が決まっていなければ、ヒアリングの聞き漏らしや、要望の整理不足、優先順位の曖昧さといった問題が起こります。工程ごとにテンプレートがあれば、誰が担当しても同じ手順で情報を集め、整理できます。

また、中間成果物がテンプレートで整理されていると、要件定義書の各章に転記するだけで文書化が進み、作成の負担が大きく減ります。「集める」「整理する」「決める」「書く」「確認する」の各工程に型を持つことが、要件定義を安定して進めるための基盤です。

要件定義書そのもののテンプレート（10章構成の記入欄と記入ガイド）は、要件定義書のテンプレートの記事で紹介しています。本記事は、その要件定義書を作るための工程で使うテンプレートを扱います。

【テンプレート1】プロジェクト定義シート

要件定義の最初に、プロジェクトの目的・ゴール・体制・制約を1枚に整理するシートです。このシートが、ヒアリングの範囲を決め、要求の優先順位を判断する際の基準になります。経営層や事業責任者と合意したうえで、関係者全員に共有します。

記入項目

• プロジェクト名／作成日／作成者／承認者
• 背景：現在の状況と、システム化を検討するに至った経緯（数値を含めて記載）
• 目的：システム化によって実現したいこと（経営上の課題との関係）
• ゴール：数値で測定できる目標／測定方法／達成時期（3つ程度に絞る）
• 対象範囲の仮説：システム化の対象と考えている業務／対象外と考えている業務
• 体制：プロジェクト責任者／業務要件の責任者／技術要件の責任者／意思決定の方法と頻度
• 制約：予算の上限／稼働開始の期限／準拠すべき規程・法令／既存システムとの関係
• リスク：現時点で想定される懸念と対策の方向性
• 要件定義の進め方：ヒアリング対象者と時期／要件確定の目標日／レビューと承認の予定

使い方のポイント

ゴールは「業務効率化」のような抽象的な表現ではなく、「問い合わせへの初回回答を2営業日から4時間以内に短縮する」のように、達成を後から判定できる形で書きます。ゴールが明確であれば、ヒアリングで出た要望を「このゴールに貢献するか」で判断できるようになります。

対象範囲は、この段階では仮説で構いません。ヒアリングを経て確定させる前提で、現時点の考えを書いておくことで、ヒアリング対象者の選定や質問の設計がしやすくなります。

【テンプレート2】ヒアリングシート

業務部門の担当者や管理者から、現状の業務・課題・要望・制約を聞き取るためのシートです。質問項目をあらかじめ用意しておくことで、聞き漏らしを防ぎ、複数の対象者から同じ観点で情報を集められます。事前準備・質問項目・記録欄の3つで構成します。

事前準備の項目

• ヒアリングの目的と、聞きたい内容の範囲
• 対象者：氏名／部門／役割（管理者・現場担当者・関連部門）／業務経験年数
• 実施日時／所要時間の目安／実施者／記録者
• 事前に共有する資料：プロジェクト定義シート、現状の業務資料（マニュアル、帳票、画面のサンプル）
• 対象者への事前依頼：普段使っている資料や、困っているケースの実例を持参してもらう

質問項目

質問は、業務の全体像から課題、要望、制約、非機能の順に進めると、話の流れが自然になります。

• 業務の概要：担当している業務は何か／1日・1週間・1か月の流れはどうなっているか／処理件数はどれくらいか
• 現状の業務フロー：業務はどこから始まり、誰が何をして、どこで終わるか／使っているシステム・ツール・帳票は何か／他部門や外部とのやり取りはどこで発生するか
• 例外的なケース：通常と異なる処理が必要になるのはどのような場合か／その頻度はどれくらいか／その場合どう対応しているか
• 課題：時間がかかっている作業は何か／ミスが起きやすい作業は何か／不便に感じていることは何か／それによってどのような影響が出ているか
• 要望：システムで解決したいことは何か／理想の業務の流れはどのようなものか／他社や他部門の事例で参考になるものはあるか
• 制約：変えられない業務手順やルールはあるか／法令や社内規程で守るべきことは何か／繁忙期や締め日など時期的な制約はあるか
• 非機能：利用する時間帯はいつか／同時に使う人数はどれくらいか／扱う情報に機密性の高いものはあるか／システムが止まった場合の影響はどれくらいか
• データ：業務で扱う情報にはどのような項目があるか／どこに保管されているか／他のシステムと重複しているデータはあるか
• その他：ほかに話を聞くべき人はいるか／確認しておくべき資料はあるか

記録欄と使い方のポイント

記録欄には、質問ごとの回答に加えて、「回答者の発言そのもの」と「実施者の解釈」を分けて記録します。発言をそのまま残しておくと、後から解釈のずれに気づけます。また、回答から派生した確認事項や、持ち帰りの宿題も一覧にしておきます。

ヒアリングの最も重要なポイントは、「通常の流れ」だけでなく「例外的なケース」と「困った実例」を必ず聞くことです。要件の抜け漏れの多くは例外処理から生じます。管理者と現場担当者では課題の見え方が異なるため、複数の立場から聞くことも欠かせません。

【無料資料のご案内】 要件定義から開発・運用までを一貫して支援するサービスの内容や、要件定義の進め方をまとめた資料を無料でご用意しています。まずは概要を確認したい方は、以下から資料をご請求ください。 ▶ 資料請求はこちら（https://nextscale.co.jp/service-document/）

【テンプレート3】要求一覧表と優先順位の基準

ヒアリングで集めた要望や課題を、1件ずつ要求として一覧化し、分類・優先順位付け・要件との対応付けを管理する表です。要求一覧表は要件定義の中核となる中間成果物で、最終的に要件定義書の機能要件・非機能要件に変換されます。

要求一覧表の項目

• 要求ID：R-001のように体系的に付番
• 発生元：誰が（部門・役職）、いつ（ヒアリング日）出した要求か
• 要求の内容：何を実現したいか（発言に近い形で記録）
• 理由・背景：なぜその要求が出たか、解決したい課題は何か（課題番号との対応）
• 分類：業務要求／機能要求／非機能要求／データ要求／運用要求／制約
• 対象業務：どの業務・どの画面に関係するか
• 優先度：必須／重要／あれば望ましい／対象外（判断の根拠を備考に記載）
• 実現方法の候補：システム化／業務の変更／既存ツールの活用／対応しない
• 対応する要件ID：要件定義書のどの要件に反映したか（対象外の場合はその旨）
• 状態：新規／検討中／採用／保留／対象外
• 備考：判断の経緯、関係者の意見、確認事項

優先順位を付けるための基準表

優先順位は、担当者の感覚ではなく、あらかじめ決めた基準で判断します。基準表の例は次のとおりです。

• 目的への貢献度：プロジェクト定義シートのゴールに直接貢献する（3点）／間接的に貢献する（2点）／貢献しない（1点）
• 業務への影響：この要求が満たされないと業務が成り立たない（3点）／業務は回るが大きな非効率が残る（2点）／あれば便利な程度（1点）
• 対象範囲：影響を受ける利用者が多い、または処理件数が多い（3点）／一部の利用者・処理（2点）／限定的（1点）
• 実現の難易度・費用：既存機能や設定で対応可能（3点）／標準的な開発で対応可能（2点）／高度な開発や外部連携が必要（1点）
• 判定：合計10点以上を必須、7〜9点を重要、6点以下をあれば望ましい、とする（数値は自社で調整する）

点数はあくまで判断の補助であり、最終的な優先度は責任者が決めます。ただし、「なぜこの要求が必須で、あの要求が対象外なのか」を基準に沿って説明できる状態にしておくと、部門間の調整や後からの異議に対応しやすくなります。

使い方のポイント

要求は、ヒアリング直後に一覧に転記し、内容が曖昧なものは発生元に確認して具体化します。1つの要求に複数の内容が含まれている場合は分割し、同じ内容の要求は統合します。要求と要件の対応を記録しておくことで、「この要望はどこに反映されたか」を発生元に説明でき、要件定義書の承認も得やすくなります。

要求を要件に変換した後の記入例は、要件定義書のサンプル・記入例の記事で紹介しています。

【テンプレート4】業務フロー記述シート

現状の業務（As-Is）と、システム導入後の業務（To-Be）を、同じ形式で記述するシートです。図で描く場合も、まず表形式で整理しておくと、抜け漏れや例外処理の確認がしやすくなります。

記入項目

• 業務名／作成日／作成者／確認者（業務担当者）
• 業務の目的と開始・終了の条件：何をきっかけに始まり、何をもって終わるか
• 登場する担当者・部門・外部関係者・システム
• 手順（1行1手順）：手順番号／担当者／作業内容／使用するシステム・帳票・データ／所要時間の目安／次の手順への条件
• 分岐と例外：どの手順で、どのような条件のときに、別の流れになるか／その流れの手順
• 課題の発生箇所：どの手順で、どのような問題が起きているか（課題番号との対応）
• To-Beでの変更点：どの手順が、システム化によってどう変わるか／担当者の作業がどう変わるか／新たに発生する作業

使い方のポイント

As-Isは、ヒアリングの内容をもとに作成し、必ず業務担当者に確認してもらいます。「実際はこうしている」という修正が入ることが多く、その修正のなかに要件の重要な情報が含まれています。

To-Beは、要求一覧で採用した要求を反映して作成し、手順ごとに「人が行う」「システムが行う」「人がシステムを使って行う」を明確にします。As-IsとTo-Beの手順を並べて比較できる形にすると、システム化の効果と、業務側で変えるべきことの両方が見えてきます。

【テンプレート5】課題管理表と議事録

要件定義の期間中は、確認事項や未決事項が数多く発生します。これらを管理せずに進めると、決まっていない事項が要件定義書に紛れ込み、後工程で問題になります。課題管理表と議事録は、要件定義を「決め切る」ための道具です。

課題管理表の項目

• 課題ID／登録日／登録者
• 課題の内容：何が決まっていないか、何を確認する必要があるか
• 関連する要求ID・要件ID
• 重要度：決まらないと要件が確定しない（高）／要件の一部に影響する（中）／後工程でも対応可能（低）
• 担当者：誰が対応・確認するか
• 期限：いつまでに結論を出すか
• 状態：未着手／対応中／完了／保留（保留の場合は再検討の時期）
• 結論と経緯：決まった内容と、その判断の理由

議事録の項目

• 会議名／日時／場所・形式／出席者（部門・役職）／記録者
• 議題ごとの記録：議題／議論の要点／決定事項／保留事項／宿題（担当者・期限）
• 決定事項の一覧：会議全体で決まったことを、要求ID・要件IDと対応付けて列挙
• 次回の予定と、次回までに準備すること
• 配布先と、内容確認の期限（異議がなければ確定とする旨）

使い方のポイント

議事録は「話したこと」の記録ではなく、「決めたこと」と「決めていないこと」を明確にする文書です。決定事項には必ず要求ID・要件IDとの対応を付け、保留事項は課題管理表に転記します。「決まっていない」ことを可視化し、期限を切って決めていく運用が、要件定義を予定どおり終わらせる鍵になります。

課題管理表は週次で見直し、期限を過ぎた課題は責任者に判断を仰ぎます。要件定義の終了時点で「高」の課題が残っている場合は、要件定義書を確定させる前に必ず解消してください。

【無料相談のご案内】 「要件定義を予定どおり進められるか不安」「AIを含むシステムの要件をどう整理すればよいか」といった具体的なご相談は、無料の相談予約からお気軽にお問い合わせください。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

【テンプレート6】要件定義レビューチェックリスト

要件定義書を確定・承認する前に、内容の妥当性を確認するためのチェックリストです。業務部門、情報システム部門、経営層、開発会社のそれぞれが確認する観点を分けて用意すると、レビューの質が上がります。

業務部門が確認する項目

• 現状の業務フローは実態と合っているか
• 導入後の業務フローで、実際に業務が回るか（例外的なケースを含めて）
• 自部門から出した要求が、要件に反映されているか、または対象外の理由が納得できるか
• 画面や帳票に、業務上必要な項目が漏れていないか
• 運用開始後の担当者と作業内容が明確で、実行可能か

情報システム部門が確認する項目

• 既存システムとの連携方法と、連携先の仕様の入手時期が明確か
• セキュリティ・データの取り扱いが社内規程に適合しているか
• 非機能要件が数値で定義され、自社の環境で実現可能か
• 運用・保守の体制と、自部門の役割が明確か
• データ移行の範囲・方法・責任分担が明確か

経営層が確認する項目

• 目的とゴールが経営課題と結び付き、投資対効果が説明できるか
• 対象範囲と予算・期間が整合しているか
• リスクと対策が把握されているか
• 意思決定の体制と変更管理の手順が明確か

開発会社が確認する項目

• 要件が設計に進める粒度で書かれ、曖昧な表現が残っていないか
• 機能要件と非機能要件に矛盾や実現困難な点がないか
• 前提条件と制約が明確で、見積もりの根拠として使えるか
• 検収条件が具体的で、テストで検証可能か

すべての観点で「はい」と答えられて初めて、要件定義書を承認します。レビューの記録（誰が、いつ、何を確認し、どう判断したか）を残すことで、承認の責任が明確になり、後からの認識のずれを防げます。

テンプレートを組み合わせて要件定義を進める方法

6つのテンプレートは、要件定義の工程に沿って順番に使い、互いにIDで対応付けることで効果を発揮します。ここでは、工程との対応、AI開発で追加すべき項目、生成AIの活用について解説します。

工程とテンプレートの対応

• 工程1 目的の整理：プロジェクト定義シートを作成し、経営層と合意する
• 工程2 情報収集：ヒアリングシートを使って関係者にヒアリングし、業務フロー記述シート（As-Is）を作成する
• 工程3 要求の整理：要求一覧表に要求を転記し、優先順位の基準で判定する。未決事項は課題管理表で管理する
• 工程4 要件の具体化：採用した要求をもとに業務フロー記述シート（To-Be）を作成し、要件定義書の各章に転記・具体化する
• 工程5 合意形成：レビューチェックリストで各関係者が確認し、議事録に決定を記録して承認する

課題番号・要求ID・要件IDで各テンプレートをつなぐことで、「この要件はどの要求から来て、どの課題を解決するのか」を常に追跡できます。テンプレート間の対応付けが、要件定義の説明責任を支える仕組みになります。

AI開発で追加する項目

AIを組み込んだシステムでは、各テンプレートに次の項目を追加します。

• ヒアリングシート：AIに任せたい判断は何か／その判断の正解は誰がどう決めているか／判断の根拠となる資料やデータはどこにあるか／AIが誤った場合に業務上どう対応できるか
• 要求一覧表：分類に「AI機能要求」「データ要求」を追加し、精度に関する期待値を記録する
• 業務フロー記述シート：To-Beに「AIが行う」「人がAIの出力を確認する」の区分を追加する
• 課題管理表：データの入手可能性、権利・個人情報の確認、精度目標の妥当性を初期の課題として登録する
• レビューチェックリスト：精度目標と評価方法、学習・参照データの要件、PoCの計画、運用時の精度管理が定義されているかを追加する

AI開発では、要件定義の段階でデータの現物を確認し、小規模な検証を挟むことが重要です。「決める前に試す」工程をテンプレートに組み込むことで、AI特有の不確実性に対応できます。

AI開発の要件定義や費用、開発会社の選び方については、AI受託開発の費用相場と開発会社の選び方の記事でも解説しています。

生成AIをテンプレートの運用に活用する

生成AIは、ヒアリングの録音や議事メモから要求一覧表の下書きを作る、業務マニュアルから業務フロー記述シートの草案を作る、要件定義書の下書きに対して曖昧な表現や矛盾を指摘する、といった用途で活用できます。

ただし、要求の優先順位や対象範囲の判断、関係者との合意は、人が担う必要があります。転記と整理と点検を生成AIに任せ、判断と合意形成は人が担うという役割分担で活用すると、要件定義の負担を減らしながら品質を保てます。

テンプレート活用で注意したいこと

テンプレートは要件定義を安定させる道具ですが、使い方を誤ると形式的な作業に陥ります。ここでは、活用時に注意したい3つのポイントを解説します。

テンプレートを埋めることを目的にしない

ヒアリングシートの質問をすべて聞き、要求一覧表の項目をすべて埋めても、それだけで要件定義が完了するわけではありません。重要なのは、集めた情報をもとに「何を実現し、何をしないか」を決め、関係者が合意することです。

テンプレートは「決めるための材料を揃える道具」であり、決めるのは責任者であるという認識を、関係者全員で共有しておきましょう。

規模に応じて簡略化する

小規模なプロジェクトで6つのテンプレートをすべて厳密に運用すると、負担が成果に見合わなくなります。プロジェクト定義シートとヒアリングシートを1枚にまとめる、要求一覧表と課題管理表を1つの表で管理する、といった簡略化が現実的です。

ただし、目的・ゴールの明確化、要求の一覧化と優先順位付け、承認前のレビューの3点は、規模にかかわらず省略しないことをおすすめします。

開発会社任せにしない

ヒアリングや要求整理を開発会社に委ねると、業務の実態と乖離した要件になったり、開発会社にとって都合のよい範囲で要件が決まったりする恐れがあります。要件を決める責任は発注側にあります。

発注側の担当者がテンプレートを使って主体的に情報を集め、判断し、開発会社は技術的な観点から助言と具体化を担う、という分担が理想です。社内に知見が不足している場合は、発注側の立場で要件定義に伴走してくれる会社を選ぶのも一つの方法です。

システム開発やAI活用の進め方については、NextScaleのコラム一覧でも関連記事を公開しています。

【無料相談のご案内】 要件定義の進め方に不安がある方、AIを組み込んだシステム開発を検討している方は、以下から無料の相談予約をご利用ください。目的の整理からヒアリング、要件定義、開発・運用までを一貫してご支援します。 ▶ 相談予約はこちら（https://nextscale.co.jp/consultation/）

まとめ

要件定義は、要件定義書を書くだけの作業ではなく、目的の整理、ヒアリング、要求の収集と優先順位付け、業務フローの整理、未決事項の管理、レビューと合意形成という一連の工程で構成されます。工程ごとにテンプレートを用意し、課題番号・要求ID・要件IDで対応付けることで、抜け漏れを防ぎ、判断の根拠を説明できる要件定義が実現します。

本記事で紹介した6つのテンプレートは、プロジェクト定義シート、ヒアリングシート、要求一覧表と優先順位の基準、業務フロー記述シート、課題管理表・議事録、レビューチェックリストです。特にヒアリングでは例外的なケースと困った実例を必ず聞き、要求には基準に沿った優先度を付け、承認前には関係者ごとの観点でレビューすることが、要件定義の品質を左右します。

AI開発では、AIに任せる判断の定義、データの確認、精度目標、人による確認工程を各テンプレートに追加し、「決める前に試す」工程を組み込みます。テンプレートを埋めることを目的にせず、発注側が主体的に判断し、関係者の合意を得ることを要件定義の完成の基準として、自社に合った型に育てていってください。