|
テレマーケティングセンター構成図 |
［題名］ 『テレマーケティングシステム設計の考察』
所 属： ＧＢ・ＳＩ事業推進部
執筆者： 増田 一成 プロジェクトスペシャリスト
［要約］ 日本の通信販売業は近年大きく成長したが欧米では小売業に占める割合もさらに大きく、今後も大きな成長が期待できる。通信販売は大量に正確に速くかつコストをかけないで直接顧客に販売する上に相手が見えない難しさがある。1日の受注件数が1000件を越えると人手で処理するのは不可能になる。大手の通販業の年商は数百億円以上で１日の受注件数も数万件に達する。当然システム化するのは必須であるがその構築はオンラインリアルタイムでデータ更新・蓄積を伴い一般の顧客を相手にお届・支払などの条件が組み合わされるので簡単にはできない。かつ出荷伝票発行のバッチやテレビショッピングは短時間に受注が集中するためシステムに大きな能力が求められる。
汎用機からのダウンサイジングとクライアントサーバーシステムで通信販売システムを構築することによってそれらの難しい条件を克服しさらに、世界の通信販売業テレマーケティングセンターで最も進んだ次の特長を持つシステムを実現した。
１．コンピューターと電話交換機の結合による受注効率の改善。
２．クライアントサーバーシステムによる負荷分散。
３．コードレス入力やカタログ検索などイメージデータの有功利用。
このシステムは９７年１月すでにある通信販売企業においてカット・オーバーシし１０％を超える売り上げの増加に対応し使いやすさは利用部門からも高く評価されている。また先進性故に海外のシステムを熟知している外資系通販会社や国内同業他社の次期システム検討の対象となり、見学された企業から次々と採用されている。
本論文は次の点について論じている。
１．通信販売業およびその中核としてのテレマーケティングセンターシステム
（直接顧客を相手とする諸問題）
２．システムを設計・開発する上の考慮点
（オンラインリアルタイムの特徴をそなえている）
３．構成とツール
（ＡＳ／４００およびＰＣなど）
４．システムの効果と適用
（受注時間の短縮など経営効率向上に大きく寄与する）
［キーワード］ １．テレマーケティング ２．ＣＴＩ ３．ＡＳ／４００
目次
１ はじめに
２ テレマーケティングシステムの特徴
２−１ 主要業務
２−２ リアルタイム受注のピーク
２−３ 受注データ
３ 設計の考慮点
４ 構成
５ テストと開発ツール
５−１ テスト
５−２ 開発ツール
６ 開発の考慮点
６−１ クライアントサーバーシステム
６−２ ＡＳ／４００システム
６−３ ＣＴＩ
７ おわりに
１ はじめに
無店舗販売は小売業の中で大きな位置を占め、今後も大きな成長をすると期待されている。無店舗販売は大きく通信販売と訪問販売に別れ、戦後化粧品を中心に訪問販売が伸びた時期があったが、７０年代から通信販売が急成長を始めた。
通信販売は明治時代の中期から百貨店・種苗を中心に存在したが、一部の業者が粗悪品を詐欺まがいで売り付ける行為によって消費者に悪いイメージを植え付けてしまい業界の発展を著しく阻害した。現在でも中高年に通信販売を嫌う人が多いのもこの影響と言える。
７０年代高度成長経済とカラーテレビの普及率が１００％近くになった背景をもとにテレビショッピングが始まり、テレビというメディアの信頼感・タレントの親近感とあいまって好感度のイメージを消費者に抱かせることが可能となったことが業界の成長に大きく貢献した。また１９８３年に社団法人日本通信販売協会（ＪＡＤＭＡ）が設立され業界の健全な発展と消費者の信頼獲得に大きく貢献した。
余談ではあるが通販・テレマ関係の書籍は一般書店では入手困難だがＪＡＤＭＡでは閲覧・購入が可能だ。また通信販売・テレマに関する最新情報は通販新聞（週刊）で容易に漏れなく得ることができる上通販業界人が必ず読んでいるので担当される方には定期購読することをお勧めする。
現在ではわが国の通信販売の年間売上金額は２兆円を超え小売業売上の約１．５％を占めています。しかし米国では１０％を越え欧州先進国でも日本以上の国がかなりあることから見るとまだまだ発展の可能性を持つと推測できる。（注１）実際この業界に参入する企業は後を絶たず、ＪＡＤＭＡ会員も年々増加している。富士・さくらなど主要な総合研究所では２０００年に３．５兆円で小売業の２％を越えると予測している。
通信販売はコンピューターと密接に結びつき大手通信販売業に不可欠であり、年商に占めるコンピューターコストの割合は５％から１０％と高い。なぜならば通信販売では電話とともに受注を入力し配送伝票を発行し代金を回収するしくみ（フルフィルメント）がコンピューター無くしては不可能であることと、コンピューターを小売業の店舗にあたる設備と認識しているからである。またしくみを複雑にする要素として次のことが上げられる。
−受注から納品まで店頭販売に負けないため」できる限り短期間に縮める必要がある。
−受注から納品・回収まで個別の情報を継続しなければならない。
−返品・クレーム・問い合わせを考え長期間のオンライン情報保存が必要となる。
−一部キャンセル・返品など例外処理が多い。（例外が一般的）
−支払形態が先払い・後払い・代金引き換え・クレジットカードなど多様である。
−顧客件数が著しく多い（数百万件はざらにある）
−受注形態も電話・はがき・ＯＣＲなど多様にある。
−受注件数も1日数万件と多く相手も一般消費者であるため対応が難しい。
なかでも受注センター（テレマーケティングセンター）はコンピューターの活用により最も効果が期待できかつ対顧客ということで企業の命運を担う最重要な適用業務である。
電話（データの発生源）・データ入力・コンピューターが人手を介して結びついているところに、システムとしてより創意とくふうが可能なはずである。
海外通販の最新動向を参考に利用部門のニーズを実現するテレマーケティングセンターを中心とした業界最新のシステムを構築することができた。そこでそのシステム構築の設計・開発時検討した点を中心に考察した。
注１：主要国の１９９５年における市場規模と小売業内のシェア
日 本 ： １６９億ドル（１．５％）
アメリカ：２１９９億ドル（１２．１％）
ドイツ ： ２８１億ドル（３．９％）
２ テレマーケティングシステムの特徴
２−１ 主要業務
テレマーケティングセンターは電話で通信販売の注文を受けることをメインの業務とする部署である。直接顧客（消費者）の窓口として通販企業で最も重視され企業のトップから注目されている。主な業務として次のものがある。
（１）電話からのリアルタイム受注
ピーク時には電話を切るやいなや次の電話がはいり入力したデータを確認する時間も無い。注文する顧客は事務的なことに慣れていないことが多く正確に受注を受けることは容易でない。オペレーターは大半がパートタイマーでかなりの企業で定着率に問題があり、経験や臨機応変の対応に期待することはできない。むしろオペレーターには何も考えさせず、コンピューターからの指示どおり対応させる必要がある。
（２）カタログ到着の確認などのアウトバウンド（センターから顧客への発信）
まだ顧客リストを見てオペレーターが手動でダイヤルしている企業が多い。コンピューターがダイヤルするパワーダイヤルやプリディクティブダイヤリング（注２）を実施しているケースは少ない。
（３）お問合わせ回答（未着・納期など）
持ち帰りが無いのと顧客は購入したらすぐ手に入れようと欲するため問い合わせは多い。
（４）相談・クレームなどの受付
通販企業として他社との差別化に力をかけたい点である。
（５）商品・価格などに関する質問の受付
質問はそのまま受注につながることが多い。
（６）はがきなど別の受注媒体・メモなどからの入力
人件費・電話代が世界一高い日本では『はがき』入力のコストの方が安い。
アメリカをはじめ海外では電話の方がコストは少くすむ。
（７）顧客などのマスター登録
電話番号から代表者名・住所など電話帳ＤＢを使って効率よく入力したい。
（８）納期遅延通知・招待券などの発送
対顧客窓口としての付随業務。
注２：プリディクティブダイヤリングとは空いているオペレーターがいない時にも
コンピューターが電話をかけ、相手が出た時に空いているオペレーターに割り
当てるかけかた。オペレーターの稼働率（実際の話している時間）を最大にす
ることができる。空くはずのオペレーター数を予測してかけるだけに最悪の場合
は顧客が出たのに切ることもあるので運用は難しい。
２−２ リアルタイム受注のピーク
注文を受ける受動的な業務に関してピークは避けられない。業態により程度が異なる。
一般に電話などのランダムに発生する事象はポアソン分布に従って単位時間あたりのピーク件数を見積もればよいが、通信販売では一概に言えない。カタログ受注（顧客が郵送されたもしくは書店などで購入したカタログを見て購入を申し込む）の場合にはカタログ到着・購入のタイミングが受注開始とずれているので、受注開始日には集中するが、件数が通常の数倍程度でありその中で発生がポアソン分布になっている。
しかしテレビショッピング（テレビ番組の中で商品を紹介し電話で受注する）の場合はそれではすまない。紹介した瞬間に電話に殺到するため電話局の受付ベース（電話局の記録から）で５０００件／分を軽く越える。ただし回線数（だいたい端末数と同じ）を越えた分は局で話中となりシステムには来ない。理論的には最大回線数と同じ件数が瞬間に発生する筈であるが実際は数秒間に分散している。理由として考えられるのは次の点であるがこれは検証できていない。（実証が困難）
電話交換機処理がシリアルなのでコンピューターに渡すのはシリアルになる。
交換機と顧客の間に待ち行列ができ、その間は呼び出し音になっている。
（ボリュームテストでは同様の現象は観察された）
テレビの送り手（キャスター）が今から注文を受けますといったピークを作らないようにして商品を紹介中でも機の早い顧客からどんどん電話がはいるようにし、端末を処理中にしてしまう。当然回線も塞がっていくのでピーク件数がいくら多くなっても空いた回線分しか集中しない。（その分、後からかけた顧客を待たせることになるがピークは分散する）
２−３ 受注データ
顧客からの電話による会話から直接入力するので原始伝票が存在しないため事後に調べようが無いという最大の問題が基本にあり次の特質を持つ。
（１）他に確認するデータ（伝票）を持たない。
メモをとる顧客はほとんど無く顧客の勘違いによる返品も発生する。
データを確認する方法は基本的には無い。
（２）顧客マスター未登録の新規受注がある。
化粧品・下着のように継続性の高い商品での新規顧客比率は１０数％前後だが
総合通販とくにテレビショッピングでは５０％ぐらいになる。
（３）使用期間中のクレーム／返品へ対応するため長期間保存する。（通常２年ぐらい）
５年前・１０年前の購入商品のクレーム・返品も発生するがシステムでは対応しないのが一般である。
（４）代金回収までの状態の変化を記録しなければならない。
台帳や品物を調べられる件数をはるかに越えておりコンピューターのデータだけがたより。
（５）ほとんどの項目に変更がありうる。（取消しも含め）
顧客は気が変わり易いので（とくに注文直後）変更を可能にする。
一般のは当日キャンセルが全キャンセルの半分で翌日キャンセルがその半分。
（６）プレゼント・実家や別荘などへ滞在の購入者以外のお届け先違いへ対応。
その時だけ／数ヶ月継続などいろいろある。
（７）同一電話番号の共同使用や移転などがあり顧客の特定は簡単にいかない。
名寄せの必要性の有無を確認する。
（８）購入代金の支払いを期待できないブラック顧客への対応が必要。
特定の地域や住所すべてをブラックにする場合がある。
（９）イタズラや異常な精神状態での注文がある。
アウトバウンドによるスクリーニングも必要となる。
注文にならない電話もあるがこれはシステム外の運用で対応する。
（１０）１顧客から一時に大量（品目数・個数）に注文を受けることがある。
専門の係りや正社員が別途対応した方がよい。設計上も例外処理にする。
（１１）質問やクレームと同時に注文を受けることも多い。
問い合わせ画面から受注画面にはいつでも切り替え可能にする。
３ 設計の考慮点
オペレーターの大半がパートタイマーであり電話の相手がすべて一般個人客で記録を取らないことを前提として設計しなければならない。原票も請書も無く信頼関係だけでなりたっているのでなおさらトラブルは許されない。わずかなトラブルでも顧客を失うことに直結する。また大半の商品が必需品ではなく消費者の感性や欲望を刺激して購買動機をつけるので話中で受けられない時間が続くことはそのまま販売機会の喪失になることが多い。さらにテレビショッピングでは１０％を越える高い比率で当日・翌日の注文キャンセルが発生するので、キャンセルは例外ではなく通常処理の１つである。また注文後に色・サイズを変更することも多い。とくに深夜のテレビ番組での受注データは顧客の記憶が不確かなことが多く後のトラブルの原因になりやすい。
（１）受注データが消滅すると回復不能なので、故障などどんなことがあっても蓄積された受注データを保障する。
（２）注文の整合性を確保するため１受注ごとにコミットする。受注中のダウンに対しては少なくとも１件前の顧客のデータまで保障し、受注中の顧客の注文は手書きで受けて確認する。受注中顧客の前の受注商品まで保障することにすると設計が一段と難しくなるので避けたい。
（３）コンピューター故障時は手書きですべて受け、回復時にコンピューター入力するしくみを準備する。限定数を越えたら抽選する商品の場合はこの方法で問題無い。先着順の商品の場合は納期がかなりかかる時には遅延ハガキ、限定数を越えている時には品切れお詫びハガキを出してアウトバウンドでフォローする。
（４）配送伝票発行などのバッチ処理はオンライン受注と並行し何時でも実行可能にし、処理時間の遅延やリランの影響が無いようにする。
（５）カタログのページ／テレビショッピングの写真などから該当イメージをクリックすることにより品番入力に代替する。
（６）イメージのレスポンスタイムを早めるため標準イメージを初期に表示させその後の画面確認の間に次の拡大／縮小イメージを準備しておく。
（７）大量のカタログ／商品イメージ準備用のソフトを作成する。
商品の確定と販売開始時期の間に十分な日数をとることはできないのでイメージ入力の負荷計算が必要。品番とのリンク・色合いの調整がありイメージ入力はＨ／Ｗの性能どおりにはできない。
（８）数百台のクライアントＰＣの外字を統一することは困難なので運用で逃げる取り決 めを作成する。ＪＩＳ第二水準までを漢字で表記することで止めたい。
（９）ファイル更新はデッドロックを避けるためすべての更新ファイルの更新順序を決め
更新ロジックの標準化をはかる。
（１０）クライアントサーバー間の受け渡しデータを明確にしてフォーマットの約束は初
期に定義し開発中に変更しない。（データフロー記述で定義する）Ｄｅｌｐｈｉ
ではパック１０進数をＡＳ／４００と受け渡せないのでゾーン１０進数で定義
する。
（１１）現在ＮＴＴが一部地域で試行している発信者番号通知（ＩＳＤＮ／携帯電話では
実施済）を利用しオペレーター入力を省略して顧客の電話番号をシステムにとり
こむ。さらに電話番号ＤＢを利用して名前・住所もとりこむ。注意しなくてはな
らないのは勤務先・親戚知人・公衆電話の利用もあることである。もちろん発信
者番号通知そのものを止めていることもあることを忘れない。
４ 構成
ＡＳ／４００をホストとして電話交換機（ＰＢＸ）とＰＣを介して結合しコンピューター・テレフォニー・インテグレーション（ＣＴＩ）を実現した。過去のシステムは汎用大型機で通常のオンラインリアルタイム処理であったがテレビショッピングのようにトランザクションが１０件／秒を越えるとレスポンスタイムが３０秒を越え実質的に故障と同じ処理（手書き受注を閑散時にコンピューター入力）をせざるをえなかった。ＡＳ／４００のクライアントサーバーシステムはピーク時も１秒以内をキープし汎用機を越える性能を証明した。（ＲＡＭＰ−Ｃ ７５，０００件／時まで対応した）
ＰＢＸからの信号・データを受付てＰＢＸを制御するにはＡＳ／４００のソフトウェアであるＣＡＬＬＰＡＴＨ／４００が必須でＲＰＧスキルで使いこなすことができる。ただしＣＡＬＬＰＡＴＨ／４００がサポートできる機種は下記（２）の３機種しか無くかつ機種によりサポートできる機能には次表のとおり差があり選択には注意が要る。もちろん
ＣＡＬＬＰＡＴＨソースの互換性はなく機種が変われば書き直しとなる。
交換機による主な違い（その他の点はほぼ同じ）
|
|
|
デフィニティ |
メリディアン |
アペックス |
|
|
待ち呼管理 |
待ち呼数 |
ﾄｰﾀﾙ着呼数 |
待ち呼数 |
|
|
ﾌﾟﾛｸﾞﾗﾏﾌﾞﾙ |
ベクターＰＧＭ可 |
可＋テーブル |
保守コンソールより可 |
|
|
スキル指定 |
個人レベル |
席で固定 |
席で固定 |
|
|
ﾌﾟﾚﾃﾞｨｸﾃｨﾌﾞﾀﾞｲﾔﾘﾝｸﾞ |
CALLPATHで可 |
CALLPATHでは不可 |
CALLPATHでは不可 |
|
|
ﾊﾟﾜｰﾀﾞｲﾔﾘﾝｸﾞ |
可 |
可 |
可 |
|
|
状況把握 |
3秒ﾘｱﾙﾀｲﾑ/ｲﾍﾞﾝﾄﾄﾞﾘﾌﾞﾝ |
30/60秒ｲﾍﾞﾝﾄﾄﾞﾘﾌﾞﾝ |
3秒ﾘｱﾙﾀｲﾑ/ｲﾍﾞﾝﾄﾄﾞﾘﾌﾞﾝ |
イメージデータはビットマップで持つと１枚数ＭＢとなり２万件以上の商品やカタログページの情報は持ちきれない。（カタログはほぼＡ４サイズでカラー）圧縮は１０分の１から１５分の１が実用的である。印刷・写真の精度にもよるがそれ以上圧縮すると見た目にも粗く感じる。イメージデータはすべてをクライアントに持たせることがパフォーマンス上望ましいが、ディスク容量を考えると不可能なこととイメージ配布の作業負荷を考え頻度の非常に高いものをクライアントＰＣにそれ以外をイメージサーバーに持たせバックアップおよび配布のソースをＡＳ／４００のディスクに持たせた。イメージの利用頻度とＬＡＮのトラフィックを考慮しイメージサーバーはクライアント４０台に1台ぐらいに置いた。（商品数が数百件以下であればイメージサーバーは不要）
イメージデータの計算例
|
|
種類 |
色 |
画像の大きさ |
件数 |
容量／件 （KB) |
全体容量 （GB) |
|
|
カタログ |
カラー |
８８５×１２６１ |
4,000 |
300 |
1.2 |
|
|
商品写真 |
カラー |
５１２×７６８ |
60,000 |
70 |
4.2 |
|
|
商品仕様 |
モノクロ |
１０２４×１５３４ |
40,000 |
100 |
4.0 |
|
|
メモ |
モノクロ |
１０２４×１５３４ |
4,000 |
100 |
0.4 |
|
|
ＴＶ用写真 |
カラー |
５１２×７６８ |
3,000 |
70 |
0.2 |
また解凍はＣＰＵをかなり消費し圧縮率・画像の大きさ・カラー・ＣＰＵ能力・画像処理プロセッサー・画像処理ソフトなどの組み合わせで処理時間が大きく異なり、応答時間に数秒から数十秒の影響を与える。今回は組み合わせたテストの結果下記の（５）を選択した。
イメージ処理パフォーマンステスト結果（抜粋）
|
|
PCマシン |
画像の大きさ |
色数 |
メモリー (MB) |
ｽﾃｯﾌﾟ1 応答(秒) |
ｽﾃｯﾌﾟ2 応答(秒) |
|
|
タイプ１ |
1024×768 |
64K |
16 |
1.5 |
3.8 |
|
|
|
|
|
24 |
1.6 |
3.8 |
|
|
|
|
|
32 |
1.6 |
3.8 |
|
|
タイプ２ |
|
|
16 |
2.1 |
5.2 |
|
|
|
|
|
24 |
2.1 |
5.0 |
|
|
|
|
|
32 |
2.0 |
5.2 |
|
|
タイプ３ |
|
256 |
16 |
7.8 |
12.3 |
|
|
|
800×600 |
64K |
16 |
3.4 |
8.8 |
|
|
|
|
256 |
16 |
6.1 |
10.8 |
［注］
ＯＳはＷin 3.1を使用 、圧縮はＪＰＥＧ１５分の１
Ｈ／ＷはすべてＩＢＭ製を部品交換して使用
タイプ１：Pentium 90MHz S3 864 VRAM2MB
タイプ２：I486DX4 100MHz S3 864 VRAM2MB
タイプ３：I486DX2 66MHz GD5428 VRAM1MB
ステップ１：応答時間を稼ぐため２分の１サイズでデコードした初期画面
ステップ２：拡大・縮小の品質を上げるため実サイズでデコードした画面
ステップ１画面への出力命令直後実行するので画面を確認している間に
終わる。
応答時間：ＰＣプログラム内でそれぞれ３回測定したものを平均した。
テストの結果次の点が判明した。
−ＣＰＵパワーにほぼ比例するので、許す限りＣＰＵを上げたい。
（今回の場合Ｐｅｎｔｉｕｍ１３３ＭＨｚでほぼ要求の性能が出ることが判明）
−メモリーの大きさはあまり影響しなかった。
−表示色数を減らすと（元が６４Ｋ）減色にＣＰＵを使いかえって遅くなる。
［構成一覧］ 構成図参照
（１）ホストコンピューター：ＡＳ／４００
ＳＷ：ＯＳ／４００，ＲＰＧ／�検ぃ達腺味味丕腺圍函殖苅娃�
（２）電話交換機：ＡＣＤ（Ａｕｔｏ Ｃａｌｌ Ｄｉｓｔｒｉｂｕｔｅｒ）付きＰＢＸ
（デフィニティ＊＊，メリディアン＊＊，アペックス＊＊のいずれか）
一般にＰＢＸはイーサネットしか接続できないので要注意。
（３）スイッチサーバー：ＡＳ／４００とＰＢＸの接続
データ量およびバックアップの観点から複数台が望ましい。
（４）イメージサーバー：イメージデータ専用のオンライン中のサーバー
これも台数を要検討
（５）パーソナルコンピューター：クライアントＰＣ（Ｗｉｎ３．１／ＮＴ＊＊）
HW：CPU（Pentium １３３MHz） ４８MB
ＳＷ：Ｄｅｌｐｈｉ２．０／３．０＊＊，カノープス社のイメージ圧縮・解凍ソフト
（カノープス社ソフトは個別契約商品です）
（６）ＬＡＮ監視コンピューター：ＲＳ／６０００
ＬＡＮのトラブル／パフォーマンスネックの分析などに使用。ＰＣでも可。
（７）ＣＡＦＩＳコンピューター：ＲＳ／６０００
クレジットカードの承認のためＣＡＦＩＳとのオンラインで必要。
直接ＡＳ／４００からＣＡＦＩＳにオンラインはできないので、ＲＳ／６０００を
経由する。他社製品だがパッケージがあるので導入は容易。
|
||||
|
||||
５ テストと開発ツール
５−１ テスト
クライアントサーバーのパフォーマンスは最も心配な点であり実際の環境と同じ条件のテストが望ましいが、現実に数百人のオペレーターと千人以上の電話をかける要員を確保するテストを繰り返すことは不可能なので次の段階を踏んだ。
（１）単体での論理テスト（利用者の満足）
（２）１台のクライアントだけの単体テスト
（３）クライアントＰＣとサーバー（ＡＳ／４００）のデータを使ったテスト
（４）クライアントＰＣを５台から１０台に増加
（５）テスト用エントリーシミュレーターを使用し入力速度を９倍にする。
入力の自動実行ツールの使用が不可欠
（６）本番環境でのＰＣ１００台使用テスト
（７）本番環境でのＰＣ４００台使用テスト
（外部から電話をかけないと意味がないのでテスト要員は少なくとも２倍必要と
なる）
５−２ 開発ツール
（１）ＡＳ／４００ＲＰＧ�犬粒�発標準化とデッドロックを避けるため標準のスケルトンとソースコードジェネレーターを作成した。これはお客様の合意を得て画面・帳表を標準化し約２０のパターンを作成できたので多くのプログラムに適用できた。またデータ項目名がネットで約６０００あるため今までのＲＰＧでの項目名桁数の６桁ではデータベース項目名に有意で一元的な命名が不可能なのでＲＰＧ�犬鮖藩僂垢詆�要性があった。
（２）ＰＣでは言語でもあるビジュアル開発ツールのＤｅｌｐｈｉ＊＊を用いた。最初のケースでは２．０／最近のケースでは３．０を利用している。利用した理由はインタープリター方式言語に比べ実行時のパフォーマンスが数倍よく、画面プログラムのレスポンスタイムが１〜２秒短縮されたため。
（３）ケースツールについてはＡＳ／４００で可能なものをいくつか検討した。しかし検討の結果採用は見送った。総代理店のソフトウェア会社もトランザクションのピークと利用ファイルの数・要求レスポンスタイムなどを検討した結果おりてきた。ファイル入出力に関する大幅なロジック改善が無い限りケースの使用は困難と思われる。パフォーマンス要求を充たせない理由はケースがファイル入出力を１つのモジュールで集中制御し整合性を確保するためそこにボトルネックが生ずるためであった。またジェネレーター方式のものはＲＰＧ�犬紡弍�していなかったこととジェネレーターそのものを販売しないためカットオーバー後の保守に不安が残り採用できなかった。
６ 開発の考慮点
６−１ クライアントサーバーシステム
クライアントサーバーシステムはパフォーマンストラブルが発生しやすいのでそうならないように注意が必要である。
（１）ＧＵＩ画面はプロトタイピングを実施し画面デザインと操作の流れを確認しておく。
設計用紙の上では利用部門から意見が出ず、システムテスト段階でクレームがつき大きな手戻りになりがちである。
（２）前章にも述べたがかなり早い時点からパフォーマンスを考慮したテストを実施する。
（３）対顧客からのデータを数百人から千人以上のオペレーターが直接入力するテレマーケティングセンターでは十分にスケジュールされた研修期間をとる必要がある。
（４）テスト施設の準備が最大の問題になる。必ず提案時に考慮し費用を見積もる。
６−２ ＡＳ／４００システム
通販システムは例外的な処理も標準化しフルフィルメントの状態変化を持ち続けるのでＤＢのデータ項目数はかなり多くなる。（あるケースではネット約８０００項目）
（１）プログラムが１０００本を越えるので表計算ソフト／グラフで管理する。
（あるケースでは約３０００本）
（２）サブシステムが多くかつフルフィルメントは受注から配送・回収まで繋がりが必須なのでサブシステム内統合テストとサブシステム間統合テストを明確に実施する。
（３）データ項目間の整合性を統合テストの前に確認しないと後から項目を追加・変更できない。（手戻りの危険性がある）
（４）テスト局面・手法に関してはＡＤＳＧに準拠する。
６−３ ＣＴＩ
ＣＴＩはコンピューターと電話交換機（ＰＢＸ）の緊密な結合なので、当然テストには電話が必要となる。ＣＴＩアプウリケーションに関しては単体テスト段階でＰＢＸとテスト用電話機数台が無いとテストにならない。統合テストやパフォーマンステスト時は数十台規模が最小限必要となる。また一般に該当ＰＢＸと組み合わせたプログラミングに熟知したプログラマーがいることはまだありえないので、かなり早期から機能テストを実施し機能確認をすることが望ましい。以下導入スケジュールの例を上げるので参考にしてほしい。
７ おわりに
テレマーケティングセンターにおけるコンピューターと電話の結合による効果として
（１）１件あたりの受注処理時間の短縮による受注コストの削減
（２）受注時間の短縮はお客様にもサービスの向上となる
（３）お客様と同じ視点でカタログを参照し確認ができる
（４）より詳しい商品説明が容易にできる
（５）配送の状況・納期など正確にお答えできる
（６）オペレーターの状況・成果を把握できる
以上の効果が期待できる。
テレマーケティングは通信販売の単なる受注センターとしての他に
（１）積極的に販売するチャネル
（２）顧客からの質問に答えるサービスセンター
（３）対ビジネス顧客の営業マンのアシスト
（４）チケットなどの予約
（５）通常のオフィスでの電話対応効率向上
など様々な分野に応用がきく。
ＡＳ／４００がクライアントサーバーのサーバー機として驚異的な能力を有している事を付け加えておく。
（１）処理能力
４００台のクライアントから１分以内にトランザクションがあってもＣＰＵの
利用率は１０％前後でおさまる高性能。（ＲＡＭＰ−Ｃ：７５０００Ｔｒ／時）
（２）応答時間（レスポンス）
クライアントでのレスポンスタイムが１秒未満（手動で測定不能）におさまった。
推定値とほとんど変わらないレスポンスタイムで前システムの汎用大型機をはるかに超える高性能であった。
（４）開発生産性
サーバーのソフトウェアはオフコンのスキルで組める。
ＲＰＧあるいはＣＯＢＯＬプログラマーですむので開発要員の言語スキル・能力に依存せずチームを編成できる。
（５）Ｓ／Ｗの信頼
システム／ＤＢソフト／ミドルウェアなどの安定性が高い。
すべてＩＢＭ製品で統一できる（例外はＤｅｌｐｈｉとＰＣのＯＳ）ので組み合わせのトラブルを避けることができた。数年前筆者は２件ＵＮＩＸマシンでＤＢを用いＣ／Ｓシステムを担当したが、比較して今回の安定性はよく開発を妨げることはほとんど無かった。
［各社商標一覧］デフィニティはＡＴＴ社の商標です。
メリディアンはノーザンテレコム社の商標です。
アペックスは日本電気株式会社の商標です。
Ｄｅｌｐｈｉ２．０／３．０はボーランド社の商標です。