非機能要件とは、システムがどのように機能すべきかではなく、どのような品質を持って機能すべきかを示す要件です。以下は非機能要件の一般的なカテゴリとそれに関連する要点です。
非機能要件一覧
| カテゴリ | 詳細 |
| 性能要件 | 応答時間: 画面のロード時間やデータベースのクエリ応答時間など。 スループット: 単位時間あたりのトランザクション数や処理数。 負荷: 同時接続ユーザ数、ピーク負荷時の性能など。 |
| 可用性 | システムの動作時間、停止時間、維持・管理の頻度や時間。 |
| スケーラビリティ | システムが将来の負荷増加に対応できる能力。 |
| 信頼性 | システムの障害率や復旧時間。 |
| セキュリティ | データ保護、認証・認可、アクセス制御、暗号化、監査機能など。 |
| 保守性 | ソースコードの理解や変更が容易か、再利用可能かなど。 |
| 移植性 | 異なる環境やプラットフォームへの移動の容易さ。 |
| ユーザビリティ | インターフェースの使いやすさ、学習の容易さ、エラーメッセージの明瞭さなど。 |
| 障害回復 | システム障害やデータロスからの復旧策。 |
| バックアップ | データの定期的なバックアップの方法や頻度。 |
| コンプライアンス | 法律、規格、規約などの要求に準拠していること。 |
性能要件
性能要件の確認と判断に関して、以下に一般的なアプローチと考慮点を示します。
要件収集の段階での確認
- ステークホルダーとの対話: ビジネスサイドやエンドユーザーから直接要件を収集する。
- ビジネスゴールの理解: たとえば、ウェブサイトの場合、ページのロード時間が1秒を超えるとユーザーの離脱率が上がるといったゴールを持つかもしれません。
- 競合分析: 類似のシステムやサービスがある場合、その性能をベンチマークとして設定する。
性能テストの実施
- 負荷テスト: システムにある程度の負荷をかけて、その応答を観察します。
- ストレステスト: システムの限界まで負荷をかけて、その限界を特定します。
- エンドユーザーのシミュレーション: 実際のユーザーシナリオをシミュレーションしてテストします。
モニタリングツールの使用
- 実運用中のシステムの性能をリアルタイムで監視するツールを使用して、問題を早期に発見し対処します。
判断基準
- 合意された基準: ステークホルダーと合意した基準に対して、テスト結果が適合しているか。
- システムの応答時間: 例えば、ウェブページのロード時間やAPIの応答時間。
- システムの限界: 何人のユーザーまで対応できるか、どの程度のデータ量を処理できるかなど
- リソースの使用率: サーバーのCPUやメモリの使用率、データベースのクエリ性能など。
継続的な評価
- システムやアプリケーションのアップデート、新しい機能の追加など、変更があるたびに性能テストを再度行い、性能要件が満たされているかを確認します。
具体的な性能要件の数値や判断基準は、プロジェクトの内容や業界、使用する技術、ステークホルダーの要求に応じて異なります。したがって、実際のプロジェクトにおいては、関連するステークホルダーとのコミュニケーションを通じて詳細な要件を定義し、継続的に評価・調整していくことが重要です。
可用性
システムが利用可能な状態である時間の割合を指し、通常パーセンテージで表現されます。特にミッションクリティカルなシステムでは、高い可用性が求められることが多いです。
- 可用性の計算可用性は以下の式で計算されます：
Availability=((Total time−DowntimeTotal time)／DowntimeTotal)×100%例えば、1年間のうち24時間だけシステムがダウンしていた場合：
Availability=((365×24−24)／(365×24))×100%≈99.73% - 現場での確認方法
- 監視ツール: システムのアップタイムを監視し、ダウンタイムやサービス中断を迅速に検出するためのツールを使用します。
- 定期的なヘルスチェック: システムやサービスの健康状態を定期的に確認し、問題が発生した場合に速やかに通知する仕組みを持つ。
- 障害シミュレーション: 意図的に障害を起こして、システムの復旧時間や手順の有効性をテストする。
- 判断基準
- SLA (Service Level Agreement): サービス提供者とユーザー間で合意されたサービスレベルを示す文書。例えば、99.9%の可用性を保証するという内容が含まれることがあります。
- 業界のベンチマーク: 業界標準や競合他社のサービスレベルを参考にする。
- ビジネスの要求: ビジネスの性質やリスクを考慮して、必要な可用性レベルを定義する。
- 追加の考慮点
- 冗長性: システムの一部が故障した場合でも、他の部分が機能を担うことで可用性を維持する。
- ディザスタリカバリ: 大規模な障害からの復旧策や手順を準備しておく。
- バックアップ: データの損失を防ぐための定期的なバックアップ。
現場での可用性の確認や判断基準は、システムやサービスの性質、ビジネスの要求、技術的な制約など、多くの要因に影響されます。したがって、関連するステークホルダーとのコミュニケーションを通じて、正確な要件や期待値を共有し、適切な手段で確認・評価を行うことが重要です。
スケーラビリティ
システムが増加する負荷に適応できる能力を指します。具体的には、ユーザー数の増加、データの増加などの成長や変化に対して、システムが適切に機能し続ける能力を意味します。
- 現場での確認方法
- 性能テスト: 負荷テストやストレステストを実施し、現在のシステムがどれくらいの負荷まで対応できるかを確認します。また、システムの拡張後に同様のテストを行うことで、スケーラビリティを評価することができます。
- 垂直・水平スケーリングのテスト: システムやインフラストラクチャのリソースを増やしたときの性能改善を確認します。
- モニタリング: システムのキー指標（CPU使用率、メモリ使用率、ネットワークトラフィックなど）を監視し、トレンドを分析して将来的なスケーリングの必要性を予測します。
- 判断基準
- ビジネス要件: 事業の成長予測や戦略に基づいて、将来必要とされるスケーラビリティを定義します。
- 業界標準: 似たようなシステムやアプリケーションのスケーラビリティ基準やベンチマークを参考にします。
- コスト: スケーラビリティを高めるためのコスト（インフラ、開発、運用など）と、それによって得られる利益や価値のバランスを考慮します。
- 技術的制約: 使用している技術やプラットフォームのスケーラビリティの制約を考慮します。
- 追加の考慮点
- アーキテクチャ: マイクロサービス、サーバーレスなどのスケーラブルなアーキテクチャを採用することで、システムのスケーラビリティを向上させることができます。
- データベースの設計: データベースのシャーディングやレプリケーションなどの戦略を適切に採用することで、データの増加に対応します。
- クラウドサービス: オンデマンドでリソースを拡張できるクラウドサービスを利用することで、スケーラビリティの問題を緩和することができます。
スケーラビリティの確認や判断は、システムやビジネスの特性、技術的な制約、コストなど多岐にわたる要因を考慮する必要があります。従って、関連するステークホルダーとの密接なコミュニケーションを通じて、要件や目標を明確にし、適切な手段で確認・評価を行うことが重要です。
信頼性
システムが期待される機能を正確に、そして中断なく提供する能力を指します。高い信頼性は、システムのダウンタイムが少なく、エラーが発生した場合でも迅速に復旧できることを意味します。
- 現場での確認方法：
- 障害注入: テスト環境や本番環境において意図的に障害を引き起こす（例: ネットワークの切断、サーバーのシャットダウン）ことで、システムの耐障害性や復旧手段を確認します。
- モニタリング: システムの正常性を常に監視し、異常やエラーが発生した場合に速やかに通知を受け取ることで、システムの信頼性を確認します。
- バックアップとリストア: データのバックアップとリストア手順を定期的にテストして、データ復旧の可靠性を確認します。
- 判断基準：
- SLA (Service Level Agreement): 信頼性に関する具体的な指標や基準がSLAに明記されている場合が多いです。
- 過去の履歴: 過去のダウンタイムの記録や障害発生時の復旧時間をもとに、信頼性を評価します。
- 業界標準: 同じ業界や市場の競合他社と比較して、自社のシステムの信頼性がどの程度であるかを判断することができます。
- 追加の考慮点：
- 冗長性: システムのコンポーネントが故障した場合にもサービスを継続できるように、冗長な設計やインフラを持つことは信頼性の向上に寄与します。
- 自動復旧: システムが自動的にエラーを検出し、修復手順を実行する能力を持つことは、手動介入なしでの迅速な復旧を可能にします。
- 定期的なレビュー: システムの信頼性を継続的に向上させるため、定期的にシステムの設計やインフラ、運用手順をレビューします。
信頼性の確認や判断には、システムの構成や運用、そしてビジネスの要求など、多岐にわたる要因を考慮する必要があります。関連するステークホルダーとの緊密なコミュニケーションを通じて、信頼性の要件や目標を明確にし、それに基づいて適切な手段で評価を行うことが重要です。
セキュリティ
情報やシステムを悪意のある攻撃や不正アクセスから守ること、およびデータの機密性、完全性、可用性を確保する能力を指します。セキュリティは多岐にわたる要因に影響されるため、定期的な確認と評価が不可欠です。
- 現場での確認方法：
- 脆弱性スキャン: 自動化ツールを用いてシステムの脆弱性を定期的にスキャンし、潜在的なセキュリティリスクを特定します。
- 侵入テスト: 専門家が攻撃者の立場でシステムを攻撃し、セキュリティの弱点を明らかにします。
- セキュリティレビュー: システムやアプリケーションの設計・コードをレビューし、セキュリティのベストプラクティスが守られているか確認します。
- ログの監査: システムやアプリケーションのログを定期的に監査し、異常なアクセスや活動を検出します。
- 判断基準：
- 法的・規制の要件: GDPR、PCI DSSなどの法的・規制の要件を満たしているか確認します。
- 業界標準: OWASP Top Tenなどの業界標準を参考にして、システムのセキュリティを評価します。
- 過去のインシデント: 過去のセキュリティインシデントやその対応を基に、システムのセキュリティ状態を評価します。
- リスク評価: 潜在的なリスクとその影響を評価し、リスクを受け入れるか、対策を講じるかを判断します。
- 追加の考慮点：
- 教育とトレーニング: 社員や関係者にセキュリティ意識を高めるための研修やトレーニングを実施します。
- アクセス管理: 最小権限の原則に基づき、ユーザーやシステムのアクセス権限を制限します。
- 多要素認証: システムやデータへのアクセスに多要素認証を導入することで、セキュリティを強化します。
- 定期的なアップデート: オペレーティングシステム、アプリケーション、ライブラリなどのソフトウェアを定期的にアップデートし、既知の脆弱性を修正します。
セキュリティの確認や判断には、システムの特性、ビジネスの要求、外部の脅威など、多岐にわたる要因を考慮する必要があります。関連するステークホルダーとの緊密なコミュニケーションを通じて、セキュリティの要件や目標を明確にし、それに基づいて適切な手段で評価を行うことが重要です。
保守性
システムやソフトウェアが将来の変更や修正を容易に受け入れることができる度合いを指します。高い保守性を持つシステムは、変更のコストが低く、エラーが発生しにくい特徴があります。
- 現場での確認方法：
- コードレビュー: 定期的なコードレビューを通じて、コードの品質や構造の良さを評価します。
- ドキュメンテーションの確認: システムやソフトウェアのドキュメンテーションが適切に整備されているか確認します。良好なドキュメントは保守性を向上させる要因となります。
- 技術的負債の評価: 未解決の問題やコードの改善点を特定し、それがシステムの保守性にどれほどの影響を与えているかを評価します。
- 変更や追加の容易性: 新しい機能の追加や既存機能の変更がどれほど容易に行えるかを実際に試すことで、保守性を評価します。
- 判断基準：
- コードの複雑性: コードの複雑性を測定するツールを使用して、ソフトウェアの複雑性を評価します。高い複雑性は保守性を低下させる可能性があります。
- 再利用性: コードやコンポーネントが再利用される度合いを評価します。再利用性が高いと、保守性も向上します。
- テストのカバレッジ: テストカバレッジを測定することで、システムの品質や保守性を評価します。
- 依存関係: 外部ライブラリやサービスへの依存度を確認し、それが保守性に与える影響を評価します。
- 追加の考慮点：
- コーディング標準: コーディング標準やガイドラインを定義・遵守することで、コードの一貫性を保ち、保守性を向上させることができます。
- 継続的インテグレーション (CI): CIツールを使用して、コードの変更を自動的にテストし、問題点を早期に検出します。
- アーキテクチャの柔軟性: システムのアーキテクチャが変更や拡張に柔軟であるかを評価します。
保守性の高いシステムは、長期的な運用コストを削減し、迅速な対応や変更を可能にします。システムの設計や開発の初期段階から、保守性を考慮することが重要です。
移植性
ソフトウェアが異なる環境やプラットフォームでの動作や適用を容易に行える性質を指します。移植性が高いソフトウェアは、多様な環境での利用や将来的な技術変更への対応が容易となります。
- 現場での確認方法：
- 環境変更のテスト: 異なるOS、デバイス、ブラウザ、データベースなどの環境でソフトウェアをテストし、動作の確認を行います。
- 依存性の確認: ソフトウェアが依存しているライブラリやフレームワークが、異なる環境で利用可能かを確認します。
- ソースコードの解析: プラットフォーム依存のコードや特定の環境に特化したコードの有無をチェックします。
- 判断基準：
- プラットフォーム依存のコード: ソフトウェアにプラットフォームや環境固有のコードが少ないほど、移植性が高いと言えます。
- 外部ライブラリの利用: 汎用的で広くサポートされているライブラリやフレームワークの利用は、移植性を向上させる要因となります。
- 設定とコードの分離: 環境固有の設定を外部ファイルや環境変数として分離して管理している場合、移植性が高まります。
- ドキュメンテーション: 移植に必要な手順や考慮事項がドキュメントに明確に記述されている場合、移植性の評価が容易となります。
- 追加の考慮点：
- 自動化: 環境のセットアップやデプロイメントを自動化するツールを利用することで、移植性を向上させることができます。
- コンテナ技術: DockerやKubernetesのようなコンテナ技術を利用することで、アプリケーションとその実行環境を一緒にパッケージ化し、移植性を向上させることができます。
- クロスプラットフォームの開発ツール: React NativeやFlutterのようなクロスプラットフォーム対応の開発ツールを利用することで、複数のプラットフォームに対して一つのコードベースで開発を行うことができます。
移植性を重視するかどうかは、ソフトウェアの要件や目的に応じて異なりますが、高い移植性を持つソフトウェアは、技術的な変更や市場の動向に柔軟に対応することができます。
ユーザビリティ
製品やサービスがユーザーにとってどれだけ使いやすく、効果的、効率的にタスクを完了できるかを示す指標です。高いユーザビリティを持つ製品やサービスは、ユーザーに好まれ、成功する可能性が高まります。
- 現場での確認方法：
- ユーザーテスト: 実際のユーザーや潜在的なユーザーを対象に、製品やサービスを使用してもらい、その反応や意見を収集します。
- ヒューリスティック評価: 専門家が製品やサービスを評価し、ユーザビリティのガイドラインやベストプラクティスに基づいて問題点を特定します。
- アンケートや調査: ユーザーから直接、製品やサービスの使いやすさに関するフィードバックを収集します。
- アイ追跡: ユーザーが製品やサービスを使用する際の視線の動きを追跡し、どの部分に注目しているかを解析します。
- 判断基準：
- 効率性: ユーザーが目的を達成するのに必要な時間や手間が最小限であるか。
- エラーレート: ユーザーが誤操作をする頻度や、エラーから回復するのにかかる時間。
- 学習性: 新しいユーザーが製品やサービスを使いこなすまでの時間や労力。
- 満足度: ユーザーが製品やサービスを使用した後の満足度や好感度。
- 記憶性: 一度学習した後、時間が経って再度使用する際の手間や再学習の必要性。
- 追加の考慮点：
- アクセシビリティ: すべてのユーザー、特に障害を持つユーザーにとっても使いやすいかどうか。
- デザインの一貫性: 同じ操作や情報が、製品やサービス全体で一貫しているか。
- フィードバック: ユーザーのアクションに対するシステムの反応やフィードバックが適切であるか。
ユーザビリティは、製品やサービスの成功に直結する要素であり、ユーザーのニーズや期待をしっかりと理解し、それに応じて設計や改善を行うことが重要です。
障害回復
システムやデータが大規模な障害や災害によって失われた場合に、それらを正常な状態に戻すためのプロセスや手段を指します。障害回復は、ビジネスの継続性を保ち、データの損失やサービスの中断を最小限に抑えるために非常に重要です。
- 現場での確認方法：
- DRテスト: 実際に障害シナリオをシミュレーションし、障害回復プロセスを実施してその効果をテストします。
- 復元時間目標 (RTO) の確認: 事業が中断された場合、システムを復旧するまでの時間を計測します。
- 復元ポイント目標 (RPO) の確認: データ損失の許容範囲を確認します。どの時点のデータまで復旧できるかを評価します。
- バックアップの確認: バックアップデータが正確に、そして定期的に保存されているかを検証します。
- システムの冗長性確認: システムの冗長構成やフェイルオーバー機能が適切に動作するかをテストします。
- 判断基準：
- RTOの達成: 定められたRTO内にシステムが復旧できるか。
- RPOの達成: データ損失が定められたRPO内に収まっているか。
- 完全復旧: 障害前の状態に完全に復旧できるか。
- 手順の明確性: 障害回復の手順が明確で、迅速に実行できるか。
- 関連ドキュメント: 障害回復の手順や連絡体制などが文書化され、関係者に共有されているか。
- 追加の考慮点：
- 定期的なレビュー: 障害回復計画は定期的に見直しを行い、最新のビジネス要件や技術環境に合わせて更新することが必要です。
- 関係者の訓練: 障害が発生した際の対応をスムーズに進めるため、関係者への訓練やシミュレーションを行うことが重要です。
障害回復の確認や評価は、実際の障害が発生する前に十分に準備をしておくことが重要です。そのため、定期的なテストやドリルを行い、障害時の対応能力を高めておく必要があります。
バックアップ
データの損失や破損、システムの障害などの予期せぬ事態から、データを保護・復元するための手段として非常に重要です。以下は、バックアップに関する現場での確認方法と判断基準を示しています。
- 現場での確認方法：
- バックアップデータの復元テスト: バックアップデータが正常に復元できるかを定期的にテストします。
- バックアップログの確認: バックアップが計画通りに実行され、エラーがないかを確認するためのログの検証。
- バックアップの頻度の確認: 日次、週次、月次など、バックアップの実施頻度が適切かどうかを確認します。
- バックアップの格納場所の確認: オンサイト、オフサイト、クラウドなど、バックアップデータが適切な場所に保存されているかを検証します。
- バックアップのタイプ: 完全バックアップ、差分バックアップ、増分バックアップなど、使用されているバックアップのタイプを確認します。
- 判断基準：
- 復元の成功率: バックアップデータからの復元が、確実かつ速やかに行えるか。
- データの整合性: バックアップデータが破損していないか、データの整合性が保たれているか。
- RPO (復元ポイント目標) の達成: 最後のバックアップからのデータ損失が、ビジネスの許容範囲内に収まっているか。
- バックアップの速度: バックアップの実行にかかる時間が、設定されたウィンドウ内に収まっているか。
- 保存期間の遵守: 法的または業務上の要件に基づき、バックアップデータが適切な期間保存されているか。
- 追加の考慮点：
- バックアップの暗号化: データの機密性を保護するため、バックアップデータが暗号化されているか。
- バージョン管理: 複数のバージョンのバックアップが利用可能で、特定の時点のバージョンを復元できるか。
- 通知機能: バックアップの完了やエラーに関して、適切なステークホルダーに通知が行われるか。
バックアップの取り組みは、ビジネスの継続性やデータの保護を担保するための基本的な措置です。定期的な確認やテストを行い、変化するビジネス要件や技術環境に合わせてバックアップの戦略を見直すことが重要です。
コンプライアンス
法律、規則、規定、業界の基準など、様々な規範への遵守を指します。特にビジネスやITの文脈では、データ保護、金融取引、業界特有の規制など、多岐にわたる要件が存在します。以下に、コンプライアンスの確認方法と判断基準を示します。
- 現場での確認方法：
- 内部監査: 組織内部の専門チームがコンプライアンスの遵守状況を評価します。
- 外部監査: 第三者の専門機関がコンプライアンスの遵守状況を確認します。
- ドキュメンテーションの確認: コンプライアンスに関連するポリシー、手順、訓練資料などの文書を検証します。
- トレーニングと教育: 従業員がコンプライアンス関連の教育やトレーニングを受けているかを確認します。
- 技術的監査: セキュリティ設定、データアクセス権限、ログの管理など、技術的な遵守状況を確認します。
- 判断基準：
- 規範の遵守: 法律、規則、業界の基準など、関連するすべての規範に遵守しているか。
- 障害の発見: 内部・外部監査での障害や違反が発見されたか、またそれが適切に対処されているか。
- ドキュメンテーション: コンプライアンス関連の文書が完全で最新であるか。
- 教育の完了: 全従業員が必要なコンプライアンス関連の教育やトレーニングを受けているか。
- 技術的対策の実施: 適切なセキュリティ対策やデータ保護策が施されているか。
- 追加の考慮点：
- コンプライアンスプログラム: 組織がコンプライアンスを継続的に遵守するためのプログラムや体制が整っているか。
- 情報の透明性: コンプライアンス関連の情報がステークホルダーに対して適切に開示されているか。
- 継続的な改善: コンプライアンスの遵守状況を定期的に評価し、必要に応じて改善活動を実施しているか。
コンプライアンスは、法的なリスクを軽減するだけでなく、組織の評価や信頼の向上にも寄与します。したがって、組織はコンプライアンスの確認と評価を継続的に行い、変化する規範や環境に対応していく必要があります。
コメント