品質属性の柱
- 松井 淳
- 2018年11月12日
- 読了時間: 7分
品質の重要性は、システムやソフトウェアの開発では大変古くから議論されてきました。DX（デジタルトランスフォーメーション）の時代と言われる近年、ますますその重要性は高くなる一方といえます。IPAが発行する「つながる世界のソフトウェア品質ガイド」では、その背景として３つの要因をあげています。
１．多様化する利用者の期待(註1)
機能を正しく動かすことが主要な品質という従来の考え方から、安全性やセキュリティはもとより、快適さや楽しさ、高度なビジネス貢献というように多様化しています。
２．多岐にわたるステークホルダー(註2)
製品そのものが複雑化かつ高機能化したことで、その製品に関わる多様な利用者の存在など、考慮すべきステークホルダーは確実に増えています。
３．つながるシステムの拡大(註3)
「つながるシステム」として利用者に価値を提供するような形態が増えていることで、関連する全ての要素が確実に品質要求を満たしている必要があります。
また同時に、システムの複雑さも高まる一方といえます。このように複雑化するシステムの品質を考えたとき、全ライフサイクルに適用される多様な品質要求をシステム要件としてとりまとめ、その効果と経済性のバランスをとりつつ具現化していくことには、極めて高い専門性が求められます。ここに、品質属性への高い専門性を備えたITアーキテクトが必要となる理由があります。
さて、「品質属性の柱」を見ていきましょう。ITABoK全体に目を通してまず気づくのは、「アーキテクチャの5つの柱」とそれに続く「アーキテクチャの専門領域」のほぼ全ての広範な範囲に「品質属性」という言葉が登場していることです。「品質属性の柱」はITアーキテクトの活動全般において必要となる横断的なスキルといえそうです。
ITABoKであげられている「品質属性の柱」を構成するケイパビリティは次の7つです。
品質属性の調整と最適化
マネージャビリティ、メンテナンス性、サポート性、拡張性、柔軟性
モニタリングとマネジメント
パフォーマンス、信頼性、可用性、拡張性
セキュリティ
ユーザビリティ、ローカリゼーション、アクセシビリティ、パーソナライズ/カスタマイズ性
パッケージング、提供、ポスト・デプロイメント
特にセキュリティに関して多くのページを割いている点は興味深いです。ITABoKによると、セキュリティは「普遍的な」品質特性の１つであり、たとえ小規模でシンプルなものでも全てのシステムに存在しています（註4）。冒頭で述べた「つながる」システムへの潮流から、今後ますます重要性が高まる品質属性といえるでしょう。
また、利用されないシステムは、ビジネスにとってはもとよりシステム運用にとっても大きな負債となります。よって、パフォーマンスやユーザビリティのようなシステムの利用者にとっての品質も重要な品質属性であり続けるでしょう。
パッケージング、提供、ポスト・デプロイメントは、近年のDevOpsの潮流によって大きくクローズアップされた領域といえます。ビジネスの俊敏性を高めていくために、欠かせない品質となってきたという認識が必要です。
経験あるITアーキテクトなら十分理解されていると思いますが、場合によっては品質属性の定義は非常に困難を極めるものとなります。しかしながら、品質属性を定義することはITアーキテクトにとって重要な責務であることを、強調しておきたいと思います。
続いて、上位３つのケイパビリティを掘り下げてみます。
最初にあげられるケイパビリティは「品質属性の調整と最適化」です。ITABoKでは、『ITプロジェクトから最適なパフォーマンス、ユーザー・エクスペリエンス、投資対効果を提供するために必要となる、基本的な戦略と戦術の適用』と説明されています（註5）。ITアーキテクトが品質を定義するとき、制約のない理想的な状況が与えられることはまずありません。そこには必ず、組織面や財務面での制約や前提があります。また、品質属性間のトレードオフも意識すべきです。よって、このケイパビリティなくしてITアーキテクトの定義する品質属性がステークホルダーの承認を得られることはないでしょう。
ITABoKによると、『この課題を成功裏に進めるための鍵の１つは、いかに良くITアーキテクトがサービスレベル要件を把握したかに依存する』とされています（註6）。多様なステークホルダーから、いかにして真の要求を引き出すか。「ヒューマン・ダイナミクスの柱」のスキルとあわせて活用することがITアーキテクトに求められると考えられます。
次にあげられるケイパビリティが「管理容易性、メンテナンス性、サポート性、拡張性、柔軟性」です。この品質属性は、運用のためにデザインされたソリューションがシステムに組み込まれることを保証します。ITABoKによると、ソリューションのコストの20％がデザインとデリバリーの期間に生じ、残りの80％がソリューションの生涯を通してのメンテナンスに費やされます（註7）。「運用期間にわたって費用対効果の高いシステム」であることは、ビジネスの視点から不可欠といえます。ITアーキテクトが説明責任を果たす際に、経営者やユーザーに理解できる言葉で、開発の初期コストだけでなく長期的なランニングコストの妥当性を語れることは、強固な信頼関係を築く上で必要なことといえます。
テクノロジーの視点で見ても、この領域はクラウド技術を中心に新しいソリューションが日進月歩で進化しており、企業にとって選択肢は広がってきています。しかし、こうしたソリューションを実際に導入することに、ハードルの高さを感じる組織は多いのではないでしょうか。その理由として、システム運用、ビジネス／業務や開発の一体となった理解と協力が必要にも関わらず、これらの橋渡しの役割を果たす人材があまりにも少ないように思います。その点を考えると、本ケイパビリティを備えたITアーキテクトが活躍できる機会は、今後ますます広がっていくと考えられます。
「モニタリングとマネジメント」について考えてみましょう。ITアーキテクトは品質属性を定義することと同様に、品質属性をモニタリングし、マネジメントすることの重要性を認識する必要があります。ITABoKでは、『品質属性に関しては、私達は特定の品質属性を自らのソリューションに組み込む事に神経を使っていますが、それらがどの様にモニターされるかには強い関心を抱いていない様に見えます。一般的に、私達はソリューションがどの様に管理、維持され、終了を迎えるかにはあまり関心を向けません。』と書かれています（註8）。マネジメントされない品質属性は、評価することも改善することもできません。品質属性が最終的にビジネス要求を満たせているかどうかを追跡できるメカニズムを導入し、監視、評価、そして改善していくサイクルをまわすための仕組みを作っておくことは、ITアーキテクトの責務であるといえるのではないでしょうか。
今回は「品質属性の柱」を取り上げました。皆さんも日々の実践において、品質の重要性と難しさを感じておられるのではないでしょうか。最後に、皆さんへの質問で本コラムを締めたいと思います。
獲得／表現／合意されない要求は実現されることはありません。皆さんの開発組織では、品質要求は表現できていますか？「誰から」「どのタイミングで」「どういう品質要求」を獲得すれば、必要十分なシステム要件として取りまとめることができるとお考えでしょうか？さらにこうした品質要求の適切な表現方法とはどういったものでしょうか？
皆さんの意見やコメントをお聞かせください。
註）
つながる世界のソフトウェア品質ガイド、「1.1 多様化する利用者の期待」P.8
つながる世界のソフトウェア品質ガイド、「1.2 多岐にわたるステークホルダー」P.9
つながる世界のソフトウェア品質ガイド、「1.3 つながるシステムの拡大」P.11
ITABoK Version2 日本語訳版、「2.1.5.4 セキュリティ」P.208
ITABoK Version2 日本語訳版、「2.1.5 品質属性の柱」P.199
ITABoK Version2 日本語訳版、「2.1.5.1 品質属性の調整と最適化」P.200
ITABoK Version2 日本語訳版、「2.1.5 品質属性の柱」P.199
ITABoK Version2 日本語訳版、「2.1.5 品質属性の柱」P.199
Comments