システム開発の強い現場には，何らかの「仕組み」がある。現場で磨き上げられた仕組みに皆が自然と従い，仕事のやり方や職場環境を常に改善していく。そんな仕組みを追い求めて，今年初めから30社以上の開発現場を訪れた。日経SYSTEMS 2009年4月号の特集記事に向けた取材である。

　特集の執筆を終えたあと，三菱東京UFJ銀行のシステム統合プロジェクト「Day2」の開発現場を取材する機会を得た。ITproで何回も取り上げたのでご存じの方も多いと思うが，3年の期間をかけ，6000人が団結して成し遂げた世界最大規模のプロジェクトだ（関連記事1，関連記事2）。

　Day2のプロジェクトでも，現場からさまざまな仕組みが生まれていた。取材で聞いた二つの仕組みを紹介しよう。

移行時のテストケースやリスクを洗い出す

　二つの仕組みを作ったのは，法人向けサービスの分散基盤を開発する部隊である。Day2では，各種アプリケーションを支える基盤システムを先行開発し，リリースしていった。そこでできた仕組みが，のちの多くのサブプロジェクトに生かされることになった。

　一つめの仕組みは，システム移行のためのテストケースを漏れなく抽出するためのものだ。テストケースを洗い出す際に，どのようなドキュメントを順にチェックしていけばよいかを図にまとめた。

　対象となるドキュメントは，基本設計書，切り替えるパッケージ・ソフトなどの違いをまとめた仕様書，他のシステムとのインタフェース仕様書，移行計画書，業務担当者への指示書など多岐にわたる。それらを漏れなくチェックするために，テストケースの作成手順を標準化した。

　もう一つは，システム移行時のリスクを洗い出し，不測の事態に備えるための仕組みである。

　Day2におけるテストは，可能限り実際の稼働環境に近い形で実施することを心掛けた。システムを移行させる実際のマシンでソフトウエアを稼働させ，連携するシステムと実際につないで実施するといったものだ。

　しかし，実際の移行日にならないと実施できないテストがどうしても残る。例えば顧客の端末とつなぐ通信回線の切り替えは，トラブルが発生すると顧客に迷惑をかける危険性があるので，事前のテストは困難だ。そうした部分がリスクとして残る。

　こうしたリスクを漏れなく洗い出すために，回線の切り替えといった移行作業の項目ごとに実環境でのテストが可能かどうかを調べ，実施できないテスト内容を記入する表を作成した。