非機能要件とは？システム開発における重要性を解説

1.　非機能要件とは

システム開発において機能案件と非機能要件と言うものが存在します。特に要件定義においては非常に重要で、理解していないと先に進めないことも珍しくありません。開発の事前に理解しておくと開発自体もスムーズに進みます。

そこでここからはシステム開発における非機能要件について詳しく解説します。システム開発における要件定義の詳細や機能案件との違いについても詳しく解説しているので、システム開発の際のご参考にしてください。

システム開発の要件定義

システム開発を行う際はいきなりシステム開発に入ることはできません。開発工程の前段階で、開発者の視点から要求をまとめ、発注側と受注側でシステム開発における詳細や工程を決める要件定義を行う必要があるからです。

この要件定義を細かく決めておかないと、システム開発において発注側と受注側の認識のズレが起こります。認識のズレが起きたまま開発をしてしまうと、ミスが発生した際に全体像が見えず、細かい工程もできていないので開発自体がストップすることもあり得るのです。そのため、安全にシステム開発を行うためにもシステム開発の際は要件定義が非常に重要となります。

システム要件定義の内容は、機能要件と非機能要件とに分けることができます。 機能要件とは、文字通り機能的な要件を指し、具体的にはシステムの操作方法や扱うデータの種類などがこれにあたります。

要件定義の中で「実装する機能」に関する要件になり、例えば、「自社の商品を購入したユーザーを分類して検索する機能」のように、実際にクライアントがシステムで使う機能は機能要件として分類されるのが特徴的です。

機能要件と非機能要件

一方、非機能要件は機能面以外の要件で、信頼性やセキュリティなどに関する記述を指します。 機能要件はユーザーからのヒアリングが比較的容易なのに対し、非機能要件はヒアリングで把握するのが難しいとされ、非機能要件によって要件定義が上手くいかずに多くのベンダーが頭を悩ませています。

そのため、ヒアリングを行う際は機能要件よりもさらに細かく聞き込み、発注側から情報を洗い出すことが求められます。実際に非機能要件のヒアリングが薄いと、要件定義の質も下がるので十分な注意が必要です。

非機能要件を含む要件定義・システム開発についてお悩みの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した方法、また対応可能な会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

2.　非機能要件の難しさ

非機能要件は要件定義を難しくする要素となっています。発注側がイメージしづらかったり、開発側との認識をあわせるのが難しかったりとややこしい部分が多く、要件定義の難易度を高めてしまうのが難点です。

そこで、ここからは非機能要件の難しさについて具体的に解説するので、システム開発を行う際はチェックしてみてください。

発注側がイメージしづらい

非機能要件が上手くいかない理由は様々ですが、大きな要因としては「イメージのしづらさ」が挙げられます。機能要件は開発されるシステムの性能や操作方法など、具体的なシステムに絡む項目なので理解しやすい ですが、非機能要件は運用する上での条件やセキュリティ対策などの副次的な項目が多く、システムとの関連性が薄く感じてしまうのです。

そのため、ヒアリングを行う際は発注側から情報が出てくるのを待つのではなく、受注側から積極的にヒアリングを行う必要があります。発注側がそもそも上手く非機能要件をイメージできていない場合もあるので注意すべきです。

ましてや、発注側がシステム開発に慣れていない場合はなおさらです。実際に自社のシステムにどのような非機能要件が必要なのか分からないこともあるので、受注側が積極的にアシストすることが重要になります。

システムの専門家である受注側から細かく提案を行うことで、発注側も気付けていなかった非機能要件に気づくことが可能です。発注側と受注側の認識のズレも防げるので、システム開発においては必ず意識しておきましょう。

開発側との認識をあわせるのが難しい

非機能要件はサービスが動く細かな内容で、利用イメージがわきづらく、受注側のOKの基準と発注側のOKの基準がズレる可能性があります。機能案件のように分かりやすさが無いのでなおさら注意が必要です。

そこで受注側と発注側の認識を合わせるためにも、文字だけのやり取りだけではなくイメージ図などを積極的に活用することがおすすめです。システム開発には難しい専門用語を用いる場面も多いので、より分かりやすいようにイメージ図を活用した方がスムーズに済むこともあります。

また、各非機能要件を提案する場合はどのようなメリット、デメリットがあるのか細かく説明する必要があります。開発側もメリット、デメリットが把握できた方がシステムのイメージを理解しやすくなるので認識のズレを防ぐ際におすすめです。

非機能要件など、システム開発についてお悩みの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した方法、また対応可能な会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

3.　非機能要件の項目

非機能要件の項目は単一ではなく、下記のように複数存在するのがポイントです。

• 可用性
• 性能・拡張性
• 運用・保守性
• 移行性
• セキュリティ
• システム環境

可用性

非機能要件における可用性とはシステムサービスを継続的に利用可能にするための要求を指します。基本的に開発したシステムは長く使われることが多いので、可用性を細かく詰める必要性が高いです。

要求の例としては運用スケジュール、稼働時間、障害、災害時における稼働目安が挙げられます。これらのスケジュールや目安をあらかじめ把握しておくことで、継続的にシステムを運用するイメージの構築が可能です。

実際に実現する際の方法としては使用する機器の冗長化やバックアップの準備、復旧や回復のための体制準備が挙げられます。これらの準備を整えておくことで可用性を実現できる可能性が高まるでしょう。

性能・拡張性

非機能要件における性能・拡張性の部分ではシステムの性能向上、将来のシステムの拡張性の追求を決めていきます。性能向上、機能拡張することでシステムはより使いやすくなるので、発注側と受注側で話し合う必要性が高いです

実際の要求の例としては業務量や将来の増加見積もり、システム化対象業務の特性などがあります。これらを把握しておくことで、どのくらいの予算になるのか、システム化対象業務の特性の詳細が分かるのがメリットです。

性能・拡張性を実現するためには性能目標値を正確に見積もること、将来へ向けた機器やネットワークの細かいキャパシティプランニングが必要です。しっかりと全体像を把握することで性能・拡張性の実現性を高める必要があります。

運用・保守性

非機能要件における運用・保守性ではシステムの保守性や運用面のサービスに関する要求がメインになります。実際にシステムを利用する上で保守性や運用面のサービスが整っていないと、いざという時にリカバリーが効かなくなってしまうでしょう。

要求の例としては運用中に求められるシステム稼働のレベル、問題発生時の対応レベルが挙げられます。これらの対応具合をお互いで把握することで、万が一の際の保守やリカバリー性が高まるのがポイントです。

運用・保守性を高める際には監視手段やバックアップ方式の確立、問題発生時の役割分担、体制、マニュアルの整備が必要です。これらのように事前に考えて準備しておくことで、スムーズな運用・保守が可能になります。

移行性

非機能要件においてはシステムの移行性も要求されます。実際には現行システム資産の移行に関する要求が組まれることが多く、発注側と受注側で細かく話し合うのが基本的な流れです。

新システムの移行期間及び移行方法を細かく決め、移行対象となる資産や移行量などを見ていきます。これらの全体像を洗い出すことで、よりスムーズなシステム移行が可能になるのです。

また、実際にスムーズにシステム移行を行う場合は移行スケジュールの立案、移行ツールの提案、移行する際の体制の確立、移行リハーサルの実現などを行うことが重要です。バックアップ体制まで整えておくと、よりリスクを抑えて移行性を高めることができます。

セキュリティ

非機能要件で近年重要になっているのがセキュリティ面になっています。セキュリティ面が充実していないと、万が一の際に企業の存続に関わることもあり得るからです。きちんと安全性を考慮して開発を進めないと、システムに脆弱性を抱えてしまうこともあるので注意が必要となります。

実際にセキュリティの要求では利用制限、不正アクセスの防止が重要になってきます。利用制限をして不正アクセスを防止できると、セキュリティ性が高まり、より安全なシステム運用に繋がるからです。

セキュリティ面を高める際にはアクセス制限、データの秘匿などが求められます。さらに不正の監視、追跡、運用スタッフのセキュリティ面の講習などもあると、さらに安全性の高いセキュリティ体制を築くことが可能です。

システム環境

システム開発や運用における法令・条約に触れる分野はないか等の確認、またシステム利用におけユーザー数の想定、アクセス数の想定などの管理・決定の項目です。

また、近年ではエコロジー性も重視されることが多く、工場などで利用されるシステムに関しては、非機能要件にて環境への配慮も含まれるようになりました。例えば耐震、免震、騒音、湿度、CO₂排出量、消費エネルギーなどの項目となります。細かい部分まで見られることが多いので注意が必要です。

4.　非機能要件の進め方・注意点

非機能要件の定義に失敗すると、後々大きな問題に発展することも珍しくありません。 非機能要件を漏れなく定義するには、各項目に関してユーザーにどう伝えるかをあらかじめシュミレーションしておくことが必要です。

それぞれの項目が何を示しているか、どれくらいの重要性があるか、どんな問題に繋がるかなど、 決めるメリットと決めないリスクを含めてまとめて伝えましょう。事前に準備しておけば、非機能要件に関してもヒアリングで聞き出すことが可能です。 後々のトラブルを避けてスムーズに開発を進めるためにも、念入りに打ち合わせを行いましょう。

特にIPAの非機能要求グレードを参考にする、モデルシステムの選定、レベルの決定など決めることは複数あるので注意が必要です。ここからは非機能要件の進め方・注意点について具体的に解説するので、要件定義の際にご参考にしてください。

IPAの非機能要求グレードを参考にする

まずは独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化センター（IPA）が公開している非機能要求グレードを参考にすると良いでしょう。実際に非機能要求グレードには下記のものが準備されています。

• 非機能要件一覧をまとめやすいシート
• モデルシステムごとのグレード表
• 活用シート
• 利用ガイド

モデルシステムの選定

非機能要件ではモデルシステムを選定することも求められることが多いです。モデルシステムとは実際に開発することを想定しているシステムに近い既存システムです。見本のようなものなので、システム開発の際はあると役立ちます。

実際に非機能要件を話し合う段階で、どのシステムをモデルにするか細かく決めていきましょう。このモデルシステムがないとシステム開発のイメージがしづらくなってしまうので注意が必要です。

発注側と受注側で何個か例を出し合うとスムーズに話し合いが進むでしょう。

レベルの決定

システム開発における非機能要件を話し合う際はレベルの決定も重要です。特に可用性に関わってくる部分になるので細かく話し合うことが求められるでしょう。実際には下記の5段階で決めるとスムーズに決まりやすいです。

レベル１：定時内（9時〜17時）
レベル２：夜間のみ停止（9時〜21時）
レベル３：1時間程度の小停止（9時〜翌8時）
レベル４：停止あり（9時〜翌8:55）
レベル５：24時間無停止稼働

このようにどのようなレベルで稼働するのか決めておくと、お互いでの開発イメージの共有がスムーズになります。

非機能要件を含むシステム開発についてお悩みの場合は、リカイゼンにお任せください！
リカイゼンでは、熟練のマッチングスタッフが、希望条件に応じて適した方法、また対応可能な会社候補を選定し、無料紹介いたします。
まずはご相談からでもお気軽にご連絡ください。

5.　非機能要件のまとめ

ここまで見てきたように、システム開発における非機能要件は重要性が高いのですが、具体的にイメージするのが難しいため、認識のすり合わせが苦戦しやすい項目となります。

発注者側のポイントとしては、システム開発を開発会社に丸投げしてしまうのではなく、発注している内容に合っているか、齟齬がないかを都度確認し、少しでも気になることがあれば開発会社と話しあい、細かく調整をしていくことがシステム開発の一番の近道になるでしょう。