非機能要求グレードの歩き方 Vol.1 オンライン編-B1業務処理量

30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、「やらかしがちな」技術的課題について、IPA^[1]の非機能要求グレード^[2]に沿って解説します。
※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。

本記事では、オンライン性能要件における「B.1 業務処理量」に焦点を当てて解説します。

B.1 業務処理量の定義とオンライン性能要件

オンライン性能要件をまとめる際には、システムの性能目標値を決定する前に、その前提となる「業務処理量」を具体に定義することが重要です。
これは、1つの業務処理で発生する取引数は、インターフェース設計に依存して大幅に異なることがあるからです。
最初に着手するべきは、設計に依存しない業務処理量を明確にすることです。

下表は、非機能要求グレード 大項目「B:性能・拡張性」-中項目「B.1 業務処理量」のうち、オンライン性能に関する項目を抜粋したものです。

項番	中項目	小項目	メトリクス (〇: 重要項目)	レベル0/1/2/3/4/5
B.1.1.1	業務処理量	通常時の 業務量	〇ユーザ数	0: 特定ユーザのみ 1: 上限が決まっている 2: 不特定多数のユーザが利用
B.1.1.2	〃	〃	〇同時アクセス数	0: 特定利用者の限られたアクセスのみ 1: 同時アクセスの上限が決まっている 2: 不特定多数のアクセス有り
B.1.1.4	〃	〃	〇オンライン リクエスト件数	0: 処理毎にリクエスト件数が明確である 1: 主な処理のリクエスト件数のみが明確 である
B.1.2.1	〃	業務量 増大度	〇ユーザ数 増大率	0: 1倍　　　1: 1.2倍 2: 1.5倍　　3: 2倍 4: 3倍　　　5: 10倍以上
B.1.2.2	〃	〃	〇同時アクセス数 増大率	〃
B.1.2.4	〃	〃	〇オンライン リクエスト 増大率	〃

項目説明

• 各カラムの説明(非機能要求グレード 2018 利用ガイド [解説編] P19^[3] より抜粋)
  • 小項目: ユーザとベンダの間で合意される非機能要求を示す項目。
  • 重要項目: 非機能要求を検討する上で品質やコストに大きな影響を与える項目。
  • メトリクス: 小項目を定量的に表現するための指標。
  • レベル: メトリクスを評価軸として、項目が通常取りうる値をレベル0からレベル5の6段階に整理した項目。レベルの差はアーキテクチャにギャップがあり、レベルが大きいほど実現の難易度が高く、一般的に開発コストが高くなることを表す。

残念ながら、非機能要求グレード「項目一覧」の「レベル」を定義することで要件を定義できると誤解されるケースが見られます。「レベル」は実現の難易度を定量的に表していますが、それだけでは要件として不十分です。
非機能要件は、「小項目」ごとに、文章で「レベル」が分かるよう具体的に記述しましょう！

以降、小項目ごとに解説します。

B.1.1 通常時の業務量

	小項目 B.1.1：通常時の業務量
説明	性能・拡張性に影響を与える業務量。 該当システムの稼働時を想定し、合意する。 それぞれのメトリクスに於いて、単一の値だけでなく、前提となる時間帯や季節の特性なども考慮する。
メトリクス	B.1.1.1: ユーザ数 B.1.1.2: 同時アクセス数 B.1.1.4: オンラインリクエスト件数

小項目名の「通常時の業務量」という表現は分かりにくいですが、「通常時」をシステム利用開始時と解釈すると、「B.1.1 通常時の業務量」と「B.1.2 業務量増大度」の2つで、中項目の「B.1 業務処理量」を網羅できることが理解できると思います。

📌ピーク時間の単位に注意

システム利用開始時の想定業務量は、
業務(タスクレベル)ごとに、期間毎(年間、月次、日次)およびピーク時の業務量をまとめます。

• 業務量は、チャネルと業務種類の組合せたタスクレベルで整理します。
  性能に影響する主要な業務の業務量を把握すれば十分で、すべてを網羅する必要はありません。
  ただし、性能影響の種類(軽い大量参照、更新、大量データなど)を考慮して業務を分類することが求められます。
  例えば、銀行口座の場合、チャネルには来店、ATM、インターネットバンキング(成長大)、お財布系システム(照会のみ、集中時刻あり)が含まれます。業務種類には、残高照会(大量参照)、取引履歴照会(件数大参照)、振込(更新)などがあります。
• 期間ごと(年間、月次、日次(ピーク日))の業務量は、蓄積するデータ量の基礎となります。
  また、この期間ごとの業務量は、ビジネス目標と整合していることが求められます。
• ピーク時の業務量は、スループットやレスポンスといったオンライン性能要件の拠り所となります。最低限1時間単位のピーク業務量を定義しますが、レスポンス要件や集中度に応じて、1分単位や1秒単位での定義が求められる場合もあります。
  • 1時間級業務の例：
    銀行事務処理のように、人が断続的に操作する業務では、ピーク日のピーク1時間の業務量を分析します。
  • 1分級業務の例：
    特定の時刻に集中する取引では、1分単位でピーク特性を把握する必要があります。
    また、タイムアウト時間を数十秒に設定する場合、タイムアウトを回避するためには少なくとも1分単位のスパイク的ピークの業務量が必要です。
    • 例: クレジットカードやインターネットバンキングでは、自動処理により特定時刻にAPI呼び出しが集中するケースが増えています。
    • その他の例: 就業開始時刻に一斉ログインするなど、多人数が時刻指定で操作する運用（例: 公共機関）。
  • 1秒級業務の例：
    取引所やバーコード決済のように、秒未満のレスポンスが求められる業務では、秒単位のピーク特性を把握する必要があります。
    特にミリ秒レベルの精度が求められる取引所では、1秒単位の分析では粗いため、さらに精密な解析が必要です。

B.1.2 業務量増大度

	小項目 B.1.2：業務量増大度
説明	システム稼動開始からライフサイクル終了までの間で、開始時点と業務量が最大になる時点の業務量の倍率。 必要に応じ、開始日の平均値や、開始後の定常状態との比較を行う場合もある。
メトリクス	B.1.2.1: 業務量増大度 B.1.2.2: 同時アクセス数増大率 B.1.2.4: オンラインリクエスト増大率

「業務量増大度」は、システムの処理能力と拡張性を決定する上で重要な要素です。

📌業務量予想モデルの作成

業務量予想モデルを作成して将来の業務量を予測し、
その予想結果から、現状の業務量に対する倍数（業務量増大度）を導くことが必要です。

小項目の説明に「開始時点と業務量が最大になる時点の業務量の倍率」と記載されています。
期間あたり増加率にライフサイクル期間をべき乗して算出しているケースがありますがこれでは不十分です。
最大業務量を求めるには、以下のアプローチが望まれます：

1. 実際のピーク要因(業務量変動要因)を抽出する。
2. 複数のピーク要因が重なったときの影響を把握し、将来の業務量予想モデルを作成する。
3. 過去時点のつもりでその後の業務量を予想し、実績に照らしてモデルの妥当性を検証する。
4. システムライフ期間中の業務量を予想し、最大業務量を求める。

さらに、運用保守作業の一環で、定期的に、実績に照らして業務量予想モデルの妥当性を評価してモデルを補正し、必要に応じて適切な対応を行うことが望まれます。

あったら怖い本当の話

※　実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。

業務量要件

・ 開始年ピーク日業務量: 100 (ピーク日: 月末および連休前に10%増)
・ 年間増加率: 年1.5%
・ 利用期間: 5年 (+予備2年)

業務量見積

・延命リスクを加味した7年後の、ピーク日(10%増)の業務量を算出。

$$\begin{alignedat}{3} \textbf{7年後}&: \mathbf{110.98} &= (100 \times 1.015 ^ 7&) \end{alignedat}$$

・結果: 7年後の約111(増大率1.11倍)を最大業務量とした。
システム開発は順調に進み、商用稼働後も大きな問題なく安定して稼働を続けていましたが・・・

😱7年持つはずが1年後にタイムアウト多発

1年後、月末と連休前の2つのピーク日特性が重なる日に、7年後の予想111を超える業務量が発生し、タイムアウトが多発してしまいました。

敗因

月末と連休前の2つのピーク要因が重なった時の影響を見逃し、年々一定比率で業務量が増加する点にのみ着目した結果、最長7年後のピーク日が最大業務量になると誤認していたことです。

再発防止：業務量予想モデルの定期的評価

ピーク要因が重なる効果を考慮した将来の業務量予測モデルを作成し、システムライフ内の業務量を予測した結果、7年間のうち、1年後と4年後に月末と連休前が重なる日の業務量が特に突出することを確認しました。
これを受け、最大業務量を7年後の111から4年後の117(増大率1.17倍)に見直し、必要な対応を実施しました。
さらに、歯止めとして、月次で業務量の予実評価を行い、ギャップが大きい場合には業務量予測モデルを見直して再評価し、必要に応じて適切な対応を促す運用を確立しました。

$$\begin{alignedat}{3} \textbf{1年後}&: \mathbf{111.65} &= (100 \times 1.015 ^ 1&) \times 1.10 \\ 2年後&: 103.02 &= (100 \times 1.015 ^ 2&) \\ 3年後&: 106.14 &= (100 \times 1.015 ^ 3&) \\ \textbf{4年後}&: \mathbf{116.75} &= (100 \times 1.015 ^ 4&) \times 1.10 \\ 5年後&: 107.73 &= (100 \times 1.015 ^ 5&) \\ 6年後&: 109.34 &= (100 \times 1.015 ^ 6&) \\ \textbf{7年後}&: \mathbf{110.98} &= (100 \times 1.015 ^ 7&) \end{alignedat}$$

余談: 不幸中の幸い

1年後の業務量が7年後の予想水準に達しタイムアウトが多発したことを踏まえて、性能改善と再発防止を実施した結果、4年後は問題なく運用できました。
もし1年後に問題が発生していなかったら、4年後にはスローダウンなどもっと深刻な障害が発生していた可能性がありました。

まとめ

本記事では、オンライン業務処理量の要件をまとめるには、将来の業務量を予測する必要があることを説明しました。

最後に、NTTデータの金融高度技術本部では、ともに金融ITの未来を切り拓く仲間を募集しています。興味がある方は募集要領をご覧ください。（参考：NTTデータ金融分野の取り組み）

脚注

1. IPA: 独立行政法人 情報処理推進機構 (Information-technology Promotion Agency, Japan)

2. 非機能要求グレード:
   参照用pdf: 非機能要求グレード2018 改訂情報(PDF:897 KB)
   活用用xls: 非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の　06‗活用シート.xls
   

3. 非機能要求グレード 2018 利用ガイド [解説編] P19:
   非機能要求グレード本体（日本語版）、利用ガイド［活用編］一括ダウンロード(ZIP:9.7 MB)の
   01_利用ガイド解説編.pdfの26枚目