All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
6
-＜プロジェクト概要＞
プロジェクト運営方針
チーム内の合意形成
Challenge “10” msec !
高速性と信頼性を両立する、世界一の取引所システムを創る。
①
上流工程“完璧主義”
＜品質管理＞
設計書レビューの徹底。問題点へのリアルタイム対応。
要件トレーサビリティの確保。
②“ライフサイクル”コスト・セーブ
＜コスト管理＞
コスト管理の意識強化。発生ベースの月次管理。
③“デジタル”予実管理
＜スケジュール管理等＞
進捗、品質、リスクレベルの予定と実績をリアルタイムに
数値評価し、プロジェクトを可視化。
④
“次世代”育成
＜人材育成＞
ＩＴで価値を創造できる人材の育成。ＩＴ総合力の強化。
⑤
“ワイガヤ”民主主義
＜ｺﾐｭﾆｹｰｼｮﾝ管理＞
率直な意見交換。カウンターパートの“人となり”を知る。
⑥“先手必勝”リスク制圧
＜リスク管理＞
ＱＣＤについて予防的・継続的なリスク・モニタリングと
リスク・ヘッジ。
◆プロジェクト管理方針
⑦リニアなスケールアウト
＜拡張性＞
ハードウェア増設によるリニアな拡張。
⑧
ミリセカンド・レスポンス
＜高速性＞
注文受付１０ミリ秒、情報配信５ミリ秒。
⑨Non Stop Market
＜信頼性＞
稼働率＝９９．９９９％。
⑩アタッチメント型業務ロジック
＜柔軟性＞
高速で普遍的なフレームワークと付け替え可能な業務ロジック。
⑪Simple is Best
＜ﾒﾝﾃﾅﾝｽ性
＞
主要業務ロジックの簡素化。付帯業務の外出し。
◆システム設計方針
◆スローガン
One Team, One Dream.
世界一のシステムを目指して頑張ろう！
◆会社間をつなぐスローガン
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
7
-東証側協力会社メンバー
約５０名
システム
テスト
＜プロジェクト概要＞
プロジェクトのスケジュール全体像
参加者接続テスト
2006年
2007年
2008年
2006年3月
2006年4月～8月
■
証券会社のCIO、
実務者ミーティング
計画策定
■
プロジェクト計画
2006年9月
■
欧米視察、 マイ
ルストーン公表
市場利用者と基本コンセプト、システム要件、開発投資計画等を協議
結合テスト
製造
▼接続仕様（第０版）説明会
2009年
■
システム構築
▼接続仕様（第１版）説明会
本番
稼動▼
詳細設計
内部設計
■
開発ベンダ選定
コンペ
富士通
選定
証券会社との十分なテスト期間を確保
▲
▲▲ ▲
▲
▲CIO
▲
▲
▲
▲
▲ ▲
▲実務者
▲
▲
▲
▲
▲
▲
▲
▲
プレ受入+受入テスト
東証プロパー 約２５名
開発体制
富士通メンバー ５００名以上（ピーク時）
2010
年
プロジェクトオフィスに全員集合！
要件定義＋外部設計
東証
ベンダ
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
8
-目的
会議体
主催者レベル
頻度
内容
経営層の
対話
プレジデント
レビュー
社長・会長
ほぼ３ヶ月毎
東証・富士通両社の経営トップレベルで
のプロジェクト全体レビューと方針の決定、
確認
ステアリング
コミッティ
関連役員
四半期毎
システム本部、関連業務部門を含めたプ
ロジェクト全体レビューと方針の決定、確認
CIOレベル
での
進捗・品質
チェック
工程会議
東証側CIO＋
ベンダ側担当
役員
１ヶ月毎
システム本部のプロジェクト全体レビュー
とアクションの決定
品質評価会議
CIO＋
プロジェクト
責任者
１ヶ月毎
当該工程の品質状況や次工程の準備状
況等を評価し、アクションを決定
全社ベース
で 移行・
稼動対応
全体移行
統制本部
専務＋全役員
2009年10月
～
２週間毎
本番移行に向けた準備状況について、
関連業務部門の対応状況も含め、進捗
表・チェックシートに基づき確認
稼動判定会議
社長＋全役員
＋関連部門
2009年11月
～
3回
稼動判定基準に基づき、稼動に向けた
準備・適合性をチェック
中間判定会議（準備状況）を11月、適合
状況を12月、１月（最終判定）で確認
＜プロジェクト概要＞
開発ベンダ、社内関連部門との合意形成
経営レベル
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
9
-＜プロジェクト概要＞
開発ベンダとの合意形成
実務レベル
開発ベンダとの週次ミーティングをテーマ毎に細かく設定し、密なコミュニケーションを継続。
8:30
9:00
10:00
11:00
12:00
13:00
14:00
15:00
16:00
17:00
18:00
運用・テスト・移行
分科会
T : 運用・テスト・移行チーム
F : テスト推進, テストツール,
運転制御, 運用, 移行
共通検討WG
(検討案件があれば開催)
GPM-C
T:マネージャー
東証本館にて
隔週開催
市場監視分科会
（自由検索）
T : 市場監視
F : 市場監視
外接分科会
T : 他システム連携チーム
F : 外部接続チーム
朝礼 (9:00)
朝会 (9:10)
市場監視
分科会
（画面開発）
T : 市場監視
F : 市場監視、ｸﾗｲｱﾝﾄ開発
FM/規制分科会
T : 売買監理チーム
F : FM/規制チーム
参加者
分科会
T : 参加者
チーム
F : 参加者
チーム
情報配信
分科会
T : 情報配信
チーム
F : 情報配信
チーム
市場監視
分科会
（共通）
T : 市場監視
F : 市場監視
朝会 (9:00) 朝礼 (9:00)
朝会 (9:10)
朝会 (9:00) 朝礼 (9:00)
朝会 (9:10)
朝会 (9:00)
東証
インフラ進捗
T: インフラチーム
富士通
朝礼 (9:00)
木
朝会 (9:10)
チーム間進捗会議
T : 全チーム
朝礼 (9:00)
東証
朝会 (9:00) 朝会 (9:00)
東証
時間
月
火
水
東証 富士通 東証 富士通 富士通
金
性能WG
(隔週実施)
T : インフラチーム
F : 性能チーム
内部検討
WG
(リーダー会終
了後)
朝会 (9:10)
標準化コミッティ
T : マネージャー
東証本館にて開催
基盤グループ進捗1
F : インフラ基盤, ネットワー
ク, システム運用, 性能
基盤グループ進捗2
F : アプリ基盤, GW基盤,
DB/DAM, 性能
お昼休み(11:45 ～ 12:45)
富士通
統合ネット
定例
Ｔ : 参加者・情報
配信・他シス連携・
インフラ・運用・テ
スト・移行チーム
リーダー会
F : マネー
ジャー,
グループ/サブ
リーダー
信頼性・拡張性WG
T : インフラチーム
F : 基盤グループ
プロジェクト進捗会議
T : マネージャー, PMチーム
F : マネージャー, グループリーダー,
プロジェクト推進グループ
FM/規制
チーム
進捗
Ｔ : 売買監理
チーム
プロジェクト
工程会議
(毎月最終火曜日)
インフラ分科会
T : インフラチーム
F : 基盤グループ
開発推進チーム
端末共通分科会
T : 端末共通
F : 開発推進、ｸﾗｲｱﾝﾄ開発、
ｱﾌﾟﾘ基盤（端末FW）
運用
グループ
進捗会
F:運用
グループ
業務
グループ
進捗会
F: 業務
グループ
開発標準分科会
T : 開発標準
F : 開発推進
部門間定例
T : マネージャー
東証本館にて隔週開催
品質マネージメント
定例
T : 品質管理チーム
F : 品質管理チーム
媒介/業務共通
分科会
T : 媒介チーム
F : 媒介／業務共通チーム
会
社
間
会
議
禁
止
会
社
間
会
議
禁
止
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
10
-注文
約定通知
受付通知
＜プロジェクト概要＞
システム概要図
プライマリサイト
arrowhead
参加者
参加者
相場
ユ
ー
ザ
東証
内
他
シス
テ
ム
参加者
参加者
GW
通知情
報
サーバ
問合せ
GW
相場情報
負荷分散
ﾄﾚｰﾃﾞｨ
ﾝｸﾞｻｰ
ﾊﾞ
ﾄﾚｰﾃﾞｨ
ﾝｸﾞｻｰ
ﾊﾞ
注文管理
サーバ
通知情
報
サーバ
ﾄﾚｰﾃﾞｨﾝｸﾞ
サーバ
売買監理
サーバ
④約定通
知
通知情
報
サーバ
通知情
報
サーバ
取引記録
サーバ
負荷分散
取引データ
ﾄﾚｰﾃﾞｨ
ﾝｸﾞｻｰ
ﾊﾞ
ﾄﾚｰﾃﾞｨ
ﾝｸﾞｻｰ
ﾊﾞ
情報配信
GW
相場
ユ
ー
ザ
セカンダリ
サイト
DB
サーバ
取引データ
ﾄﾚｰﾃﾞｨ
ﾝｸﾞｻｰ
ﾊﾞ
ﾄﾚｰﾃﾞｨ
ﾝｸﾞｻｰ
ﾊﾞ
外部接続
サーバ
清算情報
約定情報
負荷分散
売買情報
同期コピー
同期コピー
信頼性
拡張性
メモリＤＢ
堅牢性
参加者毎に負荷
分散するサーバ
銘柄毎に負荷
分散するサーバ
処理量見合で負荷
分散するサーバ
凡例：
AP規模3.5Mstep
C:
2.8Mstep
Java：0.7Mstep
サーバ台数
約２００台
メモリＤＢ
メモリＤＢ
メモリＤＢ
メモリＤＢ
高速性
“ミリ”秒の領域
秒レベルの領域
フロントサーバ群
バックサーバ群
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
11
-arrowhead
参加者GWサーバ
トレーディングサーバ
情報配信
GWサーバ
取引記録サーバ
取引
参
加
者
注文管理サーバ
データベース
サーバ
相場ユ
ー
ザ
市場監視
サーバ
＜プロジェクト概要＞
処理プロセス概要図
銘柄
テーブル
注文キュー
注文キュー
注文キュー
注文キュー
注文キュー
注文キュー
注文キュー
注文キュー
注文キュー
注文キュー
データ
ベース
注文受付
（銘柄、値段等
のチェック）
受付通知送信
約定通知送信
板登録・付合せ
（マッチング）
注文キュー
（参加者単位）
付合せ情報
キュー
約定通知作成
約定履歴作成
約定通知
キュー
相場情報
キュー
取引記録
キュー（出）
情報配信
取引記録
アプリケーション
キュー *
テーブル *
板情報
赤矢印
緑矢印
：注文応答処理の流れ
（所要２ミリ秒程度）
：情報配信処理の流れ
（所要３ミリ秒程度）
注文キュー
注文キュー
注文キュー
（銘柄単位）
すべてのデータをメモ
リー上に展開、3重化 *
注文キュー
注文キュー
取引記録
キュー（受）
市場監視
フロントサーバ群
バックサーバ群
バック系サーバがダウンしても
フロント系サーバのみで売買は継続可能
サーバ間はメッセージ・キューで非同期通信
→アプリの品質やシステムの可用性を疎に分離
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
12
-0
5
10
15
20
25
30
8:008:158:308:459:009:159:309:4510:0
0
10:1
5
10:3
0
10:4
5
11:0
0
11:1
5
11:3
0
11:4
5
12:0
0
12:1
5
12:3012:4
5
13:0
0
13:1
5
13:3
0
13:4
5
14:0
0
14:1
5
14:3
0
14:4515:0
0
ミリ秒
概ねザラバ中において目標値である10ミリ秒を大幅に下回る2ミリ秒で安定。
日中を通じてほぼブレがなく、一定のレベルを保っている。
実績 2ミリ秒
実績 2ミリ秒
目標 10ミリ秒
目標 10ミリ秒
時間帯別 注文受付レスポンスの推移（2010/04/13）
注文受付
時間帯
立会時間帯
注
文
受
付
時
間
帯
立会時間帯
＜プロジェクト概要＞
高速性（注文受付レスポンス）の目標と実績
0
5
10
15
20
25
30
時刻→
↑ミリ秒
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
13
-＜発注者責任の明確化＞
従来の開発プロセスの問題点と要因
問題点
要因
対応すべき者
発注者
受託者
① ベンダ提案の精度が低い
RFPの記述粒度が不十分
○
△
② 要件と実装の齟齬が多い
要件定義の一部に漏れや
曖昧性
○
△
③ 納品時の品質が悪い
品質管理が不十分
△
○
④ 納品遅延の予見ができない
工程管理が不十分
△
○
⑤
稼動準備状況・稼動品質の
見極めが雑駁
稼動可否チェックが不十分
○
△
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
14
-RFP
作成
①第三者（コンサル）の参画
②ＲＦＰ詳細化（約１５００
ページ）
詳細な要件定義書の作成
内部設計書の作成
詳細設計書の作成
東証
開発
ベ
ン
ダ
ー
③要件定義・外部設計の詳細化
（要件定義書＋外部設計書で
４０００ページ）
④第三者による品質チェック
（要件定義書の記述項目の網羅性等）
⑤内部設計と外部設計の分離
⑥外部設計の内製化
⑦注文受付から約定結果送信、相場情
報配信までの処理パターンを網羅的に
洗い出して、テストシナリオとして利用
⑧要件定義（約1万項目）が設計書に反
映されていることのトレース
提案書
評価
⑨東証とベンダーが
ひとつのプロジェクト
オフィスに集結
性能マネジメント計画書
拡張性マネジメント計画書
信頼性マネジメント計画書
⑩システム要件を確実に達
成するための手引書
要件トレース表の作成
外部設計書の作成
発注者責任の明確化
開発
ベンダー
の決定
オークションパターン
の作成
ベンダー選定プロセス
要件定義／設計プロセス
設計プロセス
＜発注者責任の明確化＞
開発プロセスの改善
発注者は内部的な責任をベンダ側に依存しがち。
でもトラブルが発生すれば、対外責任は全て発注者。
発注者が真に責任を負える体制が必要。
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
15
-＜発注者責任の明確化＞
発注者とベンダとの間のリスク共有
本プロジェクトのシステムテスト工程でのバグ密度の目標値＝０．３件／kstepとし、
これを按分した０．１５件／kstepを東証および開発ベンダの目標バグ密度と設定。
システムテストでのバグ密度の実績値＝０．２３件／kstepで、目標値をクリア。
品質の責任者
バグ混入工程
バグの原因
強化ポイント
東証
要件定義
要件の齟齬
詳細設計工程での
業務要件に関わる
レビューの強化
基本設計
業務要件の齟齬
詳細設計
業務要件の齟齬
開発ベンダ
詳細設計
実現方式の齟齬
製造工程での
単体テストの強化
製造
全般
上流工程での不具合の刈り取りを促し、下流工程への不具合のすり抜けを牽制
することを目的として、東証、開発ベンダそれぞれの責任範囲を決めて、下流のシ
ステムテストでのバグ件数の目標値を設定。
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
16
-＜要件定義プロセスの高度化＞
要件定義書の体系（鳥瞰図）
・全体業務フローと業務フロー図で業務の流れを俯瞰・要件の抜け漏れを確認
・それをもとに要件定義書、外部設計書を作成
要件定義書
業務フロー図
全体業務フロー
要件定義書
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
17
-＜要件定義プロセスの高度化＞
要件変更の分析による要件品質向上
要件定義の変更内容を１件毎にプロジェクトで審査。同時に変更内容を分析し、前工程
の悪さを引きずることのないよう品質改善策を実施。
変更管理
原因工程、発見契機、内容、傾
向を踏まえて、同様の悪さが該
当チーム、他チームに潜んでい
ないかを分析
誤字脱字も含め、要件定義に
修正を行う場合は１件毎に承認
プロセスを実施
同様の悪さが潜んでいる可能
性がある場合には、プロジェクト
横断でチェックし、アクション
分析資料
【例】
■事象
画面項目定義に「ＸＸ値段」とい
う曖昧な表現があり、そのため
に設計上で誤解が生じてい
た・・・
■アクション
プロジェクト横断でチェックし、
同様の項目や定義を行って
いるサブシステムＡ、サブシス
テムＢについて画面項目定義、
帳票出力の項目定義を改善
■分析
同項目は他のサブシステム
でも利用しており、同様のミス
が潜んでいる可能性が高い
要件変更の内容はもとより、発生起因がベンダか東証か、発生契機が要件の検討過程、レビュー過程、方式検討
過程か等のポイントで分析。要件の不具合が摘出すべき工程で行われているかチェックし、アクションを実施
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
18
-外部設計 内部設計
＜要件定義プロセスの高度化＞
オークション・パターンの作成（Wモデル）
コア業務である媒介処理に係る業
務要件を中心として、旧売買シス
テムの標準テストケースをもとに
「オークションパターン」を作成。
要件定義
詳細設計
製造
ベンダテスト 受入テスト
■基本設計～内部設計
参加者-媒介処理-ＦＭ-規制-情報配信-板絵（＝
端末画面）について、代表的な状態遷移・イベン
トパターンで整理し、システム全体としての要件
確認、設計の整合性の確認を行った。
どうしても方式があらあらで、かつサブシステ
ム毎に業務ロジックの設計を進めがちな中で、一
体的に設計をチェック、東証もその後のテストパ
ターンの整理が出来た。
オークションパターン
■詳細設計
媒介パターンも踏まえて作成・レ
ビューされた内部設計書をもとに詳
細設計書が作成された。
詳細設計のレビューの際にも役立
ち、設計ミスの早期発見に寄与した。
■結合テスト
結合テストのテストバリエーションの確
認において有用だった。
■受入テスト準備
上流工程で整理していたため、受入テス
トに向けて深化させ、それをベースにテ
スト準備をすることでＯＫになった。ま
た、テストケース作成、データ準備にも
そのまま利用することができた。
工程
実施
内容と成
果
各設計書へのフィードバック
PDCA
オークションパターンチェック
要件定義書
東証テストケース
オークションパターンチェック
旧システム
標準テスト
ケース
効果：
①要件の網羅性確認
②ベンダ側の具体例に基づいた要件理解
③テストケース作成へのスムーズな移行
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
19
-＜要件定義プロセスの高度化＞
オークション・パターン
サンプル
中項目寄前気配の場合
ID
媒-FLEX01
小項目 確認内容 現システム想定されるケース 要件定義書記載
Ｉ Ｄ
1片玉／売／指値(1～8気配)／1値段① － NO+Q1～Q8 ●
2片玉／売／指値(9気配以上含む)／1値段① － NO+Q1～Q8+QO
3片玉／売／指値(1～8気配)／1値段①＋非優先注文入力 － NO+Q1～Q8
4片玉／売／指値(9気配以上含む)／1値段①＋非優先注文入力 － NO+Q1～Q8+QO
22両玉／成行＋指値(1～8気配)／対当価格あり － NO+Q1～Q8+QM
23両玉／成行＋指値(9気配以上含む)／対当価格あり － NO+Q1～Q8+QM+QO ●
「パターンに対当値段あり」の記載について、
当パターンは、注文受付中にて対当値段がある
を意味している。
よって、付合せは執行されていない。
遷移パターンを作成
各項目の詳細内容を別途作成。
オークション内部処理と外部出
力データの関係がチェックでき、
「②ベンダ側ケーススタディ的
要件理解の進展」に役立つ。
小項目ＩＤ
寄前／ザラバ
：板中心値段
引累計 数量 数量 累計引 引累計 数量 数量 累計引
3030 成行 1818 3030 成行 1818 ①
12241 OVER 18 13241 OVER 18 タグ タグ 値段 時刻 数量
812 107 18 912 107 18 ＮＯ Q1 99 8：45 63
79 106 18 89 106 18 Q2 100 8：45 5
795 105 1028 895 105 1028 Q3 103 8：45 3
743 104 1038 843 104 1038 Q４ 104 8：45 3
713 103 1553 813 103 1553 Q5 105 8：45 5
68 102 53 78 102 53 Q6 107 8：45 2
68 101 558 ⇒ 78 101 558 Q7 109 8：45 2
685 100 58 785 100 58 Q8 110 8：45 4
638#99#361 738 99 361 タグ 時刻 数量 時刻 数量
5510 98 364 6510#98#364 QO 8：4535 8：4338
4515 97 64 5515 97 64
30 96 569 40 96 569
30 95 574 4010 95 574
30 94 579 30 94 579
30 93 79 30 93 79
30 UNDER 48127 30 UNDER 48127
① ② ②
タグ タグ 値段 時刻 数量
30 成行 18 30 成行 18 ＮＯ Q1 98 8：47 65
35 OVER 39 OVER Q2 99 8：47 8
4 110 2 109 Q3 100 8：47 5
2 109 2 107 Q４ 103 8：47 3
2 107 5 105 Q5 1 104 + 8：47 1 3 + 1
1
1 + 1 +
1
1 + 1 +
1
1 + 1 +
00000052 1 + 0 + 1
気配符号 変化フラグ
更新番号 変化フラグ 値段符号 気配フラグ
1 ＋ △ +
変化フラグ 数量フラグ 変化フラグ 数量フラグ
1
1 + 1 +
1
1 + 1 +
1
1 + 1 +
1
1 + 1 +
1
1 + 1 +
1
1 + 1 +
1 + 1 + 1
00000051 1 + 0 + 1
値段符号 気配フラグ 気配符号 変化フラグ
連続約定気配自動執行時間60秒
更新番号 変化フラグ
特別気配表示後自動執行時間－
連続約定気配値幅 10円
23
更新値幅 5円
中項目ＩＤFLEX01 寄前気配の場合
特別気配自動更新時間 5分
特別気配自動表示値幅 －
リアル板
FLEX板
リアル板
FLEX板
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
20
-＜要件トレーサビリティ＞
要件トレーサビリティとは？
要件定義は完璧に作ったつもりだけど、これが、１００％成果物に反映されている
ことをどう確認すればいいのか？
ひとつひとつの要件要素が設計書のどこに書かれていて、どのテスト項目で確認す
るのか、リンクがされていれば良い！
このしくみが、要件トレーサビリティ
要件定義は完璧に作ったつもりだけど、これが、１００％成果物に反映されている
ことをどう確認すればいいのか？
ひとつひとつの要件要素が設計書のどこに書かれていて、どのテスト項目で確認す
るのか、リンクがされていれば良い！
このしくみが、要件トレーサビリティ
要件要素
1.1.1 xxxx
1.1.2 yyyy
1.1.3 zzzz
1.2.1 wwww
2.1.1 qqqq
基本設計
A.1.1 dddd
A.1.2 eeee
B.1.1 ffff
B.1.2 gggg
C.1.1 hhhh
詳細設計
1.1.1 xxxx
1.1.2 yyyy
1.1.3 zzzz
1.2.1 wwww
2.1.1 qqqq
2.1.2 mmmm
3.1.1 nnnn
4.1.1 vvvv
テスト項目
A.1.1 xxxx
A.1.2 yyyy
A.1.3 zzzz
B.1.1 wwww
B.1.2 qqqq
C.1.1 ssss
C.1.2 zzzz
D.1.1 rrrr
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
21
-＜要件トレーサビリティ＞
要件トレーサビリティ：設計フェーズ
・ 要件定義書を項目化した要件トレース表（mini要件定義書)を作成
・ どの要件項目がどの設計書に記載されているかのトレースを実施
・ 設計が変わるタイミングで部分トレースによって紐付け情報喪失を防止
ポイント
●東証⇔富士通の担当チー
ムの境界線の違い
●工程で詳細化する部分の
追加の紐付け
●バージョン管理
（要件と設計の非同期の
改訂）
次工程でさらなる活用
●テストケース作成にも利
用
●データベース化して自動
チェック
要件
項
目
要件トレース表（抜粋）
要件内
容
設計書紐付け情
報
EXE- 0 0 1 0 0 - 0 0 11 板とは
注文を受け付け順に「板」に登録
銘柄毎の注文を売買別、値段別に整理
同一値段の複数注文を記載するケースでは、時間的に早く
板登録した注文を中心に近く記述する
同時呼値
同時呼値とは、規則上、約定における時間優先（登録時間
順）にとらわれずに同時に受付けられたとみなされる注文
板の各値段に登録されている注文が取引参加者単位に集
計（名寄せ）され､合計注文数量の多い取引参加者から少
ない取引参加者の順に付合せ処理時の約定数量の配分を
行う。
同時呼値は、次の状況における注文
① 始値（場単位）が決定される以前に板登録された注文
（直前の場において約定せずに引き継がれた注文含む。）
② 売買停止（市場停止を含む）から売買を再開した後の最
始値（場単位）決定時、売買停止解除後最初の約定値段
決定時、ストップ配分方式による約定値段決定時及び同一
値段に引け条件付注文が複数ある場合における立会終了
時の約定値段決定時には、その時点で有効な同時呼値を
同時呼値は、約定処理において始値等の決定後に板登録
された注文（ザラバ注文）とは区別して扱われる。同時呼値
が始値決定後に板に残っている場合、当該同時呼値と同じ
値段に登録されたザラバ注文は、当該同時呼値が全て約
引け条件付注文は、立会終了時以前の同時注文およびザ
ラバ注文とは区別して扱う。
立会終了時以前の同時注文、またはザラバ注文が
立会終了時に板に残っている場合、当該注文と同じ値段に
登録された引け条件付注文は、立会終了時以前の同時注
文、およびザラバ注文が全て処理された後に約定対象とす
EXE- 0 0 1 0 0 - 0 0 31
項目名
機能
関連業務
ルールID
業務
ルールID
項
番
1 2 3 4
①
参
加
者
か
ら
の
新
規
／
変
更
／
取
消
注
文
入
力
（
新
規
注
文
）
②
参
加
者
か
ら
の
新
規
／
変
更
／
取
消
注
文
入
力
（
変
更
注
文
）
③
参
加
者
か
ら
の
新
規
／
変
更
／
取
消
注
文
入
力（
取
消
注
文）
④
取
引
所
売
買
監
理
端
末
か
ら
の
有
効
注
文
取
消
⑤
時
間
外
ま
た
は
場
間→
注
文
受
付
開
始
⑥
注
文
受
付
中→
立
会
開
始
● ● ●
対応済
DA360 同時呼値の引き直し
DA300 付合せ約定処理
概要、2. 同時呼値注文の配分処理
対応済
①始値（場単位）決定時、
DA006 立会開始 1. ステータス変更処理
DA920 板寄せ方式対当値段算出時の約
定処理
● ● ●
２．立会ｽｹｼﾞｭｰﾙ
１．注文入力／変更／取消
状
況
内部設計書２
ドキュメント名
同時呼値
同時呼値とは、規則上、約定における時間優先（登録時間
順）にとらわれずに同時に受付けられたとみなされる注文
板の各値段に登録されている注文が取引参加者単位に集
計（名寄せ）され､合計注文数量の多い取引参加者から少
ない取引参加者の順に付合せ処理時の約定数量の配分を
行う。
同時呼値は、次の状況における注文
① 始値（場単位）が決定される以前に板登録された注文
（直前の場において約定せずに引き継がれた注文含む。）
② 売買停止（市場停止を含む）から売買を再開した後の最
対応済
DA360 同時呼値の引き直し
DA300 付合せ約定処理
概要、2. 同時呼値注文の配分処理
EXE- 0 0 1 0 0 - 0 0 11 板とは
注文を受け付け順に「板」に登録
銘柄毎の注文を売買別、値段別に整理
同一値段の複数注文を記載するケースでは、時間的に早く
板登録した注文を中心に近く記述する
同時呼値
同時呼値とは、規則上、約定における時間優先（登録時間
順）にとらわれずに同時に受付けられたとみなされる注文
板の各値段に登録されている注文が取引参加者単位に集
計（名寄せ）され､合計注文数量の多い取引参加者から少
ない取引参加者の順に付合せ処理時の約定数量の配分を
行う。
同時呼値は、次の状況における注文
① 始値（場単位）が決定される以前に板登録された注文
（直前の場において約定せずに引き継がれた注文含む。）
② 売買停止（市場停止を含む）から売買を再開した後の最
始値（場単位）決定時、売買停止解除後最初の約定値段
決定時、ストップ配分方式による約定値段決定時及び同一
値段に引け条件付注文が複数ある場合における立会終了
時の約定値段決定時には、その時点で有効な同時呼値を
同時呼値は、約定処理において始値等の決定後に板登録
された注文（ザラバ注文）とは区別して扱われる。同時呼値
が始値決定後に板に残っている場合、当該同時呼値と同じ
値段に登録されたザラバ注文は、当該同時呼値が全て約
引け条件付注文は、立会終了時以前の同時注文およびザ
ラバ注文とは区別して扱う。
立会終了時以前の同時注文、またはザラバ注文が
立会終了時に板に残っている場合、当該注文と同じ値段に
登録された引け条件付注文は、立会終了時以前の同時注
文、およびザラバ注文が全て処理された後に約定対象とす
EXE- 0 0 1 0 0 - 0 0 31
項目名
機能
関連業務
ルールID
業務
ルールID
項
番
1 2 3 4
①
参
加
者
か
ら
の
新
規
／
変
更
／
取
消
注
文
入
力
（
新
規
注
文
）
②
参
加
者
か
ら
の
新
規
／
変
更
／
取
消
注
文
入
力
（
変
更
注
文
）
③
参
加
者
か
ら
の
新
規
／
変
更
／
取
消
注
文
入
力（
取
消
注
文）
④
取
引
所
売
買
監
理
端
末
か
ら
の
有
効
注
文
取
消
⑤
時
間
外
ま
た
は
場
間→
注
文
受
付
開
始
⑥
注
文
受
付
中→
立
会
開
始
● ● ●
対応済
DA360 同時呼値の引き直し
DA300 付合せ約定処理
概要、2. 同時呼値注文の配分処理
対応済
①始値（場単位）決定時、
DA006 立会開始 1. ステータス変更処理
DA920 板寄せ方式対当値段算出時の約
定処理
● ● ●
２．立会ｽｹｼﾞｭｰﾙ
１．注文入力／変更／取消
状
況
内部設計書２
ドキュメント名
同時呼値
同時呼値とは、規則上、約定における時間優先（登録時間
順）にとらわれずに同時に受付けられたとみなされる注文
板の各値段に登録されている注文が取引参加者単位に集
計（名寄せ）され､合計注文数量の多い取引参加者から少
ない取引参加者の順に付合せ処理時の約定数量の配分を
行う。
同時呼値は、次の状況における注文
① 始値（場単位）が決定される以前に板登録された注文
（直前の場において約定せずに引き継がれた注文含む。）
② 売買停止（市場停止を含む）から売買を再開した後の最
対応済
DA360 同時呼値の引き直し
DA300 付合せ約定処理
概要、2. 同時呼値注文の配分処理
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
22
-＜要件トレーサビリティ＞
要件トレーサビリティ：結合テスト・システムテスト
・ 要件と結合テスト・システムテストのテストケースの紐付けにより要件網羅性の確認
ポイント
●要件一覧の常時最新化
●評価タイミングの妥当性
●障害発生時に未充足状態へ戻り
次工程でさらなる活用
●東証内確認でのクロスチェック
●データベース化して集計簡略化
＜結合テスト・システムテストフェーズでの要件トレーサビリティ確保プロセス＞
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
23
-＜要件トレーサビリティ＞
要件トレーサビリティ：受入テストフェーズ
・要件要素ID、設計書ID、受入テストIDを紐付けて一元管理
・充足状況をリアルタイムで可視化
ポイント
●要件要素、テストケースの
粒度設定
●システム全体での一律管理
●要件充足進捗の妥当性評価
●要件定義書の世代管理によ
り、追加や変更の要件充足
確認漏れの防止
（要件定義完了時：11,000件
⇒ 稼働時：12,000件）
稼働後でさらなる活用
●要件変更に対応
●ノウハウの他プロジェクト
への展開
集計・分析
＜要件トレーサビリティの管理イメージ＞
ﾃｽﾄｹｰｽID ﾃｽﾄｹｰｽ名世
代ﾁｰﾑ大分類 中分類 小分類 想定結果
ｹｰｽ
内
件数
要件要素ID 設計書ID
HBV50-0020001初期画面表示時の検索
条件 1HBV50:発注状況002:画面レイ ア
ウト
0001:メニュー画面から
遷移した場合の検索条
検索条件には、以下の値が表示されている こと
※ここに記載が無い項目は「空白」となる 1
MON-00200-006_10.2.1.0 HBv0050
HBV50-0020002成行を 含むチェ ックボッ
クス 1HBV50:発注状況002:画面レイ ア
ウト
0002:成行を 含むチェ ッ
クボックス＝ON
範囲指定した注文値段と一緒に、成行注文も表示される こと
※検索条件の 1
MON-00200-006_40.26.0.0 HBv0050
HBV50-0020003取引所ごとに異なる 市
場区分の表示確認 1HBV50:発注状況002:画面レイ ア
ウト
0003:プ ルダウン リスト:
市場区分
取引所区分に応じた市場区分が選択できる こと
※ただし、00:全市場は選択不可 1
MON-00200-006_40.3.0.0;MON-HBv0050
HBV50-0020004同一注文の不変項目非
表示 1HBV50:発注状況002:画面レイ ア
ウト
0004:同一注文情報の非
表示対象項目
同一注文の2行目以降は、以下の項目値が表示されないこと（空白とな
る ） 1
MON-00200-006_40.12.0.0 HBv0050
HBV50-0020005成行注文の値段欄表示
1HBV50:発注状況002:画面レイ ア
ウト
0005:成行注文の値段表
示
注文値段が成行の場合は、”成行”と表示する こと
1
MON-00200-006_40.14.0.0 HBv0050
HBV50-0030001参加者検索のショ ート
カ ットキー D1HBV50:発注状況003:画面イ ベン
ト
0001:参加者検索の
ショ ートカ ットキーが有
ショ ートカ ットキー(F4)押下によ る 参加者検索機能が有効となる のは、
検索条件の参加者コード１（最上段）のみである こと 1
UIF-00100-001_30.9.1.0 HBv0050
HBV50-0030002並び順を 指定した検索
結果表示（受付時刻順）1HBV50:発注状況003:画面イ ベン
ト
0002:表示順＝＜1:受付
時刻順＞で照会
照会結果の並び順が、注文受付番号ごとに、新規注文の注文時刻の昇
順に表示され、その各注文受付番号内の取引は、板更新回数の昇順に1
MON-00200-006_40.28.0.0;MONHBv0050
HBV50-0030003並び順を 指定した検索
結果表示（値段順） 1HBV50:発注状況003:画面イ ベン
ト
0003:表示順＝＜2:値段
順＞で照会
照会結果の並び順が、注文受付番号ごとに、新規注文の値段の降順に
表示され、その各注文受付番号内の取引は、板更新回数の昇順に表示1
MON-00200-006_40.28.0.0 HBv0050
HBV50-0030004銘柄コードを 指定しない
（未入力）状態で、共通D1HBV50:発注状況003:画面イ ベン
ト
0004:銘柄コードが未入
力
プ ルダウン の共通ヘッダ表示が、”無し”となり、編集不可能となる こと
1
MON-00200-006_30.1.0.0 HBv0050
HBV50-0030005共通ヘッダ画面が開設
していない状態で、共通1HBV50:発注状況003:画面イ ベン
ト
0005:共通ヘッダ表示＝
＜1:有＞、かつ共通ヘッ
発注状況の照会結果が表示される のと同時に、共通ヘッダ画面が自動
で表示、照会が行われる こと 1
MON-00200-006_40.1.0.0;MON-HBv0050
HBV50-0030006共通ヘッダ画面が既に
開設している 状態で、共D1HBV50:発注状況003:画面イ ベン
ト
0006:共通ヘッダ表示＝
＜1:有＞、かつ共通ヘッ
発注状況の照会結果が表示される のと同時に、共通ヘッダ画面の内容
が更新される こと 1
MON-00200-006_40.1.0.0;MON-HBv0050
HBV50-0030007共通ヘッダ画面が開設
していない状態で、共通D1HBV50:発注状況003:画面イ ベン
ト
0007:共通ヘッダ表示＝
＜0:無＞、かつ共通ヘッ
共通ヘッダ画面は表示されないこと
1
MON-00200-006_40.1.0.0;MON-HBv0050
HBV50-0030008共通ヘッダ画面が既に
開設している 状態で、共D1HBV50:発注状況003:画面イ ベン
ト
0008:共通ヘッダ表示＝
＜0:無＞、かつ共通ヘッ
共通ヘッダ画面の表示内容は、更新されないこと
1
MON-00200-006_40.1.0.0;MON-HBv0050
HBV50-0030009符号・通知番号表示設
定の確認 1HBV50:発注状況003:画面イ ベン
ト
0009:「符号通知番号表
示」を ＜0:無＞とした場
照会した結果について、「銘柄コード」「上場区分」「整理監理区分」「信用
貸借区分」「権利落ち 符号」「参加者コード」「社内処理用項目」「板更新 1
MON-00200-006_30.2.0.0 HBv0050
ﾃｽﾄｹｰｽと要件をIDで紐付けて管理
ﾃｽﾄｹｰｽID
ﾃｽﾄｹｰｽ名
世
代
HBV50-0020001初期画面表示時の検索
条件 1
HBV50-0020002成行を 含むチェ ックボックス 1
HBV50-0020003取引所ごとに異なる 市
場区分の表示確認 1
HBV50-0020004同一注文の不変項目非
表示 1
HBV50-0020005成行注文の値段欄表示1
要件要素ID
MON-00200-006_10.2.1.0
MON-00200-006_40.26.0.0
MON-00200-
006_40.3.0.0;MON-
MON-00200-006_40.12.0.0
MON-00200-006_40.14.0.0
受入テストにおける要件充足状況
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
30
-＜タスクの優先度付け＞
本番稼働間際における障害仕分け
・本番稼働前２ヶ月間に発生した障害は、業務影響度と修正リスクとを勘案して、
稼働前に改修するか、当面は運用対処として稼動後の改修とするかを判断。
ランク
定義
発生件数
A
業務影響があり、稼動までに対処が必要
91
B
運用回避が可能だが、修正が軽微
16
C
運用回避が可能で、業務影響が軽微
64
D
ドキュメントのみの修正
25
バグ修正を稼働後に延期する
ことで、システム変更に伴う
リスクを回避。
システムの中核となる媒介は０件。
参加者接続、情報配信は１件ずつ
のみ。（計２件）
残り89件は、周辺業務でのバグ。
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
31
-＜リスク管理＞
arrowheadにおけるリスク管理の特徴
１．リスクの“発生確率レベル”と発生時の“影響度”でスコア付け
２．リスク“発生確率レベル”の低減計画を策定し、予実管理を実施
３．リスクが顕在化したら、影響度を１．５倍に拡大し、重点的に管理
４．全リスクの予定スコア合計と実績スコア合計を比較⇒プロジェクト全体のリスク低減状況をチェック
１.リスクスコアの算出方法
発生確率レベル
×
影響度
＝
リスクスコア
・リスクスコアが「3」以上のリスクをプロジェクトでの
管理対象とした。
・リスクスコアが「6」以上のリスクを工程会議において
モニタリングすることとした。
７段階に分類し、管理
⇒ 次ページの具体例参照
リスクが顕在化した場合の
影響度を3段階で評価
影響度
評価内容
3
プロジェクトのベースラインに
影響を与える場合
2
プロジェクトで吸収可能な中程度
の影響を与える場合
1
影響が軽微な場合
リスクと課題の一元管理
①リスクが課題化したら
⇒影響度を1.5倍に拡大
②課題が解決したら
⇒影響度を元の値に戻す
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
32
-＜リスク管理＞
リスクの低減計画と予定／実績管理
「プロジェクトにおいて計画されている作業やイベントの実行」と「リスク発生確率レベルの低減」との関連性を、
あらかじめ定義し、計画どおりに作業等が実行されたことによりリスクスコアが低減していたことを確認する。
発生確率
レベル
リスクに関する状況
モニタリング
実現時期
監視内容
3
プロトコルを一新することについて、参加者の理解を
得られていない
－
－
2.5
新プロトコルにおける主要な変更点について参加者の
理解が得られている
2006年9月
ＣＩＯ－Ｍ、実務者－Ｍで新プロトコルの
方針について合意することを確認
2
大手、外資等の代表的な参加者に新プロトコル案を提
示し、合意が得られている
2007年3月
実務者－Ｍで新プロトコルdraft（第０版）
を提示し、合意、することを確認
1.5
全参加者に新プロトコル案を提示し、合意が得られて
いる
2007年5月
参加者説明会で新プロトコルdraft（第０
版）を提示し、合意することを確認
1
全参加者に新プロトコルを確定仕様として提示してい
る
2007年7月
第２回参加者説明会で新プロトコル（第１
版）を提示し、合意することを確認
0.5
パイロットユーザテストで新プロトコルに関連する問
題が生じない、または生じた問題への対応が完了する
2009年2月
パイロット参加者による実機テストで問題
なく接続可能であることを確認
0
参加者接続テストで新プロトコルに関連する問題が生
じない、または生じた問題への対応が完了する
2009年10月
参加者接続テストを問題なく実施できるこ
とを確認
＜リスク低減計画例：取引参加者が新プロトコルに対応できないリスク＞
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
33
-＜リスク管理＞
プロジェクト全体のリスク状況把握
個別のリスクについての予定／実績管理を行うとともに、全リスクの予定リスクスコアの合計値と
実績リスクスコアの合計値を比較管理することにより、プロジェクト全体のリスク状況の把握を行っ
た。
0
50
100
150
200
250
300
350
400
450
2006年7月 2006年11月 2007年3月 2007年7月 2007年11月 2008年3月 2008年7月 2008年11月 2009年3月 2009年7月 2009年11月
実績スコア
予定スコア
ポイント
図：全体リスクスコアの推移グラフ
予実のギャップ
を継続管理
All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.
-
34
-ご清聴ありがとうございました
株式会社東京証券取引所グループは、東日本大震災の
被害に対して、投資家をはじめとした幅広い市場利用
者の皆様と共にできる復興支援策として、本年4月～9
月までのＥＴＦ（上場投資信託）の売買手数料に相当
する金額を東日本大震災への義援金として寄付するこ
とといたしました。なお、今後新たに上場する枠組み
ができているＥＴＮ(指数連動証券）についても、義援
金の対象といたします。
http://www.tse.or.jp
HOME＞上場商品＞ETF＞ETFスクエア
東京証券取引所は、ＥＴＦの売買手数料を
東日本大震災に対する義援金として拠出します
～ＥＴＦの売買が復興支援につながります～
FUJITSU CONFIDENTIAL
Copyright 2010 FUJITSU LIMITED
東証株式売買ｼｽﾃﾑarrowhead開発の振返り
＜コアファクターの実現に向けて＞
東証株式売買ｼｽﾃﾑarrowhead開発の振返り
＜コアファクターの実現に向けて＞
2011年9月9日
富士通株式会社
保険証券ｿﾘｭｰｼｮﾝ事業本部）東証事業部
三澤
猛
SQiP2011
