エンジニア全般
システム開発を進める際、機能要件をハッキリさせることでスムーズな開発が可能になります。
しかし、機能要件とは一体何なのか、よく分かっていない人も多いでしょう。そこで本記事では機能要件について徹底解説していきます。
また機能要件と非機能要件の違いとは何かもわかりやすく解説していきますので、最後までご覧ください。
本業でシステムエンジニアをしています。 分かりやすい記事を心がけています。
機能要件とは
IT業界で仕事をしている時、特に要件定義や設計などの上流工程の仕事をしていると、機能要件と非機能要件という言葉が頻繁に話の中に出現します。
このうち機能要件について簡単に言うと、搭載すべき機能や開発するプログラムの挙動について顧客と合意した内容、ということになります。
何を目的に結成したプロジェクトなのかが、この機能要件を何にするかによってはっきりするため、前述したような上流工程の仕事をしているエンジニアだけでなく、マネージャーなどの管理職や経営者についてもこれらの言葉の意味を熟知しておく必要があります。
機能要件と非機能要件との違い
機能要件と非機能要件の違いについて、次の項目ごとに解説します。
- 定義
- 具体例
- 検証方法
- 優先度
| 項目 | 機能要件 | 非機能要件 |
| 定義 | システムがどのように動作するかについての具体的な要求事項。 | システムがどのように動作するかではなく、どのように動作するべきかについての要求事項。 |
| 具体例 | ECサイトでの商品検索機能、オンラインショッピングカートへの商品追加。 | システムの応答時間、セキュリティレベル、利用可能時間（アップタイム）、データ移行方法。 |
| 検証方法 | テストケースを作成し、一つ一つ検証 | 負荷テスト、侵入テストなど |
| 優先度 | 高く設定されることが多い | 軽視することはできない |
定義の違い
機能要件とは、システムが提供すべき具体的な機能を定義するものです。つまり、「システムは何ができるか」という質問に対する答えです。
例えば、オンラインストアであれば、「商品検索」、「カートへの追加」、「決済」といった機能が挙げられます。
機能要件は、システムの利用者が直接的に期待するものであり、ユーザーの要求を満たすために不可欠です。
一方、非機能要件は、システムがどのように機能すべきか、つまりシステムの品質や運用性を指します。
これは、「システムはどのように動作するか」という質問に対する答えです。
具体的には、性能（処理速度、応答時間）、セキュリティ、信頼性、可用性、拡張性などが挙げられます。
非機能要件は、システムの利用者が直接的に意識することは少ないかもしれませんが、システムの安定稼働やサービス品質の維持に大きく貢献します。
具体例
機能要件と非機能要件の具体例としてECサイトの例で考えてみましょう。
まずは、システムが提供する具体的な機能を定義する機能要件についてです。
ECサイトにおける機能要件には以下のようなことが挙げられます。
- 商品検索機能
キーワードやカテゴリ、価格帯などで商品を検索できる - カート機能
商品をカートに入れ、数量を変更したり、削除したりできる - 決済機能
クレジットカード、銀行振込など、様々な決済方法に対応できる - 注文履歴機能
過去の注文履歴を確認できる - お気に入り機能
商品をお気に入りリストに登録できる
一方、ECサイトにおける非機能要件には以下のようなことが挙げられます。
- レスポンスタイム
ページの表示速度が速い - 認証機能
ユーザーを認証し、不正アクセスを防ぐ - 稼働率
システムが長時間安定して稼働する - システムの稼働時間
システムが24時間365日稼働する - システムの変更容易性
システムの機能を追加・変更・削除するのが容易である
検証方法
機能要件は、システムが意図した通りの機能を提供しているか、テストケースを作成し、一つ一つ検証することで確認できます。
例えば、商品検索機能であれば、様々なキーワードで検索を行い、正しい商品が表示されるかを確認します。
非機能要件の検証は、機能要件よりも複雑です。
性能については、負荷テストを行い、システムが想定される負荷に耐えられるかを確認します。
セキュリティについては、侵入テストを行い、システムが外部からの攻撃に耐えられるかを確認します。
優先度の考え方
一般的に、機能要件はシステムの価値を直接的に決定するため、優先度が高く設定されることが多いです。
しかし、非機能要件もシステムの成功に不可欠であり、軽視することはできません。
例えば、非常に優れた機能を備えたシステムであっても、セキュリティに脆弱性があれば、利用者に大きな損害を与える可能性があります。
そのため、機能要件と非機能要件のバランスを考慮し、プロジェクトの状況や顧客のニーズに合わせて優先度を設定することが重要です。
機能要件のグレード分類
非機能要求は、IPA（情報処理推進機構）、 JISA（日本情報処理システム開発協会）が定めた項目があるため、この章ではそれらの項目について、それぞれ説明します。
IPA（独立行政法人 情報処理推進機構）による分類
IPA（独立行政法人 情報処理推進機構）による非機能要求グレードの分類は、システムの稼働と維持に必要な様々な要件を包括的に理解し管理するために設けられています。
可用性
可用性はシステムがどれだけ連続して稼働可能か、つまりダウンタイムがいかに少ないかを示す指標です。システムの冗長性を高めるために、バックアップサーバやデータベースの冗長化など、障害発生時の迅速な復旧策が必要です。
性能・拡張性
システムの応答時間や処理能力といった性能、将来的にユーザ数の増加や機能追加に柔軟に対応できるかという拡張性が含まれます。
運用・保守性
システムが日常的にどれだけ効率的に運用・保守できるかを示します。
具体的には、障害発生時の対応速度や保守のしやすさ、システムの監視方法などが含まれ、継続的な運用に欠かせない要素です。
移行性
既存システムから新システムへのデータや設定の移行が、どれだけスムーズに実行できるかに関わる要件です。
適切な移行計画と実行は、システム更改時のリスクを低減し、業務の連続性を保証します。
セキュリティ
システムが外部の脅威からどれだけ安全に保護されているかを指し、データの保護、不正アクセス防止策などが含まれます。
セキュリティは信頼性の高いサービス提供に直結し、ユーザの信頼を確保するためには不可欠です。
システム環境・エコロジー
システムが運用される物理的な環境やエコロジカルな要件に焦点を当て、エネルギー効率の良さや環境に優しい技術の使用などが評価されます。
これは、環境配慮の観点からも重要であり、コスト効率や企業の社会的責任（CSR）とも関連します。
JISA（日本情報処理システム開発協会）による分類
JUAS（日本情報処理システム開発協会）による機能要件のグレード分類は、システム開発において非常に重要な枠組みを提供しています。
機能性
システムが求められる機能を適切に提供できるかを評価する要素です。例えば、ECサイトであれば商品検索、カートへの追加、決済処理などがこのカテゴリに含まれます。
信頼性
システムが一定の条件下でどれだけ正確に、かつ連続して機能を果たすかを示します。
この要素は、エラーの回復やデータの正確性の保持に特に焦点を当てます。
使用性
ユーザーがシステムを簡単に使えるかどうか、またユーザーの満足度を考慮する項目です。
直感的なUIデザインやユーザーの学習曲線が低いかどうかがキーになります。
効率性
システムがリソースをどれだけ効率的に使うかを判断します。
これには処理速度やメモリ使用量が含まれ、高効率なシステムほど優れた評価を受けることができます。
保守性
システムの保守やアップデートがどれだけ簡単かを示します。
コードの可読性やモジュラリティが高いシステムは、変更やバグの修正が容易になります。
移植性
システムが異なる環境間でどれだけ簡単に移行できるかを示す要素です。
例えば、異なるオペレーティングシステム間での互換性がこの項目に含まれます。
障害抑制性
システムが予期しない問題や障害からどれだけうまく回復できるかを評価します。
これには、適切なエラーハンドリングと障害回復機能が含まれます。
効果性
システムがビジネスの目標やユーザーのニーズをどれだけ効果的に満たしているかを示します。
これは、システムが提供する価値と直接関連しています。
運用性
システムが日常的にどれだけ簡単に運用できるかを示します。
これには、管理の容易さや運用コストの低さが含まれます。
技術要件
システムの技術的側面が指定した要件を満たしているかどうかを示します。
これは、使用する技術やフレームワーク、プラットフォームの選定に関連しています。
機能要件の記載項目一覧と内容例
機能要件には画面などの表示物や帳票の内容、バッチの処理内容など、システムの目に見える部分やプログラムの動きに関わる部分を機能要件で記載します。
記載項目一覧
機能要件への記載項目の一覧を具体的に紹介します。
画面のレイアウトと操作
どのような画面があり、各画面で何ができるかを詳細に記述します。
帳票
システムが生成する報告書や書類のフォーマットと内容です。
バッチ処理
定期的または指定されたタイミングで実行されるバックグラウンドの自動処理です。
データ入出力
システムが扱うデータの入力方法と出力内容です。
システム間連携
他のシステムとのデータ連携の詳細です。
セキュリティ要件
データ保護とアクセス制御のための要件です。
機能要件の記載内容例
続いて、機能要件の記載内容例を紹介します。
画面
例えば、ECサイトの商品検索画面では、「商品をカートに追加する」「商品詳細を表示する」などの機能があります。画面レイアウト、使用する画像や文言、ユーザーが可能なアクションなどを記載します。
帳票
企業の経営状態を把握するための帳票で、「月間売上報告書」があります。この帳票には「売上高」「利益」「費用」などの項目が含まれ、どのデータベースのどのデータを基に集計するかを定義します。
バッチ
システムが毎夜自動で顧客データをバックアップする処理を行います。バッチ処理のスケジュール、実行するスクリプト、エラー発生時の通知方法などを記載します。
データ入出力
顧客管理システムで顧客の新規登録や情報更新を行う際の入力フォームの構造と、データベースへの書き込み方法を定義します。
システム間連携
製品管理システムと販売管理システム間でのデータ連携を例に、どのようにデータが交換されるか、どのフォーマットでデータが送受信されるかを記述します。
セキュリティ要件
ユーザー認証機能やデータ暗号化の要件を具体的に記載し、どのようなセキュリティ技術を用いるか、どのレベルのセキュリティが求められるかを明確にします。
機能要件定義書のサンプル
機能要件定義書のサンプルを以下に紹介します。
- 機能の説明
ユーザが入力したキーワードに基づいて、商品一覧から該当する商品を検索し、検索結果を表示する。 - 入力データ
キーワード（文字列）、カテゴリ（ドロップダウンリスト）、価格帯（数値範囲） - 出力データ
商品一覧（商品名、価格、画像、商品説明など） - 処理フロー
1. ユーザが検索ボックスにキーワードを入力し、検索ボタンをクリックする。… - エラー処理
キーワードが入力されていない場合、「キーワードを入力してください」と表示する。… - 関連機能
商品詳細画面、カート機能 - 優先度
高
上記は一例です。
実際の機能要件定義書では、より詳細な情報やシステムの特性に合わせた項目を追加する必要があります。
機能要件の書き方と手順
この章では機能要件の書き方について、幾つかの段階に分けて解説します。
手順1. 顧客要求のヒアリング
機能要件を書く時、一番最初に行うことが顧客要求のヒアリングです。このヒアリング結果を基にシステムの改修方針や開発方針が決まります。顧客から要求をヒアリングすると言っても全てを顧客任せにせず、こちらからも案を提案したり、試作品などを持って行く必要があります。
このようにすることで顧客の事情をより深く理解することができ、また話を深堀することができるため、顧客とのミーティングの成果が出やすくなります。
手順2. 機能洗い出し
機能洗い出しは、プロジェクトの初期段階で顧客とのヒアリングを通じて、必要なシステム機能を特定するプロセスです。この段階で、顧客のビジネス要件や期待を正確に理解することが重要です。
例えば、顧客が運営するオンラインストアの場合、商品の検索、カートへの追加、チェックアウト処理などの機能が必要になります。エンジニアやプロジェクトマネージャーは、ワークショップやインタビューを通じてこれらの情報を収集し、どの機能がシステムに不可欠かを判定します。
さらに、顧客の現在のワークフローや痛点を把握することで、改善すべき領域を明確にすることができます。
手順3. 機能定義
機能定義は、洗い出された機能要件を具体的かつ詳細に定義するプロセスです。ここでは、各機能がどのように動作するか、どのようなユーザーインターフェースが必要か、どの技術が利用されるかを詳細に記述します。
例えば、商品をカートに追加する機能では、どの情報が画面に表示されるべきか、どのボタンが必要か、クリック後のデータ処理の流れはどうあるべきかなどを定義します。
このプロセスは、後の設計や開発作業の基盤となるため非常に重要といえます。
手順4. 機能要件文書の作成
機能要件文書の作成では、定義された機能を文書化し、開発チームやステークホルダーに明確に伝えます。この文書は、プロジェクトの参考資料として使用されるため、わかりやすく正確に記述する必要があります。
文書には、機能の概要、ユーザーストーリー、画面のモックアップ、データフロー図などが含まれることが一般的です。これによって開発チームが要件を正確に理解し、設計と開発を効率的に進めることができます。
手順5. 機能要件文書をレビュー
機能要件文書のレビューは、文書がプロジェクトの目的と合致しているかを確認する重要なステップです。このレビューには、プロジェクトチームメンバーだけでなく、顧客や他のステークホルダーも参加することがあります。
レビューを通じて曖昧な点や不足している情報、技術的な誤りなどを洗い出し、修正を行います。レビューは通常、複数回にわたって行われ、文書が最終的に承認されるまで続けられます。
承認された要件文書は開発の基準として機能し、変更が必要な場合は適切な変更管理プロセスを通じて更新されます。
機能要件を作成する際の注意点
機能要件を定義する際、あいまいな理解のまま漫然と進めると、上手く要件定義ができずに時間と予算を無駄遣いしてしまうリスクがあります。ここでは機能要件の定義で気をつけるべきポイントを紹介します。
開発者は記述を明確にする
機能要件は、開発者がシステムを構築するための指針となるものです。
そのため、開発者が誤解なく理解できるよう、記述はできるだけ明確かつ具体的に行う必要があります。
- 専門用語の使用を控える
業務に携わる人以外には理解しにくい専門用語は避け、一般的な言葉で表現しましょう。 - あいまいな表現を避ける
「できる限り」「早い段階で」といった曖昧な表現は避け、「5秒以内に」「3営業日以内」など、数値や具体的な条件で記述します。 - 例示を用いる
抽象的な概念は、具体的な例を用いて説明すると理解が深まります。 - 図や表を活用する
複雑な処理やデータ構造は、図や表を用いて視覚的に表現すると、より伝わりやすくなります。
要件は検証可能な内容を含める
機能要件は、最終的にシステムが正しく動作しているかを確認するためのテストケースを作成できるような、検証可能な内容で記述する必要があります。
例えば、具体的な数値目標の設定であれば、「処理速度が速い」ではなく、「1秒以内に処理を完了する」のように、具体的な数値目標を設定します。
各機能に対して、どのようなテストケースを作成すれば良いのかがイメージできるような記述にします。
優先順位を設定する
すべての機能を同時に開発することは現実的ではありません。
そのため、機能ごとに優先順位を設定し、開発の順番を決定する必要があります。
顧客にとって最も重要な機能から開発を進めるとともに、開発リスクを考慮することが重要です。
技術的に難易度が高い機能や、多くのリソースを必要とする機能は、後回しにすることも検討するようにしましょう。
一貫性を保持する
機能要件は、システム全体で一貫性のある記述が求められます。
例えば、同じ概念に対して、異なる用語を使用しないようにすることで用語の統一を行います。
そのほかにも、機能の説明や入力・出力データの記述形式を統一します。
関連する機能との整合性をとることで、他の機能との関連性を考慮し、矛盾のない記述にします。
トレーサビリティを確保する
トレーサビリティとは、要件がどのようにシステムに実装され、テストされたかを追跡できる状態のことです。
具体的には各機能に固有の番号を付与し、変更履歴を管理します。
その他にも、機能要件と設計書、テストケースを紐付けることで、トレーサビリティを確保します。
まとめ：機能要件でシステムの必須機能を明確にしましょう
以上のように上流工程と言っても、その内容は非常に多岐に渡るものとなっています。受注側はただIT技術がわかるエンジニアを大量に集めてくるだけでなく、担当を割り振りチームを組ませてそれぞれの進捗を管理するなど、マネージメントに関連した仕事も多くなります。
発注側の立場からしても、機能要件と非機能要件の違いなど、気をつけなければならないことが数多くあります。システム開発を行うという仕事は、開発側にも受注側にも一定以上の経験やノウハウが必要となりますし、近年ITエンジニアの需要が急騰しているため、経験のあるエンジニアを集めるのも非常に多くのコストがかかります。
しかし、株式会社Jitera社でしたら事業計画の策定や成長戦略の立案からリリース後の保守運用のことまで責任をもってサポートをしてくれるうえに、優秀なエンジニアが在籍しています。従ってもしシステム開発でわからないことが生じた場合、株式会社Jiteraに1度お問い合わせしてみることをお勧めします。
