う～ん、ソフトウェア工学話を終わらそうとしたら、
日経コンピューター 2013年４月４日号 にこんな記事が
誤発注裁判が改めて問う
「バグは重過失か」
日経コンピューター 2013年４月４日号 ６８ページ～
これ、ツッコミどころ満載なんで、その中のいくつか
■この裁判を整理してみる
この裁判は、
・みずほ証券が誤発注をした。
・誤発注したときに、取り消しをしたが、取り消せなかった
→もし取り消せなかったら、
ふつうは、買いで失敗したら売り、売りで失敗したら買いと
反対取引を自らして、相殺すると思うけどが、反対取引は、
たしかかなり遅れてしたはず。
・取り消せないのは、富士通がばぐったから
・だから、「東証に責任がある」？
→謝罪と賠償をせよ
つまり、まとめると
みずほ証券←裁判→東証←受け入れ：開発→富士通
■そもそもソフトウェア工学的に見ると、顧客にソースコード
を開示させること自体、おかしい。
まず、ソフトウェア工学的に考えると、東証は、発注もとの顧客
の立場であり、ソフトウェア工学の教科書、たしかPfleegerさんの本
の日本語訳版にもあったと思うけど、顧客は、受け入れテストを
すればいいことになっている。
その際、ソースコードや詳細設計はわからなくてよい。
たとえば、アメリカの掃除機を、日本の量販店が買い、その日本の
量販店がある人Ａさんに売って、Ａさんが怪我したとする。
Ａさんは、量販店を訴えたとする。ここまではＯＫ！
でも、Ａさんは、掃除機のプログラムミスで怪我したからといって、
機密事項も含んでいるアメリカの掃除機のプログラムの開示請求をしたり、
量販店が、プログラムのチェックをしていないということを訴えるのは、
おかしいでしょ（＾＾；）
量販店が調べることは、ちゃんと動作するか、安全かということを、
「掃除機を元に」しらべる。つまりソフトウェア工学的に言えば、
量販店はブラックボックステストを行うのであって、
ソースコードを見るホワイトボックステストを刷る必要はない。
なので、ソースを開示する必要はない。
もし、ソースを開示する必要があるとすると、
日本に輸出する場合は、すべて、ソースコードを開示し、ドキュメントも
開示しなければならないという制約が付くことになる。
ソースコードには企業機密もあるので、これは、一般に大きな制約になる
というか、これは、まさに中国が求めた
中国、デジタル家電ソースコード強制開示強行へ
http://www.excite.co.jp/News/net_clm/20090424/Slashdot_09_04_24_0115201.html
となんら変わらない。これが問題になったことは、みんなも
覚えているだろう。
顧客が、ソースコードを開示しなければならないとしたら、
このように、日本が中国化することになり、日本の産業は終わるだろう。
はっきりいう、世界のソフトウェア工学は、そんなことを求めていない。
顧客の受け入れ検査はブラックボックステストが前提だ。
■みずほ証券の主張は、無理筋ではないのか？
６８ページにみずほ証券の主張があるが、本当にこの主張なら、ちょっと
無理筋な気がする・・
みずほ証券の主張
１．たとえば自動車事故が一定の確率で起こるとして、
そのことを理由に「事故を起こした運転手に過失がない
と判断されることはないはずだ」
今回の東証の事故は、事故を起こした原因が東証にあるのではなく、
富士通のバグであるという論拠になっている。
したがって、上記のたとえで言うと、
たとえば、某社の自動車は、リコールが多く、事故も一定の確率で起こしている。
そのとき、事故を起こした運転手は普通のオペレーションをしていて、
たまたま「歩行者の不注意」（＝みずほ証券の誤発注）で、
自動車のリコールすべき案件（＝富士通のバグ）あったために、
運転手（東証）が事故を冒したとき、
確かに運転手は事故を起こしたので、過失はあるかもしれない。
しかし、運転手は、リコール案件を知らなくて、普通は当然じゃないか？
リコール案件をしらなかったから、重過失になるのか？
え～、そしたら、リコール案件で自動車事故を起こした人は、
何も知らない間に、重過失かい！
おかしいだろ。。。この論拠
２．バグは容易に発見できた
→これは、あとで論じる。無理筋だ。
３．ソースコードの変更を設計書に反映するのは当然だ
今、議論しているのは、バグの問題。
「ソースコードの変更を設計書に反映」しない場合、
かならず（ないしはかなりの確率で）、このバグを生じるというのを論証しない限り、
「ソースコードの変更を設計書に反映」しないことを理由に
バグを生じる責任は問えない。
ところが、発生順序を考えると、
「修正依頼」→「設計書に反映」→「修正」
という工程なら、たしかに設計書に反映しないと、修正ミスが起こるだろうが、
「修正依頼」→「修正」→「設計書に反映」
という工程をとっている場合、「設計書に反映」しなかったから、「修正」ミスしたとは言えない。
なので、この状況から、かならずバグを生じるという論証は難しいはず。
ということで、みずほ証券側のロジックは、論理飛躍があり、無理筋。
東証のブロックが甘いから、議論が成立しているだけではないのか？
■バグは、後講釈でいうなら、みんな簡単。
アメリカでもFORTRANのプログラムで、ピリオドとカンマを打ち間違えて失敗したプロジェクトがありました。
という話を、
FORTRANのDO文と落ちたロケットのfolklore
で議論している。ここであるように、カンマとピリオド、ハイフンですら、間違える。
テストしてたら、見つかっただろうにね・・・
机上デバッグで気づくだろう・・・
後講釈なら、何でもいえるよね。
でも、見つからない・・・ってことは、現場の人なら知っているはず。
いや、ＮＡＳＡですら、みつからないんだぜ！
それと比べると、実は、今回のテストは、ちょっと（いやかなり）難しい。
ばぐった理由は７２ページに図入りである。
ＩＦ文で分岐しているのだが、その前に「条件が成立しない」というもの。
では、このテストを考えるよ
・単体テスト
網羅率を１００％にするには、すべてのＩＦ文を通す必要がある。
そこで、デバッガで、ＩＦ文の前に、会員ＮＯなどに対して値を設定してしまった場合、
２、３の条件とも（値をいれて）チェックする→ＯＫとなるので、ここでは見つからない
・結合テスト
１の部分でかならずセロクリアされるのが「問題と気づくためには」
どのくらいのテストケースが必要なのか、が書かれていない
なので、どのくらいのテストケースを挙げないと、この状況に気づかないのか、わからない
３は、約定した状態。２は部分約定の状態。
部分約定のすべてが間違えていた・・ってなったら、部分約定しないはずだけど、
たぶん、部分約定って、するよねえ・・たまに。。。
っていうことは、単純な部分約定ではなく、かなり込み入ったケースにおける
部分約定と考えられる。そのテストケースを導出するのに、どれくらいかかるか・・
そして、組み合わせチェックだから、直交表などを使った場合、この条件が
確実にチェックできるのか・・・
ね、簡単な議論ではないのよ・・・
・システムテスト・統合テスト
普段、東証で問題は起きていない。
っていうことは、これはまれなケースと考えられる。
ってことは、「簡単に見つかる」重過失のケースとはいえない。
約定できないとかいうのなら、重過失だろうけど、部分約定は簡単なケースじゃないし、
それも、今回の場合は、普通にあるケースじゃない（普通は値幅制限があるから）
もちろん、そのケースもやっておくべきだけど、それを忘れたから、重過失・・かあ？
・受け入れテスト
システムテスト、統合テストと同レベルのテストをするばずなので、
上記と同じ議論になる。
ってことで、「ゼロクリア済み」というのを見つけなきゃいけないので、
単純なテストではないのだ・・・
■ソースコード修正からドキュメント等を自動生成するのが、
ソフトウェア工学の流れのはずでは？
そして、極めつけの議論は、
７２ページ２段目から、３段目の議論
「システムを保守する者は、ドキュメントを見ないというのだろうか。
ソースコードだけが頼りというのでは、ソフトウェア工学が長年にわたってきた知見を
すべて無視することになる」
まず、ソフトウェア工学は、流行があり、長年にわたった知見でも、
流行ってないと無視される（＾＾；）
例えば、いま、ＣＯＢＯＬの研究してる人少ないと思うよ・・
ま、そこはさておき、今の流れは、ソースコードからの自動化。
つまり、ソースコードからドキュメントやその他の可視化できるものを自動的に作り出すのが主流
なので、ドキュメントを見るだろうけど、それをソースコードを頼りに作るのが、
今の流行かな。
典型例がＪａｖａＤｏｃだよね。納品物になっているけど、あれ、ソースコードから作ってる。
ＥＲ図も、ＤＢから自動生成させてたりするし・・
もし、
「ドキュメントは作らなければならない・判りきった詳細設計書でも、
自動化せずに・・・」
とか言ったら、アジリティはなくなってしまう。
アジャイル終了のお知らせになる。。。
裁判所と日経コンピューターがアジャイルを終了させる？
そもそも、アジャイルでやる場合、チケット駆動開発を導入すれば、
（１）修正要望のチケットを発行する
（２）修正者がソース修正してコミットする
→ここで差分は取れる
（３）チケットに修正箇所を書く
→もちろん、これは（２）から自動化してもいい。
とすれば、修正ドキュメントをわざわざ作らなくても、修正箇所と修正内容がわかり、
保守できる。一般の人から見ると、これこそまさに、ソフトウェア工学！
■でもね・・・
なんだけど、アカデミックな世界では、ソフトウェア工学上で、チケット駆動開発は浸透していない
情報学広場で、
チケット駆動開発を引くと、８件
TiDDとひくと、３件
Redmineで引くと２９件
IEEE Xploreで
Ticket Driven Developmentをひくと７件
（ＴｉＤＤはどうも、違う意味になるらしい）
Redmineで２件
ということで、当然ながらTiDDは、日本で進んでいるけど、今一歩なのだ・・
なので、上記開発スタイルが、TiDDな人では一般的ではあるけれど、
学会ではまだ認識されず、ドキュメントを（手作業で？）修正なんていう
議論が成立してしまうわけだ。
現場の人から見ると、かなり変な論拠で、みずほ証券も東証も闘っているんだけど、
意見書を出しているソフトウェア工学の専門家は、たぶん大学の先生なので、
大学の先生で今の現場の感覚と近いのは、鷲崎先生のところとか、西先生のところとか
極わずか・・
となると、こういう判らん議論になってしまうわけだ・・
日経コンピューター 2013年４月４日号 にこんな記事が
誤発注裁判が改めて問う
「バグは重過失か」
日経コンピューター 2013年４月４日号 ６８ページ～
これ、ツッコミどころ満載なんで、その中のいくつか
■この裁判を整理してみる
この裁判は、
・みずほ証券が誤発注をした。
・誤発注したときに、取り消しをしたが、取り消せなかった
→もし取り消せなかったら、
ふつうは、買いで失敗したら売り、売りで失敗したら買いと
反対取引を自らして、相殺すると思うけどが、反対取引は、
たしかかなり遅れてしたはず。
・取り消せないのは、富士通がばぐったから
・だから、「東証に責任がある」？
→謝罪と賠償をせよ
つまり、まとめると
みずほ証券←裁判→東証←受け入れ：開発→富士通
■そもそもソフトウェア工学的に見ると、顧客にソースコード
を開示させること自体、おかしい。
まず、ソフトウェア工学的に考えると、東証は、発注もとの顧客
の立場であり、ソフトウェア工学の教科書、たしかPfleegerさんの本
の日本語訳版にもあったと思うけど、顧客は、受け入れテストを
すればいいことになっている。
その際、ソースコードや詳細設計はわからなくてよい。
たとえば、アメリカの掃除機を、日本の量販店が買い、その日本の
量販店がある人Ａさんに売って、Ａさんが怪我したとする。
Ａさんは、量販店を訴えたとする。ここまではＯＫ！
でも、Ａさんは、掃除機のプログラムミスで怪我したからといって、
機密事項も含んでいるアメリカの掃除機のプログラムの開示請求をしたり、
量販店が、プログラムのチェックをしていないということを訴えるのは、
おかしいでしょ（＾＾；）
量販店が調べることは、ちゃんと動作するか、安全かということを、
「掃除機を元に」しらべる。つまりソフトウェア工学的に言えば、
量販店はブラックボックステストを行うのであって、
ソースコードを見るホワイトボックステストを刷る必要はない。
なので、ソースを開示する必要はない。
もし、ソースを開示する必要があるとすると、
日本に輸出する場合は、すべて、ソースコードを開示し、ドキュメントも
開示しなければならないという制約が付くことになる。
ソースコードには企業機密もあるので、これは、一般に大きな制約になる
というか、これは、まさに中国が求めた
中国、デジタル家電ソースコード強制開示強行へ
http://www.excite.co.jp/News/net_clm/20090424/Slashdot_09_04_24_0115201.html
となんら変わらない。これが問題になったことは、みんなも
覚えているだろう。
顧客が、ソースコードを開示しなければならないとしたら、
このように、日本が中国化することになり、日本の産業は終わるだろう。
はっきりいう、世界のソフトウェア工学は、そんなことを求めていない。
顧客の受け入れ検査はブラックボックステストが前提だ。
■みずほ証券の主張は、無理筋ではないのか？
６８ページにみずほ証券の主張があるが、本当にこの主張なら、ちょっと
無理筋な気がする・・
みずほ証券の主張
１．たとえば自動車事故が一定の確率で起こるとして、
そのことを理由に「事故を起こした運転手に過失がない
と判断されることはないはずだ」
今回の東証の事故は、事故を起こした原因が東証にあるのではなく、
富士通のバグであるという論拠になっている。
したがって、上記のたとえで言うと、
たとえば、某社の自動車は、リコールが多く、事故も一定の確率で起こしている。
そのとき、事故を起こした運転手は普通のオペレーションをしていて、
たまたま「歩行者の不注意」（＝みずほ証券の誤発注）で、
自動車のリコールすべき案件（＝富士通のバグ）あったために、
運転手（東証）が事故を冒したとき、
確かに運転手は事故を起こしたので、過失はあるかもしれない。
しかし、運転手は、リコール案件を知らなくて、普通は当然じゃないか？
リコール案件をしらなかったから、重過失になるのか？
え～、そしたら、リコール案件で自動車事故を起こした人は、
何も知らない間に、重過失かい！
おかしいだろ。。。この論拠
２．バグは容易に発見できた
→これは、あとで論じる。無理筋だ。
３．ソースコードの変更を設計書に反映するのは当然だ
今、議論しているのは、バグの問題。
「ソースコードの変更を設計書に反映」しない場合、
かならず（ないしはかなりの確率で）、このバグを生じるというのを論証しない限り、
「ソースコードの変更を設計書に反映」しないことを理由に
バグを生じる責任は問えない。
ところが、発生順序を考えると、
「修正依頼」→「設計書に反映」→「修正」
という工程なら、たしかに設計書に反映しないと、修正ミスが起こるだろうが、
「修正依頼」→「修正」→「設計書に反映」
という工程をとっている場合、「設計書に反映」しなかったから、「修正」ミスしたとは言えない。
なので、この状況から、かならずバグを生じるという論証は難しいはず。
ということで、みずほ証券側のロジックは、論理飛躍があり、無理筋。
東証のブロックが甘いから、議論が成立しているだけではないのか？
■バグは、後講釈でいうなら、みんな簡単。
アメリカでもFORTRANのプログラムで、ピリオドとカンマを打ち間違えて失敗したプロジェクトがありました。
という話を、
FORTRANのDO文と落ちたロケットのfolklore
で議論している。ここであるように、カンマとピリオド、ハイフンですら、間違える。
テストしてたら、見つかっただろうにね・・・
机上デバッグで気づくだろう・・・
後講釈なら、何でもいえるよね。
でも、見つからない・・・ってことは、現場の人なら知っているはず。
いや、ＮＡＳＡですら、みつからないんだぜ！
それと比べると、実は、今回のテストは、ちょっと（いやかなり）難しい。
ばぐった理由は７２ページに図入りである。
ＩＦ文で分岐しているのだが、その前に「条件が成立しない」というもの。
では、このテストを考えるよ
・単体テスト
網羅率を１００％にするには、すべてのＩＦ文を通す必要がある。
そこで、デバッガで、ＩＦ文の前に、会員ＮＯなどに対して値を設定してしまった場合、
２、３の条件とも（値をいれて）チェックする→ＯＫとなるので、ここでは見つからない
・結合テスト
１の部分でかならずセロクリアされるのが「問題と気づくためには」
どのくらいのテストケースが必要なのか、が書かれていない
なので、どのくらいのテストケースを挙げないと、この状況に気づかないのか、わからない
３は、約定した状態。２は部分約定の状態。
部分約定のすべてが間違えていた・・ってなったら、部分約定しないはずだけど、
たぶん、部分約定って、するよねえ・・たまに。。。
っていうことは、単純な部分約定ではなく、かなり込み入ったケースにおける
部分約定と考えられる。そのテストケースを導出するのに、どれくらいかかるか・・
そして、組み合わせチェックだから、直交表などを使った場合、この条件が
確実にチェックできるのか・・・
ね、簡単な議論ではないのよ・・・
・システムテスト・統合テスト
普段、東証で問題は起きていない。
っていうことは、これはまれなケースと考えられる。
ってことは、「簡単に見つかる」重過失のケースとはいえない。
約定できないとかいうのなら、重過失だろうけど、部分約定は簡単なケースじゃないし、
それも、今回の場合は、普通にあるケースじゃない（普通は値幅制限があるから）
もちろん、そのケースもやっておくべきだけど、それを忘れたから、重過失・・かあ？
・受け入れテスト
システムテスト、統合テストと同レベルのテストをするばずなので、
上記と同じ議論になる。
ってことで、「ゼロクリア済み」というのを見つけなきゃいけないので、
単純なテストではないのだ・・・
■ソースコード修正からドキュメント等を自動生成するのが、
ソフトウェア工学の流れのはずでは？
そして、極めつけの議論は、
７２ページ２段目から、３段目の議論
「システムを保守する者は、ドキュメントを見ないというのだろうか。
ソースコードだけが頼りというのでは、ソフトウェア工学が長年にわたってきた知見を
すべて無視することになる」
まず、ソフトウェア工学は、流行があり、長年にわたった知見でも、
流行ってないと無視される（＾＾；）
例えば、いま、ＣＯＢＯＬの研究してる人少ないと思うよ・・
ま、そこはさておき、今の流れは、ソースコードからの自動化。
つまり、ソースコードからドキュメントやその他の可視化できるものを自動的に作り出すのが主流
なので、ドキュメントを見るだろうけど、それをソースコードを頼りに作るのが、
今の流行かな。
典型例がＪａｖａＤｏｃだよね。納品物になっているけど、あれ、ソースコードから作ってる。
ＥＲ図も、ＤＢから自動生成させてたりするし・・
もし、
「ドキュメントは作らなければならない・判りきった詳細設計書でも、
自動化せずに・・・」
とか言ったら、アジリティはなくなってしまう。
アジャイル終了のお知らせになる。。。
裁判所と日経コンピューターがアジャイルを終了させる？
そもそも、アジャイルでやる場合、チケット駆動開発を導入すれば、
（１）修正要望のチケットを発行する
（２）修正者がソース修正してコミットする
→ここで差分は取れる
（３）チケットに修正箇所を書く
→もちろん、これは（２）から自動化してもいい。
とすれば、修正ドキュメントをわざわざ作らなくても、修正箇所と修正内容がわかり、
保守できる。一般の人から見ると、これこそまさに、ソフトウェア工学！
■でもね・・・
なんだけど、アカデミックな世界では、ソフトウェア工学上で、チケット駆動開発は浸透していない
情報学広場で、
チケット駆動開発を引くと、８件
TiDDとひくと、３件
Redmineで引くと２９件
IEEE Xploreで
Ticket Driven Developmentをひくと７件
（ＴｉＤＤはどうも、違う意味になるらしい）
Redmineで２件
ということで、当然ながらTiDDは、日本で進んでいるけど、今一歩なのだ・・
なので、上記開発スタイルが、TiDDな人では一般的ではあるけれど、
学会ではまだ認識されず、ドキュメントを（手作業で？）修正なんていう
議論が成立してしまうわけだ。
現場の人から見ると、かなり変な論拠で、みずほ証券も東証も闘っているんだけど、
意見書を出しているソフトウェア工学の専門家は、たぶん大学の先生なので、
大学の先生で今の現場の感覚と近いのは、鷲崎先生のところとか、西先生のところとか
極わずか・・
となると、こういう判らん議論になってしまうわけだ・・
アクセス
トータル
ランキング
