今,ＳＥＳ（っぽい請負、委任、派遣）市場を調べています。
その手の話といえばＪＩＥＴ，大型案件は「みずほ次期勘定系」ですよね！
っていうことで、「みずほ次期勘定系」を調べたいんだけど、
２ちゃんねるしか出てこない・・・
たとえば
みずほ銀行次期システム開発を見守るスレ16◆ [転載禁止]
http://hello.2ch.net/test/read.cgi/infosys/1440260984/
とか。
でも、そこに書かれていることが、本当だとすれば
（たぶん、わかっていない人が、テキトーに書いている部分も多い
と思うけど、もし、かりに本当だとしたら）
日経ＢＰさん、ＮＨＫさん、取材に行ったほうがいいですよ！
スクープです。はい。これ、やばいです・・・
どれくらいやばいか、上記２ちゃんに書かれている内容に答えながら
説明する
■なぜ、JavaとCOBOLが採用されることが多いのか？
このシステムに限らず、金融系はJavaとCOBOLが採用されることが多い。
なぜか？これは、金融系のシステムで求められる要求からきている。
【COBOLが採用されるわけ】
金融系では、
・金額を間違えては困る。そしてものすごく大きな数字を扱ったり、
ものすごく細かい数字を乗じたりする
（例：１兆円２３４５億６７８９万０１２３円に
金利0.023％を乗じ、円未満を切り捨てる）
そして、「有効桁数を絶対保証してほしい」という要請がある
・法律では、乗じたり、割ったりする順序が決まっている。
例：１ヶ月分の給与を出し、百円以下を切り捨て、１２倍したものを１年の収入とする
→３か月で１００万円もらっている人
順番を変えられては困る：最適化しないでほしい。
できれば、計算順序が明確にわかるように記述できてほしい
・夜間バッチの突き抜けは許されない！！！
したがって、処理を起動したときに、必要な容量は確保し、
処理スピードが予測可能であってほしい。
この要請、とくに最後の要請を満たすには、ダイナミックにメモリを
取る言語は使えない
（ダイナミックにメモリをとってしまうと、処理中にメモリ不足になったり、
処理スピードが（スラッシング、ガベージコレクションなどで）落ちるので
処理スピードが予測不能となり、最悪夜間バッチ突き抜けになる）
ＣＯＢＯＬは、メモリを動的にとらない。
そこで、とくにＪＣＬを使って動かす場合、はじめに資源をとり、それが
確保できれば、（ガベージコレクションが起こらないので）ある程度
いつも同じスピードで処理できる。
その上、有効桁数は、コンパイラの手引書に明示してあるし、
掛け算、割り算を明示して書きたければ、ＣＯＭPUTE命令をつかわず、
１つ１つ足し算なら Ａｄｄ なんとか Ｔｏ なんとか とか
いちいち記述すれば、計算順番を明示して記述できる。
ということで、すべての要請にCOBOLはあっている。なので、ＣＯＢＯＬを
とくに夜間バッチでは使いたいと思う。
【Javaが採用されるわけ】
では、COBOLだけを使えばよいかというと、そうはいかない。
画面がある場合、COBOLでは柔軟な処理ができない。
たとえば、セッションの中に入るものは、
半構造化された非定形なデータであり、自分の処理に
関係ないものもある。
このようなものを、Data Divisionで定義するのは、難しい。
ＣＯＢＯＬは、構造化されたデータを、定形的に処理するのに向いている
（金融業はＧＵＩ以外、こういう業務が多い）
そこで、画面周り、通信回りの半構造化された非定形なデータを
扱いやすい言語が必要になる。これにはＪａｖａが向いている。
他のＷｅｂで使われる言語、たとえばＰＨＰ，Ｒｕｂｙ、Javascript
などは、型推論を行ってしまう。
１＋１＝１１なんていうのは論外としても、加減乗除の有効桁数、
優先順位などがはっきりしない言語は扱いにくい。
そういう点で、Ｊａｖaは、型があるし、最適化もコンパイルオプション
とかでカバーできそう？だし・・・という点でＪａｖa
【ただし、これは一般論で】
みずほの今回の場合、Javaになったのは、人の集めやすさだと思う。
人の集めやすさだと、ＰＨＰのほうが、安くていいけど、
ＰＨＰにしなかった理由は、上記のように技術的に考えたんならいいけど、
中間搾取のしにくさ
（もともと単価安いことがわかっているＰＨＰは中間搾取しにくい）
だとしたら、浮かばれないね・・・
まあ、技術的には上のような理由があるので、けがの功名ではある。
むしろ、Ｊａｖａ一択でなく、一部ＣＯＢＯＬになったことに
良心を感じる。
■ＪａｖａとＣＯＢＯＬの連携の難しさ
ということで、ＪａｖａとＣＯＢＯＬ両方使うとなると、
連携させないといけない。
連携させるには、
PIC 9（数字項目）とPIC X(英数字項目）のint,Stringへの
置き換え以上の問題がある。
【問題１】
Packed Decimalとか、数字を変わった持ち方をしたり、
同じ03句を書いて再定義（redefine =CのUnion)することが、
ＣＯＢＯＬは、できる。
これを、Ｊａｖａでどう変換するか・・・は、いろいろ考えないといけない
【問題２】
COBOLの場合、なにもセットしないと、メモリー上にのこっているデータの値が
そのままだされる。つまり、それを印字してしまうとゴミが出力される。
(FILLERで、使わない項目でも）
そこで、これを防ぐために、集団項目にスペースを送る。
こうすると、数字項目でも（０でなく）スペースがおくれ、きれいに出力できる
（もしかすると、自分の使っていた（富士通）ＭＳＰ，ＦＳＰ，ＣＳＰだけの仕様かも？）
Ｊａｖａでこれを変換したら、もちろん、数字項目にスペースだから、
例外になってしまう。
しかし、集団項目にスペースを送るのは、動的な処理なので、
動かしてみないとわからない。
まあ、こんなことで「なんだあ かんだあ あり」、意外と変換は難しい。
基本的には、ＣＯＢＯＬ側で操作するのはたいへんなので、ＣＯＢＯＬ側は
単純に情報をセットし、Ｊａｖａ側で適宜変換してがんばるしかないのかなあ・・
■ノンプログラミングツール
富士通のInterDevelopを使っているみたいだけど、ノンプログラミングツール
（超高速開発ツール）は、バズーカ砲みたいなもんで、目的地に正しく打てば
効果大だけど、まちがって、自分に向けて打っちゃったりすると、悲惨な結果になる。
ピストルで撃つよりも・・・
現在のノンプログラミングツールは、設計書を必要とするが、要求段階、
設計段階で間違っている場合、ごみソースコードを急激に作ってしまう。
そして、それに対応した単体テストを作られた場合、単体テストまで
一気に通るので、結合テストのときに、一気に問題が露呈し、収集つかなくなる。
ただ、まったくの見当違いを設計することは少ない。
（特殊ケースが抜けていたり、インターフェースミスが多い）
なので、部分的にコメントにしたりすると、通ることがある。
コメントにすること自体は、次のテストにすすめるために必要なこともあり
一概に問題とは言えない。しかし、いつかはコメントをはずし、テストしないと
いけないので、コメントにして通して、あとでやるということを忘れてしまうと
問題になる。
さらに問題なのは、忘れたのでなく、進捗上、故意にコメント入れて通した
ことが報告されていないとすると、大問題で、あとで事件になる。
なので、ノンプログラミングツールは生産性は高いかもしれないが、
「だから大丈夫」ということにはならない。なお、ノンプログラミングツール
自体のバージョン管理の問題とかあって、必ずしも生産性が高くなるとは限らないかも・・
■レビューしてもバグになる理由
上述のように結合テストでバグになる場合は、インターフェース等の問題が多く、
これは、特殊ケースのテスト項目を削ると、一見バグが減ってくるように見える。
この結合テストは設計書で発生しているはずなので（Ｖ字モデルでは）
設計書のレビューを徹底すればなくなるかというと・・・なくならない。
レビューには３種類の方法がある（一般に言われるのは後者の２つ）
・ただのレビュー
文字の間違い、文章の間違い、コーディングルール間違いを指摘したり
自分の価値観を他人に押しつけたりする。
技術的に、あまり意味がない。
・ウォークスルー
データまたはプロセスの流れに従って、間違いがないかを確認する
機能仕様のチェックになり、結合テストのバグを減らせる
・インスペクション
ある専門的な観点（データ処理方法、ネットワーク通信方法、セキュリティなど）
からチェックをかける。
主に非機能仕様のチェックになり、総合テストのバグを減らす・・・とうれしいが、
主に、総合テストで問題が発生し、どうしようかというときに行う。
インスペクションは品質管理部が行うので、現場では、可読性の高いプログラムを
書いておいてくださいと言われることがある（私は言われた）。
なので、ウォークスルーをやるかやらないかが問題となるが、こういうことが必要
と知らない人が多いので、時間を取ってもらえない。結果、やらない。
そうすると、レビューしても、ただのレビューしかしていないと、結合でバグが
一気に出る。
■どこがやばいのか
前にＣＯＢＯＬを採用する理由は、処理時間が見えないからとか書いた。
で、Ｊａｖａを使っているとも書いた・・・
・・・ってことは、Ｊａｖａの処理時間は見えていない。
つまり、Ｊａｖａの部分は、ユーザーの処理能力要求（レスポンスタイム等）
をみたしているかどうかわからない。
これがわかるには、数理モデルを解くか、シミュレーションしないといけない。
しかし、シミュレーションなどを行うには、
通信を行う場合、インターフェース、つまりプロトコルと通信内容が
確定し、さらにその量が予測付かないといけない。
でも、これが完璧なら、結合テストは簡単に通るはず。
だけど、そうなっていない・・のなら、インターフェース部分に問題がある
可能性がある。ここがやばい！
つまり、やばい点は以下の２点（ただし、あくまでも２ちゃんねるからの推測で、
実際にはうまくいっていると・・・信じたい）
・プログラム間通信やインターフェースとなる引数の処理に関する
チェックが甘く、バグやあいまいな箇所が存在する可能性がある
→これを退治するウォークスルーのレビューも行われていない
・そのため、Ｊａｖａで、今の通信量、処理量で処理しきれるかどうか、
問題がないかなどの検証が行えない／行っていない
→総合テストでパフォーマンス不足を指定される危険性
■もし、この事態になっているとしたら、なぜ、そうなった。
「インターフェースを管理する責任者がいないから」という可能性が高い
みずほＩＲは・・・実際の設計は、ベンダー各社の責任だよね
ベンダー各社・・・とはいえ、１社ではきめられないので・・・
となると、責任者不在となる。この場合、ウォークスルーのレビューも行えない
あらかじめ、インターフェースの確認をとるウォークスルーのレビューは
当然のこと、万全を期すため、ＶＤＭによる（形式）仕様化と、データによるテスト
を行えば問題はないが、さすがにそこまでやる気は、なかったのであろう。
これを行わないと、とうぜん、Ｊａｖａでどうなるかというシミュレーションは
取れない。
■持ち直す方法
・現状を正しく把握する（本当にテストは消化できているのか？）
・インターフェースの部分のチェック
・シミュレーションなど
なお、これはあくまでも、２ちゃんねるの内容から妄想したものであり、
現実にこんなにひどい・・・ことはないよね（＾＾；）
その手の話といえばＪＩＥＴ，大型案件は「みずほ次期勘定系」ですよね！
っていうことで、「みずほ次期勘定系」を調べたいんだけど、
２ちゃんねるしか出てこない・・・
たとえば
みずほ銀行次期システム開発を見守るスレ16◆ [転載禁止]
http://hello.2ch.net/test/read.cgi/infosys/1440260984/
とか。
でも、そこに書かれていることが、本当だとすれば
（たぶん、わかっていない人が、テキトーに書いている部分も多い
と思うけど、もし、かりに本当だとしたら）
日経ＢＰさん、ＮＨＫさん、取材に行ったほうがいいですよ！
スクープです。はい。これ、やばいです・・・
どれくらいやばいか、上記２ちゃんに書かれている内容に答えながら
説明する
■なぜ、JavaとCOBOLが採用されることが多いのか？
このシステムに限らず、金融系はJavaとCOBOLが採用されることが多い。
なぜか？これは、金融系のシステムで求められる要求からきている。
【COBOLが採用されるわけ】
金融系では、
・金額を間違えては困る。そしてものすごく大きな数字を扱ったり、
ものすごく細かい数字を乗じたりする
（例：１兆円２３４５億６７８９万０１２３円に
金利0.023％を乗じ、円未満を切り捨てる）
そして、「有効桁数を絶対保証してほしい」という要請がある
・法律では、乗じたり、割ったりする順序が決まっている。
例：１ヶ月分の給与を出し、百円以下を切り捨て、１２倍したものを１年の収入とする
→３か月で１００万円もらっている人
順番を変えられては困る：最適化しないでほしい。
できれば、計算順序が明確にわかるように記述できてほしい
・夜間バッチの突き抜けは許されない！！！
したがって、処理を起動したときに、必要な容量は確保し、
処理スピードが予測可能であってほしい。
この要請、とくに最後の要請を満たすには、ダイナミックにメモリを
取る言語は使えない
（ダイナミックにメモリをとってしまうと、処理中にメモリ不足になったり、
処理スピードが（スラッシング、ガベージコレクションなどで）落ちるので
処理スピードが予測不能となり、最悪夜間バッチ突き抜けになる）
ＣＯＢＯＬは、メモリを動的にとらない。
そこで、とくにＪＣＬを使って動かす場合、はじめに資源をとり、それが
確保できれば、（ガベージコレクションが起こらないので）ある程度
いつも同じスピードで処理できる。
その上、有効桁数は、コンパイラの手引書に明示してあるし、
掛け算、割り算を明示して書きたければ、ＣＯＭPUTE命令をつかわず、
１つ１つ足し算なら Ａｄｄ なんとか Ｔｏ なんとか とか
いちいち記述すれば、計算順番を明示して記述できる。
ということで、すべての要請にCOBOLはあっている。なので、ＣＯＢＯＬを
とくに夜間バッチでは使いたいと思う。
【Javaが採用されるわけ】
では、COBOLだけを使えばよいかというと、そうはいかない。
画面がある場合、COBOLでは柔軟な処理ができない。
たとえば、セッションの中に入るものは、
半構造化された非定形なデータであり、自分の処理に
関係ないものもある。
このようなものを、Data Divisionで定義するのは、難しい。
ＣＯＢＯＬは、構造化されたデータを、定形的に処理するのに向いている
（金融業はＧＵＩ以外、こういう業務が多い）
そこで、画面周り、通信回りの半構造化された非定形なデータを
扱いやすい言語が必要になる。これにはＪａｖａが向いている。
他のＷｅｂで使われる言語、たとえばＰＨＰ，Ｒｕｂｙ、Javascript
などは、型推論を行ってしまう。
１＋１＝１１なんていうのは論外としても、加減乗除の有効桁数、
優先順位などがはっきりしない言語は扱いにくい。
そういう点で、Ｊａｖaは、型があるし、最適化もコンパイルオプション
とかでカバーできそう？だし・・・という点でＪａｖa
【ただし、これは一般論で】
みずほの今回の場合、Javaになったのは、人の集めやすさだと思う。
人の集めやすさだと、ＰＨＰのほうが、安くていいけど、
ＰＨＰにしなかった理由は、上記のように技術的に考えたんならいいけど、
中間搾取のしにくさ
（もともと単価安いことがわかっているＰＨＰは中間搾取しにくい）
だとしたら、浮かばれないね・・・
まあ、技術的には上のような理由があるので、けがの功名ではある。
むしろ、Ｊａｖａ一択でなく、一部ＣＯＢＯＬになったことに
良心を感じる。
■ＪａｖａとＣＯＢＯＬの連携の難しさ
ということで、ＪａｖａとＣＯＢＯＬ両方使うとなると、
連携させないといけない。
連携させるには、
PIC 9（数字項目）とPIC X(英数字項目）のint,Stringへの
置き換え以上の問題がある。
【問題１】
Packed Decimalとか、数字を変わった持ち方をしたり、
同じ03句を書いて再定義（redefine =CのUnion)することが、
ＣＯＢＯＬは、できる。
これを、Ｊａｖａでどう変換するか・・・は、いろいろ考えないといけない
【問題２】
COBOLの場合、なにもセットしないと、メモリー上にのこっているデータの値が
そのままだされる。つまり、それを印字してしまうとゴミが出力される。
(FILLERで、使わない項目でも）
そこで、これを防ぐために、集団項目にスペースを送る。
こうすると、数字項目でも（０でなく）スペースがおくれ、きれいに出力できる
（もしかすると、自分の使っていた（富士通）ＭＳＰ，ＦＳＰ，ＣＳＰだけの仕様かも？）
Ｊａｖａでこれを変換したら、もちろん、数字項目にスペースだから、
例外になってしまう。
しかし、集団項目にスペースを送るのは、動的な処理なので、
動かしてみないとわからない。
まあ、こんなことで「なんだあ かんだあ あり」、意外と変換は難しい。
基本的には、ＣＯＢＯＬ側で操作するのはたいへんなので、ＣＯＢＯＬ側は
単純に情報をセットし、Ｊａｖａ側で適宜変換してがんばるしかないのかなあ・・
■ノンプログラミングツール
富士通のInterDevelopを使っているみたいだけど、ノンプログラミングツール
（超高速開発ツール）は、バズーカ砲みたいなもんで、目的地に正しく打てば
効果大だけど、まちがって、自分に向けて打っちゃったりすると、悲惨な結果になる。
ピストルで撃つよりも・・・
現在のノンプログラミングツールは、設計書を必要とするが、要求段階、
設計段階で間違っている場合、ごみソースコードを急激に作ってしまう。
そして、それに対応した単体テストを作られた場合、単体テストまで
一気に通るので、結合テストのときに、一気に問題が露呈し、収集つかなくなる。
ただ、まったくの見当違いを設計することは少ない。
（特殊ケースが抜けていたり、インターフェースミスが多い）
なので、部分的にコメントにしたりすると、通ることがある。
コメントにすること自体は、次のテストにすすめるために必要なこともあり
一概に問題とは言えない。しかし、いつかはコメントをはずし、テストしないと
いけないので、コメントにして通して、あとでやるということを忘れてしまうと
問題になる。
さらに問題なのは、忘れたのでなく、進捗上、故意にコメント入れて通した
ことが報告されていないとすると、大問題で、あとで事件になる。
なので、ノンプログラミングツールは生産性は高いかもしれないが、
「だから大丈夫」ということにはならない。なお、ノンプログラミングツール
自体のバージョン管理の問題とかあって、必ずしも生産性が高くなるとは限らないかも・・
■レビューしてもバグになる理由
上述のように結合テストでバグになる場合は、インターフェース等の問題が多く、
これは、特殊ケースのテスト項目を削ると、一見バグが減ってくるように見える。
この結合テストは設計書で発生しているはずなので（Ｖ字モデルでは）
設計書のレビューを徹底すればなくなるかというと・・・なくならない。
レビューには３種類の方法がある（一般に言われるのは後者の２つ）
・ただのレビュー
文字の間違い、文章の間違い、コーディングルール間違いを指摘したり
自分の価値観を他人に押しつけたりする。
技術的に、あまり意味がない。
・ウォークスルー
データまたはプロセスの流れに従って、間違いがないかを確認する
機能仕様のチェックになり、結合テストのバグを減らせる
・インスペクション
ある専門的な観点（データ処理方法、ネットワーク通信方法、セキュリティなど）
からチェックをかける。
主に非機能仕様のチェックになり、総合テストのバグを減らす・・・とうれしいが、
主に、総合テストで問題が発生し、どうしようかというときに行う。
インスペクションは品質管理部が行うので、現場では、可読性の高いプログラムを
書いておいてくださいと言われることがある（私は言われた）。
なので、ウォークスルーをやるかやらないかが問題となるが、こういうことが必要
と知らない人が多いので、時間を取ってもらえない。結果、やらない。
そうすると、レビューしても、ただのレビューしかしていないと、結合でバグが
一気に出る。
■どこがやばいのか
前にＣＯＢＯＬを採用する理由は、処理時間が見えないからとか書いた。
で、Ｊａｖａを使っているとも書いた・・・
・・・ってことは、Ｊａｖａの処理時間は見えていない。
つまり、Ｊａｖａの部分は、ユーザーの処理能力要求（レスポンスタイム等）
をみたしているかどうかわからない。
これがわかるには、数理モデルを解くか、シミュレーションしないといけない。
しかし、シミュレーションなどを行うには、
通信を行う場合、インターフェース、つまりプロトコルと通信内容が
確定し、さらにその量が予測付かないといけない。
でも、これが完璧なら、結合テストは簡単に通るはず。
だけど、そうなっていない・・のなら、インターフェース部分に問題がある
可能性がある。ここがやばい！
つまり、やばい点は以下の２点（ただし、あくまでも２ちゃんねるからの推測で、
実際にはうまくいっていると・・・信じたい）
・プログラム間通信やインターフェースとなる引数の処理に関する
チェックが甘く、バグやあいまいな箇所が存在する可能性がある
→これを退治するウォークスルーのレビューも行われていない
・そのため、Ｊａｖａで、今の通信量、処理量で処理しきれるかどうか、
問題がないかなどの検証が行えない／行っていない
→総合テストでパフォーマンス不足を指定される危険性
■もし、この事態になっているとしたら、なぜ、そうなった。
「インターフェースを管理する責任者がいないから」という可能性が高い
みずほＩＲは・・・実際の設計は、ベンダー各社の責任だよね
ベンダー各社・・・とはいえ、１社ではきめられないので・・・
となると、責任者不在となる。この場合、ウォークスルーのレビューも行えない
あらかじめ、インターフェースの確認をとるウォークスルーのレビューは
当然のこと、万全を期すため、ＶＤＭによる（形式）仕様化と、データによるテスト
を行えば問題はないが、さすがにそこまでやる気は、なかったのであろう。
これを行わないと、とうぜん、Ｊａｖａでどうなるかというシミュレーションは
取れない。
■持ち直す方法
・現状を正しく把握する（本当にテストは消化できているのか？）
・インターフェースの部分のチェック
・シミュレーションなど
なお、これはあくまでも、２ちゃんねるの内容から妄想したものであり、
現実にこんなにひどい・・・ことはないよね（＾＾；）
アクセス
トータル
ランキング
