SalesDock ロゴSalesDock
業務改善

要件定義書のテンプレート|発注側が埋める欄と、埋まらない欄が意味すること

埋まらない欄は書けないのではなく、まだ決まっていない

10分で読める

ベンダーから「要件定義書を出してください」と言われる。テンプレートを探すと、資料請求と引き換えに配っているものが並ぶ。ダウンロードして開いてみると、項目は立派だが半分以上の欄が埋められない。

埋まらないのは書き方を知らないからではない。その欄に書くべきことが、社内でまだ決まっていないからだ。この記事は、公的な無料テンプレートを起点に、どの欄を発注側が持ち、埋まらない欄をどう扱うかを整理する。

発注書としての合意事項はCRM開発を発注する前に決めること、製品を選ぶ基準は中小企業のERP選定基準、金額の内訳はアプリの開発費用が扱う。この記事は要件定義書という文書の欄そのものに絞る。

無料の公的テンプレートがある

デジタル庁は「デジタル社会推進実践ガイドブック DS-120(デジタル・ガバメント推進標準ガイドライン実践ガイドブック)」を公開している。2026年6月12日版の第5章が要件定義にあたり、様式のひな形として要件定義書が示されている。別紙として要件定義書標準テンプレートがあり、たとえば「2.4. データに関する事項」にデータ一覧を置く構成になっている(DS-120 実践ガイドブック(PDF)デジタル庁 標準ガイドライン群、2026年8月26日に原文を確認)。

対象は政府情報システムなので、そのまま中小企業に当てはめると重すぎる。使い方は項目の借用だ。何を書く欄があるのかを知ってから、自社に要る欄だけ残す。ゼロから項目を考えるより速く、抜けも少ない。

第5章はStep.1からStep.7まであり、活動全体の流れ、事前準備、RFIの実施、要件定義の全体像、機能要件の定義、非機能要件の定義、要件定義終了後の対応という並びになっている。機能要件と非機能要件を分けて書くのが骨格だと分かる。

機能要件の欄

DS-120は機能要件について、機能、画面、帳票、データ、外部インタフェース等を記載するとしている。発注側が書ける形に置き換えると次のようになる。

  • 機能

    何ができる状態にするか。既存業務のどの手順を置き換えるかで書く

  • 画面

    誰がどの場面で見るか。画面数ではなく、使う人と場面で数える

  • 帳票

    外部へ出る紙とPDF。様式が決まっているものは先に現物を添える

  • データ

    何を持つか。DS-120の標準テンプレートは「2.4 データに関する事項」にデータ一覧を置いている

  • 外部インタフェース

    既存システムや外部サービスとの受け渡し。ここが漏れると後から一番高くつく

この5つのうち、外部インタフェースだけは性質が違う。他の欄は後から足せるが、連携先の見落としは設計をやり直させる。既存の会計ソフト、勤怠、ポータル、取引先から届くファイル。人が手で転記しているものはすべて外部インタフェースの候補になる。

非機能要件の欄

DS-120は非機能要件として、ユーザビリティ、システム方式、規模、性能、信頼性、情報セキュリティ等を挙げている。

  • ユーザビリティ

    誰が使うか。ITに慣れていない人が含まれるかを書く

  • システム方式

    クラウドか自社設置か。制約があるなら理由ごと書く

  • 規模

    利用者数、データ件数、ピーク時の同時利用

  • 性能

    待てる時間。体感で書いてよい

  • 信頼性

    止まったときに何が止まるか。何時間なら耐えられるか

  • 情報セキュリティ

    外に出せないデータ、権限を分ける単位

全部を数値で書く必要はない。発注側にしか答えられないのは、何人が使うか、止まると何が困るか、どのデータを外に出せないかの3つだ。残りはこの3つから逆算できるので、ベンダーと詰めればよい。

埋まらない欄の扱い方

空欄のまま渡すと、ベンダーは仮置きの前提で見積を作る。その前提が違っていたとき、差額は追加費用として出てくる。だから空欄を空欄で渡さない。埋まらない欄には次の3つを書く。

  1. 未決であること。
  2. 誰が決めるか。
  3. いつまでに決めるか。

この3行が入っているだけで、見積の前提が「仮置き」から「未決事項として明示」に変わる。未決の数と決定期限は、そのままプロジェクトのリスク一覧になる。設計や移行の段取りへどう効くかは基幹システム刷新が失敗する原因で扱っている。

書くのは発注側だという前提

DS-120は設計・開発の章で、はっきりこう書いている。

設計・開発を事業者に丸投げしては、良い情報システムは作れません。要件を事業者に正しく伝え、関係者間の調整を行い、進捗状況を正しく把握し、情報システムの出来具合をテストするのは発注者である職員自身です。

契約面でも同じ整理がある。IPAの「情報システム・モデル取引・契約書」(第二版・2020年12月22日公開)は、ユーザー企業とITベンダーのどちらにも偏らない中立的な契約条項を目指したもので、各工程で当事者が負うべき責任を説明した上でひな形を提供している(IPA「情報システム・モデル取引・契約書(第二版)」、2026年8月26日に確認)。要件定義は、責任の所在が発注側にある工程だという前提で作られている。

業務そのものの整理が先に要る場合は業務設計とはから入るほうが早い。要件定義書の欄が埋まらない原因が、業務側の手順が決まっていないことにある場合は多い。

来週できる一歩:外部インタフェースの欄だけ埋める

  1. いま人が手で転記している作業をすべて書き出す。
  2. それぞれについて、どこから来て、どこへ行くかを書く。
  3. ファイル形式と頻度を足す。
  4. 相手先の都合で形式を変えられないものに印を付ける。
  5. 印の付いたものを、要件定義書の外部インタフェース欄に写す。

この欄だけでも埋まっていると、ベンダーからの見積の精度が変わる。逆にここが空欄のままだと、金額は必ず後から動く。

システム発注と業務設計の記事は業務改善カテゴリで確認できる。

よくある質問

要件定義書のテンプレートは有料のものを買うべきですか?

まず無料の公的なものを見てから判断できます。デジタル庁の実践ガイドブックDS-120には別紙として要件定義書標準テンプレートがあり、機能要件・非機能要件の記載項目まで示されています。対象は政府情報システムですが、項目の立て方は民間の発注でも使えます。

要件定義書はベンダーが書くものではないのですか?

書く作業を手伝ってもらうことはできますが、決めるのは発注側です。デジタル庁の実践ガイドブックは設計・開発の章で「設計・開発を事業者に丸投げしては、良い情報システムは作れません」「要件を事業者に正しく伝え、関係者間の調整を行い、進捗状況を正しく把握し、情報システムの出来具合をテストするのは発注者である職員自身です」と書いています。

埋められない欄があるまま出してもよいですか?

空欄のまま渡すと、ベンダーが仮置きした前提で見積が出ます。埋まらない欄は「まだ業務側で決まっていない箇所」なので、空欄ではなく「未決・決める人・決める期限」を書いて渡すほうが、後の変更が減ります。

非機能要件まで発注側で書けません。

全部を書く必要はありません。非機能要件で発注側にしか答えられないのは、何人が使うか、止まると何が困るか、どのデータを外に出せないか、の3つです。方式や性能の数値はここから逆算する話なので、ベンダーと詰めれば足ります。

泉 款太(いずみ かんた)

株式会社SalesDock 代表取締役

慶應義塾大学法学部卒。スタートアップ、ラクスル、リクルート(SUUMO)を経て2025年に独立。 中小企業の経営・営業・業務・データをつなぐ事業基盤の設計と実装を支援。 不動産・製造業・クリニックを中心に、累計40社以上の支援に携わる。

代表者情報を読む →

この記事の数値について

本文中に一次資料へのリンクがある数値は、リンク先を出典としています。 リンクのない業務設計、判断基準、実務上の目安は、SalesDockが累計40社以上の支援と自社運用で得た知見を一般化したものです。 個別企業での成果を保証する数値ではなく、条件によって変わります。

NEXT STEP

手順の次に効くのは、着手する順番

個別の手順をつなげて成果にするまでの3ヶ月ロードマップを、無料資料にまとめています。