基本情報 平成22年度 秋期 問64｜ストラテジ系に関する問題

答えは b「システム開発で利用する言語に合わせた開発基準，標準を作成する」 です。

システムの要件は2種類あります。

• 機能要件：システムが「何をするか」（業務の流れ、システム化する範囲、他システムとのやり取り…）
• 非機能要件：「どんな品質・条件で作り、動かすか」（性能、信頼性、セキュリティ、開発のルール…）

b の「開発言語に合わせた開発基準・標準」は、何をするかではなくどう作るかの決まりなので非機能要件です。

👉 覚え方：「機能＝何をする／非機能＝どう作る・どう動く」。

ほかの選択肢：a 機能間のデータの流れ／c システム化する機能の範囲／d 他システムとのインタフェース は、どれも「何をするか」を決める機能要件。

なぜこれが正解か

正解は b。機能要件が「システムが実現すべき機能（業務の処理・データ・外部との連携）」を定義するのに対し、非機能要件は「その機能をどのような品質・制約のもとで実現するか」を定義する。性能、信頼性、セキュリティ、運用・保守性、移行性に加え、開発に使う言語や開発基準・標準といった開発上の制約も非機能要件に含まれる。b は開発言語に合わせた開発基準・標準の作成なので、非機能要件の定義に該当する。

各選択肢の解説

• a：業務を構成する機能間の情報（データ）の流れを明確にするのは、業務機能を整理する機能要件の定義。
• b：開発言語に合わせた開発基準・標準の作成は、開発上の制約条件＝非機能要件（正解）。
• c：システム機能として実現する範囲（どの業務をシステム化するか）を決めるのは機能要件の定義。
• d：他システムとの情報授受のインタフェースは、システムがやり取りするデータと機能の定義なので機能要件。

覚え方・ひっかけ注意

非機能要件の代表分類（IPA「非機能要求グレード」）：(1) 可用性（稼働率、復旧時間）、(2) 性能・拡張性（応答時間、スループット）、(3) 運用・保守性（バックアップ、監視、保守時間）、(4) 移行性（旧システムからの移行）、(5) セキュリティ（認証、暗号化、ログ）、(6) システム環境・エコロジー（消費電力等）。「機能=動詞、非機能=形容詞」と品詞でイメージ。

理論的背景

非機能要件はISO/IEC 25010（旧ISO/IEC 9126、製品品質モデル）の8品質特性で構造化される：(1) 機能適合性（functional suitability：完全性、正確性、適切性）、(2) 性能効率性（performance efficiency：時間効率、資源効率、容量）、(3) 互換性（compatibility：共存性、相互運用性）、(4) 使用性（usability：適切認識、習得性、運用性、ユーザエラー保護、UI美しさ、アクセシビリティ）、(5) 信頼性（reliability：成熟性、可用性、障害許容性、回復性）、(6) セキュリティ（security：機密性、インテグリティ、否認防止、責任追跡性、真正性）、(7) 保守性（maintainability：モジュール性、再利用性、解析性、変更性、試験性）、(8) 移植性（portability：適応性、設置性、置換性）。日本ではIPA「非機能要求グレード」で6大項目237項目の網羅的チェックリストが提供される。

実務での使われ方

クラウド時代の非機能要件：(1) SLA（Service Level Agreement、稼働率99.99%等）の数値化、(2) SRE（Site Reliability Engineering）のSLO/SLI設定、(3) コスト最適化（FinOps、リザーブドインスタンス、Spot利用）、(4) GreenOps（CO2排出最適化）、(5) オブザーバビリティ（Metrics/Logs/Traces、OpenTelemetry標準）、(6) 災害復旧（RTO/RPO設計）、(7) コンプライアンス（GDPR、PCI DSS、HIPAA、各種業界規制）。アーキテクチャ意思決定記録（ADR）で非機能要件のトレードオフ判断を可視化する文化が広がる。Well-Architected Framework（AWS、Azure、GCP）は非機能要件評価のチェックリストとして実務標準。

試験での位置づけ

FE科目Aで機能/非機能の区別が頻出。応用情報・システムアーキテクト・ITストラテジストでは非機能要件定義の具体的記述、優先順位付け、トレードオフ分析（ATAM: Architecture Tradeoff Analysis Method）、品質特性シナリオ作成が論述対象。プロジェクトマネージャでは非機能要件の管理計画、変更管理プロセス、ステークホルダ合意形成が問われる。

選択肢の発展補足

要件工学のフレームワーク：ボレム（Wiegers）の要件管理プロセス、RUP（Rational Unified Process）の要件ワークフロー、INVEST原則（Independent/Negotiable/Valuable/Estimable/Small/Testable、アジャイル）、FURPS+（Functionality/Usability/Reliability/Performance/Supportability+設計/実装/インタフェース/物理）。UX要件は近年特に重視され、HEART Framework（Google：Happiness/Engagement/Adoption/Retention/Task success）、Jobs-To-Be-Doneでユーザの本質的ニーズを捉える。ESG要件（環境・社会・ガバナンス）も非機能要件に組み込まれる傾向で、システムのカーボンフットプリント測定、サプライチェーンの人権配慮も対象。AI/ML要件は新領域で、公平性（Fairness）、説明可能性（Explainability、XAI）、頑健性（Robustness、敵対的サンプル耐性）、プライバシ保護（Differential Privacy、Federated Learning）が非機能要件として整理されつつある。FE午後やITストラテジスト論述で具体事例ベースで頻出。