「速度はどれくらい出ればいいですか」と聞いて、はっきり答えが返ってきた経験は多くありません。
機能の要望なら、欲しい人が言葉にしてくれます。
ところが速さ・止まらなさ・守りやすさといった要求は、誰も言い出さないまま設計が進んでしまいます。
そして本番が近づいた頃に飛んでくるのが、「これ、同時に千人来たら大丈夫ですよね」という確認です。
宙に浮いた非機能要件を拾い、誰の合意として置くかを決めるのが、テックリードの仕事の一つになります。
非機能要件は「どれだけうまく動くか」の要求
機能要件が「何ができるか」なら、非機能要件はそれがどれだけうまく動くかの要求です。
国際規格の ISO/IEC 25010 は、ソフトウェア製品の品質を9つの特性に整理しています。
2023年の改訂版で並んでいるのは、機能適合性・性能効率性・互換性・相互作用性・信頼性・セキュリティ・保守性・柔軟性・安全性の9つです。
このうち機能適合性だけが機能要件で、残りの8つはすべて非機能側という見方ができます。
言い換えると、要件定義で「機能一覧」を作った時点では、品質の話は8分の1も終わっていません。
規格の分類をそのまま顧客に見せる必要はありませんが、抜けを探すチェックリストとしてはよく効きます。
宙に浮く理由は「誰の要求か」が決まらないこと
非機能要件が後回しになるのは、担当者の怠慢ではなく構造の問題です。
プロダクトマネージャーは「何を作るか」に責任を持ちますが、応答速度の目標値を自分から出す立場ではありません。
一方でエンジニアは「どう作るか」を持っていても、どこまでやれば十分かの線引きはビジネス判断に属します。
つまり非機能要件は、両者のあいだに落ちることになります。
この落ちものを拾って、決められる形に整えて差し出す役回りが要るわけですね。
「何を」と「どう」の境界線そのものは、こちらで整理しています。
拾うときのコツは、いきなり数値を聞かないことです。
「遅いとどう困りますか」「止まったら誰が最初に気づきますか」と聞けば、業務側の言葉で答えが返ってきます。
数字を決める前に、グレードで幅をそろえる
とはいえ、ゼロから目標値をひねり出すのは骨が折れるものです。
日本語で使える土台として便利なのが、IPA が公開している非機能要求グレードです。
IPA「システム構築の上流工程強化（非機能要求グレード）」
IPA はこの道具の目的を「ユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止する」ことだと説明しています。
最新版は非機能要求グレード2018で、大項目は可用性・性能／拡張性・運用／保守性・移行性・セキュリティ・システム環境／エコロジーの6つです。
肝はレベル表で、項目ごとに0から5といった段階が並び、水準を選ぶだけで要求が言葉になる構造です。
発注者と受注者の合意形成のために作られたものですが、社内開発でもそのまま使えます。
「うちのサービスはこの項目はレベル2、ここだけレベル4」と置くだけで、議論が好みの話から水準の話へ移ります。
そのうえで運用中の指標に落とすなら、SLI と SLO の形にしておくと後の判断が楽になります。
つまずきやすい3つの落とし穴
一つ目は、全項目を最高水準にそろえようとすることです。
可用性を上げれば冗長化の費用がかかり、セキュリティを厳しくすれば開発の速度が落ちます。
非機能要件は積み上げるほど互いに競合するので、優先順位のない要求一覧はただの願望リストにすぎません。
二つ目は、測る手段を決めないまま数字だけ書くことです。
「99.9%」と書いたのに測定点が決まっていなければ、達成も未達も判定できません。
三つ目は、リリース直前に出てくることです。
アーキテクチャで担保するしかない要求ほど、後から足すと作り直しになります。
だからこそ、設計に入る前の段階でグレードだけでも置いておく価値があるのですね。
最後に
非機能要件は、機能一覧には出てこないのに、作り直しの原因にはなる要求でした。
ISO/IEC 25010 で抜けを探し、IPA の非機能要求グレードで水準の言葉をそろえます。
そして決めた水準は、運用で測れる指標まで下ろしておきます。
テックリードを目指して学んでいる私にとって、ここは技術力より先に段取りが要る領域だと感じました。
まずは自分の関わるシステムで、6つの大項目にレベルを仮置きしてみるところから始めてみます。
以上です。
コメントを残す