tonocchoのメモ

軽い気持ちで

みずほ銀行のシステム移行について思ったこと

www.itmedia.co.jp

もと金融系SEとして要注目なイベントがついにスケジュールされたなと言ったところで、ちょっと感じたことをつらつらと思いつくままに書いておこうかと思います。ちなみに何か根拠があるわけでも何でもない単なる妄想ですw

まず、移行の理由で書いちゃってるんだけど、「今も三行のシステムが動いている」という点ですね。どのレベルでの併存かによって移行の難易度が変わってくるはずです。

例えば、旧三行の勘定系と情報系が今もそのまま動いていて、それを何かフロントエンドを立ててみずほ形式に変換して使っている、というような場合、コレはやばい臭がします。

勘定系と情報系はすでに一本化されているのであれば「現行のシステムから預金などのデータを取り出し、次期システムに適合する形式に変換して転送する作業を行う。」ということは考えないような気がするのと、「預金などのデータ」は多分勘定系のことを指しているでしょうから、きっとこのへんはまだ一本化されてないんだろうなぁと思います(プレスリリースの移行先に勘定系と情報系って書いちゃってるので多分この形式でしょう)。

さて、みずほ銀行の三行統合のときになんで一本化システムにしなかったのか(平成14年の時点ならまだそこまで重たくなかったような気がする、制度的にも重要度的にも)、という点については大前健一氏も結構批判していた気がします。確か、銀行の統合はそもそも新システムを作ってそこに各銀行をインポートしていく方式でやるのがアメリカでは一般的なのになんでわざわざリスキーなことしたんだよ、とかそんな論調だった気がします。

www.mizuhobank.co.jp

ちなみにここに実際の支店ごとの具体的なスケジュールが乗っていますが、この支店の組み合わせが何らかのグルーピングになっているということでしょう。

全店舗で一斉に行うとトラブルが発生するリスクが懸念されるため、グループに分けて約1年かけて段階的に切り替える。

ということですね。このグルーピングがどういう根拠なのかも気になるところ

  • 三行まとめての移行方式で徐々に一度の移行店舗量を増やす
  • 旧第一勧銀とか、旧富士銀行とかの区切りで一行ずつやっていく
  • 単にランダム、または店番を一定の規則でグルーピング

三行同時並行でやっちゃうと障害切り分けが難しくなるので、おそらく一行ずつやるのではと思います。2〜8回目は銀行のシステム移行なので、全7回、旧第一勧銀3回、旧富士銀行2回、旧日本興業銀行2回とかそういうのじゃないかなとか思いますが、みずほ信託銀行のシステム移行1発勝負なのは結構おっかないなぁ。第一回目に2013年から稼働している業務基盤を移行する、というのがちと意味わかりませんね。

次に移行の方法です。

多分ですが、以下のようになるのではと思います。

まず背景として、現時点で新システムの勘定系、情報系はすでに何らかの方法で旧情報系、旧勘定系のクローンになっていると思います。そして、新システム自体も各支店からの接続を待っている状態だと思います。各支店が持っている預金データの中で、銀行本体の情報系、勘定系に転送されていないデータについてが移行時の勝負どころなのでは。それをどうやるかというと・・・という話です。たしかそういうデータの転送は、店じまいの作業の中でやってたかと思います。曖昧ですね。

  1. 支店のデータを新旧両方のシステムに一旦接続し、転送未遂のデータを両システムに転送して取り込みテストを行う
  2. うまく行ったら業務の基本的なワークフローを一通り試して業務遂行に問題がないことを確認する
  3. うまく行ったら新旧両システムに繋いだまま店舗運営をする(または新システムにのみ繋いでデータを旧システムにクローンしながら運営する)
  4. コレを全店舗完了するまで続ける
  5. 全店舗完了して一定期間業務上障害がなければ旧システムを切り離す(データは切り離し後もクローンされている可能性はある)
  6. 旧システムを切り離しても問題ないことが一定期間確認されたら旧システムは停止、破棄となる(旧システムのデータはすべてバックアップされて保管される可能性がある)

旧システムを温存するだろうな、と思う理由は、フォールバックの問題です。いきなりガチャっと切り替えちゃうと、旧システムのデータが歯抜けの状態になる(移行済み店舗と移行前店舗で)ので、いざフォールバックしようとしてもかんたんにはできなくなってしまいます。毎日何百万件とかのトランザクションが発生しているでしょうから、それを整合とってきっちり復旧する作業はできないと思います。まぁ、フォールバックした時点でみずほ銀行はかなり危うい立場になるでしょうけど。

旧システム(100%)ー>新旧(30%)旧(70%)ー>新旧(70%)旧(30%)ー>新旧(100%)ー>新システム(100%)

という流れのようなものと予想しています。

なんにしても、4000億円かけたプロジェクトでやろうとしていることが実は本来三行統合の時点でやっていてしかるべきだったし、みずほ銀行が始まった時点で旧三行のシステムはすべて移行されて無くなっていて然るべきだったこと、これらが2004年の時点でできなかったこととそれを14年の時を経て負債を片付けた、という点は誰かもっと突っ込んで書いて欲しいどころですね。三行統合で4000億円、今回の新システムで4000億円、結局最終的な統合に8000億円かけた、ということで銀行のシステム統合がいかに難しいものであるかがわかろうというものです。東京三菱とUFJの統合が2000億で済んだかと記憶していますが、2行が合併するのと、3行が合併するのは難易度が格段に跳ね上がるということですね。

tech.nikkeibp.co.jp

みずほ銀行さんにはぜひ頑張ってこの困難な作業を成功裏に終えていただければと思います。

ズンドコ問題に挑戦してみた

こんなのがなんかバズってたのでよーし力試しだ!と思って挑戦した。

で、こうなりました(超読みにくい)

public class きよしの {
    private int 下位5ビットマスク = 0x1F;
    private int ズンドコ成立 = 0x1E;

    public static void main(String[] args) {
        new きよしの().ズンドコ節();
    }

    private void ズンドコ節() {
        String[] zundoko = new String[] { "ドコ", "ズン" };
        int history = 0;
        while (true) {
            int index = (int) (Math.random() + 0.5);
            System.out.println(zundoko[index]);
            history = history * 2 + index;

            int last5bits = history & 下位5ビットマスク;
            if (last5bits == ズンドコ成立)
                break;
            history = last5bits;

        }
        System.out.println("きよし!");
    }
}

考え方としては、

0が来たらドコ、1が来たらズンとなりますが、それを2進数に見立てて変数に入れていきます。そのときに2倍して足すことで要は1と0の羅列になりますね。

で、最終5ビットが11110(0x1E)になったらズンズンズンズンドコなので終わってきよし!って出します。

ひたすら足しこんでもいいんだけど、ぶっちゃけ下位5ビット以外はどうでもいいのでそれ以上足しません。

コメントのいらないプログラムについてちょっと考えた

www.hassy-blog.com

はっしーさんはクライストチャーチでプログラマをされている方で別にコメント書いたら殺すマンというよりは今の環境がコメントを書かない文化になっているようで、コメントを書かない文何か他のもので担保しているような気はするのだけど、コメントについてちょっと書いてみようかと思います。すいませんがリーダブルコードとか読んだことないです。

まずアジャイルにおいてコメントは、というかドキュメンテーションは

アジャイル宣言では「動かないドキュメントより動くコードが大事だよね」というのがあって、ドキュメントに割くコストとコーディングに割くコストを天秤にかければ後者ですよね、というのがポイントです。なので、一時期流行った「語るコード」とか、「コードが設計書」という流れができたような気がします。

とはいえ自分の立場としては「コメントは必要」という立場ですが、「不要なコメント書くくらいならコード書いたほうがいい」という点や「ときとともにコードと乖離していくならむしろコメントは害悪」という立場でもあります。また「書いたコードはたしかに語っているけどハナモゲラ語じゃワカンネーからコメント書いとけ、な?」という人でもあります。

コメントを書く場合はどういうときか

さて、以前Log4Jのソースを追っかけてたとき(どんだけ前だよ)に以下のコメントがありました。

// Make Windows Happy

コレをやらないとWindowsで痛い目見るということのようで、このような環境に依存することは「なんでわざわざやってんの」ということを書く必要があると思います。

で、コレについては別にいいというか書くべきコメントなのですが、もう一点あるのは「契約書としてのコメント」です。DbCですね。

コメントが契約とは?

JavaではJavaDocを書く、ということがあります。最近の他の言語でもだいたいこの仕組みあると思いますが、なんでこういう機能があるかというと「これから書くコードはxxを満たすよ」ということの契約書(仕様書)を書いているわけです。

ということはJavaDocに対してテストを書いたり実装を書くという感覚が実は正しい気がしますね。仕様に対してコードをかけ、というアレです。

なんでコードに対してテストを書くのがうーん、かというと、「実装に対してテストを書けば実装を通すテストを書いてしまう」からです。TDDの世界ではまずテストを書く、というのが大事だけど、それより前に「これから書くコードは何をするの?」を明確にしなくてはなりません。で、この「明確にした何か」というのが仕様(コメント)でしょう。

もうちょっというと、仕様(コメント)がないなら「ソースを書いてテストも書いてカバレッジ100%、全ケース正常終了」というシチュエーションができたとしても、「その作ったものがそもそも正しいかの担保」をどこでするか、という問題が出てくると思います。

契約としてコメントを書くと変わることがある

例えばですが

// 2つの変数を足して代入する int sum = x + y;

というコメントは無意味です、というかコメントなしでもコレはわかってほしいところです。ですが以下のコードの場合はどうでしょうか。

public int add(int x, int y){ if ( x < y ) { throw new IllegalArgumentException("x < y");

ここでアプローチは2つあると思います。1つめはコメントを書かない方でifブロックをわかりやすい名前のメソッドで置き換える、2つ目はJavaDocかソース内のコメントにしっかりと書いておく。

1つ目のアプローチを採用するときの事情としては

  • 内部の開発者はみんなコードを見ることができるし、なぜそうするかの理由は別のドキュメントにすでに書かれている
  • 外部の開発者にはなんでIAEを投げるのかは何らかの事情で知ってほしくない、または別に外部に公開するものではない

ということかと思います。コードがシンプルすぎて混乱するかもですがそのへんは置いとくとしよう。

2つ目のアプローチは、APIの仕様をきちんと公開してブラックボックスとして使ってほしい場合かと思います。いちいち実装見なくてもコメント見れば全部書いてあるよ、という立場を取る、ということですね。また、書いてあることはすべてテスト済みであるということにもなるし、もし書いてあることと挙動が違えば誰が見てもバグとしてレポートできます。

この辺は結構主観的に「こういうことかな」くらいで書いてありますが、そのコード自体に対するステークホルダーが誰、という点次第でコメントを書く是非や書く場所というのも変わってくると思います。

コメントとコードとテストのアレなアレ

ちょっとしたポイントとしてでなく、仕様としてコメントをソース内に書いてしまうと、コメントのメンテを誰がやるの、という問題が出てきます。仕様を書く人が必ずしもソースコードを編集するとは限りません。むしろWikiとかに書いておいて仕様の記述内容を変える副作用を抑えるという方策を取る場合もあるかもしれません。または、きちんとしたライターにコメントを書いてもらうところもあるかもしれません。

そう考えるとプログラマがコメントを書く、という作業が必須かどうかというポイントはありそうです。

例えば依存するライブラリやサーバーのバグに対するワークアラウンドなんかはソースに書いてあったほうが便利だなとは思いますが。

あとは、テスターがやるテスト(結合テスト)で出たバグがすべて、という環境でもまたコメントの扱いは変わりそうです。

そういうわけで、コメントは必須だろうという人も多いかと思いますが、「どういうコメントがどういう扱いをされるべきか」というのは議論があっても楽しそうですね。

日本ではブロックチェーンvs全銀システムが巻き起こるかもしれない

もしくは次期全銀システムがブロックチェーンに対応かもしれない?完全に妄想の垂れ流しです。

最近、少し興味本位でブロックチェーンについていろいろと読んでいるのだけど、トランザクションシステムが中央集権(メインフレームの勘定系に全部保存する)から、分散管理になるというようなことと理解しました。

これの効果としては、送金処理をはじめとしたトランザクションのリアルタイム性が向上するということのようです。ただ、日本では銀行間送金については全銀システムというのが稼働しており、これもまたリアルタイムをサポートしているような気がします。

www.zengin-net.jp

で、この技術は、かなりブロックチェーンとぶつかるのですが、もう半世紀以上アップデートしながら動いているので、結構寿命を超えてる感ある気がします。ちなみに、いまだに他行への送金が翌営業日になるとか、その時にカタカナしか指定できないのも全銀のせいです。

このシステム、何がいいかというと、金融庁が国内のお金の流れをすべて把握できるという点にあったりすると思います。最近は全銀に対応しない金融機関もあるようですが、日本の銀行はかなり金融庁に牛耳られている気がします。

ブロックチェーンは、低コスト、かつ高速に送金処理がおこなえるわけで、金融としてはかなり魅力的かと思いますし、仮想通貨というこれまでの政府主導のものではない通貨なので、国際送金もかなり柔軟に行えそうです。となると、日本のメガバンクが金余りで投資先がない、という問題もメガバンクが仮想通貨にしてブロックチェーンすれば、海外投資もかなり積極的に行えるということのような気もします。

www.sankei.com

現在メガバンクがお金が余って仕方ないというのは日銀の政策が行けていないこともあるような気がします(どんどん日本円を発行して国債を銀行に買わせているので)が、それ以上に現行の海外送金処理が非常に重たいので、国外に送金することがとにかくつらみしかないのだということもありそうです。

海外送金しようとしたときのつらみについてはそのうち書くかもしれませんが、それはまたの機会に・・・

そんなわけですので、投資をしたい人々にとってはある意味キラーコンテンツのブロックチェーンですが、お金をあまり海外に流してほしくない行政と利害が一致しないのではないかと思っているので、国内金融機関は全銀をとるかブロックチェーンをとるか(そして全銀が廃墟と化すか法整備でブロックチェーンを追い出すか位の争いになる)というようになっていくような気がします。

Rでよくわからないこと

こんにちは、最近課題でRを使っているんですが、どうしてもなんでそうなるのかわからないのがあるので書いてみます。

key <- c("A", "B")
val <- c("C", "D")

df <- data.frame(KEY=key, VAL=val)

df[df$KEY=="A", ]$VAL <- "A"
print(df)

これですが、結果は以下のようになります。

  KEY  VAL
1  A  <NA>
2   B    D

どうしてこうなるのかがさっぱりわかりません。

引用文献の管理できてる?Zoteroで楽々引用生活のススメ!

という感じでいきなりSEOを意識したようなタイトルにしたのはほんのご愛嬌です。確かこんな感じだよね。

今、英語でレポートを書いています。色々と不安があるんですが、その中で「いちいちリファレンス書くのかったるいしあんまり参照したくないなぁ」というのがあります。これ結構大きいと思います。引用をした後に、どこから引用したかを記載するんですが、その書き方にルールがあって、これがいちいち覚えるのめんどくさいんですよね。

手書きでやっていると

と言っても、何も参照しないレポートなんて、お前の魂のポエム以上の価値もないので、嫌々ながら引用をするんですけど、参考文献をPDFで保存するとどこの何番目の資料だっけな、とか、おんなじ資料何回も参照してたとか、そういうのが結構あります。自分もリファレンスを落ち着いてみたら、2ペアありました。フルハウス目前でした。

出会いは突然

リファレンスのあまりのめんどくささに学生センターにあるフリーセミナーで何かいいのないかなーという感じでぼーっとスケジュールを見ていたら、「Zoteroでリファレンス管理」というのが目に入りました。Zotero?と思ってググったら、リファレンス管理のツールでした。これは今の自分に刺さるツールだと思って、急遽インストールして使ってみました。

インストールは簡単

brew cask install Zotero

または、公式サイトから落としてください。そもそもbrewで入らないなら入れるのやめようと思ってたんですけどね。

インストール完了後に起動すると、各種オフィスツール(見た感じ、MS Office、Open Office、Libre Officeなんかの主要なものはサポートされてるぽいですね)へのアドオンがインストールされます。次に、ブラウザへのアドオンもインストールします。今回はSafarideやっています。

その辺をだーっと入れたらおしまいです。

資料収集

Zoteroを起動した状態でやります。

ブラウザへのプラグインがインストールされると、Zoteroのアイコンがアドレスバーの横に表示されます。

f:id:s-tonouchi:20170402181203p:plain

このアイコンがZの場合は何もできないんですが、例えば何か適当な論文を検索して見ます。

f:id:s-tonouchi:20170402181344p:plain

アドレスバーの横のzマークが何か変わりました。そしたらこのアイコンをクリックします、すると画面右下にこんなんが表示されます。

f:id:s-tonouchi:20170402181446p:plain

これでZoteroに論文の各種情報やPDFなんかが保存されます。Zoteroにもこんな風に表示されます。

f:id:s-tonouchi:20170402181623p:plain

これを好きなだけ繰り返します。ちなみに、PDFなんかは環境によってはダウンロードできませんのでご注意を。

引用の仕方

では、引用の仕方です。Ms Wordを使ってやって見ます。まず、Zoteroのツールはアドインにあります。

f:id:s-tonouchi:20170402182152p:plain

引用するときは、以下のアイコンを使います。

f:id:s-tonouchi:20170402182257p:plain

クリックすると、引用のスタイルを確認されます。これは後でも変更可能みたいです。とりあえずIEEEを洗濯しました。この引用のスタイルは、レポートごとに指定があると思いますので、それに応じて選択しましょう。

f:id:s-tonouchi:20170402182345p:plain

検索窓が出ますので、検索して、引用した文書を選択してEnter押します。クリックでもいいのかしら

f:id:s-tonouchi:20170402182531p:plain

すると、カーソル位置に引用番号が出ます。ちなみに検索が使いづらい場合はクラシック検索でもいいでしょう。検索窓のZをクリックするとメニューが出ます。

f:id:s-tonouchi:20170402182703p:plain

で、引用した論文の一覧を作るにはこのアイコン

f:id:s-tonouchi:20170402182912p:plain

クリックすると一発でこんなんが挿入されます。

f:id:s-tonouchi:20170402183020p:plain

Zoteroでリファレンスの悩みにさよなら!

そういうわけで、いかにZoteroを使うと参考文献の引用が楽になるかがお分かりいただけたかと思います。ただ、引用は適切な量にしましょうね!

あと、Zotero的にはなんでも管理できるという風に歌ってはいるものの、できないものもチラホラでした。多分メタ情報がきちんと管理できてないとかその辺かもしれませんね。おしまい。

英語レポートのルールで見出したテーマの決め方

とかそれっぽいこと書くんですけど、やっと英文レポートが本番をかける感じになったので、ここまで感じたことを共有します。ちなみに、学校でそういうことをやっているお歴々はそんなん当然だろ、とか、アラフォーのおっさんが今更何言ってんのwwwwwとかそういうのやめてください。ココロが折れるので。

続きを読む