• ビジネス
  • IT
  • テクノロジー
  • 医療
  • 建設・不動産
  • TRENDY
  • WOMAN
  • ショッピング
  • 転職
  • ナショジオ
  • 日経電子版
  • 日経BP
  • PR

  • PR

  • PR

  • PR

  • PR

古いシステムの捨て方

基幹系システム再構築プロジェクト、三つの失敗要因 (2/3)

大山 宏=NTTデータ 2017/03/21 日経SYSTEMS

現行踏襲部分の仕様が不明確で、どこが悪いのかわからない

 上記作業によって一通り、仕様変更箇所の現行仕様を明らかにし、開発作業に進んだ。しかし、変更箇所以外でも、修正が難航した。理由は、ツールによるソースコード自動変換のみでは済まなかった部分があったことだ。

 具体的には、これまで仕様変更を繰り返し行ってきた複雑なプログラム部分をツールで変換すると、現行システムの仕様の動きと異なる部分がいくつか発生した。詳細を見ると、変数定義の使い方やエラー処理の使い方が混在していた。そのため自動変換ができず、混在した変数定義やエラー処理を一元化するよう手直しが必要になった。また、仕様変更要件の取り込みに際し、データモデルの一部見直しも発生。現行踏襲部分への影響範囲も拡大し、修正範囲の特定に困難を極めた。

 その後、変更要件を反映済みのプログラムのテストを実施したところ、多くのバグが見つかった。主な原因は、仕様変更がない部分の業務仕様が設計書に反映されていないため不明瞭であり、仕様変更による影響の調査に漏れがあったこと。つまり、現行システムの仕様把握ができない状態の中での仕様変更により、変更がない部分も含めてシステム全体の品質が低下したわけだ。

 その結果、このバグは、仕様変更に対する対応の誤りなのか、そもそも現行踏襲部分に問題があったのか判断できなかった。仕様変更後の品質担保どころか、現行踏襲部分の品質も担保できない状況に陥った。これによって設計しなおしが必要になり、この時点で当初計画よりも4カ月遅延することが明らかになった。

終らないテストに突入する

 それでもなんとか、結合試験を終え、システムテストフェーズまでこぎつけた。まず現行システムと新システムとの比較試験を実施したが、ここでも、現行業務の理解が不足していたため、障害解析で難航した。主な理由は、試験の完了条件を設定できなかったことだ。通常、設計書があれば、設計書をベースとして試験を実施する。しかし、設計書が存在しない、もしくは設計書があってもその内容に不備がある可能性があるため、現行システムと新システムとの比較試験は、データをベースとした試験となった。つまり、日次データや月次データなどの特異日のデータを抽出し、試験を実施する。この際、仕様の理解不足により、次のような事象が発生した(図2)。

図2●ある基幹系システムの再構築における品質の問題
[画像のクリックで拡大表示]
  • 試験データを流し始める初期環境をどのように準備すればよいか分からない
  • 試験を始められても、不具合発生時に、準備したデータの問題なのか、処理を流す順番の問題なのか、切り分けが困難
  • 最終的に、ある1日のデータでは現行と新システムが一致したが、別の日のデータを流すとまた不具合が発生するなど、データバリエーションをどこまで考慮すればよいか判断できなくなり、終わらない試験に突入する

 現行システムの情報が不足していることから、試験計画も立てられない中、プロジェクトの計画から見直した。具体的にはまず、試験計画を立てるために、ベンダー側で業務処理フローやジョブ処理フローを整理した。次に、ユーザーの現行業務にかかわっているユーザーに、各種フローの正しさを確認してもらった。

 さらに総合運転試験の計画においては、ユーザー運用部門有識者を増員した。これにより、システム運用フローや運用タイムチャートを整理し、開発計画へ反映を行った。システムテストから総合運転試験にかけて、上記整理と計画の精緻化に2カ月を要した――。

あなたにお薦め

連載新着

連載目次を見る

今のおすすめ記事

  • 【VoLTEの謎】

    格安スマホでもVoLTEは使える?

     最近はMVNOが提供する格安スマートフォン(スマホ)を利用する人が増えています。こうした格安スマホのユーザーでも新しい音声通話技術である「VoLTE」は使えるのでしょうか。

ITpro SPECIALPR

What’s New!

経営

アプリケーション/DB/ミドルウエア

クラウド

運用管理

設計/開発

サーバー/ストレージ

クライアント/OA機器

ネットワーク/通信サービス

セキュリティ

もっと見る