「何秒で動けば満足か」を決め忘れないために ── IPA「非機能要求グレード」で非機能要件を整理する

「画面遷移が遅いと言われたが、契約書にも仕様書にも応答時間の取り決めがない」

「夜間バッチが朝までに終わらなくなったが、データが何年でどれだけ増えるか誰も見積もっていなかった」

「サーバー障害で半日止まって初めて、『何時間以内に復旧できる構成なのか』を発注時に確認していなかったことに気づいた」

システム開発のトラブルというと機能の認識ずれが思い浮かびますが、実際に運用が始まってから揉めるのは、こうした機能以外の要件、いわゆる非機能要件の決め忘れであることが少なくありません。

この決め忘れを防ぐための公的なツールが、IPA(独立行政法人情報処理推進機構)の非機能要求グレードです。この記事では、その中身と、中小企業の業務システムでの現実的な使い方を、発注側にも分かる言葉で整理します。

1．まず結論

• 非機能要件とは、「何をするか」ではなく「どのくらいの品質・条件で動くか」の要件。可用性・性能・運用・移行・セキュリティ・設置環境の6分野に整理できる
• 非機能要求グレードは、この6分野の要求項目を網羅的にリスト化し、段階的なレベルで発注側と開発側がすり合わせるためのIPAのツール群(無償)
• 全項目を埋める必要はない。自社に近い「モデルシステム」を選び、重要項目から順に、自社の実情に合わせて調整していく使い方が想定されている
• 非機能のレベルは上げるほど費用が増える。「なんとなく高い水準を要求する」のではなく、業務への影響から逆算してレベルを選ぶ
• 決めた結果は要件定義の文書に残す。ここで決めた前提が、見積もりの比較と、運用開始後の「言った・言わない」の防止に効く

2．非機能要件とは ── 「動く」と「使える」の間にあるもの

機能要件は「受注を登録できる」「帳票を印刷できる」のような、システムが何をするかの要件です。開発の打ち合わせは自然とこの話に集中します。

一方、次のような問いは、機能の一覧には出てきません。

• このシステムは、何時から何時まで動いていればよいか。土日は？夜間バッチ中は？
• 障害で止まったとき、何時間以内に復旧しないと業務が回らなくなるか。データはどの時点まで戻れれば許容できるか
• 何人が同時に使い、1日に何件処理するか。5年後にはデータ量はどれだけ増えているか
• 誰が監視し、バックアップを取り、障害の一報を受けるのか
• 旧システムのデータは、どこまで新システムへ持っていくのか

これらが非機能要件です。厄介なのは、決めていなくてもシステムは一応「動く」ことです。問題は運用が始まり、負荷が増え、障害が起きたときに初めて表面化します。そしてその時点では、サーバー構成や設計の根幹に関わるため、直すのに大きな費用がかかります。

3．非機能要求グレードとは

非機能要求グレードは、非機能要件をめぐる発注側と開発側の認識の行き違いを防ぐことを目的に、IPAが公開しているツール群です。初版は2010年4月に公開され、現在の最新版はセキュリティと仮想化(クラウド)まわりの変化を反映した「非機能要求グレード2018」(2018年4月公開)です。現在はIPAサイトのアーカイブ扱いのページに置かれていますが、非機能要件の抜け漏れを確認する基準として、実務では今も定番として使われています。

中身は、次の道具立てで構成されています。

各メトリクスには段階的なレベルの選択肢が定義されていて、「高い/低い」のような曖昧な言葉ではなく、レベルの選択として要求を表現できるのが特徴です。

3つのモデルシステム

もう一つの特徴が、システムが停止したときの社会的影響の大きさで分けた3つのモデルシステムです。

• 社会的影響がほとんど無いシステム
• 社会的影響が限定されるシステム(企業の基幹システムなど)
• 社会的影響が極めて大きいシステム(社会インフラなど)

グレード表には、モデルごとの目安レベルが記入済みです。つまりゼロから議論を始めるのではなく、「うちはこのモデルに近い」と当たりをつけてから、実情に合わせて上げ下げしていく使い方ができます。

4．6つの大項目 ── 発注側の言葉に翻訳する

非機能要求グレードの6大項目を、発注側が答えられる問いに置き換えると次のようになります。

こうして見ると、6大項目のほとんどは技術の質問ではなく業務の質問であることが分かります。「月末の請求処理が半日遅れたら何が起きるか」に答えられるのは、開発会社ではなく発注側です。非機能要件の主導権は、実は発注側にあります。

5．現実的な使い方 ── 238項目を埋めようとしない

項目一覧には238のメトリクスがありますが、全部を一つずつ議論するのは中小企業の案件では現実的ではありませんし、利用ガイドもそういう使い方を想定していません。想定されている流れはこうです。

1. モデルシステムを選ぶ
   (自社のシステムはどの影響度に近いか)
        ↓
2. グレード表の重要項目について、
   モデルの目安レベルを出発点に自社の実情で調整する
        ↓
3. 必要な部分だけ、項目一覧で詳細化する

中小企業の業務アプリなら、ステップ2の「重要項目のすり合わせ」だけでも効果は十分にあります。経験上、少なくとも次の点だけは要件定義で文書にしておくことをおすすめします。

• 稼働時間帯と、停止したときの業務影響(可用性)
• バックアップの取得間隔と、障害時に「いつ時点のデータまで」「何時間で」戻すか(可用性・運用)
• 現在のデータ量・件数と、数年後の見込み(性能・拡張性)
• 応答時間やバッチ処理時間の目標値。「今のシステムと同等以上」でもよいので基準を決める(性能)
• 監視・バックアップ・障害一次対応の分担(運用・保守性)

このとき忘れてはいけないのが、レベルとコストのトレードオフです。たとえば「絶対に止まらないシステム」を目指すと、サーバーの冗長化や監視体制で費用は跳ね上がります。「業務が翌朝まで待てるなら、当日中の復旧で十分」と判断できれば、その分を他へ回せます。非機能要求グレードのレベルは、要求を上げる道具ではなく、業務影響と費用のバランスを話し合うための共通言語として使うのが正しい距離感です。

6．契約・見積もりとの関係

非機能要件は、契約とも直結します。

まず見積もりの比較です。非機能の前提を揃えずに複数社から見積もりを取ると、A社は冗長構成、B社はサーバー1台で見積もっているかもしれません。金額の差が構成の差なのか見込みの甘さなのか、発注側には判別できなくなります。

次に検収と運用開始後です。応答時間やバックアップの取り決めが文書にあれば、「遅い」「想定外」という水掛け論は、基準に照らした事実の確認に変わります。

IPAの「情報システム・モデル取引・契約書」でも、要件定義工程の成果物として非機能要件を文書化することが想定されています。要件定義を準委任で行い、決まった内容をもとに開発を請負で契約するという多段階契約の流れの中に、非機能要求グレードは自然に組み込めます。契約のかたちについてはIPA「モデル取引・契約書」の解説記事をご覧ください。

まとめ

IPA「非機能要求グレード」のポイントを整理します。

• 非機能要件は「どのくらいの品質・条件で動くか」の要件。決めなくても動くが、運用開始後に表面化して揉める
• 非機能要求グレードは、可用性・性能・拡張性・運用・保守性・移行性・セキュリティ・システム環境の6大項目・238メトリクスを段階的なレベルですり合わせるIPAの無償ツール群
• 3つのモデルシステムの目安レベルを出発点に、重要項目から調整する。全項目を埋める必要はない
• 6大項目の中身はほとんど業務の質問。答えを持っているのは発注側
• レベルは上げるほど費用が増える。業務影響から逆算してバランスを選び、結果を要件定義の文書に残す

「何を作るか」と同じくらい、「どのくらいの品質で動き続けるか」を先に決めておくこと。それが、動くのに使えないシステムと、その後の揉めごとを防ぐいちばん安い方法です。

業務システムの要件整理でお困りの方へ

非機能要件のすり合わせには、業務の実情(ピーク時期、データ量、止まったときの影響)と、それを実現するシステム構成の両方を行き来する作業が必要です。

合同会社小村ソフトでは、Windows業務アプリやWebシステムの受託開発・改修のご相談の際、この記事で紹介した考え方に沿って、性能・運用・障害時の挙動を要件の段階で一緒に整理しています。「今のシステムの処理がだんだん遅くなってきた」「更新を機に運用の取り決めを見直したい」といった段階からでもご相談いただけます。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

非機能要件とは何ですか？

システムが「何をするか」(機能要件)以外の、「どのくらいの品質・条件で動くか」に関する要件です。たとえば、システムをいつ使えるようにするか(可用性)、何人で使って何秒で応答するか(性能・拡張性)、誰がどう運用・保守するか(運用・保守性)、旧システムからデータをどう引き継ぐか(移行性)、どんな防御をするか(セキュリティ)、どんな環境に設置するか(システム環境)などが該当します。決め忘れると「動くけれど使いものにならない」システムになりがちです。

非機能要求グレードは無料で使えますか？どこで入手できますか？

IPAのWebサイトから無償でダウンロードできます。グレード表・項目一覧・樹系図・活用シートと利用ガイド(解説編・利用編・活用編)がセットになっており、最新版は2018年4月公開の「非機能要求グレード2018」です。現在IPAサイトではアーカイブ扱いのページに置かれていますが、非機能要件の抜け漏れ確認の基準として、実務では今も広く使われています。

238項目すべてを決めないといけないのですか？

いいえ。全メトリクスを一つずつ議論することは、利用ガイドでも想定されていません。まず自社に近いモデルシステムを選んで全体の目安を決め、グレード表にある重要項目を中心に自社の実情に合わせて調整し、必要な範囲だけ項目一覧で詳細化する、という段階的な使い方が示されています。中小企業の業務システムなら、重要項目のすり合わせだけでも「決め忘れによる揉めごと」の大半は防げます。

非機能要件はいつ決めるべきですか？

要件定義の段階です。可用性や性能の目標は、サーバー構成や設計の根幹に関わるため、開発が進んでからの変更は費用と期間に大きく影響します。IPAの「情報システム・モデル取引・契約書」でも、要件定義の成果物として機能要件だけでなく非機能要件を文書化することが想定されています。見積もりを比較する段階で非機能の前提を揃えておかないと、金額の違いが構成の違いなのか、見込みの甘さなのか判断できなくなります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。