TBS買収問題ですっかり世論の袋叩き状態の楽天だが、EDINETの情報によると、楽天がTBS買収資金に活用しているものに実に興味深いものがあった。報道のとおり、買収資金の大半は、みずほコーポーレート銀行、三井住友銀行、住友信託銀行と主力三行からコミットメントライン(資金の用途と特定せず即座に金融機関から与信枠から資金を引き出せる契約。借り入れがなくても手数料が発生するが、借り入れ金利も長期借り入れよりも高め)に頼っているが、是に加えて少額だが楽天の自己資金及び、傘下の楽天証券からの借り入れがある

仮に、楽天がTBSを敵対的買収に動くとすれば、1兆円を超える買収資金が必要と考えられているが、すでに主力三行は楽天側のコミットメントラインの与信枠引揚げ用性を拒否している。従って楽天が買収資金を獲得しようとするならば、Livedoorが取ったようにMSCBを発行して株価を裏付けに資金を獲得する方法、もう一つがTBSの保有資産を担保にジャンク債を発行して資金を獲得するLBO、それから子会社を上場する方法の三つがある

楽天の株価低迷によって、MSCB発行はすでに道が断たれているといってもいい。楽天がTBSを買収する本当の狙いは、放送と通信の融合などというお題目を信じているバカは稀有であることを考えても、TBSの保有資産を担保にLBOを行うというのは、それなりに合理性がある。一方で、日本のM&A環境を考えると子会社上場による資金調達というのが最もベストな選択と言えるだろうが、上場審査に時間がかかることから、機動的な資金調達法とは言いがたい

ところで、仮に楽天が子会社を上場させるとすると、最も有力な選択視としては楽天証券の上場が挙げられる。しかしながら、楽天証券は先に述べたように楽天のTBS買収ファンドに対して融資を行っている上に、最近の株式市場の活況に伴うシステム問題を抱えている。どうも微妙だ

そもそも、楽天証券とは楽天がSMBCから旧DLJ Direct SFG証券を買収して改名したものである。DLJ Direct SFGとは、米国の大手投資銀行DLJと、当時の住友銀行が合弁で設立したネット証券のことである

DLJは後に、スイスのクレディ･スイスグループの投資銀行部門である米クレディ･スイス･ファーストボストン(CSFB)に買収され、DLJのディスカウントブローカー部門であるDLJ Directも外部に売却されてしまった。それでも、CSFBはDLJ Direct SFGの持ち株を手放さなかったが、買い手さえ見つければいつでも売却する用意があった。SMBCも同様だったと見られる

その間、当初米国株と日本株を格安手数料で取引できるディスカウントブローカーとして登場したものの、DLJ Direct SFGは信用取引やデイトレーダー向けのツールMarket Speedをリリースするなど、少しずつ独自の戦略を歩み始め、ネット証券では第三位の規模を誇るようになった。特に、Marker Speedはデイトレーダーに熱狂的に支持され、またDLJ Direct SFGもシステム面では惜しみない投資を行っていた。当初、DLJ Direct SFGは米国DLJが開発したシステムを日本向けに改良して使用していたが、2000年頃から取引急増に合わせて、データーベースシステムを登場したばかりのHPQ製のSuperdomeを採用し、CORBAベースのアプリケーションサーバを開発するなど積極的なシステム投資で、システムトラブルが続いてたイートレード証券から顧客を奪っていた

しかし、2003年に楽天がDLJ Direct SFGを買収し楽天証券となって以降、楽天証券に対するシステム投資は急激に減らされた。最も極端だったのが、アプリケーションサーバと基幹DBに対して積極的な投資が行われなくなった点である

一般的に、ネット証券のシステムは主にフロント系システムとバックオフィス系の二つのシステムがある。楽天の場合、当初からバックオフィス系は大和総合研究所のSONARを使用し、自社ではフロント系システムしか持っていない。フロント系システムとは、顧客から取引を受け付け、顧客の資産残高から取引可能か照合して、証券取引所に対して取引を発注する、という一連の流れを処理する。そのため、フロント系システムには、顧客の口座情報を格納する勘定系と、顧客に対して株価の情報などを提供する株価情報系(情報系)と呼ばれるシステムが存在する

楽天証券の場合、Webサーバ、アプリケーションサーバ、RDBMSサーバの三層のシステムで構成されている。Webサーバは、Webベースでの取引の他に、別系統として専用アプリケーションであるMarketspeed用のサーバが用意されており、それらはCORBAベースのアプリケーションサーバに接続されている。基幹サーバであるRDBMSは、勘定系の役割を果たしており、顧客から出される注文と口座残高を照合し、証券取引所に対して注文を発注する処理を行う

DLJ Direct SFGまでの時代、急増する取引注文に対応するために、アプリケーションサーバはHPQのNクラスや、SUNWのEnterpriseクラスといったミッドエンジレベルのかなり大型のサーバが使用されていた。しかし、楽天証券になってから、コスト削減のためにあかさらさまにスケールアウトを行い、アプリケーションサーバに関しては当初はSUNWの4CPU系のサーバに、後に1Uサイズの2CPUサーバまで落とされてしまった

その間、基幹DBの更新はCPUの交換とメモリー増強が行われるだけで、取引の急増に対応するためのアーキテクチャの変更は行われなかった。かつて、システムトラブルが多かったイートレード証券や、ほとんどWindowsだけでシステム構成を行っているにも関わらず驚異的な安定性を誇るカブドットコム証券などが、勘定系システムの分散化を進めているのとは対照的に、楽天は相変わらず巨大なSuperdome1台ですべての処理を行っていた

コスト削減効果は大きかったが、問題が出始めるのが今年に入ってからの株価の高騰に伴う市場の活況である。楽天は勘定系システムを基幹系DBサーバ(Superdome1台だけ)で処理しているために、情報系やバックオフィスシステムに対して送る日時ベースのバッチ更新処理も基幹系DBサーバで行っている。そのため、夜間にバッチ処理のために利用不能時間が存在するが、取引と口座の急増によってバッチ処理が遅延し、取引開始時間までに間に合わないという事態すら発生した

しかも基幹DBサーバは、障害発生時に待機系に切り替わるのに時間がかかるという問題点もあった。それも、待機系はコスト削減のために本番系の基幹DBサーバよりも劣ったスペックのサーバしか用意されていない。このため、ひとたび基幹DBサーバにハードウェアやソフトウェアの障害が発生すれば、待機系に切り替わるまでに取引が全くできなくなり、しかも順調に切り替わったとしてもその後の処理は遅くなる

2005年6月までには顕在化していた、楽天証券のアーキテクチャ上の問題は、7月後半からの一層の株価上昇で致命的な問題を発生させた。7月からの致命的なシステム障害は9回を数え、バッチ遅延は日常化、寄り付き後の注文取消しの遅延や不具合は常に存在する状態になった。もはや、楽天はまともに取引が出来ない証券会社となってしまった

基幹DBサーバの増強だけでなく、すべての処理が究極的に集中する基幹DBの分散化や、アプリケーションサーバの上位クラスへのアップグレードが必要なことは誰の目にも明らかだった。すでに他社は、勘定系すらも、参照系(リアルタイム系)と更新系(バッチ系)の二つに分割して、バッチ処理によるサービス中断がないシステムを構築しているにも関わらず、楽天証券は頑なにシステム投資を行わなかった。そのため、8月･9月に大規模なシステム障害が発生し、一般にも報道されるようになって初めてシステム増強に乗り出した。それも、単にSuperdomeをPA-RISCベースからItaniumベースの新機種にアップグレードし、Oracle RACを採用して処理能力を増強するというそれだけの増強策である

楽天証券のシステムトラブルの日常化は、冷笑を通り越して他のネット証券会社から激しい非難を浴びた。SBIの北尾CEOは、名指しこそ避けたものの、イートレード証券の決算発表の場において、イートレード証券のシステム担当者を紹介し、わが社の生命線であると絶賛して暗に楽天批判を行った。松井証券の松井道夫社長は、もっと直接的に楽天は業界の面汚しだと、強い口調で批判している。顧客はもっと苛烈に批判はしているが、楽天から他の証券会社にポジションを移すことで対応している

その楽天証券が、楽天本体によるTBS買収資金を融資しているというのは、実に本末転倒な話だ。証券会社は、銀行と同様に一定の自己資本を積み立てる、自己資本規制比率が定められている。楽天は法定の規制はクリアしているが、システムに適切な必要な投資を行わない一方で、楽天本体に対して株式投機資金を融資しているというのは、楽天証券の機関銀行化ではないだろうか

痛めつけられた楽天証券が上場したところで、楽天が必要とするTBS買収資金が得られるとは、とても思えない。「釣った魚に餌をやらない」…。買収した企業から資産を吸い尽くし拡大してきた楽天帝国は、TBS買収によって限界を見せはじめたと言えるだろう