スコープ管理

要件定義ようけんていぎ

システム開発発注RFP機能要件非機能要件スコープ

要件定義について教えて

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

「新しいシステムに何をやってほしいか」を言葉で整理して文書にまとめる作業だよ！家を建てるときの「間取り図と仕様書」みたいなもので、これがズレると出来上がったシステムが「思ってたのと全然違う！」になるんだ。

要件定義とは、システム開発の最初のフェーズで行われる作業で、「そのシステムが何をできなければならないか」を洗い出し、関係者全員が合意できる形で文書化するプロセスです。発注者（ビジネス側）とベンダー（開発者側）が同じゴールを向いて開発を進めるための「設計図の前段階となる約束書」といえます。

要件定義がしっかりできていないと、開発が進んでから「あの機能が足りない」「そもそも使い勝手が違う」といった手戻り（やり直し）が大量発生します。開発費用の超過・納期の遅延・品質低下はほとんどがここでの詰めの甘さに起因するといわれており、ITプロジェクトにおいて最も重要な工程のひとつです。

要件定義は、発注者側（ユーザー企業）が主体的に関わるべき工程でもあります。「何をしたいか」を一番知っているのは現場や経営者であり、ベンダー任せにすると業務の実態とかけ離れたシステムができあがりやすくなります。

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

種類	説明	例
機能要件	システムが「何をするか」	注文管理・在庫確認・帳票出力など
非機能要件	システムが「どのように動くか」	性能・セキュリティ・可用性・保守性など

機能要件は「できること・できないこと」のリスト、非機能要件は「どの程度のレベルで動くか」の品質基準です。発注者が見落としがちなのは非機能要件で、後から追加しようとすると費用が跳ね上がりやすいため注意が必要です。

要件定義の2大カテゴリは「機能要件（キノ）」と「非機能要件（ヒ）」。この2つを”キノヒ”と覚えておくと、ヒアリング時に抜け漏れを防げます。

1970年代〜 ソフトウェア開発の規模拡大に伴い、「作る前に決める」文化が生まれ始める。ウォーターフォール型開発の普及とともに要件定義が開発工程の「第一フェーズ」として確立
1984年 IPAの前身となる組織が日本でソフトウェア工学の体系化を推進。要件定義の重要性が国内でも認知される
1990年代 ERPパッケージ（SAPなど）の普及により、「パッケージに業務を合わせるか・パッケージをカスタマイズするか」を決める要件定義の位置付けが重要化
2000年代 アジャイル開発の台頭により、「最初にすべてを決める」従来型要件定義の限界が議論される。ユーザーストーリーやバックログによる要件管理が登場
2010年代以降 DX推進の流れで、業務部門がシステム発注する機会が増加。発注者側リテラシーとしての要件定義スキルが注目される

要件定義は一般的に以下のステップで進みます。

要件定義の最終成果物は**「要件定義書」です。この文書は開発契約の基準となり、後工程の設計・開発・テストすべての起点になります。「スコープ外（やらないこと）を明示する」**ことも要件定義書の重要な役割で、追加要望による予算超過を防ぐ防波堤になります。

要件定義のアプローチは開発手法によって大きく異なります。

どちらが優れているかではなく、開発するシステムの性質・発注者の準備状況に合わせた選択が重要です。基幹系・業務システムの発注ではウォーターフォール的な要件定義書を求められることが多いため、発注者としてしっかり関与する姿勢が求められます。

ビジネスパーソンが発注側として関わる際に特に注意すべき落とし穴を整理します。

規格番号	内容
ISO/IEC/IEEE 29148:2018	システム・ソフトウェア工学における要件エンジニアリングのプロセスと要求事項を規定した国際標準
IEEE 830	ソフトウェア要件仕様書（SRS）の推奨プラクティス（現在は29148に統合）