開発の基本概念

要件定義ようけんていぎ

システム開発要求仕様ウォーターフォール機能要件非機能要件RFP

要件定義について教えて

簡単に言うとこんな感じ！

家を建てる前に「部屋は何部屋？お風呂は？駐車場は？」って決める設計打ち合わせみたいなもの！システム開発の一番最初に「何を作るか」をちゃんと言葉にして合意しておく作業だよ。ここをサボると、できあがったシステムが「思ってたのと違う！」になっちゃうんだ。

要件定義とは

要件定義とは、システム開発を始める前に「このシステムで何を実現したいか」「どんな機能が必要か」「どのような品質・性能が求められるか」を明確にして文書化するプロセスのことです。発注側（ビジネス側）と開発側（ITベンダーやエンジニア）が同じゴールを向いて開発を進めるための”共通言語”を作る工程とも言えます。

要件定義の成果物は要件定義書（または要求仕様書）と呼ばれ、この文書が後続の設計・開発・テストすべての基準となります。要件定義が曖昧だと、開発の後工程になるほど手戻りコストが膨らみ、最悪の場合「作ったけど使えない」システムが完成してしまいます。プロジェクト失敗の原因の多くが要件定義の不備にあるとも言われており、発注者にとって最も重要な関与ポイントです。

ビジネス側の担当者が「現場の業務をどう改善したいか」という業務要件を整理し、それをITで実現するためのシステム要件に落とし込む作業を、発注側とベンダーが協力して行います。発注者が「ITのことはよくわからないから任せた」と丸投げしてしまうと、ビジネス上の真のニーズが伝わらず、的外れなシステムが出来上がるリスクが高まります。

要件の種類と構造

要件定義で整理する内容は大きく2種類に分かれます。

種類	別名	内容	例
機能要件	Functional Requirements	システムが「何をするか」	受注データを登録できる／PDFで帳票を出力できる
非機能要件	Non-Functional Requirements	システムが「どれくらいの品質で動くか」	1秒以内に画面が表示される／99.9%の稼働率を維持する

非機能要件の主なカテゴリ（覚え方：「か・せ・し・う・う・ほ」）

カテゴリ	内容	具体例
可用性（か）	止まらないか	年間ダウンタイム8.76時間以内
性能・拡張性（せ）	速いか・増やせるか	ピーク時1,000同時接続に耐える
セキュリティ（し）	安全か	通信の暗号化・アクセス権限管理
運用・保守性（う）	管理しやすいか	障害発生時に1時間以内に復旧できる
移行性（う）	データを引き継げるか	既存の顧客DBを新システムに移せる
保守性（ほ）	後で直しやすいか	改修コストが最小化されている

要件定義書に含まれる主なドキュメント

業務フロー図 — 現状（As-Is）と将来（To-Be）の業務の流れを図で示す
機能一覧 — 必要な機能をリストアップした表
画面一覧・画面遷移図 — どんな画面が必要かの概要
データ項目定義 — 扱うデータの種類・形式・桁数など
外部インターフェース定義 — 他システムとの連携仕様
非機能要件定義書 — 品質・性能・セキュリティの基準

歴史と背景

1960〜70年代 — 大型コンピュータ（メインフレーム）時代。システム開発は一部の専門家が担い、要件整理は口頭・メモ程度だった
1970年代 — ウォーターフォールモデルが登場。「要件定義→設計→実装→テスト」という順序立てた開発手法が広まり、要件定義が独立した工程として重視されるように
1980〜90年代 — 企業の基幹システム（ERPなど）導入が加速。大規模プロジェクトでの要件定義の重要性が業界全体に認識される
2001年 — アジャイル宣言が登場。「変化への対応」を重視する開発手法が普及し、要件を最初にすべて決めきる必要はないという考え方も台頭
2000年代以降 — IPA（情報処理推進機構）が「非機能要求グレード」などの標準化ガイドを公開し、非機能要件の定義が体系化される
現在 — クラウドやSaaS活用の拡大により、ゼロから作る「フルスクラッチ開発」は減少傾向。一方で、パッケージ導入でも要件定義（何をどうカスタマイズするか）の重要性は変わらない

開発フローにおける要件定義の位置づけ

要件定義はシステム開発の最上流に位置します。ここでの判断が、プロジェクト全体のコスト・品質・スケジュールを大きく左右します。

ウォーターフォールとアジャイルにおける要件定義の違い

観点	ウォーターフォール	アジャイル
要件定義のタイミング	開発開始前に全要件を確定	反復しながら少しずつ詳細化
要件変更への対応	変更には大きなコストがかかる	変更を前提として設計されている
向いているシステム	要件が安定している基幹系	仕様が変わりやすいWebサービス系
発注者の関与	最初の集中的な関与が重要	開発期間中も継続的に関与が必要

要件定義と RFP の関係

RFP（Request for Proposal：提案依頼書） はベンダーに「こういうシステムを作ってほしい。提案してください」と依頼するための文書で、要件定義の内容を基に作成されます。

発注者側の流れ

  ① 業務課題の整理
       ↓
  ② 要件定義（何が必要かをまとめる）
       ↓
  ③ RFP作成（ベンダーへの提案依頼書）
       ↓
  ④ ベンダー選定・契約
       ↓
  ⑤ 開発スタート

要件定義がしっかりできていれば、RFPの精度が上がり、ベンダー各社から比較可能な提案を受け取れます。逆に要件定義が曖昧だと、各社がバラバラな解釈で提案してきて金額・内容の比較ができなくなります。

規格番号	内容
IEEE 830	ソフトウェア要求仕様書（SRS）の推奨プラクティス。要件定義書の記述方法を標準化
ISO/IEC/IEEE 29148	システム・ソフトウェアエンジニアリングにおける要求工学の国際規格