JMS 日本経営システム

経営シリーズ

  • 情報システム

ユーザーが創る情報システム~計画的なテスト推進で早期安定稼働を実現する

No.619 | 2021年11月号

今月の視点

 
 システム開発プロジェクトの成功とは、計画通りの品質、予算で、早期の安定稼働を実現することである。
 システム開発は、システムベンダー(以下、ベンダーという)に任せきりにしては、うまくいかない。ユーザーが実現したい要件をしっかりと伝えた上で、それに沿って設計しているかを監理するだけでなく、完成したプログラムを計画的にテストすることも重要である。
 予期せぬ不具合は必ず発生する。入念なテストが行われなければ、本稼働時に不具合が発覚し、プログラムや間違って生成されたデータの修正に追われることになる。
 今回は、システムのテストを計画的に推進し、早期の安定稼働を実現したA社の事例を通じて、その際のポイントについて考えてみたい。

1 テスト工程の概要

 テスト工程は、次頁のプロジェクト全体の推進手順に示す通り、プログラム作成完了後に、システムが不具合なく動作するかを検証する工程であり、「結合テスト」、「総合テスト」、「運用テスト」の3つの段階がある。


 テスト工程の多くはベンダーが行う作業だが、ベンダーは業務を細部まで熟知しているわけではないため、ユーザーの協力なくして、実際の業務運用を前提にしたテストにはならない。


 稼働までの期間で、効率的にシステムの品質を検証して作り込むためには、早い段階からユーザーが計画的にテストを監理し、業務運用を踏まえたテストを推進することが重要である。

 テスト工程の3段階における検証の内容及びユーザーの果たすべき役割は、次の通りである。


①結合テスト
 結合テストは、サブシステム単位で構成機能間のデータ連携を含めた動作検証を行う工程である。この工程の前半はベンダー側での検証が主となるが、これが一通り完了すれば、サブシステム単位の動作・品質を、帳票出力・データ照会の機能を使って、ユーザーも検証可能になる。
 この段階から、ユーザー自身が業務処理基準に沿った検証に取り組むことで、サブシステム単位の品質を作り込むことができる。


②総合テスト
 総合テストは、サブシステム全てを連結させた状態で、システム全体の動作を検証するための工程である。結合テストでサブシステム単位の品質を作り込んでおけば、この段階ではサブシステム間の整合性確認、インターフェースの動作検証、システム全体としての性能検証が主となるため、ユーザー側の負荷は小さくなる。

③運用テスト
 運用テストは、現場の事務担当者の協力を得ながら、実際の運用上問題がないかを検証する工程である。この工程は以下を目的としており、ユーザー自らが実施しなければならない。
・システムの操作性を含めた品質の最終的な作り込み
・新システムでの業務運用方法、処理基準の検証
・新システムでの業務運用に対する担当者の習熟度向上
・本稼働に向けたマスタ・データ移行のリハーサル


※テストとしては、プログラム作成と一体的にベンダーが実施する単体テストもある。単体テストでは、入出力やバッチ処理を構成する個々のプログラムが設計通り動作するかの検証を行うが、ユーザーの役割は、進捗管理やシステムエンジニア(以下、SEという)からの質問への回答などに限られる。


※ERPパッケージ導入を選択した場合も、業務・管理のレベルを落とさないための追加開発(アドオン、カスタマイズ)を実施すれば、上記全てのテストが必要になる。

2 A社の事例

(1)システム開発の背景

 A社は、全国に展開する建築資材メーカーである。
 高い営業力を武器に堅実に成長してきたが、近年は安価な外国製品の流入を主因として、事業環境が厳しさを増している。
 新しい独自製品の市場投入や積極的営業推進による販路拡大で、売上高は増加傾向にあるものの、利益は伸び悩んでいた。
 現行システムでは、営業活動において重要な原価・粗利情報を適切な区分で把握できない。システム外での情報蓄積・集計を始めてみたものの、人によって精度にばらつきがある上、この作業を担う間接部門要員の残業時間増加も課題になっていた。


 社長はこの状況を打開するため、システム再構築を決断した。
「製品群・販路が拡大したことで、現行システムと業務の乖離はさらに大きくなっており、必要な経営情報を適時的確に把握することができない。

 改めて自社の事業・業務を見つめ直し、あるべき業務・システムの姿を明らかにした上で、基幹業務システムを再構築し、的確な営業施策の立案や、業務の標準化・効率化につなげたい。」

(2)プロジェクトの始動

 社長は、営業部、経理部、製造部、システム管理室のメンバーと、主要拠点の総務責任者からなる、全社的な基幹業務システム再構築プロジェクトを発足させた。社内スタッフだけでは、業務・システムの要件調整がうまくいかず、システム規模が膨らむことや、知見の不足からベンダーの品質、コスト、スケジュールを適切に監修できないことが想定されたため、ユーザー側に立ったプロジェクト管理に定評のあるコンサルタントの支援を受けることにした。


 まず、プロジェクトチームは、現行システムの仕様、管理会計・原価計算制度、計数管理方法、日次・月次の業務処理方法の調査・分析に着手した。この過程で、様々な問題点や課題が見えてきたが、部分最適に陥らないよう全体統制を図りながら、自社に合った制度・業務を練り上げていった。
 こうして、次の3点を骨子とする業務・システムの基本要件書を作成した上で、開発工数を見積もって、スケジュールに展開し、システム全体のマスタープランを取りまとめた。


①原データを活用し、サブシステム間での人手を介さないデータ連携を追求した統合システムの構築

②事業分野拡大に対応した適切な利益管理セグメントの設定

③担当者によって異なる業務処理方法の標準化

 このプランに基づくベンダー選定は、ERP導入も視野に入れたが、A社は原価計算を中心に独自性が強く、適合度が高いソフトを見つけられなかった。適合しないソフトを選べば、追加開発による投資増大や、無理な業務運用につながる懸念もあるため、独自開発を選択することとし、的確な要件理解に基づき精度の高い提案内容を示したX社への発注を決定した。

(3)設計・開発工程


 設計工程の最初に実施する構造設計は、開発の成否を左右する重要な工程である。この段階でシステム構造を作り込んでおくことは、テスト工程の精度向上にもつながる。
 A社は、コンサルタントの支援を受けて、主導的に設計を監修し、X社と知恵を出し合いながら、以下の点に留意して新システムの基本構造を組み立てていった。

①シンプルなシステムフロー(システム処理の流れ)
 システムフローが長くなっても、構成する個々のプログラムは、条件分岐の少ないシンプルなものとする。プログラム構成がシンプルであれば、技術力の高いSEでなくても無理なく設計できることに加えて、テスト工程で不具合が見つけやすく、不具合発生時の対処も行いやすいというメリットがある。


②サブシステム間連携をシンプルにする設計
 サブシステム間連携が複雑になると、サブシステム単位の検証が行いづらくなる。そのため、販売管理システムから他システムに連携するのは、売上補助簿である売上データ、売掛金管理システムからは、売掛金補助簿である売掛金台帳データというように、サブシステム間連携は補助簿データを基本とした。


③ユーザー側での検証を徹底するための検証資料の充実
 入力データ、補助簿、総勘定元帳の全てが矛盾なく処理されているかどうか、テスト段階からユーザーの検証が行き届くように、検証資料・検証用データ出力を充実させる。


 こうして完成した構造設計書をもとに、基本設計ではプログラム構成、処理ロジック、出力機能・帳票様式などを具体的に展開した。構造設計、基本設計を通じて、設計を細部まで具体化したことで、SEの開発効率が高まり、詳細設計、プログラム作成もマスタープランのスケジュール通りに進んでいった。

(4)結合テスト計画の立案


 ベンダーのプログラム作成と並行して、プロジェクトチームは、結合テストの進め方を具体化することにした。
 結合テストの前半は、開発した機能が設計通り動作するかをSEが検証する工程であり、サブシステム内の機能間データ連携を含めた動作検証が完了すれば、ユーザーが立ち会って、構造設計書、基本設計書に沿った品質確認を行っていくことが可能になる。
 ユーザー立ち会いでの品質検証(ユーザーレビュー)は、総合テスト以降に行われるケースも少なくないが、不具合の検出が遅くなるほどリカバリーが大変になる。A社では、できるだけ早く不具合を見つけ出して対処するために、結合テストの後半でユーザーレビューを実施することを基本方針とした。具体的な結合テスト計画は、次の通りである。


①結合テストの実施スケジュール
 結合テスト実施予定期間3ヶ月のうち、最初の1ヶ月をベンダー側での動作検証、残り2ヶ月をユーザーレビューに充てる。

②品質検証の基準
 基本要件書、構造設計書、基本設計書をもとに、業務処理パターンごとの正常動作判定基準及び処理結果の確認帳票・データを設定する。主な内容は下表の通り。

③テストデータ

 実際の業務運用に即した検証になるように、現行システムの帳票・データをもとに、テストデータを準備する。また、他のサブシステムから連携されるデータを使用する処理については、連携データを事前に準備し、他のサブシステムの進捗から影響を受けないよう留意する。


(5)結合テスト計画に基づくユーザーレビュー


 結合テスト前半のベンダー側動作検証が完了した後、結合テスト計画に基づくユーザーレビューを開始した。ベンダー側で結合テストを実施している間に、テストデータの準備が完了していたため、スムーズにユーザーレビューを開始することができた。
 レビュー過程では、A社のプロジェクトメンバー、コンサルタント、X社プロジェクトマネージャー、各サブシステムの統括SEが立ち会って、合同で各機能の正常動作判定を実施した。

 構造設計工程で、ユーザーが積極的に参加してシステムの基本構造を詰めてきたため、構造的欠陥はなかったが、設計上の考慮不足やプログラム不具合は見つかった。また、入力画面や出力帳票の検証過程で、実際の数字が入った帳票や出力画面を確認したことで、A社の業務要件と合わない部分も見えてきた。
 こうした内容は、ベンダーが単独で検証しても見つけられるものではなく、業務を理解しているユーザーの目を通すことでしか発見できない。問題点の件数としては多かったが、結合テスト段階で見つけられたため、すぐに担当SEとプログラム改修方針を詰めることができ、細部まで丁寧に作り込んでいった。

(6)総合テスト


 ユーザーレビューを通じた作り込みにより、サブシステム単位の完成度が高まっていたことから、総合テストではサブシステム間の連結部分に検証の重点を絞ることにした。
 例えば、セグメント別売上・粗利の実績を管理するサブシステムは、サブシステム内の構造は単純だが、営業情報管理システム、販売購買管理システムからの連携データを使用しており、間接的には原価計算システムの原価情報も使用することになる。
 このように複数サブシステムとの連携を前提とした機能は、総合テスト段階での品質の作り込みが鍵になる。
 そのため、総合テストの検証対象データは、できるだけ実際の運用状態に近づけることを重視した。他のサブシステムで入力されたデータを使用するだけでなく、現行マスタ及び過去実績データの移行リハーサルとの同期化により、起こり得るパターンが網羅された過去実績データ(売上データ、仕入データ等)も使用して、検証を行うこととした。


 検証作業自体は、ベンダー主体で実施したが、不具合対応の管理(要因把握、修正仕様・進捗、再テスト)、サブシステム間のスケジュール調整・移行リハーサルとの同期化といったスケジュール管理については、A社が主体となって実施し、計画通りに進めていった。


(7)運用テスト

 当初、運用テストは新旧システムの完全並行稼働を実施することを目指したが、現在の支店・工場の事務担当者の要員体制で、現行業務を抱えたまま、新システムを同時に動かしていくことは繁忙度が上がり、テスト精度や、ひいては社員の士気の低下にもつながることが危惧された。

 この状況を踏まえ、以下の2段階に分けて運用テストを進めていくことにした。


ⅰ)テスト前半は、実施対象拠点を絞って、現場運用におけるシステム品質検証、操作性の作り込み、移行リハーサルを行う。また、各主要拠点に2〜3名程度のシステム導入・展開の中核スタッフを育成する。

ⅱ)テスト後半は、実施対象拠点を全社に拡げる。売上・請求や仕入・支払といった外部取引に関わる主要機能は、本番運用レベルの入力を実施するが、機能によっては入力ケースを絞るなど、テスト内容に軽重をつける。


 運用テストを実施する過程で、様々な改善要望が現場から挙げられた。
 こうした改善要望への対応を性急に進めれば、基本要件との矛盾が生じたり、思いもよらない不具合を引き起こしたりと、かえって確実な本稼働を阻害するリスクがある。
 そのため、プロジェクトチームは、改修要望を詳細に聞き取って整理しつつも、基本要件の範囲での稼働を最優先した。この時点では、追加・改修対象を「本稼働に支障をきたす重要事項」に絞り、追加・改修による大きな効果が見込めるような要望であっても、本稼働後の整備事項とした。


 さらに、安定運用に向けて、新システムの前提となっている新しい業務要件が遵守される必要があるため、現場の事務担当者が理解できるようにマニュアルとして編集し、これをもとに業務統制を進めていった。運用テストを通じて、マニュアルは一層業務に即した内容にブラッシュアップされ、本稼働後も業務手順書として活用された。


 こうして運用テストが完了し、当初のスケジュール通りに本稼働に至ることができた。総合テスト、運用テストの各段階で移行リハーサルを行ってきたことも奏功し、移行トラブルは、ほとんど発生しなかった。
 本稼働後は、運用ミスによるデータ不具合などが多少発生したが、すぐに解決することができ、数ヶ月で安定稼働に至った。
 その後、運用テスト時及び本稼働後に出された改善要望を、システム整備計画として取りまとめ、追加・改修作業を計画的に推進した。

 その結果、1年を待たずして、あるべき業務への改革が実現され、間接部門要員の残業時間の大幅な削減につながった。加えて、原価・粗利情報を適時的確に把握できるようになり、営業展開の武器になった。


 新システムは、A社の事業推進に不可欠なツールとして定着し、営業施策立案、業務標準化・効率化の両面で、所期の成果をあげている。

3 留意点


①結合テストでサブシステム単位の完成度を高める
 ベンダーによる結合テストは、基本設計書に基づいて想定データを作成し、動作検証を行うという流れが基本である。
 しかし、業務を熟知しているわけではないベンダーが、実際の運用で起こり得る処理のパターンを網羅することは難しい。
 パターンが限られれば、検証レベルは高まらず、総合テスト、運用テスト段階でプログラムの不備、不具合、業務要件との相違が頻発し、本来、なすべきことに手が回らなくなってしまう。
 このような事態に陥らないよう、現実的な業務運用に即した質の高いテストを実施するには、ユーザーの主体的参画が不可欠である。
 

 具体的には、ユーザーが基本要件書に基づいて業務処理パターンを展開し、業務処理手順に即して事前にテスト仕様(検証パターン・検証事項等)を作り込む。その上で、結合テスト後半を主導的に監修して、サブシステム単位の完成度を高める。


 ユーザー主導となる結合テスト後半で、効率良く品質の作り込みを進めていくためには、ユーザーレビューによりユーザーの目を通すことが重要である。
 設計上はユーザーの要求仕様を満たしていても、ユーザーの業務要件に合致するシステムになっているとは限らない。設計段階でユーザー・ベンダー間のすり合わせを徹底し、認識の乖離をなくすことが基本だが、設計書だけではユーザーが十分にイメージを持てないことが多いためである。
 結合テスト前半でのベンダー側動作検証が一通り完了すれば、基本的な動作不良はなくなり、実際に開発されたプログラムの動作をユーザーが見ることが可能な状態になる。この段階でのユーザーレビューにより、ユーザーが直接目を通さなければ見つけられないような問題点を早期に見つけ出し、時間的な余裕を持って改修対応を行うことが望ましい。


②総合テスト段階で移行データを使用して検証精度を高める
 総合テストの重点チェック対象であるサブシステム間の連携部分では、想定外のデータによる不具合が起こりやすい。
 これらの不具合を確実に潰すためには、実際の業務で起こり得るデータのパターンをできる限り網羅することが大切であり、実際の業務運用で作成された過去実績データを使用した検証が有効である。A社のように、移行リハーサルと同期化し、画面入力や想定データだけでなく、移行対象の過去実績データも活用して検証を行うことで、データの網羅性、検証精度は飛躍的に高まる。
 事前に計画していれば、現行マスタ及び過去実績データの移行リハーサルのタイミングを総合テスト着手段階に合わせることは十分に可能である。本稼働時の移行不備によるトラブル削減も見据え、この段階での移行リハーサル実施及び総合テストとの同期化をテスト計画、移行計画に組み込みたい。

③実現性の高い運用テスト計画を立てる
 運用テストを効率良く進めていくためには、現場事務担当者の積極的な協力が欠かせない。事前に現場の要員体制を念頭に、テスト計画を綿密に準備する必要がある。
 運用テストの目的は、以下の2点に大別される。
 ⅰ)現場での業務運用に耐えるレベルになっているかどうかの品質確認及び最終的な作り込み
 ⅱ)実務担当者の新システム運用習熟


 運用テストで新旧システムの完全並行稼働を行うことで、上記のⅰ)、ⅱ)ともに、高いレベルで実現することを目指すという方法もあるが、要員体制面の事情で難しい場合も多い。これを無理に進めようとすれば、現場の疲弊につながるだけでなく、広範囲でのテスト実施への対応は、システム開発側の負荷も高くなるため、本稼働にも影響しかねない。
 ⅰ)の目的に対しては、テスト範囲を限定する方が、かえってうまくいくこともある。一方、ⅱ)の目的では、できる限り全社的に展開・浸透させることが肝要である。これら2つの目的を認識した上で、実現性の高い運用テスト計画を立てなければならない。

 今月号をもって、「ユーザーが創る情報システム」の、プロジェクト計画からテストに至る一連の留意点を整理することができた。最後に、そのバックナンバーを整理しておきたい。

全  体  像:ユーザーが創る情報システム №468
上流工程:プロジェクト計画で成功への道筋をつける №497
マスタープランで成功への基盤を固める №585
開発の成否を分けるベンダー選定 №606
中流工程:ユーザー主導の設計監理で開発を軌道に乗せる №594
下流工程:計画的なテスト推進で早期安定稼働を実現する 今月号