要件定義書の書き方＆テンプレート/サンプル７選|すぐに使えて便利

と言った疑問・要望に答えます。

本記事で、「システム要件定義書」ってどう準備して進めれば良いか理解出来きます。そもそも「要件定義」自体が不明と言う方は、初めに「システム開発の「要件定義」とは？意味・目的・進め方を事業会社目線で解説」の記事をご参照ください。

本記事では以下の構成で解説していきます。

本記事は、以下の社内SE基礎講座の「システム要件定義のテンプレート」の記事です。

IT初心者・社内SE向け｜システム開発の【基礎講座】関連記事一覧

要件定義書とは？

要件定義書とは何か？この答えは、誰目線で【要件定義書】を捉えるかでニュアンスが異なります。

この３つの視点で解説します。

事業会社の事業部や業務部門にとっての要件定義書とは？

要件定義書は、プロジェクトで達成する目的を達成するために必要な要件を記述し次の工程に進むための文章・ツールです。この要件定義書には、システムで実装する部分のみならず、システム外で実装する要件も含みます。

要件定義書＝ not only システム開発の要件定義書です。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

社内SEにとっての要件定義書とは？

業務要件の中から、システムで実現したいシステム化の要件を定義記述する文章・ツールです。ネットや書籍で情報収集すると、この意味で要件定義書＝システムの要件を定義する文章・ツールと書いている情報が多いのではないでしょうか。

しかし、社内ＳＥが実際にＩＴモノづくり＝ＩＴでビジネス課題を解決する場合には、ＩＴ以外、もしくは、ＩＴとセットでどうビジネスや業務を変え課題を業務・事業部と一緒に解決していくかが重要です。ＩＴだけで解決出来る事の方が圧倒的に少ないです。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

Sierにとっての要件定義書とは？

契約に基づきシステム実装・実現を約束する範囲をユーザーと握る為の文章・ツールです。

Sierがシステム開発の案件を受注した段階では、その定められたスコープの内で何を実現するかを定めるのがシステム要件定義です。

世間一般で、要件定義という言葉を耳にすると、既に暗黙の了解としてシステム要件定義を指している場合があります。しかし、社内SEや事業会社目線では、業務要件の記述こそ非常に重要と言う点を認識しておく必要があります。

システム要件定義書の概要

ここからは、システム開発や構築の為の要件定義書にどんな要素や記述が必要なのか？を解説します。解説するポイントは以下です。

要件定義書の書き方

要件定義書の書き方の手順は以下です。
０．（外部に支援を依頼する場合）契約
１．　インプット情報収集
２．　収集した要求や要件情報の整理
３．　不足する内容のヒアリング・深堀
４．　文章化とレビュー
５.　 要件を然るべき場所・人（達）の承認

上記ステップを補足shます。まず初めに、外部を使い要件定義を推進する場合、１にも２にも契約が必要な点は最初に気を付けるべき点です。契約が済んだら、まずは要件定義書を書きあげる為に必要なインプット情報の収集が必要です。要件定義書を書くためのインプットが不足すると中身のある要件定義書を書きあげる事ができません。システム要件定義書は、プロジェクトの全体の要件のシステムで開発する一部分です。その為、要件定義書を書きあげる為に必要なインプットなる関連成果物を抑えておく必要があります。(以下で、図と一覧で補足します。）

情報が集まったら、不足する情報をディスカッションし深堀します。そうして討議した情報を文章化します。この文章化が非常に重要です。文章化せずすすめてしまうシステム開発は後の工程で必ず認識齟齬が発生します。文章化し然るべき場所と人（達）により承認してもらう事で要件を固め次の工程に進むことができます。

要件定義書が出来上がっても、検討が十分にされず中身の無い文章ではシステム要件を特定できない。然るべき検討がされ、その結果の文章化が重要。成果物を作るというのは手段であり、目的は、実のある検討を形にする事。手段が目的にならないように注意

— kato@社内SE (@it_compass_guru) May 24, 2024

要件定義の前のフェーズは、企画フェーズです。したがって、企画フェーズ検討された内容に基づき要件定義フェーズで内容を深堀していきます。以下は企画フェーズで作成される成果物の例です。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

企画フェーズで上記の成果物が出来上がっていると、要件定義で何をするの？と思うかもしれません。GOOD　QUESTIONです。企画や起案フェーズでは、成果物があったとしても（事業会社のシステム検討では結構なかったりしますが、、、）ハイレベルな情報です。要件定義では、そのハイレベルな情報や、企画フェーズで検討されなかった情報を検討し深堀していきます。システムを構築する為には、どんどんどんどん物事を具体化していく必要があります。この要件フェーズで一気に柔らかい部分や不明確な要件を積め、何をシステムに求めるか固めます。

要件定義書の書き方のポイント

後ほど、要件定義書に必要な項目とそれぞれの書き方を解説します。ここでは、もっと一般的に要件定義書事態を書く上でのポイントを解説します。そのポイントは以下です。

１．曖昧な表現を避ける

要件定義書の目的は、書くことではなく明文化し関係者と内容を合意し認識齟齬を防ぐものです。その為、要件定義書に記載している表現が曖昧では、人により解釈がことなり認識齟齬の元になります。

２. 文章化・明文化を意識する

議論した内容で、記載した方がいいか迷うような項目は記載すべきです。時間がたてば、議論した人の記憶も曖昧になり薄れていきます。書かれていないのはたとえ議論しても無いと同じです。迷ったら明文化を意識しましょう。

３．　一貫性を持つ

プロジェクトでは、要件定義の書き手も読み手も複数の人が参加します。その為、書き方もバラバラである場合には、読み手も相当なコストがかかります。用語、図式、ドキュメントのテイスト・ルールを統一し読みやすい文章を目指します。

４．成果物テンプレートを握る

要件定義書として納品・レビューする段階で、こんな要件定義書は期待していなかったとならないように、要件定義できれば開始時点で、成果物のテンプレート等で認識合わせをしましょう。こうする事で後での手戻りや認識齟齬を未然に予防できます。

成果物の全体像を理解する

（書き方のコツというよりは、進め方のコツですが）要件定義を上手く進めれない人は、全体像がわからないのがほとんどです。

抑えるべき全体像は2つです。
１．そもそもの成果物の一覧を知らない
２．成果物１つずつがどんな形で完成するか？のイメージがつかない

一言で言い換えるとゴールが分からないので迷走するという状態です。これを回避するために、以下で解説する、要件定義書の中身として必要な要素・項目と、要件定義書を作る為に必要なインプット情報の両方の観点で関連する成果物を抑える必要があります。その上で、それぞれのイメージをプロジェクト開始前にSierや事業部等とすり合わせ認識齟齬を防止します。

成果物別の役割分担を握る

どの要件定義の成果物を誰が作るか理解していないと責任分界点があいまいになり、結局、社内SEが全部手を動かすことになります。要件定義書作成に必要な多数のインプット情報のどれを誰が収集するのか明確化する事で効率的に且つ協力して準備を進める事が出来ます。

コミニケーションの質と量を上げる

上手く書く為には、インプット情報を集めるだけでは不十分です。ドキュメントの内容が薄い部分に関しては、ディスカッションやヒアリングを通してインプットの質を上げる努力が必要です。必要な情報の量と質が上がれば自然とアウトプットとなる要件定義書の成果物の品質も上がります。

要件定義書の要素

システム要件定義に必要な一般的な要素の一例は以下です。上記のインプット情報でもシステム要件定義書に引用し入れる場合の多い要素を含んでいます。ちなみに、要件定義書という言葉から１つの巻物（ドキュメント）を想像する人もいらっしゃいますが、必ずしも１ドキュメントと言う必要はなく、Sierや自社の企業文化によって適当なドキュメントに分類・分割される場合もあります。

どんなシステム開発をするのかにより、必要な項目は異なりますが、基本形として上記を認識しましょう。例えば、クラウドのサービス利用（一部カスタマイズ）の場合ハードウェア構成等は不要にるといった具合です。

要件定義書作成の役割分担

要件定義書を書き進める上では、どの部分を誰が担当し要件定義を推進するのかも重要です。まずは、以下の図の様に要件定義を自社で推進する場合どのパターンでSierやコンサルを利用しているか認識する必要があります。その上で、要件定義で必要なインプット情報のどの成果物を誰が責任を持ち作成し、又要件定義書を（Sierを使う場合は）誰がどこまで書くかプロジェクト開始前（契約時点）で合意する必要があります。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

要件定義書の各項目の書き方

要件定義書の各項目を更に詳しく解説していきます。以下一覧の幾つかの主要な項目に関して解説していきます。要件定義書のサンプルやテンプレートをお探しの方は、このセクションの下に読み飛ばしてください。

　プロジェクトの目的の書き方

プロジェクトを通してどんなビジネスや業務課題を解決したいのか記述します。本来であれば、起案者のプロジェクト計画書から引用する形で済むはずです。しかし、大抵そこまで明文化されたドキュメントが存在しない場合もある為要件定義書の冒頭にあえて明文化しておきます。

課題とシステムでの解決方法概要の書き方

ビジネス・業務が直面している課題とそれを今回の施策でどう解決するか記述します。これも、プロジェクト企画書が存在する場合はハイレベルな課題が既に洗い出されている場合があります。もし、存在しない場合は、プロジェクトの目的を達成するために、何を課題と捉えどう解決するつもりか文章化します。

Sierと社内SEでは、ここで記述する課題の領域に差がある点に留意が必要です。Sierの場合は自社の提案するソリューション領域に特化し何の課題を解決するか記載します。社内SEの要件定義の場合、ITで解決する課題と、IT以外で解決する部分を含む全体像を捉え、ITスコープを明確にする目的もあります。

例えば、倉庫業務の効率化の場合、
・複数拠点存在した倉庫の集約　（IT以外で解決）
・受注業務を宅配業者に委託　（IT以外で解決）
・自動倉庫の導入　（ITを含む打ち手で解決）
の様に整理が可能です。

システムでの解決概要の書き方

ここでは、上記の例の場合、自動倉庫のどんな機能を構築・導入するのかの概要を記載します。文章やPPTの作り方次第では、上記の項目とマージし表現出来ます。

システム全体像の書き方

導入するシステムの全体像や業務領域を記載します。目的は、今回のプロジェクトでどのシステム、どの業務領域がハイレベルでスコープなのかを図などを使い表現するのが目的です。特に、プロジェクトで複数システムの改修がマルチベンダーで実施される場合は、どこまでの業務で利用されるシステムが対象になるか認識を合わせる必要があります。又、AS-ISの全体像がどのようなTO-BEの全体像になるのかを含むことで変化点を明確にできます。

業務フローの書き方

本来、業務フローの作成自体は業務が実施すべきです。しかし、IT導入後どの部分がシステムで実現される業務になるのかのTO-BEはシステム要件定義で文章化する事でTO-BE像が出来上がります。SIerの場合、パッケージで既に定義されたOUT OF　BOXの業務プロセスがある場合もあります。今回提案する企業にどう調整した形のプロセスになるのか明文化します。要件定義書に添付する形で業務フローを入れ込む方法もありですし、業務フローを元にハイレベルな資料を起こし、開発対象範囲のスコープを明確化するツールとしても活用できます。

機能要件の書き方

システムがユーザーに提供するシステム機能（動作）を定義します。機能要件の書き方のコツとしては、一括りに機能と言っても様々な機能の定義が存在する点をまず認識する必要があります。又、機能要件事の依存関係も概要を把握しておくべきです。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

（①～⑤がユーザーが求める機能要件の例としてみてください）

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

データ要件の書き方

ユーザーが直接利用する機能以外にも、データ要件、ユーザーインターフェース要件等々があります。データ要件は、定義された機能や非機能要件に基づきどんなデータが必要かを定義します。データ要件は、機能要件やユーザーインターフェース要件がある程度詰めないと見えてこない特徴を理解する必要があります。又、スクラッチ開発の場合データ要件にはデータの構造、データの形式、データのフローなどを記載します。一方、パッケージ導入の場合、データ構造や形式などはある程度定められているため、この定義の仕方も異なる為、パッケージ導入の場合、Sier等とパッケージ導入における要件定義で決めるデータ要件・項目の確認が必要です。この進め方は、データだけではなく、ユーザーインターフェースも同様です。

ユーザーインターフェース要件の書き方

画面や帳票などにどのようなUIを求めるのかを定義していきます。書き方のポイントとしては、ユーザーインターフェースには、人が見る画面だけではなく、帳票やDLするファイルの定義も含まれる点を留意し漏れなく検討が必要です。又、UI検討を大きなチームで実施し且つ統一したルールが無いと要求事のバラバラのUI要件・設計になる場合があるので統一感をもって進める必要があります。

移行要件の書き方

移行時に、どのような前提や要件があるのかを記載します。この場合の移行は、データ、業務、アプリケーション、運用を既存からどのように新システム・業務に移行するかを定義します。データだけ、アプリだけでは片手落ちです。

移行要件のポイントとしては、移行要件の洗い出す事を忘れないことが最も重要です。機能の要件はTo-Beの業務フローを見ながら想像しディスカッションも弾みます。しかし、そのTo-Beにたどり着くために必要な移行に関してはそもそも検討が漏れる傾向があるので注意が必要です。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

運用要件の書き方

システムリリース後、運用上求められる要件に関して記載します。このポイント・書き方は、運用チームを巻込み要件を洗い出す事です。結局開発チームは、開発が終われば運用チームに引き継ぎます。その運用チームの視点でその仕組みや運用設計で回るのか、要件を出してもらう必要があります。運用をやりもしない人が要件を出すのと、実際に運用する人が洗い出す要件では質が異なります。又、運用する本人たちが出す要件やIT運用設計は彼・彼女たちが責任を持ち実装する必要がより強くなり成功確率が上がります。

非機能要件の書き方

非機能要件は、実装する機能を支える、システムに求められる条件といえます。この書き方のポイントは、広義の非機能要件の中にも様々な項目が存在する点を理解する事と、非機能要件を洗い出す適切な関係者を巻込むことです。業務や事業部にヒアリングをする事で性能系の非機能要件を洗い出す事が出来ます。但し、セキュリティーの観点や認証方式等ITの専門家の視点で必要な要件はユーザーヒアリングでは洗い出せません。

その為、非機能要件を洗い出すために、自社のそういったインフラやセキュリティーチーム（企業によってどういうチームで担当しているか異なる為要確認）を巻込みシステムとして具備すべき非機能要件を洗い出す必要があります。

社内SE 1年目から貢献！情シス　企画・開発・運用 107のルール

システム要件定義書ですぐに使えるテンプレート７選＋α

無料で使えるエクセルの要件定義書のフォーマットがダウンロードできるサイトを紹介していきます。

ご紹介する要件定義書テンプレート・サンプル

①要件定義書サンプル　ー（ワード）表表紙のみ

Bizrouteさんのサイトでダウンロードできる要件定義書のテンプレート（ワード）です。表表紙だけですが、なんの項目を書いたらいいかわからない人におすすめです。

②要件定義書サンプルー（エクセル）表表紙のみ

エクセル版の要件定義書テンプレートです。
・表紙
・更新履歴
・目次
・内容
です。

あくまで、要件定義書のフォーマットのテンプレートサンプルです。無料で使えダウンロードの際にユーザー情報登録も無くて便利です。

③IPAの要件定義書の各小冊子事のサンプルやフォーム

IPAのサイトでは、各小冊子事の要件定義書のサンプルを提供してくれています。紹介されている小冊子の一覧は以下です。

上記リストは2024年5月時点でのIPAサイトの情報を元にリスト化したものです。

④要件定義書サンプル:札幌市 文書管理システム再構築に係る設計・開発業務

少額案件ではちょっとリッチすぎる感はありますが、全体感がすごく好きです。建付けを参考にして作っていくのがいいと思います。

⑤要件定義書サンプル:2022 年度産業保安システム更改に係る要件定義書

実際の要件定義で内容をサンプルとしてイメージがつかめます。

⑥要件定義書サンプル:環境省自然環境局総務課動物愛護管理室

環境省自然環境局総務課動物愛護管理室の要件定義書サンプルです。

記述が細かく書いてあり全体像とどんな内容を書くべきかの理解に便利です。システム開発の規模次第でここまですべての記述は不要ですが全体感を掴むことができます。注意点は、PDFなので修正して使うことはできないのでエッセンスの理解用に活用ください。

⑦毎月勤労統計調査オンラインシステムの更改及び運用・保守に係る業務一式要件定義書

P37から運用に関する要件もしっかり記述してあるので運用に関する要件の検討が特に必要なプロジェクトの場合は参考になります。

⑧システム要件定義の進め方を理解：情報処理推進機構（IPA）のユーザのための要件定義ガイド

超初心者の方には、上記画像の『情報処理推進機構（IPA）のユーザのための要件定義ガイド 第2版　要件定義を成功に導く128の勘どころ』がおすすめです。

128ページと長文なので使い方のアドバイスは、社内SEの方は、2章と4章～7章を読み進めると全体像がかなりつかめるようになります。

IPAの要件定義ガイド

⑨IT関連のオンライン講座

システム開発に必要な学びを提供してくれるプラットフォームがBizlearnでITに関連するそもそもの知識の勉強をするのもシステム開発スキルアップにつながります。

システム開発に使えるテンプレートがダウンロードできるサイト

システム開発に関連するその他ドキュメントがダウンロード可能なサイトのご紹介です。

システム開発の成果物・ドキュメント一覧まとめの記事

本サイトでも、要件定義以外に上記の成果物のダウンロード可能なリンクをまとめています。本記事と合わせてご覧ください。

テンプレート無料ダウンロード

【テンプレートの無料ダウンロード】のサイトから以下のダウンロードができます。

Bizroute

1 仕様書・設計書のテンプレート
1.1 要件定義書
1.2 基本設計書
1.3 詳細設計書
1.4 テスト仕様書
2 システム開発の初期に必要なテンプレート
2.1 体制図
2.2 議事録
3 スケジュール管理・タスク管理用
3.1 WBS
3.2 ガントチャート

と言ったサンプルがダウンロード可能です。

社内SEの勉強におすすめ！システム開発が学べる本22冊【厳選】

ITエンジニア（SE・社内SE・情シス）として何から勉強したらいいか分からない 現場で認められる実力を伸ばしたい！どんな本が社内SEの勉強にオススメか知りたい ...

itinfoshop.com

2024.05.03

要件定義書の書き方＆テンプレート/サンプル７選|すぐに使えて便利まとめ

本記事でご紹介内容のまとめは以下です。

要件定義の書き方のおさえておきたい概要

要件定義に必要なインプット情報

要件定義書の目次・構成要素

要件定義書のサンプルダウンロードサイト

本記事の内容が要件定義書を上手く書けるお手伝いになれば幸いです。