1. はじめに
IPA(情報処理推進機構)では情報処理に関する様々な情報や資料が公開されています。
最近では情報セキュリティへの関心の高まりから、「情報セキュリティ10大脅威」などは数年前に比べ一般的になってきていると思います。
私は普段インフラ系プロジェクトを担当しており、特にウォーターフォールモデルによる開発に携わる事が多いのですが、機能要件に比べ非機能要件に対する理解が低いと感じていたため、昨年内容が更新された非機能要求グレードを読んでみました。
2. 非機能要求グレードとは
「非機能要求グレード」は非機能要件を確認する為のツールです。非機能要件について検討すべき要求項目が羅列されているだけでなく、指標（レベル）についても示されており、要求事項について、この項目はどういう確認をとれば良いのかイメージを持ちやすい様に整理されています。
Webサイトの階層(パンくずリスト)
IPA > 社会基盤センター > これまでの活動内容 > テーマ別解説 > システム構築の上流工程強化 > 非機能要求グレード
3. 非機能要件とは
非機能要件とはそのシステムやソフトウェアが直接ユーザに提供する機能(例えばカメラアプリであれば写真と撮る機能や美肌効果をつける機能など)以外の要件です。本資料では以下の様なものに触れられています。
| 要件 | 説明 |
|---|---|
| 可用性 | 必要な時にシステムが使用可能である度合い |
| 運用保守性 | システムトラブルからの業務復旧容易性や災害対策範囲 |
| 性能、拡張性 | レスポンスやスループット、データ容量、システム使用年数や、システム改修を見越した要件など |
| 移行性 | 予定通りに移行できるか、移行の難易度 |
| セキュリティ | 情報は守られているか |
| システム環境、エコロジー | どこにシステムを置くのか、環境に配慮できているか |
上記にはRASISの項目も含まれていますが、資料に目を通していて思ったのは別の評価軸のフレームワークとして参考にするのが良いと思いました。
| 要件 | 説明 |
|---|---|
| 信頼性 | 故障の起こりにくさ。MTBF |
| 可用性 | 必要な時にシステムが使用可能である度合い。稼働率=MTBF/(MTBF+MTTR) |
| 保守性 | システム障害時の修理し易さ。MTTR |
| 保全性 | 保存されているデータが完全で損なわれないか |
| 安全性(機密性) | 災害や障害に対するデータの耐性度合い |
4. 要求事項をしっかりと確認する
本書の中では、この資料で整理をサポートできるのはあくまで要求であり、 そのままシステムアーキテクチャや必要リソースを導き出せるものではないと明記されています。あくまでもシステム計画段階のアウトプットとなります。
システムの設計というよりは、システム要件の整理（要求整理）にフォーカスしています。
ASIS,TOBEを考えることの大切さ、相手の考えや背景を考えることの大切さに触れているなど、実際のプロジェクトで気をつけるべき事項につても折り込まれています。
4-1. 要求レベルが現行通り
現行システムで利用されているアーキテクチャやハードウェアを確認し、それらの性能を参考に新システムの要求を整理する。
4-2. コスト削減
多くのプロジェクトではプロジェクト対応に関わる一時費用に目がいきがちです。しかし対象システムを利用する期間が長くなれば長くなるほどTCOのうち大きな割合を占めるのは稼働後の運用コストです。運用コストの削減をシステム導入後に改めて考える難しさについても言及されています。
4-3. 非機能要件に対する要求に効率良く対応する
要求される要件はシステム毎や同じシステムでも機能により要求レベルが異なります。例えば個別に最適化された性能要件を実装するよりも、ある一定レベルの性能要件を満たすものを準備し、それで満たせないものを個別対応する方が運用性やコスト面で優れる場合があります。
4-4. テストの重要性
要求事項が実際に保たれているかはテストで確認しないとわかりません。特に非機能要求は目に見えないものですので、要件整理時・設計時に整理した内容を満たせているかを確認することは重要です。
4-5. クラウドに対する考え方
実現するシステムがオンプレミスかクラウドかではなく、元々の要求事項を満たせるかどうかが大切。一時的な負荷増大に対し柔軟にリソースを制御できるクラウドに分があると考えるのか、システム利用計画が明確であり、コストを抑える事が可能、クラウドベンダの急なサービス変更に影響を受けないオンプレミスにメリットを感じるのかは、要求に依存します。