要件定義書の必要項目と書き方｜実案件のサンプルと未決事項の管理法（テンプレート付）

要件定義書に必要な項目は、業務要件・機能要件・非機能要件の3区分に整理できます。この3区分のうち、情報システム部門の関与が必要なのは非機能要件の一部だけで、残りは業務部門だけで書き進められます。そして実案件では、非機能要件の複数項目や基幹システムとの連携仕様が未確定のまま基本設計へ進んでいる例があります。止まらずに進める鍵は、未確定の項目を「未決事項一覧」として切り出し、何が判明したらどの項目を見直すのかをセットで記載しておくことです。以下、基本の書き方から順に解説します。

この記事を読み終えたとき、以下が実現できているはずです。

1. 要件定義書の標準的な章立てと、必要項目を確定できる
2. 打合せの回数、参加者、意思決定者1名の体制が確立できる
3. 決まらない項目を「未決事項一覧」として切り出し、設計フェーズに進む判断ができる
4. 契約前にツール側の制約を確認する質問リストができる

要件定義書は、「業務として何を実現したいか」を発注側（システムを使う会社側）の言葉で書いた文書です。基本設計書は、その要件をシステムでどう実現するかを設計側の言葉に翻訳した文書です。仕様書は、文脈によって指すものが変わりますが、多くの場合、実装（プログラムを作る作業）に必要な精度まで落とし込んだ文書を指します。

実務上の分かれ目は1点だけ覚えておけば十分です。「画面にどう表示するか」という話が出てきたら、それは要件定義ではなく設計の話です。

要件定義書に画面レイアウトを描き込み始めると、ボタンの位置や色といった議論に時間が吸われ、本来決めるべき「どの業務を、誰が、どの順番で行うか」が後回しになります。画面の話が出たら、いったんメモに退避させて、業務の話に戻してください。

要件定義書に記載する3区分

この表で注目していただきたいのは、右列の「誰が決めるか」です。3区分のうち2つは業務部門が主体で、情報システム部門の関与が必要なのは非機能要件の一部だけです。情報システム部門の手が空くのを待つ必要があるのは、全体のごく一部だということが分かります。

標準的な章立て（この構成で書けば漏れません）

はじめて要件定義書を書く場合は、次の章立てをそのまま使ってください。実案件でも、ほぼこの構成に収まります。

1. プロジェクト概要（背景・目的・期待効果）
2. 対象範囲（対象業務、対象部門、対象外とする範囲）
3. 業務要件（現行フロー、新業務フロー、関係部門と役割）
4. 機能要件（機能一覧、帳票一覧、承認フロー）
5. データ要件（項目定義、マスタ設計、コード体系）
6. 非機能要件（利用者数、データ件数、保存年限、権限、性能、可用性）
7. 外部連携要件（連携先システム、連携方式、連携項目）
8. 移行要件（移行対象データ、移行方式、移行時期）
9. 運用・保守要件（運用体制、障害時対応、バックアップ）
10. 制約条件・前提条件
11. 未決事項一覧
12. 対象外一覧

このうち11と12は、一般的なテンプレートには入っていないことが多い章です。本記事の後半で扱う中心の論点になります。

なお、公的機関が実際に使用した要件定義書は、総務省・IPA（独立行政法人情報処理推進機構）などが一般公開しています。分量の多い本格的な様式を確認したい場合は、そちらもあわせて参照してください。

要件定義書の一般的な進め方（5ステップ）

教科書的な手順も、ここで一度だけ整理しておきます。

1. 現状把握：現行業務のフローと課題を洗い出す
2. 要求の整理：関係部門から「こうしたい」を集め、優先順位を付ける
3. 要件への変換：要求のうち、今回実現するものを要件として確定する
4. 合意形成：関係者間で要件をレビューし、承認を得る
5. 文書化：上記の章立てに沿って要件定義書としてまとめる

3の「要求」と「要件」の違いは押さえておいてください。要求は関係者の希望、要件は今回実現すると決めたものです。この線引きをしないまま進めると、集まった要求がそのまま要件になり、範囲が際限なく広がります。

本記事の材料は、当社が2026年から進めている業務システムの導入前検証の記録です。

導入前検証とは、本格導入を決める前に、実際の業務データや帳票を使って「この業務がシステムに載るか」を試す取り組みで、一般にPoC（Proof of Concept＝概念実証）と呼ばれます。対象は9社、業種は製造・卸売・小売・建設・商社・ソフトウェア開発・教育、従業員規模は15名から2,300名まで幅があります。このうち、要件定義まで進んだ2件を取り上げます。

あらかじめお断りしておくと、以下は導入によってどれだけ効率化したかという効果の報告ではなく、設計段階で何が決まり、何が決まらなかったかの記録です。効果測定はまだ行っていませんが、そのぶん、一般的な導入事例では表に出てこない「決まらなかったこと」まで把握できています。

案件A｜見積から請求までを1つのデータでつなぐ

この企業の現行業務は、Excelマクロ（Excelの操作を自動化する簡易プログラム）による9ステップの連携で回っていました。

流れを追うと、まず営業担当が作成した見積情報を総務部門が受け取り、見積管理用のマクロに入力します。すると見積番号が自動で採番され、見積書と注文書が出力されます。次に、そのデータをマクロで納品書・受領書のシートへ引き渡し、同じように番号を採番して出力。さらに請求書のシートへ引き渡して請求番号を採番し、請求書と検収書を出力する——という流れです。

一見すると複雑ですが、この現行フローを文章で書き出しただけで、要件定義書の「業務要件」は8割方埋まりました。

ここに実務上の教訓があります。「あるべき姿」を白紙から構想して書き始めるより、いま実際に動いている手順を1ステップずつ書き出すほうが、圧倒的に早く進みます。すでに存在する業務には、誰がいつ何をするかという情報がすべて含まれているからです。

1. 最終的に出来上がった要件定義書・基本設計書の目次は、次の5構成でした。
2. 業務概要（現行フローと課題、新業務フロー）
3. 要件一覧
4. マスタ設計（項目定義）
5. マスタ設計項目タイプ

•  
• 帳票出力レイアウト（見積書／注文書／受領書・納品書／請求書／検収書）

3の「マスタ設計」とは、システムが扱うデータの入れ物を設計する作業のことです。どんな項目を持ち、それぞれの項目名を何とし、どういう順番で並べるかを一覧にします。この案件では、その一覧が316行になりました。1行が1項目にあたるので、316個の項目を定義したということです。

テンプレートを見て「項目が多すぎるのでは」と感じた場合、それは多すぎるのではありません。帳票6種類を1つのデータ構造に載せようとすると、この規模になるのが自然です。実務がその粒度で動いている、というだけのことです。

案件B｜取引先の署名を伴う帳票を電子化する

こちらのマスタ設計は151行でした。案件Aの半分以下の項目数です。ところが、

難易度は案件Bのほうが高くなっています。

理由は2点あります。1つは、社外である取引先が業務に関与すること。もう1つは、基幹システムとの連携が要件に含まれることです。

項目数の多さと設計の難しさは、必ずしも一致しません。関与する相手が社外に及ぶかどうか、既存システムとつなぐ必要があるかどうかのほうが、はるかに大きく効いてきます。

このうち原理原則［9］では、要件定義は発注者の責任であるとされています。ベンダーやツール提供元は、あくまで支援する立場です。また原理原則［4］では、利害関係者間の合意を得ないまま次工程に入ってはならないことが示されています。

ベンダーから「要件を出してください」と言われて困ってしまう状況は、この責任分担が社内で共有されていないときに発生します。「システムのことだからベンダーが考えてくれるはず」という前提でいると、話が噛み合わないケースも出てきます。

では、発注者側の誰が、何回集まればよいのでしょうか。案件Aで実際に行われた進め方は、次のとおりでした。

1. 打合せ回数：5回
2. 1回あたり：1時間
3. 意思決定者：部長1名
4. 持ち込んだ資料：現行のExcelと帳票サンプルのみ（業務フロー図や課題一覧は用意していない）

注目していただきたいのは最後の1点です。業務フロー図を事前に作らなくても、要件定義は進みます。

現行のExcelと帳票の実物さえあれば、そこから項目とフローを読み取れるためです。「まず業務フローを整理してから打合せに入ろう」と考えて、その整理に数週間かけているうちに着手が遅れる——これはよくある失敗です。それよりも、実物を持って打合せに入り、その場で一緒に読み解いていくほうが早く進みます。

一方で、案件Bにはウィークポイントもありました。要件定義の成果物に対する社内レビュー体制が設けられていないという点です。

この案件では、先方に要望をExcelにまとめてもらい、それに対して実現可否を追記していく、会話ベースの進め方をとっています。手軽で着手は早いのですが、「書き漏れている要件がないか」を第三者が点検する場がありません。抜けの検出が、担当者個人の記憶力に依存してしまいます。打合せ回数を減らす方針自体は問題ありませんが、その代わりにレビューの機会を1回だけでも設けておくことをおすすめします。

打合せの前に決めておく3点

1. 意思決定者を1名指名する →複数人の合議にしない。合議は「持ち帰って検討」を生みます
2. 現行のExcelと帳票の実物を全種類そろえる →一部だけだと、後から別の帳票が出てきて設計が変わります
3. 参加者に、その業務を毎日触っている人を必ず含める →管理職だけだと例外処理が漏れます

先ほど引用したIPAの原理原則17ヶ条には、原理原則［3］として「プロジェクトの成否を左右する要件確定の先送りは厳禁である」という条項があります。本記事の結論——「決まっていないと書いたうえで次工程へ進む」——は、一見するとこの原則に反しているように読めます。

矛盾しません。両者が指しているものが違うからです。

原理原則［3］が戒めているのは、決められるのに決めない状態です。関係者が集まれば決まる、資料を読めば分かる、判断すれば済む——それを「まだ先でいいだろう」と後回しにすると、設計が進んだ後で覆り、手戻りが発生します。これは確かに厳禁です。

一方、本記事が扱っているのは、現時点では決められない項目です。連携先の仕様書が保守ベンダーから出てこない、当時の担当者が退職していて経緯が分からない。この種の項目は、待っても自動的には決まりません。そして待っている間、決められる項目まで含めてプロジェクト全体が停止します。

そこで必要になるのが、両者を区別する基準です。次の1問で切り分けてください。

「この項目は、社内の誰かが判断すれば決まるか？」

1. 決まる → 先送り厳禁。今日、誰が判断するかを決めてください
2. 決まらない（社外からの情報待ち／既存システムの制約待ち） → 未決事項として管理したうえで、前に進んでください

そして、後者を「未決」とだけ書いて放置するのは、原理原則［3］が戒める先送りと実質的に同じです。次章で述べる書式——何が判明したら、どの項目を見直すのかまで書いて、はじめて「管理された未決」になります。この違いが、本記事の主張の要です。

外部連携｜AS/400にデータ連携できること

つまり、基幹システムとデータをやり取りすることが要件として確定しています。ところが、2026年8月時点でも基幹システム側の連携仕様の詳細は入手できていません。担当者の記録は次のとおりです。

基幹システム（AS/400）側の、連携仕様の詳細をまだ入手できていないので、現状は基幹システムの制約により定まった項目はありません。

一般的な解説記事では、「まず既存システムの制約を洗い出し、それを踏まえて要件を定義する」と書かれているのをよく見かけます。手順としては正しいのですが、現実には、その制約情報が出てくるまでに数ヶ月かかることがあります。保守ベンダーに問い合わせが必要だったり、当時の担当者がすでに退職していたりするためです。

案件Bで採られた4つの手順

1. 現行の3帳票から項目を抽出し、そのまま項目定義とする（いま使っている帳票に載っている項目は、少なくとも業務上必要だと確定しているため）
2. 明細の行数は、実際に運用されている帳票の実績値を根拠に確定する（この案件では2〜6行。「念のため多めに」ではなく、実績で決めます）
3. 一部の項目のみ、新しい運用に合わせて名称や型を変更する
4. 連携仕様が判明した時点で見直す前提を、要件定義書に明記しておく

このうち4が最も重要です。「未決」とだけ書いておくやり方では、後から誰も見返しません。数ヶ月後に仕様書が届いたとき、どの項目に影響するのかを誰も覚えていないからです。「何が判明したら、どの項目を見直すのか」をセットで書いてください。

未決事項の書き方（そのまま使えます）

要件定義書の末尾に「未決事項一覧」の章を設け、1件につき以下を書きます。

【未決事項No.3】
基幹システム連携の項目定義

現状：連携仕様書が未入手のため、現行帳票の項目をそのまま採用している
判明時に見直す対象：項目名、桁数、コード体系、連携単位（明細行数）
判明予定：情報システム部門経由で確認中。

時期未定 見直しの責任者：（氏名）

この記述があれば、基本設計へ進んで問題ありません。「決まっていないから進めない」ではなく、「決まっていないことを、決まっていないと管理したうえで進む」——これが要件定義書の実務的な使い方です。

なお、基幹システムを残したまま周辺業務だけを電子化していく進め方については、AS/400（IBM i）サポート終了で考える2層ERPでの運用についてもあわせてご覧ください。「2層ERP」とは、基幹部分は既存の大きなシステムに任せ、拠点や個別業務は軽量なシステムで補う構成のことです。

本記事の章立てと「未決事項一覧」をそのまま反映した（Excel・6シート）です。

業務要件・機能要件・非機能要件の記入シート、項目定義シート、未決事項一覧、契約前の確認リストを含みます。記入例つきなので、白紙から考える必要はありません。

▶ 要件定義書テンプレートをダウンロード（Excel／フォーム入力不要・そのまま保存できます）

案件Aのヒアリングでは、次のことが分かりました。同時利用人数、年間の見積件数、保存年限、権限の範囲は、いずれも先方に確認できていません。要件定義を完了して基本設計に入った時点でも、この4項目は未確定のままでした。

望ましい状態ではありませんが、現実には珍しいことでもありません。ここで重要なのは、「全部決めましょう」と号令をかけることではなく、先送りしてよい項目とダメな項目を区別することです。

補足しておくと、「従量課金」とはデータ件数や利用量に応じて料金が変わる方式のことです。この方式のサービスを選ぶ場合、年間件数の見積もりが月額費用に直結するため、先に概算を出しておく必要があります。定額制であれば、件数は後から分かっても支障ありません。

「可用性」は、システムが停止せずに動いている割合のことです。自社でサーバーを持つ場合は自分たちで決める項目ですが、SaaS（クラウド上で提供されるサービス）を使う場合は、提供元が示す稼働率をそのまま採用することになります。

そして、保存年限と権限の2つだけは、契約前に必ず決めてください。

保存年限は、法律で定められた保存期間（たとえば帳簿類は7年など）が関わるため、後から「実は10年必要だった」と分かると、すでに保存したデータの持ち方を作り直すことになります。権限の範囲は、「他部署の数字が見えてしまう」「本来見るべき人が見られない」という状態が発生すると、業務そのものが回らなくなります。どちらも、後から変えると影響が設計全体に及びます。

案件Aでは、要件定義を終えて基本設計に入った段階で、次のことが起きました。

要件定義後に、システムの画面に表示できる項目数の制限により、明細の表示項目数を変更した

見積書に載せる明細の項目数を要件定義の段階で決めていたにもかかわらず、ツール側の「1画面に表示できる項目数」の上限に引っかかり、基本設計の段階で項目を絞り直すことになった、ということです。

これは特定の製品の欠陥ではありません。画面や帳票に載せられる項目数、1レコードあたりの容量、添付ファイルのサイズ、承認段数の上限といった制約は、どのツールにも必ず存在します。そして、こうした制約はカタログや料金表に書かれていないことがほとんどです。営業資料は「できること」を紹介するために作られているためです。

したがって、こちらから質問しない限り、制約は分かりません。

契約前に提供元へ質問する7項目

1. 1画面に表示できる項目数の上限はいくつか
2. 明細（サブレコード）の行数に上限はあるか ※サブレコードとは、1件の申請や伝票に対してぶら下がる明細行のことです
3. 承認フローの段数と分岐条件に上限はあるか
4. 帳票出力の様式は、どこまで自由に変更できるか
5. 外部システムとの連携方式は何が使えるか（CSV／API／中間テーブル） ※CSVはファイルを受け渡す方式、APIはシステム同士が直接通信する方式、中間テーブルは双方が読み書きする共有の置き場を用意する方式です
6. 課金体系はユーザー課金か、従量課金か。ユーザー課金の場合、社外ユーザー（取引先）のアカウントも社内ユーザーと同じ単価か
7. 項目の追加・変更を利用者側で行えるか。行える場合、誰の権限で可能か

6について補足します。ユーザー課金は利用者1人あたりいくらで計算する方式、従量課金はデータ量や処理件数など、実際に使った量に応じて計算する方式です。この違いは、対象人数が増えたときの総額に大きく影響します。

一般論として述べると、ユーザー課金は、対象者が数名から十数名にとどまり、その全員が日常的に使う業務であれば、総額が読みやすい方式です。一方、対象者が全社員規模に及びながら1人あたりの利用頻度が低い業務では、使っていない人の分まで費用が発生するため、総額が膨らみやすくなります。どちらが有利かは対象人数と利用頻度の組み合わせで決まるため、「そもそも人数で課金される仕組みなのか、使った量で課金される仕組みなのか」を先に確認したうえで、自社の条件を当てはめて試算してください。

この7点の回答を書面でもらい、要件定義書の付録として綴じておいてください。それだけで、基本設計での手戻りがかなり減ります。

画面と項目の作り方についてはデータテーブル機能、外部連携についてはデータ連携・システム間連携の課題で詳しく扱っています。

前述の商社（300〜500名規模）でも、社内から次の懸念が出ていました。

やりたいことが1つの製品で本当にできるのか。やりたいことが増えると高額になって頓挫するのではないのか

この懸念はもっともです。そしてこの企業では、実際にスコープ（対象範囲）を絞る判断が行われています。対象としていた3帳票のうち1つは、伝票を出力した後の社内回覧のワークフローが複雑であることを理由に、PDFの出力までを今回の対象とし、その先の回覧は範囲外としました。回覧については、当面これまでどおりメールで運用します。

ここで大切なのは、絞ったこと自体ではありません。「やらないと決めたこと」を要件定義書に文字で書いてください。書かないと、後から「これもできると思っていた」という認識のずれが必ず発生します。そして、その指摘は稼働直前に出てくることが多く、対応の余地がありません。

要件定義書に「対象外一覧」の章を設け、1件につき以下を書きます。

【対象外No.1】
価格交渉票の、出力後の社内回覧

対象外とする理由：出力後のワークフローが複雑で、今回の期間内に設計が収まらないため
現行運用の継続：出力したPDFを、従来通りメールで回覧する
将来の扱い：第2段階で検討する（時期未定）

「現行運用の継続」を必ず書くのがポイントです。対象外にした業務が宙に浮かず、「当面はこのやり方で回す」ことが明示されるためです。

スコープを絞る3つの判断基準

1. 対象業務の件数が多い（同じ作業が何度も発生するほど、自動化の効果が出やすいため）
2. 現行データがすでに構造化されている（Excelの表や定型の帳票になっている。紙のメモや口頭伝達だと、まず整理から始める必要があります）
3. 関与する部門が少ない（合意形成にかかる時間が短く、決めた内容が覆りにくいため）

3つとも満たす業務が、最初の対象として最も成功しやすい候補です。

取引先に見せる範囲は、機能単位ではなく業務手順単位で切る

社内の承認がどこまで進んでいるかは、取引先にとって必要な情報ではありません。むしろ、社内の決裁状況が外部から見えることには不都合もあります。案件Bでは「社内の進捗は取引先側に見せない」ことが要件になりました。

このとき、線引きの基準を「この機能は見せる／この機能は見せない」という機能単位で考えると、判断がぶれます。基準にすべきなのは既存業務の手順単位（だれがいつ何をするか）です。

案件Bの場合、もともとメールで依頼と資料の送受信をしていました。そこで、「確認依頼を出してから、確認書を受け取るまで」という現行のやり取りの範囲を、そのまま取引先の操作範囲としています。現行業務でやり取りしていた範囲と一致させれば、取引先側も迷いません。

承認段数は、実運用と設定可能上限を分けて定義する

案件Bの要件一覧には「階層は5階層まで指定できること」と書かれています。一方、実際の運用は4段（上長→支店長→仕入責任者→本社業務部）です。

なぜ実運用より1段多く確保しているのか。組織変更が起きたときや、例外的な案件で承認者が1人増えたときに、システムの改修を発生させないためです。上限に余裕がないと、そのたびにベンダーへ依頼が必要になります。

つまり、要件定義書には「現在の段数」ではなく「設定可能な上限」を書いてください。

なお、この4段の順序がなぜこの順番なのかは、社内でも根拠が確認できていません。長年運用されてきた承認ルートは、こうして理由が失われたまま引き継がれていることが少なくありません。システム化のタイミングは、それを見直せる数少ない機会になります。

送信と受領を、別々の要件として立てる

紙に署名捺印をもらう業務を電子に置き換える場合、送る側の機能だけを設計して終わりにしてしまいがちです。しかし実際には、受け取る側の設計も必要になります。

案件Bでは、PDFを取引先へ送信する機能と、押印済みPDFを取引先から受領する機能を、別々の要件として定義しています。1つの機能として書いてしまうと、受領時のファイル形式やファイル名の付け方、誰に通知するかといった論点が抜け落ちるためです。

4以外の非機能要件が未決のままでも、進めて構いません。重要なのは、未決であること自体ではなく、未決であることが管理されているかどうかです。

補足として、前述の9社では、ヒアリングシートの評価指標（KPI）欄がほぼ全社で空欄または「不明」でした。つまり、「何をもって導入可と判断するか」を決めないまま検証に入る企業が大半だということです。裏返せば、未決事項一覧を作って持っているだけで、社内の合意形成は他社より一歩先に進みます。

Q1. 要件定義書は何ページくらいになりますか？

分量よりも、章立てが揃っているかどうかで判断してください。本記事で紹介した案件では、帳票6種を対象にして項目定義が316行、帳票3種で151行でした。ページ数の目安を示すなら、対象帳票1種類あたり項目定義が20〜50行、本文が5〜10ページ程度に収まることが多くなります。ページ数を増やすことが目的ではありません。

Q2. 要件定義書と基本設計書は、必ず分けて作る必要がありますか？

分けたほうが安全です。ただし、小規模な案件で作成者が同じ場合、1冊にまとめている例もあります。分ける・分けないよりも重要なのは、「業務としてどうしたいか（要件）」と「システムでどう実現するか（設計）」を、文書内で区別して書くことです。混ざると、後から変更が発生したときに、どこまでが業務の決定でどこからが技術の選択かが分からなくなります。

Q3. 非機能要件の欄が全部埋まりません。提出してよいのでしょうか？

保存年限と権限の範囲の2つが決まっていれば、他が未確定でも提出して差し支えありません。ただし空欄のままにせず、「未決事項一覧」の章に切り出し、判明時に見直す対象項目まで書いてください。空欄と「管理された未決」は、受け取る側にとってまったく別物です。

Q4. 業務フロー図は事前に作るべきですか？

必須ではありません。本記事で紹介した案件Aは、現行のExcelと帳票サンプルだけを持ち込み、打合せ5回（各1時間）で要件定義を完了しています。フロー図の作成に数週間かけて着手が遅れるくらいなら、実物を持って打合せに入り、その場で読み解くほうが早く進みます。

Q5. ベンダーに要件定義から依頼することはできますか？

支援を依頼することは可能です。ただしIPAの原理原則17ヶ条の原理原則［9］が示すとおり、要件定義そのものは発注者の責任とされています。ベンダーに委託した場合でも、成果物の内容に責任を負うのは発注者側です。委託する場合は、「誰が最終的に承認するか」を社内で先に決めておいてください。

止まる地点は、体制・連携仕様・非機能要件の3つに分かれます。体制については、意思決定者を1名に指名し、現行のExcelと帳票の実物を持って打合せに入ってください。実案件では5回×1時間、決裁者1名で要件定義が完了しています。

連携仕様が出てこない場合は、現行帳票から項目を抽出して先に確定させ、「何が判明したら、どの項目を見直すのか」をセットで記載してください。ただし、社内の誰かが判断すれば決まる項目を後回しにするのは、IPAの原理原則［3］が戒める「先送り」です。社内で決まるものは今日決める、社外待ちのものは管理して進む——この線引きが要点になります。

非機能要件は、保存年限と権限の2つだけを必ず決め、それ以外は条件付きで先送りできます。SaaS・ノーコードに載せる場合は、契約前に7つの制約を提供元へ質問してください。

すべてが決まってから書き始める必要はありません。未決事項一覧を手元に持って、基本設計へ進んでください。

要件定義書テンプレート（Excel・6シート）をご用意しています。

業務要件・機能要件・非機能要件の記入シート、本記事で紹介した「未決事項一覧」シート、項目定義シートのひな形、契約前に確認すべき7つの制約の質問リストを含みます。記入例つきで、どこに何を書くか迷わない構成です。
▶ 要件定義書テンプレートをダウンロード（Excel／フォーム入力不要）

自社の要件がシステムに載るかどうかを検討する段階では、バックオフィス業務の課題整理と、ノーコードでの実現範囲をまとめた資料もあわせてご覧いただけます。
▶業務効率化に役立つ資料をダウンロードする（資料請求）

関連記事
業務システム導入の課題とROIの考え方
レガシーシステムからの脱却
情報システム部門の課題と活用例
工事台帳とは？記載項目と作り方｜エクセル運用の限界と移行設計

※本記事の実案件に関する記述は、当社が2026年から実施している導入前検証（9社・2026年8月時点で完了1社）のヒアリング記録および要件定義段階の設計書に基づきます。社名・拠点別の内訳・具体的な金額は伏せています。検証の完了報告ではなく、設計段階の記録です。

出典：独立行政法人情報処理推進機構（IPA）「超上流から攻めるIT化の原理原則17ヶ条」