□------------------------------------------------------------------□
□ Ａ社ＥＯＢ導入における、システムテスト計画について
□------------------------------------------------------------------□
---------------------------------------------------------------------
（設問ア）
---------------------------------------------------------------------
1.Ａ社ＥＯＢの構築
---------------------------------------------------------------------
1.1.システム導入の背景
----
Ａ社は東日本を中心に１００店舗を展開する中堅クラ
スのスーパーである。Ａ社における衣料品の売上は全体
の３割を占め、食品に続く重要なカテゴリーとして位置
付けられている。しかしながら、衣料品の店舗発注は、
紙ベースのオーダーブックと、ハンディターミナルを用
いた、バーコードスキャン方式による簡易なシステムで
あり、発注数量の決定は１０年以上のベテラン社員（売
場主任）でなければ作業できない状況であった。
一方でＡ社では西日本への進出を計画しており、ベテ
ラン層を各店舗に充分に配置する事は難しくなる事が予
想されていた。そこで、若手社員やパート社員での発注
をサポートする為に、エレクトリックＯＢ（以下、
ＥＯＢ）の導入を決定した。ＥＯＢは、商品の販売実績
や天候・来店客数等ガイドラインを参照しながら売場で
の発注を実現するものである。
私はシステムインテグレータであるＥ社に勤務してお
り、Ａ社ＥＯＢの導入に際し、営業時点より参画してお
り、受注後はＡＰＳＥとして開発に携わる事となった。
----
1.2.システムの概要
----
システムは、ＷＡＮ接続された本社サーバ・店舗サー
バ、およびＥＯＢから構成されている。約４０台の店舗
サーバはＥＯＢ受信時の時間短縮を狙いとして、中規模
以上の店舗に配置したものである。尚、ガイドラインの
基礎データは夜間に本社から店舗サーバに送信される。
ＥＯＢは本社サーバ又は、店舗サーバよりデータを受信
後、オフラインにて発注作業を行い、本社に送信される。
本社サーバではその後、伝票発行等のシステムに連動す
るものである。
---------------------------------------------------------------------
（設問イ）
---------------------------------------------------------------------
2.評価の対象とした品質要件とその理由
---------------------------------------------------------------------
2.1.店舗夜間バッチ処理終了時刻の保証
----
前述の通り、ガイドライン情報は夜間の内に、本社
サーバから店舗サーバに更新される。また、発注情報は
店舗サーバ経由で本社サーバに更新され、これらは
ＲＤＢＭＳベンダーとして実績のあるＯ社のデータベー
スおよび分散データベース機能を使用して構築されてい
る。
今回Ａ社から強く要請された事は、ガイドライン情報
の更新を行う、店舗夜間バッチ処理を朝９時迄に完了さ
せる事であった。これは、店舗オペレーションの組み立
てと、納品リードタイムから決定されたものであり、発
注は一日の早い時間帯に実施せざるを得ないとの事であ
る。もしも、店舗夜間バッチ処理の終了が９時を過ぎる
事になれば、接客等その他業務の関連から、現実的に発
注業務を行う事は難しく、Ａ社にとって大きな販売機会
損失を生み出す事となる。
プロジェクトでは最悪の場合を考慮し、店舗サーバ設
置店舗においても、本社サーバからのガイドライン受信
を可能な設計を行っているが、Ａ社の要請通り店舗夜間
バッチ処理を９時迄に完了させる事が最も重要な品質保
証項目であった。
尚、分散データベースの内容について整合性を保証す
る事は言うまでも無い。
----
2.2.データ量と予測された処理時間
----
過去の類似プロジェクトの実績から、分散データベー
スの更新については以下のオーバーヘッドを伴い、Ａ社
ＷＡＮ環境である６４ＫＢＰＳのネットワークにおいて
も、０．８ＫＢＰＳ程度の性能である事が予め判ってい
た。
a.更新データに加え、更新命令そのものがネットワー
クを流れる。
b.双方での２重更新のチェック、及びそのリカバリ。
従って店舗サーバーの更新対象データ１７０ＭＢを全
て分散データベースに構築する事は非現実的であり、
ＥＯＢでの更新処理有無を判断基準に、以下の通り店舗
サーバの更新方法を決定した。
更新有り：分散データベース（１０ＭＢ）
更新無し：ローカルデータベース（１６０ＭＢ）
ＦＴＰ＋取込処理により更新する。
以上の措置により、店舗サーバの更新処理は、６時間
で処理可能であると見積もる事が出来た。又、夜間バッ
チ処理の全体スケジュール上、店舗夜間バッチ処理の開
始は３時の予定であり、９時迄にはぎりぎり完了する見
込みであった。
---------------------------------------------------------------------
3.テストの制約と工夫
---------------------------------------------------------------------
3.1.店舗サーバー設置上の制約
----
Ａ社店舗サーバの設置台数は４０台であり、全てをＡ
社内に設置し、本番並の環境でテストを実施する事は、
事実上不可能であった。そこでプロジェクトでは、以下
の方針でテストを行う事とした。
a.Ａ社内に本社サーバ・店舗サーバを設置するが、
ネットワーク定義の変更により擬似ＷＡＮ環境を構
築し、６４ＫＢＰＳ下での性能を測定する。
b.店舗サーバの設置台数は４台が上限であり、１台か
ら順次設置台数を増やし、本社サーバのＣＰＵ・
ディスク等の負荷増加傾向を測定する。
c.以上の測定結果を元に、全４０台設置時の性能予測
を行う。
----
3.4.テストスケジュールの工夫
----
以下はテスト時の工夫というよりは、プロジェクト計
画時の工夫ではあるが、結果的に品質保証を行う上で重
要なポイントとなった為、あえて述べておきたい。
Ａ社ＥＯＢ導入プロジェクトの概略スケジュールは以
下の通りであった。
４− ７月：設計
８−１０月：開発
１１−１２月：テスト
１− ３月：運用教育
Ａ社の出店地域は５県にわたっており、運用教育に長
期間を要す点に特徴がある。Ａ社では運用教育を兼ねて
店舗サーバの設置を実施する予定であったが、自社から
の提案により、１２月末までに店舗サーバの設置を完了
させる事とした。これは、Ａ社内でのテスト時には本番
環境を用意する事が出来ない為、運用教育の２ヶ月間に
最終的なバッチ処理のチューニングを行う事を目的とし
て提案したものでる。事情を理解して頂いたＡ社からも
承認を得る事ができた。
---------------------------------------------------------------------
（設問ウ）
---------------------------------------------------------------------
4.テスト計画の評価と課題
---------------------------------------------------------------------
4.1.テスト計画の評価
----
Ａ社内における４台での性能予測結果、４０台を設置
した場合においても店舗夜間バッチ処理は充分に時間内
に完了する見込みであり、店舗サーバの設置も順調に進
んでいた。しかしながら、問題は店舗サーバの設置台数
が３０台を越えた時点で発生した。それは、分散データ
ベースの更新時に１回／週程度、本社サーバがハング
アップする事象である。
これについては、ＯＳ・ＲＤＢＭＳ・バッチ制御いず
れのベンダーにおいても事例が無く、アプリケーション
もしくは他社製品の問題であろうと、充分な対応を得る
事ができなかった。
設計時点では、以下を目的に分散データベースの更新
を本社再度で一括して行う事としていた。
a.店舗側にはオペレータが居ないため、店舗サーバの
更新状況を本社で一括して監視する。
b.障害時の再処理は本社オペレータが行う為、本社
ジョブとした方が容易に再処理を行う事ができる。
結局のところ、上記の設計方針を変更し、店舗ジョブ
から分散データベースの更新を行う事で問題は解決した。
改造に要するプロジェクトの負荷は大きかったが、運用
教育の２ヶ月間で問題を解決する事が出来た為、カット
オーバー時期を延期する迄には至らなかった。もしも、
店舗サーバーの設置を、Ａ社の計画通り運用教育時に
行っていたならば、３ヶ月以上の遅れは避けられなかっ
たであろうと判断する。一方で、Ａ社内に本番環境を用
意する事が不可能であれば、自社内あるいは外部環境の
借用を検討してでも本番並の環境を用意すべきであった
と反省している。
----
4.2.今後の課題
----
前述の通り、Ａ社ＥＯＢ導入プロジェクトではテスト
時に本番環境を用意する事が出来なかった為、問題の発
見が遅れてしまった。プロジェクトにとって最も重要な
品質項目を確認するためには、やはり本番並の環境が必
要であると判断する。
しかしながらこれについては、スケジュールとコスト
のバランスも重要である。スケジュールがタイトな場合、
コストをかけてでも本番環境を用意すべきであるが、余
裕がある場合には運用教育期間に最終テストを行い、品
質を作り込む事も可能である。
いずれにしても、スケジュールとコストについて顧客
と充分な協議を行った上で、プロジェクトの実行スケ
ジュール・テスト計画を策定する事が重要であると考え
る。
[ 戻る ]