はじめに
エンジニアのみなさま、日々の学習本当にお疲れ様です！
また本記事まで足を運んでいただき本当に感謝です。
約3分程度で読めるので最後まで読んでもらえると幸いです。
先週、要件定義の記事の投稿をしました。時間あればぜひ読んでみてください。
今回は「非機能要件」の 可用性 性能・拡張性 運用・保守性 移行性 セキュリティ システム環境・エコロジー の6項目について理解を深めてアウトプットしようと思います。
非機能要件｜6項目について
1. 可用性
システムが継続して利用可能な状態を維持する能力を指します。『稼働率』 で表現されます。システムは定期メンテナンスや予期しない障害により、一時的に利用できなくなることがあります。可用性は、稼働している時間と停止から復旧までの時間の割合で決まります。たとえば、Amazonの「Amazon ECS」サービスは 『99.99%』 の稼働率を保証しており、24時間365日の稼働の場合、1年間で業務が中断する時間の合計が 『52.6分』 の想定になります。このような高い可用性を実現するためには、冗長化やバックアップ体制が必要ですが、それに伴いコストも増加します。
システム導入時には、求められる可用性を明確に定義することが重要です。基幹業務システムでは短時間の停止が許容されることもありますが、ECサイトなどでは高い可用性が求められます。可用性には、稼働率に加え、メンテナンスの影響や障害時の復旧手順も含まれます。事前に計画されたメンテナンスが利用者に与える影響を最小限に抑えることが、可用性向上に寄与します。
2. 性能・拡張性
性能はシステムの動作やパフォーマンスを指し、データ量や処理速度が業務に適合 するか、通常時とピーク時の応答速度 を考慮します。例えば、伝票照会画面は通常3秒以内、ピーク時は5秒以内の応答をするなどです。最近のサイトやwebサービスは表示速度がかなり速くなっているためユーザの目もかなりその速さに慣れてしまっています。そのため、『顧客が考える速さ』と『提案側が提供する速さ』のすり合わせは早い段階で対応した方が良いと考えます。
拡張性は 将来の業務量の増加に伴う性能向上の可能性 を示します。具体的な 性能要件（処理能力やレスポンスタイムなど）や拡張性要件 を定め、システム設計時に考慮することが重要です。例えば、同時利用者数やデータ負荷に耐えられるかを確認し、ハードウェアの配置やスケーラビリティを設計に組み込むことで、トラブルを防げます。システム稼働後に問題が発生するとハードの配置やスケールの内容により、想定外のコストが発生してしまいます。問題を避けるためには、初期のデータ量やユーザー数の予測は必ず顧客とすり合わせる必要があります。
3. 運用・保守性
システムの運用や保守に必要な要件を指します。具体的には、システムの運用時間や障害監視の仕組み、バックアップの範囲・頻度、計画的な停止の有無、異常検知時の対応策 などが含まれます。個人的には異常検知時の対応は明確に決める必要があると考えます。異常検知時にどの部分が異常なのかを切り分ける術がない場合、開発者の作業としてはかなり骨が折れます。一方で検知する箇所を増やしてしまうとコストが発生するため、顧客と折り合いをつける必要があります。
これらの要件は BCP（事業継続計画） とも関連し、システムが障害時にも業務を継続できるよう、適切な計画が必要です。また、運用マニュアルや手順書に要件を組み込むことで、運用時の役割分担や手順が明確になります。全体として、運用・保守性はシステムの安定性と効率性を確保するための重要な要素です。
4. 移行性
旧システムから新システムへの移行の容易さを表す要件です。この移行には、 システム停止期間、移行方法、計画、トラブル時の対処 などが含まれます。移行中のシステム停止期間を最小限に抑えるためには、詳細な移行スケジュールの検討が不可欠です。具体的には、移行期間やシステム停止の可能日時、並行稼働の有無を検討します。
また、移行対象の資産としてマスターデータやトランザクションデータが含まれ、安全に移行できるかどうか、負担はどの程度かも重要な要素です。さらに、クライアントへの周知やリハーサルの実施、作業分担の明確化も、スムーズな移行を実現するための重要なステップです。この検討が曖昧になるケースが多いため、これらの要素を総合的に考慮することで、システム移行の成功率を高めることができます。
5. セキュリティ
システムの安全性を確保するための重要な要件で、特に リスク管理 において中心的な役割を果たします。システムへの不正アクセスを防ぐためには、 認証機能やアクセス制限、データ暗号化が不可欠 です。これにより、機密情報への適切なアクセス制限が実現し、不正なアクセスを効果的にブロックできます。
加えて、セキュリティのリスク分析や診断も重要です。ネットワークやWeb診断を通じてシステムの脆弱性を特定し、必要なセキュリティパッチを適用することでリスクを軽減します。マルウェア対策や不正監視も不可欠で、これらの対策を講じることでデータ漏洩や不正アクセスのリスクを最小限に抑えることができます。
6. システム環境・エコロジー
システムの構築や運用における法令や条約、利用者数や拠点数、ハードウェアの制限事項を考慮した目標設定 が求められます。システムの運用が労働環境や自然環境に与える影響も重要な検討対象であり、特にデータセンターのサーバを使用する際には、消費エネルギーの目標値設定が必要です。
さらに、 消費電力、CO2排出量、耐震性能、騒音性など、環境への配慮 が求められます。『こんな事まで決めないといけないのか！』と思うくらい大変です...これらの要素はコンプライアンスとも関連するため、慎重な定義と適切な基準の適用が不可欠です。
非機能要求グレードについて
「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。
※IPA（独立行政法人 情報処理推進機構）より抜粋
ドキュメントはこんな感じです。全部で238項目あります...
決めること多すぎる。
上記サイト内の下段にある
非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)
からドキュメントを取得することができます。
システムの規模によると思いますが、上記ドキュメントを顧客と共有しながら会話をすることで、非機能要件の6項目に対して抜け漏れなく対応できると考えます。
一方で顧客の担当者は当然ながら他業務もあるため、全ての項目を回答するとかなり負担が大きいです...過去の案件を見ていると、非機能要件に時間をかけて検討できることはほとんどない印象です。そのため、システムの要件を聞きながら 『必ず決めてほしい項目』 のみ事前に伝え、余裕があれば他の項目も検討していくのも手かと考えます。
さいごに
非機能要件は要件定義の段階では顧客もイメージしづらい項目になります。加えて、システムを運用してから見えてくる部分が多いため、提案する側はさまざまな実例を伝える。特に 『考慮が足りない場合にどのような苦労や課題が発生するか？』 を伝えながら顧客側にできる限り負担がかからない様に検討・判断いただく工夫が必要かと考えます。
参考記事（勉強になりました。ありがとうございます）
おまけ
弊社のご紹介もさせてください！
「日本で一番エンジニアが成長できる会社を創る」
エンジニアリングの募集
PM・Webディレクションの募集
セールス・事業開発の募集
コーポレート系の募集
コンサルティングの募集
弊社メンバーは日々学習した内容をアウトプットしております！
少しでもご興味を持たれた方は求人を見てみてください！
ご応募もお待ちしております！