要件定義書の書き方【発注者向け】自社で書く項目・開発会社に任せる項目と、確定までの進め方

「要件定義書をまとめてください」と言われたら

社内システムの刷新や新しい業務システムの担当に指名されると、開発会社から「要件定義書をまとめてください」「要件を出してください」と頼まれることがあります。何をどの形で書けばよいのか、そもそも発注側が書くものなのか、と迷って検索した方も多いはずです。

本記事は、要件定義書の書き方を発注者の立場から整理したものです。想定している読者は、発注側で要件定義を任された業務部門・情報システム部門の担当者と、その相談を受ける社内外の技術者です。受注側のエンジニアが文書を書くときの作法 (表記のルールや図の描き方) は扱いません。

先に結論を書きます。要件定義書を書く作業は開発会社の支援を受けてかまいませんが、内容を確定する権限と責任は発注側にあります。発注側が自分で書くのは、目的と判定基準、いまの業務の流れ、対象にする範囲としない範囲、使う人・規模・止まってよい時間などの水準、誰が決めるかの 5 つです。専門用語は要りません。

根拠には、IPA (情報処理推進機構) の ユーザのための要件定義ガイド 第 2 版 (2019 年発行。以下、IPA ガイド)、IPA と経済産業省の 情報システム・モデル取引・契約書 第二版 (以下、モデル契約)、経済産業省の DX レポート (2018 年) を使います。要件定義の費用は本記事では扱いません。発注体制のどこで失敗の兆しが出るかは、システム導入が失敗する 12 の兆候 で先に確かめられます。

要件定義書は誰が書くのか — 書く作業と確定する責任は別

「要件定義書は誰が作るのか」という問いには、書く作業と確定する責任を分けて答えます。

IPA ガイドの紹介ページは、「システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにあると言われています」と書いています。そのうえで、IT ベンダやシステム部門が中心になって進めるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革が必要だとしています。

モデル契約の条文も同じ考え方です。第 14 条は、開発会社 (条文では乙) が「甲による要件定義書の作成作業を支援する」と定めています。甲は発注側です。開発会社は専門知識をもとに調査・分析・整理・提案・助言を行いますが、要件定義書を作る主体は発注側という建て付けです。さらに第 9 条は、発注側の責任者が要件定義書の確定を行う権限と責任を持つとしています。

実際には、ヒアリングをもとに開発会社が文書の大半を書くことが多く、それ自体は問題ありません。問題になるのは、書いてもらった文書を読まずに確定させることです。確定した要件定義書は、その後の設計・開発・受入テストの基準になります。

FIXIT

えっ、要件定義書って開発会社が書いてくれるものじゃないの？

Kaname

書く作業は手伝ってもらえます。ただ、中身を決めて確定させるのは発注側です。

FIXIT

専門用語なんて書けないけど、それでも大丈夫なの？

Kaname

大丈夫です。現場では、業務の言葉で書いてもらうほうが話が早く進みます。

RFP・要件定義書・設計書の違い

似た名前の文書と混同しやすいので、先に違いを整理します。

RFP を先に書いた場合も、要件定義書は RFP より細かい粒度で作ります。逆の順番もあり、モデル契約は、要件定義の作成支援を準委任で受けて要件定義書を作り、それをもとに開発会社へ RFP を出して見積もりを受ける流れを示しています。RFP の書き方は AI 開発の RFP の書き方 で扱っています。

要件定義書の目次と、発注側・開発会社の分担

IPA ガイドは、要件定義で作るドキュメントを 13 の分類に整理しています (表 3.2)。ビジネスコンセプト、ステークホルダ (関係者)、要求分析、業務の流れ (ビジネスプロセス)、画面・帳票・外部インターフェースなどの各種一覧、データ定義、非機能要求、運用・移行・総合テストなどです。

中小〜中堅規模の案件で、すべてを別々の文書にそろえる必要はありません。発注者の言葉に言い換えて 7 つの章にまとめると、次の目次になります。分担は「自社で書く」「一緒に書く」「開発会社に任せる」の 3 つに分けました。

分担の考え方は単純です。業務とビジネスの事情は発注側にしか書けず、技術的な表し方は開発会社のほうが速く正確に書けます。「一緒に書く」は、発注側が業務の言葉で出し、開発会社が文書の形に整え、発注側が読んで直す往復を指します。

「開発会社に任せる」とした章も、読まずに承認してよいわけではありません。データの章なら、帳票に載せたい項目が抜けていないかを見ます。移行の章なら、旧システムを止めて切り替える時期が、業務の繁忙期と重なっていないかを確かめます。

発注側が自分で書く 5 項目と書き方の例

自社で書く部分の価値は、文章の上手さではなく、開発会社が知らない事情が書かれているかで決まります。以下の記入例は、受注管理を表計算ソフトで行っている卸売業の会社を想定した架空の例です。

目的と、達成したかを判定する基準

IPA ガイドは経営層に向けて、「数値レベルの具体的な目標あるいは、達成状況が確認できるレベルの目標設定が必要」と書いています。「業務を効率化する」だけでは、できあがったシステムが目的を果たしたかを判定できません。

目的
  受注から出荷指示までの手作業を減らし、月末の締めにかかる残業をなくす
判定基準
  - 受注 1 件あたりの入力時間を、いまの約 10 分から 3 分以内にする
  - 月末の締め作業を 2 日から半日にする
  - 出荷指示の転記ミスによる誤出荷を 0 件にする

いまの数値が分からなければ、1〜2 週間だけ計ってから書いても間に合います。判定基準があると、要件定義の途中で機能を足すか迷ったときに、どの基準のための機能かで判断できます。

いまの業務の流れ (As-Is) と困っていること

誰が、何を受け取って、何をして、誰に渡すかを、業務の言葉で順番に書きます。図にできなくても、番号付きの箇条書きで十分です。

1. 営業が電話・FAX・メールで注文を受ける
2. 営業事務が表計算ソフトの受注台帳に転記する (1 日 40〜60 件)
3. 在庫を倉庫に電話で確認する
4. 出荷指示書を印刷して倉庫に FAX する
5. 月末に経理が受注台帳と出荷記録を突き合わせる
困っていること
  - 同じ注文を 2 回転記している
  - 月末は 2 人が残業して照合している

返品、締めたあとの訂正、月末だけ発生する処理のような例外の業務も書き足します。ふだんの流れだけを書くと、例外の業務が要件から抜け、稼働後に手作業で埋めることになります。業務フロー図と画面リストの作り方は、見積もり完全ガイドの 用意すると精度が上がる 3 つの資料 にまとめています。

対象にする範囲と、対象にしない範囲

対象外の範囲は、書いておかないと食い違いが起きる項目です。書かれていないことを、発注側は「当然入っている」と考え、開発会社は「入っていない」と考えがちです。

対象
  受注登録、在庫の引き当て、出荷指示、月次の売上集計
対象外
  - 会計システムへの仕訳の入力 (今回は CSV の出力まで)
  - 請求書の発行
  - スマートフォンからの利用

対象外にした理由も 1 行添えておくと、次の段階で追加するときの判断材料になります。

使う人・規模・止まってよい時間などの水準

非機能要件と呼ばれる部分です。発注側は稼働率のような専門用語や数値の指標を使わず、業務の事情として書けば足ります。

使う人      営業事務 6 人、倉庫 3 人、経理 2 人。同時に使うのは最大 8 人程度
量          受注は 1 日 40〜60 件、繁忙期の 12 月は 2 倍
使う時間    平日 8 時〜20 時。夜間と休日は使わない
止まったとき 半日までなら電話と紙でしのげる。月末の 3 日間は止まると困る
データ      受注の記録は 7 年残す
場所        社内と倉庫から使う。社外からは使わない

これを数値の水準 (稼働率、応答時間、バックアップの頻度など) に落とし込むのは、開発会社と一緒に行います。水準を決めるための問いと、発注前に埋めるチェックリストは、見積もり完全ガイドの 非機能要件の章 を参照してください。

誰が決めるか (決裁者・業務部門の責任者)

要件をめぐって社内の意見が割れたときに、誰が決めるかを先に書いておきます。ここが空いていると、要件定義の打ち合わせが「持ち帰って検討します」の繰り返しになりがちです。

最終決裁          営業本部長
業務の要件を決める人 受注課長 (受注・出荷)、経理課長 (集計・CSV の出力)
窓口と進行        情報システム担当
意見が割れたとき  受注課長と経理課長で協議し、決まらなければ営業本部長が決める

モデル契約が要件定義書を確定する権限と責任を与えているのも、発注側の「責任者」です (第 9 条 3 項)。誰が責任者として最後に押印するのかを、この時点で決めておきます。

要件定義の進め方 — 誰がいつ関わるか

本記事では、要件定義に入る前の構想の確認から確定までを、次の 7 つの段階に分けます。開発会社が要件定義書の初版を書くのは 5 段階目からで、その前の 4 つは発注側が主に動く段階です。

1 段階目について、IPA ガイドは「良き構想なくして良き要件定義はない」という見出しを立て、要件定義が始まる前に構想を確かめ、不備があれば整える時間を設けるべきだとしています。目的が決まらないまま 3 段階目以降に進むと、何を優先するかの判断材料がありません。

6 段階目の試作も、IPA ガイドが示す要件定義の手順に含まれています。システムの機能について、画面・帳票のレイアウトによるプロトタイプ (試作) の確認もあわせて行う、と書いています。文書だけを読んで判断するより、画面を見たほうが業務部門は過不足に気づきやすくなります。

打ち合わせの決定事項は、必ず議事録に残します。モデル契約の第 16 条は、発注側が要件定義検討会を開き、開発会社がそこに参加する形を定めています。そして第 17 条の点検は、要件定義書が「要件定義検討会での決定事項」に適合するかを確かめる手続きです。議事録が、確定のときの照合の基準になります。

経営層・業務部門・情シスの役割

IPA ガイドは、関係者ごとに意識すべきことを分けて書いています (2.1 節)。要約すると次のとおりです。

• 経営層は、システムで何を目標にするかを示し、要件定義に参画します。ガイドは「経営層の参画とリーダーシップが成功のカギを握っている」と書いています。ただし社長や担当役員に限らず、場合によっては、経営者の意を汲んだ企画担当のスタッフが代わりに参画してもよいとしています
• 業務部門は、どのようなシステムを作り、そこからどのような効果を引き出すかに責任を持ちます。ガイドは要求仕様の提示責任とシステムの検証責任を挙げる一方、「当然、すべての要件定義が業務部門でできるわけではない」とも書いています
• 情報システム部門は、業務部門を引っ張る役です。ガイドは「要件定義は、業務部門（オーナー部門）責任が基本だが、システム部門が触媒となり業務部門を引っ張って」いく姿を理想としています。要件定義に協力する開発会社を適切に選ぶ責任も、発注側にあるとしています

情報システム担当が 1 人だけの会社や、担当者がいない会社では、窓口と進行を誰が担うかを 2 段階目で決めます。社外の技術者に相談に乗ってもらう場合も、決める人は社内に置きます。

開発会社が書いた要件定義書を確定する前に確かめること

開発会社から要件定義書の案が届いたら、次の観点で点検します。全部の章を同じ深さで読む必要はありません。発注側にしか判断できないところから読みます。

受入テストの観点は、納品のときに発注側と開発会社の解釈が分かれやすい項目です。要件定義書の書き方が曖昧だと、合格か不合格かを決められません。受入テストで発注側が何をするかは、受入テストは誰がやるか で扱っています。

FIXIT

分厚い要件定義書が届いたら、全部読まないとハンコを押せないの？

Kaname

全部を同じ深さで読む必要はありません。目的、対象外、未確定事項の 3 か所から読みます。

FIXIT

じゃあ、読んでも分からない技術の章はどうするの？

Kaname

業務の言葉で説明してもらう時間を、点検期間の中に取っておきます。

点検期間と記名押印 — モデル契約第 17 条の手続き

モデル契約の第 17 条は、要件定義書の確定を次の手続きで定めています。

1. 発注側が要件定義書の作成を完了したら、個別契約で定めた点検期間のうちに、要件定義検討会での決定事項に適合するかを、発注側と開発会社が点検する
2. 適合することを確認した証として、双方の責任者が要件定義書に記名押印する。この確認をもって要件定義書は確定する
3. 適合しないと判断された場合は、双方で協議して定めた期限までに発注側が修正版を作り、もう一度点検する
4. 修正に伴って作業期間や委託料を変える必要が出た場合は、契約の変更の手続き (第 33 条) による

実務で押さえるのは 2 点です。1 つは、点検期間の長さを契約の時点で決めておくことです。業務部門の担当者が通常業務と兼務しているなら、読む時間と、開発会社に説明してもらう時間の両方を見込みます。もう 1 つは、押印の意味を社内で共有しておくことです。確定した要件定義書は、その後の設計と開発の前提になります。あとから内容を変えるには変更の手続きを経ることになり、費用や納期の見直しにつながることがあります。

丸投げにしないための線引きと契約形態

要件定義の丸投げについては、経済産業省の DX レポートが「2.4 ユーザ企業とベンダー企業との関係」で、次のように指摘しています。

我が国においては、要件定義から請負契約を締結するケースも少なくない。これは、何を開発するかをベンダー企業に決めてくれと言っていることと同じである。ベンダー企業もそのまま要望を受け入れてしまっている。

同じ節は「要件の詳細はベンダー企業と組んで一緒に作っていくとしても、要件を確定するのはユーザ企業であるべきことを認識する必要がある」と続けます。レポートの参考資料として載っている「DX 推進システムガイドライン」の構成案でも、失敗ケースとして「要件定義を請負契約にすると、ベンダー企業に丸投げとなってしまう（ベンダー企業も要件定義を請負契約で受けることは慎み、準委任契約とすべき）」を挙げています。

モデル契約の解説も、請負型をとると「ユーザ側の心理として『丸投げ』『ベンダにすべてお任せ』という意識が強くなる場合があることが指摘された」と書いています。準委任型にしなかった場合、発注側が自社内の関係者と調整する責任があいまいになりやすい。その結果、発注側の対応不足を補うために開発会社が社内の関係者へ直接連絡を取り始め、発注側の調整が働かないまま要件の見落としも生じやすくなる、という指摘です。

任せてよいのは作業で、手放さないのは決定です。分けると次のようになります。

契約形態は、準委任が基本です。モデル契約は、超上流工程 (構想や要件定義など、設計に入る前の工程) の重要性を明らかにするために「要件定義」を独立した段階とし、契約類型を準委任型としました。要件定義の作成は発注側自らの責任で行い、開発会社は準委任で支援する、という考え方です。準委任では、報酬を工数の実績に基づいて算出する方法がとられることが多い、とも書いています。

準委任だからといって、開発会社が責任を一切負わないわけではありません。モデル契約の解説は、開発会社が受任者として善管注意義務 (専門家として求められる注意を払う義務) を負い、支援が適切でなければ債務不履行の責任を負うとしています。

要件定義の費用の目安と、要件定義を準委任で切り出す理由は、見積もり完全ガイドの 要件定義の費用の章 で扱っています。準委任と請負の選び方は AI 開発の契約は準委任と請負どちらが正解か、AI 駆動開発の案件で丸投げが起こす問題は AI 駆動開発で失敗しない進め方 を参照してください。

AI 駆動開発で、要件定義の進め方はどう変わるか

AI を開発に組み込むと、要件定義の段階でも作業の速さが変わります。ただし、変わらない部分もはっきりしています。

試作を早く見られるのは、IPA ガイドが要件定義の手順に含めているプロトタイプの確認と同じ方向の変化です。発注側は、文書を読んで想像するのではなく、画面を触って「この項目は要らない」「この順番では入力しにくい」と判断できます。

一方で、AI が整えた文書は、自社の事情を知らないまま書かれていても、もっともらしく読めます。読みやすさを内容の正しさと取り違えないようにしてください。また、たたき台と試作が早く出るぶん、発注側の判断が遅いと、プロジェクトの待ち時間の大半が発注側の判断待ちになります。2 段階目の体制づくりで、決める人と打ち合わせの頻度を決めておくことが、AI を使う案件ではいっそう大事になります。

AI 駆動開発の工程全体と、要件定義・仕様策定で開発側が何をするかは、AI 駆動開発の進め方 で扱っています。

FIXIT の進め方 — 要件を確定するのは発注側、材料を早く出すのが私たち

FIXIT は AI 駆動開発のクリエイティブスタジオとして、AI 駆動開発 の最初にディスカバリーの段階を置いています。1〜2 回のワークショップで、ビジネスの背景、期待する投資対効果、関係者の構造を把握し、AI で短縮できる工程を特定します。続く設計の段階では、ドメインモデルの草案と、受入テストの骨格を作ります。

SaaS MVP 開発 では、主要な機能が決まっている場合、最初の要件すり合わせに約 3〜4 日を見込んでいます (要件が固まっていない場合は、その前に 1 週間のディスカバリーを置きます)。ユーザーストーリーの粒度を AI でそろえ、画面遷移図とデータモデルを作り、仕様のレビューまでを行います。

発注側には、ディスカバリーで把握した背景や、ドメインモデルの草案、受入テストの骨格、画面遷移図とデータモデルを見ながら、本記事の 5 項目 (目的と判定基準、いまの業務の流れ、対象外の範囲、水準、誰が決めるか) を判断していただくことになります。要件を確定するのは発注側で、私たちはそのための材料を早く出す役割を担います。契約は、要件が固まりきらない探索の段階は準委任、成果物が明確な段階は請負と、局面で使い分けるのを標準にしています。

まとめ

発注側の役割は 3 つに絞れます。目的と対象外を自分で書くこと、試作を見て決めること、点検してから確定させることです。書く作業は開発会社の支援を受けてかまいませんが、決定と確定は手放さないでください。

次の一歩は 1 つです。目的と判定基準、対象にしない範囲、決める人の名前を、社内で A4 1 枚に書いてみてください。開発会社との最初の打ち合わせにこの 1 枚を持っていけば、要件定義書の概要の章と、対象外の範囲がほぼ埋まった状態から始められます。

AI 駆動開発で要件定義から開発までをどう進めるかを相談したい場合は、お問い合わせ からご連絡ください。発注先を選ぶ段階なら、先に RFP の書き方 で依頼の条件を整理しておくと、相談が具体的になります。