要件定義書の書き方|項目・目次と、伝わる書き方のコツ

要件定義書の書き方を、目次と項目、伝わる書き方のコツに分けて解説する記事のアイキャッチ。机の書類とノートPC

当サイトの記事は編集部が国土交通省・IPA・デジタル庁などの公的機関の情報、規格や業界団体の公開情報を調べて独自に執筆しています。記事内にIT・Webエンジニアの転職サービスへの案内(広告)を含みます。

上司から『要件定義書を書いておいて』と言われたものの、何から書けばいいのか分からない。そんな状況で、この記事にたどり着いた方も多いはずです。

結論から言うと、要件定義書の書き方は先に目次を決めて、章ごとに「誰に聞いて何を書くか」を埋めていくのがいちばんの近道です。目次は「背景と目的」「業務の流れ」「機能」「非機能」「移行・運用」の5章で考えると迷いません。

この記事を読めば、目次と項目の組み立て方から、伝わる文の書き方までが分かります。

目次

要件定義書の書き方は「目次」から始める

先に結論

要件定義書は、いきなり本文を書き始めると途中で迷子になります。まず目次を作り、章ごとに書く項目と、聞きに行く相手を決めてから書き始めましょう。

要件定義書は、作るシステムの中身を決めて、発注側と開発側が合意するための文書です。デジタル庁の用語集では、要件定義を「必要な要件を明確に定める行為又はその定めた内容のこと」としています。

『いきなり白紙から書くのは無理…』と感じますよね。でも、目次という地図があれば、どこから手をつけてもかまいません。

書き始め方起きやすいこと
思いついた順に本文を書く項目の抜けに気づかない。同じ話が何度も出てくる
目次を先に決めてから書く空いている章が抜けとして見える。担当を割り振れる

要件定義書そのものの意味や役目は、要件定義書とは?目的・書く内容・作る流れをやさしく解説で紹介しています。

公的な手引きでの要件定義書の構成

国の情報システム向けのデジタル庁のガイドライン(DS-100)では、要件定義書に書く内容を原則として次の4つとしています。

DS-100の要件定義書の内容中身
ア 業務要件の定義業務の目的、目標、業務の流れなど
イ 機能要件の定義機能、画面、帳票、データ、外部インタフェース
ウ 非機能要件の定義性能、信頼性、情報セキュリティ、移行、運用、保守など
エ システム方式の決定システムをどんな方式で作るか

民間の要件定義書でも、この並びは参考になります。この記事ではこれを下敷きに、もう少し書きやすい5章に組み直してみますね。

要件定義書の目次は5章で考える

ここが大事

要件定義書の目次は「背景と目的」「業務の流れ」「機能」「非機能」「移行・運用」の5章にすると、書く順番と聞く相手が自然に決まります。

編集部では、要件定義書の構成を5つの章に分けた「書き方の地図」を作ってみました。章ごとに、書く項目と、主に聞きに行く相手を並べています。

章書く項目の例主に聞く相手DS-100でいうと
1. 背景と目的システム化の背景、目的、対象範囲、やらないこと発注側の責任者業務要件
2. 業務の流れ今の業務と困りごと、システム化後の業務の流れ現場の担当者業務要件
3. 機能機能一覧、画面、帳票、データ、他システムとの連携現場の担当者と開発側機能要件
4. 非機能性能、止めてはいけない時間、セキュリティ発注側と開発側非機能要件
5. 移行・運用データ移行、切り替えの時期、教育、運用と保守の体制情報システム担当と現場非機能要件(移行・運用など)
要件定義書の目次を背景と目的・業務の流れ・機能・非機能・移行運用の5章に分けた書き方の地図の図解

5章の順番で書くと話がつながる

5章の順番には意味があります。目的が決まらないと業務の流れが決まらず、業務の流れが決まらないと機能が決まらないからです。

例えば「受付の手間を減らしたい」という目的が1章にあれば、2章では受付の流れを、3章では受付の画面を書く、とつながっていきます。読む人も、どの機能が何のためにあるのかを追いかけやすくなるんです。

要件定義書の表紙と項目一覧

先に結論

表紙には文書名、版、日付、作った人と承認した人を入れます。本文の前に改版履歴、用語集、未確定事項の一覧を置いておくと、後で読む人が迷いません。

『表紙なんて、タイトルだけでいいのでは?』と思いますよね。ただ、要件定義書は何度も直される文書なので、どの版をいつ誰が承認したかが分かることがとても大事なんです。

置く場所入れる項目書く理由
表紙文書名、システム名、版、日付、作成者、承認者どの版が正式か分かるように
改版履歴版、日付、直した所、直した理由何が変わったかを追えるように
用語集社内の言い方、略語、専門用語読む人によって意味がずれないように
未確定事項の一覧決まっていない事、決める人、決める時期決め残しを忘れないように

未確定事項は隠さずに書く

DS-100では、未確定な要件はリスク要因になりうることに注意し、その旨を要件定義書で明らかにするとしています。決まっていない事を書かずにおくと、後で「決まっていると思っていた」という食い違いが起きます。

補足

未確定事項は「何が」「いつまでに」「誰が決めるか」の3点で書いておきましょう。決まった時は、未確定事項の一覧から消して本文に移し、改版履歴に残します。

英語では、要求を書いた文書を requirements specification と呼ぶことがあります。規格では JIS X 0166:2021 が要求エンジニアリングを扱っていて、くわしく学びたい人の手がかりになります。

章ごとの書き方のコツ

先に結論

章ごとに、書く粒度が違います。背景と目的は短く言い切り、業務の流れは図で、機能は一覧表で、非機能と移行・運用は確かめられる言葉で書くのがコツです。

ここからは、5章それぞれの書き方を見ていきますね。

1章 背景と目的:一文で言い切る

目的は、長い説明より一文の言い切りのほうが伝わります。「受付から請求までの入力を一度で済ませ、二重入力をなくす」のように、何がどう変わるかを書きましょう。

あわせて「今回はやらないこと」も書いておくのがおすすめです。範囲の外を書いておくと、後から機能が増え続けるのを防げます。

2章 業務の流れ:今と後を並べる

業務の流れは、今のやり方と、システムを入れた後のやり方を並べて書きます。文章だけだと分かりにくいので、業務フロー図を添えるとぐっと伝わりやすくなります。

困りごとは、現場の言葉のまま書き残しておきましょう。「月末に同じ数字を何度も打ち直している」のような生の声が、機能を決める時の根拠になるんです。

3章 機能要件の書き方:一覧表にする

要件定義書の機能要件は、一覧表にまとめるのが基本です。1行に1つの機能を書き、誰が使うか、何をするか、どれくらい大事かを並べます。

機能番号機能名使う人できること優先度
F-01受付登録受付担当申し込み内容を入力して登録する必須
F-02受付一覧受付担当・所属長登録した受付を日付や状態で絞り込んで見る必須
F-03請求書出力経理担当受付の内容から請求書を作って印刷する必須
F-04集計表所属長月ごとの受付件数を表で見るあればうれしい

この表は編集部が作った架空の例です。機能番号を振っておくと、画面や帳票、テストの項目から「どの機能の話か」を指せるようになりますよ。

画面・帳票・データ・連携も3章に入れる

DS-100では、機能要件として機能のほかに、画面、帳票、データ、外部インタフェースに関する事項を挙げています。機能一覧だけで終わらせず、この4つも3章の中に書いておきましょう。

項目要件定義書で書くことの例
画面画面の一覧と、それぞれの画面で誰が何をするか
帳票出力する書類の一覧と、いつ誰が使うか
データ扱う情報の種類と、どこからどこへ渡るか
外部インタフェース連携する他のシステムと、やり取りする情報

画面のくわしい見た目や項目の並びは、次の設計の段階で決めます。要件定義書では「何の画面が要るか」までを書けば十分です。

4章 非機能:確かめられる言葉で書く

非機能の章は、「速い」「安全」のような言葉で書くと、後で合格かどうかを決められません。「朝の混む時間帯でも画面がすぐ出る」のように、場面と合格の線を書いておきましょう。

非機能要件の項目と決め方は、非機能要件とは?要件定義書に書く項目と決め方でくわしく紹介しています。

5章 移行・運用:切り替えの日から逆算する

移行の章では、今のデータをどこまで移すか、いつ切り替えるかを書きます。運用の章では、毎日の確認や困った時の連絡先を誰が受け持つかを決めます。

ここは後回しにされやすい章です。でも、切り替えの日に困らないためにも、要件定義の段階で書いておくのが安心です。

誰が読んでも同じに伝わる書き方のコツ

先に結論

要件定義書は、書いた人がいない時に読まれる文書です。主語をはっきりさせ、一文に一つのことを書き、あいまいな言葉を確かめられる言葉に直しましょう。

IPAの「超上流から攻めるIT化の原理原則17ヶ条」には、「要件定義書はバイブルであり,事あらばここへ立ち返るもの」という条があります。何かあった時に立ち返る文書だからこそ、読む人によって意味が変わらない書き方が大事なんです。

書いた後のチェック
  • 一文に一つのことだけを書いている
  • 「システムが」「担当者が」など主語がはっきりしている
  • 「など」「適宜」「なるべく」で終わる文が残っていない
  • 同じものを同じ言葉で呼んでいる
  • 決まっていない事は未確定事項の一覧に移している

例えば、読み合わせの場でこんなやり取りがあったとします。

「この『関係者に通知』の関係者って、誰のことですか?」
「あ、所属長と経理の担当です。書き足しておきますね」

こうした質問が出た所は、ほかの人も同じ所でつまずきます。その場で直して、改版履歴に残しておきましょう。

あいまいな書き方と、伝わる書き方

よくある書き方を、伝わる形に直してみました。

あいまいな書き方伝わる書き方の例
必要に応じて通知する受付が登録された時、所属長にメールで通知する
検索機能などを設ける受付一覧を、日付と状態と担当者で絞り込めるようにする
なるべく早く表示する受付一覧は、朝の混む時間帯でも待たずに表示する
適宜バックアップを取る毎日の業務終了後に、データの控えを別の場所に取る

『細かく書きすぎると、かえって読みにくくなるのでは?』と思う方もいますよね。迷ったら「この文を読んだテストの担当者が、合格か不合格かを決められるか」で考えてみてください。

よくある失敗

社内でしか通じない言い方を、そのまま書いてしまうことがあります。「例の帳票」「いつもの締め処理」では、開発会社の人には伝わりません。初めて出てくる言葉は、用語集に意味を書いておきましょう。

要件定義書の作り方・作成方法の手順

先に結論

要件定義書の作成は、目次を作る、聞き取る、たたき台を書く、読み合わせる、承認する、の順に進めます。一度で完成させようとせず、版を重ねて仕上げていきます。

要件定義書の作り方を、最初から承認までの流れで並べてみました。

要件定義書の作成方法
  1. 5章の目次を作り、章ごとに聞く相手を決める
  2. 責任者に目的と範囲を、現場に業務の流れと困りごとを聞く
  3. 聞いた内容から、たたき台を書く
  4. 発注側と開発側で読み合わせ、ずれや抜けを直す
  5. 未確定事項を一覧にして、決める人と時期を決める
  6. 発注側の責任者が読んで承認し、版を確定させる
要件定義書を目次作りから聞き取り、たたき台、読み合わせ、承認まで進める作成の流れの図解

IPAの17ヶ条には「要件定義は発注者の責任である」という条もあります。開発側がたたき台を書く場合でも、最後に承認するのは発注側だと覚えておきましょう。

要件定義書の作成ツールの選び方

要件定義書の作成ツールは、特別なものでなくてもかまいません。多くの職場では、Word、Excel、プレゼン資料用のソフトを使い分けています。

ツールの種類向いている所気をつけたい所
Word などの文書ソフト文章の多い章、表紙、改版履歴表が大きいと見にくい
Excel などの表計算ソフト機能一覧、項目一覧、未確定事項の一覧長い文章が読みにくい
プレゼン資料用のソフト業務の流れの図、説明会での共有細かい条件を書き込みにくい
Markdown と文書共有の仕組み版の管理、複数人での同時編集書き方に慣れが必要

どれを使うかより、社内で決まった書式があるかを先に確かめるのが大事です。ひな形の探し方は要件定義書のサンプル・テンプレート|公開されている見本の使い方で紹介しています。

要件定義書の書き方でよくある相談

先に結論

よくある相談は「要件定義書と要求定義書は同じか」「サーバー構築の要件定義書の書き方」「設計の途中で項目を足したいと言われた」などです。どれも、要件定義書に何を書くかが分かれば答えが見えてきます。

よく寄せられる相談を、内容をまとめた形で紹介しますね。

相談1:要件定義書と要求定義書は同じもの?

要件定義書と要求定義書は同じものなのか、別のものなのか、という相談です。閲覧数がとても多く、迷う人が多いことが分かります。

IPAのDX SQUAREの解説では、「要求」と「要件」の標準的な定義はないとしたうえで、要求を文書にしてステークホルダーと合意したものが要件、という趣旨の説明をしています。つまり、希望を集めた段階が要求、合意して決めた段階が要件と考えると分かりやすいです。

会社によって呼び方が違うこともあるので、社内でどちらの名前を使っているかを確かめておきましょう。違いは要求仕様書とは?要件定義書との違いと書く項目でも紹介しています。

相談2:サーバーやネットワーク構築の要件定義書はどう書く?

サーバーやネットワークを作る時の要件定義書の書き方が分からない、という相談も多く読まれています。

基盤の要件定義書も、5章の地図はそのまま使えます。ただ、画面や帳票の話が少なく、4章の非機能と5章の移行・運用が中心になります。

厚生労働省の職業情報提供サイト(job tag)では、ITインフラを設計する仕事の設計書の主な内容として、機能、構成、性能、信頼性、予算、開発工程が挙げられています。要件定義書でも、このあたりを決めておくと設計に進みやすくなりますよ。

相談3:詳細設計の途中で「この項目を入れたい」と言われた

要件定義が終わって詳細設計をしている最中に、要件にない項目を足してほしいと言われた、という相談です。

こういう時は、まず要件定義書に戻って、書かれている範囲かどうかを確かめます。範囲の外なら、追加として扱い、改版履歴に残してから進めましょう。

17ヶ条には「機能要求は膨張する。コスト,納期が抑制する」という条もあります。「入れるなら、時期や費用がこう変わります」と添えて、発注側に決めてもらうのがスムーズです。

相談4:要件定義プロセスとシステム要件定義は何が違う?

要件定義プロセスとシステム要件定義の違いを分かりやすく知りたい、という相談もあります。

IPAの共通フレーム2013では、「2.2 要件定義プロセス」と、システム開発プロセスの中の「2.3.2 システム要件定義プロセス」が別々に並んでいます。名前は似ていますが、置かれている段階が違うんです。

前者は業務の側から何が必要かを決める段階、後者はそれを受けてシステムとしての要件にする段階、と考えると流れがつかみやすいですよ。

要件定義書を書ける人になりたい方へ

先に結論

要件定義書を書く力は、上流工程の仕事でいちばん求められる力の一つです。今の仕事で書く機会があるなら、それ自体が大きな経験になります。

要件定義書を書くには、業務を聞き出す力、文章にまとめる力、開発の流れを知っていることの3つが要ります。どれも、書いて直してを繰り返すうちに身についていくものです。

上流工程にどう進んでいくかは、上流工程とは?要件定義・設計ができるエンジニアになる道筋で紹介しています。

要件定義や設計書を書く経験は、上流工程を任される職場で評価されやすいものです。今の職場で経験を積むのも大切な道ですし、担当工程から一歩進みたい人は、求人の仕事内容を比べてみると道が見えてきます。

IT・Webエンジニアの転職(PR)

仕様書を書く経験を活かせる職場を探すなら、求人も比べてみる

要件定義や設計を任されるか、発注側か開発側か、扱うシステムや働き方は会社によって大きく違います。担当したい工程や条件から、IT・Webエンジニアの求人を比べてみてください。

無料ITエンジニアの求人を探す

求人の条件・待遇は各求人票と応募先の案内でご確認ください。

よくある質問

要件定義書の項目には何がありますか?

背景と目的、業務の流れ、機能要件、非機能要件、移行・運用の5章で考えると抜けが出にくくなります。表紙、改版履歴、用語集、未確定事項の一覧も入れておきましょう。

要件定義書の機能要件はどう書けばいいですか?

1行に1つの機能を書く一覧表にして、機能番号、機能名、使う人、できること、優先度を並べるのが基本です。画面や帳票、データ、他のシステムとの連携も機能要件の章に書きます。

要件定義書の表紙には何を書きますか?

文書名、システム名、版、日付、作成者、承認者を書きます。どの版が正式なのかが分かるようにしておくのが目的です。

要件定義書は何で作るのがいいですか?

文章の多い章は文書ソフト、一覧の多い章は表計算ソフトが向いています。社内に決まった書式があれば、まずそれに合わせましょう。

初めてでも要件定義書を書けますか?

書けます。目次を先に決めて、章ごとに聞く相手を決めれば進めやすくなります。たたき台を早めに見せて、直しながら仕上げていきましょう。

まとめ

この記事の要点
  • 要件定義書は目次を先に決めてから書く
  • 目次は背景と目的・業務の流れ・機能・非機能・移行運用の5章で考える
  • 表紙と改版履歴、用語集、未確定事項の一覧を入れる
  • 機能要件は一覧表、非機能は確かめられる言葉で書く
  • 一文一事、主語をはっきり、あいまいな言葉を残さない
仕様書ドットコム

仕様書ドットコム 編集部

仕様書の意味・種類・書き方から、システム開発の要件定義書・設計書・テスト仕様書、公共工事の標準仕様書・共通仕様書、住宅や発注の仕様書、仕様書を書く仕事のキャリアまでを、初めて仕様書に向き合う人が自分で判断できるように整理している情報サイトです。 公式サイト

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

コメント

コメントする

目次