 |
「ユーザーが要件を決めてくれないので…」「性能要件を出していただかないと機器が見積もれません，早く要件を出してください！」。要件定義フェーズのみならず，プロジェクトの様々な工程でよく耳にする言葉である。
非機能要件はユーザーにヒアリングして洗い出すのが，インフラ設計における一般的な手法だ。だが，インフラ設計者はヒアリングによって得られたユーザーの「要望」を絶対的な「要件」としてとらえてはいけない。非機能要件を洗い出すに際しては，要望の裏にあるリスクやそこから派生する制約を先読みすることが重要である。その思考を停止してしまうと，後工程で様々な問題が発生する。
今回は，非機能要件の中でも読者にとって最も身近だと思われる「（オンラインの）性能要件」を例に解説する。なお，現在のシステム構築では，現行システムが存在せずゼロから開発することはほとんどない。従って，ここでは現行システムで何らかの稼働統計が存在しており，ユーザーがその内容を知っているという前提で話を進める。
オンラインの性能要件には，一般的に以下のようなものがある。
- スループット
- レスポンス・タイム
- トランザクション量
- ピーク時間帯とその集中率
ヒアリングで，ユーザーが次のようなことを語ったとする。一見，上記の性能要件を埋められるように思える。
「現行システムのオンラインは，レスポンス・タイムがだいたい2秒くらいで，端末は約3000台です。1日のトランザクション量は約10万件で，午前中に1日のトランザクションの8割が発生します。今回のシステム更改で30％程度の性能向上を達成したと考えています」。
ユーザーにヒアリングして得た回答がこの程度であることは多い。しかも，ユーザーは要件を出したと信じきっている。インフラを設計する側（SE）と業務でシステムを使う側（ユーザー）では数字の「気にしかた」が異なるため，仮に現行システムの稼働統計が存在していたとしてもユーザーはその程度にしか数字を把握していないことが多いのである。しかし，この内容では性能要件とはなり得ない。性能要件は，業務パターンや処理方式を前提に定義するため，それ無しで数字だけを並べても要件としては使えないのである。
この「ユーザーが日々業務を行う上で気にしている数字」と「インフラ設計に必要な数字」では，そのレベルにおいて大きなギャップがある。それを埋める活動こそ，性能要件定義でやらなければならないことなのである。
性能要件を定義する正しい手順
性能要件の出し方を考えるために，性能要件がすべての要件の中でどういう位置を占めるのかを整理しておこう。まず，業務要件から導き出す機能要件はアプリケーション処理そのものである。各業務を処理パターンとして分類し，各々の処理方式設計を行う（図1のステップ1）。
一方，非機能要件とはアプリケーション処理方式（機能要件）に依存しない共通の要件である。各処理方式を横串で見て実現方式について検討すべき要件である（図1のステップ2）。
 |
| 図1●性能要件の位置付け |
ここでいう非機能要件とは，具体的には拡張要件，セキュリティ要件，運用要件を指す。性能要件は一般的に非機能要件として分類されているが，各アプリケーション処理方式ごとに定義すべき要件である点が，他の非機能要件とは異なる。
つまり，性能要件はアプリケーション処理方式が固まらない限り，定義できない。最初からユーザーが「はい，これが要件です」とポンと出せるものではないのである。業務パターンや処理方式が現行システムと全く同じシステムを構築する場合は性能要件を早々に決めてしまうことも可能だが，実際の案件でそんなことは滅多にない。前提とするミドルウエアなどのアーキテクチャが変われば，現行システムではいくつかに分かれている処理が一つになったり，その逆になるケースが必ずある。要件定義フェーズでのヒアリングはあくまで「現行システムにおける参考値」もしくは「ユーザーの要望」以外の何者でもない。
性能要件を最も効果的に定義する方法は，現行システムの稼働統計を入手し，システム設計をする上で必要な数字を拾い上げることである。具体的には，次のような手順を踏むとよい。
（1）ピークをつかまえる
一日のピーク時間帯を現行システムの業務分類ごとに分析する。ピーク時間帯（10分程度の刻み）でのスループット，レスポンス・タイムを算出する（図2）。これが現行システムにおける参考値となる。
 |
| 図2●業務分類ごとのピーク時間帯の把握 |
（2）トランザクションミックス（トランザクションの組み合わせ比率）を分析する
現行システムにおいて各業務処理がどういう割合で発生するか，30分程度の刻みで分析する（図3）。
 |
| 図3●トランザクションミックスの分析 |
（3）新システムにマッピングする
現行システムの業務パターン一覧と新システムでの業務パターンをマッピング（統合するものもあれば，分割するものもある）し，新たなトランザクションミックスを作成する（図4）。例えば「業務Aと業務Bが統合され，新しい業務Xになる。かつ，業務Cが分割され，業務Y1とY2になる」といった具合である。この例では，現行システムに比べて午前9～10時のピーク性がより顕著になっている。
 |
| 図4●新たなトランザクションミックスの作成 |
（1）～（3）を経て完成したピーク時の性能要件が，新システムにおける性能要件である。これ以外にも，新システムにおけるアーキテクチャ上の制約や予算的な制約まで加味する必要がある。「性能要件はユーザーが出すもの」（≒絶対要件）という固定観念にとらわれてはならない。
非機能要件は，その裏にあるリスクやそこから派生する制約を先読みすることが重要である。要件定義→概要設計→方式設計といった各フェーズにおいて，インフラの立場から性能要件をユーザーと一緒に定義していくことが肝要なのである。
|
