要件定義を担当することになったけど、なぜ非機能要求が必要なの？
非機能要件は何をすればいいの？
そもそも非機能要件とは？
企画構想から要件定義の進め方がわからない？
システム開発の要件定義では、機能要件と非機能要件を決定する必要があります。
機能要件は理解していても、非機能要件がなぜ必要なのか、そもそも非機能要件で何を決めるのか、今ひとつ理解ができていない方もいるかと思います。私自身がそうでした。
非機能要件は技術的な面が強いため、情報システム部門やシステム会社が勝手に決めて提案することが多いかもしれませんが、事業方針や事業計画に大きく影響する重要な要素です。
ここでは、非機能要件とは何か、非機能要求がなぜ必要なのか、そして非機能要件の進め方とポイントをわかりやすく解説します。少しでも参考になれば幸いです。
非機能要件とは
要件定義でお客様から受ける要求事項は、機能要求と非機能要求の２つに分類されます。
機能要求はビジネスに直結した要件で、現行業務や現行システムの改善要望です。それに対して非機能要求は、システムの性能や運用に関わる要件で、ビジネスに直結しないものになります。
例えば、今後の売上増加を見越してデータ量を現行の倍にしても問題ないシステムにしたいとか、処理件数が増えても現行と同じくレスポンス時間は3秒以内にしたいとか、サポート時間は24時間365日にしてほしい等です。バックアップやセキュリティに関するものも該当します。これらの要求事項をまとめたものが非機能要件になります。
しかしながら、非機能要求に関してはお客様自身も日頃から不満や改善要望を持っておらず、お客様にヒアリングして聞き出すことが難しい要求事項になります。
なぜ非機能要件が必要なのか？
では、なぜ非機能要件をまとめる必要があるのでしょうか？お客様から要望が出てこないのなら要件として不要ではないかと思われる方もいるかもしれませんが、システム基盤を構築する上でとても重要な判断材料となるからです。
例えば、現行システムのレスポンス時間は3秒以内で快適に利用できるため利用者は不満を持っておらず、要求事項にも明記されなかったらどうでしょうか？
記載が無かったからと言ってレスポンスを無視できるはずはありません。構築した新しいシステムのレスポンス時間が10秒かかるようなものなら、お客様による検証（受入テスト）で即クレームが発生し、早急な対策で連日徹夜が続くことになりかねません。要求が無かったからと言って、それに掛かる費用は支払ってもらえないでしょう。
また、良かれと思ってシステム停止が極力ないようにサーバを冗長化して可用性を高める構成にしても、そのシステムは特定の業務部門しか利用せず、数日停止しても問題ない場合は過剰な投資となってしまいます。
それとは逆に、個人情報を扱うシステムだった場合は、安易なサーバ構成にしてしまうとセキュリティ面で重大な損害を与えてしまう可能性もあります。データの暗号化やアクセス制限、不正監視など、セキュリティ対策が必要になります。
このように、非機能要求によって構築するシステムの要件が変わるため、要件定義で機能要求と合わせて非機能要求を確認する必要があるわけです。
非機能要件は誰が決めるのか？
非機能要件はお客様にとって分かり難いものですが、あくまでも最終決定はお客様になります。
お客様は、常に速くて安くて安心・安全なシステムを要求するでしょう。しかし、システム開発には予算が決められています。システム構築を請け負う会社やプロジェクトマネージャーは、プロジェクトの予算に合わせて最良なシステムを提案しなければなりません。
お客様による検証段階でクレームが出ないように、システム開発の手戻り防止、システム運用のトラブル減少・回避のために、非機能要件をしっかりとまとめましょう。
システム開発のコストとして、構築時の初期導入コストと運用開始以降に発生するランニングコストがあります。初期導入コストを抑えても、運用後のランニングコストが高いようでは問題です。初期導入コストだけに捉われず、ランニングコストも含めた全体コスト（TCO：total cost of ownership）で判断しましょう。
非機能要件の進め方
既存システムを再構築するプロジェクトが多いと思いますが、まずは現行システムの非機能要件を可視化することから始める必要があります。
既存システムの課題・要求を確認する
既存システムで規定された非機能要件があるか確認し、無いものは課題や要求が無いかも合わせて確認します。間違っても「現行通り」という要求で終わらせないことが重要です。
お客様にヒアリングする
次に、プロジェクトの事業方針やシステム化方針に従って、構築するシステムの非機能要件をお客様にヒアリングして明確にします。
非機能要件を決定する
最後に既存システムと構築するシステムの非機能要件を総合的に検討し、最終的な非機能要件にまとめます。
クラウドサービス利用においても同様です。安易にクラウドサービスの宣伝文句の受け売りで採用せず、そのクラウドサービスが非機能要求に合致しているか、時には試用テストして確認することも検討しましょう。
非機能要件のポイント
非機能要件を進める時のポイントをまとめました。この内容はクラウドサービスを利用する場合でも同様です。
現行業務や既存システムの不備・問題点から聞き出す
非機能要件はビジネスに直結しないだけに、お客様に要件を伺っても曖昧な答えしか返ってこない、もしくは全く答えが無い（分からないから任せる）ことが考えられます。
まずは既存の業務やシステムで非機能要件に関係するような困り事が無いかをヒアリングするとお客様も話し易いと思います。
例えば、「月末に近づくとシステム動作が遅い」と言う課題がヒアリングから見つかったとします。より具体的に問題を整理するために、毎月何日くらいに遅くなり出すのか（いつ）、どの業務のどの画面で何をすると遅くなるのか（どこで・何を・どうする）、 遅くなるタイミングは全員同じか（誰が）、平常時のレスポンスであれば問題ないのか（どうする）、と言う感じで5W1Hを意識して具体的に確認しましょう。
「5W1H」とは情報を整理するフレームワークで、When（いつ）、Where（どこで）、Who（誰が）、What（何を）、Why（なぜ）、How（どうする）の6つの言葉で構成されており、それぞれの頭文字を取って表しています。詳細は多くの方が解説されておりますので興味がある方は検索してください。
非機能要件を漏れなく確認する
お客様にヒアリングする前に確認したい非機能要件をリスト化しておくことが重要ですが、思いつくものを書き出しても抜け漏れを防ぐのは難しくなります。
そこで非常に参考になるのが、独立行政法人情報処理推進機構（IPA）が公開している「非機能要求グレード2018」です。
「非機能要求グレード」は、「非機能要求」についてのユーザと開発者との認識の行き違いや、互いの意図とは異なる理解を防止することを目的とし、非機能要求項目を網羅的にリストアップして分類するとともに、それぞれの要求レベルを段階的に示したものです。重要な項目から順に要求レベルを設定しながら、両者で非機能要求の確認を行うことができるツール群です。
引用：独立行政法人情報処理推進機構（IPA）｜システム構築の上流工程強化（非機能要求グレード）｜機能要求グレードとは
非機能要求グレードは、システム基盤に関係する非機能要求をスコープとしており、可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの6つに分類して整理されています。
元々は情報システムを新規開発する場合を想定して作成されているものの、システム改修（機能拡張）やアジャイル開発、クラウドサービス利用においても活用できるものです。
ただし、非機能要求グレードの項目は全部で238項目もあるため、そのままを業務部門に送りつけて記入してもらうには項目が多すぎますし、それぞれの項目の内容も理解できないと思います。
そのため、業務部門とは対面でお互いに質疑応答を繰り返して必要なレベルを合意していく方法が推奨されています。
非機能要求グレードを決めるには、下記の3つの手順で段階的に実施する方法を推奨しています。
手順1
「グレード表」の先頭にあるモデルシステムシートの16項目から検討を始めます。3つあるモデルシステムイメージから構築するシステムに近いモデルをベースにそれぞれの項目を確認します。
手順2
238項目ある「非機能要求グレード活用シート」のうち、コスト影響や 手戻りリスクが多いと想定される92項目（重要項目に○があるもの）についてレベルを決定します。
手順3
それ以外の238項目すべてを決定します。
また、概算見積もりを提示するためには重要項目の92項目だけは決定しておくのが望ましいとしています。
サービスレベルの決定は経営層や決裁権のある責任者を入れて合意する
構築するシステムのサービスレベルはコストに大きく影響します。システムが停止する時間は出来るだけ短くしたいと言うのがお客様の正直な気持ちでしょうが、24時間365日停止しないシステムと1時間だけ停止するシステムでは掛かるコストが何倍も変わってきます。
本当にそのサービスレベルが必要なのかは、そのプロジェクトの目的や事業方針によって判断する必要があります。
そのため、事業に関わる重要項目については経営層や決裁権のある責任者を入れて合意し、そのサービスレベルをベースに業務部門と要件を整合しましょう。
最適な要求レベルに調整する
業務部門にヒアリングすると「システムは止めないで！」「画面の動きを速くして！」「昔のデータは消さないで！」などと、自分自身の業務に悪影響を与えないように高度な要求をされます。
しかしながら、そのようなシステムを構築するためにはサーバを増強したり、運用時間を長くするためのサポート体制を整えたり、コストや開発期間に影響します。
プロジェクト予算を超える過剰な要件にならないように、要求の必要性の確認、要求内容とコストの関係、過剰な場合は代替案の提案など、お客様にとって最適なレベルとなるように調整しましょう。
例えばレスポンスの要求を決める時、すべてのオンライン画面で3秒以内という具合に一律に基準を決めないことが重要です。レスポンスを重視する特定の画面だけ、データ項目が30個以上ある画面は5秒以内など、過剰なレベルにならないように調整しましょう。
優先度の高い要求を選択する
プロジェクトに関わるステークホルダーには、実際にシステムを利用する業務部門もあれば、開発費用に厳しい経理部門、事業拡大を成功させたい経営層など、様々な立場の方がいます。それぞれの要求を持っているため、ステークホルダー全員の要求すべてを実現するのは難しい場合があると思います。
その時は、プロジェクトの目的や背景、前提条件、制約条件に照らし合わせて要求事項に優先度を設け、優先度の高いものは採用し、優先度の低いものは非機能要求のレベルを下げる選択ができないか調整します。
また、レベルを下げた優先度の低い要求は、システム運用後に追加機能として開発する等、ステップを分けて段階的に機能拡張する方法も提案しましょう。
お客様である業務部門の方と長期間検討を重ねて決めた要件だけに、優先順位の検討には迷うことが多いでしょうし、声の大きい方に負けることも。優先順位を決めるためには、客観的に判断できる基準を定義して予め共有しておくことが重要です。
システム運用部門を入れて検討する
ご承知の通り、システムは構築して終わりではなく、むしろ始まりで、その後の安定したシステム運用で事業や業務に貢献することが役割です。
既存システムの再構築はもちろん、新規システム構築であっても、システムの運用方法を一番理解しているのはシステム運用部門です。運用時間やバックアップなど、運用・保守性に関する非機能要件を決める時は、システム運用部門のメンバーを加えて討議することが重要です。それで決定したことは、運用時にシステム運用部門から苦情を言われることはないでしょう。
初めてクラウドサービスを利用する時やアプリケーション基盤を刷新する等、場合によってはインフラ部門やハードウェアやミドルウェアのベンダーにも参加いただいくことも検討しましょう。
非機能要件グレードを活用して事業に貢献するシステム構築を！
非機能要件はシステム基盤に関わる技術的な面が強いため、情報システム部門やシステム会社が勝手に決めて提案することが多いかもしれませんが、事業方針や事業計画に大きく影響する重要な要素です。
繰り返しになりますが、非機能要件の最終決定者はお客様です。お客様に説明して理解させるのは、システムを構築する側の責任です。
非機能要求グレードを活用して、お客様にとって最適で、事業に貢献するシステム構築を目指しましょう。
もし要件定義の進め方に少しでも不安がある方は、要件定義の記事をまとめていますので、こちらもあわせてお読みください。要件定義が計画通りに完了することを願っています。
