おれせん。

　一消費者の私見とかどうでもいいっちゃどうでもいいんですが、TPP絡みで赤松健が妙なこと云ってる、というか「中の人から見るとそうなのか」という感じだったので、じゃあ外野からもチャチャ入れてみようか、みたいな話。

（TPPの他の論点についてはここでは関知しません。著作権をめぐるその他の諸問題についても概ね同様）

「そもそも非親告罪化するのか？」という点がまずありますが（この記事が発端、というかほぼここ一点突破に見えます）、仮にされたとして、一般読者のレベルではほぼ何も変わらないと思います。
　ごく一部の（超特殊な）作り手側には若干の影響が無いともいえない、ぐらいかな、と。（後述）

　何故か、という説明の前に、（日本の）官僚機構、特に検察官僚の思考回路について説明しておきます。（一般論です）
　官僚機構は、「誤りを認めること」「一回決めたことを覆すこと」を極端に嫌います。（何故と聞かれても「さぁ」としか）
　で、検察官僚＋起訴便宜主義の組み合わせの結果どうなるかというと、「起訴したからには有罪にせねばならぬ」となるわけです。（Google:有罪率99%）

　で、だ。

「非親告罪化」したとすると、「（手続き的に）原作者の意向に関係なく著作権法違反で逮捕して起訴できるようにはなる」わけですが、起訴した後で原作者が「うちのそれは二次創作OKですよ」と云い出したら、検察のメンツ丸つぶれどころの騒ぎじゃないわけですね。
（逆に「うちが立件したんだからまさか二次創作OKの許可は出すまいね？」ぐらいの圧力をかけてくる線があれば大問題ですが、その場合は起訴便宜主義を巡る議論を喚起しかねないので、やはり想定しがたい）
　ということはつまり、「本当に原作者の意向を無視して検察が『暴走気味に』著作権侵害を取り締まる」というのは、理論的にはありえても現実的にはほぼ無いだろう、と想定されるわけです。
（まず間違いなく「逮捕」「起訴」の前の何処かの段階で権利者の意向を確認するだろうし、であれば現状と大差ないだろう、という話です）

（例えば自動車の速度超過はそこら辺に沢山いるわけですが、その全てが処罰されているか？　ということです。
「何でもかんでも網をかけ、運用は検察の胸先三寸」という現行の運用に、検察にとって使い勝手の悪いツールが一つ増えるに過ぎない、と思います。何しろ「権利者がNOと云ったらそれまで」なのだから、道具としてはあてにならないにも程がある）

　また別の重要な観点として、「非親告罪化されたからといって、その分の捜査リソースが増えるわけではない」ということもあります。
　限られたリソースを「後からちゃぶ台返しされるかも知れない案件」に優先的に突っ込むとは想定しがたい、ということです。

（歓迎すべからざる事態であることは確かですが、実務的に何がどう変わる気はしません）

　で、「ごく一部の（超特殊な）作り手側には若干の影響が無いともいえない」と書きましたが、ここで想定しているのは「別の犯罪捜査の捜査線上に引っかかった容疑者を著作権法違反容疑で引っ張る」という可能性は、無くもないかな、という話です。
　あるいはまた「別の事案で捕まった容疑者が『ブツ』を所持していた場合に、容疑事実が一個増える」ぐらいのこともあるかもしれません。

　そんなん、俺知らんがな。
（著作権法違反は立件がめんどいのでスルーされる可能性も高いとは思いますが）

　最後に。
　俺としては「著作権法違反の非親告罪化」には反対です。
　それは、同人がどうこうという観点ではなく、何であれ「検察の裁量の範囲を拡大することに反対」ということです。
（軽犯罪法違反とか基本的にクソだと思います）

　……ところで、もしTPPが「起訴便宜主義」をぶっ壊してくれるとしたら、個人的には割と魅力的だと思います。（「制度的事項」とか「紛争解決」でテーマにならねえかな(ﾎﾟﾜﾜ）
　もちろん、そんな条項を官僚機構が飲むわけがない、のですが。

みずほ銀行：システム障害に関するお知らせおよびお問い合わせ先

http://www.mizuhobank.co.jp/oshirase.html

　中段の「システム障害特別調査委員会の調査報告書について」のリンク

　直リンクはこれ（5/20掲載）

　前半しばらく「グダグダ鬱陶しい能書き」が続きますが9ページ目の「3. 本障害発生以前のシステム障害及び対応状況」あたりからギアが入って、11ページ目の「4. 本障害の発生事実」からトップギアというかちょっとしたヘル絵図であります。

　……ああ、その前にここを引用しておこうかな、4-5ページの「2. システムの概況」内「(3) 次期システムの概要」箇所。

(3) 次期システムの概要
　次期システムについて、ビジネス環境の急激な変化に対応すべく、肥大化・複雑化した現行システムを新たなシステムとして再構築するために、2004 年から MHFG を中心に検討が開始された。
　2004 年当初の「次期システム基本計画書」では、第 1 ステップは 2005 年度内に、第2 ステップは 2006 年度内にそれぞれ完了させ、第 3 ステップは投資計画上 2011 年度内に完了させることを目指していた。しかし、第 2 ステップの実現が 2010 年度までかかったことから現在第 3 ステップに入っているが、完了に至っていない。

　スピード感のある経営（）笑
　……みずほの規模になったらデカイのは判るがこの遅さの時点で「意思決定プロセスの何処かにバグがある」と疑っていいだろJK。

　では本題。
　無断転載禁止とか特に書いてないので、「4-(1)-ア」を長々転載。
（ア/イ/ウ/エ/オ/カ/キ/クとあり、アだけそんなに面白くないけどその先超やばい）
⇒全文転載しようと思ったら、pdfをまんまコピペするだけだとうまく行かなくて整形がめどいのでア～エまでにします。悪しからず。

4. 本障害の発生事実
　(1) 発生事象と復旧措置

　　　ア 為替処理の遅延

3 月 15 日（火）から 24 日（木）にかけて、大規模な為替処理の遅延が発生した。上記の為替処理の遅延に至る障害の発生経緯は以下のとおりである。

(ア) 預金・取引内容照会の不全
3 月 11 日（金）に発生した東日本大震災発生に伴い、A 社の義援金口座 a へ大量の振込が寄せられた。この大量振込により、14 日（月）10:16 時点で取引明細件数がシステムの仕様であるオンライン照会のリミット値を上回り、営業店端末を利用した義援金口座 a に対する「預金・取引内容照会」機能が利用できない状況が発生した。
MHBK は、上記 A 社に対して、通帳記帳が不要である「リーフ口」の義援金口座を法人扱いで新規開設するとともに義援金口座に関する案内を新口座へ切替えるよう要請し、14 日（月）11:30 に新規口座開設を完了した。

(イ) 夜間バッチの異常終了及び長期化（3 月 14 日（月）分）
上記(ア)で預金・取引内容照会の不全が発生した義援金口座 a に対して、預金･取引内容照会の不全の発生後も多数の振込依頼が継続し、これらの処理件数は、夜間バッチにおいて、1 口座あたりの処理可能な件数のリミット値を上回ったため、3 月 14 日（月）22:07 に夜間バッチが異常終了した。また、異常終了時に処理結果データの一部が欠落する事態も発生した。
上記の夜間バッチの異常終了後、MHBK は、原因となったリミット値を拡大し夜間バッチを再実行する復旧措置を実施した。しかし、後続の処理には上記の異常終了時に欠落した処理結果データが必要であったが、このデータの復元作業が難航し、約 8 時間を要したため、夜間バッチが長期化するに至った。

(ウ) 夜間バッチの中断及び手動化（3 月 14 日（月）分）
3 月 14 日（月）分の夜間バッチが上記のとおり長期化した結果、夜間バッチ終了後の営業店端末の開局準備の時間が不足し、営業店端末を利用した取引開始時刻が遅延する懸念が生じた。これに対し、MHBKは通常時間での営業店端末開局を行うべく、手順書にしたがって 15 日（火）7:00 頃に夜間バッチを中断し、営業店端末の開局準備及びDJS切替の実行に着手した。
夜間バッチは、通常は自動運行によりバッチジョブを計画・実行する仕組みであったが、中断及び DJS 切替を実行した結果、上記の自動運行を利用することができなくなった。そのため、システムが正常化するまでの間、手動で夜間バッチを実施することとなったが、これにより膨大な作業が発生し、処理失念や誤処理による多数の副次的障害を引起こした。

(エ) 夜間バッチの異常終了及び長期化（3 月 15 日（火）分）
B社において、3 月 15 日（火）から携帯電話を用いた振込サービスによる義援金が呼びかけられた結果、15 日（火）15 時以降、義援金口座bに対して大量の振込が発生した。MHBKの当該サービス担当者は、EBISで受入可能なデータ量を事前に確認したものの、15 日（火）付の夜間バッチにおいて、1 口座あたりの処理件数のリミット値を上回ったため、16 日（水）7:17 にシステムが異常終了した。
上記の 15 日（火）分の夜間バッチの異常終了発生のエラーメッセージが 14 日（月）分の義援金口座 a の夜間バッチに対するメッセージと類似していたため、MHBK は、前日の復旧処理を踏襲してリミット値の拡大措置を講じ、夜間バッチを再実行した。しかし、再実行の結果、同様の異常終了が発生したため、16 日（ 水 ）19:20 から 17 日（木）4:13 までの間に、4 度にわたり更にリミット値を拡大するなどの対策を施した上で再実行したが、異常終了は解消しなかった。そこで、MHBKは、義援金口座 b が原因であるものと判断し、一時的に当該データを除外した上で再実行し、17 日（木）5:20 に、義援金口座 b のデータ以外の夜間バッチを完了した。
また、17 日（木）13:30、MHBK は、夜間バッチの手動化に起因して抑止されていた不要データの削除処理を必要なデータを退避した上で実施した。しかし、17日（木）22:46 に、この削除処理により後続作業で必要なデータが喪失していることが判明した。これに対応するための喪失データの特定に 5 時間、データの再作成に 11 時間をそれぞれ要し、夜間バッチを更に遅延させる要因となった。最終的に、15 日（火）分の夜間バッチは、19 日（土）19:05 に終了した。

　絵　に　書　い　た　よ　う　な　玉　突　き。
　シンジ君みたいに「動け！　動け！」って半狂乱なオペレータが目に浮かびます。
（むしろ「これはだめかもわからんね」か）

　あとそれから、「第4 発生原因の分析」の項もなかなかテンション高いです。
　現にこういうトラブルが起こった以上、現状に対して批判的なスタンスになるのは避けられないとは思いますが、外部の有識者が担当とはいえあまりにあまりなバッサリぶりは中々清々しいｗ

第4 発生原因の分析

1. 原因分析の概要
本調査の結果判明した事実により、各種障害を引起こした原因を検討すると、システム障害発生前及び発生後間もない時期の担当者による基本的な過誤（例えば、リミット値の認識不十分、システム全体の理解不足、これらによる回復作業時間見積りの誤りやDJS 切替等の判断の誤り等）によるところが大きいものと認められる。しかしながら、更に、このような基本的過誤をもたらし障害の影響を拡大させた原因を検討すると、システム機能上の不備、未然防止に至らなかったシステムリスク管理態勢上の不備、復旧対応における緊急時態勢の不備、人材の育成・配置の遺漏並びに経営管理及び監査の不備等が指摘され、再発防止策を検討する上では、このような基本的過誤をもたらした原因を明らかにすることが必要である。
以下、このような観点から障害を発生させ、影響を拡大させた原因を検討する。

　結果が出てからならなんとでも云える、とはいうものの、言及されてる範囲ではそれなりに妥当げな気はします。
　……で、あとはこの正論を如何に握りつぶすかというエクストリームスポーツに期待ｗ

　……東電もこういうレポート出さないかなぁ……。

　……無理だろなぁ……ｗ