みずほ証券がジェイコム株を61万株、１円で売却依頼を東証に出した件。注文直前の気配値、一株91万2千円で買い戻すことで決着しそうだが、当方の感想。「そんなばかな」。コンピュータネタ、目次へ第一報を聞いたときは「明らかなミスと誰にでも分かる場合は、売買契約そのものが不成立」という例がネット販売であったので、同じような理屈で約定が成立しないのかなあと思った。（ZERO-ONEでしたっけ？VAIOノートの売価を19,800と表示してしまって、注文を受けてしまったものの、明らかな錯誤ということで〜民法の規定でしたっけ〜売り手が全部キャンセルしたの。）でも、まあこれは商慣習の違い。証券取引には民法の規定が当てはまらないそうだ。そういうものだと言われれば、そういうものかなと思う。
が、金額と株数を取り違えるというポカを受容するとしてもだ。なんで91万2千円の値が付きそうなものを61万円で売却する注文を出せるのだ。みずほ証券ははじめから、その差額30万2千円を損するつもりだったことになる。そんなことがあの会社では許されるのか。つまり「内部統制」の問題である。たとえミスが無くとも会社に明らかな損害を与える取引を、みずほ証券はノーチェックで実施できるということだからだ。（ホールセール向けの証券会社で「１株だけ売る」なんて顧客注文があるかねえ。多分担当者が練習で行ったような気がするなあ。いずれにせよ「はじめから損するつもりで」売り注文を出したのだから「結果として大損しても」同情の余地はない。儲けるつもりでも損することがあるのが株式市場なんだから。）
再発防止策は、売買注文システムに注文を入力する時には、担当者が申請をあげて権限者が決裁をしたのち、市場に注文を出す、よう事務フローを整備する、ということになるであろう。多分システム開発が間に合わないだろうから、申請はとりあえず「書面で」となり、取引をしたいときにはワープロで申請書を書き、印鑑を押す、というきちんと証跡が残る形になるだろう。まあ、いちいち申請書を作っていたのでは時間がかかるので、腕に覚えのある担当者がＥＵＣと称して「申請書作成支援マクロ（ネットワーク対応版）」あたりを作るかもしれない。ただし公式なシステム化は遅れるので（今回の大損でシステム投資のお金がなくなったから）、当分の間書面で事務が回る、ということになりそうだ。←市場系のシステムなら違和感を感じるけど、それ以外なら、ありそうな話ですなあ。基幹業務のシステム化とワークフローのＯＡ化を別々にやるとこんな運用になりそう。・・・これを（システムＡ）とする。冒頭の問題は金で解決したようなので杞憂に終わったが、当初はみずほフィナンシャルグループが解体になるのでは、とさえ思ってしまった。この取引で想定された損失は青天井。みずほ証券と親会社のみずほコーポレート銀行は連結決算のハズだからここのバランスシートへの影響もありうる。倒れるところまでは行かないと思うが、自己資本比率がBIS規制の８％を割り込んでもおかしくない。
となると、持ち株会社のみずほフィナンシャルグループは「グループとして支援」などと呑気なことを言う余裕はない。次回の決算までにみずほコーポレート銀行を連結対象から離さなければならない。あの会社多分冷たい。前例はある。「山一証券は芙蓉グループではない」と言って切り捨てた。
さらに政府から借りている公的資金を返済しないといけない。フィナンシャルグループのもう一つの銀行（みずほ銀行）から借りて払うかねえ。公的資金の借り入れは旧日本興業銀行として借りているから、別にフィナンシャルグループとして返さなくても理屈は通るかもしれない。
またみずほ証券は否応なしにジェイコムの大株主になったわけだが、企業戦略上の影響はどうなるんだろう。（みずほグループが派遣社員を依頼する先がみんなジェイコムになったりして。）システム屋として嫌なことが１つある。これが人手を介した取引だと、注文を出した時に「変ちゃうか？」で取引に載らない可能性が高い。場立ちの新人が売りと買いを間違えてサインを出し、泣く泣く自分でその株を買ったという話を聞いたことはあるが（バブル期以前なので、あとでものすごい資産になったはず）、１円で61万株！なんてサインを出すと「おい！」という目でにらまれ、そこで気がつく可能性が高い。
ところがコンピュータの中で売買契約が成立するのだと、プログラミングされていない限りチェックはかからない。まさに機械的に約定が成立してゆく。
恥ずかしながら、この種のシステム化リスクは今まで気がつかなかった。それは「不自然な突合にワーニングメッセージを出す」というシステム仕様を設計中に考えることはあるかもしれない。が、開発費用を削減されれば（労働の対価を落とすという形で誇りを傷つけられれば）「多分やらない」。もう一つ嫌なこと。みずほ証券のシステムは「１円６１万株」という明らかに不自然な取引に対してワーニングを出したらしい。担当者は、これを無視したそうだ。しかし考えてみろ、よほどの馬鹿でなければ無視するはずがない！（最近よほどの馬鹿が増えて困ってはいるが）。きっとその馬鹿はオペ時に何らかのワーニングメッセージが出ることを想定していた、あるいはワーニングメッセージが頻発するので「いつものやつか」と無視したと考えられる。そうだとすると大変だ。頼むから詳細は発表しないでくれ、もしそうだとすれば「いやでも分かるようにシステム的に対処すること」という要件があちこちで「追加」される。やりたくないはずなんだ。特にファンクションポイント法で生産性を計測しているところは。
というのは、ファンクションポイント法（以下「ＦＰ法」と略記。ここが詳しいです）では基本的に「内部ファイル」「外部ファイル」「入力」「出力」「検索」というものすごく単純な要素で機能を測ってしまうからだ。それは難しさによる調整はある。が「出力の数」だけを見るとエラーメッセージが分かりやすかろうが（エラーの時はダイアログボックスが真っ赤）／分かりにくかろうが（標準ダイアログボックスが出る）、丁寧だろうが（どこの何が間違いと判断されたと表示される）／おざなりだろうが（一般保護違反）、変わらないわけだ。それはFP法が悪いのではなく適用が悪いと言われるかもしれない。が、ＦＰ法がエラーメッセージを分かりにくく・おざなりにしてゆく傾向を孕むことは否定されまい。
すると、今回の事件を教訓に「エラーメッセージがいやでも分かるようにシステム的に対処する」という要件が出た場合、ＦＰ法で測った生産性が低下してゆくのだ。当然「今までの生産性をキープしろ」という要望が出るだろうから、皆さん大変になる。と、ここまで来たところで先ほどの（システムＡ）を取り出す。 このつぎはぎのシステム、株式取引決裁ワークフローと株式注文システムをバラバラに作ったわけだが、ＦＰ法で測ると、決裁と注文がきちんとリンクしているシステムと規模は変わらないんじゃないだろうか。つまり、エラーメッセージ単独でも見えたことだけど「システムの使いやすさとＦＰは直結しない（作りやすさを考慮に入れると乖離する場合、使いにくさを助長する）」ということが言えるかもしれない。
なわけで、生産性を測ることを考えるとまたまた気が重くなるのでありました。（だから生産性を収入ないしテストケース数で測ろうと主張しているのだ。）いやね、ＦＰ法へのこの疑問、以前から感じていたのだわ。ほとんど同じ機能を持つシステムなのだけど、ユーザーの評判には格段の差があった（らしい）例があるから。画面遷移に原因があって、一つは目的の画面まで、階層をたどって降りてゆく作り。もう一つは[NEXT]のボタンを押すと、業務の流れに沿った次の画面が表示される作り。多分ＦＰ法で測った２つのシステムの規模は変わらないのだろうなあ。
ちなみに東証から「システム障害の再発防止策を作るので手伝ってくれ」という依頼は来ておりません。（証券アナリスト協会の会員名簿を見て、証券系システム開発／システム障害管理の経験者をピックアップすれば確実にヒットするのだが、そーゆーことはしないんだろうなあ。）