業務要件定義

システムを開発するとき、「何をつくるか」を決める工程が業務要件定義です。企画プロセスで「どの業務をシステム化するか」という大まかな方向性が決まった後、要件定義プロセスでは「そのシステムは具体的に何ができなければならないか」を詳細に定めていきます。

要件定義が曖昧なまま開発を始めると、「思っていたものと違う」「必要な機能が抜けている」といった問題が後から発覚し、手戻りが発生します。要件定義は、システム開発の成否を左右する非常に重要な工程です。

要件定義プロセスの流れ

要件定義は、大きく次のステップで進みます。

それぞれのステップを詳しく見ていきましょう。

要件定義の出発点は、利用者の要求の調査です。ここでいう「利用者」とは、実際にシステムを使う現場の担当者や業務の責任者のことです。

要件定義は利用者視点で行われることが大きな特徴です。開発者が「こういう機能があれば便利だろう」と想像してつくるのではなく、実際に業務を行っている人の声を聞き取ることからスタートします。

調査の具体的な方法としては、次のようなものがあります。

試験で出るポイント

要件定義は「利用者（ユーザ）の視点」で行うことが重要です。「開発者の視点で技術的な設計を行う」のは要件定義ではなく、後続の設計工程です。

利用者から集めた情報をもとに、調査内容の分析と現行業務の分析を行います。

この段階では、現在の業務がどのような流れで行われているかを整理し、どこに問題や非効率があるかを明らかにします。たとえば、次のような観点で分析を進めます。

現行業務を正確に理解することで、「新しいシステムでどこをどう改善すべきか」が具体的に見えてきます。

分析結果をもとに、システムに求める条件を業務要件としてまとめます。ここが要件定義の中核です。

業務要件の定義では、新しいシステムが対応すべき業務の範囲や内容を明確にします。たとえば「受注から出荷までの業務をシステムで管理する」「在庫がある基準を下回ったら自動で発注する」といった形で、業務上の要件を具体的に記述します。

業務要件を具体化する際に重要なのが、機能要件と非機能要件の区別です。この2つはITパスポート試験でも頻出のテーマです。

区分	意味	具体例
機能要件	システムが「何ができるか」を定めたもの	商品の検索ができる、注文履歴を一覧表示できる、CSVファイルで出力できる
非機能要件	機能以外の品質や条件を定めたもの	応答時間は3秒以内、24時間365日稼働、同時に1,000人が利用可能

機能要件は、利用者が「このシステムで何をしたいか」に直接対応するものです。「商品を検索したい」「売上レポートを出力したい」など、システムの具体的な機能を指します。

一方、非機能要件は、機能そのものではなく、その機能をどの程度の品質で提供するかを定めるものです。非機能要件には、次のようなカテゴリがあります。

たとえば、ネットショッピングのシステムを例にすると、「商品をカートに入れて購入できる」は機能要件、「注文確定ボタンを押してから2秒以内に完了画面が表示される」は非機能要件です。

試験で出るポイント

「機能要件と非機能要件の違い」は頻出です。機能要件は「何ができるか」、非機能要件は「どの程度の品質で動くか」と覚えましょう。選択肢に具体例が並んだとき、性能・セキュリティ・可用性に関するものは非機能要件です。

要件をまとめたら、最後のステップが要件の合意です。定義した要件の内容を、利用者（発注側）と開発者（受注側）の双方で確認し、合意を形成します。

合意が重要な理由は、要件定義の内容がそのまま「システムの設計図の土台」になるからです。ここで認識のずれがあると、完成したシステムが「思っていたものと違う」という事態に陥ります。

合意を得る際には、要件定義書などの文書にまとめて関係者間でレビュー（確認）を行い、承認を得るのが一般的です。

要件定義は、前工程である企画プロセスと混同されやすいため、違いを整理しておきましょう。

工程	主な目的	決めること
企画プロセス	システム化の方向性を決める	どの業務をシステム化するか、投資対効果はあるか
要件定義プロセス	システムに求める具体的な条件を決める	どんな機能が必要か、どの程度の品質が必要か

企画プロセスが「何をシステム化するか」という大きな意思決定であるのに対し、要件定義プロセスは「そのシステムに何を求めるか」を具体的に詰めていく工程です。

試験で出るポイント

「要件定義で行うことはどれか」という問題で、「システム化の費用対効果の評価」や「経営戦略との整合性の確認」は企画プロセスの内容です。要件定義では「利用者の要求を調査し、機能要件・非機能要件を定義する」ことが中心となります。