“東証を変えた男”が語る、金融業界の伝説「arrowhead」誕生の舞台裏――“決して落としてはならないシステム”ができるまで
2005年11月から2006年にかけて、金融業界に激震が走った。東京証券取引所のシステムが数回、障害を起こし、株式取引が全面停止するという事態にまで陥ったのだ。
世間に大バッシングの嵐が吹き荒れる中、東証のCIO（Chief Information Officer：ITとビジネスをつなぐ役割を担う情報システム部門担当役員の名称）としてシステム全面刷新の指揮を執り、高い信頼性を保ちながら、取引の応答速度を1000分の1にするという偉業を成し遂げたのが、現在、日本郵便で専務を務める鈴木義伯氏だ。同氏が率いた「arrowheadプロジェクト」は、金融業界のシステム開発者の間で「伝説のプロジェクト」として語り継がれている。
日本を代表する重要インフラ企業のCIOとして、これまで数々の難題をクリアしてきた「国内きっての“プロCIO”」である鈴木氏は、失敗が許されない重責の中でどのように仕事に取り組み、ビジネスの課題をITで解決してきたのか。また、日本企業の情報システム部門の在り方についてどんな考えを持っているのか――。クックパッドのコーポレートエンジニアリング部で部長を務める中野仁氏が話を聞いた。
「バブル崩壊で窮地に陥った地銀を救え！」 地銀を束ねてシステムを共同化
中野： 鈴木さんといえば、金融業界伝説のプロジェクトといわれる「arrowhead」を完成させた豪腕CIOとして知られています。そもそもなぜ、ITの仕事を選んだのですか。
鈴木： 私はもともと大学で電子工学を学んでおり、自分の専門性を生かした大きなプロジェクトを運営し、社会に貢献したいと考えていました。それを実現できそうな会社として日本電信電話公社（現NTT）に入社したのです。
最初に配属されたのが「データ通信事業本部」という、当時、できたばかりの計算機と通信を手掛ける部署で、その後、この部署を母体にしたNTTデータが設立されてからも、変わらず計算機の仕事に携わってきました。ですから、それ以外のことは実はあまり良く知らないのです（笑）。
NTTデータにいた当時は、ITに対する投資のボリュームは金融業界が最も大きかったので、私も自ずと金融の案件に携わるようになりました。特に地方銀行の案件をメインで担当しており、銀行のIT部門の方々よりも、経営企画の方々と一緒に事業を創っていくような仕事が多かったので、自然と経営企画の方々と仲良くなりました。
そういう方々の中から銀行経営の中枢に上っていく人たちも多いですし、頭取まで上り詰める方も少なくないので、結果として銀行の中枢の方々と懇意になることができました。そういうコネクションができて、直接、いろいろと相談できる関係になれたことは、とてもラッキーでしたね。
中野： 当時はちょうどバブル全盛期からバブル崩壊あたりの時代で、銀行では第三次オンライン真っ盛りの頃ですね。
鈴木： バブル崩壊の際、銀行が大変な状況に陥ってしまったのは、ご存じの通りです。そこで何とか地方銀行の経営を支えたいと思って、勘定系システムを複数の地方銀行で共同化する仕組みを提案しました。
コンセプトは極めてシンプルで、「過去8年分の予算額を教えてください。その半分の予算で勘定系システムを提供します」というプロジェクトです。その上で「8年間継続利用してください」というのが条件でした。
もう1つ、参加の条件として挙げたのが、「機能追加のために毎年10億円の投資をさせてください」ということでした。共同利用のシステムの場合、“機能追加のための予算をどこが持つか”を調整するのが難しいところなのですが、あらかじめ「毎年10億円の予算」を確保しておけば、この問題で頭を悩ませる必要がありません。
さらにもう1つ、「預金量30兆円以上の規模の銀行数行にメンバーとして集まっていただく」という条件も挙げていました。この条件はハードルが高いかと思いましたが、それに見合う銀行が一定数以上集まらないと共同利用システムは実現しませんから、参加する銀行が自らほかの銀行に積極的に声を掛けてくれました。
こうして複数の地方銀行で共同利用する勘定系システムの開発を始めたのですが、初回リリースは結果的には相当な予算オーバーになってしまいました。1400万ステップという膨大なプログラムを一気に開発したので、死ぬかと思いましたね（笑）。
中野： 私も実はもともと金融系のSIer（企業のIT導入支援、コンサルティングを請け負う企業）で開発の仕事をしていたので、この地方銀行の勘定系統合プロジェクトの話はたびたび耳にしました。金融業界ではとても有名な、大きなプロジェクトですよね。私は某都市銀行の合併案件に携わったことがあるのですが、下っ端の私でも死ぬかと思うくらい大変な仕事でした。鈴木さんの案件では、それぞれの銀行が異なる要件を持っているから、それをすり合わせるのはさぞや大変だったのではないでしょうか。
鈴木： 確かに大変でしたね。この課題をどう解決したかというと、集まった地方銀行の中でも熱心で、発言力や統率力がある代表の銀行さんと相談して、そこで決めた内容にほかの銀行さんにも従ってもらうという方法をとりました。
鈴木： NTTではそんな仕事を手掛けていたところ、2005年から2006年にかけて、東京証券取引所が相次いで深刻なシステム障害を起こし、社会問題にまで発展するという事態が起こったのです。当時、私はNTTデータの子会社であるNTTデータフォースの社長を務めていましたが、急きょ、東京証券取引所のCIOに就任し、システムの立て直しを指揮することになりました。
中野： 当時は断れない状況だったのですか？
鈴木： 断れないですね。当時、西室泰三さんが東証の社長に就任しており、彼がNTTに「誰か出してほしい」とリクエストを出して、結果的に私が行くことになりました。当時の東証が置かれていた状況は極めて深刻で、金融庁もIT業界全体も「早くこの状況を解決しないと、金融業界の信用を揺るがす大変なことになる」というのが共通認識でした。
金融インフラである東証の問題でもあり、ひいては財界全体の総意でもあったわけですよ。そういう構造だったので、断るという道は残されていませんでしたね。「できるのか、できないのか」という打診ではなく、「どうやったらできるんだ」という形での要請でしたから。
Photo
危機にひんした東証にCIOとして就任。そこで見たのは……（提供：ゲッティイメージズ）
中野： 実際に東証へ行かれたときの第一印象はいかがでしたか。
鈴木： あれだけ力のあるメンバーがそろっている東証でさえ、こういう状況になってしまうんだなと驚きました。簡単に言えば、「外部への依存度が高いシステム作りをしていると、自主的にいろいろなことの判断ができなくなってしまう」ということがだんだん分かってきたんです。
また、当時は、「ITが企業の中核である」といった状況ではなかったのも事実です。
そんな状況下でCIOに着任したわけですが、当時は世間のバッシングがそれはもうすさまじくて、社内でもさすがに危機感が高まっていました。素早く結論を出して実行できたのは、そのためですね。危機感が高まれば高まるほど「どうにかしなければならない」と社内がまとまりやすくなりますから。あとはアイデアが出せるかどうか、だけです。
中野： 「ITが中核でない」というのは、古くからある業界や大きな会社ではよく聞く話ですね。
鈴木： 企業の中でITが、まだまだ特殊な業務だと思われているんですね。でも、「ITが特殊だ」なんて言ってる間は、まぁ、ダメですね。事業全体の中で、ITが財務や中核事業などと肩を並べるぐらいの位置付けにならなければダメですよ。
中野： 東証も銀行もほぼ装置産業で、中身はほとんどITですよね。例えばネット銀行やネット証券は店舗を持たず、社員も最小限ですが、システム周りがきちんとしていればそれだけでもビジネスが回ります。
それぐらい、金融においてはITが重要なわけですが、そうであるにもかかわらずITが傍流というのは、本当に根深い問題だと思います。メーカーや物流、小売りなど、ビジネスにおいてITが占める割合が少ない業界ではなおさらですね。
鈴木： そうですね。そういった背景もあって、私が東証に行くときに条件として要求したのは、「CIOとして経営メンバーの一員にしてほしい」ということでした。経営層として入らないと、言いたいことも言えないし、社内で自分の考えもなかなか通りませんから。あともう1つ、NTTデータから、一緒に東証に来て変化の仕組みを考えられるスタッフを連れていくことを条件に挙げました。この人たちには、2年後にちゃんと元の職場に戻ってもらいましたが。
“決して落としてはならないシステム”をどうやって生み出したのか
鈴木： 着任して3カ月後に今後の計画を提出した際、最も重視したのが、当時、東証が抱えていた「構造的な問題」を根本から解決することでした。現在の日本郵便にも同じことが言えますが、一番の問題は「企業内のITの構造が、『システム開発を目的としているITベンダー（企業向けのサービスやシステムを提供する会社）と同じ構造』になっていること」だったからです。
つまり、「自分たちが主体性を持って開発する」という構造になっていないんですね。本来は、技術を活用して事業を作り、お客さまにより良いサービスを提供するのがITの役割であるにもかかわらず、そうなっていない。それを可能にする構造に社内の体制を変えるために、その後、1年半ほどかけて東証用のエンタープライズアーキテクチャ（EA：企業のビジョンや目的を実現するために、組織構成や情報システムのあるべき姿、各部門の業務内容と連携の状況などといった要素を見直し、全体最適の視点で最適化する手法）を作りました。
中野： 具体的には、どのようなことを定めたのですか。
鈴木： 「何か物事を検討する際には、IT部門内だけでなく、業務部門と一緒に要件を整理する」「要求はどの時点でどうやってITベンダーに発注するかを明確にする」「その時にITベンダーとの間の契約はどうするか、業務部門とはどのように役割を分担するかをはっきりさせる」といったように、具体的な目的や目標を設定して、それらをきちんと実現できるプロセスになっているかどうかを工程の途中でしっかり評価するようにしました。
また、工程の最初の段階で、工程の組み方からチームの作り方、システムの作り方など、さまざまな面で考え得るリスクを全て抽出して、これらをどうやってリスクヘッジするかを整理しました。正確に言うと、リスクをヘッジするというよりは、リスクをコントロールするという考え方ですね。これらの方針や考え方をEAとしてまとめたわけです。
会社の文化はすぐには変わりませんから、まずは理想のモデルをEAとして提示して、それに基づいて社員が働けるようにしましたね。そうすると、徐々にそれにのっとった仕事の実績が積み上がっていき、何年かするうちに文化として徐々に定着していくんですよ。こうしたことを可能にするには、まずは仕掛けをちゃんと作る必要がある。
中野： そうすることで中で働く人の考え方が徐々に変わっていって、IT部門も組織全体としてやる気が出て、結果として一人ひとりが自走できる人間へと成長していけるわけですね。
鈴木： そうですね。厳しい仕事が多くなりますが、誰も文句なんか言わないですよ。こうした仕掛けを取り入れることで、自身がやるべきことがはっきり見えるし、やったことに対して会社側もきちんと評価できるようになるのだから。
中野： 「自分で問題を解決している」「自分で考えて自分で成果を出している」と実感できることが何より大事ですよね。IT部門の仕事は、どうしても“業務部門の御用聞き”になりがちですが、それでは優秀な人が伸びるわけがありませんし、そもそも優秀な人がそんなところで働きたいと思うわけがありません。
ちなみに、そうやって東証の構造を変革していったからこそarrowheadプロジェクトを成功に導けたのだと思いますが、社外のパートナー企業との関係性はどうたったのでしょうか。やはりそこも変えていったのでしょうか。
鈴木： 主要な開発パートナーは、実はトラブルを起こす前と同じ会社だったのですが、これは入札の結果、たまたまそうなっただけでした。しかし、トラブル前とは異なり、私たちもEAに基づいてどんどんプロジェクトに介入し、どちらかというとITベンダーをコントロールするように変わっていたから、新たな関係性を基に、互いに刺激し合いながら伸びていくことができました。
その証拠に、開発パートナーでarrowheadプロジェクトに関わっていた人の中から、その後、副社長や中枢メンバーに出世した人が何人か出ているし、それを見たパートナー企業の社内では「次のarrowheadプロジェクトには、ぜひ参加したい」という声も挙がっていたようです。
また、東証でも、当時のIT部門にいた人たちの中から、その後役員になった人が数人います。東証では現在、IT部門の存在感は他の部署と同等になっているし、CIOは生え抜きの人が務めている。外部から招いた人材ではなく、内部の社員からCIOを選べるようになったのは、とてもいいことですよ。そういう意味では、日本郵便はまだ成長の途上なのかもしれません。
中野： IT組織の戦闘力は、会社全体の強さに直結しますよね。しっかりやるとレバレッジを効かせることができます。
鈴木： 今の時代はまさにそうですね。かつてのように、業務をITに置き換えていた時代には、ITにはさほど大きな影響力はなかったわけですが、今日のようにITで事業を創る時代には、もうITの活用力が企業の成長そのものに直接影響を及ぼすのだから。
目標値の5倍速い！ 爆速「arrowhead」を生み出した富士通の技術と発想のヒミツ
富士通が東京証券取引所に納入した株式売買システム「arrowhead（アローヘッド）」は、2010年1月4日の稼働以来、現在までの約3カ月間、トラブルなく運用されている。
arrowheadは、注文応答時間や情報配信スピードの高速化を実現し、注文、約定、注文板などの取引情報を、異なるサーバ上で三重化して処理するなど、高速性と信頼性を兼ね備えた「世界最高水準の取引所システム」と位置づけられているものだ。
富士通では、arrowheadについて「金融テクノロジの高度化などを背景に、個人投資家のオンライン取引の普及や、証券会社や機関投資家によるアルゴリズム取引など、新たな取引が広がりをみせている。こうした市場環境や取引形態の変化のなかで、注文レスポンスや市場情報配信の高速化のニーズが高まっており、東京証券市場の国際的な市場競争力を強化するためにも、大規模なサーバシステム上で、高性能、高信頼なミッションクリティカルシステムを実現する必要があった。新たな先進技術や機能強化を組み入れたミドルウェアの採用など、富士通の総合力を結集して構築した」と説明する。
中でも、arrowheadに求められていたのは「10ミリ秒」（1ミリ秒は1秒の1000分の1）の高速性だったという。株式売買の発注元から注文を受け、応答保証サーバで受付通知のキューを発行し、受付通知を発注元に戻すまでの目標時間とされていたのが「10ミリ秒」だったのだ。
これに対して、富士通では1月の稼働時点で「5ミリ秒の注文応答時間を実現する」と発表。この時点で、目標の2倍以上のスピードだが、現在の実績は、なんと「2ミリ秒」。目標の5倍にあたるレベルでの高速稼働を実現しているという。この高速性はarrowheadの最大の特徴ともいえるものだ。
ミリ秒単位のレスポンスを支えるインメモリDBMS
この高速性を支える基幹ソフトウェアが、インメモリデータの高速データ管理ミドルウェア「Primesoft Server」である。
「基幹IAサーバにはPRIMEQUESTを採用し、SANディスクアレイとしてETERNUSを採用している。だが、これらのハードウェアの仕様は特別なものでない。これだけの高速性を実現しているのは、Primesoft Serverによるところが大きい」と語るのは、富士通、プラットフォームソフトウェア事業本部、次世代社会基盤ミドルウェア開発統括部部長代理の橋詰保彦氏だ。
Primesoft Serverでは、メモリ上に取引情報を配置することで、超高速データアクセスと、高いレスポンス性能、高スループットを実現している。「高速アクセスにおいて、ネックとなるのがI/O。ディスクアクセスをなくすことでI/Oのネックをなくし、メモリ上で高速アクセスするという、これまでの既存技術にとらわれない発想によって実現した」（橋詰氏）とする。
ログ情報についてもインメモリ処理を行っており、これもPrimesoft Serverならではの特徴といえる。さらに、メモリ上に配置した取引情報を三重化。各データ処理の実行環境は、「アプリケーション層」「インスタンス層」「ノード層」の3層に切り分け、アクティブインスタンスの異常時には、わずか数秒で、スタンバイインスタンスに切り替えることができるという。
「異常検知を含んで1.5秒程度での切り替えが可能。誤認なく異常を検知するという点で工夫を凝らしているのが、Primesoft Serverの特徴と言える」（橋詰氏）
異常個所に応じた三層の自動切り替えも、安定したシステム運用を実現するための仕掛けだという。また、レスポンス確保に特化したフロントエンドと、データ蓄積のためのバックエンドとに処理を分離。フロントエンドでは、ディスクアクセスをなくすとともに、機能分散された各サーバを非同期メッセージングで連携する。さらに、同一機能を持つサーバを並列に配置することで、スケールアウト型の拡張性を確保している。これも高速性、信頼性に大きく寄与しているポイントだ。非同期な処理連携を行うPrimesoftキューは、高速でメッセージ送信順に通番を払い出し、連続性を保証するとともに、業務のリカバリの際にも利用されることになる。
ネットワークの問題も独自の技術と発想で解決
高速アクセスを実現するにあたって、もうひとつのネックとなるのが「ネットワーク」である。ここではメモリアクセスのような決定的な回避策というものはないという。しかし、arrowheadはこの問題についても、これまでの考え方を打ち破る手法で解決している。
「信頼性が高いが高速性で課題が残るTCPではなく、高速性を実現できる軽量なUDPプロトコルを採用した。ただし、信頼性を確保するため、富士通独自の送達確認技術を活用することにした。このプロトコルは、汎用的なものである必要がないため、独自の技術を採用するという判断をした。複数の受信インスタンスに対する多彩な送達確認パターンを実装し、局面に応じて使い分けるレイヤードACK技術を活用した」（橋詰氏）
また、2系統に同一データを送信して、受信側が早く到着したデータを使用するという仕組みを使い、後からきたデータは削除するという処理も行っている。「同じデータを送信し、片方を捨てるというやり方は、一見無駄に見えるが、片方の系統に異常が発生してもデータを再送せずに業務を継続できる。ネットワーク異常時も性能劣化がない通信が実現できる」という。
一方で、拡張性にも配慮している。arrowheadでは、安定した取引サービスを提供できるよう、常にピーク値の2倍のキャパシティを確保しているという。必要に応じての拡張は、1週間程度で実現。稼働時点でも、過去のピーク値の約4倍のキャパシティを確保できているという。
パーティショニングによるデータの自由なノード配置を行うことで、CPUやメモリ不足時にはノードグループを追加して拡張できるようになるほか、突発的な呼量増加に対応する動的データ再配置機能によって、UAPサービスの一部資源を数分で予備UAPサービスに移動できる。例えば、1月4日のJALの取引量増加の際には、前場の動きを見て後場にはUAPサービスを独立したものに移動。4月1日の第一生命の上場の際にも、事前に独立したUAPサービスに定義しておくといった柔軟性のあるリソース配備を行っている。
「Primesoft Serverの開発にあたっては、データベースやネットワークのエキスパートを集める一方、既存技術にとらわれない発想をコンセプトとした。メモリ上で冗長構成を実現するということ自体が既存技術にとらわれない発想といえる。専門的に深堀りしすぎると限界が生じる。既存技術にとらわれないことが、桁違いの高速性を実現することにつながった」（橋詰氏）
arrowheadは、まさに現在におけるミッションクリティカルシステムの最高峰といえる。富士通の最先端技術が数多く注ぎ込まれていることに加え、既存の発想を越えた取り組みがあったことが、これまでにない高信頼、高可用、高速なシステムとして実を結んだのだ。
