1. No category

特集
だ
能
機
分
十
不
は
で
け
の
・
快
速
・
安
特 集
定
件
要
機能だけでは不十分 安・速・快の要件定義
。
。
使える」― 快” を求めている
に
適
快
「
・
が速く」
安・速
スポンス
テムに “
要だ。
レ
ス
「
シ
」
報
く
強
変革が必
、情
の
は
義
門
定
「事故に
部
、 要件
層や業務
）
えるには
応
今、 経営
に
池上 俊也
求
（
。
要
る
ス
探
ネ
ジ
ハウを
こうしたビ
らそのノウ
か
例
事
第一線の
14
NIKKEI SYSTEMS 2015.4
特 集
義
機能だけでは不十分 安・速・快の要件定義
PART 1 ［導入］ビジネス要求は非機能重視に....p.16
PART 2 ［事例］聞き方・決め方・描き方............. p.19
PART 3 ［解説］多様化する非機能要求............p.26
PART 4 ［研究］先駆者の非機能要件定義.......p.32
＜写真：Getty Images ＞
NIKKEI SYSTEMS 2015.4
15
PART
1
導入 ビジネス要求は非機能重視に
安・速・快が価値を生む
要件定義の変革が急務
安・速・快の非機能要求に経営層や業務部門の目が向けられている。
安とは「安心・安全」
、速とは「速度」
、快とは「快適性」だ。
もはや機能だけでは不十分。非機能要求に応える要件定義への変革が急務になっている。
東京・新宿の高層ビルの一角。ジャ
は、画面のボタン上に表示される為替
長 兼 基盤開発第一グループ長）は「画
パンネット銀行の外貨預金システムの
レートをリアルタイムで更新し、ボタ
面を集約すると当然、アクセスや処理
稼働開始を見届け、プロジェクトメン
ンを押したタイミングで約定するとい
が集中する。これが200ミリ～ 500ミリ
特 集
バー約50人は歓喜に沸いた。相反する
うもの。為替レートの更新頻度は、
秒という目標値の達成を阻んだ」と打
条件をクリアし、ビジネス要求に応え
200ミリ～ 500ミリ秒と、極めて短い
ち明ける。
機能だけでは不十分 安・速・快の要件定義
る業界初のリアルタイム取引システム
値に設定した。
「これほどのスピード
相反する要求の狭間で苦悩した。非
を完成させたからだ（図1）
。
は外国為替証拠金（FX）取引では前
機能要求の見直しは不可避だった。メ
「スピード感のある取引と、迷わな
例があったが、約定を含めた外貨預金
ンバーらは、事前にRFP（提案依頼書）
い画面操作を目指した」
。同プロジェ
システムでは例がなかった」
（北氏）
。
として示していた要求の見直しに着
クトを率いたジャパンネット銀行の北
一方、取引に必要な画面遷移を極
手。業務部門とともに優先順位を検討
周介氏（執行役員 CX本部長）はこう
限まで減らし、快適性を高める方針も
し「外貨から円にリアルタイムで換算・
振り返る。最後発なだけに、ビジネス
打ち出した。背景には、タブレットや
表示する」
「ユーザーが画面を自由にカ
的な価値の創出に挑戦したのだ。
スマートフォン
競合に勝つ「速度」と「快適性」
16
の 普 及 に 伴う、
北氏らが重視したのは、競合に勝つ
ティーへの対応
ための「どこにもない外貨預金システ
があった。
ム」だった。具体的には「スピード感
ところが、挑
のある取引」と「迷わない画面操作」
戦的なプロジェ
というビジネス要求を設定。速度（性
クトには大きな
能）と快適性（ユーザビリティー）と
壁が立ちはだか
いう、いわゆる「非機能要求」に高い
るもの。
「速度」
価値を見いだした。
を確保する要求
もちろん、金融機関の取引システム
と、1画 面 に 複
である以上、セキュリティと事業継続
数画面を集約す
性（BCP）という「安心・安全」が大
る「快適性」の
前提となる。つまり「安・速・快」と
要求には、
トレー
いう非機能要求を実装してこそ、高い
ドオフの関係が
価値を創出できる。
あった。同 社・
ただし、
このままでは要求は曖昧だ。
ITインフラ担当
北氏らは、速度と快適性の要求を詳細
の宮本昌明氏
化していった。具体的に速度について
（開発二部 副部
NIKKEI SYSTEMS 2015.4
ビジネス要求
ユ ー ザ ビ リ
スピード感の
ある取引
■要件定義のポイント
（1）価値の創出
速度
（2）要求の再定義
迷わない
（3）
アーキテクチャーの工夫
画面操作
快適性
開発に当たったプロジェクトメンバー
機能だけでは不十分
安・速・快 の要件定義
スタマイズできる」などの要求を、
「速
らは、要件定義の段階でシステム構成
ログイン用のWeb-APサーバーを分離
度」を優先する代わりに取り下げた。
のアーキテクチャーを見直し始めた。
し、前者を200ミリ～ 500ミリ秒のリア
当初想定していたアーキテクチャー
ルタイム更新、後者を10秒間隔の更新
う要求も、
瞬時に描画するのではなく、
は、クラスタリングした物理サーバー
とするアーキテクチャーに変更した。
一定間隔でチャート画像を画面に張り
に対して、各アクセスをロードバラン
これで、機会損失を避けつつも、利用
付ける要求へと変更した。あくまでも
サー（負荷分散装置）で振り分けるも
ユーザーを絞り込める。その結果、サー
速度を最優先した結果である。
の。しかし、各サーバーは高い頻度で
バーリソースを追加することなく、予
これで目標値を達成できる。そう考
為替レートを同時に取り込む。このた
定していたリアルタイム取引を実現で
えたがベンダーの開発者と検討したと
めどうしても、為替レートを管理する
きた。
ころ、まだ足りなかった。投資コスト
サーバーの負荷が高まる上に、ネット
は限られている。
「ユーザー数を減ら
ワークトラフィックにも大きな影響を
す」という、ビジネス上極めて選択し
与えていた。
ここ最近、ビジネス要求として「非
にくい判断を迫られた。
どう解決するか。宮本氏らはあえて
機能」を重視する動きが広がっている。
「為替チャートをつど描画する」とい
経営層や業務部門が非機能を重視
視点に立った。それは「ログインして
リティとBCPへの関心が特に高まって
普通に考えれば、速度を優先するた
いないユーザーに対しては、為替レー
いる。一方の業務部門は、性能や停止
めに利用ユーザーを限定するのは本末
トをリアルタイムで表示しなくてもよ
時間、ユーザビリティーを強く要求す
転倒といえる。本来はリソースを追加
いのではないか」という発想だ。
るようになった」
。こう説明するのは、
する必要があるが、それではコストが
もともと同システムの価値とは、リ
プライスウォーターハウスクーパース
青天井となりかねない。そこで宮本氏
アルタイムで為替レートを表示するだ
の一山正行氏（シニアマネージャー）
けでなく、
「ボタ
だ。その上で「背景には事件や災害、
ンを押したタイ
情報システムの社会的影響の拡大など
ミングで約定で
がある」と一山氏は話す。
きる」点だった。
こうした要求は、いわゆる「非機能」
このリアルタイ
に当たり、業務処理を担う「機能」で
ム取引の恩恵を
はない。つまり現在の情報システムで
受けるのは、ロ
は、機能だけでは不十分。非機能の実
グインしている
装も必要条件なのだ。
ユーザー の み。
もっとも、非機能要求を重視する動
ならば未ログイ
きは、今に始まったことではない。代
ンのユーザーは、
表的な動きとして、2010年に大手ベン
アクセス先を分
ダー 6社が共同で策定した「非機能要
け、為替レート
求グレード」
がある。非機能要求グレー
の更新頻度を下
ドは、発注側が要求する非機能につい
げても構わない
て、可用性や性能・拡張性といった六
―。
つのカテゴリーに分け、全部で236項
さっそくメン
目のメトリクス（指標）とレベル（グ
バーらは、ログ
レード）を定義している。現在は情報
イン 用 のWeb-
処理推進機構（IPA）が公開し、誰で
APサーバーと未
も無償で利用できる状況だ。
新・外貨預金システム
200ミリ∼500ミリ秒
間隔で、
ボタン上の
為替レートを更新
複数の画面を
1画面に集約
1 ジャパンネット銀行の新規構築プロジェクト
図
ビジネス要求として強く求められたのは「速度」と「快適性」
。最後発の外貨預
金システムで価値を創出するため、非機能を重視した要件定義を実施した
NIKKEI SYSTEMS 2015.4
機能だけでは不十分 安・速・快の要件定義
「経営層は投資対効果とともに、セキュ
特 集
技術的な視点ではなく、ビジネス的な
ログインユーザーに絞って突破
17