エンジニア未経験が学ぶ要件定義の基礎知識
システム開発における「要件定義」は、ビジネスの狙いを現実のシステム設計へと落とし込む最も重要な工程です。未経験者が押さえておくべき全体像と基礎知識を整理します。
要件を定義するとは？
要件定義とは、「作ろうとしているシステムで何を実現したいのか」を整理し、開発チームが実装可能な仕様として明文化する作業です。
発注者やユーザーの「こんなことがしたい」という抽象的なニーズ（要求）を、エンジニアが開発に着手できる具体的な基準（要件）へ変換する「橋渡し」の役割を果たします。
要件はなぜ決める必要があるのか？
要件定義が曖昧なまま開発を開始すると、プロジェクトの終盤で致命的な問題が発生します。
- 手戻りの防止: 作成途中で「やっぱりこの機能も必要だった」と判明した場合、設計や実装のやり直しで多大なコストと時間が吹き飛びます。
- 認識のズレの解消: 発注者（ビジネス側）と受注者（エンジニア側）の間で「できると思っていたこと」のギャップを事前に埋めます。
- 納期と予算の守り抜き: 作るべき範囲（スコープ）を明確にすることで、プロジェクトの無駄な膨張を防ぎます。
要件では何を決めるのか？
要件定義で決定する主な要素は、目的（ゴール）、機能、そして品質基準（機能要件・非機能要件）の3つです。
「要望」と「要求」と「要件」の違い
最も混同しやすい3つの言葉は、段階に応じて明確に区別します。
- 要望（Wish）: 期待や理想。「売上を伸ばすためにシステムを便利にしてほしい」
- 要求（Demand）: 実現したい具体的なニーズ。「顧客データをCSVでダウンロードしたい」
- 要件（Requirement）: システムに落とし込んだ決定事項。「管理者権限のユーザーが、過去1年分の取引履歴をUTF-8形式でCSV出力できるようにする」
プロジェクトのゴール
システムを導入することでどんなビジネス課題を解決し、どのような成果（KGI/KPI）を目指すのかを定義します。ゴールがブレると、途中で機能追加の判断に迷った際の指針を失います。
機能要求の分析・定義
システムが直接提供すべき機能（画面や処理）を洗い出して定義します。
- ユーザー管理機能（新規登録、ログイン、マイページ）
- 決済機能（クレジットカード決済、領収書発行）
- 管理画面機能（売上レポート作成、ユーザー停止）
非機能要求の分析・定義
機能以外の、システムの品質や運用条件に関する基準を定義します。
- 性能・処理能力: 同時アクセス数に何人まで耐えられるか、画面表示速度は何秒以内か
- セキュリティ: データの暗号化、アクセス権限の制御
- 可用性: システムが停止しない時間（稼働率99.9%など）
- 保守性・運用性: バックアップの頻度や障害発生時の復旧手順
要件は誰が決めるのか？
要件は発注者（プロダクトマネージャーや事業責任者）だけで決めるものでも、エンジニア任せにするものでもありません。
- ビジネス側（PdM / PM）: 「何を達成したいか（What / Why）」を定義し、最終決定を行う責任を持ちます。
- 技術側（エンジニア / デザイナー）: 「技術的に実現可能か」「より良い実現方法はないか（How）」の視点からフィードバックし、共同で作り上げます。
要件はプロジェクトマネジメントにおいて、いつ・どのタイミングで決めるのか？
要件定義は、原則としてプロジェクトの初期段階（開発着手前）に行います。
- 構想・企画: プロジェクトの発足・目的設定
- 要件定義（★ここ）: 目的を具体的な機能・非機能要件に落とし込む
- 基本設計・詳細設計: 要件をもとに画面デザインやデータベース構造を決める
- 実装・テスト: コードを書き、仕様通り動くかテストする
アジャイル開発の場合は、開発サイクルごとに要件定義と実装を細かく繰り返しますが、いずれのスタイルでも「コードを書く前」に要件を確定させる原則は変わりません。