要件定義とは？進め方6ステップと要件定義書の項目・記載例、よくある失敗と対策を解説

📖 読了時間：約11分

要件定義とは、システムで実現すること（要件）を顧客と開発側で決め、要件定義書という文書にまとめる工程です。システム開発の最初の工程にあたり、ここで決めた内容が、後の設計・製造・テストのすべての前提になります。

IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」は、システム開発の遅れの過半は要件定義の失敗にあると言われる、と述べています。それだけ、プロジェクトの成否を左右する工程だということです。

以下では、要求と要件の違い、決める要件の種類、6つのステップでの進め方、要件定義書の項目と例、よくある失敗と対策の順に解説します。

この記事を読めば、要件定義の全体像と、実際に進めるときの手順が分かります。まずは無料でスキルログに登録し、これまでに関わった上流工程の経験を整理しておきましょう。

システム開発の工程は、要件定義、基本設計、詳細設計、製造、テストの順に進みます。要件定義はその入り口で、何を作るのかが決まらなければ、どう作るのかを考える設計には進めません。工程全体の流れはシステム開発の工程とは？流れと成果物の一覧で解説しています。

要求と要件の違い

要件定義を理解するうえで大切なのが、要求と要件の違いです。

用語	意味	例
要求	顧客や利用者が望んでいること	在庫の数をいつでも確かめたい
要件	要求のうち、システムで実現すると決めたこと	商品ごとの在庫数を画面で検索できる。更新は5分以内に反映する

要求をそのまま全部作ると、予算や期間が足りなくなります。要求を整理し、優先順位をつけて、実現する範囲を決めたものが要件です。

要件定義を担当する人

本来は発注する側（ユーザー企業）が主体となって決める工程ですが、実際には開発会社のシステムエンジニアやコンサルタントが支援し、聞き取りや文書づくりを担うことが多くあります。完成させる責任よりも作業の遂行に責任を持つ、準委任契約で進めることが多くあります。契約の違いは準委任・派遣・請負の違いで解説しています。

種類	決めること	具体例
機能要件	システムが提供する機能	商品の登録・検索・在庫の引き当て、月次の売上帳票の出力
非機能要件	性能、使いやすさ、安全性、運用など、機能以外の条件	検索結果を3秒以内に表示、平日8時〜22時は止めない、権限のない人は閲覧できない

機能要件は利用者の業務から考える

機能要件は、利用者の業務の流れに沿って洗い出すと漏れが減ります。「誰が、いつ、何のために、どんな操作をするか」を業務ごとに書き出し、そこからシステムに必要な機能を導きます。

非機能要件は見落とされやすい

非機能要件は、顧客から自発的に出てくることが少なく、後から「遅い」「止まると困る」と問題になりやすい要件です。IPAは、非機能要件を漏れなく確認するための「非機能要求グレード」という手引きを公開しており、性能や可用性、セキュリティなどの項目ごとにレベルを選んで合意する方法を示しています。

ステップ1：現状の業務を把握する

今の業務の流れ、使っている道具、関わる人を聞き取り、図にまとめます。業務の流れを図にした「業務フロー」は、関係者の認識をそろえるのに役立ちます。

ステップ2：課題と目的を整理する

「なぜシステムを作るのか」を明確にします。目的があいまいなままだと、要求の優先順位をつけられず、範囲が広がり続けてしまいます。

ステップ3：要求を洗い出す

利用部門、管理部門、情報システム部門など、立場の違う関係者から要求を集めます。声の大きい人の要求だけに偏らないよう、関係者を一覧にして聞き漏れを防ぎます。

ステップ4：要件に絞り込み、優先順位をつける

集めた要求を、予算と期間に照らして「必ず実現する」「できれば実現する」「今回は実現しない」に分けます。実現しないことを明記しておくのも重要です。

ステップ5：要件定義書にまとめる

決めた内容を、後の工程の担当者が読んでも分かる言葉で文書にします。あいまいな表現を避け、数値で確かめられる書き方にすることが大切です。

ステップ6：レビューを経て合意する

顧客と開発側の双方で内容を確認し、承認を得ます。合意した内容が、以降の見積もりや変更管理の基準になります。

在庫管理システムを例に、要件定義書の主な項目と書く内容をまとめました。項目の名前や構成は会社によって異なります。

項目	書く内容	記載例
目的・背景	システムを作る理由と、解決したい課題	在庫の確認に1日2時間かかっている作業をなくす
対象範囲	実現すること・しないこと	本社と3つの倉庫が対象。発注機能は今回は対象外
業務フロー	新しい業務の流れ	入荷→検品→在庫登録→出荷の流れを図で示す
機能要件	必要な機能の一覧と概要	在庫検索、入出荷登録、在庫数の月次帳票
非機能要件	性能・可用性・セキュリティなど	検索は3秒以内、平日8時〜22時は稼働
前提・制約	守るべき条件	既存の販売管理システムとデータを連携する

数値で確かめられる書き方にする

「速く表示する」ではなく「3秒以内に表示する」のように、テストで確かめられる書き方にします。こうしておくと、後の総合テストで合格の基準として使えます。

IPAの「ユーザのための要件定義ガイド 第2版」は、要件定義で起きる問題を48項目に整理し、それぞれに解決策を示しています。現場でよく見られる失敗と対策は次のとおりです。

• 関係者の聞き漏れ：後から別の部署の要求が出てくる → 関係者を一覧にして確認する
• 範囲があいまい：「これも入っていると思った」と食い違う → 実現しないことも書く
• 非機能要件の不足：稼働後に性能や運用で問題が出る → 項目の一覧で漏れを確かめる
• 合意の不足：担当者の承認だけで進めて後から覆る → 決裁できる人のレビューを受ける

変更はゼロにならない前提で備える

どれだけ丁寧に要件定義をしても、開発の途中で変更は起こります。変更を受け付ける手順と、費用や期間への影響の決め方をあらかじめ合意しておくことも、要件定義の大切な成果です。

要件定義の経験は、次のような職種への道で特に評価されます。上流と下流の工程の違いは上流工程と下流工程の違いで解説しています。

• システムエンジニア：要件をもとに設計をまとめる
• プロジェクトマネージャー：要件をもとに計画と予算を管理する
• ITコンサルタント：業務の課題からシステム化の方針を提案する
• 社内SE：自社の業務を理解し、外部の開発会社と要件を詰める

経歴として伝えるときは、「要件定義を担当」とだけ書くのではなく、対象の業務、関係者の数、作成した文書、自分の役割まで書くと伝わります。スキルシートでの書き方はスキルシートで要件定義経験を書く方法で詳しく紹介しています。ただ、ExcelやWordで経歴を書き足していくと、案件ごとに書く項目がばらつき、担当した工程の範囲や役割があいまいになりがちです。スキルログで記録すると、次の点で楽になります。

• 項目がそろう：案件ごとに期間・役割・プロジェクト規模・チーム規模・業種・担当工程・成果を同じ項目で入力するので、書き漏れがなく、案件どうしを比べやすい
• 体裁を整える手間がない：入力した内容はPDF出力で体裁の整ったスキルシートになり、新しい案件を足したらそのまま出し直せる
• 伸びたスキルが見える：スキルごとにS・A・Bなどの自己評価と経験年数を並べて確認でき、次に伸ばすところが分かる

登録した経歴をもとに、自分の経験で狙える求人や案件、年収や単価の目安を、転職・案件相談で一緒に確かめることもできます。

要件定義とは、顧客の要求を整理し、システムで実現すること（要件）を決めて、要件定義書にまとめる工程です。要件は機能要件と非機能要件に分けて整理し、現状の把握から合意までの6つのステップで進めます。

要件定義の後は、決めた内容をもとに画面や処理の作り方を決める設計の工程に進みます。基本設計と詳細設計の違いは基本設計と詳細設計の違いで解説しています。

要件定義と基本設計の違いは何ですか？

要件定義とは「何を作るか」を決める工程で、基本設計は「どう見せるか・どう作るか」の大枠を決める工程です。要件定義の内容を、画面や機能の形に具体化するのが基本設計です。

要件定義は誰が担当しますか？

発注する側が主体となり、開発会社のシステムエンジニアやコンサルタントが支援するのが一般的です。実際の聞き取りや文書づくりは、開発側が担うことが多くあります。

要件定義にはどれくらいの期間がかかりますか？

規模によりますが、数週間から数か月かかります。関係者の数や、業務の複雑さによっても大きく変わります。

未経験でも要件定義を担当できますか？

いきなり主担当になることは少ないです。まずは議事録の作成や資料づくりで要件定義の場に参加し、経験を積みながら担当範囲を広げていきます。

要件定義にAIは使えますか？

はい、補助として使えます。議事録の要約や、要求の整理、確認すべき観点の洗い出しに役立ちます。ただし、顧客との合意や優先順位の判断は人が行う必要があります。

ここまでの内容を踏まえて、まずはスキルログに無料で登録し、これまでに関わった要件定義の案件を、関係者の数や作成した文書まで入力してみましょう。