2001年5月31日 – 東京 – 現在、日本国外のパッケージソフトウェアベンダーにはひと頃の勢いはありません。日本国内のシステムインテグレーターが海外製品に対し販売協力する(業界用語で「担ぐ」と言います)ことも稀になり、海外ベンダーの日本現地法人の経営基盤は全般に不安定、経営者も頻繁に変わります。その表面的な理由は、日本国内の需要が低迷するとともに、海外ベンダーの製品競争力自体も足踏みを続けていることです。 ある意味では、金融テクノロジーの成熟化に伴って、日本国内のベンダーにキャッチアップされてしまったとも言えるでしょう。しかしより本質的には、(1)市場に関する分析の不足、(2)コラム: 「金融機関のシステム開発」で述べた顧客からの信頼性喪失、(3)さらに現地法人のマネジメント、に問題がありそうです。 特に市場分析の問題としては、ほぼ唯一の英字業界誌であるRisk誌が好例です。特殊な専門分野で成功するには、主要な市場参加者、有力な学界関係者、規制当局の動向をフォローアップする努力が不可欠です。しかし、英字メディアから東京市場の有力金融機関、理論家、主要ソフトウェアベンダーの動きを読み取ることは困難です。Risk誌では先ごろも “Japan Risk” と題した特集がありましたが、著名な金融機関からの情報は少なく、日本の動向を伝えると言うよりもむしろ在日企業による全面広告の様相でした。いくら日本特集を組んでもRisk誌の主要な読者はあくまで非日本語圏におりますから、雑誌編集者に読者からのフィードバックを期待しても難しいでしょう。雑誌が広告料を支払ったスポンサー企業を持ち上げるのもまた自然なことです。それでは英字誌の情報の正確性に疑問を持ったとして、日本語情報を求めようとしても、Institutional Investorsを読んで理解可能な日本人と、金融財政事情を読んで理解できる米国人の比率を考えてみれば難易度は明らかです。おかげで安易に市場参入、当然ながら営業不振、高額の東京のオフィスは売上がなければ維持できませんから短期間に撤退、という事例が相次いでいます。 この英語=日本語間の情報フローの非対称性の問題は、日本語メディアと英字メディアの双方を解すことができる我々にとっても決して良いことではありません。端的な例は、英字誌やカンファレンスの広告媒体や資料としての価値が大幅に減じたことです。長年各種の海外セミナーやカンファレンスに参加して参りましたが、1980年代～1990年代中頃であればウォール街からの技術吸収としての参加意義が十分にありました。しかし商業銀行の信用リスク管理のように日本国内の方がむしろ研究事例が豊富な話題では、日本における1～2年前の話題が海外セミナーのテーマになっていたりすることも多く、時々うんざりさせられます。今では海外セミナーに参加する最大の目的は「次に東京市場に入ってくる可能性のあるシステムベンダーはどこか」といった業界動向調査となっています。経費節減の影響が大とはいえ、邦銀からの参加者もほとんどいなくなりました。 目先は不振が目立つと言っても、仮に日本の金融システム市場が1990年代前半並みに回復するような目算が立てば、日本国内のシステム会社の買収などの形で海外資本による本格参入があるかもしれません。これはSUNGARDグループによるInfinity買収のような手堅い市場参入策ですが、必要資金が大きく適当な候補もなくて過去には例がありません。その時々のスポット的な話題を狙って商品を販売する程度であれば単独の日本現地法人を作る方が簡単ですが、この方法は経営を任せうる人材の調達難が相変わらずネックです。この業界でいくら大手と言っても売上高数億円から数十億円の小企業、しかも専門性が高いので経営の難易度も高いわけです。直接レジュメから判断するにせよエグゼクティブサーチを頼むにせよ成功例は多くありません。当面は相変わらず日本のシステムインテグレーターを出先販売機関とし、大幅な販売マージンを落とす形での散発的な日本市場参入が続きそうです。なお、仮に我々自身が海外進出するとしても、直面する問題はおそらく同じです。
2001年5月31日 – 東京 – 金融機関のシステム開発に限らず、最近のシステムプロジェクト案件が難しくなっている背景には、エンジニア全般の人材の質の問題と、システムインテグレーターの会社としてのモラルの問題があります。雑誌の関連記事では、日経コンピュータ 2001年2月12日号 「IT業界のモラルハザード」をご覧になれば状況の一端を知ることができるでしょう。 メインフレームシステム上での大規模開発が主流であった当時は、企画設計に十分な時間を割き、上流工程を担当するコンサルタントやSE(System Engineer)から下流工程を担当するプログラマーからテスターまで、水が流れるように逐次作業を進める開発手法が一般的でした。これがウォーターフォール型開発方式です。新人は大抵下流工程から入り、鍛え上げられて上流工程に移動するというキャリアパスを踏み、相応の教育訓練が行われました。システム開発も何年もかかるのんびりとしたもので、技術の移り変わりも今ほど急速ではありませんでした。開発言語はCOBOL(コボルと読みます)、高度なアルゴリズムを書けない代わりに分業に向いていました。システムインテグレーターの役割とは人員を大量にプールし、育成し、チームで開発することだったのです。顧客への価格提示を人月単位で行う商慣習もこの時生まれました。突出したプログラミング能力があるからといって出世できない代わりに、規格化された大量の労働力が存在した時代です。 状況が一変したのは1980年代末頃から普及したUNIX系のシステム開発が広まって以降です。開発方法論が固まっていない新しいシステム環境では、それまで大量育成された人材の多くが役に立ちません。当然ですが、メインフレーム時代のような経験年数に応じた職階制度が徐々に崩壊、転職は日常茶飯事、UNIXやネットワークに詳しい若手の発言力も増しました。金融業界と同じく肩書きが次第にインフレ化、「プログラマー」、の上が「SE」で、その上が「コンサルタント」になりました。新人でもすぐに「コンサルタント」です。ウォーターフォール型の開発方式が崩壊したことも影響がありました。当時、ウォーターフォール型に代わる開発方式として、プロトタイプを短期間に何度も作成し見直した結果をフィードバックしつつ最終成果物へと向かうスパイラル型開発方式が注目されていました。ウォーターフォール型の開発過程をひとつの開発プロジェクトの中で何度も繰り返すわけです。本来的な意味でスパイラル型が普及していればよかったのですが、日本経済の長期低迷とインターネットブームに重なったのが不運でした。顧客からの開発単価引下げと納期短縮要請を達成するために、企画設計段階とテスト段階から手を抜いた上にソフトウェア部品の組み合わせと外注で納品してしまう、要するに単なる工程省略になってしまいました。表面的にはやさしくなった開発言語の助けもあって、中途半端なシステムが量産されてしまいます。 今やこうしてシステムインテグレーターの役割は、短期化した開発への人材の逐次投入、ほとんど人材派遣業に近い存在になっています。新聞などでよく報じられるように、大手コンピューター会社に加えて、人材派遣会社までが大量採用した人材を短期間で訓練し、開発現場に投入しています。当然ですが本人の適性や教育は二の次であり、大手から中小に到るまでエンジニアが粗製濫造される構造がみられるのです。本来、スパイラル型開発方式が最も力を発揮するのは少人数のよく訓練された専門家チームのはずですが、IT業界にそんな専門家を育てる余裕はありません。コンピュータサイエンスの教育訓練などなくとも、下請け会社ばかりでなく大手でも講習会に行かせれば即「戦力」です。ここ数年ブームであったインターネット関連の強い労働需要も問題です。他産業であれば「未熟練労働者」とみなされる人材であっても、多少社会経験があれば「コンサルタント」の肩書き、そうでなければ「SE」や「エンジニア」の名刺を持たせさえすれば、書類の上では人月単価で計算され顧客に請求書を発行可能な状況が常態化しています。今では、表に立つシステムインテグレーターの看板はほとんどあてにならなくなっています。プロジェクトが混迷した場合でも人事や業務命令は個々のエンジニアとの直接契約ではなく会社間の契約を介して行われますから、人材派遣会社よりも厄介なのかもしれません。特にネットワークやサーバーなど基盤系の担当者に問題があれば、プロジェクト全体が立ち往生してしまいます。 現在、システムインテグレーターへの開発委託を含むプロジェクトに参加する際は、(1)そもそもその会社の正社員か(外資系大手コンピュータ会社に発注したつもりが某宗教団体に仕事が流れた事件に代表されるような2次発注先や3次発注先でないか)、(2)本人に辞めそうな素振りはないか(一般に労働条件の悪い業界なので本人のモラルとともに心の健康に注意が必要)、(3)最後に当人のスキル(研修で濫造された人月単価の単なる埋め合わせ要員ではないか)、をよく吟味してかかる必要があります。
信用リスクと市場リスクを統合管理する当社リスク管理製品 PortfolioBrowser を丸紅株式会社様にご採用頂きました。
概況 今会計年度(2000年4月～2001年3月)も前期比売上高28%増と好調に推移、個別案件に特段の引掛かりもなく、高水準の利益を確保できました。 社歴の浅い当社ではありますが、財務計数的には先々期中に純資産および利益水準において店頭市場公開基準まで到達しております。 1998年7月創業以来これまで無借金、無配当、株主資本比率(自己資本比率)を100%近くに維持しつつ増収増益を続けた結果、財務体質を一段と強固にすることが出来ました。 当期売上高 467,137,967円 昨年度の売上高は、主力の信用リスク管理システム製品 CreditBrowser と、CreditBrowser の上位に位置し市場リスク管理を統合するシステム製品PortfolioBrowser (対外未発表) の2製品でほぼ二分する形でした。 また、他に格付けスコアリングシステム製品 ScoringBrowserを含め、自社開発の金融リスク管理システム製品の販売収入が当社売上の大半を構成しております。 資産の状況 金融資産については安全性と流動性を重視し、普通預金および大口定期を対象とし、複数の金融機関に分散して運用しております。 MMFを含め利回り保証のない短期金融資産、ならびに運用目的の長期資産は保有しておりません。 当社の顧客は大手の金融機関であり、販売商品は自社開発の大規模なシミュレーションソフトウェアです。 従って仕入れも在庫も基本的に存在しません。 固定資産の大半はコンピュータのハードウェアでとなっております。 今般の法人税法改正に基づき、今期からソフトウェア開発原価の計上を行っております。 なお、2002年3月実施予定のペイオフ解禁ならびに金融不安に対する備えとして、今年度中に金融資産の一部を日本の短期割引国債および米国財務省証券に振り替える予定です。 資本の状況 資本金 50,000,000円 + 準備金 140,479,000円 (注)資本勘定の140,479,000円は法令に定めるプログラム等準備金。 租税特別措置法第20条の2第1項及び第57条第1項の表の第1号の中欄のロに規定する汎用プログラム(制御プログラム以外のもの)として、情報処理振興事業協会にソフトウェア登録。 登録番号 25295。 登録年月日平成11年2月28日。 当社取締役3名が当社株式を100%保有、外部との資本関係は一切ありません。 設備投資の状況 昨今の金融機関の合併に伴い計算対象となるデータ量が増加、各金融機関への支援能力維持のためには、自社保有システムの強化が急務です。 また、設備陳腐化は研究開発の妨げです。 耐用年数の残るコンピュータシステムであっても1～2年経過した程度で積極的に除却を行い、新規に買い換えております。 2001年3月現在、ギガビットLANで結ばれた数百ギガバイトから1テラバイトの容量を持つ2～4並列CPUのUNIXおよびWindowsサーバー機を7台保有、開発および顧客のバックアップに備えております。 業務環境 当社は、自社内に研究開発リソースを持つ独立系システムベンダーというユニークな立場にあり、信用リスク管理を中心とする金融リスク管理システムの分野において日本国内で事業活動を行っております。 以下、簡単に当社を取り巻く業務環境についてご説明申し上げます。 需要動向 金融リスク管理システムの分野では、1980年代から1990年代半ばまで、ALM (Asset Liability Management)、BPV (Basis Point Value、sensitivity analysis)、Potential Exposure、RAROC/RAPM (Risk Adjusted Return […]
2001年4月 – 東京 – 住友信託銀行株式会社様に当社の大規模信用リスク管理システム CreditBrowser® をご採用頂きました。 また同月、株式会社三菱東京フィナンシャル・グループ様でも CreditBrowser® が稼動しました。
日本生命保険相互会社様に、信用リスク管理高度化のため、当社のCreditBrowser® をご採用頂きました。
2000年11月15日 – 東京 – 日経金融新聞 金融フロンティア 手術室をのぞいてみよう 十年前は珍しかった金融シミュレーションも、今ではありふれてプライシングやリスク計測に使われている。しかし、計算過程の理解は大変だ。このため、モデルの信頼性保証は、勢いシステム会社や設計者の手にゆだねられ、患者と医者に似た関係が生まれてしまう。だからと言って、手術内容に患者が無関心でいてよいはずはない。 そこで本稿では、医療事故になりかねない金融数学の事例を集めてみた。 1. 過少自由度の設計 複数の確率変動要因間の関係は、線型代数学の助けを借りて実対称行列で表現できる（図1）。図の斜線部は密行列（非零の領域）であり、金融ではシステマチックリスクと呼ぶことがある。密行列を複数内包する行列形式がスカイライン行列で、確率変動モデルの典型的形状だ。実対称行列の一辺の長さ（行列の次元数）が自由度で、内包する密行列および対角成分に応じた確率変数を右辺に置いて、確率方程式を組み立てる（図2）。これは金融に限らず構造解析をはじめとする他のシミュレーション分野でも同じである。話について来ていない方も「そんなものだ」と思ってほしい。 さて問題はここからだ。大きな自由度を扱うには、それなりに面倒なテクニック（数値計算法と言う）が必要だ。このため、意図的に自由度を少なくして計算をサボるケースをよく見かける。一時期流行したリスクメトリックスもそのひとつ（図3）。ひどい例では三千銘柄超の個別株を一確率変数で表現し、大きな誤差を伴うモデルさえ存在する。 国際ルール化している当局規制も、確信犯的に過少自由度を認めている。規制の裏をかくのはとても簡単、自由度不足の場所にスプレッドポジションでも作ればよい。「国際決済銀行（BIS）基準対応のVaR（バリュー・アット・リスク）を使えばリスク管理は万全」的発想は危ないのである。 2. 不安定な三角分解操作 実利主義・結果至上の金融屋の数学は、数学者からよく揶揄（やゆ）される物理学者の数学以上に杜撰（ずさん）だと思う。私自身も銀行員時代を含めて反省する点が多々ある。 シミュレーションの過程では先の密行列に対し、単変量で言う平方根操作、L・Lt形式への変換、つまり三角分解が必要だ。ところが、ここに入門書でよく紹介されるコレスキー分解法を使う場合、個々の数字が同じ方向に動きがちな金融系列（例・短期金利）を多数扱ったりすると、計算中にエラーが起こることがある。そんなモデルは、時々「妙に数字が狂う」。専門用語で言えばロバスト（強固）でない。この問題を抱えたシステムは計算を繰り返すほど間違いが多く生じる。だから相関係数を毎日見直すような使い方を禁止していたりする。 詳細は解説が長くなるので省くけれども、入門書から一歩進んで勉強すれば、まずL・D・Lt形式に変換してからL・Lt形式に向かう行列操作が適切とわかるだろう。 3. 収束性改善策の乱用 収束性改善策は見かけ上の誤差を減少させる。しかし、その副作用、系列間相関（マルチコ）や準乱数周期の弊害も大きい（図2）。「だれがこんな人にPh.D.を与えたのか」と笑い話ができるほど、この種の統計学上の誤り（Type I Error、通称「慌てもののエラー」）にははまりやすい。たとえば、とある著名なリスク管理システム会社の方からさえ、「準乱数（乱数に似た数列）により、数万件のポートフォリオを相手に、五千回以下の試行回数で市場・信用イベント同時存在下のリスク量を計算可能」と主張されて、閉口したことさえある。 数値シミュレーションの性格上、実用精度に到達するのは、単体イベントの計測でも一万回級、同時イベントならば、さらに多くの計算試行の末である。合併銀行の巨大資産さえ、十万回の計算をPCサーバーが十七時間（四CPUのLinuxサーバーで測定、信用VaR、CVaR、リスクコントリビューション、OLAP、DM／MTMを同時計算）で完了する今日でも、相応の準備が必要だ。 事後点検の勧め 今や成功率90%以上、手術台で患者が亡くなれば心臓外科医の腕がまず疑われる冠動脈バイパス手術も、昔ははるかに危険な施術であった。数年前、「専門家」に依頼した高額なモデル監査も結構怪しい。中古建築と同じく、モデルやシステムの品質は利用者自身が見極める他に方法はない。 ニューメリカルテクノロジーズ 鳥居 秀行
2000年9月22日 – 東京 – 日本SGI株式会社 SGI Forum 2000 於 ウェスティンホテル東京 講演概要 数値シミュレーションはリスク管理ばかりではなく、ウェザーデリバティブやクレジットデリバティブなど派生商品のプライシングにも多用されています。こうしたケースでは、比較的小規模で機動的なモデル開発が行われており、金融機関内ではディーリングの現場でよく使われています。この講演では、金融系の数値シミュレーションを行う場合の一般的な方法論と、陥りがちなミスの事例をまとめてみました。講演主催との関連でシステムベンダー関係者も多数含まれるセミナーであったため、金融業務に馴染んでいない方でもわかるような平易さ、かつ眠気を誘わないよう内容に留意してあります。 セミナーで配布した資料「並列数値シミュレーション技術のデリバティブへの応用」(pdf 1.72MB)はこちらからご請求いただけます。 その他セミナーで配布した資料は www.numtech.co.jp/resources/presentations-reports/ でご確認いただけます。
大規模信用リスク管理システム CreditBrowser® のバージョンアップを行いました。三菱信託銀行株式会社様、株式会社東京三菱銀行様、株式会社住友銀行様ほかに順次リリース致しました。
2000年6月1日 – 東京 – 大規模信用リスク管理システム CreditBrowser® を株式会社東京三菱銀行様にリリース致しました。メガバンクにおいて CreditBrowser® の導入は、株式会社三井住友銀行様に続き、2行目となります。