非機能要求

私は外見のデザイナーであると非難されてきた。先に機械があって、その外側を作っているだけではないかと。しかし、たいていの場合、外側が非常に重要である。外装のない機関車は動かないではないか。

─レイモンド・ローウィ

非機能要求の概要

非機能要求(NFR、もしくはシステム品質)は、安全性、信頼性、保守性、拡張性、使いやすさのようなシステム属性として説明される(「……性」と表現されることが多い)。非機能要求はシステム設計上の制約や制限になることもある(この場合、設計制約という名前で呼ばれるかもしれない)。これらの要求は、システム全体の使いやすさや有効性を保証するものであり、機能を実現するエピックや、システム能力、フィーチャー、ユーザーストーリーと同じくらい重要である。これらの要求のいずれかを満たさなければ、社内のビジネス部門やユーザーや市場のニーズ、あるいは監督官庁や標準機関に課された必須要件を、満たさないシステムになってしまうからである。

非機能要求は、永続的な品質や制約であり、機能要求とは違って、反復やプログラムインクリメントやリリースごとに「完了の定義」の一部として再確認されることが多い。NFRは、チーム、プログラム、価値のストリーム、ポートフォリオという、SAFeの4つのレベルすべてに存在する。

NFRの定義と実装は、システム構築者にとって非常に重要な懸案事項である。必要以上に条件を付けると、ソリューションのコストが高すぎて実現できなくなるかもしれない。あいまいなままであれば、ソリューションは意図した用途に適さないものになるだろう。NFRの調査、定義、実装を適用型のインクリメンタルな方法で行うことは、リーン-アジャイルなシステム構築を成功させるための重要なスキルである。

詳細

従来から、ソリューション全体の使用適合性に影響するすべての種類の要求について検討する1つの方法として、「FURPS」という頭字語が使われてきた。従来の要求の分類を表す機能(Functionality)、使いやすさ(Usability)、信頼性(Reliability)、パフォーマンス(Performance)、サポートのしやすさ(Supportability)である[5]。機能要求は主に、ユーザーストーリーフィーチャーおよびシステム能力で表現される。ほとんどの作業が発生するのはここである。チームは機能的な価値をユーザーにもたらすシステムを構築する。ソリューション開発の時間と工数の大部分は機能につぎ込まれる。

「URPS」は非機能要求を表す。機能要求ほど表に現れないかもしれないが、システムを成功させるには、NFRも同様に重要である。NFRは、新規開発に対する制約と考えることができる。それぞれがシステム構築者の設計の自由をいくらかずつ奪うからである。「スイート内の全プロダクトでSAMLベースのシングルサインオンを実装しなければならない」などがその例である(この場合、シングルサインオンは機能要求であり、SAMLの上に技術を構築することが制約である)。NFRは、機能要求ではうまく対処できないビジネス上の重要な課題を広くカバーすることができる。システム設計者への備忘録として、要求になり得る項目を幅広く網羅したリストが参考文献[1]に示されている。

NFRはすべてのレベルに存在する

図1に示すように、非機能要求はSAFeの4つすべてのレベルでバックログに関連付けられている。

図1.  NFRは4つすべてのレベルに存在する

NFRはアジャイルリリース列車価値のストリームが作成するソリューションの重要な属性なので、NFRがもっとも明確に現れるのはプログラムレベル価値のストリームレベルである。多くの場合、システムおよびソリューションアーキテクト/エンジニアリングがNFRの定義と洗練を担当する。

このようなシステムの特別な属性については、システムを作成しているすべてのチームが意識しておかなければならない。そうすると、NFRのテストを先延ばしするのではなく早く行うようになり、品質の作り込みのプラクティスが推進される。各チームは、関連するNFRを完了の定義に追加し、ローカルで設計や実装の意思決定をする際の制約として使用する。また、ある程度のNFRのテストは自分たちで実施する。そうでなければ、ソリューションが主要なNFRを満たさないかもしれず、プロセスの終盤で発覚した場合には修正コストが非常に高くなりかねない。

さらに、チームレベルのNFRも重要になることがある。作成するフィーチャーやサブシステムに制約やパフォーマンス要求を作り込むからである。

ポートフォリオレベルにも同様にある程度のNFRが必要だろう。シングルサインオンの例のように、システム横断的な性質を持つ品質の多くが該当する。その他にも、オープンソースの利用に関する制限、共通のセキュリティ要求、規制の標準などがある。ポートフォリオレベルの特定のNFRが達成できていない場合、それを実装するためにアーキテクチャーイネイブラーが必要になるかもしれない。あるいは、ポートフォリオレベルのNFRが、ビジネスエピックやイネイブラーエピックの成功基準に自然に含まれることもある。

バックログの制約としてのNFR

図2に示すように、SAFeでは、NFRを「バックログに対する制約」としてモデリングしている。

図2.  NFR制約の付いたバックログ

 

もっと厳密に言うと、SAFeの要求モデルでは、「NFRはゼロ複数、または多数のバックログ項目を制約することができる」と指定されている。さらに、システムが制約を満たしていることを確認できるよう、ほとんどのNFRには1つ以上のシステム品質テストが必要である(図3)。

図3.  バックログ項目、非機能要求、システム品質テストの間の関連

 

多くのNFRは、対処しなければならないイネイブラーの形で発生する。その後、NFRは、システムや進行中の新しいバックログ項目すべての制約となる。

NFRがソリューション開発に与えるシステム的/経済的影響

非機能要求がソリューションの開発やテストに大きな影響を与えることがある。NFRは仕様化するのが難しく、過剰になりがちである。たとえば「99.9999%の可用性」と書かれている場合、「99.999%の可用性」に比べて開発工数が1桁も2桁も増える可能性がある。それが必要な場合も必要でない場合もあるだろうが、仕様を書く際にはNFRの影響をよく理解しておかなければならない。同様に、重量、体積、電圧などの物理制約も、よく考慮しなければ、ソリューションが過剰に複雑で高価なものになりかねない。

ソリューションの経済的枠組みには、費用やその他の考慮事項とのトレードオフを考慮して、NFRをどの程度まで取り入れるかを評価する基準を含めるべきである。サプライヤーも同じようにNFRの影響を受けるため、正しく言明しなかった場合や経済的枠組みのトレードオフの悪影響を完全に伝えなかった場合には、システムやコンポーネントがいたずらに複雑になり、費用がかかってしまう。

NFRを定期的に見直すことも重要である。他の要求と違って、NFRはバックログに対して設定される永続的な制約であり、バックログ項目自体ではないため、PI計画策定時に取り上げられるとは限らない。しかし、非機能要求は開発中に変化するので、システム構築者は注意が必要である。

NFRとソリューションの意図

ソリューションの意図とは、ソリューションについての真実を含む唯一の情報源であり、そのため、機能要求だけでなく、NFRも含まれる。さらに、NFRと、NFRの影響を受ける要求、NFRの検証のために使われるテストとの間のリンクも含まれる。また、固定と変動のソリューション意図の経済性を理解するためにも、NFRは重要な役割を果たす。

図4.  ソリューションの意図

一部の機能は、早い段階では明確になっておらず、開発中にテストしたり顧客と交渉したりする必要がある。NFRにも同じことが言える。最初から固定であり、よく理解されているものもあるが、ソリューションと一緒に進化していくものもある。

NFRにより制約が課されるため、広い範囲のシステム機能に影響が及ぶ可能性がある。そのため、NFRはアジャイル分析の重要な要因となる。

  • ビジネスエピック、システム能力、フィーチャーの分析
  • アーキテクチャー滑走路の計画と構築
  • ソリューションのドメインに関する増加した知識を反映するためのリファクタリング
  • 製造、配置、サポート、インストール、保守性などのDevOps制約の追加

ソリューションの意図を作成するためのツールは、NFRを経済面に着目して定義し実装する方法を確立するためのある程度のメカニズムとなる。

  • アジャイルアーキテクチャー─確固とした意図的アーキテクチャーがあると、NFRの開発が楽になり、変化したときに柔軟性を保つのに役立つ。
  • モデルベースシステムエンジニアリング─モデルを使ってNFRの影響をシミュレーションしたり、検証のためのテストにリンクを張ったりすることができる。
  • セットベースの設計─セットベースの設計は、NFRを実現するための別の枠組みであり、設計の意思決定をサポートするためのエッジケーステストの指針となり得る。

非機能要求の定義

NFRを定義する際には、以下の基準を考慮するとよい。

  • 境界が設定されている。一部のNFRは、境界の設定されたコンテキストがないと無意味である(害になることすらある)。たとえば、性能に関する事項は、メインアプリケーションにとって非常に重要であっても、管理アプリケーションやサポートアプリケーションにとってはあまり意味がない(あるいは費用がかかりすぎる)かもしれない。
  • 独立している。NFRは互いに独立しているべきである。独立していると、他のシステム品質を考慮せずに、あるいは影響を受けずに、評価とテストができる。
  • 交渉可能である。NFRの背後にあるビジネス要因と取り巻くコンテキストを理解すると、交渉が可能になる。
  • テスト可能である。NFRには、客観的で測定とテストが可能な基準を記載しなければならない。テストできなければ出荷できないからである。

実装アプローチ

多くのNFRは、現在または将来にいくらか追加の仕事をしなければ、満たすことができない。すぐにNFRを実装しなければならない場合もあれば、インクリメンタルなアプローチで取り組むことができる場合もある。経済的枠組みで説明したトレードオフが実装アプローチに影響するはずである。複数の学習サイクルによってNFRの適切なレベルを突き止められるような方法で実装を行うべきである。

  1. 今すぐに。一部のNFRは、新しい、目前の課題として出現し、今すぐに対応しなければならない。たとえば、デリバティブ取引の新たな規制ができた場合、すぐに対処しなければ、会社が市場から完全に締め出される、あるいは、規制違反を引き起こす危険性がある。
  2. ストーリーごとにインクリメンタルに。チームに選択肢があることもある。たとえば「パフォーマンスを大きく向上する」というニーズは、図5に示すように、一度に1ストーリーずつ、徐々に対応することができる。
図5.  ソリューションにNFRをインクリメンタルに取り込む

NFRの実装方法は、ARTがどのように組織化されているかにも影響を受ける。アーキテクチャーのレイヤに合わせてARTが作られている場合は、NFRを全体として実装してテストすることが非常に困難である。システム能力を中心にARTが作られている場合、NFR全体の実装とテストと保守は、比較的容易である。

非機能要求のテスト

システムがNFRを満たしていることを確認するには、もちろん、テストをしなければならない。NFRのテストは、図6に示すアジャイルテストの4象限(参考文献[2]と[3])の観点から見るのが最も分かりやすい。

図6.  アジャイルテストの4象限(参考文献[2]と[3]から引用)ほとんどのNFRテストは第4象限のシステム品質テストに属する。NFRテストは範囲が広く非常に重要であるため、多くの場合、システムチームとアジャイルチームが協力する必要がある。これらのテストは可能な限り自動化して、予期せず技術的負債が増大することがないよう、継続的に(少なくとも必要に応じて)実行できるようにするべきである。

しかしながら、時間が経つにつれて(自動化した場合ですら)、回帰テストが累積的に増大し、必要なリソースや処理時間が大きくなりすぎる可能性がある。ひどい場合、現実的にはNFRテストをたまにしか実施できない、あるいは特別なリソースや人をつぎ込んで実施するしかないという状況になる。現実に継続して実施できるようにするには、図7に示すように、縮小版のテストスイートとテストデータを作成しなければならないことが多い。

図7.  システムチームとアジャイルチームが協力して現実的なNFRテスト戦略を作成する

 

「部分的なテスト」は理想的とは言えないかもしれないが、システム品質を向上するには実際に有益であり得る。

  • 縮小版のテストスイートをローカルで使用できれば、チームはテストデータやテスト方法の不整合を発見できるかもしれない。
  • チームは、独自に新しいテストを作成することができ、その一部がシステムチームによって採用されて、大きなセットを構築するのに役立つことがある。
  • テストのインフラと構成は、おそらく継続的に改善される。
  • チームはNFRの影響を実際に理解できる。その結果、ビジネスフィーチャーやアーキテクチャーフィーチャーの見積もり精度が向上する。

しかしそれでも、ときにはNFRをテストできる環境を日常的に利用できない場合がある(車両誘導ソフトのフィールドテストなど)。その場合には、以下の方法が役立つかもしれない[4]。

  • 仮想化されたハードウェアを利用する。
  • シミュレーターを作成する。
  • 類似の環境を構築する。

いずれにしても、非機能要求を効率的にテストするには創意工夫が必要である。逆にNFRテストがなければ、大きな技術的負債が生じるリスクが高くなったり、ひどい場合にはシステム障害を招くかもしれない。


さらに知りたい場合

[1] https://en.wikipedia.org/wiki/Non-functional_requirement

[2] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011. (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[3] Crispin, Lisa and Janet Gregory.Agile Testing:A Practical Guide for Testers and Agile Teams.Addison-Wesley, 2009.(邦訳:実践アジャイルテスト テスターとアジャイルチームのための実践ガイド、翔泳社、2009)

[4] Larman, Craig and Bas Vodde.Practices for Scaling Lean & Agile Development:Large, Multisite, and Offshore Product Development with Large-Scale Scrum.Addison-Wesley, 2010.

[5] Leffingwell, Dean and Don Widrig.Managing Software Requirements:A Use Case Approach (second edition).Addison-Wesley, 2003.

Last update:30 November 2015