イノベーションスプリント2011 東証新株式売買システムarrowheadにおける開発プロセス

本セッションの構成

• ご講演

宇治浩明様（東京証券取引所）「東証新株式売買システム arrowheadにおける開発プロセス」

• ミニパネルディスカッション

– 宇治浩明様（東京証券取引所株式売買システム部長）

– 金子久三男様（富士通アドバンストソリューションズ執行役員常務）

司会進行: 森崎修司（奈良先端科学技術大学院大学）

２０１１年１月１３日

株式会社東京証券取引所

株式売買システム部長

宇治浩明

東証新株式売買システム

arrowheadにおける開発プロセス

イノベーションスプリント２０１１

All Rights Reserved. Copyright © 2011 Tokyo Stock Exchange, Inc.- 2 -

目次

１．プロジェクトの概要

３．発注者責任にもとづく詳細な要件定義書

４．設計・テスト工程での要件トレーサビリティ

５．フィードバック型Ｖ字モデル

２．ステークホルダーとの綿密な合意形成

６．定量的リスク管理の取組み

７．arrowhead成功の鍵

1.1 プロジェクト始動に向けて

国際的な市場競争力の強化（海外投資マネーを集める力）

市場からの信頼回復

市場環境の変化Direct Market Access

アルゴリズム取引→高頻度取引（HFT）HFTに対応するべく取引所間でのスピード競争

システム障害等の経験障害による市場停止

キャパシティ不足による立会時間短縮

arrowhead(次世代システム)の構築

市場を巡る環境変化や、市場の信頼回復のため、

次世代の市場インフラとなるシステム構築が始動

背

景

課

題

アクション


1.2 システム高度化競争と取引所の合従連衡

ロンドン証券取引所

NASDAQ

ニューヨーク証券取引所

OMX

Euronext

イタリア証券取引所

Liffe 経営統合・システム共通化(2007.5)

買収(2007)

SGX

ASX

買収?(2010)

海外の主要取引所はシステムの高度化競争に突入。注文応答時間はミリ秒レベル。市場統合により、投資体力を強化。欧米における私設取引所の拡大、中国マーケットの急成長

香港上海深セン

東京市場が世界から置いて行かれる懸念

私設取引所

アーキペラゴ

買収(2005)


1.3 arrowhead開発の基本コンセプト(コアファクター)

海外視察も踏まえ、arrowhead構築の基本的なコンセプト＋定量目標を取りまとめ、提示

拡張性

あらかじめ定めた拡張基準を超えた場合、１週間程度で対応を可能とする。

〔拡張基準（想定）〕

1日or分間の注文件数において、実績ピーク値がシステム限界値の半分の件数を超えた場合

⇒ 過去の１日or分間の最大件数の２倍のキャパシティを常に用意

高速性注文受付通知のレスポンスを１０ミリ秒以下 ⇒稼動後実績は平均２ミリ秒

FLEXによる情報配信のレイテンシーを５ミリ秒以下 ⇒稼動後実績は平均２ミリ秒

柔軟性多様な商品や取引ルールの追加、変更に短期間で対応可能とする。

⇒機能のパラメータ化、アタッチメント型業務ロジック

信頼性９９．９９９％以上の可用性の確保を目標

⇒主要な処理サーバ（トレーディングサーバなど）は三重化構成

堅牢性セカンダリサイト（バックアップセンタ）の構築広域災害時２４時間以内復旧

その他

情報配信機能強化

システム運用堅確化

セキュリティ強化


注文

約定通知

受付通知

1.4 システム概要図

プライマリサイト

arrowhead

参加者

参加者

相場ユーザ

東証内他システム

参加者

参加者GW

通知情報

サーバ

問合せGW

相場情報

負荷分散

ﾄﾚｰﾃﾞｨﾝｸﾞｻｰﾊﾞﾄﾚｰﾃﾞｨﾝ

ｸﾞｻｰﾊﾞ注文管理サーバ

通知情報

サーバﾄﾚｰﾃﾞｨﾝｸﾞ

サーバ

売買監理サーバ

④約定通知通知情

報サーバ

通知情報

サーバ

取引記録サーバ

負荷分散

取引データ


ｸﾞｻｰﾊﾞ情報配信GW

相場ユーザ

セカンダリサイトDB

サーバ

取引データ


ｸﾞｻｰﾊﾞ外部接続サーバ

清算情報

約定情報

負荷分散

売買情報

同期コピー

同期コピー

信頼性拡張性

メモリＤＢ

高速性

堅牢性

参加者毎に負荷分散するサーバ

銘柄毎に負荷分散するサーバ

処理量見合で負荷分散するサーバ

凡例：

AP規模3.5Mstep

C: 2.8Mstep

Java：0.7Mstep

サーバ台数

約２００台

メモリＤＢ

メモリＤＢ

メモリＤＢ

メモリＤＢ

arrowhead

参加者GWサーバトレーディングサーバ

情報配信GWサーバ

取引記録サーバー

取引参加者

注文管理サーバ

データベースサーバー

相場ユーザ

市場監視サーバー

1.5 プロセス概要図

赤矢印

緑矢印

銘柄テーブル

注文キュー注文キュー





データベース

注文受付（銘柄、値段等

のチェック）

受付通知送信

約定通知送信

板登録・付合せ（マッチング）

注文キュー（参加者単位）

付合せ情報キュー

約定通知作成約定履歴作成

約定通知キュー

相場情報キュー

取引記録キュー（出）

情報配信

取引記録

* 富士通製の超高速データ処理ミドルウエア「Primesoft Server」の機能を利用

アプリケーション

キュー *

テーブル *

板情報

：注文応答処理の流れ

（所要２ミリ秒程度）

：情報配信処理の流れ

（所要２ミリ秒程度）


注文キュー（銘柄単位）

すべてのデータをメモリー上に展開、3重化 *


取引記録キュー（受）

市場監視


0

5

10

15

20

25

30

8:00

8:15

8:30

8:45

9:00

9:15

9:30

9:45

10:00

10:15

10:30

10:45

11:00

11:15

11:30

11:45

12:00

12:15

12:30

12:45

13:00

13:15

13:30

13:45

14:00

14:15

14:30

14:45

15:00

ミリ秒

概ねザラバ中において目標値である10ミリ秒を大幅に下回る2ミリ秒で安定。

日中を通じてほぼブレがなく、一定のレベルを保っている。

実績 2ミリ秒実績 2ミリ秒

目標 10ミリ秒目標 10ミリ秒

時間帯別注文受付レスポンスの推移（2010/04/13）

注文受付

時間帯立会時間帯

注

文

受

付

時

間

帯

立会時間帯

1.6 高速性（注文受付レスポンス）の目標と実績

0

5

10

15

20

25

30

時刻→

↑ミリ秒


目次






２．ステークホルダーとの合意形成



東証側協力会社メンバー約５０名

システムテスト（ST)

節目において適宜開催

2.1 プロジェクトのスケジュール全体像

参加者接続テスト

2006年 2007年 2008年

2006年3月

2006年4月～8月■ 証券会社のCIO、実務者ミーティング

計画策定■ 次世代システムプロジェクト計画

2006年9月

■ 欧米視察、マイルストーン公表

市場利用者と基本コンセプト、システム要件、開発投資計画等を協議

結合テスト（IT）

製造

▼接続仕様（第０版）説明会

2009年

■ 次世代システム構築

▼接続仕様（第１版）説明会

本番稼動▼

詳細設計基本設計

（外部＋内部）要件定義

■ 開発ベンダ選定コンペ富士通選定

主にセカンダリサイトを使用の予定

▲▲▲ ▲ ▲ ▲CIO ▲ ▲

▲▲ ▲ ▲ ▲実務者 ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲

受入テスト

東証プロパー約２５名

開発体制

富士通メンバー５００名以上（ピーク時）

2010年

プロジェクトオフィスに全員集合！


2.2 外部ユーザとの合意形成

証券業界との協調体制

CIOミーティング（11社）実務者ミーティング（16社）

基本コンセプトや対応方針等に

ついて、政策的な見地からＣＩＯ

レベルで意見交換

システム要件等の実務的な内容

についてヒアリングを行うとともに

意見交換

新光証券、カブドットコム証券、モルガン・スタ

ンレー証券、マネックス証券、野村ホールディ

ングス、大和証券グループ本社、メリルリンチ

日本証券、極東証券、光証券、UBS証券、日

興コーディアル証券

三菱ＵＦＪ証券、カブドットコム証券、極東証券、

ＵＢＳ証券、メリルリンチ日本証券、リテラ・クレ

ア証券、野村證券、松井証券、モルガン・スタン

レー証券、東洋証券、大和証券ＳＭＢＣ、ゴー

ルドマン・サックス証券、光証券、日興コーディ

アル証券、新光証券、マネックス証券

▼取引参加者ミーティング

コンセプトや方式、接続仕様等を中心に幅広く意見交換

▼ユーザ説明会

接続仕様やユーザ接続テスト内容等の周知

開催主な内容

1 2007. 4 システム方式、接続仕様の概要

2 2007. 7 接続仕様書(1.0版)、取引参加者向け端末

3 2007.12 接続仕様書(改訂）、新統合ネット

4 2008. 7 接続仕様書(改訂）、セカンダリサイトの整備、ユーザ接続テストの概要

5 2008.11 システム利用手続き、コロケーションの概要

6 2009. 3 ユーザ接続テストの予定・手続き、移行

7 2009. 6 ユーザ接続テストの内容、移行

8 2009.11 売買制度見直し、移行の詳細、稼動スケジュール、稼動後のテスト環境

取引参加者に対する開発支援

① 接続プロトコルの早期提示（オープン仕様とした）

② システム接続テスト環境の早期提供（テスト時間の確保）

③ 取引参加者接続テスト環境の平日提供（システム開発作業環境改善）

※ 上記以外でも業態別等で各種説明会を開催


設計・開発・製造

2.3 ユーザ部署との合意形成

・超上流工程からユーザ部署とシステム設計方針の企画立案・要件定義段階、その後の設計段階以降も協働し、要件のブレ・漏れを排除

要件定義策定方針策定

2006年9月最終報告策定

2006年３月取引所あり方有識者懇談会

取引参加者ワーキングの実施

システム設計の方針、新ルールの共同検討

業務フロー確認、ユーザインタフェースの作成、業務仕様の細部確認

業務マニュアルの作成準備

業務運用テストの準備着手

2007年春


目的会議体主催者レベル頻度内容

経営層の

対話

プレジデント

レビュー社長・会長ほぼ３ヶ月毎

東証・富士通両社の経営トップレベルでのプロジェクト全体レビューと方針の決定、確認

ステアリング

コミッティ関連役員四半期毎

システム本部、関連業務部門を含めたプロジェクト全体レビューと方針の決定、確認

CIOレベル

での

進捗・品質チェック

工程会議

東証側CIO＋

ベンダ側担当役員

１ヶ月毎システム本部のプロジェクト全体レビューとアクションの決定

品質評価会議

CIO＋

プロジェクト

責任者

１ヶ月毎当該工程の品質状況や次工程の準備状況等を評価し、アクションを決定

全社ベース

で移行・

稼動対応

全体移行

統制本部専務＋全役員

2009年10月～

２週間毎

本番移行に向けた準備状況について、関連業務部門の対応状況も含め、進捗表・チェックシートに基づき確認

稼動判定会議社長＋全役員

＋関連部門

2009年11月～

3回

稼動判定基準に基づき、稼動に向けた準備・適合性をチェック

中間判定会議（準備状況）を11月、適合状況を12月、１月（最終判定）で確認

2.4 開発ベンダ、社内関連部門との合意形成経営レベル


2.5 開発ベンダとの合意形成実務レベル

開発ベンダとの週次ミーティングをテーマ毎に細かく設定し、密なコミュニケーションを継続。

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-CT:マネージャー東証本館にて

隔週開催

市場監視分科会（自由検索）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 : マネージャー

東証本館にて開催

基盤グループ進捗1F : インフラ基盤, ネットワー

ク, システム運用, 性能

基盤グループ進捗2F : アプリ基盤, GW基盤,

DB/DAM, 性能

お昼休み(11:45 ～ 12:45)

富士通

統合ネット定例

Ｔ : 参加者・情報配信・他シス連携・インフラ・運用・テスト・移行チーム

リーダー会F : マネー

ジャー,グループ/サブ

リーダー

信頼性・拡張性WGT : インフラチームF : 基盤グループ

プロジェクト進捗会議T : マネージャー, PMチーム

F : マネージャー, グループリーダー,プロジェクト推進グループ

FM/規制チーム進捗

Ｔ : 売買監理チーム

プロジェクト工程会議

(毎月最終火曜日)

インフラ分科会T : インフラチームF : 基盤グループ開発推進チーム

端末共通分科会T : 端末共通

F : 開発推進、ｸﾗｲｱﾝﾄ開発、ｱﾌﾟﾘ基盤（端末FW）

運用グループ進捗会

F:運用グループ

業務グループ進捗会F: 業務

グループ

開発標準分科会T : 開発標準F : 開発推進

部門間定例T : マネージャー

東証本館にて隔週開催

品質マネージメント定例

T : 品質管理チームF : 品質管理チーム

媒介/業務共通分科会

T : 媒介チームF : 媒介／業務共通チーム

会社間

会議禁止

会社間会議禁止


2.6 プロジェクト運営方針チーム内の合意形成

Challenge “10” msec !高速性と信頼性を両立する、世界一の取引所システムを創る。

①上流工程“完璧主義” ＜品質管理＞

設計書レビューの徹底。問題点へのリアルタイム対応。

要件トレーサビリティの確保。

②“ライフサイクル”コスト・セーブ＜コスト管理＞コスト管理の意識強化。発生ベースの月次管理。

③“デジタル”予実管理＜スケジュール管理等＞進捗、品質、リスクレベルの予定と実績をリアルタイムに

数値評価し、プロジェクトを可視化。

④“次世代”育成＜人材育成＞

ＩＴで価値を創造できる人材の育成。ＩＴ総合力の強化。

⑤“ワイガヤ”民主主義＜ｺﾐｭﾆｹｰｼｮﾝ管理＞

率直な意見交換。カウンターパートの“人となり”を知る。

⑥“先手必勝”リスク制圧＜リスク管理＞ＱＣＤについて予防的・継続的なリスク・モニタリングと

リスク・ヘッジ。

◆プロジェクト管理方針

⑦リニアなスケールアウト＜拡張性＞ハードウェア増設によるリニアな拡張。

⑧ミリセカンド・レスポンス＜高速性＞

注文受付１０ミリ秒、情報配信５ミリ秒。

⑨Non Stop Market ＜信頼性＞稼働率＝９９．９９９％。

⑩アタッチメント型業務ロジック＜柔軟性＞高速で普遍的なフレームワークと付け替え可能な業務ロジック。

⑪Simple is Best ＜ﾒﾝﾃﾅﾝｽ性＞主要業務ロジックの簡素化。付帯業務の外出し。

◆システム設計方針

◆スローガン

One Team, One Dream.世界一のシステムを目指して頑張ろう！

◆会社間をつなぐスローガン


目次









3.1 開発プロセス改善の取り組み

立上げフェーズソリューション設計フーズ受入フェーズ

クロージングフェーズRFP

作成要件定義書作成要件確認書作成

プロジェクト企画書作成

納品検査検収テスト

移行判定

稼動

RFP、要件定義書の作成・進捗確認は適宜実施

・レビューに参加・進捗確認は適宜実施・テスト完了報告受領

立上げフェーズソリューション設計フーズ開発フェーズ

RFP作成※RFPの詳細化

要件定義書作成※要件定義書の詳細化

プロジェクト企画書作成

外部設計

詳細なＲＦＰ、要件定義書、ＩＦ仕様書の作成

内部設計詳細設計

品質評価会議

品質評価会議

品質評価会議

品質評価会議

品質評価会議

品質評価会議

開発着手会議

ベンダー選定会議

要件定義完了会議

本番移行確認会議

稼動確認会議

稼動準備確認会議

開発完了報告会議

レビュー・進捗管理徹底に加え、工程毎の品質評価会議にて品質管理の徹底

開発フェーズ

基本設計機能設計詳細設計単体テスト

結合テスト

システムテスト

従来の開発プロセス

改善後の開発プロセス

受入テスト・総合テスト(参加者接続・他システム接続)

受入フェーズ

クロージングフェーズ納品

検査検収テスト移行判定

稼動

ベンダー開発作業

改善

ベンダー開発作業

コーディング

単体テスト

結合テスト


コーディング

開発着手会議

ベンダー選定会議

要件定義完了会議

品質評価会議

稼動確認会議

本番移行確認会議

開発完了報告会議

従来の開発プロセスの問題点と要因① ベンダ提案の精度が低い ⇒ RFPの粒度が粗い② 要件と実装の齟齬が多発 ⇒ 要件定義漏れや曖昧さ③ 納品時の品質が悪い ⇒ 品質管理できていない④ 納品遅延の予見ができない ⇒ 工程管理がずさん⑤ 稼動準備状況・稼動品質の見極めが雑駁 ⇒稼動チェックずさん

プレ受入テスト

受入テスト・総合テスト(参加者接続・他システム接続)

RFP

作成

①第三者（コンサル）の参画②ＲＦＰ詳細化（約１５００

ページ）

詳細な要件定義書の作成

内部設計書の作成詳細設計書の作成

東証

開発ベンダー

③要件定義・外部設計の詳細化（要件定義書＋外部設計書で

４０００ページ）④第三者による品質チェック（要件定義書の記述項目の網羅性等）

⑤内部設計と外部設計の分離

⑥外部設計の内製化

⑦注文受付から約定結果送信、相場情報配信までの処理パターンを網羅的に洗い出して、テストシナリオとして利用

⑧要件定義（約1万項目）が設計書に反映されていることのトレース

提案書評価

⑨東証とベンダーがひとつのプロジェクト

オフィスに集結性能マネジメント計画書拡張性マネジメント計画書信頼性マネジメント計画書

⑩システム要件を確実に達成するための手引書

要件トレース表の作成

外部設計書の作成

発注者責任の明確化

開発ベンダーの決定

オークションパターンの作成

ベンダー選定プロセス

要件定義／設計プロセス

設計プロセス

3.2 発注者責任の明確化

発注者は内部的な責任をベンダ側に依存しがち。

でもトラブルが発生すれば、対外責任は全て発注者。

発注者が真に責任を負える体制が必要。


3.3 要件定義書の体系（鳥瞰図）

・全体業務フローと業務フロー図で業務の流れを俯瞰・要件の抜け漏れを確認・それをもとに要件定義書、外部設計書を作成

要件定義書

業務フロー図

全体業務フロー

要件定義書


3.4 標準化への取り組み

・ユーザの業務の効率性、共通化、分りやすさのため、標準化に取り組み

■ 画面設計方針

■ 帳票設計方針（印刷）

■ 帳票設計方針（ファイル）

■ メッセージ設計方針

■ 端末におけるユーザ認証方法

■ コード定義書

運用ベンダ用画面売買規制用画面市場監視用画面

画面設計方針に従い標準化へ


3.5 要件定義書のレビュー徹底

・チーム内、チーム間、全体レビューの実施・レビューに当たってはチェックシートの活用、レビュー表をもとに横展開も徹底

セルフレビューチーム内レビュー

チーム間レビュー

プロジェクト全体レビュー

3.6 要件変更の分析による要件品質向上

要件定義の変更内容を１件毎にプロジェクトで審査。同時に変更内容を分析し、前工程の悪さを引きずることのないよう品質改善策を実施。

変更管理

原因工程、発見契機、内容、傾向を踏まえて、同様の悪さが該当チーム、他チームに潜んでいないかを分析

誤字脱字も含め、要件定義に修正を行う場合は１件毎に承認プロセスを実施

同様の悪さが潜んでいる可能性がある場合には、プロジェクト横断でチェックし、アクション

分析資料

【例】■事象画面項目定義に「ＸＸ値段」という曖昧な表現があり、そのために設計上で誤解が生じていた・・・

■アクションプロジェクト横断でチェックし、同様の項目や定義を行っているサブシステムＡ、サブシステムＢについて画面項目定義、帳票出力の項目定義を改善

■分析同項目は他のサブシステムでも利用しており、同様のミスが潜んでいる可能性が高い

要件変更の内容はもとより、発生起因がベンダか東証か、発生契機が要件の検討過程、レビュー過程、方式検討過程か等のポイントで分析。要件の不具合が摘出すべき工程で行われているかチェックし、アクションを実施


目次









4.1 要件トレーサビリティ：設計フェーズ

・要件定義書を項目化した要件トレース表（mini要件定義書)を作成・どの要件項目がどの設計書に記載されているかのトレースを実施・設計が変わるタイミングで部分トレースによって紐付け情報喪失を防止

ポイント

●東証⇔富士通の担当チームの境界線の違い

●工程で詳細化する部分の追加の紐付け

●バージョン管理

（要件と設計の非同期の改訂）

次工程でさらなる活用

●テストケース作成にも利用

●データベース化して自動チェック要

件項目

要件トレース表（抜粋）要件内容設計書紐付け情報

EXE-00100-001 1 板とは

注文を受け付け順に「板」に登録銘柄毎の注文を売買別、値段別に整理同一値段の複数注文を記載するケースでは、時間的に早く板登録した注文を中心に近く記述する

同時呼値

同時呼値とは、規則上、約定における時間優先（登録時間順）にとらわれずに同時に受付けられたとみなされる注文

板の各値段に登録されている注文が取引参加者単位に集計（名寄せ）され､合計注文数量の多い取引参加者から少ない取引参加者の順に付合せ処理時の約定数量の配分を行う。

同時呼値は、次の状況における注文①　始値（場単位）が決定される以前に板登録された注文（直前の場において約定せずに引き継がれた注文含む。）② 売買停止（市場停止を含む）から売買を再開した後の最初の約定値段決定以前に板登録された注文始値（場単位）決定時、売買停止解除後最初の約定値段決定時、ストップ配分方式による約定値段決定時及び同一値段に引け条件付注文が複数ある場合における立会終了時の約定値段決定時には、その時点で有効な同時呼値を確定したあと、当該同時呼値について約定処理を行う同時呼値は、約定処理において始値等の決定後に板登録された注文（ザラバ注文）とは区別して扱われる。同時呼値が始値決定後に板に残っている場合、当該同時呼値と同じ値段に登録されたザラバ注文は、当該同時呼値が全て約定等により処理された後に約定対象となる。引け条件付注文は、立会終了時以前の同時注文およびザラバ注文とは区別して扱う。

立会終了時以前の同時注文、またはザラバ注文が立会終了時に板に残っている場合、当該注文と同じ値段に登録された引け条件付注文は、立会終了時以前の同時注文、およびザラバ注文が全て処理された後に約定対象とする

EXE-00100-003 1

項目名機能関連業務ルールID

業務ルールID

項番

1 2 3 4

①参加者からの新規／変更／

取消注文入力

（新規注文

）

②参加者からの新規／変更／

取消注文入力

（変更注文

）

③参加者からの新規／変更／

取消注文入力

（取消注文

）

④取引所売買監理端末からの

有効注文取消

⑤時間外または場間→

注文受

付開始

⑥注文受付中→

立会開始

● ● ●

対応済

DA360　同時呼値の引き直しDA300　付合せ約定処理概要、2. 同時呼値注文の配分処理

対応済

①始値（場単位）決定時、 DA006 立会開始 1. ステータス変更処理 DA920 板寄せ方式対当値段算出時の約定処理

● ● ●

２．立会ｽｹｼﾞｭｰﾙ変化１．注文入力／変更／取消

状況

内部設計書２ドキュメント名

同時呼値



同時呼値は、次の状況における注文①　始値（場単位）が決定される以前に板登録された注文（直前の場において約定せずに引き継がれた注文含む。）② 売買停止（市場停止を含む）から売買を再開した後の最初の約定値段決定以前に板登録された注文

対応済


EXE-00100-001 1 板とは

注文を受け付け順に「板」に登録銘柄毎の注文を売買別、値段別に整理同一値段の複数注文を記載するケースでは、時間的に早く板登録した注文を中心に近く記述する

同時呼値



同時呼値は、次の状況における注文①　始値（場単位）が決定される以前に板登録された注文（直前の場において約定せずに引き継がれた注文含む。）② 売買停止（市場停止を含む）から売買を再開した後の最初の約定値段決定以前に板登録された注文始値（場単位）決定時、売買停止解除後最初の約定値段決定時、ストップ配分方式による約定値段決定時及び同一値段に引け条件付注文が複数ある場合における立会終了時の約定値段決定時には、その時点で有効な同時呼値を確定したあと、当該同時呼値について約定処理を行う同時呼値は、約定処理において始値等の決定後に板登録された注文（ザラバ注文）とは区別して扱われる。同時呼値が始値決定後に板に残っている場合、当該同時呼値と同じ値段に登録されたザラバ注文は、当該同時呼値が全て約定等により処理された後に約定対象となる。引け条件付注文は、立会終了時以前の同時注文およびザラバ注文とは区別して扱う。

立会終了時以前の同時注文、またはザラバ注文が立会終了時に板に残っている場合、当該注文と同じ値段に登録された引け条件付注文は、立会終了時以前の同時注文、およびザラバ注文が全て処理された後に約定対象とする

EXE-00100-003 1

項目名機能関連業務ルールID

業務ルールID

項番

1 2 3 4

①参加者からの新規／変更／

取消注文入力

（新規注文

）

②参加者からの新規／変更／

取消注文入力

（変更注文

）

③参加者からの新規／変更／

取消注文入力

（取消注文

）

④取引所売買監理端末からの

有効注文取消

⑤時間外または場間→

注文受

付開始

⑥注文受付中→

立会開始

● ● ●

対応済


対応済

①始値（場単位）決定時、 DA006 立会開始 1. ステータス変更処理 DA920 板寄せ方式対当値段算出時の約定処理

● ● ●

２．立会ｽｹｼﾞｭｰﾙ変化１．注文入力／変更／取消

状況

内部設計書２ドキュメント名

同時呼値



同時呼値は、次の状況における注文①　始値（場単位）が決定される以前に板登録された注文（直前の場において約定せずに引き継がれた注文含む。）② 売買停止（市場停止を含む）から売買を再開した後の最初の約定値段決定以前に板登録された注文

対応済



4.2 要件トレーサビリティ：ＩＴ～ＳＴフェーズ

・要件とIT/STのテストケースの紐付けにより要件網羅性の確認

ポイント

●要件一覧の常時最新化

●IT/ST評価タイミングの妥当性

●障害発生時に未充足状態へ戻り

次工程でさらなる活用

●東証内確認でのクロスチェック

●データベース化して集計簡略化

＜IT～STフェーズでの要件トレーサビリティ確保プロセス＞


4.3 要件トレーサビリティ：東証テストフェーズ

・要件要素ID、設計書ID、受入テストIDを紐付けて一元管理・充足状況をリアルタイムで可視化

ポイント

●要件要素、テストケースの粒度設定

●システム全体での一律管理

●要件充足進捗の妥当性評価

●要件定義書の世代管理により、追加や変更の要件充足確認漏れの防止（要件定義完了時：11,000件

⇒ 稼働時：12,000件）

稼働後でさらなる活用

●要件変更に対応

●ノウハウの他プロジェクトへの展開

集計・分析

＜要件トレーサビリティの管理イメージ＞

ﾃｽﾄｹｰｽID ﾃｽﾄｹｰｽ名世

代ﾁｰﾑ大分類中分類小分類想定結果

ｹｰｽ

内

件数

要件要素ID 設計書ID

HBV50-0020001初期画面表示時の検索

条件1 HB V50:発注状況

002:画面レイア

ウト

0001:メニュー画面から

遷移した場合の検索条

件初期値

検索条件には、以下の値が表示されていること

※ここに記載が無い項目は「空白」となる

「日付」＝業務日付

1MON-00200-

006_10.2.1.0HBv0050

HBV50-0020002成行を含むチェックボッ

クス1 HB V50:発注状況

002:画面レイア

ウト

0002:成行を含むチェッ

クボックス＝ON

範囲指定した注文値段と一緒に、成行注文も表示されること

※検索条件の

執行条件が＜1:指定なし＞の場合はザラバの成行注文を、

1MON-00200-

006_40.26.0.0HBv0050

HBV50-0020003取引所ごとに異なる市

場区分の表示確認1 HB V50:発注状況

002:画面レイア

ウト

0003:プルダウンリスト:

市場区分

取引所区分に応じた市場区分が選択できること

※ただし、00:全市場は選択不可1

MON-00200-

006_40.3.0.0;MON-

00200-

HBv0050

HBV50-0020004同一注文の不変項目非

表示1 HB V50:発注状況

002:画面レイア

ウト

0004:同一注文情報の非

表示対象項目

同一注文の2行目以降は、以下の項目値が表示されないこと（空白とな

る）

「銘柄コード」「銘柄名」「上場区分」「整理監理区分」「信用貸借区分」「権

1MON-00200-

006_40.12.0.0HBv0050

HBV50-0020005成行注文の値段欄表示

1 HB V50:発注状況002:画面レイア

ウト

0005:成行注文の値段表

示

注文値段が成行の場合は、”成行”と表示すること1

MON-00200-

006_40.14.0.0HBv0050

HBV50-0030001参加者検索のショート

カットキーD1 HB V50:発注状況

003:画面イベン

ト

0001:参加者検索の

ショートカットキーが有

効な項目

ショートカットキー(F4)押下による参加者検索機能が有効となるのは、

検索条件の参加者コード１（最上段）のみであること1

UIF-00100-

001_30.9.1.0HBv0050

HBV50-0030002並び順を指定した検索

結果表示（受付時刻順）1 HB V50:発注状況

003:画面イベン

ト

0002:表示順＝＜1:受付

時刻順＞で照会

照会結果の並び順が、注文受付番号ごとに、新規注文の注文時刻の昇

順に表示され、その各注文受付番号内の取引は、板更新回数の昇順に

表示されること

1MON-00200-

006_40.28.0.0;MON

-00200-

HBv0050

HBV50-0030003並び順を指定した検索

結果表示（値段順）1 HB V50:発注状況

003:画面イベン

ト

0003:表示順＝＜2:値段

順＞で照会

照会結果の並び順が、注文受付番号ごとに、新規注文の値段の降順に

表示され、その各注文受付番号内の取引は、板更新回数の昇順に表示

されること

1MON-00200-

006_40.28.0.0HBv0050

HBV50-0030004銘柄コードを指定しない

（未入力）状態で、共通

ヘッダ表示：ありの照会

D1 HB V50:発注状況003:画面イベン

ト

0004:銘柄コードが未入

力

プルダウンの共通ヘッダ表示が、”無し”となり、編集不可能となること1

MON-00200-

006_30.1.0.0HBv0050

HBV50-0030005共通ヘッダ画面が開設

していない状態で、共通

ヘッダ表示：ありの照会

1 HB V50:発注状況003:画面イベン

ト

0005:共通ヘッダ表示＝

＜1:有＞、かつ共通ヘッ

ダ画面が表示されてい

発注状況の照会結果が表示されるのと同時に、共通ヘッダ画面が自動

で表示、照会が行われること1

MON-00200-

006_40.1.0.0;MON-

00200-

HBv0050

HBV50-0030006共通ヘッダ画面が既に

開設している状態で、共

通ヘッダ表示：ありの照


ト


＜1:有＞、かつ共通ヘッ


発注状況の照会結果が表示されるのと同時に、共通ヘッダ画面の内容

が更新されること1

MON-00200-

006_40.1.0.0;MON-

00200-

HBv0050

HBV50-0030007共通ヘッダ画面が開設

していない状態で、共通

ヘッダ表示：なしの照会


ト


＜0:無＞、かつ共通ヘッ


共通ヘッダ画面は表示されないこと1

MON-00200-

006_40.1.0.0;MON-

00200-

HBv0050

HBV50-0030008共通ヘッダ画面が既に

開設している状態で、共

通ヘッダ表示：なしの照


ト


＜0:無＞、かつ共通ヘッ


共通ヘッダ画面の表示内容は、更新されないこと1

MON-00200-

006_40.1.0.0;MON-

00200-

HBv0050

HBV50-0030009符号・通知番号表示設

定の確認1 HB V50:発注状況

003:画面イベン

ト

0009:「符号通知番号表

示」を＜0:無＞とした場

合

照会した結果について、「銘柄コード」「上場区分」「整理監理区分」「信用

貸借区分」「権利落ち符号」「参加者コード」「社内処理用項目」「板更新

回数」「参加者任意項目」「仮想サーバ番号」が非表示となること

1MON-00200-

006_30.2.0.0HBv0050

ﾃｽﾄｹｰｽと要件を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-

00200-MON-00200-

006_40.12.0.0

MON-00200-

006_40.14.0.0

受入テストにおける要件充足状況


ベンダテスト受入テスト

4.4 要件トレース実施による効果

・各工程での成果物に対して、要件充足（総数：11,000件、機能要件：10,500件、非機能要件：500件）を

トレースして、開発システムの要件実装性を高める。

内部設計詳細設計製造

受入テストでの要件定義起因と外部設計起因のバクを削減できた。（当該バグの内、約８６％を設計工程で摘出。）設計進度に合わせて、要件充足を確認できた。要件定義の不備を適時修正し、設計書へ反映することができた。手戻り工数を減らすことができた。

ベンダと東証側の連携ができた。要件未達部分に対し、適時対策を実施することができた。要件充足の完了を確認できた。

工程

効果

充足率：

67.4%

充足率：

86.5%

充足率：

98.0%

充足率：

100%

設計書レビュ結果による要件充足を

トレース

テスト項目および結果の要件充足を

トレース

(残分→詳細設計

で確認)(残分→課題管理で対応)

(残分→稼動判定

までに対応)

機能設計処理設計

充足率：

94.4%


目次









5.1 従来のＶ字モデル

コーディング

要件定義

要件定義書

レビュー

基本設計

基本設計書

レビュー

詳細設計

詳細設計書

レビュー

プログラム設計

プログラム設計書

レビュー

単体テスト

テスト項目

テスト実施

結合テスト

テスト項目

テスト実施


テスト項目

テスト実施

運用テスト

テスト項目

テスト実施要件エラー発見

基本設計エラー発見

詳細設計エラー発見

修正-手戻

修正-手戻

修正-手戻

PG設計エラー・

コーディングバグ発見

修正-手戻

・設計段階では、各設計書レビューが完了したら工程終了。・次工程は、前工程の設計書を正として、詳細化を実施。・テスト項目は各テスト実施時期の直前(或いは並行して)作成されがち。


外部設計内部設計

5.2 オークション・パターンの作成（W字モデル）

コア業務である媒介処理に係る業務要件を中心として、旧売買システムの標準テストケースをもとに「オークションパターン」を作成。

要件定義詳細設計製造ベンダテスト受入テスト

■基本設計～内部設計

参加者-媒介処理-ＦＭ-規制-情報配信-板絵（＝端末

画面）について、代表的な状態遷移・イベントパターン

で整理し、システム全体としての要件確認、設計の整合

性の確認を行った。

どうしても方式があらあらで、かつサブシステム毎に

業務ロジックの設計を進めがちな中で、一体的に設計を

チェック、東証もその後のテストパターンの整理が出来

た。

オークションパターン

■詳細設計

媒介パターンも踏まえて作成・レ

ビューされた内部設計書をもとに詳細設

計書が作成された。

詳細設計のレビューの際にも役立ち、

設計ミスの早期発見に寄与した。

■結合テスト結合テストのテストバリエーションの確認において有用だった。

■受入テスト準備上流工程で整理していたため、受入テストに向けて深化させ、それをベースにテスト準備をすることでＯＫになった。また、テストケース作成、データ準備にもそのまま利用することができた。

工程

実施内容と成果

各設計書へのフィードバック PDCA

オークションパターンチェック

要件定義書東証テストケース

オークションパターンチェック

旧システム

標準テスト

ケース

効果：

①要件の網羅性確認②ベンダ側の具体例に基づいた要件理解③テストケース作成へのスムーズな移行


5.3 オークション・パターンサンプル

中項目寄前気配の場合

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 ●

「パターンに対当値段あり」の記載について、当パターンは、注文受付中にて対当値段がある場合を意味している。よって、付合せは執行されていない。遷移パターンを作成

各項目の詳細内容を別途作成。

オークション内部処理と外部出

力データの関係がチェックでき、

「②ベンダ側ケーススタディ的

要件理解の進展」に役立つ。

小項目ＩＤ

寄前／ザラバ

：板中心値段

引累計数量数量累計引引累計数量数量累計引

30 30 成行 18 18 30 30 成行 18 18 ①

122 41 OVER 18 132 41 OVER 18 タグタグ値段時刻数量

81 2 107 18 91 2 107 18 ＮＯ Q1 99 8：45 63

79 106 18 89 106 18 Q2 100 8：45 5

79 5 105 10 28 89 5 105 10 28 Q3 103 8：45 3

74 3 104 10 38 84 3 104 10 38 Q４ 104 8：45 3

71 3 103 15 53 81 3 103 15 53 Q5 105 8：45 5

68 102 53 78 102 53 Q6 107 8：45 2

68 101 5 58 ⇒ 78 101 5 58 Q7 109 8：45 2

68 5 100 58 78 5 100 58 Q8 110 8：45 4

63 8 # 99 # 3 61 73 8 99 3 61 タグ時刻数量時刻数量

55 10 98 3 64 65 10 # 98 # 3 64 QO 8：45 35 8：43 38

45 15 97 64 55 15 97 64

30 96 5 69 40 96 5 69

30 95 5 74 40 10 95 5 74

30 94 5 79 30 94 5 79

30 93 79 30 93 79

30 UNDER 48 127 30 UNDER 48 127

① ② ②

タグタグ値段時刻数量

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 104 8：47 3 11 + 1 +

11 + 1 +

11 + 1 +

11 + 1 +

00000052 1 + 0 + 1

気配符号変化フラグ更新番号変化フラグ値段符号気配フラグ

1 ＋ △ +

変化フラグ数量フラグ変化フラグ数量フラグ

11 + 1 +

11 + 1 +

11 + 1 +

11 + 1 +

11 + 1 +

11 + 1 +

1 + 1 + 1

00000051 1 + 0 + 1

値段符号気配フラグ気配符号変化フラグ

連続約定気配自動執行時間 60秒

更新番号変化フラグ

特別気配表示後自動執行時間－

連続約定気配値幅 10円

23

更新値幅 5円

中項目ＩＤ FLEX01 寄前気配の場合

特別気配自動更新時間 5分

特別気配自動表示値幅－

リアル板

FLEX板

リアル板

FLEX板


5.4 フィードバック型Ｖ字モデル

コーディング

要件定義

要件定義書

レビュー

基本設計

基本設計書

レビュー

詳細設計

詳細設計書

レビュー

プログラム設計

プログラム設計書

レビュー

単体テスト

テスト項目テスト実施

結合テスト


システム確認


運用確認


要件定義書品質向上

基本設計書品質向上

詳細設計書品質向上

PG書品質向上

・次工程は前工程の成果物に従い開発するが、随時、前工程の不具合を傾向分析し、品質状況を評価する。

・前工程の成果物の弱点が見つかったら、前工程に立ち戻って品質強化を行い、手戻りを未然に防止する。

要件定義書品質強化

基本設計書品質強化

詳細設計書品質強化

PG書品質強化

前工程

成果物

次工程

成果物

成果物

作成

成果物

レビュー

次工程

バグ票

前工程


5.5 フィードバック型Ｖ字モデルで想定される効果

Ｖ字モデルの場合（赤曲線）

・コーディングは設計書を正として行い、単体テストはホワ

イトボックス主体で行うため、設計書に内在するエラーを

摘出しずらい。

・設計書の内在エラーは結合テストで検出するというＶ字モ

デルの考え方のため、結合テストでの設計書内在エラー摘

出を当然と考えがちである。

⇒従って結合テスト工程まで設計の内在エラーが残るため、

その分の手戻り工数が増加し、結果的に結合テスト工程遅

延要因となる。

コーディング単体テスト結合テスト

設計レビュー

完了時の

設計エラー

残存件数

結合テストまですり抜けた

設計エラー数Ｖ字モデル

ＦＶモデル

フィードバック型Ｖ字モデルの場合（青曲線）

・コーディング時に設計書内容を厳密に確認し

設計バグ摘出を意識するため、内在エラー

もその殆どをここで摘出することができる。

⇒従って設計修正及び設計品質確認をコーディング期

間中にほぼ完了させることができる。

⇒結合テストまで設計エラーを残さないためトータル

の手戻り工数は非常に少なく抑えることができる。

設計レビュー完了以降の設計エラー残存件数の推移


5.6 ＜参考＞発注者とベンダとの間のリスク共有

本プロジェクトのシステムテスト工程でのバグ密度の目標値＝０．３件／kstepとし、

これを按分した０．１５件／kstepを東証および開発ベンダの目標バグ密度と設定。

システムテストでのバグ密度の実績値＝０．２３件／kstepで、目標値をクリア。

品質の責任者バグ混入工程バグの原因強化ポイント

東証

要件定義要件の齟齬詳細設計工程での業務要件に関わる

レビューの強化基本設計業務要件の齟齬

詳細設計業務要件の齟齬

開発ベンダ詳細設計実現方式の齟齬製造工程での

単体テストの強化製造全般

上流工程での不具合の刈り取りを促し、下流工程への不具合のすり抜けを牽制することを

目的として、東証、開発ベンダそれぞれの責任範囲を決めて、下流のシステムテストでの

バグ件数の目標値を設定。


5.7 ＜参考＞手戻りを防ぐ品質管理

・品質警戒値及び許容値を設定し、テスト進捗に応じた障害収束状況を注視・品質許容下限値に近づいた状況で、障害傾向を特定し品質強化策を適宜実施・障害傾向が特定出来るように業務影響度や原因分類の管理項目を予め設定

障害状況

0

20

40

60

80

100

120

140

160

180

200

220

240

260

280

300

320

340

360

4/1

4/8

4/15

4/22

4/29 5/

65/

135/

205/

27 6/3

6/10

6/17

6/24 7/

17/

87/

157/

227/

29 8/5

8/12

8/19

8/26 9/

29/

99/

169/

239/

3010

/7

10/1

4

0

4,000

8,000

12,000

16,000

20,000

24,000

28,000

32,000

36,000

40,000

44,000

48,000

52,000

56,000

60,000

64,000

68,000

72,000障害総件数許容上限値：290

障害総件数警戒値：250

障害総件数許容下限値：215

障害認定分（総障害数）

障害対処分（対処日起票）

内）設計ミス原因

内）製造ミス原因

内）環境設定ミス原因ほか

テスト実施数： 60,000

テスト検証数： 60,000

障害の影響度内訳

0

10

20

30

40

50

60

70

80

90

100

110

120

130

140

150

4/1 4/8 4/15 4/22 4/29 5/6 5/13 5/20 5/27 6/3 6/10 6/17 6/24 7/1 7/8 7/15 7/22 7/29 8/5 8/12 8/19 8/26 9/2 9/9 9/16 9/23 9/30 10/7 10/14

業務影響度／重大

業務影響度／大

業務影響度／小

業務影響度／デグレ障害のパレート分析

-30

-20

-10

0

10

20

30

40

50

60

70

80

90

100

110

120

設計誤

り

（業務仕様以外

）

製造

ミ

ス

設計誤

り

（業務仕様

）

環境設定誤

り

運用手順書誤

り

修正

ミ

ス

デー

タ誤

り

ＯＳ

・ＭＷ

デグ

レー

ド

ハー

ド障害

基本設計

ミ

ス

リリー

スミ

ス

改善

ほか

調査中

-30%

-20%

-10%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

110%

120%テスト検出分

性能チューニング検出分

障害累積比率

①

②

③

アラームライン（①品質下限値に近傍）

⇒業務継続の影響度を確認

⇒パレート分析より業務仕様ミスの有無確認

品質強化策の実施（②）

⇒業務仕様ミスはベンダー任せでなくユーザ

視点でも点検（場合により要求定義確認も）

品質の安定（③）

⇒予め設定した管理項目に沿って早期に安定

あらかじめ要品質強化基準を設け、監視


5.8 ＜参考＞本番稼働間際における障害仕分け

・本番稼働前２ヶ月間に発生した障害は、業務影響度と修正リスクとを勘案して、稼働前に改修するか、当面は運用対処として稼動後の改修とするかを判断。

ランク定義発生件数

A 業務影響があり、稼動までに対処が必要 91

B 運用回避が可能だが、修正が軽微 16

C 運用回避が可能で、業務影響が軽微 64

D ドキュメントのみの修正 25

バグ修正を稼働後に延期する

ことで、システム変更に伴う

リスクを回避。

システムの中核となる媒介はゼロ

件。参加者接続、情報配信は１件

ずつのみ。（計２件）

残りは、周辺業務でのバグ。


目次









6.1 arrowheadにおけるリスク管理の特徴

１. 検出されたリスク毎にリスク発生確率レベルと影響度でスコア付けを実施し、管理対象リスクを決定

２. リスクスコアの低減計画を策定し、予定／実績管理を実施し、必要に応じてアクションを打つ

⇒ リスク管理におけるＰＤＣＡサイクル

３. 管理対象の全リスクの予定スコア合計と実績スコア合計を比較することで、プロジェクト全体の

リスク低減状況を把握

１.リスクスコアの算出方法

発生確率レベル × 影響度＝リスクスコア

・リスクスコアが「3」以上のリスクをプロジェクトでの

管理対象とした。

・リスクスコアが「6」以上のリスクを工程会議において

モニタリングすることとした。

７段階に分類し、管理

⇒ 次ページの具体例参照

リスクが顕在化した場合の

影響度を3段階で評価

影響度評価内容

3 プロジェクトのベースラインに

影響を与える場合

2 プロジェクトで吸収可能な中程度

の影響を与える場合

1 影響が軽微な場合

リスクと課題の一元管理

①リスクが課題化したら⇒影響度を1.5倍に拡大

②課題が解決したら⇒影響度を元の値に戻す


6.2 リスクの低減計画と予定／実績管理

「プロジェクトにおいて計画されている作業やイベントの実行」と「リスク発生確率レベルの低減」との関連性を、

あらかじめ定義し、計画どおりに作業等が実行されたことによりリスクスコアが低減していたことを確認する。

発生確率

レベルリスクに関する状況

モニタリング

実現時期監視内容

3プロトコルを一新することについて、参加者の理解を得ら

れていない－

－

2.5新プロトコルにおける主要な変更点について参加者の理解

が得られている2006年9月

ＣＩＯ－Ｍ、実務者－Ｍで新プロトコルの方針

について合意することを確認

2大手、外資等の代表的な参加者に新プロトコル案を提示し、

合意が得られている2007年3月

実務者－Ｍで新プロトコルdraft（第０版）を

提示し、合意、することを確認

1.5全参加者に新プロトコル案を提示し、合意が得られている

2007年5月参加者説明会で新プロトコルdraft（第０版）

を提示し、合意することを確認

1全参加者に新プロトコルを確定仕様として提示している

2007年7月第２回参加者説明会で新プロトコル（第１版）

を提示し、合意することを確認

0.5パイロットユーザテストで新プロトコルに関連する問題が

生じない、または生じた問題への対応が完了する2009年2月

パイロット参加者による実機テストで問題なく

接続可能であることを確認

0参加者接続テストで新プロトコルに関連する問題が生じな

い、または生じた問題への対応が完了する2009年10月

参加者接続テストを問題なく実施できることを

確認

＜リスク低減計画例：取引参加者が新プロトコルに対応できないリスク＞


6.3 プロジェクト全体のリスク状況把握

個別のリスクについての予定／実績管理を行うとともに、全リスクの予定リスクスコアの合計値と実績

リスクスコアの合計値を比較管理することにより、プロジェクト全体のリスク状況の把握を行った。

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月

実績スコア予定スコア

ポイント

図：全体リスクスコアの推移グラフ

予実のギャップ

を継続管理


目次









7.1 arrowhead 成功の鍵（1）

１．危機意識の共有

東証のシステムトラブルで信用回復が喫緊の課題であった。

世界の取引所と比較して取引速度が遅く、早急に世界最高水準への高速化が求め

られていた。

２．発注者責任の明確化

基幹システムは要件定義、外部仕様まで東証の責任で作成する。

要件定義書、外部設計書は一字でも変更する場合、要件変更として扱い、ＣＩＯ承認

案件として、発注者の責任で修正する。

３．リスク管理の可視化

４．経営責任者によるプロジェクト推進体制構築


7.1 arrowhead 成功の鍵（2）

５．上流工程完璧主義 → 網羅された要件定義と設計＆テストでの要件トレース

要件定義書の詳細化（旧システムの約３倍）と網羅性向上（第三者チェック）を図る。

東証自ら、すべての要件が設計書上に反映されたことを１項目ずつトレースして確認

し、要件定義書と設計書のズレを自ら消しこむ。ベンダの理解不足や誤解を早く取り除

く。テスト項目およびテスト結果についても、要件要素毎に充足管理。

６．各工程の質は次工程で確保 → フィードバック型Ｖ字モデル

各工程の品質は、次工程で目標件数（指標値）の不具合を摘出しきることで確保。

各工程においては、前工程成果物をインプットとして、現工程での作業を行うが、

その中で前工程成果物の不具合を摘出し、バグとして管理を行う。

前工程での不具合抽出不足により、現工程で摘出する前工程成果物の不具合件

数が多い場合は、前工程に遡って、品質向上策を実施し、前工程成果物（要件定

義書、詳細設計書等）の品質を確保したうえで再度、現工程を実施する。

このフィードバックプロセスにより、Ｖ字の対応工程ではなく、各工程の質はすぐ次

の工程で確保する。


ご静聴ありがとうございました

ミニパネルディスカッション

• 金子様自己紹介

• 開発関係者の間で価値を共有するために意識したことは？

• 価値の実現において発生した問題は？

• 会場から質問

46 Copyright 2011 FUJITSU ADVANCED SOLUTIONS LIMITED

皆さんこんにちは富士通アドバンストソリューションズの金子です。

当社は富士通グループの一翼を担うソフト・サービス企業であり、金融系、官公庁、キャリア、エネルギーなどのお客様に最適なソリューションを提供します。

【富士通入社後の主な担当プロジェクト】

１９７１年富士通に入社ファイルシステム

(領域管理はAPL ６４ＫＢ

ﾒﾓﾘ容量年度経歴(活動内容）開発言語ﾃﾞｰﾀ管理ｼｽﾃﾑ

～

－で実施）～

１２８ＫＢ

１９７４年・銀行オンラインシステム開発(地方銀行、信用組合）オンライン～

(アセンブラ）３８４KB～

バッチ 768KB

(COBOL）

１９７７年銀行勘定系システム（PKG)の開発 COBOL～

→２３０－８リシリーズ(仮想メモリ：ページング機能）

１９８１年銀行勘定系システム（PKG)の開発 COBOL ＮＤＢメガの～

→Mシリーズ(多重仮想空間）世界へ

１９８５年某都銀の第三次オンラインシステム開発～

１９８８年某都銀の国内債券ディーリングシステム開発（ディーリング席：１５０席）～

１９９０年　オープンシステム開発へＣ言語主体へＲＤＢへ～

・某都銀の外国債券ディーリングシステム開発Ｃ INFORMIX

・信託子会社向けPKGの開発 4GL 上記＋ＯＲＡＣＬＥ

・某都銀)常任代理人システム開発 C、PB ＳＹＢＡＳＥ

１９９５年・銀行系クレジット会社のカード発行システム開発 C、VB ＯＲＡＣＬＥ～

１９９７年・銀行証券系（バックオフィス)PKG開発／メガバンク向け日銀RTGSシステム開発 C、PB ＯＲＡＣＬＥ～

２０００年インタネット専業銀行システム開発 C、Java ORACLE ギガの～

→J銀行、S銀行、N信託銀行、O信託銀行世界へ

２００６年高生産性開発言語開発(設計書からソースプログラムを自動生成）～

→上流工程～下流工程までをサポート - －

２００７年東証）ａｒｒｏｗｈｅａｄシステム開発にプロジェクトマネージャとして参画Ｃ、ＪａｖａＳｙｍｆｏＷａｒｅ１０月より →ＵＩ設計の後半より参画

2010年富士通アドバンストソリューションズ４月より

約３年間：開発現場でのコンピュータ操作および言語の習得　　→言語は主にCOBOL,FORTRAN，アセンブラ

少ないメモリでのオンライン／バッチの並行処理　　→オンライン業務プログラムは全てアセンブラで開発　　→オンラインはオーバレイプログラム構造

SUNﾜｰｸｽﾃｰｼｮﾝによるC/Sｼｽﾃﾑ

クライアントはWindows PCへ

東証宇治様へ

開発メンバ間で価値を共有するために特に意識したことは？

a. 委託側組織内b. 委託側から受託側に伝えるための工夫や努力

富士通アドバンストソリューションズ金子様へ

開発メンバ間で価値を共有するために特に意識したことは？

受託者側組織内での工夫や努力

富士通アドバンストソリューションズ金子様へ

価値の実現において発生した問題は？

a. 苦労した点は？b. どのように対応した？

会場からの質問

Technology

イノベーションスプリント2011 東証新株式売買システムarrowheadにおける開発プロセス