## ITシステムの品質確保の考え方は？

*ITシステムにおける品質とは、想定したことが想定通り動作する度合い*のことをいいます。仮に、仕様通り作成されたシステムでも、*操作方法が使いにくかったり、エラー処理が複雑だったりするもの*は、**ユーザの満足度が低下**します。この状態では、高品質のシステムとは言えません。ここでは、ITシステムにおける品質に関して、開発者側とユーザ側での対応を解説します。

開発者は、ユーザの満足度を高めるために**品質特性**を考えて、*企画・設計・開発・テストを進めます*。*品質特性とは、ソフトウェアの品質を評価する基準*のことで、ISO/IEC 9126(JIS X 0129)に定義されています。ISO/IEC 9126(JIS X 0129)では、以下の6つの特性と、それぞれの品質特性をさらに細分化した21の副特性が定められています。**以下が6つの品質特性です**。


◆ *機能性*(Functionality)
　目的から求められる必要な機能の実装の度合いで、想定条件の下で要求仕様を満たす能力
◆ *信頼性*(Reliability)
　想定条件の下で機能が正常動作し続ける度合いで、障害の起こりにくさの度合い
◆ *使用性*(Usability)
　ソフトウェアの想定動作に関して、利用者に対する分かりやすさ、使いやすさの度合い
◆ *効率性*(Efficiency)
　与えられた条件で、目的達成のために使用する時間や資源の度合い
◆ *保守性*(Maintainability)
　保守作業や改修作業に対する、必要なコストの度合い
◆ *移植性*(Portability)
　別の環境へ移した際、移植のしやすさや、そのまま動作する度合い

ユーザ側は、*業務システムに実装したい要求を、要求仕様としてまとめていきます*。同様に、運用に必要な各種要求についても要望として整理します。特に、レスポンス時間保証が求められるシステムや、システムダウンの影響を最小化する場合は、**動作品質の十分な考慮が必要**となってきます。ユーザ側で開発を主導する場合はこのような内容をもとに検討していきます。

*テスト工程は、要求発生から納品までの流れに従ってステップ化*していきます。その際は品質特性を意識したチェック項目を作成し、**品質基準をクリアする判断**を進めていきます。

開発者はユーザ側から要求を受けてから、以下の**ステップに従って、開発工程を進めていきます**。まず*要求分析*(Requirements analysis)の工程で、ユーザの要求を理解するために、ユーザから要望書である*要求仕様書を入手*します。続いて*要件定義*(Requirement definition)の工程で、ユーザの要求が実装可能なIT要素で実現できるかどうかを確認し、*要件定義書*として作成します。

次に、*基本設計*(Basic design)の工程で、要件定義書の記載事項に基づき、*外部設計仕様*として設計していきます。さらに、*詳細設計*(Detailed design)の工程では、基本設計書の各項目に対応する開発を想定し、*設計の詳細化*を進めていきます。その後の詳細工程では、*開発・製造*(Development / Manufacturing)で、詳細設計の項目・ルールに従い、*モジュールの開発・製造*を行います。

上記の開発工程の品質を保証するために、以下の**ステップでテストを進めていきます**。まず*コードレビュー*(Code review)では品質を確保するために、*ソースコードの品質評価*を行います。続いて*単体テスト*(Unit Test)では、開発・製造の工程での品質を確保するために、テストデータとテストロジックに基づいて*単体動作の妥当性を検証*します。

次に、*結合テスト*(Integration Test)では、詳細設計工程での品質を確保するために、テストデータにより、*モジュール間の動作の妥当性を評価*します。加えて、上限値・下限値やエラー処理の振る舞いが妥当かを確認します。その後に*システムテスト*(System Test)で、疑似ユーザデータを用いて*システム全体での動作が妥当か確認*します。また高負荷環境での動作が安定するかどうかや、運用想定のエラー処理が妥当かどうかもみていきます。

最終工程となる*運用テスト*(Operations Test)では、要件定義工程の品質を確保するために、ユーザの運用環境と実データを用いて、*ユーザの要求が満たされていることを確認*していきます。この工程では、ユーザ側からも運用担当者を派遣し、運用方法の*要員教育*を並行して実施することもあります。

ここでの要員教育とは、「*想定した環境下で、運用方法の差異をユーザ側から派遣し、確認すること。差異がある場合は、受入テスト前に差異について習熟し、不備がないことを事前評価し、受入準備を図ること*。」です。

その目的を果たすために、ユーザ側の要員が運用テスト期間に実施するパターンです。これにより、受入テストを円滑に進めることも可能となります。並行して、引渡しに際し、別途運用計画と要員育成計画を作成・実施します。


*運用テスト*(OT: Operations Test)は、**開発者側が責任を持ち**、進めていきます。*要件定義書の記載が、開発システムでカバーされていることを保証*するために実施します。この運用テストについて具体的な内容を見ていきましょう。

運用テストは、ユーザ側の要求する機能が満たされていることを確認し、保証するものです。そのために、ユーザの動作環境や実際のデータを用いて、*商用環境を想定した操作方法・手順を用い、確認*していきます。同様に、誤ったこと(エラー)が、想定通りに(想定エラーとして)処理されることを、**最終評価**していきます。

加えて、機能性のみならず、性能維持が高負荷でも守られるか、操作が安定しているか等の*非機能要件の適合状況を検証*します。さらに、ユーザ側は、運用テスト工程を活用して、*受入後の操作の習熟を図る*ことができます。

運用テストでは、開発者の作成したテスト計画書とテスト仕様書、テストデータを用います。*テスト環境の定義が妥当か、開発者側の責任範囲の設定が適切かについて確認*しましょう。

*応答時間、処理時間、操作エラー、障害発生時の動作や、エラー処理手順、障害検知・障害対応フローの確認*についても、**運用テストで見極めます**。

*運用テストは開発者の責任により実施*されます。しかし、求められる要件はユーザ環境で必要とされる事項です。したがって、**ユーザ側の立場に立って計画立案・実施をすること**が求められます。そのため、テストシナリオを事前に用意し、ユーザ環境に合わせたテストパターンを複数定義して適合性を確認します。

運用テストってどんなテスト？目的や内容、注意すべきポイントとは？

*受入テスト*(UAT: User Acceptance Test)とは、発注要件を満たしているかについて、**ユーザ側が最終確認をする**ものです。*検収テスト*とも言われています。したがって、*ユーザのニーズや要件を満たしているか*が、**判断基準**となります。同様に、ビジネスプロセスを満足していることが重視されます。

ユーザの作成した要求仕様に従って、要求定義書が作成されます。その際、運用環境や想定事項を考慮し作成します。ここでは、要求仕様の内容が実際に正しく反映されていることを、*ユーザ側が受入時に判断する必要があります*。そのため、**検収の判断として受入テストを実施**します。この受入テストは、大規模なシステムや複雑なシステムの多くで、受入工程に取入れられています。

運用テストで実施している同じことを繰り返すだけでは、個別に受入テストを実施する必要性が低くなります。主な*実施理由は、運用テストで実施することができない商用環境固有の処理や、業務データ処理に起因する確認を、ユーザ視点で行うため*です。特に重要な機能を、有限の評価時間の中で効率的・重点的に実施します。同様に、*運用時に発生するリスク*について業務影響の有無を想定し、**リスク低減を図ります**。

ユーザ側では、上記開発者の品質確保のための各ステップを理解し、進捗報告を受けていきます。そのため、*進捗報告に従い、受入可能な品質かどうか、事前に評価を進めていきます*。

ユーザ側の受入テストでは、合否判断のための受入基準を定めて、事前にユーザ側・開発者側双方が合意して進めていきます。本番稼働後の影響、障害発生の対策を意識し、**重点的に確認したい項目を定義**しておきます。同様に、*障害発生時の処理フローや、業務フローへの影響を調査*します。これによって、運用時に発生する事態への**対策を事前に講じ**、運用時の**リスク低減を図ります**。

## テスト工程を理解し、運用時の安定性を高めよう

各テスト工程が理解できると、関連仕様書をはじめとする成果物の理解度が高まります。同時に、*顧客要件の理解が高まり、必要な確認事項が理解できます*。理解度が高まるにつれて、自身の責任範囲も広がり、**より多くの責任が任されるエンジニアとなるでしょう**。

テストエンジニアの求人の探し方と、そのポイントを解説！

ITシステムでは、品質を確保するための手法が設けられています。ここでは、業務システムの運用を想定したテストとして、運用テストと受入テストを紹介します。運用テストと受入テストの違いを理解し、システムの安定度を高めていきましょう。

運用テストとは、納品前の最終検査です

受入テストとは、検収の確認です

両テスト共に、ユーザ運用環境を理解したテスト環境で計画・実施することがポイントです

運用テストと受入テストの違いとは？
相違点を理解してシステムの品質を高めよう！

## ITシステムで用いる要件とは？

ITエンジニアが遭遇する用語として「要件定義」があります。「要件定義」は*顧客の行うことをまとめた要望書*となります。それに基づき、ITシステムで実装できる設計書を作成します。顧客の要望を網羅するために、「機能要件」と「非機能要件」として**見えない要望を可視化**していきます。

機能要件は、顧客が実際にしたいことを指します。例えば、経理システムに経費精算情報を入力すると適切な費目に集計され結果が格納される機能をつけて欲しいと顧客側が要望した時、この機能を**機能要件**といいます。これは*直接的な顧客の要望を要件化*したもので、顧客とのヒアリングの中で比較的簡単に汲み取れるものです。しかし*システム設計には追加の検討*、つまり**非機能要件**も必要となってきます。

高品質なシステム開発に欠かせない機能要件と非機能要件とは？

上記の機能要件の例において、経理システムでは経費精算が集計・格納できれば良いのですが、本当にそれだけでしょうか？例えば、月曜日の朝一の定時処理にアクセスが集中してシステム負荷が高まったり、結果が所定時間内に戻ってこなかったりした場合は、本来の顧客要望が満たされないことになります。そのために、*本来必要とされる処理能力を定義したり、動作条件を定義したり、信頼性や保守の容易性*についても要件にまとめたりする必要があります。この**見えない要件を非機能要件**と言います。

## 非機能要件で定義される項目は？

非機能要件は、*機能要件を満たすシステム設計の動作環境や動作特性を保証する*ために**必要な検討事項**となります。したがって*非機能要件は、システム単体の設計より広範囲の動作特性を考慮して、総合的に検討する必要があります*。以降で具体的なガイドラインを見ていきましょう。

### IPA情報処理推進機構が定義した非機能要求グレードとは？

 IPA情報処理推進機構では、*要求定義の品質を確保するため*に、**非機能要求グレード**を策定しました。

背景としては、*システムが大規模化・複雑化したこと、および利用の広がりの観点から情報システムに安定的な提供基盤のニーズが高まった*ためです。利用用途としてはユーザと開発者の認識のずれを削減し、要求項目の漏れを削減することにあります。

### 非機能要求グレードの実際の項目は？

非機能要求グレードの実際の項目に触れていきます。*非機能要求グレード*では、*非機能要件*を以下の**6種類238項目に分類**しています。
・*可用性*
　継続性(11項目)、耐障害性(15項目)、災害対策(4項目)、回復性(3項目)
・*性能・拡張性*
　業務処理量(14項目)、性能目標値(15項目)、リソース拡張性(9項目)、性能品質保証(5項目)
・*運用・保守性*
　通常運用(19項目)、保守運用(13項目)、障害時運用(8項目)、運用環境(8項目)、サポート体制(16項目)、その他の運用管理方針(7項目)
・*移行性*
　移行時期(3項目)、移行方式(2項目)、移行対象機器(1項目)、移行対象データ(6項目)、移行計画(6項目)
・*セキュリティ*
　前提条件・制約条件(1項目)、セキュリティリスク分析(1項目)、セキュリティ診断(3項目)、セキュリティリスク管理(7項目)、アクセス・利用制限(5項目)、データの秘匿(3項目)、不正追跡・監視(8項目)、ネットワーク対策(3項目)、マルウェア対策(項目3)、Web対策(2項目)、セキュリティインシデント対応/復旧(項目1)
・*システム環境・エコロジー*
　システム制約/前提条件(2項目)、システム特性(7項目)、適合規格(3項目)、機材設置環境条件(18項目)、環境マネージメント(6項目)
参考：[IPA情報処理推進機構 非機能要求グレード](https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html)

上記URLより、**どなたでもドキュメント一式、並びに評価シートがダウンロード可能**です。

【保守・運用】仕事内容や将来性、必要なスキルについて徹底解説！

*非機能要件を定義することは、多くの経験を必要とする難しい工程*です。IPA情報処理推進機構の*非機能要求グレードを活用することで、これを比較的簡単に行うことができる*ようになります。というのも、汎用的に利用できる6種類の項目について漏れなく各項目がカバーされていることに加え、**ユーザおよび開発者で共通利用が可能**であるからです。

### 非機能要求グレードの利用方法は？

*IPA情報処理推進機構の非機能要求グレード*には利用ガイドと活用シートが同梱されています。利用ガイドは解説編・利用編・活用編の3種類のドキュメントからなり、手順が記載されています。これらを利用することで、**要求項目をレベル化し潜在的な要求を可視化**していくことができます。最初の段階では、要求を一意に決定できませんので、ユーザ側と開発者側で協議して収束させていきます。同様に参考モデルをグレード化してシステム間の差を段階的に定義しているため、必要な要求が確認できるようになっています。

### 非機能要件の指標「RASIS」とは？

*RASISとは、コンピュータシステムのサービスサイクルをカバーする指標*となります。各項目は英語の頭文字からなり、以下の項目に分類されます。
・*(R) Reliability*　　： 信頼性、故障や障害への耐性
・*(A) Availability* 　 ： 可用性、システムの継続性
・*(S) Serviceability* ： 保守性、障害復旧の保守容易性
・*(I) Integrity*　　　： 完全性、データの一貫性
・*(S) Security*　　　： 機密性、情報アクセスの安全性の維持

すでに気づかれた方も多いと思いますが、*RASISの項目は非機能要求グレードの各分類に含まれています。RASISを要件定義に盛り込むこと*で、**大部分がカバーされる**ことになります。

### 非機能要件の評価基準「SLAおよびSLO」とは？

クラウド事業者との契約や、クラウドサービスを利用する際にSLAやSLOという用語が出てきます。*SLAはService Level Agreementの略で、サービス提供時にどの程度のサービス品質を保証するか提示したもの*です。項目としては**測定可能**なもので、高負荷時の性能や速度を保証したり、稼働時間を保証するために提示する項目となります。同様に*SLOはService Level Objectiveの略で、上記SLAで保証される実際の性能や速度、あるいは稼働時間等の目標水準や目標値*となります。

**これらの項目はサービスイン後の品質を保証するための評価基準となります**。

クラウドエンジニアとは？従来型エンジニアとの違いや市場性・年収について解説します！

## プロジェクトへの適用方法は？

実際の非機能要求グレードをプロジェクトに適用する流れについて簡単に説明します。非機能要求グレードでは複数のモデルシステムが定義されており、まずはその中から*対象業務に近いモデルシステムを選定*します。続いて、*業務で必要とされる重要項目のレベルを決定し、重要項目以外のレベルを決定*していきます。

*一定の成果が確認されれば、関連システムの標準化を行い*、**プロジェクト適応範囲を順次拡大**していきます。

*非機能要件の要件定義は、見えない要件や暗黙の了解を可視化し、顧客と合意すること*です。そのために、**顧客とのコミュニケーションが重要**になってきます。コミュニケーションを円滑に進めるために、ヒアリングシートを作成し、統一化されたコミュニケーションを目指しましょう。

要件定義では、想定したグレードを仮置きでも設定し提示することで議論の基準を作成します。併せて、コスト面の提示も行うことで、実現の妥当性を判断していきます。その際、いくつかの*アーキテクチャの選択肢を持つ*ことで、*レベルとグレードを決定*していきます。同様に、保守対象システムと保守レベルを決めたり、将来の法令準拠への対応も必要に応じて検討していきます。

各要件に対して、**重みづけ**を行い選択肢を決定していきます。また過度にグレードを上げても、システムが利用されないと検討の意味がありませんので、*利用状況・需要予測を調査して検討*していきます。*グレードの選定には実装コスト等のトレードオフが発生*することがありますので、これらも決定時に考慮します。また意思決定には時間がかかるため、*PDCAを短いサイクルで回し、決定時間を短縮*しましょう。初期コストが高いと決定判断がつきにくいので、段階的拡張(スモールスタート)の案を用意します。さらに、長期ビジョンの計画を別途検討することが、**成功への近道**です。

## 非機能要件を理解し高品質なシステムを設計しましょう

今後、*ITシステムはさらに複雑化し、大規模化していきます*。同様に、*利用用途が爆発的に拡大します*。当初想定していた範囲外の利用も増えていきますから、*非機能要件の考え方をマスターして、システム設計に活かせるようになりましょう*。その結果、**自身の経験値も大幅に高まることでしょう**。

今後、ITシステムはデジタルトランスフォーメーション(DX)の推進により*利用用途が拡大*していきます。同様に、*利用ユーザの拡大や大規模化により、予期せぬ問題が将来的に発生するリスク*も高まります。本記事では非機能要件に焦点を当て、より安心して利用できるシステム設計のために、要件定義を進める手法を解説します。

非機能要件定義は、見えない要件を可視化することから

コンピュータシステムの要件定義は、非機能要求グレードを活用しましょう

一度プロジェクトで作成すると、関連システムへの展開が可能に

プロジェクトの成否を左右する非機能要件の一覧について詳しく解説！

仕事内容の記事（21ページ目）