機能要件とは？非機能要件との違いや決定ステップ、注意点を解説
- DX
Introduction
システムを開発する際に重要なのは、開発技術や設計手法、開発ツールや環境などの優劣だと思われがちですが、実はそうともいいきれません。優れたシステムを開発するためには、機能要件を詳細に漏れなく定義することが重要です。
機能要件とは、情報システムが提供する機能に関する要件のことで、開発の最初に定義します。この機能要件が明確に漏れなく定義されなければ、そのあとの工程で優秀なシステムエンジニアやプログラマーが開発を担当しても、品質が確保されたシステムをつくるのはむずかしいでしょう。機能要件を決める工程は、システム開発のなかでもっとも重要な工程といえるのです。
この記事では、機能要件とは何か、非機能要件との違いや機能要件の決定ステップ、機能要件決定時の注意点について解説します。
目次
機能要件とは
ここでは、機能要件とはどういうものか、非機能要件との違いについても解説します。
業務の実現のために情報システムが提供する機能に関する要件
機能要件とは、システム開発時に顧客やユーザーから求められる機能のことを指します。たとえばECサイトのシステムであれば、ログイン認証機能、商品選択機能、個人情報などの登録機能、決済機能、履歴閲覧機能などが最低限必要です。このような機能をまとめたものが、機能要件です。
財団法人 地方自治情報センター（現：J-LIS 地方公共団体情報システム機構）の『非機能要求グレード（地方公共団体版）利用ガイド』によると、以下のように定義されています。
機能要件
機能要件とは、例えばどのような情報を入力し、どのような処理を行い、結果どのような出力がされるか、といった業務の実現のために情報システムが提供する機能に関する要件である。
システムを開発する際には、顧客やユーザーから求められる機能を満たすことがもっとも重要です。顧客やユーザーが求めるシステムを開発するためには、機能要件を明確に洗い出して、詳細に定義しなければなりません。
設計や製造の段階で、スキルが高く経験豊富なエンジニアが開発を担当しても、肝心の機能要件が適切に洗い出されていなければ、顧客やユーザーが求めるシステムの開発はむずかしいでしょう。
機能要件と非機能要件との違い
システムを開発する際は、機能要件だけでなく、非機能要件についても明確にしておく必要があります。
非機能要件とは、顧客やユーザーが求める目に見える形の機能ではなく、処理速度やレスポンススピードなどの性能要件、セキュリティ要件、拡張性、移行性、環境要件などがあります。
システムを快適に利用するためには、処理速度やレスポンススピードが適切に維持されていなければなりません。そのためには、無駄のないアルゴリズム、データ構成、サーバーやネットワーク構成などを設計する必要があります。
また、セキュリティ要件、今後のユーザーの増加や機能追加などを考慮した拡張性、サーバーから発せられる騒音やCO2などに関する環境要件などの検討を行うことも重要です。
このように、顧客やユーザーが求める機能とは別に、さまざまな観点で非機能要件を明確にしておかなければなりません。
非機能要件についてはこちらもご覧ください。
＞＞非機能要件とは？機能要件との違いや設計方法、設計のポイントについて解説のページへ
機能要件と非機能要件の主な項目・具体例
ここでは、機能要件と非機能要件の具体的な項目についてご説明します。
機能要件の主な項目と事例
機能要件にはさまざまなものがあり、開発するシステムやその目的によって内容は大きく異なります。
たとえば美容院の予約サイトを開発する場合は、美容院の紹介ページ、会員ログインページ、マイページ、メニュー選択・予約機能、決済機能、過去の利用履歴機能、コメント機能、メールによるリマインド機能など、さまざまな機能が必要です。
場合によっては、過去の利用履歴からおすすめメニューをレコメンドする機能、キャンペーンお知らせ機能、SNSとの連動機能なども必要かもしれません。
このように、システムに必要とされるありとあらゆる機能を洗い出し、どのような機能にするかを検討する必要があります。
非機能要件に該当するカテゴリ例
独立行政法人 情報処理推進機構（IPA）の『非機能要求グレード』によると、非機能要件は以下のように定義されています。
・可用性
継続性、耐障害性、災害対策、回復性などに分類されているのが特徴です。たとえば、継続性では、システムの運用スケジュールや稼働時間、業務の継続性、災害からの復旧水準などを定義します。万が一、災害が発生した場合の復旧を想定しているかについて、明確にします。
可用性についてはこちらもご覧ください。
＞＞可用性とは？信頼性・耐障害性との違いや助長化する方法を解説のページへ
・性能・拡張性
通常時、業務量増大時を想定し、ユーザー数や同時アクセス数、データ量などの性能を満たしているか、拡張性はあるかなどについて明確にします。また、オンラインレスポンス、バッチレスポンスなど、性能の目標値を定めます。
・運用・保守性
運用時間やデータのバックアップ、運用監視、運用保守のための計画停止、運用負荷削減、障害時の運用、サポート体制などの非機能要件を定義します。
・移行性
旧システムから新システムへデータの移行が発生する場合には、移行時期、移行方式、移行対象、移行計画などについて定義します。
・セキュリティ
情報セキュリティに関するコンプライアンスを定め、セキュリティ診断、セキュリティリスク管理、アクセス・利用制限、データの秘匿、不正の追跡監視、ネットワーク対策、Web対策などについて定義します。
セキュリティ診断についてはこちらもご覧ください。
＞＞脆弱性診断（セキュリティ診断）とは？実施する目的や種類、ツールの選び方をわかりやすく解説のページへ
・システム環境・エコロジー
システム特性、適合規格、機材設置環境条件、環境マネジメントなどについて定義します。
機能要件の決定ステップ
機能要件を決定していく際には、漏れなく必要な要件を洗い出して決定するために必要なステップがあります。ここでは、機能要件の決定ステップについて解説します。
ステップ1：ユーザーの操作フローを洗い出す
まずはユーザーがシステムも含めて、業務や操作をどのような流れで行うのか、操作フローを洗い出します。ユーザーがどのような操作をどのような順番で行うのかを可視化することで、必要な機能が見えてくるのです。
たとえば美容院の予約サイトを利用する場合、ユーザーはスマホをとり出してサイトにアクセスし、ログインしてメニューを選び、日にちと時間を選択して予約を行います。では、キャンセルする場合はどうするか、メールで連絡を受けとってそこからアクセスするパターンもあるなど、あらゆる操作フローを洗い出します。
また、ユーザーは美容院の顧客だけではなく店側のサイト管理者もいるでしょう。予約内容を管理して、管理者権限で削除や変更をする場合もあります。
このように、さまざまな操作フローが浮かびあがってくるため、すべてを洗い出すことが重要です。
ステップ2：必要な機能を一覧化する
上記で洗い出された操作フローをもとに、必要な機能をリストアップします。
ログイン認証機能、メニュー・日時選択機能、予約機能、変更・キャンセル機能、メールお知らせ機能、管理者メニュー機能、コメント機能など、必要な機能を一覧化します。
ステップ3：機能ごとの詳細要件を整理する
上記でリストアップした機能の詳細な要件を整理して、明確に定義します。
たとえば、ログイン画面のレイアウトを決め、ID・パスワードで認証し、ワンタイムパスワードを払い出すなど、機能を定義します。パスワードを間違えた場合の処理、ロックアウトの処理などについても詳細に決めるのが特徴です。
ステップ4：優先度と開発段階を決める
上記のとおり各機能を定義すると、開発の規模が大まかに決まります。ここでプロジェクト全体の予算や納期、リソースなどを考慮し、どの機能を優先させるかを決め、段階的に開発を進める場合はその計画を立てます。
たとえば、ログイン機能、メニュー・日時選択機能、予約機能、管理者メニュー機能は最低限必要なため優先度が高いです。それ以外の変更・キャンセル機能、メールお知らせ機能、コメント機能などは後回しにするなどと計画を立てていきます。
機能要件の書き方と注意点
機能要件を定義する際に気をつけるべき注意点についてまとめました。
「何をするか」「誰が使うか」を明確にする
具体的に何をするか、誰が使うのかを明確にしなければ、適した機能要件の洗い出しや定義ができません。
たとえば上記の美容院予約サイトの例では、顧客がスマホの扱いに長けた若い女性なのか、あまりデジタルが得意ではない高齢者なのかによって機能の内容が変わってきます。若い女性ならスマホで予約しやすいレイアウトにして、高齢者向けなら大きい文字でわかりやすい画面やボタン配置にする必要があります。
曖昧な表現を避ける
機能要件を定義する際には、抽象的で曖昧な表現を避けます。
たとえば美容院予約サイトの例であれば、予約メニューと日時を選ぶなどと書くと、どういう順番なのか、同時に選ぶのかなど、機能の詳細がはっきりしません。そのため、メニュー選択画面でメニューを選択して次の画面に進む、日時選択画面でカレンダーから日時を選択するなどと明確に定義する必要があります。
担当が変わっても理解できる内容で書く
機能要件に限りませんが、要件定義書や仕様書、設計書などを書く際には、担当者が変わっても理解できる書き方で書く必要があります。担当者が変わると要件定義書の内容が理解できなくなってしまう場合、チーム内や顧客との共有もむずかしく、後工程の担当者にも内容が伝わらないでしょう。
発注側と受注側の合意形成を丁寧に行う
機能要件に書かれたことは、システム開発の発注側と受注側が内容を確実に理解して合意する必要があります。ここで書かれた内容を実現するため、システム開発の全体を決める重要な合意です。ここで発注側と受注側の認識の乖離や誤解が生じないよう、確認しあわなければなりません。
まとめ
機能要件とは、システム開発時に顧客やユーザーから求められる機能のことを指します。たとえばECサイトのシステムであれば、ログイン認証機能、商品選択機能、個人情報などの登録機能、決済機能、履歴閲覧機能などが最低限必要です。このような機能をまとめたものが、機能要件になります。
システム開発において、機能要件は最初に決めるもっとも重要な部分です。どのような開発手法を選ぶにせよ、機能要件や非機能要件の洗い出しと定義は、開発工程のなかでもっとも重要な工程といえるでしょう。
開発手法にはさまざまな種類がありますが、従来の方法では顧客やユーザーからの要望をとり入れにくいと悩むケースも多いかもしれません。その場合には、新しいことをとり入れやすい開発手法に変えていく必要もあるでしょう。顧客からの要望に柔軟に対応しやすく、変化に強い開発手法には、アジャイル開発があります。
アジャイル開発を導入して、顧客のニーズや仕様変更に柔軟に対応できる開発を行いたい場合は、SHIFTのアジャイル開発支援（SHIFT 1LINE）をご活用ください。お客様のアジャイル内製開発体制の構築とプロジェクト推進において、開発・ITガバナンス・プロダクトデザインなど、すべての局面で強力にサポートいたします。
継続的なプロダクト開発に伴走する、SHIFTのアジャイル開発支援
「顧客の要望を迅速にとり入れられるアジャイル開発の手法を導入したい」「アジャイル開発手法を導入して顧客満足度の高い製品を開発したい」「アジャイル開発を導入したいが、社内にノウハウがない」などの悩みを抱えている企業様は多いかもしれません。
アジャイル開発は、従来のウォーターフォール開発と比べると、比較的新しい開発手法です。短いスパンの開発を繰り返すため、機能変更や機能追加に柔軟に対応できるというメリットがあります。
しかしアジャイル開発をスムーズに進めるためには、設計、実装、テストという短いスパンを繰り返して、つねにフィードバックを繰り返す必要があるため、豊富な専門知識や経験、ノウハウが必要です。アジャイル開発に関する知識やノウハウがない状態で、アジャイル開発にシフトするのはむずかしいでしょう。
そこで、SHIFTのアジャイル開発支援（SHIFT 1LINE）をご活用いただければ、お客様のアジャイル内製開発体制の構築とプロジェクト推進において、開発・ITガバナンス・プロダクトデザインなど、すべての局面で強力にサポートいたします。
短期的な人材確保や長期的な人材育成など、お客様のニーズにあわせて対応し、お客様のシステム開発に柔軟性とスピードをもたらします。
監修
永井 敏隆
大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。
担当講座
・コンポーネントテスト講座
・テスト自動化実践講座
・DevOpsテスト入門講座
・テスト戦略講座
・設計品質ワークショップ
など多数
――――――――――
ヒンシツ大学とは、ソフトウェアの品質保証サービスを主力事業とする株式会社SHIFTが展開する教育専門機関です。
SHIFTが事業運営において培ったノウハウを言語化・体系化し、講座として提供しており、品質に対する意識の向上、さらには実践的な方法論の習得など、講座を通して、お客様の品質課題の解決を支援しています。
https://service.shiftinc.jp/softwaretest/hinshitsu-univ/
https://www.hinshitsu-univ.jp/
――――――――――
この記事を書いた人
ご支援業種
- 製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント
など多数
