要件定義書の書き方｜基幹システムの目次・サンプル・テンプレートで解説

要件定義書は、第三者が読んでも同じ動きを思い浮かべられることと、「作らないもの」まで書いてあることの2つで質が決まります。この記事では、基幹システムの要件定義書の書き方を、11章の目次、機能要件一覧のサンプル、あとで揉める書き方の直し方、確定後の変更管理まで、大手コンサルティングファーム出身の専門家の知見と公的機関の資料をもとに解説します。

要件定義書とは：発注側と作る側の「合意の記録」

要件定義書は、新しいシステムで何を実現し、何を実現しないかを、発注側（業務部門・経営）と作る側（ベンダー・開発会社）の間で合意した記録です。見積もり、設計、テスト、検収のすべてがこの文書を基準に進みます。基幹システムの要件定義書の書き方を誤ると、その後の工程すべてに影響します。

IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」（2019年）は、「システム開発の遅延の過半は要件定義の失敗にある」と言われていると紹介し、業務部門のユーザが主体的に要件定義へ関わる必要性を説いています。調査の数字もこれを裏づけます。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書2026」では、品質・予算・工期（QCD）の悪化に影響した工程として「要件定義」を挙げた企業が57.4〜69.0％にのぼりました。同じ調査で、機能要件定義を「ほぼ内製」「内製が多い」と答えた企業は46.1％、非機能要件定義では37.6％です。

※JUASの調査は東証上場企業とそれに準じる企業（回答957社）が対象です。中小企業にそのまま当てはまる数字ではありませんが、要件定義でつまずきやすい傾向は規模を問わず参考になります。

基幹システムは販売・在庫・購買・会計と業務の範囲が広く、書き漏れや解釈の違いがそのまま追加費用と工期の延長になります。なお、「要求定義」と「要件定義」は別物です。要求は「こうしたい」という業務側の希望、要件は「システムでこう実現する」と決めた内容です。違いは要求定義と要件定義の違いで詳しく解説しています。

基幹システムの要件定義書の目次（11章）

中小企業の基幹システムなら、次の11章で足ります。大企業向けの網羅的な様式をそのまま使う必要はありません。大事なのは資料の量ではなく、見積もりと判断に必要なことが抜けていないことです。

3章の業務フローは、現状と将来を並べて描くと、どこが変わるかが一目で分かります。描き方はAs-Is/To-Beとはで例を示しています。1章の「成功基準」は、「月次決算を締め日から5営業日で確定」「受注から出荷指示までを当日中」のように、刷新の前後で比べられる数字にします。

見落とされやすいのが11章の用語集です。同じ社内用語でも、部署によって指している数字が違うことがあります。次のような言葉は、要件定義の早い段階で意味をそろえておきます。

• 「在庫」：倉庫にある数か、受注で引当済みの分を引いた数か。検品前の入荷分を含むか
• 「売上日」：出荷した日か、取引先が検収した日か。月末の出荷はどちらの月に計上するか
• 「単価」：定価か、掛率をかけた後の金額か。値引きは単価に含めるか、別の行にするか
• 「納期」：自社から出荷する日か、取引先に届く日か

営業が言う「在庫」と倉庫担当が言う「在庫」が違えば、画面に出す数字の要件も変わります。用語集は数行でもよいので、最初の打ち合わせから作り始めます。

サンプル：機能要件一覧（製造業の例）

要件定義書の中心は4章の機能要件一覧です。次の表は、従業員120名・2拠点の金属部品加工業を例にした一覧の抜粋です。1行に1つの機能を、「誰が・何をすると・どうなる」の形で書きます。

※説明用の例です。成果物サンプルの全体は成果物サンプルで見られます。

この一覧で押さえたいのは3点です。

• 優先度を3段階に分ける：「必須／あれば／後回し」。全部を必須にすると、費用と工期の調整ができなくなります。
• 補足欄に「対象外」を書く：「OCRは対象外」「会計ソフトは現行を継続」のように、やらないことを同じ行で明記します。
• 前提条件も書く：「工場内Wi-Fiの整備が前提」のように、システムの外で必要な準備を書くと、発注側の作業が見積もりから漏れません。

IDは「業務の略号＋連番」にしておくと、テスト仕様書や課題一覧から「SD-05の締め処理で不具合」のように参照できます。検収のときに、どの要件が満たされたかを1行ずつ確認できるのも利点です。

非機能要件は「数字」と「誰が困るか」で書く

8章の非機能要件は、IPAの「非機能要求グレード」の6つの大項目（可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー）に沿って書くと漏れを防げます。非機能要求グレード2018は238の項目（メトリクス）を持ちますが、中小企業の基幹システムですべてを埋める必要はありません。まずは次の5項目を、業務の言葉で決めます。

※説明用の例です。数値は業務の実態と予算に合わせて決めます。

決め方の詳細は非機能要件とはで、6つの大項目ごとに解説しています。

帳票と外部連携は「一覧表」にして別紙にする

5章の帳票と7章の外部連携は、本文に文章で書くと抜けが見えません。1行1件の一覧表にして別紙にし、本文からは「別紙参照」とします。見積もりのとき、作る側は行数と難しさで工数を出せるようになります。

※説明用の例です。

帳票も同じ形で、「帳票名・使う人・出力のタイミング・現行の様式を残すか」を1行ずつ書きます。現行の帳票をすべて残そうとすると、それだけで追加開発が積み上がります。実際に毎月使っている帳票を、利用者と一緒に数えるところから始めると、標準の帳票で足りるものが見えてきます。9章の移行要件は、どのデータを何年分移し、件数と金額をどう照合するかまで書きます。進め方は基幹システムのデータ移行で解説しています。

あとで揉める書き方4つと、書き直し例

要件定義書で揉めるのは、発注側と作る側で解釈が分かれる言葉です。「柔軟に」「適切に」「使いやすく」「必要に応じて」が出てきたら、具体的な動作と受入基準まで書き直します。

要件が固まらないときに起きている3つのこと

要件定義が長引くとき、原因は書き方より手前にあることがほとんどです。よく見られる3つのパターンと対処をまとめます。

中小企業では特に2つ目が起きやすい傾向があります。「この取引先だけ処理が違う」「月末だけ特別な締め方をする」といった運用が、特定の担当者の頭の中にだけある状態です。大企業では「誰が何を決めるか」の整理が課題になりやすい一方、中小企業では「誰が何をしているか」を把握することが先決です。会議の順番や決め方は要件定義の進め方で解説しています。

要件定義書を書く5つのステップ

1. 目的と成功基準を経営と決める
   「今回の刷新で、経営上の何を改善したいか」「刷新後にどの数字が変わっていれば成功か」を最初に確認します。部門間で意見が分かれたときに誰が最終判断するかも、ここで決めます。
2. 現行業務を図にする
   主要業務の流れを、部署をまたいで1枚の業務フローにします。同じデータを何度入力しているか（転記の回数）を数えると、効果の大きい箇所が見えます。
3. 要望を集め、優先度をつける
   要望は大量に集めるより、「必須／あれば／後回し」に分けて範囲を決めることが本質です。
4. 機能要件一覧と周辺の章を書く
   機能要件一覧を中心に、帳票・データ・連携・非機能・移行の章を埋めます。受入基準（何ができればOKか）も同時に書きます。
5. 第三者の目で読み合わせる
   実際に入力する現場担当者に、見積から請求までの一連の流れで読んでもらい、今より負担が増えていないかを確認します。

4つ目のステップで書いた受入基準は、そのまま稼働前のテストの合否基準になります。「何ができればOKか」が要件定義書にないと、テストの段階で合否の議論がやり直しになります。テストの組み立て方はユーザー受入テスト（UAT）の進め方を参考にしてください。

確定した要件定義書を守る：変更管理のルール

要件定義書は、承認して終わりではありません。設計や開発が始まってから出る追加要望をどう扱うかを決めておかないと、合意した範囲が少しずつ崩れます。

公表されている裁判例に、旭川医科大学とNTT東日本の電子カルテシステム開発をめぐる札幌高裁2017年8月31日判決があります。Westlaw Japanの判例コラム第120号によると、ベンダーは625項目の追加開発要望を受け入れたうえで、それ以降は追加要望を出さないという「仕様凍結合意」を結びました。控訴審は、仕様凍結合意の後にユーザー側が要望を出したのは162項目だったと認定し、ユーザー側に約14億円の支払いを命じています。発注側が要望を出し続けることは、契約上のリスクにもなり得るという例です。

中小企業の基幹システムでも、確定後の変更は次のような簡単な表で管理すれば足ります。

※説明用の例です。

ルールは2つだけ決めます。影響を見積もってから判断することと、判断する人を1人に決めることです。口頭の「ついでにお願い」を受け付けない運用にすると、合意した範囲と費用が守られます。

提出前の10のチェックポイント

• 刷新の目的と、成功を測る数字が書かれている
• 対象範囲と対象外が明記されている
• 例外処理（特定の取引先・月末処理など）が洗い出されている
• 機能要件に優先度（必須／あれば／後回し）がついている
• 「柔軟に」「適切に」「使いやすく」「必要に応じて」が残っていない
• 各機能に受入基準（何ができればOKか）がある
• 外部連携の相手・データ・頻度・エラー時の処理が決まっている
• 移行するデータの範囲と、照合の方法が決まっている
• 発注側が担う作業（テスト・データ準備・研修参加）が書かれている
• 領域ごとの決裁者と、確定後の変更を判断する手順が決まっている

よくある質問

まとめ

基幹システムの要件定義書は、要望をそのまま並べる文書ではなく、実現する業務と優先順位を決め、作らないものまで明記した合意の記録です。曖昧な言葉を測れる基準に置き換え、決める人と決めたことを残し、確定後の変更は影響を見てから判断する。この3つを押さえるだけで、追加費用と手戻りの多くは防げます。

自社の場合はどこから整理すべきか分からない、という方は、無料診断で現状の課題と、構想策定で決めるべきことを整理します。