ヒアリングシートとは？システム開発の発注前に準備する項目とテンプレートの使い方

システム開発を外注するとき、最初のつまずきは「何を作りたいか」を発注者側が言葉にできないことにあります。ヒアリングシートとは、発注前に自社の現状・課題・要望・制約を項目ごとに整理し、開発会社へ正確に伝えるための準備文書です。この記事では、システム開発でヒアリングシートが担う役割と書くべき項目、テンプレートの使い方と作り方の手順を整理します。そのうえで、要件定義書・仕様書・RFPとの違い、発注者がヒアリングシートを主導することが見積り精度と開発の成否をどう左右するかを、発注者の立場から具体的に示していきます。

まとめ：ヒアリングシートは発注前の要件整理と認識共有の土台

ヒアリングシートは、発注者が「解きたい課題」と「今の状況」を先に書き出し、開発会社との最初の打ち合わせを噛み合わせるための準備文書です。目的・対象業務・現状の課題・要望・予算・納期を一枚に整理しておくと、初回のヒアリングが要望の聞き取りではなく提案のすり合わせから始められます。口頭だけで伝えた要望は抜け落ちや解釈のずれが生まれやすく、後工程の要件定義や見積りに跳ね返ります。

発注者にとっての勘どころは、ヒアリングシートを開発会社に丸投げせず、自社側の準備物として主導することです。埋められない項目があってもかまいません。むしろ「決まっていること」と「まだ決められないこと」を分けて示すだけで、開発会社は前提を掴みやすくなり、見積りの精度が上がります。ヒアリングシートで整理した内容はそのまま要件定義の工程に引き継がれ、最終的に仕様へと具体化されていきます。

ヒアリングシートとは何か｜システム開発の発注準備で認識をそろえる文書

ヒアリングシートは、システム開発の入り口で発注者と開発会社の理解をそろえるために使います。まずは定義と目的、必要とされる理由、誰がいつ作るのかを押さえます。

ヒアリングシートの定義と目的｜発注前に現状と要望を整理する準備文書

ヒアリングシートとは、開発を依頼する前に、発注者が自社の業務課題・現状のしくみ・実現したい状態・制約条件を質問項目の形で書き出した文書を指します。目的は二つ。ひとつは頭の中にある漠然とした要望を、他人に伝わる具体へ変換すること。もうひとつは、開発会社との初回打ち合わせで論点を共有し、聞き取りの時間を提案の時間に振り替えることです。「業務を楽にしたい」という願望を、「月末の請求書作成に3日かかっているのを半日にしたい」という測れる形へ落とす。その最初の翻訳がヒアリングシートの仕事だと考えると分かりやすいでしょう。

システム開発でヒアリングシートが必要な理由｜口頭伝達の抜け漏れ防止

システム開発は、発注者・営業・エンジニアなど複数の関係者が同じ情報を共有して進みます。口頭だけのヒアリングは、聞き手の解釈や記憶に依存し、担当者が変わると前提が引き継がれません。文書化しておけば、社内の複数部署から要望を集約するときにも記入欄が抜け漏れのチェックリストとして働きます。とくにシステム開発では、正常時の業務だけでなく例外処理や繁忙期のデータ量といった、口頭では出てきにくい情報が後の設計を左右します。書き出す過程そのものが、発注者自身の要望を棚卸しする機会になるのです。

誰がいつ作成するのか｜発注者の事前準備と開発会社のヒアリング

ヒアリングシートには二つの立場があります。ひとつは開発会社が営業活動で使う「聞くためのシート」、もうひとつは発注者が発注前に自社で整理する「答えるための準備」です。本記事が扱うのは後者にあたります。開発会社から様式を渡される場合もありますが、渡されるのを待たずに発注者側で先に現状と要望を整理しておくと、複数社へ相談するときに同じ土台で比較できます。作るタイミングは、開発会社を探し始める前後。要望が固まりきっていない段階でも、分かっている範囲から書き始めてかまいません。

ヒアリングシートに書く項目｜現状・課題・要望・制約を整理する構成

ヒアリングシートの項目は開発対象で変わりますが、発注者が発注前にそろえておきたい情報には共通の型があります。基本情報・現状把握・要望と優先順位の三層に分けて見ていきます。

基本項目｜システムの目的・対象業務・利用者・予算・納期の整理

最初に埋めるのは、プロジェクトの輪郭を決める基本項目です。次の要素が具体的に書けているかを目安にしてください。

• システム化の目的と、解決したい業務課題
• 対象となる業務範囲と、利用する部署・人数
• 想定するおおよその予算と、稼働させたい時期
• 社内の推進体制と、意思決定できる担当者

予算と納期は「未定」と書きたくなる欄ですが、幅でよいので数字を入れておきます。50万円規模なのか500万円規模なのかで、提案される作り方はまったく変わるためです。金額の当てがつかないときは「この課題にいくらまでなら投資したいか」という上限だけでも示すと、開発会社は現実的な選択肢を返しやすくなります。

現状把握の項目｜既存システム・業務フロー・データ量・課題の記録

次に埋めるのは、今の業務がどう回っているかを記録する現状把握の項目です。新しく作るものより、今あるものの情報が抜けると見積りが大きくぶれます。

• 現在使っている既存システムやツール、Excel台帳の一覧
• 対象業務の流れと、担当者ごとの作業手順
• 扱うデータの種類と、月間・年間の件数の目安
• 今の運用で困っている点と、その業務上の影響

見落とされがちなのがデータ量です。同じ受注管理でも、月200件と月2万件では必要なしくみが変わります。既存システムとの連携が必要なら、その製品名やバージョンも書いておくと、後になって「連携できない前提だった」という食い違いを防げます。

要望と優先順位の項目｜必須機能とあったら良い機能を切り分ける

最後に、実現したい機能を優先順位つきで書き出します。ここで全要望を同じ重みで並べると、予算内でどれを削るかの判断ができなくなります。「これがないと導入する意味がない必須機能」と「あれば便利だが後回しでよい機能」を分けて記入してください。たとえば在庫管理システムなら、在庫数のリアルタイム表示は必須、需要予測はあったら良い機能、という具合に線を引きます。優先順位を発注者自身がつけておくと、予算オーバー時の削り込みを開発会社任せにせず、自社の判断で進められます。フラットな要望リストは、そのままでは見積りの材料になりません。

ヒアリングシートのテンプレートと作り方｜項目の埋め方と注意点

ヒアリングシートは、テンプレートを出発点にすると記入漏れを減らせます。ただしひな型を埋めることが目的化すると、かえって要点がぼやけがちです。構成・作り方の手順・記入のコツの順に見ていきます。

テンプレートの構成｜そのまま流用せず自社の要件に寄せて調整する

ネット上や書籍で配布されるヒアリングシートのテンプレートは、基本項目・現状・要望・制約といった見出しをあらかじめ備えています。骨組みとしては役立ちますが、汎用のひな型ほど自社に不要な欄が混じり、逆に業界固有の制約を書く欄が足りません。テンプレートは抜け漏れ防止の枠として使い、自社の業務でしか出てこない事情――既存システムとの連携条件、繁忙期のデータ量、法令や社内規程による制約――に記入の密度を寄せます。削る判断と足す判断の両方が要る、という点を意識してください。

作り方の手順｜目的の定義から質問項目の設計と優先順位づけまで

ヒアリングシートづくりは、目的を先に定めてから項目を組み立てる流れで進めます。おおまかな手順は次のとおりです。

1. システム化で何を解決したいか、目的とゴールを一文で定義する
2. 対象業務と利用者を決め、関係する部署から情報を集める
3. 現状・要望・制約に必要な質問項目を洗い出す
4. 各要望に必須か任意かの優先順位をつける
5. 社内でレビューし、決まっていない項目に決定期限を添える

手順のなかで飛ばせないのが最後のレビューです。一人で書くと自部署の視点に偏るため、関係部署に目を通してもらい、現場でありえない前提が混じっていないかを確かめます。埋めきれない項目は空欄のままにせず、「誰がいつまでに決めるか」を書き添えておくと、開発会社との打ち合わせで宿題として扱えます。

記入のコツと失敗例｜あいまいな要望を具体的な数値に落とし込む

伝わるヒアリングシートの条件は、解釈の幅を残さないことに尽きます。「使いやすく」「速く」「柔軟に」といった評価語は、人によって基準が違うため、そのままでは要件になりません。「一覧画面は3秒以内に表示」「入力項目は1画面10個まで」のように、数値と条件で判定できる形へ言い換えます。よくある失敗は、正常時の業務だけ書いて例外を書かないことです。返品が発生したとき、繁忙期に件数が跳ね上がったとき、担当者が不在のときといった例外の扱いを書いておかないと、後の要件定義で穴が一気に表面化します。もう一つの失敗は、要望を盛り込みすぎて優先順位が消えることです。

ヒアリングシートと要件定義書・仕様書・RFPの違いと使い分け

ヒアリングシートは、要件定義書・仕様書・RFPと混同されがちです。これらは作る工程と役割が異なり、発注準備のどこで登場するかで棲み分けます。個別の違いを順に見ていきます。

要件定義書との違い｜ヒアリング内容を確定した要件へ落とし込む

ヒアリングシートは発注前に発注者が要望を整理する準備の文書、要件定義書は開発会社と一緒に「作るべき機能」を確定させる合意の文書です。ヒアリングシートに書いた「請求業務を半日で終えたい」という要望が、要件定義の工程で「請求データを自動集計し、承認後にPDFを一括出力する」という要件へ具体化されます。両者は連続しており、準備の質が要件定義の速さを左右する関係です。要件定義そのものの進め方は要件定義とは何かを解説した記事で詳しく整理しています。ヒアリングシートは、その要件定義に入る前の下ごしらえだと捉えてください。

RFP（提案依頼書）との違い｜複数社への要求提示か自社の整理か

RFP（提案依頼書）は、発注先を選ぶ前に発注者が候補各社へ要求と前提条件を提示し、提案と見積りを募る対外的な文書です。ヒアリングシートが自社内の要望整理を目的とするのに対し、RFPは各社に同じ条件で提案を競わせるための配布資料という違いがあります。実務では、発注者が自社整理のためにヒアリングシートを先に作り、その内容を土台としてRFPに書き起こす順序が現実的です。小規模な開発では、RFPまで作らずヒアリングシートを開発会社に共有して相談を始めるケースも多く見られます。

仕様書との関係｜ヒアリングから要件定義を経て仕様へ具体化する流れ

仕様書は、確定した要件をもとに「システムがどう動くか」を機能・画面・データの単位で書き下した文書です。ヒアリングシートの要望が要件定義で確定要件になり、それが仕様書で実装可能な粒度まで具体化される、という上流から下流への流れになります。発注者が仕様書のどこを確認すべきかは仕様書とは何かを解説した記事にまとめています。この三段階のうち、発注者が最も主体的に関わるべきなのが最上流のヒアリングシートです。ここが薄いと、どれだけ精密な仕様書を作っても、解くべき課題自体を外しかねません。

発注者がヒアリングシートを主導する意味｜準備の質が成否を分ける

ヒアリングシートは、開発会社に書かせる帳票ではなく、発注者が発注の主導権を握るための道具です。準備の質が見積りの精度と開発の結果を左右する、という点でここは発注者が手を抜けない領域になります。

発注者主導の準備が見積り精度を上げる｜丸投げが招く追加費用と手戻り

見積りは、渡された情報の解像度に比例して精度が上がります。要望を「よしなに」と丸投げすると、開発会社はリスクを織り込んで金額を高めに見るか、前提を仮置きして安く見積もり、後で追加費用として跳ね返るかのどちらかです。ヒアリングシートで対象業務・データ量・必須機能まで示しておけば、開発会社は根拠を持って見積もれます。準委任契約と請負契約の選び分けも、要件がどこまで固まっているかで判断が変わるものです。準備の薄さは、金額の上振れか完成後の食い違いという形で、最終的に発注者へ返ってきます。

作り込みすぎない線引き｜どこまで準備し要件定義に委ねるかの判断

一方で、ヒアリングシートを完璧に仕上げようとするのは行きすぎです。発注者だけで画面設計やデータ項目まで細かく決め込むと、開発会社の提案の幅を狭め、より良い作り方を引き出せなくなります。発注者が固めるべきは「何を解決したいか」「どこまでが必須か」という目的と優先順位まで。「どう作るか」は要件定義と設計の工程で、開発会社の専門性に委ねる線引きが現実的です。ヒアリングシートの完成度は、記入量の多さではなく、目的と制約が過不足なく伝わるかで測ります。埋まらない欄を無理に埋めるより、決められない理由を添えるほうが誠実な準備です。

準備段階から開発会社に相談する選択｜要件整理を伴走で進める方法

社内に上流工程の経験者がいない場合、ヒアリングシートを完成させてから相談する必要はありません。分かる範囲まで書いた段階で開発会社に持ち込み、残りの項目を一緒に埋めていく進め方もあります。要件定義から伴走する開発会社であれば、発注者が言語化しきれない要望を質問で引き出し、要件へ翻訳する役割を担うのが強みです。要件整理の段階から相談したい場合は、上流から入る業務システム開発の相談窓口を、発注者側の立場で使う方法があります。準備は、独力で完璧を目指すより、早めに専門家を巻き込むほうが結果的に近道になることが多いものです。

よくある質問

ヒアリングシートについて、発注準備の観点でよく寄せられる質問に回答します。

ヒアリングシートは発注者と開発会社のどちらが作りますか？

両方の立場があります。開発会社が営業で使う様式を渡してくることもありますが、発注前に発注者側で現状と要望を整理しておくと、複数社を同じ土台で比較でき、打ち合わせも提案から始められます。様式を待たずに、分かる範囲から自社で書き始めるのが実務では有効です。書いた内容は要件定義にそのまま引き継がれます。

ヒアリングシートと要件定義書は何が違いますか？

ヒアリングシートは発注前に発注者が要望を整理する準備文書、要件定義書は開発会社と作るべき機能を確定させる合意文書です。工程としてはヒアリングシートが先、要件定義書が後になります。ヒアリングシートの「こうしたい」が、要件定義で「システムがこう動く」という確定要件へ具体化される、という連続した関係です。

ヒアリングシートに最低限書くべき項目は何ですか？

目的（解決したい課題）、対象業務と利用者、現状の業務フローと既存システム、扱うデータ量、必須機能と任意機能の優先順位、そして予算と納期の目安です。とくに予算の幅とデータ量は、提案される作り方を大きく左右するため、概算でも入れておくと見積りの精度が上がります。決まらない項目は空欄にせず決定期限を添えます。

ヒアリングシートのテンプレートはそのまま使ってよいですか？

骨組みとしては役立ちますが、埋めるだけの使い方はおすすめしません。汎用のひな型には不要な欄が含まれる一方、自社の業界固有の制約や既存システム連携といった肝心な部分が抜けやすいためです。テンプレートで抜け漏れを防ぎつつ、案件固有の要件に記述の密度を寄せる使い方が現実的です。

ヒアリングシートを用意せずに発注するとどうなりますか？

要望が口頭ベースになり、解釈のずれや伝え漏れが起きやすくなります。開発会社はリスクを見て見積りを高めに置くか、前提を仮置きして後から追加費用が発生するかのどちらかに傾きがちです。最低限、目的・必須機能・データ量だけでも文書化しておくと、見積りのぶれと完成後の食い違いを大きく減らせます。

関連記事

• システム開発とは？種類・工程・依頼方法までの全体像：ヒアリングシートを含む発注全体の流れを俯瞰したい方向けの入門記事です。
• 要件定義書の書き方（サンプル）と章立て：ヒアリングシートの内容を確定要件へ落とし込む次工程の書き方を解説します。