TOP>企業情報>コラム>お客様の声>NO.10 カブドットコム証券

NO.10 カブドットコム証券

オンライン証券では、情報システムが会社の実体そのものである。中でも徹底した自前主義、ディスクローズ主義に特色のあるカブドットコム証券に、自前構築ならではのメリットとリスク、さらには失敗体験に至るまで詳しく聞いた。(マシン上のサインは、マイクロソフト ビル・ゲイツ氏、スティーブ・バルマー氏)

Guest Speaker
カブドットコム証券株式会社
システム統括部 システム一課長
天野達雄氏


1. システムは自前で構築


カブドットコム証券は、数あるオンライン証券の中で、唯一システムを自前で組んでいる会社だと聞きました。まず「自前」というのはどういう定義ですか。

外注に頼り切らずに、自らを頼んでシステム開発をしたという意味です。すべてをスクラッチから書いたわけではありません。

ほとんどのオンライン証券は、市販の「オンライン証券向けのトータル・システム・パッケージ」を購入して業務を開始するようです。しかし、カブドットコム証券では、システムは外から調達せずに、個別のパッケージ・ソフトに自分流の作り込みを加えてシステムを組み上げました。

2. なぜ自前でシステムを組むことにしたか


なぜ自前でシステムを組むことに決めたのですか。

3つのメリットを狙ってのことです。

1. 【コスト・メリット】
システムを外から調達した場合、「手間」は減りますが、「費用」は必ずしも減りません。自前構築と、外からの調達を、コスト面で比較した場合、イニシャルコストは微妙ですが、ランニング・コストは自前の方が間違いなく安価です。証券システムのランニング・コストは「一約定あたり費用」という基準で見ますが、アウトソースすると、ばかばかしいほど高くなります。

2. 【スピード・メリット】
オンライン証券をとりまく急激な環境変化に対応するためには、そして、各社間の熾烈なサービス競争を勝ち抜くためには、開発にスピード感が必要です。そしてスピードを求めるなら自社で開発するのが一番です。作り替えたいと思えば、すぐに作り替えればよい。外注の技術レベルや、都合や、営業交渉などに煩わされたり、足を引っ張られたりすることもありません。

3. 【差別化メリット】
カブドットコム証券には、±指値(プラマイさしね)や、ストップロスオーダーなど、様々な独自サービスがあります。こうしたサービスは、アイデアそのものが素晴らしいのか、それともアイデアは浮かぶが実装が追いつかないのかというと、答えは後者です。社内に開発ノウハウを持っていれば、アイデアを実装でき、他社との差別化ができます。

3. 自前でシステムを組むことのリスク


自社でシステムを持つことのデメリットは何ですか。

デメリットというよりも、リスクですね。例えば次のようなリスクでしょうか。

  ・頼れるのは自分だけというリスク
  ・外注のせいにできないリスク
  ・イニシャルコストがかかる(=投資回収に時間がかかる)リスク
  ・日々の運用・保守などを少ない人員の中で回すリスク

しかし、先に述べたメリットの方が、これらのリスクを補って余りあります。オンライン証券は過渡期、戦国時代。まずはリスクを取ってリターンを得て、勝ち抜かねばなりません。

システムを自分で保有する会社と、外出しする会社の違いを、社内ではよくラーメン屋さんに例えて話します。 システムを外出しする会社は、フランチャイズに加盟してスープやレシピを本部からもらうラーメン屋さん。カブドットコム証券は、自分でスープを作って、味を改良していくラーメン屋さんというように。

また、日々、運用や保守に明け暮れていると、何だか田んぼや畑と同じようにも思えてきます。毎日の手入れは大変だけど、そうして常に耕して肥やしを入れないと、今年は収穫できても来年は枯れる。システムも運用(手入れ)を怠ると、次の改良の時にうまくいかなくなるというように。

4. カブドットコム証券のシステム構成


カブドットコム証券はどのようなシステム構成をとっているのですか。

順々に述べると次の通りです。

  ・すべてオープン系のシステム構成である。
  ・大きくは「注文を受け付けるフロントエンド部分」と「お客様の資産状況を記録する勘定系部分」の二つに
   分けられる。
  ・フロントエンド部分は、株の売り買いに関わるシステム。WindowsとSQL Serverで組んでいる。Web経由
   でお客様から注文を受けて、それを東証、大証などに流し、注文を「約定」させる。
  ・勘定系部分は、お客様の資産情報、つまり、どんな銘柄の株をいくつ保有しているかなどの情報を記録
   するシステム。ここはUNIXとOracle

オンライン証券の場合は、フロントがUNIXで勘定系が汎用機であることも多いようですが、カブドットコム証券ではフロントがWindowsで勘定系がUNIXという構成です。

フロントをWindowsにした理由は、開発スピードです。UNIXでCからこつこつプログラミングするよりも、Windowsの便利な開発フレームワークを使って素早く開発した方が良いと考えました。

勘定系がUNIXである理由は、ベースにした勘定系のパッケージ製品(MetaOffice/Securities)がUNIXにしか対応していなかったからです。

アシストに手伝ってもらっているのは勘定系の方、UNIXとOracleの部分です。

5. 受注システムと資産記録システムでは、どちらが「基幹系」か。


お客様の日々の取引を制御するフロント系。お客様の口座情報を管理する勘定系。カブドットコム証券にとってはどちらが「基幹システム」ですか。

どちらもカブドットコム証券の非常に重要な基幹系システムといえるのですが、究極の選択ですね。では、仮にこのデータセンターで大事故が起きたとして、どちらのシステムに生き残っていて欲しいかという仮定で考えてみます。やっぱり勘定系の方に残っていてほしいですね。

フロント系の注文システムももちろん重要です。しかし最悪の事態を考えた場合、注文システムが障害で止まってしまった時の影響範囲は注文受付が出来なくなるだけで、お客様から預かっている株券等の有価証券や現金等、資産情報には無影響ですが、勘定系システムが停止した場合は、これらの全資産情報に影響が及ぶ為、お客様から注文を受け付けられなくなるどころか、お預りしている資産の返却をさせていただくことすら出来なくなってしまいます。冗談でも想像したくない事態ではありますが…。

6. 3つの失敗体験

カブドットコム証券のシステムにおける、失敗寸前体験(=ひやり、ハッと体験)をさらに超えた、失敗体験(=やってしまいました体験)について教えていただけるでしょうか。読者にとっては、成功体験よりも、失敗体験の方が参考になるので。

わかりました。カブドットコム証券は色々なことをオープンにするのがポリシーなので、読者の皆様のために、いろいろお話ししてみましょう。 今、思い出せるのは次の三つの失敗体験です。

1. 【創業当初;キャパシティ・プランニング見誤り】
2000年の創業時、キャパシティ・プランニングを見誤り、システムに過負荷がかかり、動作が著しく遅くなった。

2. 【2003年夏;相場高騰に伴う過負荷にシステムが耐えきれなくなる】
2003年夏に日経平均が急上昇。システム増強が追いつかず、動作が著しく遅くなった。

3. 【2006年初頭;資産残高のズレ】
2006年初頭に、一部の銘柄で外部情報提供会社より、誤った株式分割情報データを取り込んでしまい、画面表示上の資産残高にズレが生じた。

7. 失敗体験その1:「創業当初;キャパシティ・プランニング見誤り」


では、一つずつお聞きします。最初の失敗体験「創業当初;キャパシティ・プランニング見誤り」について具体的には。

カブドットコム証券は、2000年11月に日本オンライン証券とE-Wing証券が合併して生まれた会社です。この立ち上がりの際に、キャパシティ・プランニングを見誤り、その結果、DBサーバのCPUが100%で凍りつくなどし、約一週間の間、過負荷の状態になりました。

この場合、お客様サイドから見ると、Webを通じて売り買いの注文を出したときに、ブラウザがジーッと処理中のまま、なかなか完了しなかったり、あるいはタイムアウトになって、注文が成立しないなどの状況が発生していました。

お客様から苦情は来ましたか。

はい、たくさん来ました。

どんな内容の苦情ですか。

お金に直結する苦情なので、『今、売ればいくらの儲けだったのに』などの激烈な内容です。中には、金融庁に直接、苦情の電話をかけるお客様もいらっしゃいました。しかし、最も怖いのは、何の苦情も言わず、スッと他のオンライン証券に乗り換えるお客様です。

その時、どのような顧客対応をしましたか。

ありとあらゆる手を尽くしました。一つの例としては、お客様に、次の内容を記した手紙をお送りしました。

 1. 発生事象の報告(何が起きたか)
 2. 影響範囲の報告(誰にどこまでの影響があったか)
 3. 今後の暫定策、恒久策(とりあえずの対策と根本的な対策)

特に、「恒久策」として、SLA(サービス・レベル・アグリーメント)を設けました。

8. オンライン証券のSLAは、アイデアはシンプルだが実装は困難


どのような内容のSLAですか。

『5分を超えて注文処理が遅延した場合には、仮に遅延がなかった場合に約定したであろう最良価格と比較し、お客様に不利な場合にはその差額を返却(値合金処理)します』という内容です。


また、月間でこのようなSLAが何回発動されたかも、Webサイトで公開しています。

そうしたSLAは、どこのオンライン証券でも実施しているのですか。それとも御社だけですか。

2006年9月の段階で、明言しているのは弊社だけだと思います。このSLAも、アイデアはシンプルですが、実行することは以下の理由により難しいと思われます。

 1. 大障害時のリスク(補償額)が読めない。
 2. 単純なアイデアの割に、システム実装は案外に複雑かつ難解で、大変な作業。
 3. 新サービス導入のような華々しい施策ではなく。障害時の保証という後ろ向きの施策。総論としては
   誰でも賛成するが、実際に会社としてお金をかけて実行するかというと、皆、躊躇する。

特に三番目の理由を克服するのが難しい。弊社にしても、創業時に痛い目にあったおかげで、克服できたというのが正直なところです。現在もこのSLAが他社に対する競争力の源泉となっていると自負しています。

9. 夜間株取引のシステムを組むのは大変か


2006年9月現在今、カブドットコム証券の手数料は、他社と比べてどうですか。高いのか、安いのか。

高からず、安からずの価格です。なお、取引量が大口か小口かで料金体系が変わったりしないので、1,000万円以上の取引をする場合は割安感が出てきます。

手数料を改定するなど随時、値下げもしていますが、大きな方針としては、値下げよりは、サービス充実の形でお客様還元を行うことにしています。

最近のサービス拡充例などがあれば、お知らせください。

2006年9月より、株式の夜間取引ができるPTS(私設取引システム;proprietary trading system)を始めました。PTSとは以下のようなものです。

 1. 従来は、株式売買は9時~15時の間に証券取引所を通じてしかできなかった。
 2. PTSにより、19時30分~23時の夜間でも取引できる。これは証券取引所を介さない取引である。
 3. 昼の間に株式取引ができないサラリーマン層などの利便が上がると期待できる。


夜間取引のシステムは、組むのが大変ですか。

システム構築の方は、抽象構造で考えれば、それほど大変ではありません。お客様からの注文を、昼間は「カブドットコム証券システム → 東証などのシステム」という形で中継しているのを、夜間は「カブドットコム証券システム → PTSシステム」の形で中継するというように、リレー先が変わるだけなので、システムの構造上はさほどの影響はありません。

しかし、システム運用は明らかに大変になります。夜間もシステムが休めないので、今まで以上に安定稼働性に気を配らねばなりませんから。

企業が重要な発表を行うとき、株価に影響を与えないよう、証券取引が締まった後の夕方17時に発表することがよくあります。しかし夜間取引が始まると、発表のタイミングがますます難しくなりそうです。

今はまだ夜間取引の規模が小さいので、そうした影響は微小ですが、将来的には「PTS向けの配慮」も企業側に生じてくるかもしれません。

10. 失敗体験その2:「2003年夏;相場高騰に伴う過負荷にシステムが耐えきれなくなる」


「2003年夏;相場高騰に伴う過負荷にシステムが耐えきれなくなる」についてお聞かせください。

2003年の春から夏にかけて、日経平均が7,000円台から10,000円台に急回復したのは記憶に新しいところです。相場急騰ピークとなった7月頃には、カブドットコム証券への注文量も想定量の1.5倍まで急増しました。システムが耐えきれなくなりそうでした。

急遽、設備を増強しましたが、マシンの設置とチューニングが終わるまでの数日間は、創業当初の過負荷の時と同じように注文受付が滞りました。

11. 「株式のEコマース」ではキャパシティ・プランニングがなぜ困難なのか


カブドットコム証券は創業当初にキャパシティ・プランニングのヨミで失敗しました。その後、お客様への損失払い戻しをも視野においたSLAを設け、ある意味、自分を追い込んだ。そのSLAを発動させないためにも、設備は十分に増強していたと思います。それでも再び失敗した。オンライン証券のキャパシティ・プランニングはそれほど難しいのでしょうか。

2003年の相場の急騰と注文量の増加。まさかここまで急激に伸びるとは予想できなかったというのが、正直なところです。個人的には、この時の経験で、「株式のEコマース」という業態でのキャパシティ・プランニングの難しさを再認識しました。

具体的にはどのように難しいのですか。

以下のとおりです。

 1. オンライン証券は、「株式」という商品の「Eコマース」である。
 2. オンライン証券では「株式」を売り買いしている。「株式」は、相場の上下に伴い、注文量も上下する。
   突然相場が上がれば、突然注文量も増える。「相場」は、キャパシティを決定する重要な変数である。
   しかし、相場の上下は読めない(読めるのならファンド・マネージャーになれる)。したがってキャパシティ
   も決定しにくい。
 3. オンライン証券とは「Eコマース」の一種である。Eコマースであるが故に、サイト訪問者の数に、理論上、
   上限がない。これがリアル店舗での株販売であれば、受付スタッフの人数が受付可能量の上限を決める。
   電話での取引受付でも、やはり電話回線の数が受付可能量の上限を決める。言い換えるならば、仮に
   注文が殺到したとしても、『今、受付がいっぱいです。電話がパンクです』という理由で、顧客の納得を
   得られないこともない。
   だが、「Eコマース」の場合、そのような「物理的上限」がない。よって、受付可能量にも理論上、上限は
   ない。しかし、実際には上限はある。コンピュータ・システムの能力が上限を作る。
   注文が殺到したからと行って、リアル店舗が“壊”れるわけではない。電話回線が“切断”されるわけでは
   ない。しかし「EコマースのWebサイト」に注文が殺到して、システム受付可能量の上限を超えると、シス
   テムが“落ちる”。これは顧客からは状況が把握しにくいだけに納得しづらい。

12. 企業内情報システムとオンライン証券のキャパシティ・プランニングの違い


私は、前職では企業向けのシステムを開発していました。その時のキャパシティ・プランニングと、今のカブドットコム証券でのキャパシティ・プランニングは全く違います。

企業内システム、例えばメールやグループウェアなどのキャパシティ・プランニングの場合、計算式は、大まかには以下のようになります。

【システム使用量 = 利用者数 × 一人当たりの使用頻度】

利用者数や使用頻度は、いずれも、急に増えたり減ったりしない変数です。よって、キャパシティ・プランニングも過去の傾向から、ある程度は導き出すことが可能です。

また、受発注システムのキャパシティ・プランニングなら、大まかには以下のようになります。

【システム使用量 = 取扱商品点数 × 一商品当たりの受発注量】

商品の受発注量は、市場での売れ行きに左右されるので、やや変化の度合いが激しい変数です。しかし現実には、商品が急激に売れ始めた場合、受発注システム自体が”落ちる”ほどの負荷が発生する前に、在庫が尽きるなどの事態が先に発生することのほうが多いと考えられ、システムへの負荷は自然に低くなると思われます。

一方、カブドットコム証券のキャパシティ・プランニングの計算式は以下のようになります。

【システム使用量 = カブドットコム証券の口座数 × 一口座当たりの取引量】

いずれも相場の上下、熱狂度に応じて、急増急減する変数です。また、先にも述べたとおり、見た目の注文受付可能量に上限がなく、放っておけば、システムが落ちるまで注文が出されます。

このように、企業向け情報システムとオンライン証券とではキャパシティ・プランニングの緊張感がまったく違います。企業向け情報システムの感覚で、オンライン証券システムのキャパシティ・プランニングをやっていると、あっという間に立ち行かなくなります。

13. 現在のカブドットコム証券におけるキャパシティ・プランニング


現在、カブドットコム証券のキャパシティ・プランニングはどのように行っているのですか。

口座開設数、約定数の推移を見ながら、年度単位で予算計画、増強計画を立てます。相場高騰(→注文量増大)のような緊急時には、緊急増強を行います。

ここでの困難は、増強決定から実装までのリードタイムです。Webサーバなどであれば、「増強決定 → サーバ発注手配 → 実装」まで一週間もあれば済みますが、基幹システムの場合、構成を決めて、導入まで半年はかかります。このリードタイムをいかに縮小するかが、今後、アシストなどの支援も得ながら、考えていかねばならない課題です。

現在、カブドットコム証券ではSuperdomeなどのハイエンド・マシン、要するにIntelの一番デカくて速いマシンを入れています。ハードウェアの性能が上がれば、その分キャパシティ・プランニングにも余裕が出ます。メーカー各社の今後の開発努力に期待したい部分です。

14. 失敗体験その3:「2006年初頭;資産残高のズレ」


最後に「2006年初頭;資産残高のズレ」とは。

2005年の年末に、個人投資家に人気のある銘柄が株式分割を行うことになりました。

株式の分割情報は、年明けに株式情報提供ベンダよりcsvファイルで送られてくることになっていたため、それをシステムに取り込むことで、分割情報の反映は無事終了のはずでした。しかし担当者レベルのやり取りの中で、そのcsvファイルが予定の日に届かず、さらにcsvファイルのデータに一部誤りがあった結果、株式の分割情報がシステムに正しく反映されず、最終的にその分割銘柄を持っていたお客様の資産残高画面の表示と実際の預り資産にズレが発生しました。

これは担当者の人為ミスを、システムがチェックしきれなかったことが要因です。プログラムのロジックに不十分さがありました。

この事態に際し、どのような対応を行ったのでしょうか。

暫定策として、直ぐに画面上の残高表示を正しい残高に調整し直しました。さらにトラブル発生から3ヶ月の間は、状況をトラッキングし、締め処理のタイミングで、再びズレが起きたりしないかどうかを目視チェックし続けました。
こうした不具合対応の期間中は、システム部門は不眠不休状態になります。アシストなど協力会社の支援を最も必要とする時期でもあります。

15. なぜシステム構成や失敗体験をディスクローズするのか


カブドットコム証券では、Webサイト上で、自らのシステム構成や使用ハードウェア、ソフトウェアなどもすべて公開しています。また今回の取材でも、貴重な失敗体験をお話しいただきました。なぜそこまで徹底的に情報を公開なさるのですが。

すべての情報をディスクローズしていくことは、お客様への説明責任を果たせ、またサービス向上にも繋がると考えているからです。ミスをした場合も、いわゆる『隠蔽』をすることなく、公表して説明責任を果たすべきだと考えています。

※ 2006年現在の構成図です

※さらに詳しいシステム情報はこちら

16. アシストへの評価


アシストは勘定系のデータベース(Oracle )、の構築・運用を担当しています。アシストを起用するようになった経緯についてお聞かせ下さい。

カブドットコム証券創業当初は、別のSI会社にOracleの構築・運用を依頼していました。しかし途中からアシストに切り替えました。

切り替えた理由は何ですか。

カブドットコム証券では、システム部門を含む全部門を対象範囲としてISO9001を取得しています。それに則り、リソースの供給者管理、つまりシステムの提供会社の見直しを年に一回行わねばなりません。そして、ある年の見直しで、いくつかの理由からアシストを起用しました。

現在のアシストへの評価はいかがでしょうか。

「最強のOracle専門家集団」と呼んで良いでしょう。現状で不満はありません。100点です。今後は是非120点を目指していただきたいです。アシストの良い点を粒立てて述べれば以下のようになります。

1. 対応の早さ
企業によっては、営業部門とSE部門の間に距離を感じる場合があります。営業に対応を依頼してもSEの対応があるのが一週間後というように。しかしアシストは営業とSEの直結性が高く、ほぼ即日の対応があります。

2. OSを選ばないOracle知識
Oracleができると謳う会社でも、Solarisは得意だが、他のOSは不得意というように偏りがあることがあります。我々としては彼らの得意不得意に足を引っ張られたくない。一方アシストは、Oracleが得意というだけあって、どのOSでも対応できる。ある時期、OSをSolarisからHP-UXに切り替えましたが、アシストからは的確な支援をいただけました。

3. Oracleのナレッジ(修羅場経験)
Oracle専門家はOracleオタクとは違います。マニュアルを暗記しているというだけではダメで、実際の修羅場経験が必要です。アシストの技術者は、現場経験が豊富で、全社的なナレッジの蓄積を感じます。

4. コミュニケーション能力
カブドットコム証券には、様々なIT関連会社が、共同してシステムを構築・運用しています。つまり、様々な利害関係を持つ会社が集まっているわけで、局面によっては利害が相反することも生じます。こうした環境においてはコミュニケーション力が大事です。コミュニケーション力の根幹は「(カブドットコム証券の)方向の把握力」だと思います。カブドットコム証券が、お客様のために、今何をしようとしているか、どこに向かおうとしているか、それを的確に認識し、利害調整の軸とする姿勢が重要です。この点でもアシストは評価できました。

5. コミットメント力
今日、お話ししたようなシステム不具合が発生した時は、極端な場合には不眠不休で復旧に努めねばなりません。死ぬ思いをします。そういう時にアシストは一緒になって復旧に努めてくれました。そういう会社が必要です。

17. 今後の予定、そしてアシストへ期待すること


今後の情報システムの予定について、少し教えていただけますか。

近々、基幹システムのアップグレードを行う予定です。その際、アシストさんにJP1 による統合運用管理の構築部分をご支援いただく予定です。統合運用管理システムに期待する効果としては以下の通りです。

・トラブル発生時、これまでは…
担当者がシェルを起動し、そこからトラブル・シューティングするイメージ。属人性が高く、その担当者がいなかった場合の対応に不安が残りました。

・トラブル発生時、JP1導入以後は…
例えば、『ネットワーク障害発生 → アラートが管理者に来る → 管理者は状況を認識した上で、障害復旧ボタンをポンと押す → あらかじめ仕込んでおいた障害復旧プログラムが走って、障害を直す』 というような、「半自動体制」になるイメージを期待しています。

今後のアシストに期待する点は。

今、オンライン証券界は戦国時代です。カブドットコム証券は、優れたサービス力と安定稼働力で、お客様の支持を得たいと考えています。そのためには協力会社各社の支援が不可欠です。

アシストには、今後もOracleの専門家、プロフェッショナル集団として、優れたサポートを期待いたします。またJP1についても今後はOracleと同等の提案性を期待します。引き続き、よろしくお願いします。




※現在、ご利用いただいている製品、サービス
  ・ リレーショナルDB(構築支援含む):Oracle
  ・ 統合運用管理ツール(構築支援含む):JP1
  ・ 各種保守サポート

※ カブドットコム証券のWebサイト
※ 取材日時 2006年10月 【取材協力:(株)カスタマワイズ】

「お客様の声」の新着コンテンツ


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る