要件定義書の書き方｜記載項目6つと作成手順6ステップ、RFP・要件仕様書との違い

要件定義書の書き方の話をする前に、そこで何を作ろうとしているのかから始めます。ここを飛ばすと、あとの事故の話が伝わらないからです。

題材は、経費精算システムの入れ替えです。

いまの状態はこうです。社員が紙の申請書に領収書を貼って提出し、上長が印鑑を押し、経理が金額と科目を確認して、月次で振込データを作る。月末になると、経理が数日がかりで確認しています。

新しいシステムの目玉は、AIによる読み取りです。領収書をスマートフォンで撮ると、日付・金額・支払先を読み取って、申請を自動で作る。入力の手間がほぼゼロになります。

ここで、なぜ要件定義が必要になるのかというと、作る側と発注する側が、別の会社だからです。

自分たちで作るなら、頭の中の像がずれても、作りながら直せます。外に頼むと、ずれたまま3ヶ月進みます。 だから作る前に、何を作るかを文書で合意する。

言葉を先にそろえます。要件定義とは、システムで何を作るか——実現すべき機能と満たすべき条件——を、業務の目的から落とし込んで確定させる工程です。よく似た言葉の要求定義は、その一歩手前で、発注側が「業務として実現したいこと」を整理する工程を指します。要求（やりたいこと）を要件（作るものの条件）に変換して確定させるのが要件定義、と分けると混乱しません。

そして、要件定義書とは、その確定した内容を発注側と開発側で合意するための文書です。業務上の目的、対象範囲、実現する機能、性能やセキュリティの条件、そして何をもって完成とするかの判定基準を書きます。

そして今回は、AIが工程の中に入ります。 ここが従来の要件定義と違うところで、あとで効いてきます。

従来のシステムは、書かれていないことをしません。 仕様書に無い動きはしない。だから仕様書の網羅性が、そのまま品質になりました。

AIは、書かれていないことをします。 役に立とうとするからです。網羅性だけでは、品質にならない。

前置きはさておき、本題に入ります。

今日は、この要件定義を教科書どおりに書いて、動かして、そこで何が起きたかという話をしていこうと思います。

① 教科書どおりに、要件を書く

要件定義とは

要件定義とは、作るシステムが「何を満たしていれば完成といえるか」を、発注側と開発側の合意として文書に確定させる工程です。システム開発の最上流に置かれ、ここで決めたことが以降の設計・実装・テストの基準になります。

似た言葉に「要求定義」があります。要求は利用者側が「こうしたい」と言うこと、要件は開発側が「ではこう作る」と引き受けられる形に翻訳したものです。要求のまま契約すると、実現方法が決まっていないので見積もれません。要求を要件に翻訳する作業そのものが、要件定義です。

要件定義書とは｜何のために作る書類か

要件定義書は、その合意を残した成果物です。目的は3つあります。

• 合意の証拠にする — 「言った・言わない」を後から確かめられる状態にする
• 見積もりの根拠にする — 何をどこまで作るかが決まらないと金額が出ない
• 完成の判定基準にする — 検収のときに、この書類と突き合わせる

3つ目が実務では効きます。検収でもめる案件は、たいてい「完成の定義がこの書類に書かれていなかった」案件です。

要件定義書・要件仕様書・要求定義書の違い

現場で混ざりやすい3つを、書く人と粒度で分けます。

書類	書く人	粒度
要求定義書	発注側（利用部門）	やりたいこと。実現方法は書かない
要件定義書	発注側と開発側の合意	満たすべき条件。ここが契約と検収の基準になる
要件仕様書	開発側	実現方法。画面・項目・処理まで踏み込む

呼び名は会社ごとに揺れます。名前を統一するより、「この書類は検収の基準になるのか、ならないのか」を先に確認するほうが実務的です。

RFP・RFIとの違いと、作る順番

発注側が書く3つの文書は、目的も時期も違います。

	目的	相手
RFI（情報提供依頼書）	どんな会社・製品があるかを集める	複数のベンダー
RFP（提案依頼書）	提案と見積もりを出してもらう	候補に絞ったベンダー
要件定義書	作るものを確定させる	発注先が決まった1社

順番は RFI → RFP → 発注先の決定 → 要件定義書 です。要件定義書を先に完成させてから相見積もりを取る形もありますが、その場合は要件定義だけを別契約で発注することになります。RFPの書き方はRFPの書き方｜必須項目とRFI・要件定義との違いに整理しています。

要件定義書に、決まったフォーマットは存在しない

探すと様式が何種類も出てきますが、法律や規格で定められた書式はありません。IPA（情報処理推進機構）が公開している事例集も、業種や規模ごとの分類であって、「この様式で書け」というものではありません。

だからこそ、項目の抜けは自力で防ぐしかありません。次に挙げる6つを目次にして、埋まらない欄を残さないのが最短です。

記載項目1｜システム概要（目的・背景・範囲）

何のために作るのか、いま何が困っているのか、どこまでを対象にするのか。この3つを最初に置きます。

実務で効くのは「範囲」です。対象に入れるものより、対象に入れないものを名指しで書くほうが後で揉めません。「今回は在庫管理を含まない」の一行が、追加要望を切り分ける根拠になります。

記載項目2｜用語定義

同じ単語を、部署ごとに違う意味で使っていることがあります。「案件」「顧客」「締め日」あたりが典型です。

用語定義は飾りではなく、テストの合否を分けます。「締め日」が締める日なのか締めた翌日なのかで、月次の集計結果が1日分ずれます。

記載項目3｜業務要件

システムではなく業務の側を書く欄です。次を含めます。

• 業務フロー — 誰が、どの順で、何を渡すか
• 利用者の一覧 — 部署・人数・役割
• 運用規模 — 1日の件数、繁忙期の倍率、保持する期間
• システム構成 — 既存のどのシステムと、どうつながるか

運用規模を数字で書いておくと、非機能要件が自動的に決まります。「1日3,000件、月末は5倍」と書いてあれば、必要な処理性能はそこから逆算できます。

記載項目4｜機能要件

システムが「する」ことを列挙します。実務では次の切り口で漏れを潰します。

• 画面 — 一覧・詳細・入力・検索。それぞれ誰が見るか
• 権限 — 誰が、どの画面の、どの操作をできるか
• 帳票・出力 — 印刷物、CSV、PDF。書式と出力単位
• データ — 保持する項目、必須か任意か、桁と型
• 外部インタフェース — 連携先、方式、頻度、失敗したときの扱い
• データフロー — どこから入って、どこへ出ていくか

権限の欄は最後に回されがちですが、最初に書くべき欄です。権限が決まらないと画面の出し分けが決まらず、画面の数が確定しません。

記載項目5｜非機能要件

「する」ことではなく、「どういう状態であるか」を書きます。IPAの分類に沿うと6つです。

• 可用性 — 稼働時間、停止してよい時間、障害時の復旧目標
• 性能・拡張性 — 応答時間、同時利用者数、将来の増加見込み
• 運用・保守性 — 監視、バックアップ、誰が面倒を見るか
• 移行性 — 既存データをいつ、どうやって移すか
• セキュリティ — 認証、権限、ログ、個人情報の扱い
• システム環境・エコロジー — 設置場所、対応ブラウザ、互換性

非機能要件は、書かないと「暗黙の期待値」になります。「止まらないと思っていた」は要件ではありません。数字を1つ入れてください。「月間稼働率99.5%」「応答3秒以内」で十分です。

記載項目6｜体制・役割分担・スケジュール・予算

作るものだけでなく、作る側の条件も書きます。

• 体制 — 発注側の窓口は誰か、決裁者は誰か
• 役割分担 — テストデータの用意、既存システムの調査、ユーザ教育を誰がやるか
• スケジュール — 工程ごとの期間と、発注側の作業が必要な日
• 予算 — 総額と、含まれていないもの

いちばん抜けるのは「発注側の作業」です。テストデータの用意やマスタの整備は発注側の仕事になることが多いのに、書かれていないためスケジュールに載っていません。

書き方の手順1｜現状の業務とシステムを把握する

いまどうやっているかを先に書き出します。担当者の頭の中にしかない手順を、紙に出す工程です。

ヒアリングだけで済ませないでください。実際に使っている台帳やExcelを見せてもらうと、説明では出てこなかった例外処理が必ず出てきます。

書き方の手順2｜要求を引き出し、明確にする

「こうしたい」を集め、なぜそうしたいのかまで掘ります。手段で言われた要望を、目的に戻して聞き直すのがコツです。

「一覧画面にボタンが欲しい」の裏に「毎朝30件を手で転記している」があるなら、ボタンではなく自動取り込みが答えになることがあります。

書き方の手順3｜要件の優先順位を決める

全部は入りません。必須・推奨・任意の3段階に分け、必須の理由を1行添えます。

「なぜ必須なのか」を書いておくと、後で削れます。理由が「前のシステムにあったから」なら、削る候補です。

書き方の手順4｜システム全体の構成を決める

新規に作る部分、既存を流用する部分、パッケージを買う部分に切り分けます。

ここで既存システムの連携方式を確定させておかないと、後工程で「相手側が対応できない」が発覚します。相手のシステムの担当者に、この時点で一度当ててください。

書き方の手順5｜業務・機能・非機能に分けて書く

集めた要求を、前述の3分類に振り分けて文書化します。

振り分けられない要求が必ず残ります。「使いやすくしてほしい」のような要求です。残ったものは、測れる形になるまで戻して聞き直します。「3クリック以内で申請が終わる」なら要件になります。

書き方の手順6｜予算とスケジュールを決める

確定した要件から工数を積み、期間と金額を出します。

要件が固まる前に日程だけ先に決まっている案件が多いのが実情です。その場合は、日程に入る範囲を必須要件から順に切り、入らなかったものを「今回やらないこと」として明記します。

関係者の合意｜誰の承認をもって確定とするか

要件定義は、書き終わりではなく承認された瞬間に終わります。承認者を1人に決め、日付を残してください。

関係部署が多いときほど、承認者を1人にします。全員一致を条件にすると、いつまでも確定しません。

確定した後の変更管理

要件は必ず変わります。変えないための仕組みではなく、変わったことが全員に伝わる仕組みを先に決めます。

• 変更の申請先と承認者を決める
• 変更が金額と日程に与える影響を、そのつど出す
• 変更履歴を要件定義書と同じ場所に残す

影響を出さずに受けた変更が、後から工程を押します。「これくらいなら」を積み上げないでください。

書くときのポイント1｜発注側と開発側で、同じ絵を見る

文章だけで合意すると、読み方が分かれます。画面のラフ、業務フロー図、データの流れ。絵を1枚挟むと解釈のずれが減ります。

絵に描けないものは、まだ決まっていないものです。描こうとして手が止まった箇所が、抜けている箇所です。

書くときのポイント2｜専門知識がなくても読める文にする

要件定義書を読むのは開発者だけではありません。利用部門も、決裁者も読みます。専門用語を使うなら、用語定義に載せてから使います。

読み手が判断できない書類は、承認されても合意になっていません。「よく分からないが問題ないだろう」で押された印は、後で覆ります。

書くときのポイント3｜要求ではなく、課題の解決策になっているか

要望を全部並べただけの書類は、要件定義書ではなく要望一覧です。冒頭に書いた課題が、この要件で解けるかを1つずつ照らします。

どの課題にもひもづかない要件が残ったら、削る候補です。

書くときのポイント4｜抜け漏れの潰し方

チェックの仕方を決めておかないと、分量が増えたぶんだけ見落とします。

• 業務フローの矢印を1本ずつ指でたどる — 矢印の先に受け手がいるか
• 権限の表を、役割×画面のマスで埋める — 空欄が残っていないか
• 外部連携を、失敗したときの動きまで書く — 成功時しか書いていないことが多い
• 「今回やらないこと」を一覧にする — 書かれていない＝やる、と読まれる

4つ目が効きます。やらないことの一覧は、要件定義書の中でいちばん短く、いちばん役に立つ節になります。

要件定義書は誰が作るのか

発注側と開発側の共同作業です。実際に文書に落とすのは開発側（SIerやベンダーのSE）であることが多いのですが、業務の中身を決めるのは発注側です。

発注側に「決められる人」がいないと、要件定義は止まります。窓口が伝言役だけだと、質問が返るたびに数日かかります。

ExcelやPowerPointで作ってもよいのか

問題ありません。決まった様式が無い以上、道具も自由です。表が多いならExcel、絵が多いならPowerPoint、文章が多いならWordが向きます。

ただし、版と最新の所在だけは決めてください。メールに添付されたファイルが3つ流通している状態が、いちばん危険です。

要件定義には、どのくらい期間がかかるのか

規模によりますが、開発全体の1〜2割を充てるのが目安として使われます。半年の開発なら3〜6週間程度です。

短くしたいときは、範囲を狭めます。期間だけを削ると、決まっていない項目を抱えたまま設計に入ることになります。

要件定義でよく起きる失敗

現場で繰り返し見るのは、次の4つです。

• 要望を集めただけで終わる — 優先順位も、やらないことも決まっていない
• 非機能要件が空欄 — 性能と運用が、暗黙の期待値のまま残る
• 発注側の作業が書かれていない — テストデータもマスタも用意されないまま日程が来る
• 承認者が決まっていない — 誰も確定させないので、いつまでも変わり続ける

どれも「書き方」の問題ではなく「決め方」の問題です。書式を整えても、この4つは埋まりません。

書き方の型は確立しています。機能を洗い出し、画面を数え、非機能条件を並べる。

経費精算は業務がはっきりしているので、かなり具体的に書けます。

“`
【正常系】
・領収書を撮影 → AIが日付・金額・支払先を読み取り → 申請が作成される
・申請者が内容を確認して提出
・上長に通知 → 承認または差し戻し
・経理が科目と金額を確認 → 確定
・月次で振込データを出力

【異常系】
・画像が不鮮明で読み取れない → 手入力に切り替える
・金額が上限を超える → 申請できない旨を表示
・上長が不在 → 代理承認者に回す
・締め日を過ぎた申請 → 翌月扱いにする
“`

正常系も異常系も書きました。レビューも通りました。このとき、要件定義書は分厚い一冊になっていました。

そして、動くものができます。期待どおりに動きました。 領収書を撮ると読み取り、申請が立ち、承認が回り、月次で振込データが出る。

ここまでが、要件定義の教科書どおりの書き方です。業務・機能・非機能に分け、優先順位をつけ、やらないことを書き、承認者を決める。この型どおりに書けば、書類としては通ります。

この記事の後半で扱うのは、その型を守って書いたあとの話です。正常系も異常系も列挙したのに、なぜ数字が合わなくなるのか。列挙という方法そのものが、何を取りこぼすのかを見ていきます。

② 数字が合わない日が来る

稼働から3ヶ月ほど経ったころ、経理から連絡が来ます。

申請したはずの精算が振り込まれていない、という問い合わせが1件あった。

調べます。申請者の画面には、申請が「提出済み」として残っています。 ところが経理側の確定一覧には、その1件がありません。前後の申請は普通に並んでいます。1件だけ、無い。

最初は表示の不具合を疑いました。次に権限、次に検索条件。どれも違いました。

原因はこうでした。その申請は、締め日を過ぎた直後の数分間に作られていました。

→ ① 締め日の締め切り処理が走り、その月の受付は閉じた
→ ② 直後に、申請者が領収書を撮影した
→ ③ AIが読み取り、申請を作成した
→ ④ 申請者の画面には「提出済み」と表示された
→ ⑤ ところが経理側は、閉じた月の申請を集計に含めない。翌月にも繰り越されなかった

申請者から見れば出した。経理から見れば受け取っていない。 どちらの画面も正しく動いています。

要件定義書には「締め日を過ぎた申請は翌月扱いにする」と書いてありました。書いてあったのに、繰り越されなかった。 なぜなら、その処理は「申請が作られたあとに締め日を過ぎた場合」を想定していて、「締め処理が走った直後に、新しい申請が作られる場合」は想定していなかったからです。

③ 抜けていたのは、正常系と異常系の「あいだ」

要件定義書に不備はあります。ただし、雑だったからではありません。

→ 正常系は書かれていました
→ 明示的な異常系も書かれていました（読み取り失敗、上限超過、承認者不在、締め日超過）

抜けていたのは、そのあいだです。

システムとしては受け付けられない状態なのに、人が来てしまう。 このケースが、誰の頭にも浮かんでいませんでした。

そして、いちばん厄介なのはこれがエラーとして飛ばないことです。

→ 例外は出ていない
→ 画面も落ちていない
→ ログにもエラーが無い
→ 申請者の画面には「提出済み」と正しく表示されている

壊れたものを探す仕組みは、全部すり抜けます。 見つかったのは、社員から問い合わせが来たからでした。

問い合わせが来なければ、この不具合は翌月も翌々月も起き続けていたことになります。そして、いくらだったかも分からないままです。

書類の厚さと、この抜けは無関係でした。 「これで網羅した」と言えるだけの厚さがあっても、思いつかなかったケースは、何ページ書いても書かれません。

④ もうひとつ — AIは、書かれていないことをする

同じ時期に、別の問い合わせも来ていました。私的な支出が精算されそうになった、という報告です。

領収書の画像に「〇〇商店」とだけ書かれていて、AIはそれを取引先との会食と読み取り、交際費として申請を作っていました。実際は本人の買い物です。

AIの精度は悪くありません。書かれている情報からは、そう読めます。 問題は、判断がつかないときに「作らない」という選択肢を与えていなかったことでした。

従来のシステムは、書かれていないことをしません。AIは、書かれていないことをします。 役に立とうとするからです。

ここが、AIを挟む要件定義における最大の差分です。

⑤ 直してみる — 列挙する対象を、機能から3つに変える

機能から発想すると抜けます。理由は単純でした。

→ 機能から発想すると、「システムができること」が並びます
→ でも事故が起きるのは、「システムができないのに、人が来たとき」です
→ できないことは機能一覧に載らないので、発想の起点になりません

そこで、列挙する対象を3つに切り替えました。

1. 受け渡し — 誰から誰へ、何を、どれだけ渡すか

業務を「部署の役割」で分けると、絵はきれいになりますが抜けます。事故は役割の中ではなく、役割と役割のあいだで起きるからです。

書くのは組織図ではなく、渡すものの一覧です。AIを挟むなら、AIも「渡す相手」の1つとして同じ表に並べます。

2. 停止点 — どこで人の判断を待つか

そして、その承認は処理を止めて待つのか、先に進めてあとから追認するのか。

「確認ダイアログを出す」は、業務を同期的に止める設計です。毎月まとまった数の申請が流れる現場でこれをやると、承認者が律速になります。金銭が動く、取り消せない、外部に送信される——このどれかに当たるなら止める価値があります。それ以外は、止めなくていい可能性が高い。

3. 受け付けられない状態のときに、人が来るケース

冒頭の事故が、まさにここです。

→ 締め処理の直後に申請が来たら
→ 上限に達した直後に、同時申請があったら
→ 承認者が異動した直後に、その人宛の承認が回ってきたら

このリストは、機能から発想すると出てきません。「無いものを数える」という発想が要ります。

⑥ あとで知った — この抜けには、名前がついていた

素朴な整理のつもりでしたが、調べると同じ分け方をする言葉が、すでにありました。

テストの世界では、カバレッジを4つに分けて呼び分けることがあります。厳密な定義があるわけではなく、緩く使われている言葉です。

→ 正常系（happy path） — 入力が正しく、例外が起きず、期待どおりの結果が出る理想の経路
→ 異常系（sad path） — 認証拒否のような、想定済みの失敗
→ 境界値（edge case） — 入力の端
→ 同時多発（corner case） — 低確率の条件が複数、同時に当たる

冒頭の事故は、4つ目でした。 「締め処理が走った瞬間」と「申請が作られた瞬間」という、それぞれ低確率の事象が同時に当たっている。だから誰も思いつかなかった。

そして、この抜けが生む結果にも名前がありました。サイレント障害（silent failure）です。定義がそのままです。

「正常系からの逸脱が、何のシグナルも出さないとき、それはサイレント障害になる」。

僕が「エラーとして飛ばないから見つからない」と書いていたものは、すでに名前が付いて、対処法まで整理されている現象でした。

その対処法が、3つ目です。突き合わせ（reconciliation）。

会計システムの文脈では、突き合わせが合わないときは記帳を止めて管理者に通知するのが期待される挙動とされています。ログを1行出して先へ進む、ではありません。

もっと分かりやすいのが、件数の突き合わせです。

送り出した件数と、返ってきた件数は一致しなければならない。一致しなければ、差分を必ず表に出す。 この規則が無いと、50件送って48件返ってきたときに、システムは「48件を処理しました」と報告します。「2件が欠けています」とは報告しません。

冒頭の事故と、まったく同じ構造です。 申請者の画面は「提出済み」と報告した。「経理に届いていない」とは報告しなかった。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか

3列を書き出す作業は、すぐ終わりました。機能一覧を作るのに使った時間より、はるかに短い。

そして、書き出した「受け付けられない状態のときに人が来るケース」は、十数件になりました。 そのうち、既存の要件でカバーされていたのは数件だけです。

残りのうち、実際に起こりうると判断したものを絞り込むと、その中に、冒頭の事故と同じものがありました。

つまり、あの事故は、この表を先に書いていれば防げていたことになります。機能一覧を削って、この表を1枚足すほうが、事故は減ります。

⑧ 現場で使うなら、この3列

そのまま埋められる形にします。

表1：受け渡し

渡す側	受け取る側	渡すもの	頻度	そろっていない率（実測して埋める）
申請者	AI読み取り	領収書の画像	申請ごと	読み取れない画像の割合
AI読み取り	申請者	日付・金額・支払先	申請ごと	人が直した項目の割合
申請者	上長	申請	申請ごと	差し戻しの割合
上長	経理	承認済み申請	申請ごと	経理で直した割合
経理	振込処理	確定データ	月1回	振込エラーの割合

「そろっていない率」の列が、いちばん効きます。 ここは推測で埋めず、実際に数えてください。数字が入った瞬間、どこにAIを入れるべきかがほぼ決まります。

表2：停止点

工程	人が判断するか	止め方	理由
AI読み取り後	する	非同期（提案して先へ、あとで修正）	取り消せる
上長承認	する	非同期（一括で確認）	1件ずつ同期で止めると律速
経理確定	する	同期で止める	金銭が動く。取り消せない
振込実行	する	同期で止める	同上

同期で止めるのは、金銭が動く2工程だけ。 残りは「提案して先へ進み、あとから追認」にします。

表3：受け付けられない状態のときに、人が来るケース

状況	人が来ると	いま何が起きるか	どうする
締め処理の直後	申請が作られる	提出済みと表示され、集計に入らない	受付を閉じ、翌月へ回す
上限到達の直後	同時に申請	片方だけ通る	両方止めて通知
承認者の異動直後	承認が回る	宛先不明で滞留	代理へ自動転送
AIが判断できない	そのまま申請	推測で作成される	作らずに人へ回す

4行目が、AIを挟む場合の必須行です。 「判断がつかないときは作らない」を、明示的に書きます。

表4：突き合わせ（無いものを数える）

突き合わせるもの	頻度	拾う条件	一致しないとき
申請者側の提出済み ⇄ 経理側の受領	毎日	片方にしか無い行	止めて通知
承認済み件数 ⇄ 確定件数	毎日	件数の差	止めて通知
確定金額 ⇄ 振込金額	月次	金額の差	止めて通知

「ログを1行出して先へ進む」にしないでください。 止めて、人に通知する。これが、サイレント障害への唯一の対処です。

⑨ この書き方が効き続ける理由

要件定義が重要になった、という言い方はやや不正確です。重要性の中身が入れ替わりました。

実装が高かった時代、要件定義の役割は手戻りを防ぐことでした。作り直しに数ヶ月かかるから、作る前に決め切る価値があった。

実装が数日になった今、手戻りのコストは劇的に下がりました。 だから「決め切る」ことの価値は、実は下がっています。

代わりに上がったのが、漏れを見つけることの価値です。作り直しは安いが、気づかない事故は安くなりません。

そして、抜けやすい場所は毎回同じです。受け渡しと、停止点と、受け付けられない状態に来る人。 この3つだけ、他の10倍の時間をかけてください。

4つ目の表は、そのうえで必ず作ってください。 上の3つは事故を減らしますが、ゼロにはできません。ゼロにできない前提で、気づける仕組みを持つ。 それが、あの分厚い一冊には書かれていなかったものです。

---

ちなみに、経理の月末は目に見えて短くなりました。

浮いた時間で何をしているかというと、振込が終わったあとの突き合わせです。件数と金額を並べて、片方にしか無い行を探す。

自動化した時間を、自動化が壊れていないか確認する時間に使っている。 これでいいのか、いまも少し考えています。

以上です。

要件定義のよくある質問

要件定義と要求定義は何が違いますか？

要求は利用者側が「こうしたい」と言うこと、要件は開発側が「ではこう作る」と引き受けられる形に翻訳したものです。要求のままでは実現方法が決まっていないので見積もれません。要求を要件に翻訳する作業そのものが要件定義です。書く人も違い、要求定義書は発注側、要件定義書は発注側と開発側の合意として作ります。

要件定義書には何を書けばよいですか？

6つです。システム概要（目的・背景・範囲）、用語定義、業務要件（業務フロー・利用者・運用規模・システム構成）、機能要件（画面・権限・帳票・データ・外部インタフェース）、非機能要件（可用性・性能・運用保守・移行性・セキュリティ・システム環境）、体制と役割分担とスケジュールと予算です。範囲の欄には、対象に入れないものを名指しで書いてください。

要件定義の進め方の手順を教えてください。

6ステップです。現状の業務とシステムを把握する、要求を引き出して明確にする、必須・推奨・任意で優先順位を決める、システム全体の構成を決める、業務・機能・非機能に分けて書く、予算とスケジュールを決める。そのあとに承認者を1人決めて確定させ、確定後は変更管理の仕組みで回します。全員一致を確定の条件にすると、いつまでも終わりません。

要件定義書に決まったフォーマットはありますか？

ありません。法律や規格で定められた書式は存在せず、IPAが公開している事例集も業種や規模ごとの分類であって様式の指定ではありません。ExcelでもPowerPointでもWordでも構いません。ただし様式が自由なぶん、項目の抜けは自力で防ぐしかないので、記載6項目を目次にして埋まらない欄を残さないのが最短です。

要件定義書とRFPはどちらを先に作りますか？

RFPが先です。順番はRFI（情報提供依頼）で候補を集め、RFP（提案依頼）で提案と見積もりを受け、発注先を決めてから要件定義書を作ります。RFPは複数のベンダーに向けて「何を実現したいか」を書くもの、要件定義書は決まった1社と「何を作るか」を確定させるものです。要件定義だけを別契約で先に発注する形もあります。

要件定義で最も抜けやすいのはどこですか？

正常系と、明示的な異常系の「あいだ」です。正常系は誰でも書きます。入力エラーや残高不足といった分かりやすい異常系も書かれます。抜けるのは「システムとしては受け付けられない状態なのに、人が来てしまう」ケースです。この領域は例外を投げないことが多く、壊れたものを探す監視では見つかりません。

エラーが出ない不具合は、どう見つけるのですか？

突き合わせ（reconciliation）を設計に含めます。2つの記録の件数や金額が一致するはずの場所を決めて、一致しなければ差分を出す。会計システムでは、突き合わせが合わないときは処理を止めて管理者に通知するのが期待される挙動とされています。ログを1行出して先へ進むのではありません。

AIを組み込むと、要件定義は何が変わりますか？

「やってはいけないこと」を明示する必要が出ます。従来のシステムは書かれていないことをしませんが、AIは書かれていないことをします。役に立とうとして、案内してはいけないものを案内する。だから許可の一覧だけでなく、禁止の一覧と、それが破られたときの検知方法を同時に設計してください。

AIで実装が速くなると、要件定義の重みは上がりますか？

上がります。ただし時間をかければ品質が上がるわけではありません。作り直しのコストが下がったので「決め切る」ことの価値はむしろ下がり、代わりに「漏れを見つける」ことの価値が上がりました。網羅性のために時間を使うのではなく、抜けやすい場所を先に知って、そこだけ深く掘るのが効きます。