要件定義とは?
要件定義とは、システム開発の最初の工程で、「システムで何を実現するか」を発注者と開発者が合意して文書化する作業のこと。ここでの認識ズレが後工程の手戻りの最大原因で、プロジェクトの成否を左右します。
実務での使い方
整理する内容は大きく3つで、①業務要件(業務フローがどう変わるか)②機能要件(システムが何をするか)③非機能要件(性能・セキュリティ・稼働率など)です。開発会社任せにせず、業務を知る現場担当者が参加することが品質の条件になります。RFPの段階で課題を明確にしておくと、要件定義がスムーズです。
よくある失敗は、要望をすべて「必須」にして予算とスケジュールが破綻することです。Must(必須)とWant(歓迎)を分け、初回リリースはMustに絞るのが定石です。また、性能や障害時対応などの非機能要件は漏れやすく、後から発覚すると高くつく代表例です。
要件定義で決めること:機能要件と非機能要件
要件定義で固めるものは大きく2種類です。機能要件=システムが「何をできるか」(画面・帳票・データ・外部連携など)。非機能要件=「どれくらいの品質で動くか」(性能・可用性・セキュリティ・保守性など)。見積もりと契約の土台になるため、発注側と開発側の認識合わせの中心です。
見落とされやすいのは非機能要件です。「何秒で表示されるか」「障害時に何時間で復旧するか」「誰がどこまで操作できるか」は、決めていないと完成後に揉める典型的な論点です。
要件定義の失敗パターンと対策
よくある失敗は3つです。①現場ヒアリング不足=経営層と情報システム部門だけで決め、実際に使う現場の業務と合わない②全部盛り=関係者の要望をすべて取り込み、予算・納期が膨らむ③丸投げ=「いい感じに提案してください」とベンダー任せにし、出来上がってから認識ずれが発覚する。
対策の基本は、要件に優先順位を付けることです。「必須(ないと業務が回らない)/重要(効果が大きい)/あれば良い」に仕分け、予算超過時は下から削る合意を最初に取っておきます。また、現行業務の再現を要件にせず、「この機会にやめる業務」を決めることが、コストと効果の両面で最も効きます。
要件・要求・仕様は何が違う?
システム開発では、①要求②要件③仕様の3語を段階として使い分けます。要求は利用部門が出す生の要望(「毎月の集計に3日かかっているので楽にしたい」)。要件は、その要求のうち実現すると合意した内容を、システムが満たすべき条件として整理したもの(「月次集計を自動生成し、10分以内に出力できること」)。仕様は、要件を満たすための具体的な作り方(どの画面に何の項目を置き、どのデータをどう処理するか)です。
順番が重要で、要求をそのまま仕様に落とすと失敗します。要求は矛盾していたり、実現手段まで指定していたり(「Excelのマクロで作ってほしい」)することが多く、そのまま作ると本来の目的を外すためです。要求を一度「何を実現できればよいか」という要件の形に翻訳し、手段の選択は仕様の段階に回すのが定石です。
発注側が責任を持つのは要求と要件、開発側が主導するのが仕様、という分担が一般的です。ただし要件の文書は双方の合意で確定させるものなので、「決めるのは開発会社」と考えると、後工程で「言った・言わない」が起きます。
要求→要件→仕様の順に翻訳する。要求をそのまま仕様に落とすと、手段が目的化して本来の課題が解けない。