要求定義と要件定義についての記事というのは需要があるようですね。
検索されるだけなのか？そもそも話し合いの中では、その「定義」を確定して、話しておくことが大事なのですよね。言語を学ぶ上で、まずはひらがなからカタカナからそしてローマ字など文字を学ぶように、プログラミング用語や現場で使う単語などというのは意識して使っていかないと追いつけなくなってしましますからね。
役割分担、期日を決めるなどマネージメントの方もプロジェクト進行では、考えていきたいですね。
最近の近況
バーチャルな世界に興味があり、バーチャルSNSなどにも顔を出しながら作業してます。
はじまり
はぁ…
なんでシステム開発が失敗するんだろう…
仕様の変更が多くて…
言った言ってないのトラブルから避けたい…
システム動かしてみても全然使えない…
実は．．
事業運用をオペレーションレベルに展開しないままに、
システム開発をしてしまうところに原因があります。
入力画面や出力を決めても…
それを使って、いかに日々の仕事をこなすのか？
オペレーションレベルまで突き詰めた創りこみをしないで、専門家だから、プロだからと．．．コンピュータの専門家に、業務運用の仕組みまで丸投げにしてしまうことが問題になります。
表 何が違うのか？
| 項目 | 要求定義（Requirement Definition） | 要件定義（System Requirement Specification） |
|---|---|---|
| 視点 | 利用者・ビジネス側の視点 | 開発者・システム側の視点 |
| 内容 | 「〜したい」「〜を実現したい」 | 「〜する必要がある」「〜を満たす仕様」 |
| 主語 | 事業・業務 | システム |
| 書く人 | ビジネス担当（＋SE） | SE・アーキテクト |
| 成果物 | ビジネス要求、業務フロー、課題、期待値 | 機能仕様、非機能仕様、システム要件 |
要求定義と要件定義の違いについて
ビジネス層
事業運用オペレーション
ユーザーインタフェース（UI）
顧客体験（CX）
業務フロー・KPI
目的
「利用者が何をしたいのか」「事業として何が必要か」を明らかにする。
要求定義
・「〜したい」と利用者側の希望、ビジネスで何が必要なのかなどを記載したもの
✔ 要求の例
「売上を把握しやすくしたい」
「予約管理をスマホから簡単にしたい」
「問い合わせ対応を自動化したい」
「顧客満足度を高めたい」
✔ 要求定義で作るもの
ビジネス背景・目的
ペルソナ / ユーザーストーリー
現行業務と課題
期待する成果（KPI、成功指標）
必要な業務プロセス
技術的なことはここでは書かない のがポイント。
「どう実装するか」ではなく 「なぜ必要か」「何をしたいか」 に集中します。
システム層
アプリケーション
パッケージ選定
データベース/API
通信・ネットワーク
技術層
データベース/通信プロトコル/...
OS
ハードウェア
セキュリティ
要件定義
・「〜が必要」システムの仕様書、システムが何をしなければならないかなどを記載したもの
目的
「要求」を満たすために、システムが実現すべき仕様を明確にする。
✔ 要件の例
「売上データを1時間間隔で自動集計すること」
「予約一覧は3秒以内に表示すること」
「問い合わせを自動返信するAIモデルを搭載すること」
「ユーザー数100万に耐えられるスケールを確保すること」
✔ 要件定義で書くもの
機能要件（何をするか）
例：ログイン機能、検索機能、決済機能…
非機能要件（どうあるべきか）
性能・可用性・セキュリティ・拡張性…
データ要件
テーブル定義、データフロー
システム構成
OS、ミドルウェア、API、ネットワーク
外部連携
決済APIや外部サービス仕様
要求定義と要件定義の違いを考える
どの会社でも、コンピュータのシステムを導入しています。
実績のあるパッケージソフトの導入なら問題ありませんが、自社のシステムを開発するとなると失敗などがあります。
特に、経験の少ないＳＥが担当した場合や無理な要求をした場合に失敗する可能性が高まります。
その原因は何なのでしょうか？
そこで重要となるのが、システム化の「要求」を正しくＳＥに伝えるということです。
ＳＥは、エンドユーザーの要求を正しく掴まないと．．．
要求を出発点とするシステム開発を成功させることができません。
システム開発には、ユーザーの要求を正しくつかみ、技術者が開発のために必要な要件定義を作成することが大切です。
開発には、要求を「どんな資料で、どうまとめる」のでしょうか？
要求定義と要件定義の関連は、どこにあるのでしょうか？
●要求定義
- 「～がしたい」 利用者の希望
- ビジネスで何が必要かを記述したもの
- 事業運用をオペレーションレベル考えそれを実現する
- コンピュータシステムへの要求
●要件定義
- 「～が必要」システムの仕様書
- システムが何をしなければならないかを記述したもの
- システムの機能やＤＢ・通信などの利用方法
要求定義が変更されると要件定義の変更が必要となります。
事業の方針が変わると、オペレーションが変わります。
オペレーションが変わるということは、画面や帳票などの
インターフェースの変更が必要となります。
ですから、システム開発をする時は．．．
具体的なオペレーションレベルで、作業の「仕組み」を捕えていないと、
「要求定義」が抽象的なものになります。
業務の運用の仕組みが抽象的なままだと．．
担当ＳＥの、その業務経験や能力、得意・不得意で、作成する「要件定義」が違ってきます。
ここが問題なのですね。
システム成功の要件は、担当ＳＥの経験と能力任せ．．
これでいいのでしょうか？
システム開発を３つの区分に分けると考えやすくなります。
- ビジネス
- システム
- ＩＴ技術
システム開発の現場では、この３つのレベルを一緒に論じがちです。
これは、全く別の能力です。全てに精通する人はいません。
「要求・要件」を追跡できる仕組みが必要
ビジネスの運用方針が変わった変わった．．
- システムのどこを修正すべきか？
システムに問題が出た．．
- その問題は、ビジネスのどこに影響があるか？
ビジネス環境は変化しています。
システムの開発環境も変化しています。
今、最良と思えるシステム開発ができたとしても、
そのまま使い続けることはできません。
常に改良を加えていく必要があります。
その時に．．．
要求と要件を追跡する仕組が無いと．．
プログラムのソースリストを追いかけることになります。
途方もない労力がかかります。
そして、成功率はかなり低くなります。
開発ドキュメントには２つ必要です。
- ビジネスの構造をオペレーションレベルで示すもの
- システム開発を行うＳＥが利用するもの
※ 両方をそろえることがこれからの開発には必要です。
要求定義
（利用者が求めるシステムの機能）
ビジネスの「要求」
ビジネスの基本設計
ビジネスの詳細設計
（ビジネスのオペレーション）
要件定義
（開発されるシステムの機能・仕様）
システム開発の設計仕様
- システムの基本設計書
- システムの詳細設計書
ソフトウェア
ビジネスの要求によって変化しやすいソフトウェアの要件を追跡管理していく環境を築く
文章から双方向で追跡できる環境を築く
方針決定
開発の範囲や手順
導入例・開発例の意見の一致
システムの品質 をよくしていくことにもつながります。
レイヤー構造で見ると理解しやすい
システム企画は基本的に、次の3層で考えます。
- ① ビジネス層 ＝ 要求定義（Whatを決める）
- ② システム層 ＝ 要件定義（Howを決める）
- ③ 技術層 ＝ 実装・設計
① 要求定義（ビジネス）
人・業務・UI・オペレーションの要求
「こういう価値を提供したい」
② 要件定義（システム）
ビジネス価値を実現するための機能・非機能要件
「こういう機能が必要」
③ 設計・開発（技術）
実際のアプリ、DB、通信、OS、インフラなど
「こう実装する」
よくある混乱ポイント
❌ UIの色や配置はどっち？
→ 要求定義
理由：ビジネス要求・ユーザー体験に属するため。
❌ APIの個数やレスポンス形式はどっち？
→ 要件定義
理由：システム仕様だから。
❌「業務改善のためにAIを使いたい」はどっち？
→ 要求定義
AIというプロダクト指定ではなく、目的が重要。
❌「AIモデルは○○方式を採用する」はどっち？
→ 要件定義
技術の選定は具体的な仕様となるため。
まとめ：役割分担を明確にすると失敗しない
● 要求定義
→ 「ビジネスのために何を実現したいか」を言語化するフェーズ。
● 要件定義
→ 「それを実現するためにシステムが何をすべきか」を設計するフェーズ。
要求が曖昧だと、要件定義は正しく作れない。
要件定義が曖昧だと、実装は必ず迷走する。
この2つを明確に切り分けられると、
プロジェクトは驚くほどスムーズに進みます。
関連情報
関連サイト
投稿情報
投稿日 2016年11月02日
更新日 2021年04月17日
確認日 2022年11月02日
- NEWS 227625 views
- 2021 祝17万pv突破しました。
- 2021.4.17 祝19万pv突破しました。
- 2021.6.22 祝20万pv突破しました。
- 2025.6.6 祝24万pv突破しました。
めっちゃみてくださってますね。
ありがとうございます。
関連記事
- 【About】(http://qiita.com/sunstripe) - サンストライプについて
