これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
これから学ぶ人も、資格取得を目指す人も、最適なカリキュラムを選べます。
CTC 教育サービス
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
みなさんこんにちは。一般的にソフトウェア開発はリリースがゴールのように捉えられがちですが、システム運用はリリース後からが本番です。サービスの品質を維持し続けるには運用設計でどれだけ品質を高められるかが重要ですが、「そもそも何をどう設計すればよいのだろう」という疑問もあるかと思います。
一般的にインフラ運用は非機能要件をどれだけ満たすかが評価基準になることが多いのですが、機能要件と違い、「ある要件を満たしていない」という状態が見えにくく、運用設計に熟練したメンバーがいないと「この非機能要件は要求として挙がっていない」のか、「運用設計の考慮から漏れていた」のかが判別できず、運用後に「ところでこの障害、どう復旧するのが正しいのだろう」などのような判断の迷いに繋がりかねません。
非機能要求グレードは、システム基盤の発注者要求を見える化する非機能要求グレード検討会から生まれたツール群で、本稿執筆時点では2018年4月25日に公開された版が最新版となっています。
参考URL : https://www.ipa.go.jp/sec/reports/20180425.html
そもそも機能要求と非機能要求の違いとは何でしょう。IPAのサイトから図を引用しますと以下のようになります。
利用者の能動的な要求を実現したものが機能要求で、主にアプリケーションがこれに応えます。機能要求が実現されないと、例えばそこにあるべきボタンが実装されていなかったりすると、それは目に見えるバグとしてすぐに顕在化します。
一方で、機能要求に比べて非機能要求は利用者から見てあまり意識されることは多くなく、非機能要求の抜けや漏れもすぐに顕在化することは稀です。しかしこれは、言い換えると性能劣化やセキュリティインシデント、バックアップデータの不在やリストアの失敗など、想像するのが怖くなるような事態で発覚するケースが跡を絶ちません。
非機能要求グレード2018をダウンロードして見てみますと、約240の項目があり、大項目は
に分類されます。しかし、すべてのサービス、システムにおいてこれらすべての項目が網羅されている必要はなく、例えばクラウドを利用するにあたって利用者の責任でエコロジー対策を盛り込むのは不自然なように、無理やりすべての非機能要求を実現しなくてもよいと考えます。
とは言え、せっかくこれだけの網羅性をもった資料があるのですから、これを活用しない手はありません。先に述べましたように、非機能要求は利用者側がすべて意識することは稀で、可用性やセキュリティのような「これが実現できないとビジネスに悪影響がある」という項目はベンダー側へ要求されるとは思いますが、運用・保守性など、人の頑張りでカバーできる(と思われている)項目に対しての要求は、ほとんど挙がってこないように見受けられます。
しかし、人の手が多く介在すればオペミスなどのリスクは高いですし、移行性の考慮がないと、システム老朽化などの理由でリプレースする際に、移行漏れが発生してそれこそ機能要求のデグレードが発生してしまいます。
また、企業によっては独自の非機能要件が求められることもあるかと思いますが、一般的な非機能要求がどのようなものかを理解していると、限られた期間と予算内でどの要求がどんな優先度なのかを交渉する材料にすることもできます。
すごく身も蓋もないことを言ってしまいますと、利用者(顧客)は機能要件の実現には積極的ですが、非機能要件だけに対して工数や予算を捻出してくれることは残念ながら多くありません。また、非機能要件の実現「だけ」に予算が出るということは、それ以前に何かしらの事故があったなど、後ろ向きな理由がキッカケになることもありました。
しかし、提案段階から非機能要求グレードなどを用いて正しい運用設計のセオリーを持ち込むことで、これから導入するシステムの価値を向上させ、運用メンバーが高いモチベーションで業務に臨むことも可能になります。
非機能要求グレードを用いることで、運用設計の網羅性が高まり、また、上流工程の手戻りをへらすことも可能になります。是非導入してみてはいかがでしょう。
[IT研修]注目キーワード Python UiPath(RPA) 最新技術動向 Microsoft Azure Docker Kubernetes
