SQiP: 東京証券取引所 arrowhead 開発のユーザ側、ベンダ側双方のプロジェクトマネージャに聞く
-
- いいね！1
Yasunobu Kawaguchi
@kawaguti
宇治: プロジェクトの背景。市場環境の変化: 高頻度取引(HFT)への対応。2000年より前は東証にも立ち会い場があった。現在はコンピュータ対コンピュータ。旧システムのレスポンスタイム２〜３秒では海外の取引所に負けてしまう。 #SQiP
2011-09-09 09:25:45
Yasunobu Kawaguchi
@kawaguti
宇治: プロジェクトの背景。システム障害: ときの大臣からもしかられた。信頼が得られないと私設取引所に市場参加者が流れてしまう。 #SQiP
2011-09-09 09:27:02
Yasunobu Kawaguchi
@kawaguti
宇治: システムの目標。まずコンセプトを決め、できるだけ定量的に目標値を決めていった。次に、プロジェクトの運営方針決め。スローガンが必要。３年もプロジェクトやっているとみんなの考えが変わっていく。システム障害から何年も立つと忘れてしまう。なぜこのシステムを作るのか #SQiP
2011-09-09 09:28:39
Yasunobu Kawaguchi
@kawaguti
宇治: 上流工程をしっかりやるとか、民主的にやっていくとか。富士通さんと一緒にやったが、会社間の壁があるとうまくいくものもいかなくなるので、ワンチームだというスローガンも決めた。 #SQiP
2011-09-09 09:29:29
Yasunobu Kawaguchi
@kawaguti
宇治: プロジェクトのスケジュール 2006年〜2009年。内部的には遅延はあったが、なんとか外に見えないように(カバー)できた。プロジェクトメンバーの東証、協力会社、富士通の全メンバーを有明にプロジェクトオフィス２フロアを借りて全員同居。 #SQiP
2011-09-09 09:31:37
Yasunobu Kawaguchi
@kawaguti
宇治: プレジデントレビュー。偉い人の会議だが、現場の問題を出して、カンカンがくがくやった。意思決定のスピードが速まった。全体移行統制本部。ヘッドは専務にやてもらい、進みが悪いところはガンとやってもらった。 #SQiP
2011-09-09 09:33:26
Yasunobu Kawaguchi
@kawaguti
宇治: 打ち合わせスケジュール。同じビルなので、ビッチリと決まった打ち合わせをおこなった。 #SQiP
2011-09-09 09:34:10
Yasunobu Kawaguchi
@kawaguti
宇治: システム概要。200台のLinuxサーバをつなげた、機能分散かつ負荷分散。通常のデータベースは証跡ログのみ。取引はインメモリデータベース３重化。売買をするフロントサーバ部分と内部で使うバックサーバ群、絶対に止めちゃいけないところとそうでないところの優先度付け #SQiP
2011-09-09 09:36:08
Yasunobu Kawaguchi
@kawaguti
宇治: フロントサーバとバックサーバの同期はなるべく粗結合、非同期に。バックサーバに何かがあってもフロントサーバには問題が出ないように。高速性は2ミリ秒で、予定の1/5のレイテンシに抑えることができた。 #SQiP
2011-09-09 09:37:09
Yasunobu Kawaguchi
@kawaguti
宇治: 発注者責任の明確化。ベンダの提案の精度が低い？=>RFPの記述粒度が粗い。要件と実装の齟齬？=>要件定義に漏れがある。と考えて改善してきた。 #SQiP
2011-09-09 09:38:24
Yasunobu Kawaguchi
@kawaguti
宇治: 開発プロセスの改善。発注者はベンダに責任を押し付けることもできるが、結局顧客に見えるのは発注者なので、発注者がきちんと責任を持つべき。東証の社員はプログラムを書けないので外部コンサルの力を援用しRFP作成。 #SQiP
2011-09-09 09:40:00
Yasunobu Kawaguchi
@kawaguti
宇治: 詳細な要件定義書と外部設計書の作成は東証で。4000ページ。1k1ページくらいの分量。要件定義を第３者のコンサルタントにチェックしてもらった。ベンダーである富士通にもチェックしてもらって記述を追加。 #SQiP
2011-09-09 09:41:24
Yasunobu Kawaguchi
@kawaguti
宇治: 非機能要件がシビアだった。最後のチューニング段階で非機能要件を考えても間に合わないし手戻りが出る。性能、拡張性、信頼性のマネジメントの計画書、手引書をつくった。 #SQiP
2011-09-09 09:42:36
Yasunobu Kawaguchi
@kawaguti
宇治: 各工程でやるべきことをやろう。その例の一つが、発注者とベンダの間のリスク共有。東証の過去の事例だと、東証の受け入れテストでバグが出た。ベンダー内部のシステムテスト、総合テストの品質が悪かった。システムテストのバグ密度の目標値を0.3件/kstepとし、 #SQiP
2011-09-09 09:44:29
Yasunobu Kawaguchi
@kawaguti
宇治: 0.3件/kstepとし、半分ずつを東証と富士通の責任としてカウントしペナルティを設定。結果的には 0.23件/kstep だったのでペナルティはなしだった。 #SQiP
2011-09-09 09:45:31
Yasunobu Kawaguchi
@kawaguti
宇治: 要件定義書のメンテナンス、品質評価もきっちりやることを目標にした。要件変更の一件一件をきちんと管理した。ひとつひとつに承認プロセス。1000件の要件変更がでた。全てを宇治課長が確認、承認した。お金が発生するものはCIO承認。できるだけ要件がぶれないように。 #SQiP
2011-09-09 09:47:13
Yasunobu Kawaguchi
@kawaguti
宇治: オークションパターンの作成(Wモデル)。Wモデルの専門家からすると、こんなものはWモデルじゃないと言われるかもしれないがw、できることをやってみた。要件定義書が網羅的に書かれているかを確認。富士通の設計書レビューでも利用。東証の受入テストでも利用。 #SQiP
2011-09-09 09:49:30
Yasunobu Kawaguchi
@kawaguti
宇治: オークションパターンとは、売買の板(売り注文と買り注文のリスト)の状況とあるべき結果状況を表したもの。 #SQiP
2011-09-09 09:50:29
Yasunobu Kawaguchi
@kawaguti
宇治: 要件トレーサビリティ。要件定義書に書かれたものが100%成果物に反映されたかを調べるにはどうしたらいいか。要件定義書に書かれた要件要素は１万項目、その一件一件がすべて #SQiP
2011-09-09 09:51:27
Yasunobu Kawaguchi
@kawaguti
宇治: 詳細設計、結合テスト、システムテスト、受入テストですべて要件要素との対応をチェック。受け入れテストでは、要件充足度がどのようにあがっていったか(最後は100%になるはず)をチェックした。 #SQiP
2011-09-09 09:53:52
Yasunobu Kawaguchi
@kawaguti
宇治: V字モデル。従来、システムテストや受入テストで出ていたバグを、より早い段階で見つけ出すことを目標にした。フィードバック型V字モデル。プログラミングするときに設計書のミスを見つけた場合には、設計書にフィードバックして前工程の品質をあげる。 #SQiP
2011-09-09 09:55:49