NO.04　鹿児島銀行

鹿児島銀行では、ここ数年来、融資支援システムに注力していると聞きました。現在の融資支援システムの概要を、簡単にご説明いただけるでしょうか。

現在の融資支援システムは大きく次の3つ、KeyMan、KeyManS³、モニタリング・システムで構成され（表1）、またこれら3システムの役割分担は、PDCAサイクルに当てはめて説明できます（表2）。

今回、アシストに構築を依頼したのは、3つ目のモニタリング･システムの部分です。モニタリングという役割は一見地味に見えますが、「本当に使えるシステム」を構築するためには必須の部分です。

そうしたシステムを構築するにあたり、最初にやったことは何ですか。

まず、「融資とは何か」、「地方銀行である鹿児島銀行のあるべき姿とは何か」などの原理原則を考え抜きました。こういう原理原則抜きに「現場の声」を聞いたとしても、皆、部門ごとの目標、支店ごとの目標に基づいて話しますから、この機能が欲しい、あの帳票がほしい、こういう機能でないと現場では使えないというように、「安直な現場主義」が生まれ、収集がつきません。そういう「それぞれの目標」ではなく「鹿児島銀行全体としての原理原則」を最初に定める必要があると考えました。

原理原則の策定の次は何に着手したのでしょうか。

その後は、以下の順番でことを進めました。

　1. できあがった原理原則をベースに、鹿児島銀行のあるべき姿を具体的に描写する。
　2. 次に、現在の状況を正確に把握し、描写する。
　3. あるべき姿と現状との乖離を明確にする。
　4. その乖離を埋めるには、何ステップの作業が必要なのかを、具体的に検討する。

こうして、「あるべき姿との乖離」として約2,000項目がリストアップされました。しかしながら、その2,000項目すべてを一度にシステム化するわけにもいきません。大きなブロックに分けて、順々に着手しました。

まずどこから手をつけたのでしょうか。

まず業務の一気通貫システム、KeyManの構築から着手しました。やはり業務プロセスの効率化が、いちばんコンピュータ化に馴染むからです。そうしてKeyManが完成したのが2002年のことです。

KeyManについてもいろいろ語るべき点は多いのですが、本日の取材の趣旨からはやや外れるので、まずはここまでの説明にとどめることといたします。

続いて、KeyManS³についてお伺いしたいと思います。これはどういうシステムでしょうか。

KeyManS³は、KeyManの次に構築したシステムで、一言でいうと「営業支援システム」です。KeyManで業務効率化（コスト削減）を達成したら、次は売上向上を目指す。これがやはり自然な順番というものです。KeyManにより、融資の受付から実行までをPC上で行うようになれば、それに伴いお客様データがデータベースにどんどん蓄積されてきます。これを営業マンに分かりやすい形で提供し、健全な融資を含め、Win-Winの関係を増やしていこうというのがこのシステムの狙いです。

KeyManS³のシステム上の特長はどんな点でしょうか。

｢取引先（仕入/販売先）を融資先に紹介するための機能｣は、地銀システムらしい特長といえるかもしれません。KeyManには、弊社のお客様、すなわち鹿児島県内のさまざまな企業のデータが記録されています。このデータを上手に活用すれば、新たな融資先に、販売先や仕入れ先を、紹介することができます。

それは確かに、借りる側からするとありがたい話ですね。

よくよく考えてみれば、鹿児島銀行というのは、県内の各企業の業務内容や財務状況を総合的に、鳥瞰、把握できる立場にあるわけです。これを活かして、融資先に、新規顧客や仕入れ先の情報も提供すれば、顧客満足も上がります。融資という金融商品に、情報という付加価値をつけて、商品価値を高められます。簡単に表現しますと、「友だちの友だちは皆友だちです。鹿児島銀行が間を取りもつので、皆で取引し合って、鹿児島全体を盛り上げましょう」という考え方です。そういうマッチングこそ、地元経済のために地銀がやるべきことだと考えます。

そうした取り組みがKeyManS³によって可能になったと。

いや、取引先の紹介といった取り組みは、昔からやっていました。ただし以前は、各社の業務状況も財務状況も、担当者の頭の中に入っているだけ、つまり、「担当者はお客様を知っている。しかし銀行は知らない」という状態でした。これがKeyManS³の導入により、「銀行全体がお客様を知っている状態。すべてのお客様全体の状況を上空から鳥瞰できる状態。互いの相関や相性を総合判断して、適切にマッチングできるようになった状態」になりました。

それは平たく言うと「せっかく作ったKeyManやKeyManS³を行員が有効活用しているかどうか、監視するシステム。もしあまり使っていない場合は、もっと有効活用しなさいと注意、叱責するための、その注意のための根拠データを採取するシステム」、要するに「社員監視システム」ということでしょうか。

KeyManもKeyManS³も巨費を投入して作ったシステムですから、もちろん積極活用してほしいと思っています。しかし、モニタリング･システムの本当のねらいは、社員の監視ではなく、鹿児島銀行の融資支援システムにPDCAの進化サイクルをビルトインするという、もっと積極的なものです。これを、さらに詳しく述べると以下のようになります。

　1. KeyManもKeyManS³も未だ完璧ではない。モニタリング･システムを通じて、現場での利用に合って
　　 いない点を見つけ出し、次の改善につなげる。
　2. KeyManもKeyManS³も永遠に進化させなければならない。モニタリング･システムを通じて「その進化
　　 の正しい道筋」を見つける。
　3. 「システム」と「業務」を統合して「ビジネスモデル」に昇華させるためのシステム。そういう「メタ・
　　 システム」であるとも言える。

単純な話、顧客のニーズも外的環境もどんどん変わっていくわけです。特に銀行業界は、最近の金融自由化、規制緩和の動き一つ取ってみても、変化のスピードが、かつての護送船団方式の頃に比べ、格段に早くなっています。そのような時代において、ある時期に定めた「要件定義書」をいつまでも絶対視するのは適切ではありません。極論を言えば、いちばん最初に考え抜いた「2,000項目の業務改善リスト」にしても、当時は正しかったかもしれないが、今も、あるいはこれからも正しいのかといえば保証はありません。システムが拠って立つ前提そのものに対しても、健全な意味で常に疑いを持てるような、そういう状態を「システム化」すること。これがモニタリング･システムの最も重要な意義です。

それはつまり、PLAN（計画）−DO（実行）−CHECK（点検）−ACTION（是正処置）のPDCAサイクルをシステム化するということでしょうか。

そういうことです。各システムをざっくり位置づけると、営業支援システムであるKeyManS³が「PLAN」、業務システムであるKeyManが「DO」、そしてモニタリング･システムは「CHECK」の機能を持つといえます。こうして三位一体のシステムを作り上げ、PDCAサイクルをぐるぐる回して、鹿児島銀行の融資支援システムを永遠に進化させたいと考えたのです。

そのPDCAサイクルの中で、モニタリング･システムは例えばどのように活用されるのでしょうか。

仮に、モニタリング･システムによって、KeyManやKeyManS³のある機能がどうも現場であまり使われていないということが分かったとします。この場合、使われていない原因として以下の3つがありえます。

　1. その機能自体は、使えば効果が上がる『良い機能』であり、システムの仕様や実装にも不備がない。
　　 しかし現場行員が何となく敬遠していて、使われていない。あるいは機能の操作方法が未習熟である
　　 ため使われていない。
　2. その機能自体は、使えば効果が上がる『良い機能』だが、例えばシステムの仕様や速度に問題がある
　　 ため、行員が使おうとしない、いわゆる「こんなシステム、使えないよ」と思われている状態。
　3. そもそもその機能自体が、使っても効果が上がらない『不必要な機能』である。それゆえ使われていない。

では、一つずつ伺います。まず、システムが使われないパターン1、「その機能自体は、使えば効果が上がる『良い機能』であり、システムの仕様や実装にも不備がない。しかし現場行員が何となく敬遠していて、使われていない。あるいは機能の操作方法が未習熟であるため使われていない」という場合はどう対処するのでしょうか。

この場合はシステムに問題はないわけですから、もっと活用するようにと行員に注意を促すなり、操作方法の研修を行ったりすることが解決策になります。

パターン2、「こんなシステム、使えないよ」と思われている場合については。

なぜその機能が「使えないのか」を調査します。もしかすると「表示速度が遅いから使えない」のかも知れません。この場合は、システムをチューニングしたり、ハードウェアを強化したりすることが解決策になります。あるいは「使わせ方の手順、施策」が間違っているから「使えない」と思われているのかもしれません。この場合は、インターフェースも含めて「手順や施策」の改善を図ることが解決策になります。しかし、KeyManのような大規模システムの場合、こうした｢改善｣もなかなか困難なのですが…。

どのように困難なのでしょうか。

これが小規模システムで、利用者は一枚の画面だけを相手にしていれば良いというのなら、「使いにくさの原因究明｣も比較的簡単です。しかしKeｙManは、融資の受付、審査、稟議、実行を一気通貫させたシステムであるという性質上、場合によっては、数十枚の画面の遷移がありえます。こうなると使いにくさの原因の特定は極めて困難であり、やはりモニタリング･システム（PowerPlay）の助けが必要になります。また「使いにくさ」とは、きわめて定性的、感覚的な指標です。要するに、ある人にとっては使いにくい機能も、他の人にとっては使いやすかったりします。こうした個人差、印象などのノイズ要因を排除して、行員全員にとっての「使いやすさの最大公約数、合理的な落としどころ」を見つけるためには、やはりPowerPlayなどのツールを使って、膨大な操作ログ･データを統計的、総合的に把握、分析する必要があるのです。

パターン3、「そもそもその機能自体が、使っても効果が上がらない『不必要な機能』である」という場合は。

そういう結論は、KeyManやKeyManS³を手塩にかけて構築した情報システム部門としては、あまり出てほしくないところですが、やはり独善に陥ってはなりません。このような結論が出た場合は、システムの要件そのもの、2,000項目のチェックリストそのものを見直すことになります。

ここまでやればPDCAサイクルも回りそうですね。

システムというのは、｢要件通りに構築したら、それで終わり｣というものではないと思います。現場で活用され、ひいては顧客に益する物でないと存在価値がありません。こうした前提を考えた場合、モニタリング･システムとは、決して、KeyManやKeyManS³のおまけ、補助ではありません。システム全体のPDCAサイクルを構成する重要な要素です。

続いて、アシストと鹿児島銀行との関わりについてお聞きしたいと思います。アシストとの付き合いが始まったのはどういう経緯からでしょうか。

KeyManの構築に際し、アシストからOracleを買ったのがはじまりですね。

この時は、なぜアシストからOracleを買ったのでしょうか。

アシストは、Oracleに関しては実績もあったし、価格も手ごろだったし、営業のMさんは鹿児島出身で付き合いやすかったし、これだけ条件がそろうと、アシストから買わない理由がないですよね。しかし、この頃のアシストの印象は、「Oracleの販売店。Oracleを売ってくれるお店の一つ」以上でも以下でもありませんでした。

その後、アシストへの評価が変わったのはいつ頃からでしょうか。

Oracle導入後のアフターフォローを通じてですね。単に売りっぱなしというのではなく、定期メンテナンスやトラブル対応以外にも、いろいろ売り込みというか提案がなされる。それを通じて評価が高まりました。

鹿児島銀行としては積極売り込みは歓迎といったところでしょうか。

どんな売り込みでも良いということではありません。何と言いましょうか、「施策としての売り込み」はちょっと困る。「今、当社で一押しの製品です。キャンペーン中です」とか、「このたび当社が開発した新製品です。ぜひご検討を」では困ります。正直言って、いくら売り込まれても、必要ない物は必要ないですからね。しかし、アシストのMさんは、鹿児島銀行のことをよく勉強して、こちらのニーズに合ったものをタイミング良く売り込んでくれました。しかも一つの提案がだめでも、また次を出してくる。なかなか引き出しの多い会社だなと思いました。

今回のモニタリング･システムの構築において、PowerPlayが採用された理由はどのようなものでしょうか。

PowerPlayを採用するしない以前に、そもそも今回のモニタリング･システムにおいて、スクラッチで手作りするか、それともツールを使うかという二者択一をまず決めねばなりませんでした。KeyManとKeyManS³はスクラッチで作ったので、その流れで行けば、モニタリング･システムも手作りするのが自然な進行でした。しかし、モニタリングのあるべき姿を定義してみた結果、やはりツールの方がいいだろうという結論に変わりました。

「モニタリングのあるべき姿の定義」とはどのようなものでしょうか。

ざっと、以下のようなものです。

　1. モニタリング･システムは、KeyManS^3（営業支援システム。PLAN担当）、KeyMan（業務効率化シス
　　 テム。DO担当）を進化させるためのCHECK担当のシステムである。ならばそのシステム自身も自分を
　　 CHECKし、進化していけるのが良い。つまり、柔軟にどんどん変わっていけるのが強い。
　2. スクラッチから作ると、コストもかかる。保守も大変。変更（進化）させるのも一苦労。

こういう前提を考えると、やはりツールを購入して、それを、大きなフレームと位置づけて、システムを組み、それを柔軟に変化、進化させていくことが正しいだろうと思えました。

そうしてツールを使うことが決定したわけですが、数あるツールの中から、今回特にPowerPlayを選択した理由は。

もちろんPowerPlayの機能や仕様がすばらしかったからということも理由の一つですが、アシストに関連する選択理由を挙げると、以下の4点が挙げられます。

　1. 複雑と思われがちなBI^※製品を、わかりやすく説明してくれたこと。
　2. 見積もり内容が明朗だったこと。
　3. アシストが提供するサービス内容と、我々が外部にアウトソースしたいと考える内容が、ほぼ一致して
　　 いたこと。
　4. Oracleのノンストップ運用のノウハウを持っていたこと（これはPowerPlayとは直接関係ありませんが、
　　 重要な点です）。

最初のポイント「複雑と思われがちなBI製品を、わかりやすく説明してくれたこと」というのは具体的には。

あくまで一般論ですが、技術系の会社のプレゼンテーションですと、どうも内容が機能に偏りがちです。「こんな機能があり、あんな機能があり、我が社の製品の優位性はこうです、どうです、すごいでしょう」といったところです。しかし、こちらが知りたいのは、その製品の優位性ではなく、その製品を使うことで、我々の業務がどう改善するかです。アシストについては、技術的な説明（こんなことができます）の他に、効果の説明（この機能で業務がこういう風に良くなります）という話を、地に足のついた形で説明してくれたので、アシストとなら、話し合って一緒にやっていけそうだなという印象を受けました。

※BI：BIとはBusiness Intelligenceの略で、企業内外の事実に基づいた膨大なデータについて体系的に蓄積、分類、分析、加工を行い、それによって、ビジネスにおける具体的なアクションを迅速に取れるようにするといった概念のことです。

次のポイント「見積もりの明朗性」とは。

今回のようなプロジェクトの場合、我々としては、販売店に、製品本体の他に、こちら側の環境に合った形でのインストール、設定、サポートなども求めたいところです。そして、その旨を販売店に伝えると、たいてい「開発導入支援費」という費目が見積もりに一行加えられてくるのですが、あれ、結構困りますね。

どのように困るのでしょうか。

「開発導入支援」とは何のことなのか、つまりどこまでやってくれるのか、それが全然見えません。一方、アシストの見積もりには、こういった支援を何日間、ああいった支援を何日間といった細目が明記してあり、また、できない部分についてはその旨、はっきり通知がありました。そのようにして支援がない部分が分かると、その裏返しとして、自分でやらなければならない範囲も見えるので段取りが立てやすくなります。

その他の会社は、なぜ作業の細目を書いてこないのでしょうか。

あくまでも推測ですが、アシストの場合、PowerPlayでもOracleでも、実装の実績が豊富なので、その経験を元に、こういう作業ならこれぐらい、ああいう作業ならこれぐらいというように仕事量が自然に見積もれるのではないかと思います。そういう実績がない場合は、見積もりには「開発導入支援費」と一行だけ書いて、内容については「何でもやります」と大きく出るしかないということになるのでしょうか。しかし、これまでの経験でいうと「何でもやります」という会社が本当に何でもしてくれることはまずありません。

三番目のポイント「アシストが提供するサービス内容と、鹿児島銀行が外部にアウトソースしたいと考える内容が、ほぼ一致していた」というのは具体的には。

われわれ社内システム部門としては、やはり業務改善のための設計の作業に専念したいわけです。そういう観点でいうと、以下のようなことは外注したいですね。

　1. ソフトのバージョンアップで何が変わるのか、どこにどういう影響が及ぶのかということの調査。
　2. ソフトの不具合や要望などのメーカーへのエスカレーション。
　3.障害時のエラーの切り分けや原因究明。

この分担は図にすると以下のようにもなると思います。

図の下の方のシステム周辺については、我々としては、なるべく結論だけを受け取りたいのです。

「結論だけを受け取りたい」…と言いますと。

例えば、Oracleの新バージョンが出たとして、そこで我々が何を知りたいかというと、これは究極のところ、「新しいバージョンに変えて良くなるのか、ならないのか。今の環境に新しいバージョンを入れて、動くのか、動かないのか」という、そういうYES - NOの結論だけです。

必要最小限の情報でよいと。

しかし、そのYES-NOを出すためには、Oracleについて膨大な量を調べなければならないし、実証試験も必要になります。しかし、我々は、上図のとおり、業務寄りの部分に注力したい。したがってOracleのマニアックな詳細については、それを専門とする、信頼できる外部の協力ベンダーに任せ、我々はただYES-NOの結論だけを受け取りたいということです。

最後のポイント「Oracleのノンストップ運用のノウハウを持っていた」というのは具体的には。

これはKeyManやKeyManS³のシステムが完成するにつれ、クローズアップされてきた部分ですね。最初はKeyManもKeyManS³も、勘定系ではなく融資支援のシステムなので、たまには止まっても何とかなるだろうと思っていたのですが、実際にKeyManで融資の受付、審査、実行など一気通貫で行うと、何というか、ほとんど工場の生産設備のようなもので、これが止まると業務がストップしてしまうことが分かりました。ですから、アシストに、Oracleのノンストップ運用に関する技術とノウハウが蓄積されていたのは大変ありがたいことでした。

これが単に金貸しということであれば、ただお金を貸す、返してもらえなければ、焦げ付くということになります。焦げ付かないためにはどうするのか、財務諸表を見て、黒字なら貸せるが赤字なら貸せないなど、一部のマイナス面にのみ着目する、そういう判断になります。しかし、「鹿児島銀行のあるべき姿」を考えた場合、これでは良い判断とは言えません。

「鹿児島銀行のあるべき姿」とはどういうものでしょうか。

行内でよく言うのは、「我々は、地方銀行の中の地方銀行、“ど地銀”であるべきだ。今までそうだったし、これからもそうあるべきだ」ということです。地銀というのは、地元経済を盛り上げてナンボです。まず鹿児島全体を盛り上げて、それから鹿児島銀行がその恩恵を受けるというのが正しいあり方です。そういう考えで行くと融資の基準も変わってきます。例えばある融資希望企業が、仮にその時、赤字であったとしても、これからの事業計画の内容や、社長の人柄、地域経済への貢献度など定性・定量的に総合判断すると、今回は融資するという判断もありうるわけです。

そこで融資先には取引先や仕入れ先も紹介すると。

そういうことです。そうやって資金と情報とで両面支援し、融資先に伸びてもらい、紹介した取引先、仕入れ先にも伸びてもらい、その上で、鹿児島銀行も利益を上げていくという、そういう鹿児島全体でのWin-Winの盛り上がりを実現したいのですね。そういうあり方は、われわれ行員のマインドにも合いますし。

マインドに合う…と言いますと。

我々も、ここでこうして鹿児島銀行に勤めているというのは、鹿児島が好きで、鹿児島に骨を埋めようという気持ちが、やっぱりあるわけです。そういう我々は、いろいろスマートな施策を展開するよりは、“ど地銀”として着実に地域貢献する方が性に合うのです。

今後のアシストに期待することをお聞かせください。

システム技術上の支援はもちろんのこと、それ以外の点で言うと、外部のベストプラクティスの発掘に期待したいところです。

「ベストプラクティスの発掘」と言いますと。

我々の場合、他社のシステムの研究というのが、どうしても金融業界だけに偏ってしまいます。しかし、アシストの場合、製造業や、小売業など、いろいろな分野で、システム構築に関わっているわけですから、そうした経験の中で、「あ、この業界のこのやり方は、もしや鹿児島銀行に合うのじゃないだろうか」と気づく点があればぜひ教えていただきたい。そうした刺激があれば、当行のシステムもさらに進化できると思います。とにかくアシストさんには、ぜひ当行の鹿児島全体を盛り上げる活動に、システム構築を通じて一緒にご参加いただければと思います。これからもよろしくお願いいたします。

※現在、ご利用いただいている製品、サービス
　　・リレーショナルDB
　　・パフォーマンス監視ツール
　　・統合運用管理ツール
　　・BIツール（設計支援～実装支援）
　　・各種保守サポート

※ 鹿児島銀行のWebサイト
※ 取材日時 2005年12月 【取材協力：（株）カスタマワイズ】