滋賀銀行様

DBMからCRMへ

滋賀銀行におけるITの目的は、単なる事務の効率化にとどまらない。経営の意思決定支援や顧客サービスを強化する不可欠のサポート・ツールとすべく、1996年2月「マルチメディア委員会」を設置。そして1999年4月には独自のイントラネット「∞（夢現）ネット」を稼動させた。さらに同年12月、勘定系・情報系・収益管理などさまざまなデータを一元管理するDBM（Data Base Marketing）システムが完成。情報インフラとしてDWH（Data Ware House）を採用し、プロモーションから営業戦略、店舗業務まで、さまざまなマーケティング活動を支援する環境を整えた。

当時を振り返って、岩﨑博システム部 部長は語る。

岩﨑部長DBM内に完成度の高いデータベースが構築できたので、さらにフロント戦略に活用させるべく、CRM （Customer Relationship Management）の開発に着手しました。当時これほどの先進的な情報系システムは、地銀ではほとんど例がなく、まさに手探りのスタートとなりました。

開発の指揮をとった中島浩之 システム部 部次長 兼システム企画グループ 課長は語る。

中島部次長最初にデータを一元管理するために構築したDBMのデータベースは、あくまで勘定系のデータが中心でした。しかし今後の銀行業務のなかで、資産運用相談をはじめとする営業活動の中でのお客様との交渉記録や契約情報や、ご融資の審査結果など、勘定系以外の別システムで管理する業務データとなると確信していました。

多くの銀行のシステムはこれまで勘定系を中心に構築・運用され、情報関連の業務システムは派生的な存在だった。しかし金融ビックバン以降、金融の自由化が進むにつれて、投信、保険など銀行が提供するサービス・商品が拡大している。それにともない、多くのサブシステムが加えられていったが、情報の扱いはサブシステムごとにデータベースを持つのが一般的だった。対して今回のシステムは、中核にデータベースを置き、各サブシステムが情報を取りに来る点に特徴がある。最終的な見え方に違いはないが、内部的なシステムの迅速性、安全性は格段に上がる。さらに情報活用の面でも、今後の激化する競争を勝ち抜くためのセールスやコンサルティングの強化、さらには利用者の利便性向上という意味でも、可能性が広がる。

滋賀銀行におけるCRMチャネルミックス戦略

（クリックで拡大画像をご覧いただけます。）

オープン系への挑戦

システム構成としては、勘定系ホストと並列に置かれたDWHを情報系の中核とし、オープンシステムによるマルチベンダー環境で各種端末を統合。インタフェースはイントラネット環境下でのWebブラウザが採用され、顧客情報のハブとして機能させることをめざした。

システム開発の指揮を執った今井和喜 システム開発グループ 調査役はそう振り返る。

以前の滋賀銀行ではホストから各端末まで、すべてのシステム、ネットワークはF社製品で占められていた。しかし2001年から始まった営業店システムの更改に際し、F社からH社に切り替えたという経緯がある。理由は当時の髙田紘一頭取（現会長）の “複眼的、動態的”という理念だった。この方針に基づき、勘定系ベンダー＝端末ベンダーという既成概念を捨てて、公平な立場で一から検討・評価した結果、端末側ベンダーはH社、システムはLinux、インタフェースはWeb、というオープン環境が選ばれ、CRM支援システムに関しては、すでにDBMで実績を積み上げていたCACが担当することになった。こうした布陣で、以降、同行のシステムは急速にオープン環境へと移行していく。

安全を第一とする銀行のシステム部では、なかなか新しいテクノロジーに挑戦しないのが通例だ。
その点、不安はなかったのだろうか。髙木長久 システム開発グループ 調査役にうかがった。

髙木調査役自分たちにとってははじめてでも、オープンソースとして話題になっていたLinuxには注目していました。閉じたシステムだと手の出しようがありませんが、オープンソースなら、自分たちもある程度関わることができます。そもそもオープン環境が進んでいけば、マルチベンダーにならざるを得ません。もちろん安全面は重視しましたが、CACから提案いただいたのはRed Hat Enterprise Linuxだったので、その面でも心配はありませんでした。むしろ挑戦という気概で取り組み、それが次の情報系の基盤にもなっていったのです。

プロジェクトチーム発足

開発に先立ち、まずは各部門の代表メンバーによるプロジェクトチームが編成された。彼ら彼女たちからニーズを集め、同時に各々の現場、とくに店頭に頻繁に足を運び、テラーの女性たちの意見・要望を聞きながら、まずは画面イメージを作っていった。

当時を振り返って、今井和喜 システム開発グループ 調査役は語る。

今井調査役彼女たちの意見をヒアリングして試作画面を作り、テラーが集まる研修などで再度ディスカッションを実施しました。こうしたステップを何度も踏んだことで、真に使い勝手のいいシステムが徐々に形になっていったのです。

それらの要望が固まった段階で、CACは、基本設計のフェーズを進め、さらに現実的に実装できる機能を集約。目玉のポータル機能をはじめ、勘定系画面にビルドインされた小窓画面への顧客属性シンボル表示や投信業務フロー機能など、ほぼ当初の目的どおりの機能を盛り込んでいった。

ものづくりをきわめる

一般的に、要件定義の段階でのクライアントとベンダーの役割分担は二つのタイプに分けられる、といわれる。ひとつはシステム仕様をクライアントが決定し、システム会社はその実現に力を注ぐタイプ。もうひとつが、クライアントとシステム会社がともに考え、検証し、要件を固めていくタイプだ。
クライアントが要件を決め、ベンダーは設計と実装に専念する。このように役割を割り切ると、実装面で迷走してしまうということがままある。逆にクライアント側が実装やレスポンスなどをイメージして要件定義や概要設計実施し、同時にベンダーも詳細設計以前の全体像を固める段階から関わると、開発作業や移行もスムーズに進むことが多い。

今回のプロジェクトはまさに後者のタイプ、両者の協業によって進められていった。

もちろん、こうした協業スタイルの場合、責任を明確にしないと、お互いに甘えてしまうという危険がある。しかし今回のプロジェクトでは、双方で緊張感を持ちつつ、必要な情報を共有することができた。その最大の理由は、CACによる本システムに対する徹底した業務理解の姿勢だったという。

滋賀銀行からは今回のCRMに関する基本的な考え方から、こまごまとした業務フロー、さらには具体的な実装イメージまで、参考になる情報や知識・ノウハウがCACに惜しみなく提供されていったのである。
今井調査役も自分たちのこだわりを意識している。

そもそも滋賀銀行のシステム部には、現場やものづくりを大事にするという文化があるという。考えるだけ、企画だけ、ではなく、ソースまで見てしまおうというこだわりの文化だ。

そんな雰囲気を外から眺めて、CACの木立は、こんな感想を抱いている。

CAC 木立滋賀銀行のシステム部の方はみな、とてもリテラシーが高いのです。皆さん設計限界などもよく理解されているので、おかげさまで実現可能な機能を実装していくための手順決めや作業なども、非常にスムーズに進めることができました。

予想されたトラブル

銀行としてはじめてのオープンシステム構築には、当然トラブルもあった。最大の要因は、やはりマルチベンダー環境に起因する。

一例をあげよう。プロジェクト終盤、開発環境から本番に移行した際に、原因不明でパフォーマンスが著しく低下したことがあった。SQLチューニングなど試行錯誤を繰り返し、最終的にJava Appletの記述の変更によって解決。リリース間近で一時は騒然となったが、短期間の対処で事なきを得た。
そのときの苦労を、石田部次長はこう振り返る。

CACは日ごろからさまざまなベンダーの技術や製品に触れている。勢い経験も豊富で、いざというときの勘も働く。まさに独立系ゆえの特色といえよう。多くのベンダーの問合先からたらい回しにされた問題が、最後にCACに寄せられることも多い。こうしてオープン化時代の貴重なノウハウが、CACに蓄積されていったのである。

端末側での創意工夫

銀行の店頭業務は、まさにお客さまとの相対。仕事の大半は事務作業だが、しかしそれだけに追われていては、肝心の顧客応対が疎かになってしまう。事務仕事をいかに効率的にさばき、いかに顧客に満足してもらうか、さらには収益につながる店頭セールスを展開できるか、それが今回のCRM支援システムのもうひとつの要となった。

開発にあたっては、まずは端末の画面に何を表示させるか、そのアイデアが求められた。

銀行内勘定系ホストにある顧客データはもちろん、外部の投資信託履歴データ等、多くの情報がいったんはDWHに集約され る。それらのデータを一括し、現場のテラー端末にどう表示させるか。女性テラーはもちろん、かつての業務経験者からも意見を集め、どのデータをどう加工したら、目的通り表示できるか、アイデアと技術面でさまざまな検討が加えられた。

たとえばポートフォリオのシミュレーションを表示したい場合、どのようなルールベース・エンジンを使えばいいのか。分配金は％で表示したい、しかし最後の詰めはお客さまとテラーが話し合い、手入力で検討できる余地を残したい。その結果は円グラフで示したい、といったようなことだ。

こうした要請に応えて、CACは勘定系ホストから顧客情報を拾い出し、情報系サーバーと連携させることで、端末側でのさまざまな表示機能をJavaのServlet、Appletにより実装させていった。

より進化した金融サービスが実現

CRM支援システム本稼動後の、現場での評価はどうか。

導入時、行内ユーザーの矢面に立った中島部次長が振り返る。

実際の使い勝手を、当時テラーとして店頭に立っていたシステム開発グループ 芦田久美子様にうかがった。

芦田 様お客様を目の前にした時、すぐに手元の端末にシンボルでお客様の属性・関連情報が表示されるようになったので、確認などの作業が大幅に簡略化されました。加えてクリックしていくだけで、各預り資産の取引履歴や、投信であれば前日ベースの評価損など、深い情報がどんどん表示されていきます。それをもとに応対すると、お客様との会話も膨らみますし、『そこまでわかってもらっているんだ』と驚かれて、次のセールスにつながることがよくあります。

とくに若いテラーにとって、今やこのシステムがなければ仕事にならないほどだという。

（クリックで拡大画像をご覧いただけます。）

銀行の窓口には、ハイカウンターとローカウンターがある。相談業務に対応するのがローカウンターだが、つねにテラーが待機しているわけではない。限られた人数でもあるため、通常は事務をさばき、お客様がご相談に来店された際に、きめ細かいセールスやコンサルティングを実施する。このため、その都度に異なる担当者、異なる端末になることも多い。そんなときでも、いつも共通の顧客情報をCRM端末で蓄積・提供することができる。より効率的で進化した金融サービス、その業務プロセスが、今回のCRM支援システムで実現したのである。

CRMがフロントのインフラになる日

現在でも、改善や機能追加は継続的に行われている。直近の改善項目、機能追加としては、業務ナビゲーション、インターネットやコールセンターから利用できる商談予約、来店予約、窓口混雑状況把握などが検討されているという。

機能追加のなかで、とくに重要視されているのが、金商法対応、オペリスク対策、個人情報保護関連などの機能だ。しかも、

と今後の抱負を語る。

さらに預り資産のポートフォリオ閲覧など、顧客が外部のインターネットから利用できる機能へと、利用者の要望は広がりつつある。

制度改革の裏には、いつも「利用者のため」という大原則がある。インターネットの活用という意味も含めて、今回のCRM支援システムは、営業支援基盤、ひいてはフロントエンドにおける全行的なプラットフォームとして、その重要性を増していくことは間違いないだろう。