Successwith COOL Suite COOL:Plex ［ 圧倒的な生産性を誇るマルチプラットフォーム対応の パターンベース・アプリケーション開発ツール ］ 富士通サポートアンドサービス株式会社 金融機関の自動機監視システムと、自動機コーナーからのコール受付業務という 異なる２系統の情報ラインを統合するＣＴＩアプリケーションの開発に、 データ中心の設計手法とCOOL:Ｐlexと、市販のアプリケーション部品を適用。 実装工程に高い生産性と品質を確保した結果、上流工程に注力できるようになり、 ユーザ要件に柔軟に対応でき、しかも再利用性の高いパッケージを開発できた。 ネットワークビジネス本部システム統括部 サービスシステム部 関西開発センター長 梶 日出明 氏 富士通サポートアンドサービス （株） （以下 でき、しかも再利用可能なパッケージを、 Fsas、桑原晟代表取締役社長）では、金融 高い生産性と品質を維持しながら開発。 機関向け C TIアプリケーションの開発に、 取り分けPlexを使ったことで、 「実装部分 C A の パ タ ーン ベ ース 開 発 ツ ー ル の信頼性を確保できるようになり、顧客 「COOL:Plex」 （以下Plex）と、販売代理店のタカヤ （株）が ニーズにあった問題分析や論理設計に、より注力できる 開発したアプリケーション部品集 「ATOLAS」 を適用。 「SCS ようになりました」 と、本プロジェクトを指揮したネットワ （Supervisory Control System ）CTI」体系の自動機コ ークビジネス本部システム統括部サービスシステム部関西 ールセンターシステム（以下SCS CTI）として製品化した。 開発センターの梶日出明センター長は話している。 同開発プロジェクトの特徴は、①銀行のオンライン端末 CTIのフロント・アプリケーションに、自動機 （現金自動 監視システムと、P BX（構内電話交換機）を制御するC TI 受払い機）運用監視システムとの連携機能を、Plexの部品 （Computer Telephony Integration） という異種システ の形でアドオンする。このソリューションは、既にユーザ ム間の連携を対象とし、② DOA （データ中心アプローチ） システムの開発案件として商談中にあり、自社のコールセ による分析・設計と、③P l e xおよび A T O L A Sを活用した ンターにも適用済みだ。 コンポーネントベースのプログラム開発に、④自社開発の 追加部品を組み合わせた点にある。 これらによって、各ユーザ企業固有の要件に柔軟に対応 企業情報システムのユーザサポートや情報サービスを本 業とする同社が、金融機関向け CTIソリューションの開発 に乗り出した経緯から辿ろう。 コールセンターの運用ノウハウを活かし CTIパッケージを製品化 こうして2つの情報ラインをCTI上に統合し、双方から共有するソ リューションが求められた。だがこれを実現するのは容易ではなかっ た。SCS CTIはこの難問を解決したのだ。 Fsasは全国約 200拠点に3800名のサポート要員を配備し、故 SCS CTIは電話による問い合わせと、自動機の専用監視装置から 障や操作のヘルプ、コンサルティング、保守サービスを提供。緊急 監視サーバに送られる監視情報、DB内の機器情報をリンクし、自動 時にはオンサイトに急行して問題解決に当たっている。2 0 0 0年4 機の状態とオペレータの顧客対応を統合管理する。通報が入ると同 月には東京港区のサポートセンターをアウトソーシングセンターに 時に、オペレータ画面に自動機の状況やリモート制御情報、サービス 全面リニューアルし、CRC（カスタマ・リレーションセンター） と呼ぶ エンジニア派遣状況などを表示し、的確な状況把握と顧客対応、自動 コールセンターを開設。ハード／ソフト両面のヘルプデスクや保守 機の稼動率アップと迅速な保守を実現。既に「同様の保守サービスを を網羅して、ワンストップ型の顧客サービスを代行し、ASPサービ 事業化したい」とか、製品発売に伴って保守サービスを始めようとし スもスタート。同年6月には、ハウジング設備の提供も開始した。 ているSIやベンダに注目されているという。 また、これらの事業経験から得たノウハウは、各地の開発拠点が 具体的な業務機能としては、顧客対応業務には、①発番通知を利用 製品の形に集約。監視／通報、資産管理、ライセンス管理、指紋認 して店舗を特定し起票する各種受付機能と、②警備会社や保守会社へ 証など、顧客サポート事業に必要な製品を社内外に提供している。 派遣を要請し、到着連絡、完了連絡などを受けて進行状況を管理する 元々富士通のフィールドサポート部門向けの支援部隊として発足し 機能、③受付と連携した情報検索機能を提供。自動機監視業務には、 た関西開発センターも、インシデント・トラッキングシステムや遠隔 ④障害自動機の早期発見、⑤状態取得および指令発行、⑥復旧確認。 診断ソフト等を開発してきた。 管理業務向けには、⑦受付起票の承認処理、⑧紛失・盗難時の事故カ CTI事業に乗り出した背景には、ユーザ毎に提供してきたソリュー ションをサービスパッケージの形で横展開しようという戦略があり、 その一環として、長年にわたる顧客サポートの経験をCTI分野に活か ード登録、⑨受付起票に基づく報告書作成の各機能を提供する。 ①については障害受付、問合せ受付、紛失盗難受付、拾得物受付の 4種の起票画面を標準で用意し、⑨にはカスタマイズで対応する。 すことにした。でき上がったモノを売るという発想ではなく、あく まで顧客ニーズを出発点とし、実績を汎用化するアプローチだ。 「コールセンターやヘルプデスクは一見どこも似たように見えます が、背後の業務こそが本質です。それを効率化するためにCTIをどう 付加するかがテーマでした。固定的なパッケージでは、一社一社異 なる顧客業務にマッチするはずがありません」 （同）とし、個別ニーズ ＤＯＡで設計し、ＣＯＯＬ:ＰlexとＡＴＯＬＡＳで実装する SCS CTIはDOAで設計し、Plexで実装した。上流工程には特に ツールを使っていない。 D O Aの適用は今回が初めてだったが、 「DOAに最適という点でPlexを高く評価しており、今後開発部門の に応じる柔軟性を、CTIパッケージの必須要件と考えた。 共通開発基盤にしたい」 （同）とし、統一作業を始めようとしている。 ATM監視システムとCTIを連携する「SCS CTI」 てきたが、サポート基盤の W i n d o w s化計画に伴い、9 5年頃には 同社では86年頃からホストやUNIXのアプリケーションを開発し Visual BasicとC＋＋を採用。「当時も過去の開発手法をそのまま適 同社のCTIソリューションは、 「コールCTI」 「オフィスCTI」 「SCS CTI」 用できず、色々迷いながらVBベースの開発へ転換を図りましたが、 と、それらのインフラ構築を加えた4分野における企画・設計、導入、 “大規模開発ではどうも巧くいかないな”という思いがありました。 運用の各サービスで構成される。SCS CTIは金融機関の自動機コー そこで今回、DOAに初挑戦することにしました」という経緯がある。 ナー支援システムで、図1のように、自動機監視システムと、各自動機 異種システム間の連携についても、DOAで作られた DBをハブと コーナーの電話とつながったトラブルコール受付用CTIを連動する。 することで解決していく方針。「D O Aできちんと設計しておけば、 金融機関のA T MやC Dといった自動機は、取引データを勘定系セ アプリケーションやロジックを矛盾なく追加できる。それがDOAの ンターとやり取りすると同時に、自動機自体の状態や顧客による操 利点だと思っています」と言う。開発手法を巡る議論では、コンポ 作等の情報を、自行専用または共同利用型の自動機運用監視センタ ーネントベース開発やオブジェクト指向を、DOAの対極に位置付け ーに送信している。だが監視センターとトラブルコール受付が併設さ れているところでも、自動機監視システムと電話系システムは全く別 系統で構築されていたため、次のような問題が生じていた。 ①顧客からトラブルの通報を受け付けた際、マシンの特定や障害内容 の把握に手間取り、サービスエンジニアの派遣が遅れがちだった。 ②経験の浅いオペレータでは対応できないトラブルの場合、他の担当 者にコールを転送するために顧客を待たせてしまう。 ③紙の受付票等を集計／分析するための作業負荷が発生していた。 「○○支店のお客様が“おかしい”と言っていますが、どうなってい ますか？」と、いちいち受付オペレータから監視オペレータに聞きに 行く必要があり、 「オペレータがひとりで応答できるようにしたい」と いう要求があった。一方、監視センターの側、特に監視規模の大きい 金融機関では、 「人手による監視業務を効率化したい」という要求を抱 えていた。また監視電文は自動機のメーカーごと、さらに機種ごとに 異なるため、3社の自動機があれば、3社の監視システムを導入して いた。 「それらを一元管理したい」というニーズもあった。 図1SCS CTIのシステム構成 図2 SCS CTIを利用した業務フローの概要 えず不安を覚えたが、それもタカヤの支援の中で示された。 SCS CTIの開発規模は、機能数にして206。Plexが生成するコ ードは958kステップで、人手でコーディングした部分は1割弱の約 91kだった。開発モデルは「ATOLAS Base」を基盤とし、 Fsas独 自のベースファンクション用ライブラリ、データモデル用ライブラ リ、アプリケーション用ライブラリで構成。「TAPIやOCXをはじめ 多数のActiveXコントロールや C++コードを使用し、電話機能や自 動機への電文受渡しといった異種システム間連携を実現している点 で、他に類を見ないPlexの適用事例となっています」 （CAフィールド サービスグループ 三井伸行マネージャー）と言われる。 Plexに決めた後は、迷わず ATOLAS を使うことにした。 ATOLASはPlexの拡張クラスライブラリで、タカヤのシステム技術 部が97年に製品化した。今回利用した「ATOLAS Base」はアプリ ケーションの基礎となるフレームワーク部品集で、DB保守／更新や 画面インターフェースなど4つのマスタ系保守パネルと、5つのトラ ンザクション系入力用パネル、帳票用部品を含む11種類のフレーム る論者が珍しくない。梶氏はむしろ、「DOAによってしっかりデー ワークを提供。画面遷移や入力チェック、DBの入出力を一括処理す タを設計しているからこそ、アプリケーション・プロセスの側にコン るほか、小数点等の細かな処理も部品の形で揃えている。 ポーネントを適用できるのだ」と、両者を関係付けているわけだ。 開発ツール探しは、「容易にカスタマイズ可能なパッケージをどう 問題は、ATOLASが業務系の伝票処理を想定した部品集であるた め、今回のようなインフラに近い機能の開発には、部品が不足して したら実現できるか」という問題意識が出発点となった。97年7月の いた点だ。足りない部品は、Plexが標準で提供している「OBASE」 ソフトウェア開発環境展で Plex（当時の製品名はObsydian）を知り、 と呼ぶコンポーネントクラスを拡張し、Fsasで自社開発した。最終 他にビジネスルールベースの開発ツール2製品について調べた。 的には、伝票処理画面とは全く異なるイメージに仕上がった。 「ルールベース型のツールは非常に魅力的でしたが、サポートサー 画面数はリソース系の保守画面を含め300枚で、当初想定してい ビス分野では、多様なユーザ環境との密な連携が求められます。CTI たよりもかなり画面遷移が多くなった。アプリケーションの設計次 は端的な例です。その点でPlexの方が有利だと判断しました。さら 第では、1画面に機能を押し込める方法もあるし、画面遷移によって に国内実績も豊富なので、大きく失敗する可能性はないな、と考え 分岐ロジックを表現するような作り方もある。今回は後者を選んだ ました」とPlexの採用理由を述べている。確かにルールベースの開発 が、結果的に成功したという。 ツールは、複雑で変化の激しいビジネスルールやロジックの実装・保 トラブルコール受付業務を含め、一般にコールセンター業務の手順 守にこそ効果を発揮する。より汎用的なPlexの方が、 CTI連携等の やプロセスフローは複雑で、各センター毎に異なる。これを効率化す インフラ機能の開発には適していたと言えるだろう。 るには、 どのプロセスに時間がかかっているかを分析する必要がある。 DOAベースのRAD（Rapid Application Development）手法に たとえばタイムスタンプ等の仕掛けを作って業務フローを分析する よってユーザの個別要件に柔軟に応じる必要があった同社では、「今 には、1画面に押し込めるのではなく、プロセスの流れに沿って画面 では最適解だったと思っています」とPlexに満足している。 遷移する形にしておいた方が有利だ。オペレーション業務のノウハウ を活かし、フローの最適化やスクリプト設計を考慮して画面遷移を設 プロジェクト概要と、部品ベースの設計ノウハウ 99年4月、正式に開発プロジェクトを発足し、要件定義をスタート。 完了したのは2000年の2月末だった。ツールの導入検討に先行し、 計すれば、改善しやすい柔軟なシステムになるということだ。 足りない部品を追加開発し、TAPIアプリケーションを開発 以前構築した複数の類似システムをボトムアップ分析し、ER図を書 SCS CTIの開発で連携対象となったのは、富士通の自動機統合監 くなどの準備を進めていた。これが今回の要件定義やデータモデリ 視システム「C C M SⅢs p」だった。C C M SⅢs pのサーバとS C S ング作業に役立った。 Plexの導入を決めて最初に行ったのは、タカヤの半日体験コース CTIのDBサーバは、Oracle DBを介して、自動機1台1台の監視情 報を共有する。メーカー毎にまちまちの自動機からの電文内容を、 の受講だった。Fsasでは当初、Plexを使った部品ベースの開発につ ゲートウェイで統一した上で、DB上に蓄積・統合し、SCS CTIか いて、技術的に納得できない部分があって悩んでいた。そこで複数 ら即座に参照できるようにした。 の代理店の説明を聞いた結果、タカヤを協力会社に選ぶことにした。 一方CTI側の連携は、富士通の PBX「ES200i・force」シリーズ プロジェクトメンバーの構成は、初期のデータモデリングに2名、 を対象とした。 CTIの実現方法には、コンピュータ側のTAPIボード 要件定義に延べ5名、ビジネスモデルとデザインモデルの定義にそれ を経由してPBXと接続するTAPIのアプリケーションを開発する方法 ぞれ延べ5名、メイクに8名で、テストには7名が当たった。 と、PBXが提供する独自APIを直接利用する方法があるが、梶氏ら ATOLASまわりの開発には、タカヤの支援を要請。ER図からアプ はその両方を経験した。 リケーションの全体像を読み取り、どの部分を部品に実装すべきか など、全体設計のノウハウを学んだ。 TAPIは93年5月にマイクロソフトとインテルが提案したテレフォ ニーAPIの一種。アプリケーションはTAPIを介してtapi.dllを呼び出 設計フェーズでは、下流にPlexを使うという前提を意識する必要 し、これがドライバ・インタフェースの S P I（Service Providor はなかった。当初、Plexを使った時の開発プロセスのイメージが見 Interface）を介して、 PBXベンダが提供するサービスプロバイダ Success COOL Suite with COOL:Plex DLLと連携する。WindowsNT上で、PBXのコール制御と、トーン SCS CTIの自動機情報画面と情報検索画面 信号の検知および生成を可能とし、各種音声処理アプリケーション の開発を効率化する。 PBX固有のAPIで直接つなげば、高度な連携や複雑な機能を実現 できる半面、特定の PBXに特化し、パッケージとしての互換性が犠 牲になる。一方TAPI経由では、PBXの機能をフルに活かせない。顧 客指向のソリューションを実現するには、Web等を統合する最近の コールセンター環境を想定し、様々なユーザアプリケーションやネ ットワーク環境、音声系機器との融合が不可欠になる。そのため Fsasでは、TAPI制御OCXを利用したPlex部品を開発している。 でき上がったアプリケーションソースは大きく分けて、ATOLAS をそのまま利用した部分、 ATOLASを継承して自社開発した追加部 品、直接OBASEから継承して開発した部品から成る。 ATOLASはマルチ OS対応なので、ダブルクリック時の動作など が 、 必 ず し も W i n d o w s の 作 法 に 則 っ て い な い 。 F s a s では WindowsNTをターゲットとしているため、そうした点を補う部品 や頻繁に使う機能部品を、自社の独自クラスとしてATOLASを継承 して作った。OBASEから新規に起こした部分は全体の1割以下。ど 「実装部分の信頼性を確保できるようになり、今後はより顧客ニーズ にあった問題分析や論理設計に、一層注力できるようになりました」 うしても必要な数個の部品のみだった。たとえば複数の選択肢を組 と言う。ATOLASの仕様を基準におくことで、ユーザの表現に惑わ み合わせるウィンドウ画面や、TAPIとのインタフェース部分等だ。 されることなく実装要件を整理できたのだ。 今後はそれらを含め、開発基盤として再利用していく方針だ。た 「動く部品である」という点については、たとえば他のメンバーが だし独自の部品体系を作るのではなく、基本はあくまでATOLASを 作ったソースと結合しないと画面が遷移しないといったことがなく、 継承しながら、自社ニーズに合った部品を追加していくという。 他のソースの完成を待たずに動作を確認できる。部分的なテストを 積み重ねながら開発を進められるので、手戻りも大幅に低減。開発 プロジェクトの一部の進捗遅れが、チーム全体の足を引っ張ることが 「部品化の最大の効果は上流工程に現れる」 ない。これは大規模なチーム開発になるほど効果を見込めるという。 一般にソフトウェア部品化の価値は「品質と生産性の向上にある」 実は今回のシステムは、もう少し早く完成する予定だった。接続 と言われる。確かに生産性は非常に高くなった。だが梶氏は「最大の 相手であるCCMSⅢspのインタフェースが大きく変更されたため、 効果、本質的効果は、上流の設計品質と保守性に現れました。コー 開発途中で見直しが入ったのだ。「もし以前のように機能中心で作っ ドの生成能力を比較しても、あまり意味はありません」とコメント。 ていたら泥沼に陥っていたはず」だが、 D O Aで設計していたため、 アプリケーションの部品化の価値は「設計に割り切りができる点と、 どこをどう修正すべきかがすぐにわかった。また部品の適用により、 動く部品であるという点にある」と言い切る。 影響範囲を容易に特定でき、手戻りも少なく、品質には影響しない 今回はPlexだけでなく、DOAの考え方に切り換えるのが初めてだ ったため、戸惑う場面も多かった。特に要件定義については、どこ ため、被害を最小限に封じることができた。「部品化の最大のメリッ トはそこにあったとも言えます」と振り返っている。 までの機能をパッケージの標準機能として実装すべきか、これまで Fsasでは今後、PlexとATOLASを他の開発案件にも適用する計 も悩んできた。「ユーザ主導で要件を決めるのと、自分たちのノウハ 画で、現在CRCの受付システムを中心に、問題点や機能を洗い直し ウを集約して提供すること、両者の間には幅があります。その間に ている。また監視情報をホストに一括集中している金融機関も少な 悩みがあり、いつも苦労しています」 （同）と言う。 くないため、ホスト連携型CTIアプリケーションの開発案件も進行 にもかかわらず以前の開発現場では、上流工程よりも実装に注力 せざるを得なかった。それが今回PlexとATOLASを使ったことで、 しているが、「今回設計した DB構造に、大きく手を加える必要はな いはず」だと言う。 すべての製品名および会社名は、各社の商標、または登録商標です。 製品の仕様・性能は予告なく変更する場合がありますので、ご了承下さい。 © 2001 Computer Associates International, Inc., and / or one of its subsidiaries. All Rights Reserved. お問い合わせ 〒163-0439 東京都新宿区西新宿2-1-1 新宿三井ビル お問い合わせ窓口：CAジャパン・ダイレクト（TEL：0120-702-600） W E B サイト：www.caj.co.jp ※記載事項は変更になる場合がございます。 2001年2月現在
© Copyright 2024 ExpyDoc
