最近、社内から非機能要件に関する相談が複数あったことや、CoinCheckのNEM流出問題もあったことから、改めて非機能要件テーマにその必要性とどのように定義するべきかをテンプレートとセットでご紹介します。
CoinCheck事件の被害の拡大は非機能要件が甘かった
先日発生したCoinCheckにおける仮想通貨NEMの流出検知に8時間かかったのは非機能要件の詰めが甘かったとしかいいようがありません。
非機能要求グレード活用シート(後述)のE7.1.5にもありますが重要度が高い資産に対する検知をしっかりと定義していれば、8時間もかかるということはなかったのではないでしょうか？
そして、そのリスクを考えると一定時間の取扱総額を定義して一定額以上は取り扱えないようにある種のサーキットブレーカーを取り入れることは事前に十分想定可能であり、それはマルチシグやコールドウォレットの対応よりも容易と考えます。こうした仕組みは銀行ATMでもとられており、十分にシステム構築時に想起可能な要件と思われます。
非機能要件はなぜ必要なのか
大きなシステムの新規構築時には必ず検討する非機能要件ですが、新規案件の小粒化や改修案件の増加によりきっちりと非機能を検討する機会が減少してきているように感じます。また、Cloud開発や機械学習などこれまでとは異なる新分野に対する非機能要件が正しく認識できていないなどもあると思います。
私は生保や航空会社の大きな新規システム開発を過去に担当していたことから非機能を自分で検討し、開発し、運用する経験を幸運にも得られました。ただ、そういった経験がない場合に非機能要件の導出を自力で行うことはとても難しいと思います。(当然ながら開発経験のないITコンサルができるわけがありません。)
**そして悪いことに正しく検討されなかった非機能要件はシステム開発の後半でおばけのように次々と出現してきます。**これはシステム開発におけるリスクを食いつぶし、そこで働くエンジニアの精神を蝕んていきます。なぜなら、ウォーターフォール開発における、後工程での要件追加は必然的にソースコードをスパゲッティにするからです。
CoinCheckの例を見るまでもなく、正しい非機能要件定義はお客様にとっても有用です。豪華すぎず、必要な範囲で非機能を定義することで、お客様も開発も保守も運用も幸せになれると思います。
非機能要件を正しく定義する第一歩
日本では非機能要件関連の活動として以下のような団体がそれぞれ取り組んでいます。
[画像引用元：IPAの「非機能要求グレード研修教材」より]
この表の中でシステム開発会社がまず確認するべきものはIPA/SECの非機能要求グレードになります(下記URL)。
**「えー、こんなの見る暇ないよー」**という声が聞こえてきそうです。ただ、安心してください。ここにはそのまま使えるテンプレートが以下のサイトに含まれています。テンプレートみんな好きですよね。
こちらよりダウンロードできるZipファイルにはPDFが5ファイルとテンプレートとなるExcelが含まれています。まず、こちらを全部ざっとでもいいので目を通してもらって、この資料の存在を意識していただければと思います。
必ず何かの機会でネタ帳として使える機会がでてくると思います。
非機能要求の見える化と確認の手段を実現する「非機能要求グレード」の公開
なぜ非機能要件が開発の後半で明らかになるか
原因のほとんどは人的要因だと考えます。
要件定義や設計を行っているエンジニア及び顧客が非機能要件を定義できていないのです。システムテストあたりから運用メンバーが引き継ぎも兼ねてテストにはいりますが、その時点で彼らから「なんであのログないの？」「計画停止した後の動きがおかしい」など指摘が挙がり始めるのです。
要件定義の段階から彼らを交えるなどするか、無理ならウォーターフォールでなくリーンなどのアジャイルを適用してこの問題を回避することが一つの策と考えます。
それも無理なら、要件定義や設計の本に非機能のことはあまり書いていないことは明確なので、以下のテストや見積もりの本から先回りして確認することが良いと思います。
以下の本は私は会社と家に置くほど読み込んでおり、とても良い本でおすすめです。ソフトウェア見積もりは不確実性のコーンの原典です。
基本から学ぶソフトウェアテスト
ソフトウェア見積り 人月の暗黙知を解き明かす