koufuuの日記: UFJ 37
日記 by
koufuu
表のストーリーでもUFJが話題だが、それほど驚かなかった。まぁ、予想の範囲だし。(四大都銀の勘定系で採用というなら驚いたが。)どっちかというと、
このニュースの方が驚いたな。
(2003.7.29 23:26追記)
von_yosukeyan氏が居れば、なんか書いてくれそうだが、と思いつつ、表のストーリーがらみで、ちょっとリンク先だけ追加しておく。 新生銀行の事例。ただし、このパッケージ(FLEXCUBE)って、通帳が作れなかったような気がするんだが。邦銀で、海外勘定パッケージが採用されないのは、今まで顧客に提供していた通帳をなくすわけには行かないのが理由と聞いた記憶がある。(海外では通帳は無いのが普通らしい。)その他、日本向けカスタマイズの工数がかさむため、パッケージ採用のメリットが薄いそうだ。その点、新生銀行は、過去の縛りが無かったので採用できたという話だったかと。
国内でのオープン系の銀行勘定系だと、 NEC BankingWeb 21ぐらいしか事例がなかったような?ちなみに、NECは オープンミッションクリティカルとか呼んでいるが、合併前の旧住友銀行勘定系システム(メインフレームベース)を構築する際のノウハウをベースにしたらしい。メインフレームで作るときに、既にオープン系への移行を視野に入れて設計していたらしい。で、当時の住友銀行は、NECに対してオープン系にして外販してもいいからと言って、システム構築費を叩いたという噂を聞いたことが…。さすが、けち友銀行と思った…。
(2003.7.29 23:26追記)
von_yosukeyan氏が居れば、なんか書いてくれそうだが、と思いつつ、表のストーリーがらみで、ちょっとリンク先だけ追加しておく。 新生銀行の事例。ただし、このパッケージ(FLEXCUBE)って、通帳が作れなかったような気がするんだが。邦銀で、海外勘定パッケージが採用されないのは、今まで顧客に提供していた通帳をなくすわけには行かないのが理由と聞いた記憶がある。(海外では通帳は無いのが普通らしい。)その他、日本向けカスタマイズの工数がかさむため、パッケージ採用のメリットが薄いそうだ。その点、新生銀行は、過去の縛りが無かったので採用できたという話だったかと。
国内でのオープン系の銀行勘定系だと、 NEC BankingWeb 21ぐらいしか事例がなかったような?ちなみに、NECは オープンミッションクリティカルとか呼んでいるが、合併前の旧住友銀行勘定系システム(メインフレームベース)を構築する際のノウハウをベースにしたらしい。メインフレームで作るときに、既にオープン系への移行を視野に入れて設計していたらしい。で、当時の住友銀行は、NECに対してオープン系にして外販してもいいからと言って、システム構築費を叩いたという噂を聞いたことが…。さすが、けち友銀行と思った…。
作れません。 (スコア:1)
von_yosukeyan氏の日記を見て新生銀行のPowerFlex口座作ったクチですが、通帳はありません。ちなみにはんこもオプションというか、はんこまたはサインのいずれかを選択という形式でした。
米国などでは通帳が無いため、個人用の会計ソフト(QuickenとかMS Money)が早くから普及しているのだ、という話を聞いたことがあります。源泉徴収などというシステムの無いアチラだと、金の出入りを記録しとかないと、税金収めるとき面倒ですからね。
Re:作れません。 (スコア:1)
written by こうふう
von_yosukeyan氏ではありませんが (スコア:1)
Re:von_yosukeyan氏ではありませんが (スコア:1)
誰の日記だろう?
written by こうふう
十分沈んでるし、そろそろいいかな? (スコア:1)
というわけで、糞ッタレLSATが終わってほっとしてるyosukeyanです。といっても、本番は今月末だしそれより7教科対策しろっ と怒られそうなので暫定復活なのですが(偽善
まぁご存知だと思うんですが、海外の銀行では通帳がない代わりにステートメントが発行されます。日本と同じように、若干の手数料を徴収されるんですが、毎月発行されるのではなくて、一定量の小切手決済が発生すると送付しなければならない(半分義務?)みたいなんで、投信口座の報告書みたいなものなのかもしれないです
といいますか、もともと日本長期信用銀行には厳密な意味での通帳はなかったと思います。確かお預かり帳とか言ってたかもしれないですが(まぁ興銀しか知らないのでアレですが)、システムの入れ換えを前後してなくなったような気がします。
さて、銀行の勘定系・情報系へのOSSの採用ですが、個人的には「第三次オンラインシステムの解体」が本格化してきたかなぁ、という感想を抱きました。もちろん、メインフレームベースのシステムを置き換えるという話じゃなくて、EAIを使ったハブ&スポークなシステムへの移行、という意味でです
誰かの日記で読んだのですが(偽善)、日経コンピューターとかいうオヤジ雑誌の6月2日号に、大手銀行4行(まぁ3行だけど)のシステムに関する特集記事の受け売りなんですが、基幹系統合が終了した3行が、第三次オンラインシステムの解体に乗り出したこと、しかしそれは必ずしも第四次オンラインシステムのようにシステムを一気に入れ替えるようなことではないこと、などが趣旨のようです
ボク自身が興味深く感じたのは、この後者のほうです。厳密に言えば住友銀行は(koufuuさんも書かれている通り)1994年に稼動した第四次統合オンラインシステムで、第三次オンラインシステムを入れ替えており、SMBC発足時のシステム統合でさらにシステムを再編しているので、4行の中では最新のシステムですが、基本的にその他3行は、1980年代半ばに構築された第三次オンラインシステムのままです。
3オンは、興味深いことにまず都銀各行で構築されたシステムを、80年代後半から地方銀行に対して各メーカーが水平展開していったという歴史的な経緯があります。もちろん、現在のような勘定系パッケージがあったわけではなく、メーカーや銀行システム子会社がシステムの一部を再利用する形で展開していった訳です。
その3オンが、地方銀行を中心として共同化やパッケージへの移行へ向かっているのとは対称的に、都銀ではゆっくりとした解体と移行という現象が見られる、というのはとても面白いことだと思います。というのは、たとえば銀行は経費率削減に血眼なんですが、考えてみれば銀行システムの開発は、システム子会社が行っているとは言え、連結対象ですし基本的には銀行の「内製」な訳です。昔は、銀行勘定系システムよりも大きなメインフレームベースの巨大オンラインシステムはそうなかったからかもしれないですが、それにしても非効率な役所でさえ外注しているし、証券会社のシステム部門になるとスピンオフされてしまう時代なんですから、大手銀行のシステム子会社というのがそれほど生産性の高い部門なのか、というのは非常に疑問な訳です
ですから、地方銀行やUFJ銀行が、システム部門をアウトソーシングに切り替えたり、UHS(UFJ日立システムズ:旧三和系のUFJの勘定系運用を行ってる日立の会社)とJRIが、共同で振替システムの開発(Javaベースで書かれて、UFJはIA-64系Linuxシステムで稼動を目指している)を行っているというのは、それほど違和感はなかったりします。もちろん、パッケージ採用の話にしても、です
しかし、現実的にはパッケージはあんまりうまくいってません。FlexCubeは一時期売り込みしまくってたように思ってましたが、結局新生以外はどこも採用していませんし、NECのBW21にしても八千代銀行のシステム稼動はえらいこと遅れて稼動しました。F通のPROBANKに至っては、採用予定銀行が半分くらい逃げてしまってて、システム稼動も9ヶ月ほど遅れて人海戦術で開発している、なんて恐ろしい話があるんですが
パッケージがなぜうまくいかないのか、というのはいろいろな説があるんですが、koufuuさんが以前仰っていたように既存のシステムに出来るだけ近づけようとカスタマイズ要求をしまくる、ってのがあると思いますが、問題はそれ以前に標準的な銀行業務を定義しきれないという問題もあると思います。まぁF通はそういうのはすごいへたくそな会社なんで(ヒュア)、そもそもあの会社にパッケージを作れというのが無理があったのかもしれないですが、BW21も八千代のシステム構築でとりあえず標準を作って、それを参考に他行に水平展開していくという形ではないと展開できなかったと思います。
でまぁ、海外製のパッケージがなぜ使えない
Re:十分沈んでるし、そろそろいいかな? (スコア:1)
とりあえず、海外のパッケージがつかえないというのは、銀行勘定系システムに求めるものが、日本と海外で違っているんじゃないかと思うんですが。ふと思ったのが、日本では、銀行は無謬であるのが当たり前であり、それをサポートするためにシステム化したり、人手による場合には繰り返しチェックするわけですが、海外ではそんなことをするぐらいならコスト削減に回しているんじゃないかと思うわけで。勘定系に求めるシステム化の度合いも違うんじゃないかなぁと思うわけで。や、これは、憶測です。
あと、そもそもの文化の違いがあるという気もします。銀行以外に目を向けて、ERPパッケージを見てみると、海外系パッケージが多いわけですが、どちらかといえば、失敗事例が多かったり、パッケージを使っている割りにはカスタマイズ(SAPはモディファイというんだっけな)が必要になってコストがかさむという…。結局のところ、文化が違うんじゃないかと。
って、そこに理由を求めるのは安易に過ぎる気もするわけですが。
written by こうふう
Re:十分沈んでるし、そろそろいいかな? (スコア:1)
ERPと銀行パッケージは、導入時の問題点という意味では、似ていて個人的にも気になっている部分です。実際、金融行向けのSAPがあったような気がするんですが、富士総研が提供している導入支援サービス以外あんま聞いたことないですねぇ
ERPは、出来合いのパッケージソフトで企業の基幹系システムを置き換えるというよりも、パッケージの導入によってセクションごとに部分最適化された業務を、組織全体で全体最適化しなおす、という点も大きいと思うんですが、現場の意見を取り入れているとカスタマイズ要求が多くて、結局従来よりも全体的なコストの高いシステムになったりする・・・なんて事例は、それこそ耳にタコができるほど転がってますねぇ
先日の日経の「経済教室」に、ちょっと興味深い小論が掲載されていました。ちょっと手元にないので、どこの先生が書かれたのかは失念してしまいましたが、日本企業の生産性の低下は、ミドルに対して裁量権を与えすぎたために、企業全体のガバナンスが低下し、部分最適化された官僚組織が出来上がってしまったと結論付けていました。
目から鱗だったのは、例として上げられていた内製製品の例でした。競争力のある製品・サービスを提供するために、外部から容易に調達できるデバイスではなく、コアデバイスを内製化することで、最終製品の競争力をつけようとするとします(近い例としては、松下のDVD向けの複合チップなんかがいいんではないかと)。コアデバイスの開発チームに対して大幅な裁量権を与え、高い性能を持ったコアデバイスが完成したとしましょう。しかし、単に開発チームに対して裁量権を与えただけでは、開発チームは最終製品の品質を向上させるのではなく、最良のコアデバイスを完成させることに力を注ぎすぎてしまう・・・文中では「夢を語り始める」と書いていました・・・そして製品が売れなくなると、今度はコアデバイスの開発チームの独立採算制が経営陣から求められ、チームは事業部に格上げされ、市場のニーズにマッチしない製品を老朽化した非効率な生産設備で生産し続けてしまう・・・というところでしょうか
この説自体に納得は出来ないのですが、なぜ多くの日本企業が総花的な組織なのか、という疑問に一応の一つの答えを与えられたような気がしました。もちろん、日本企業だけが総花的な組織というわけではなくて、実際にかつてのGEとか、現在のボーイング社やノースロップグラマンのような軍事宇宙航空複合体や、金融機関が典型的でしょう。しかし、日本の場合には日経平均採用銘柄のほとんどの企業が、コア事業とは全く別分野の事業部を持っているという場合が多く、電機企業に至っては弱電から強電まで、あらゆるモノを生産していて、そのほとんどで競争力を失っています。
少し前まで、これは日本的な特質なのではないか、と思っていました。たとえば、小泉政権の産業政策などでは、知的財産立国、IT立国、観光立国・・・と本来ならばいくつかにしぼるべきの先行投資に対して優先順位のつけられていない多数の分野に対して、ばら撒き的に投資を行っていて、個々の分野ではやはり競争力につながっていない。しかし、先の例で考えてみると別日本的というわけではなく、単にガバナンスが欠如しているからではないかと、ちょっと考え直すようになりました
話を少し戻して、銀行システムに対する投資にしても、一旦パッケージ導入を経営意思決定しても、実際の導入現場では金融ソリューションに対して全く知識がないメーカー系SEと、システムに対して全く知識がない銀行から派遣された管理職の板ばさみになっている、というのはどこでもある光景だと思います。しかし、それでもこれまでに第一次から第三次までのオンラインシステムが構築できていたのは、金融市場やオンラインシステム自体が急拡大していった成長時代だったから、何とかなっていたのであって、決してエンジニアの技術力が昔に比べて低いわけでも、昔のほうが経営者の企業統治能力が高かったからではないのではないかと思うのです
これは、前の段落とは矛盾しているように思われるかもしれませんが、技術力や企業統治が明確になくてもうまくやれていた時代というのが確実にあったと思うのです。たとえば、現在の中国などが良い例でしょう。ましてや、現在の金融業界は護送船団方式からの決別と、金融自由化の波にさらされているわけですからなおさらです。与えられたコストの範囲内でモノを作ることが出来る、という考えではなく、総量的なコストをどれだけ削減できるか。または、全体に共通するフレームワークを構築する、といった場合には、従来のやり方では通用しない、というところが
Re:十分沈んでるし、そろそろいいかな? (スコア:1)
JNBのトラブルのニュースを聞いたときの感想としては、(1)は、従来型の銀行でも、ネット専業銀行でも大差ないと思いますが、(2)が大きく異なるんじゃないかと思いました。たとえば、預金の払い出し一つ取ってみても、システム障害時にも一般の銀行では、窓口にて一定額までは払い出すようになっているはずです。(預金の払出しは、コンティンジェンシープランの中でもトッププライオリティのはずです。)対して、システムが全てのネット専業銀行の場合には、システム障害が発生したときにどうするのが適切なのか?という話です。
部分最適と全体最適の話については、前から思っていることがあります。一度、日記に書こうと思っていたのですが、重要なことは、「全体最適が外部要因によって変化する」ということではないかと思っています。つまり、今、「部分最適」といって効率化の障害のように言われていることも、元を正せば、「昔の外部要因に対する」全体最適をブレークダウンした結果ではないかと思っているのです。そして、ブレークダウンしたものが、硬直化してしまい、外部要因の変化に対応できなくなっているのが真の問題ではないかと考えています。話が逸れたついでに書いてしまいますが、最近はやりのBSCも、使い方を間違うと「今の外部要因に対する」全体最適を硬直化させる危険性をはらんでいるのではないかと思っています。結局のところ、PDCAサイクルが重要ということなんでしょうが。
日経の小論は、読み落としてしまったようですが、「企業全体のガバナンスが低下した」というよりも、後の方でvon_yosukeyanさんが書かれているように、「企業のガバナンスが確立途上にある」という方が近いのではないかと思います。とりあえず、ここでの論点は、企業の事業ドメインに絞ってみます。
von_yosukeyanさんにこんなことを書くのは、釈迦に説法だとは思いつつ、書かないとつながらないので書きますが、企業は、もともと成立過程では、1つの事業ドメインに集中しているはずです。そして、ある時点で、別の事業ドメインに手を出します。これ自体は、非難の対象とはならないと考えています。まぁ、別の事業ドメインに手を出すときに、 アンゾフのマトリックス [globis.co.jp]ぐらいは頭の片隅においておけばいいというぐらいでしょうか。そもそも、複数の事業ドメインを持つことは、リスク分散の観点から、ゴーイングコンサーンに資すると考えられます。
問題は、自社のコアコンピンタンスを考えずに、手当たり次第に事業多角化を進めてきたことにあるのだろうと思います。かつてのGEがまさにその状態ではなかったかと。小論での、「ガバナンスの低下」の主張は、トップがコアコンピタンスを認識していない、或いは、そもそもその企業にはコアコンピタンスが無い、ということではないかと思います。実際のところ、護送船団方式では、コアコンピタンスが無い可能性が高いといわざるを得ないかと。
ただし、この事業の多角化の論点で、日本と欧米を比べる際に、注意すべきは、(ベンチャー)起業数ではないかと思います。つまり、欧米では、リスクの高い分野はベンチャーが手をつけ、市場を開拓していく傾向があったのに対し、日本は資本力のある大企業がリスクを取って参入していたのではないかと。逆に、それが日本でベンチャーが育たなかった要因にもなっているのではないかと思いますが。というより、ベンチャー企業を各社が事業部・事業本部として抱えてしまっているという方が近いのかもしれません。結果的に、本来「倒産」しているはずのベンチャー事業部が、他事業部の利益を食いつぶしつつ、生き延びているのかも知れません。
それで、話を戻しますが、個人的には、「ガバナンス」と「ミドルに対する裁量権」は相反するものではないと考えています。もともと、「ミドルに対する裁量権」が必要となったのは、組織構造を文鎮型に変えるためであり、組織構造をそのように変えることは、トップの意思を下に速やかに伝えるために有効なはずです。仮に、「ミドルに対する裁量権」と「ガバナンス」が相反するとすれば、ミドルに対してトップが何を求めているか伝わっていない、言い古された言葉を使えば、ビジョンが明確でない、ということではないかと思うわけです。つまり、「ガバナンス」がしっかりしているのであれば「ミドルに対する裁量権」は適切に働き、そうでないならそうならないということではないかと思うわけです。この辺は、感覚で書
written by こうふう
Re:十分沈んでるし、そろそろいいかな? (スコア:1)
1)RDBの復旧に必要なトランザクションログの取り寄せ手段がマニュアル化されていなかった(本番系のあるSISの大和センターと待機系のある明石センターの間でログを探しまわってしまった)
2)本番系の復旧を最優先したために、待機系への切り替えや、SMBCでの一時払い戻し業務の開始などの判断が遅れた
というところでして、Continuity Planそのものに関しては、金融庁や監査法人の監査対象になっているので、ないってことはないと思ってたんですが・・・。
それはそれとして、事業ドメインに関してです
そもそも、わが国において最初に事業部制をとったのは松下電器だと記憶しています。製造業のように、異なる最終製品や様々な中間生産物を生産する部門が存在し、それぞれに高い独立採算制が求められる場合には、事業部制は意義があるのだと思います。しかしながら、銀行業のようにコア業務は商業銀行機能であるという場合に、どれだけ周辺業務に独立性を与える必要があるのか疑問に思えるわけです。
これは、わが国の株式会社制度が執行と監査を分離しない制度だったことが関係しているのかもしれません。しかし、取締役が50人以上いる会社で、そもそも意思決定が可能なのでしょうか。そして、CEOや社長を置いていても会長や、会長を退いた代表相談役、相談役、理事、関連会社に天下ったOBと、法的には権限がないにもかかわらず意思決定に対して強い影響力を行使することができる人たちが存在していたりします。
そういった人たちは、往々にして関連事業会社を独立王国として、本体内の事業部や部といったミドル層を経由した影響力を行使する場合が多いと思うのです。経済的合理性からいえばとっくに廃止されているはずの事業部や関連会社が、赤字を垂れ流しながら存在し続けるというのは、ミドルに過大な裁量権が存在する状態で、意思決定そのものがボトムアップに行われるのが原因ではないかと思ったりするんですが
Re:十分沈んでるし、そろそろいいかな? (スコア:1)
1)あたりだと、地銀ぐらいだとベンダ任せの可能性がありますが、それとてベンダを適切に管理することが求められているはずですし、2)なんかは、殆どの銀行では阪神淡路大震災後やY2Kのときに検討し直しているはずです。JNBの場合、開業の時期からしてY2Kでの対策というのが重要ではなかったと思われますので、他行に比べて検討が不十分だったのかもしれません。実際、都銀クラスでも、去年や今年ぐらいにやっと、Y2K当時のコンティンジェンシープランを見直していたはずです。その大きなトリガは9・11なわけですが。やっぱ何かイベントがないと大きな見直しは入れにくいのかもしれません。
で、JNBのCPに話を戻しますが、作り方が甘かったのか、監査が甘かったのか。とはいえ、2)についてなどは、窓口を持たないネット専業銀行特有の対応が求められる部分なのかも知れず、監査する側もチェックが不十分だったかもしれないかと。
次、事業ドメインですが。確かに、指摘の通り、製造業と銀行業では、意味合いが違うと思います。
で、関連事業会社や事業部の赤字垂れ流しが存在しつづけているのは、OBの存在もあると思いますが、結局、責任の所在が不明確だからじゃないかと思っています。結局、赤字部門を整理するとなると誰の責任なのかという話になってしまうわけですが、いずれ黒字化するはずなので存続させるというのを、何となくコンセンサスを取っておけば赤字になっても、誰も責任を取らないということじゃないかなぁと。合議制の悪弊だと思いますが。もちろん、責任の所在が不明確になる理由の一つとしてOBの影響力というのも含まれると思います。そんなわけで、赤字になっても、関連事業会社や事業部のトップの首が代わって、組織としては残りつづけるということかもしれません。出向しているOBは、それで困らないということなんでしょうが。
個人的には、昔はもちろん、組織のフラット化が言われている現在でも、ミドルの裁量権なんてものは殆ど無くて、上を口説けるミドルと口説けないミドルがいるというだけだと思っていますが。
written by こうふう
Re:von_yosukeyan氏ではありませんが (スコア:1)
http://srad.jp/comments.pl?sid=110764&cid=368388 [srad.jp]
RACは確か日光誠心誠意証券が、税金計算に使ってたような気がするんですが気のせいですかね? 確かテラバイトクラスのストレージにつながってたような気がするんですが
Re:von_yosukeyan氏ではありませんが (スコア:1)
written by こうふう
何でここに書くのかは不明ですが (スコア:1)
まぁ同じ大規模オンラインシステムという意味で共通点があるということにして、yh氏の過去の日記を見て思ったんですけど、行政システムに対するOSSの適用ってのは、ちょっと金融情報システムとは違った意味で論点があるわけで
というのは、最近ボクが尊敬する宇賀先生が法学教室なんかでお書きになってるんですけど、行政手続をオンライン化すると従来の行政法的な受理とかの概念をどう解決するのか、と書かれているんです
#宇賀先生は、行政手続法や行政情報公開法といった行政法の最新理論にお詳しい偉い人
で、まぁ行政手続というのは基本的には紙媒体で行われることを想定して、行政手続法という標準法が制定されているわけなんですが、オンライン手続に関してはいわゆる電子政府三法などの規定では足りない部分があるわけです。三法では、行政手続きに関して規定した各法律で、書面で行うこと、とされている部分を、オンラインでも行うことができる、と一括して書き換えてるだけで、じゃあ「形式的要件が満たされているのに、フォームの記述が足りないから受付できないと表示されたらどうするんだ?」とか、「データの転送を持って受理とするのか、それともサーバのDBに記録された時点で受理とするのか」といったおなじみの議論がまだ不明確であるというところですな
それから、e-Japan計画が示した行政手続の電子化に関する数値目標なんですが、実際んところぜんぜん達成できるわけないです。というのは、行政手続自体が非常に多く、これらを電子化すると膨大な費用がかかってしまうわけです
その手続きが本当に必要なのか、という点をもう一度洗いなおすという作業がなければ、とんでもなく巨大なシステムが誕生してしまいます。たとえば、今日のストーリーにも掲載されている国税の電算システムは、非効率と非難される郵貯オンラインシステムの数倍のコード量と10年近い工期をかけてるわけなんですが、当初の電子媒体による納税なんかにしても、やっと一部の税務署で導入されているだけ、という状況だったりします
先日、中央省庁のペーパーレス化の達成状況が90%以上になったなんてニュースもありましたが、あれにしても結局は従来の紙ベースで行われてた事務処理を、Dominoだとかメールに添付した文書ファイルで行っているっつー訳です。
で、本題に戻しますと、行政システムにOSSを採用することはいいことだ、というのは別にして、逆にOSSを採用してどんなメリットがあるのか、というのがあまり検討されていないような気がするのです
適当に挙げてみると、ハードウェアやソフトウェアのイニシャルコストが削減できること、コードの再利用性が高いこと、不当競争行為に繋がりにくいこと、仕様が公開されているOSSを利用することによって中小ベンダーの直接参入が可能となりコスト低下をもたらすこと、なんかです
で、これらの中で行政システム独自の論点としては、コードの再利用性と仕様公開による競争なんですけど、上でぐだぐだと書いてみたことを考えるとちょっと違って来るんじゃないでしょうか
第一に、仕様公開の件ですがこれについては一部を除いてまったく行われていません。単に行政システムをOSSで構築したとしても、独自にコーディングした部分を公開する義理なんかありませんから、参入障壁の撤廃になるわけじゃないと思うんです
第二に、コードの再利用性ですが、上で書いてみたとおり、行政事務自体が予算の削減や規制緩和、行政法体系の改正などでシステム自体が作り変えられる可能性があるのに、再利用性はそれほど重視されなくなるかもしれないというところです。実際のところ、行政としても手っ取り早く安くできるシステムというのが必要とされていて、以後のシステムに関してはあんまり考えてなかったりしますから。
もうひとついえることは、財政法上の障壁です。基本的に行政の予算編成は単年度予算が基本で、たとえば年度をまたがるリースが長期契約でコストを下げるということができなかったりします。
どうも、個人的には行政システムに対するOSSの採用というのは、経済産業省が旗振り役になっている割には、内閣府や肝心の総務省の反応がよろしくないところが気になるところで、単なる産業政策上のモンじゃないかなぁと思ったりするんですが
行政手続(Re:何でここに書くのかは不明ですが) (スコア:1)
ちなみに、おいらの知識は、「 電子行政の法務知識 [amazon.co.jp]」(NTTデータ)で読んだ内容(宇賀先生のお名前と立場も、その中で紹介されています)と、某官庁関係の仕事をしているときに、室長や実務担当者レベルから聞いた話(って、本来は金融分野を担当している漏れが何でそんな仕事をやってたのかは謎)ぐらいしかないわけですが。
行政手続の電子化というか、システム化について言えば、とりあえず、通達として出されているものとして、「 申請・届出等手続のオンライン化に関わる汎用受付等システムの基本的な仕様 [soumu.go.jp](平成13年8月6日行政情報化推進各省庁連絡会議幹事会了承)」、 「 汎用受付等システムの構築・運用に関する共通事項 [soumu.go.jp](平成15年6月 6日改定共通システム専門部会了承)」あたりが、関係深いと思うわけですが。
法律用語として正しいのかどうか分からないのですが、受理をもって申請・届出の効果が生じると位置付けた場合、宇賀先生の立場は、行政手続法の意義として、到達した時点で受理したことになるということになるのではないかと思います。ここで、某官庁で聞いた実務レベルの話として、例えば、窓口で申請・届出を受け付ける場合、窓口で形式チェックして、受理しないというケースがあるわけですが、電子申請で、サーバやDBに到達した事を持って受理とすると、人間のチェックを受けずに受理してしまうわけであり、不備があった場合に、問題になるということがあるようです。そのため、受理は、サーバやDBに到達した時点ではなく、担当者がチェックした時点としたいという要望があります。また、実務上は、郵送で受け付けたものが形式不備の場合には、送り返したり、電話・FAX等で問い合わせたりしているようです。それが、法律上どうなのかは聞かなかったのですが、これは行政手続法上は、まだ到達していないことになっているんでしょうか?
加えて、問題なのが、全て電子化できない場合、例えば、別途郵送で紙の添付資料が送られてくる手続を電子化する場合、です。(「そんなもん、電子化する意味無いやん、やめとけよ」と言いたくなりますが、まぁ、役人はやるといったことはやらないとダメなようでして…)この場合、恐らく、全ての書類が揃った時点で受理することになると思いますが、そうなると、サーバに到達したとか、DBに格納されたとかというのとはまた違う議論になってしまう気もします。
ま、この辺は、ITに詳しい法律の専門家の方にちゃんと整理して欲しいところです。私の仕事は法解釈をすることではなく、専門家による法解釈に沿ったシステムを提案するだけですので…。
written by こうふう
Re:行政手続(Re:何でここに書くのかは不明ですが) (スコア:1)
1点目は、「その手続きが本当に必要なのか」という話。これは、まったくもって、同感です。 2002年2月28日 [srad.jp]にも書いたんですが、BPR的な視点が無いように思えます。手続が必要かどうか、必要な場合にもその処理フローが適切なのか、その辺を省庁横断的に考えている部署が無いように思えます。また、個別の手続についても、「今、紙でやっているやり方が変わると困る」という反応が目立つように思えます。似たような話として、「手続を変えるためには、法改正が必要なるので、避けたい」とか。
2点目。到達の話ですが、私とvon_yosukeyanさんが書いているリスクが違う気がしたので、ちょっと書いてみます。
まず、von_yosukeyanさんの懸念は、「形式要件が満たされているものを受け付けない」のは問題であるという不受理に関するものだと思うのですが、私の懸念は、「形式要件を満たしていないものを受け付けてしまう」という問題です。これは、受付システムでの機械的なチェックにより、形式要件を過不足無くチェックできるかどうかという懸念の裏表だと思います。で、実際問題、全ての行政手続で過不足無くシステム化するのは、難しいようにも思えます。今の私の個人的意見としては、機械的チェックは緩くしておき、人間のチェックをした上で、受理とした方がいいように思っていますが。ただ、法律的にどうかといわれると困ってしまうんですけど。
written by こうふう
Re:行政手続(Re:何でここに書くのかは不明ですが) (スコア:1)
書面の形式的不備に関しては、通常は要件を満たしていない申請となり却下(これ自体は申請に対応する行政処分に相当します)となってしまいます。といっても、たとえばしやくそ(菱沼さん風<なぞ)で婚姻届を出す場合には、届けに必要なところをしやくその人が親切に「ここはこうしてください」と教えてくれますよね? これは一種の行政指導(窓口指導)になります。行政指導は、法的な拘束力がないためにこれに従う必要は必ずしもありません。
しかし、これに対して受理は行政側の義務です。それだけでなく、受理した申請に対して行政はその申請に対して処分を決定するまでの標準的な期間内に処分を行うか、補正を指導する必要があります。(行政手続法第6条、同7条)
で、もう少し話を戻してみると、たとえば通関手続きのように管轄が異なる複数の官庁に、様々な書類を提出する必要がある場合など、全体の手続きをワンストップに行えない場合なんかもあります。
これがたとえば、上海とか釜山、香港のように最近コンテナの取扱量が急激に増えている外国の港では、たいてい手続きがネット上で一括してできるのに対して、日本では「荷物が届いているのに通関手続きが終わらない」なんてこともあるわけで、日本の大きな港から直接荷物を積み出すよりも、日本海側の港から韓国にコンテナを送ってから、韓国を基点にアメリカや香港にコンテナを送るなんてことも最近は多いそうで
#CuPES(通関手続き申請システム)という省庁の申請業務を横断的に行うシステムが今年の3月から稼動しています。400項目ほどの申請が閉鎖型ネットで申請できるそうです
Re:行政手続(Re:何でここに書くのかは不明ですが) (スコア:1)
でも、Webベースじゃなく、端末ソフトがいるんですね…。あと、NACCS以外なんですか。 ここ [bolero.net]とかを見ると、NACCSにも課題があるというように見えるんですが。とはいえ、仕事では企業間・銀行間の文書の電子化の話が中心だったので、NACCSはよく知らんのですが。
そういや、インボイス情報をCSVで受け取れるようですが、TEDIやBoleroも対応したんでしょうかねぇ?つか、Boleroやっている人からすれば、今更CSVかよ!って感じかもしれませんが。
貿易電子化の残る大物は、保険関係とか原産地証明あたりなんですかね?って、私が知らないだけで話は進んでいたりするのかもしれませんが。
written by こうふう
Re:行政手続(Re:何でここに書くのかは不明ですが) (スコア:1)
あと航路関係の申請なんかはどうなんでしょうね? つうか、昨日たまたま上海中央電視台のニュースを見ていたんですけど、電子化に先行してペーパーベースだけどワンストップな窓口で申請が可能になったとか何とか言ってましたし(実際にどういう手続きが必要なのか知らないのは確かなんですが)
Re:行政手続(Re:何でここに書くのかは不明ですが) (スコア:1)
なんで、Boleroの方だけ知っているかといえば、まぁ、某都銀関係ということでお察しください。(って、おいらは既に関係ないんですが。)
ま、保険は大手保険会社を抑えればいいだけだと思われる(あ、今見る [bolero.net]とI/PとI/Cの両方が出来てるなぁ。前は片方しかなかったはずなんだが、やっぱり、両方必要だったんだな。)ので、そんなに問題ない気もしていたんですが、原産地証明がやっかいそうでしたね。発行するのが各地の商工会議所というのが…。
written by こうふう
Re:行政手続(Re:何でここに書くのかは不明ですが) (スコア:1)
written by こうふう
行政システムとOSS(Re:何でここに書くのかは不明 (スコア:1)
個人的に、行政システムに求められるOSS的(と、とりあえず呼びますが)な要件としては、ソースが公開されていることが重要ではないかと。「独自にコーディングした部分は公開する義理はない」かもしれませんが、契約というか入札条件として「パッケージを使う場合にはOSSを使う」「新規開発部分はソースコードの著作権を発注者に譲渡」としておけば、公開するかどうかは発注者(行政サイド)の問題になるんじゃないかと思うわけです。
で、重要なのは、ソース公開により、バックドアが無いことを第三者が確認したり、開発と運用保守を分けて考えられるようになるかもしれないんじゃないかと思うわけです。1円入札問題の根源は、開発と運用保守が切り離せないところにあると思っていますから。
で、コードの再利用については、以前は、再利用による横展開も重要だと思っていたんですが、共同利用 [nikkeibp.co.jp]でもいいかなぁと思い出しています。もちろん、信金共同システムのように収拾がつかなくなるリスクを孕んでいるわけですが。
次に、財政法上の障壁ですが、「 情報システムに係る政府調達の見直し [rieti.go.jp](平成13年12月)」の中で、「 情報システムに係る政府調達制度の見直しについて [soumu.go.jp]」を引用して紹介しているように、国庫債務負担行為を使うという手もあるかと思います。もっとも、リースに使えるかどうかは分かりませんが…。ただ、情報システムであれば、ベンダとの間で、ホスティング・ハウジングという形へのアウトソーシングという形態を選択し、複数年契約するという手もあるかと思いますが。ただ、実際にやっているところがあるかどうかは知りません…。官僚の方たちは、この文書を知っているようなのですが、前例がないことをやろうとしませんので…。
written by こうふう
Re:行政システムとOSS(Re:何でここに書くのかは不 (スコア:1)
実は、今年の概算要求でいくつかの中央省庁が複数年契約のシステム構築で枠を要求していて、たとえば総務省だと共通電子申請システム、特許庁だと現行の特許DBシステムの刷新などの案件でこれを使おうとしてるみたいです
ついでに、上の文書 [soumu.go.jp]で気になったのですが、EVMを工程管理に導入するという動きがあるというのが、昨年くらいから計算省やIPAを中心にあるみたいなんですけど、ベンダー側の受け入れ態勢が整っていないので、導入がのびのびになってたりします。海外の行政調達ではEVMが事実上標準になっているので、IBMあたりは体制はあるのかもしれないですが、他はどうなんでしょうね?
共同利用システムに関しては、「運用と保守体制の分離」の観点から言えばちょっと悩ましい関係にあるように思えます。実際には、共同システムの場合にはすでに稼動しているシステムをカスタマイズして使うか、新たに開発するかの二つの選択肢しかないわけですが、後者を選択した場合、当初からフルスペックのシステムを作ろうとすると、BW21やProbankみたいに破綻してしまう可能性が高いのではないかと思うのです
で、挙げられている京都の成功例のように、実際には最小限のシステムを構築しておいて、運用しながら機能を追加していくという「運用と保守が密接に結びついた」状態でなければ成功しなかったのではないかと。どうしても共同システムというのは(金融システムにしても、従来の市町村の事務協同組合にしても)参加者が増えると小さく作って大きくするよりも、最初からでっかく作ることに意識が向かいがちになってしまいますから
実は、共同システムのほかにも、北海道が行政情報システムのフレームワークを作ろうとしているという話があって、先行研究に予算要求をしていたはずなんですが、どこで見たのかちょっと忘れてしまったので(汗
Re:行政システムとOSS(Re:何でここに書くのかは不 (スコア:1)
EVMは、どうなんでしょうかね?実際のところ、ベンダの状況は分かりません。一応、伏字モード(?)で行きますが、NやFと仕事をしたりした限りでは、少なくとも通常のプロジェクトではEVMで管理していないようです。あー、Nとは最近仕事してないから分かりませんが。そういや、半年前の時点では、アクセ○チュアもやってなさそうでしたね。さすがにアクセン○ュアぐらいだと、やろうと思えば出来るんじゃないかと思いますが。(でも、ア○センチュア社内標準の管理方法でやっていると言って持ってきていた管理指標は件数ベースのものばかりで、EVMっぽいものは無かったような気もするんですけどね。)
データ、I○M、Hとは仕事をしたことが無いので分かりません。
で、うちの会社の状況ですが、EVMはやっていないはずです。どこかで試行プロジェクトをやっているような気もしないではないですが…。実際のところ、うちの管理会計ってプロジェクト単位じゃなくて、更に細かい工程単位(SLCPのタスクレベル)で仕掛りを計算しているんですが、EVMをやるなら、工程単位を更に成果物単位にまで細分化して管理しないとダメだと思うので、うちの会社では当面は無理かも…。つか、うちの会社の当面の施策にEVMへの対応ってあったっけな?CMMのレベルを上げるとかいうのは見た気がするんだが…。ひょっとしたら、CMMレベルアップの話の中にEVMも入ってたかも知れんが…。
で、北海道の話は、 これ [nikkeibp.co.jp]でしょうか?正直、電子政府/電子自治体関係って、似たような話が多くてよく分からんのですが。で、よく見るとやっている自治体は割と偏っているし。実は、地域間デジタルデバイドが現在進行形で拡大中なんじゃないかと思ったり。
written by こうふう
ここだけの話 (スコア:1)
で、なんか、Nと某BC(FG?)でなんかやるらしいが…。
もし、この噂が本当なら、そう遠くない将来に表に出てくる話だろう。だって、BWが八千代専用だとすると、他の地銀に何を売るのかが問題になっているわけだしね。
written by こうふう
Re:ここだけの話 (スコア:1)
そういえば昨年会長に退いたNの元社長って、Fと同じくSE系の人なんですけど、実は金融系システム(住友の三オンとか)の人だったらしいですね
実は、BWの計画が始まった初期辺り(99年頃?)の記憶が曖昧でよく憶えてないんですけど、確かキックカスタマーが愛媛銀行だか四国銀行だったかで、BWが完成するまでに愛媛銀の勘定系を人員+建物込みで買収して、「西日本地域のアウトソーシング事業の本拠地にする」とかぶってたような気がしてたんですけど、記憶違いかなっと
で、八千代銀行なんでスガー
ここって、現在は第二地銀なんですが元はと言えば信用金庫が地方銀行に転換(?)した銀行らしいです。転換当時、地方銀行協会が八千代の加入を拒否したので、第二地銀協会が渋々八千代の加入を認めたとか。ついでに言うと、政府の公的資金注入行でもあります(こっちの方は、破綻した国民銀行の営業を継承している関係かもしれないけど)
もちろん、城南信金、京都中信よりも規模が小さい銀行な訳なんですが、確か同規模くらいだった東京相和銀行が、通帳廃止だとかATM/勘定系24時間化とかシステム面では先進的だったのを思い出して何となく既視感を感じたり
Re:ここだけの話 (スコア:1)
#いや、おいらは部外者なので詳細を知らないという事もあるんですが。ひょっとしたら違う話なのかも…。
written by こうふう
資本関係について (スコア:1)
個人的にはうんこは(みずほほど嫌いじゃないけど)大嫌いな銀行なんで、別にどうでもいいんですけど、融資に占める中小企業取引比率や、利ざや率の高さ、手数料収益率などを考えると、収益の回復に期待できる銀行なので、投資しても損はないかと
去年の終りごろのことを考えると、外資からの資本調達で三井住友が4%台のフィーをゴールドマンに支払って優先株を調達し、「日本企業を害しに売るようなものだ」と批判されましたが、今年に入ってからUFJやSMFGがアジアの裕福層に対して劣後ローンの形で資本調達をしていますが、国内調達よりも低コストに調達できてたりするんです。(表面金利は高く思えるかもしれませんが)
問題は、それすらもできない巨大金融機関があることです。例のあそこなんですけど、はっきりい言って来年三月決算で、資本準備金を取り崩すとか、今年もまた1兆円規模の増資を行わない限り(公的資金の)優先株に対する配当が行えない事態になってしまうのではないかと思います。
まぁ、それ以前にあの銀行は、DKB派とFBK派とIBJ派の内部抗争が激しくて、それどころではなかったりするんですが。どうもシステムトラブルを機にFBK派をCBを独立王国化したIBJ派(イボ痔)が抑えて、イボ痔対でくの坊・殺人銀行連合軍という形になってるみたいで
Re:資本関係について (スコア:1)
で、だめぽは、ダメでしょう(マテ。あれですよ、とりあえず、宝くじを売ってくれれば漏れは困らないですが(ぉぃ。(でも、サマージャンボは買わなかったですが。どぅせ外れてただろうしw。)
それはともかく、真面目な話、資本準備金を取り崩しちゃうと、(計算していないので直感ですが)自己資本比率が危なくなったりするような?やっぱり、増資するんじゃないかと。
そういや、こないだの日経コンピュータでは、西日本銀と福岡シティ銀の合併プロジェクトを、第二のだめぽ銀行プロジェクト呼ばわりしていましたな。いや、非常に適切な表現だと思いますがw。あの中で「コンサルティング会社選びは難航した」とあるんですが、実は、困猿会社の一つとして、弊社にも声が掛かっていたり。漏れの同僚が何度が打合せに行ったんですが、その時点で「だめぽの二の舞になるのが見えている。というより、既になっている。」とか言ってました。ま、断っておいて正解ですな。
written by こうふう
Re:資本関係について (スコア:1)
だめぽの場合ですと、実は格付けが低すぎて海外から資本調達が不可能なんですよね。できんこともないと思うんですけど、円建てで2%以上のフィーを払えない(それだけ収益力がない)のと、資産内容の査定をDCFでやると自己資本比率が6%を切っちゃうんで、それだけは避けたいのではないかと
#だめぽほどリスクの高いところに、2%のフィーじゃ投資する気にもなれんですが(だってS&PでBBBの社債でも1.6%ですから)>気分的にはCCC
10年ほど前にシティー・コープが経営危機に陥ったとき、ジョン・リードはエコノミー席でサウジまで出かけて、11%の優先株の発行を三日三晩交渉して勝ち取ったっつー話があったりするんですが、SMBCやうんこの場合と同じように発行条件はその後だんだん良くなっていくんです
SMBCにしてもうんこにしても、資本の半分を入れ替えるくらい今後も資本調達をしていかなければならないわけなんですが(それくらい過小資本で資本が劣化)、四半期ごととは言わないですけど、市場からは節々で確実に結果を出していくことが求められていたりするんですが、結構辛いと思うんですよねぇ
実はみずほもSMBCも2年連続くらいで資本準備金を取り崩しているんです。前の年は総会決議(みずほは決議なし<違法じゃないけど違法に近い)、今年は逆さ合併と中間持ち株会社化でやってるんですけど、資本準備金自体が足りなくなってるんで、金融庁も最近は不良債権処理よりも収益力強化のほうをうるさく言ってるみたいですな
計算してみて驚いたんですが、昨年の中小企業貸出増減(公的資金注入行分)で、減少額の90%がみずほによる貸し剥がしだったりするみたいです。もうなりふりかまっていられない状態みたいで、あちこちでトラブルを起こしてるんですけど、そのうち重大犯罪になったりしないかなと。まぁ昨年から、竹中先生を激怒させるは、中小企業貸出は減らすは、全銀協会長行に恥をかかせるは、増資で取引企業とトラブル起こすわで、もう後がないことは確かなんですが
ATM24時間化 (スコア:1)
本日の日経朝刊一面に「UFJ、ATM24時間化」という記事が
UFJは、収益率改善のためにホールセールよりもむしろリテール分野を強化していますが、個人的にはどうかなぁと思う点があります。
UFJがリテール戦略を強化する背景には、大企業融資が弱いという背景があります。実は、四大グループの中では預貸率が上位(みずほ、SMBC)と下位(BTM、UFJ)に分化していてグループ全体の収益力に大きな影響を与えています。今年の三月期決算では、SMBCについで収益力が高かったUFJですが、経費節減余力や金利引き上げなどで見込める収益力上昇余地がUFJは低い状況で、状況を打開するためには一層のリテール強化が方針として存在すると思います。
ただし、こういった戦略は過去の成功体験があるのではないかと思ったりするんです
旧三和は、大手銀行の中では独立系としては上位行でしたが、いわゆる金融エスタブリッシュメント(富士、三菱、さくら、興銀)の中には入っておらず、住友と同じく関西勢として冷遇されてきました。1980年代の平和相互銀行買収による住友の関東侵略の劇的な成功の後、三和は関東でのリテール戦略を強化することによって関東上陸を成功させ、(住友の相手にもならなかったが)富士銀行の関東・関西での攻勢を踏み潰したという経緯があります。
ここで、過去の栄光をもう一度、といった感じに見えなくもないのですが、ATM戦略に関しては前々から少し疑問を抱いている点があります。
第一に、既存ATMの稼働率がそれほど高くないことです。これは、24時間稼動を行っていないから、という理由も挙げられるかもしれませんが、日本の場合は米国と異なり都市でも地方でもATM網がかなり発達しています。地方でのATM稼働率もそれほど高くないですが、居住人口が多く支店半径から500M以内での利用率が高い都市部ではATM利用需要が高く、ATM利用率の高い若年人口も多いという利点があります。その反面、都市部では人口の割にはATM数も多く、実質的には飽和状態にあるのではないかと思います。
第二点目に、コンビニATMの存在があります。すでに、E-NET、LANS、IYBANKの三大ネットワークに加えて、さくら銀行時代から拡充されてきた@BANKまであります。これらのすべてが24時間稼動で、おまけにMICS提携(IYはBANCS)提携まで行っています。このうち、BTMなどは優遇サービスでコンビニATM網利用手数料を優遇していますし、SMBCもやはり自行ATMでの優遇があります。これに対して、UFJにはATM利用が定額となる優遇サービスが存在しません。これは手数料収益を重視しているのか、それとも優遇サービスの提供によってクロスセリングできる商品がないのかどちらかです。
第三点目に、次期MICSが24時間化されることです。おそらく、多くの地域金融機関は都市部ではコンビニATM利用を進めるところがあるかもしれませんが、実質的な24時間化に対応するのは次期MICSでの相互提携利用のほうではないかと思います。
以上の点を考慮すると、以下のような疑問点が出てきます。
一番目には、自行ATMの稼働時間を延長しても、おそらくは需要がないことです。記事では、105円の手数料を徴収するとのことでしたが、それならばコンビニATMを利用しても大して違いはないからです。結局のところ、手数料収入よりも稼動コストのほうが高くなってしまうのではないでしょうか?
二番目には、場所的な問題点があります。そもそも、24時間化で恩恵を受けるのは、夜中飲みに行ったり買い物したりするときに、現金が少し足りない、なんて状況でしょう。夜中でも買い物をするといえば、ほとんどの場合コンビニですし、繁華街では支店よりもコンビニATMのほうが便利という場合が多いでしょう。加えて、防犯上の問題があります。夜中無人になる銀行ATMコーナーよりも、有人のコンビニATMのほうが安全に感じるという消費者調査もあります。
三番目には、支店の数が少ないことです。UFJは三大都市圏に支店網を持つとはいえ、人口比の支店の数は他銀行と比べてかなり「薄い」といわざるを得ません。実質的に稼動できるのは、支店ATMとなり支店から離れたATMコーナーでの稼動ができないとなると、24時間化のメリットは薄いと思われます。
思うに、ATM戦略単独ではどこもやっていることなので、リテール戦略強化には直接には繋がらないのではないかと思います。相乗効果が期待できるものがありませんし、消費者としてもメリットがありません。
逆に言えば、案外需要が高いのが窓口業務時間の延長です。
通常のサラリーマン(つうか、ビジネスパーソンって言った方がいいか?)が金融サービスにアクセスできる時間帯は、平日ではATMが稼動している時間帯しかありません。確かに、SMBCなどは土日休日に住宅ローン相談や資産運用のために窓口を開いてる店も
Re:ATM24時間化 (スコア:1)
実は、数年前に、三和銀行システム部の副部長とufitの部長に(別件で)ヒアリングに行ったことがあるんですが、その時点で24時間サービス提供は可能だ、後は経営の判断だけとか聞いた記憶があります。そのときの印象からしても、利用者の利便性の観点で用意したというよりは、(技術的に)出来るから用意したというシーズ発想的なものだった気がします。
で、ニーズサイドを考えてみると、von_yosukeyanさんが言われるように、あんまりニーズは無いんじゃないかなぁと思うわけです。例えば、夜中に急に必要になるお金って、飲み代・タクシー代・ホテル代等だと思うわけですが、その程度の金なら、手数料を払って銀行から下ろすより、消費者金融で借りて金利を払った方が安かったりするわけです。そして、消費者金融の方が、その手の利用に適した立地場所にあるわけです。つか、クレジットカードの利用が伸びている昨今の状況からすれば、現金が無いと二進も三進も行かなくなるというケースは減りつつあると思うわけですが。
営業時間の延長に関して、フルバンキングサービスが求められているかどうかは、ちょっと分かりません。相談・コンサルティング等のための窓口を土日に開くというは意味があると思うんですが、それ以外は、逆に窓口に来なくてもネット・電話・郵送等で出来るようにする方が利便性が増すんじゃないかなぁと思ったりするわけですが。対面でコミュニケーションが必要なものは窓口で対応するしかないと思うので、(現状の)営業時間外や土日にも受け付けて欲しいというのがあると思うんですが。
written by こうふう
Re:ATM24時間化 (スコア:1)
チャネルの拡大という観点からは、すでにUFJは自宅からテレビ電話(?)を利用した各種業務の基盤整備を3年計画で行う予定みたいなんですが
実際のところ、ATM手数料を取られるくらいなら消費者金融を利用する・・・という流れは、金融機関の提供する決済機能がニーズに合致していないのではないかと思ったりします。例えば、欧米の場合ではクレジットカードがこの機能を果たしていると思うのですが、日本の場合だとクレジットカードで決済できる分野と出来ない分野、振込決済ができる分野と出来ない分野が明確に損でいしていて(例えば税金の支払など)、結局現金が決済手段として常に必要になっていると思います
一方の消費者金融にしても、法手金利の引き下げや、銀行系消費者金融子会社の拡大によって、競争は激化しているのですが貸し倒れ比率は逆に高まっているんですよね。いつまで、現在のような拡大基調が続くのか定かではないですが・・・。
#ところで、今日付けの某新聞に野中先生の秘書が裏書したという手形の写真が載ってたんですが、今はなき国民銀行庄原支店のものですた(w
2年くらい前の話なんですが (スコア:1)
20台ほどサーバーがありまして、ほとんどにUPSが装着されていたんですが、なぜかUNIX(SolarisとDigitalUNIX)を除いてNetwareとかNTとかのシステムは電源が自動で落ちなかったんです
そのうち回復するだろう、なんて思ってたんですが、UPSによってはあと10分くらいで電源が落ちてしまう状態だったんで、その場に居合わせた人間で必死になってサーバーの電源を落としまくりました。Netwareサーバーの電源を落としたのは、後にも先にもあの時だけですな>漏れは
で、必死にシャットダウンコマンドを打ってた時に電源が回復して(結局7分くらい停電してたか?)、10台くらいの電源を入れなおしたんですが、4台ほど電源が入らない(つうか、HDDがお亡くなりになってた)サーバーがあったんです
確かDNSなんかに使ってたSS-20と、MS-SQLとかファイルサーバー用のPCサーバー(NT3.5が走ってたからかなり古いヤツ)とかだったと思うんですが、ずっと電源落としてなかった(おそらく2~3年は)サーバーばかりが死んでましたな。
結局、午前中に発生した停電で一日中業務が混乱したらしい(午後は講義に出てたんでよく知らんのですが)んですけど、カルフォニアの大停電でも古いサーバーがHDDがらみで永久に起動しなくなったなんて話を聞いて、そんなもんかなぁなんて思ったりとか
Re:2年くらい前の話なんですが (スコア:1)
とりあえず、電源部やHDDあたりが逝かれることが多いようです。おいらは実際に体験していないので、信憑性は分かりませんが。
しかし、去年、某所へCP策定支援に行ったときに、リスクシナリオに停電を入れておいてホントに良かったなぁと思う今日この頃。(いや、普通、入れておくもんなんですがね)
written by こうふう
Re:2年くらい前の話なんですが (スコア:1)
とゆーか、ハード自体はVMとかでかなり抽象化されてるし、現場の人はほとんどハードをいじるとかないみたいです。そもそも、CPUからメモリー、バス、電源、ストレージ、冷却システムに至るまで予備があるので、多少ぶっ壊れても平気だとか何とか
逆に、停止を前提としていないので「でんせつのあかいぼたん」を押すとぶっ壊れるなんて話を聞いたことがあるんですけど、ホントかどうか知りません
バイト先の偉い人は、確かに元某社のメインフレーマーだったんですが「動いてるモノはそっとしておけ」というのは、別のバイト先では資料なしソースなしのシステムとか、設定した人が退職して(rootのパスワードすらわからんので)誰もいじれないシステムとかありますた(ガクガクブルブル
道路ハム団とクレカ (スコア:1)
さて、実はちょっと前に蹴られたタレコミなんですけど(多分理由はソースが日経本紙朝刊だったからだと思うけど。日経テレコン未登載)
高速道路で偽造クレジットカードの利用が急増していて、カード会社が道路公団との決済を拒否する動きが一部にあるそうです
高速道路でのクレジットカード決済は、CAFIS経由でカード会社の勘定系にカード利用の可否を問い合わせているのではなく、渋滞等の問題からオフラインで決済を行っているみたいです。一応道路公団は、カード会社から決済拒否に遭っているカード番号を独自のデータベースに集めて、決済時に問い合わせているみたいなんですが、このデータベースの容量が偽造カードとして出回っているカードの数の十分の一以下しかなく、公団はかなりの数の偽造カードをつかまされているそうです
問題は、公団が偽造カードをつかまされたとしても、その損害は公団ではなくカード会社が負うことになっているそうです。イマイチ公団とカード会社の契約関係が不明なんですが、データベースの容量増加に関しては、処理速度が遅くなるので公団が拒否しているので、カード会社としては高速道路での利用を拒否したい、と考えているそうです
記事では、ETCが使えなくなるかもしれない、なんて憶測も書いてありましたが、それはさすがにないとしても、どうも解せない話です。この公団独自のデータベースは、カード挿入してから利用の可否を判断するまでに5秒、CAFIS経由での問い合わせの場合の15秒から30秒に対して圧倒的に早い(と記事。個人的な体感速度はもう少し早い気がするが>CAFIS経由)からデータベースの増加や他の手段の利用は認めないという理屈自体も理解不能なんですが(システムを増強するとかいうのは頭にないのか?)
#実は、最近話題の道路公団の団体割引制度なんですけど、実はこれがETCの普及を妨げているのではないか、という話もあったりします。団体割引の適用を受けるために、利用額が少ない運送業者でも同業者(異業種でもいいんだけど)で組合を作って一定の利用実績を作る・・・なんて手段です。この場合、料金所で専用の磁気カードを提示すれば、料金後払い(月末払い)で料金が最大で30%くらい安くなるそうです。
Re:道路ハム団とクレカ (スコア:1)
まぁ、状況は分かるけど、道路公団側の対応がよく分かりませんねぇ。システム増強するのが筋だと思うんですが。あるいは、リスクを相互に負担するという意味で、道路公団が受け付けたが、カード会社が弾いたものは公団が負担するとかねぇ。カード会社からすれば、オーソリしていないものに与信をするというのは筋が違うという感じでしょうし。
公団といえば、どっかで見かけた主張として、償還主義に基づく料金は、事業継続企業としてみれば高すぎるというのがありました。つまり、償還主義に基づく料金というのは、償還が終わった時点で負債がゼロで資産(道路)が丸々残ることを想定しているわけですが、事業継続企業であれば、負債に見合った収入があればいいわけであり、資産がその収入を生むのであれば問題は無いという主張です。
何にせよ、会計基準の置き方で、債務超過にも資産超過にも、何とでもなりそうな気がしますが…。
written by こうふう