架空案件論文案

　４面待ちのピンフっぽいものを作ったつもりなのだが、やはり捏造案件とばれてしまうのだろうか。わりとありがちなものを組み合わせたのだが。

１．１　システムの概要
　今回、論述の対象とするのは、インターネットで通信販売を行っているＡ社のコールセンターのオペレーター業務支援システムである。Ａ社はパソコン関連のサプライ製品をネット経由で販売しており、店舗コスト、流通コスト、人件費を省いた低価格攻勢で近年業績を伸ばしている会社である。当初は、サポートはしません、その代わり価格で還元、という方針で、コアなユーザーを中心に支持を伸ばしてきたが、近年、顧客層の広がりや、取り扱い製品のメーカーからの依頼もあり、製品への問い合わせやクレームを受け付ける必要が生じてきた。このため、電話でのサポートを行うコールセンターを立ち上げることが決定され、支援システムを構築する必要ができた。

１．２　システムの特徴
　Ａ社は特徴である「低価格」を崩したくないということで、システムのコストを極力抑えてくれという要望があり、コストがきわめてタイトな要求になった。
　また、平行でコールセンターを立ち上げるためのプロジェクトが走りはじめた。これは場所、通信回線、人員とその教育というものを主な要素としており、コールセンターサポートシステムとも、機器の配置、回線容量、設置台数といったインフラ周りのものはもちろん、人員教育を見据えたユーザーインターフェースについても、連携をとって進めてゆく必要があった。なぜなら、コールセンターを立ち上げて顧客への対応を始める以上、その場でオペレーターがシステムの操作にまごつくことがあっては許されないからである。その結果「人員の研修に割ける時間はせいぜい１ヶ月」という厳しいものとなった。
　私は、本システムの開発を請け負ったＰ社所属のシステムアーキテクトとして、システムの開発の設計部分を担当した。

２．１　開発案件の分析（課題）
　システムに要求される機能を明らかにするために、私は会社のキーマンにヒアリングを行った。すると、オペレーターは顧客からかかってくる電話に対して次のようなことを回答する必要があることが判明した。①商品の紹介依頼、②商品へのクレーム、③これから商品を注文するとどの程度で到着するかの期間、④商品の配送状況、である。これらについて、お客様から照会があれば極力迅速に対応しなければならない。これらに対応できる社内情報が既存のものであるかどうかについて、ヒアリングを繰り返したところ、①については、現在Ｗｅｂで提供している商品検索機能があり、③については在庫管理システムに即発送可能かと、注文中商品の納期についての情報があることが分かった。これと発送に使う宅急便会社の見込み輸送期間の情報を組み合わせることができれば対応できることが判明した。④については発送時の発送済み情報があるだけであった。②についてはこれから構築の必要がある。
　これらの情報は、各システムに分散して格納されており、現状のシステムで対応するとなると、各システムの照会端末を必要システム数だけ並べて独立に照会するしかないという状況であった。これを行うと、システム数だけ端末が必要となるため、オフィススペースおよび回線・機器の面できわめてコスト高になる。システム開発コストは削減できる可能性があるが、その場合でも、Webの商品検索機能をのぞいて、セキュリティのためにアクセス制限を付ける必要があり、開発コストが下がるという保証はない。さらに既存システムに直接手を加えるため、既存ユーザーも反発した。いや、既存システムを保守するシステム部門は自システムをコールセンターに拡大することにさえ反対した。元々コストをかけずに作ってきたシステムであるため、設計に余裕がない。つまりキャパシティや誤操作時の対処その他に大幅な見直しが入ることを嫌ったわけである。また、新たに構築するコールセンターサポートシステムを仲介に、他のシステムの変更が自システムに影響することを懸念したこともある。

２．２　課題の解決
　既存システムを保守する担当部門は、直接端末をオペレーターに使用させることを嫌ったため、私は次のようなルールの元にデータを参照させてもらうことを提案した。①データベースがリレーショナルデータベースであるため、ビューを作成してもらい、そのビューのみを参照する。②各独立システム間での連携した照会を行わない。③照会時間は、コールセンターの営業時間である９時から17時に限定する。これについては、経営トップの声がけもあり了解を得ることができた。
　この制約のうち③は運用ルールとしてまとめれば問題ない。同時並行で走るコールセンター立ち上げプロジェクトに照会して問題のない旨を事前に確認済みである。①については、こちらがビューの定義を提供すれば使えるように構築してもらえることで既存システム担当と合意できた。問題は②である。
　これについては、オペレーターに提供する画面上で、各システムの情報を一元的に見せることができればよい、という割り切りの元に、サポートシステムをWebベースの３層クライアントサーバー式にすることによって解決した。具体的にはサポートシステムの画面をHTMLの基本機能であるフレーム分割を利用して各情報提供元システムから得た情報を「同一画面ではあるが、分割して商品内容／在庫管理／発送管理システムからの情報を見せる」ようにしたわけである。照会条件はメインのフレーム内から行うが、実際に見せる情報は別々のシステムから持ってきた、別のフレームに表示するわけである。
　実際に構築するシステムは、他システムの情報をHTMLに加工する部分と新たに構築するサポート内容の記録／照会のデータベース構築で済んだため、１ヶ月という短期間でユーザーに提案できるレベルまで構築し、最終調整はオペレーター研修と平行しながら、プラス１ヶ月で本番リリースにこぎ着けることができた。
　またコストの面からは、ニアショア開発、つまり国内ではあるが、人件費の比較的安い地方での開発を利用した。また、コールセンターも人件費／オフィス費用が安い地方に構築することとなり、担当間で事前に情報共有をはかっていたため、ニアショア開発先とコールセンターの構築先を近距離とし、今後のメンテナンスの場合もスムーズに行くよう工夫した。

３．１　評価
　期間が非常にタイトであったが、計画通りの本番カットオーバーを迎えることができ、開発費用についてもニアショア開発を利用して、社内の同規模のシステムに比べて１割程度削減できたため、本プロジェクトは成功であったといえる。
　ユーザーインターフェースは、フレームを利用したため、正直あまり格好の良いものとはいえないが、ユーザーが内部の人間に限られるものであり、さほどの問題ではないと考えている。また、フレーム分割で別々のシステムからデータを呼んでいるため、レスポンスに差ができるが、「先に到着したデータを元に顧客と話を始める」ことができるということで、顧客を待たせることが少ないというメリットが生まれた。これはオペレータが機転を利かせてくれたたまものであり、感謝している。

３．２　今後の課題
　新たにコールセンターに照会された内容を蓄積するデータベースを構築した。これを顧客情報とリンクさせてマーケティング拡大に役立てたいというアイディアがＡ社から寄せられている。正直突貫工事で構築したため、現在そのためのインターフェースをシステムとして持っていないが、正式に案件として依頼が来た場合には、既存部分についてもリファクタリングを行い、マーケティングについても効果的なシステムを構築してゆきたいと考えている。

コンピュータネタ、目次へ
ホームへ