IT system trouble Prevention and Investigations　ITシステム事故　Let's Go Prevention　Door. this HP all pages is ISSN 2187-5049

ベンダーの思考、ユーザーの夢に『虹のかけ橋』は？　　 ISSN2187-5049 Vol.1 2014-02-27 (c)n.inagaki
IT判決にみるプロジェクト頓挫の原因は？　わだかまりが残るのは？どの部分か
コンフリクトの前に志しあり、コンフリクトの後に絆あり・・・・・って成り立つか？

その１　みずほ銀行システム障害『調査報告書』

はじめに
2011年3月11日に起きた、みずほ銀行義援金口座大量振込事故に対して、同行から2011年5月20日に「調査報告書（要旨）」と同日付け「調査報告書（全文）」が公表されている。※１

要旨編（16頁）と全文編（35頁）{別紙や電文フォーマットの資料が参照できるように}で構成されている。が、報告書の本来の目的ではずであるガバナンス基本理念に反する記載内容になっている。
要旨編は全文編の約半分の頁を割いているが原文のコピペであり、意図的とも思われる単に言い回し表現を替えたのみの箇所での繋いだ文章が多い。※2

これは、全文編8頁6行に・・・復旧後、「システム障害報告」にまとめられた。・・・と記されているが、どのようにまとめ、原因究明に迫り、それをどのように教訓とし企業文化に生かしているか？の今回事件まで９年間の検証作業を欠いている。（仮に何も生かしていなかったとすれば、役員の内部統制管理態勢の不履行義務違反でなかろうか？）

所謂、結論先にありきで（本報告書が、みずほ銀行、みずほｺｰﾎﾟﾚｰﾄ銀行、みずほ信託銀行の合併を是認する）結論から誘導される急ぎすぎた内容になっている。

また、全文編作成の本調査委員会の４氏と補助者の構成が紹介されているが、元弁護士２名と監査人、コンサル会社と任命が偏り、全体が、訴訟になっても証拠とならなきような表記（失念した。遺漏並びに不備等、基本的過誤をもたらした原因を明らかにする必要がある・・・等明らかに検証すべきところは避けて、本報告では未記載）と監査第1主義で固められる姿があり、事件のシステム的な真の原因追求の姿勢がみられないのは残念である。※3

そして、その上に、みずほ銀行の今後の再発防止策として「みずほの改革プログラム」の妥当性評価及び提言をしている。これは事故究明と同一委員会内での自己評価であり、「報告書」の独立性に疑義を感じさせる結果となっている。

※１　http://www.mizuhobank.co.jp/company/release/2011/pdf/news110520_2.pdf
　　　　 http://www.mizuhobank.co.jp/company/release/2011/pdf/news110520_3.pdf
　　　　 http://www.mizuhobank.co.jp/company/release/2011/pdf/news110520_4.pdf　(いずれも本体HPから外された)

※３　「総入力件数」「リミット値の数値」や「リミット制限のコントロール箇所」がどこにも具体的に記されていない。また旧富士銀行データは旧第一勧業システムに移行が行われその後の新規トランザクション増加に関わらず、オン中引落処理のシステムデザインが検討されたかの検証も欠いている。我々に与えられた時間は２４時間固定であり、〆勘定時間が終了してから翌朝までの時間は一定でありトランザクション処理のためリソースマネージメント（容量管理）は、オンラインの必須与件であるにかかわらず、この面の検証も表記されていない。

※４　今回システム障害の損失額の推定を発表：日経コンピュータ副編集長大和田氏(108Kb)

命題①なぜ人間はミスを起こすか？
今時、富士銀行リミット方式（日中オン処理が24Ｈ/日の限られた時間内処理で絶対条件でありながら）が有効なシステムデザイン上の問題ではない
のは明らかであり、その方式が認識されながら５年間も何故放置されたか？の疑問に答えていない。

　→「気ずき」の組織化や「容量管理」「品質管理」の実態・会議検討過程を開示するのが肝心である。
　→銀行のオンラインには、システムデザイン面で「Feed Forward Control」概念（事前入力制御）がなぜ取り入れられないか？

命題②組織は「判断のミス」を防げるか？
緊急時（パニック時）の人間行動・判断になぜミスが挿入される、その制御策を持てていないか。
障害時の緊急時の現場の「エスカレーション」実態の解明が必要である。
どんな組織・体制を作ろうとも人間が動かし人間が随所で介在するので、ヒューマンエラー（この場合「誰に」、「どのタイミングで」、「どの様な内容が」、「双方に認識の齟齬がなかったか」等の）エスカレーション・フォロー報告を付加すべし。
　→米国では、エスカレーション実態の把握と事件後の見直し策、学習された教訓等が文書化されるのが、事故対応能力の向上のされ、それが企業文化そのものとされている。

命題③なぜ、災害義援金のような性格のサービスを銀行商品と同一土俵で語るのか？
そもそも被災地への支払行為は、後日実施される性質のものだが、本日〆勘定の勘定系オンライン業務にのせるのか？
　→（「先払い処理承認商品」等の新規商品開発を行えないか？最近３メガバンク体制で競争が無くなってきたのでないか）
　→なぜ「義援金口座」を競うのか？なかば公共的仕組に仕上がっているが民間の金融機関の「過剰サービス」でないか？
　→本来「エコポイント制度」で成功したクラウドシステム等の新技術活用するのがE-Japanでないのか？

命題④組織論からの解明も
「なぜ、いままで放置されて来たか」、巨大ITシステムと職務権限、IT品質管理・保守管理の根本的課題が存在するのでないか？
また、そのような緊張感なき組織群に対するマネージメントのあり方を隠蔽し、取締役義務不履行はなかったか？の検証も無く、まず合併ありきやトップの頭の挿げ替えで組織力強化に繋がらない。事実解明こそが、積み重なり人間の知見蓄積、規範の向上になる。

バタバタの緊急時対応の経過の中に組織的な連携能力がどのように有効に機能したかの「組織のケーパビリティ」評価が欠かせないのでないか。
異常時における組織間コミュニケーションは、情報伝達態様が「あせり」と「通常時の認知」状態をパニックに落としいれ、潜在的共有知識を破壊する。
合併間もない組織体が、通常時の品質会議やコンフリクト調整プロセスで苦労と課題解決の遅延を招きながらも、心の底にある利害意識を呼び起こす。
人間は基本的にミスを犯すものであり、動揺時は深層心理が表面に露出しやすい。

昨今の「システムトラブル裁判」を眺めても、保守的なマイインドが比重を増し、まず自己擁護的な歪を増長させている。
コンテジェンシー「BCP Plan」が紙のウォークスルーの域を超えられていない組織に正しい秩序ある行動を求められる...とした前提で今回の報告書が理想的伝言ゲームのアヤの上に、その解決策として「合併」の結論が導きだされている。拙速し倫理的でない。
　
このように、当報告書が時間的制限のなかでも「合併ありきの結論」を急ぎすぎたので、真の解明が欠落しているのは残念である。
組織間連携能力とは、それ自身が「企業力/組織力」そのものでないか？
先に導き出された当局向け結論を追認する「報告書」になってしまった。早く収束させたい力学が勝ち、後付けの味の無い「報告書」である。
　→トップの交代と銀行間の合併ニュースでかき乱され、「真の解決課題」が隠されてしまった。

　『事故報告書』の限界と提言

視点①　『報告書』の構成員について
「事故のトリガーがITシステムに起因する」場合は、IT専門家と称する人も構成員に加えた方が「ITガバナンス」が働くのでないか。
今回の場合、元裁判所OB、監査人２社の４名構成である。
一般的に監査人の立場は「第１次コントロールが存在し、その統制の整備度（第２次コントロール）」を評価するに長けていられるもので、必ずしも真の起因追求の知見・情熱を保証しえないものである。
構成員による関係者ヒアリングも、職務の細分化で全体像が掴み難いくなっている銀行のオンラインシステムで、全体を俯瞰した視点での問題解明が非常に重要となる。
IT担当者は自分への責任波及や訴訟を恐れて硬直的になるのが一般的傾向の中で「真実」を見出すのは、ITのベテラン経験者が適切と考える。

視点②　依頼者側のプレッシャー
今回は、「役員の首の挿げ替えと合併シナリオ」があり、調査進行がそれに誘導された帰来がある。
報告書発注のオーナーは依頼者側であり、発注金額が特定された活動である。

そこに、おもんばかりのプレッシャーが働いてはいないか！
依頼者は、事故が甚大な影響と資産の毀損を与えた以上「株主代表訴訟」や「歴代担当部署者の責任追求」「サポートベンダーへの波及」：
責任転嫁の義務不履行訴訟」等の亡霊がつき纏うものである。そんな陰の亡霊が存在する。
「責任追及するための資料でない」と言いながら、自ずと限界がある。

仮に「真の原因」が判明しても、マイルドな表現を好むものであるので「真の事実」が葬さられる。
みずほHGの３者関係は、旧第一勧業銀行の人事部２部制の１０年経過しても「わだかまり」が解消しなかった基盤の上に載っているので、
合併すれば解決してくれるであろう･･･大きな組織は詳細欠点をカバーしてメリットの方を多とする希望的観測の護送船団思考のままの
「行政睨み」、「陰の行政縛り」が、強すぎたのでないか。
真の「レピュテーション経営」に目が行かなくて、ジャーナリズムの風潮にのった「ガバナンス」論が報告書依頼のプレッシャーになっていないか？
ITシステム問題で、今後の報告書のあり方を決めて行くために検証も必要であろう。

視点③ 経産省は、クリチカル社会基幹システムに対する『IT事故調査委員』制度の設立すべき
海難事故の真の原因追求のための海難審判制度が確立されている。
（ここでは免責が担保されて真の事故原因の追究が主テーマとなっている）
また、
人命に係る航空機・列車事故にも当局の「事故調査委員」が派遣され、報告書が提出されている。
直接人命にかかわらないが、今や社会的インフラ基盤としてﾐｯｼｮﾝクリティカルなシステムがITの助けを受けて数多く稼動している。
故障・障害は甚大な損失を国民多数に与えるので、この面での社会コストから、経験の智恵を集積してIT構築・運用の効率化をはからねばならない。
「IT専門事故調査委員会」の設置が望ましい。　

視点④事故調査報告書は、国民的資産であり「データベースの制度化」を
「事故報告書」に慣れていない本邦では、時に恣意的誘導も見られるが、事故原因の蓄積と弛まぬ追究姿勢が技術の向上をもたすものと確信する。
人間は、時にミスを犯す動物であり、「想定外」という単語を使う事象以外でも人間が作り上げた物には、障害や事故が多く発生している。
一方、成文法下の司法の場での民事裁判下では、真の問題を追求すべきであるが技術問題よにも責任や債務がどちらにあるかで戦われる裁判沙汰は、法的裏づけのない分野であり、技術面での再び事故を起こさない術や新技術見出すようなメリットなき戦いに終わっている。
そして、
技術面のDB化の蓄積遅延が、同じような事故事象を繰り返している。
今やITシステムが、社会基盤インフラとして欠かせない存在でり、ITの高度活用が益々求められる社会にある限り大事故は、独立的立場が保証される制度の基で「事故報告書作成とDB化」を推進したいものである。
　　
米国には歴代大統領の公務にかかわるすべての記録類を保存する政府大統領図書館があるとされる。　
そこでは、様々な記録に精通する２５０人ものアーキビストたちが資料のアーカイブとともに、意思決定の場面を体験できる施設であり、政治家養成の場としても機能している。他山の石としたい。

＜参考＞
※1 「事故調査委員会」は、航空・鉄道・船舶事故の原因究明と事故防止の目的で設置法に基づくものと、国家行政組織法第8条に基づく（いわゆる８条委員会たる審議会」が馴染みある言葉で一般的に責任追及よりも、その事故の真の原因究明に使命があるとされている。
一方、主に民間で「外部調査委員会・第３者委員会」名を付した活動もみられる、組織内監査機能不全で会計面不祥事対応にその多くがみられる.

最近は、依頼者側のプレッシャーに引きずられる傾向が強かったり、依頼者側とのコンフリクトが表面化しているので、専門技術者に加え弁護士の参画をえ真相に迫るケースが多くなってきた。調査活動に独立性を保ち、組織が自主規律確立のための機能回復への真の原因究明報告の期待値が高まっている。
参照：『企業等不祥事における第３者委員会ガイドライン』日本弁護士協会には、（現時点でのベストプラクティスが表明されている）　　
追記：2013/06/12　◆理事コラム『第三者委員会 -雑感- 』ACFE JAPAN理事　宇澤亜弓氏　（ACFEWebサイトより転載）
追記：2013/06/15　◆日本野球機構(NPB)も『第三者委員会』を設置すると発表した。職責に対する倫理観/品格の問題をどこまで分析されるか？期待したい。

追記：2014/02/26　◆みずほ銀行は、2011年の東日本大震災後のシステム障害を機にグループ銀行を再編し、古いシステムの刷新を進めてきたが開発に手間がかかり、１年程度の延期を表明した。　
──────────────────────────────────────

　　

その２　ITシステム事故予防

　成熟期に入った今（GDP２％以下社会）、革新的なBM（ビジネス・モデル）が出現する確率は低い。
よってリスクを重視した経営者の姿を見ることは、「生き残る事ができても、成長する事も難しい時代である。
危険と機会に満ち溢れている現代のビジネス環境の中で勝ち組となるのは、価値の維持および価値創造の手段として賢くリスクを取り、管理している企業だけである。※1
そして、CROの責務は、「新しい価値を創造し、組織の競争力を高める」役と言われる。
リスクセンス（リスク感度）は企画センスと合い通じるものがある。

　今や新規商品開発や新ビジネス領域は狭く、事業遂行に全てリスクが内在しているので、そのセンスが問われる（世の教科書は、リスクを識別し、測定し、モニタリング管理すべしとされる）。
企画マインド（B型人間に多い？）は後天的に養成し難いものでもあるが、その部署には何故か「提案企画」が没になったかの過去の蓄積が溜まっているはず（先輩の助言や感や没理由）が明記されていなくとも組織的知見となっているはずである。※2　

　企業内にALM委員会やリスク委員会を設置した。リスクマニュアルを作成した・・・で安心することが最大のリスクである。少なくとも１年に１～２回は、リスク認識項目やリスク項目抽出方法の全面改定の覚悟でゼロベースで見直すべきである。
　金融機関は、金融自由化なかんずく金利自由化を受けて、ALM管理（Asset Liabirity Management　金利リスク管理、BIS規制管理　自己資本に対する流動性管理）の不十分さ、技術論の限界から貴重な経験を学んだはずである。

ビジネスリスクは、競合や他からの脅威に晒されており、潮の目を察知するアンテナを高くしまた第３者の意見を謙虚に聞く耳をもちたいものである。

　経営視点における「システムトラブル予防」の位置づけは

　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　システム事故予防策の経営者視点

まず、「ＩＴ's System trable Privention」への第一歩は、顧客からのトランザクション(T/R)解析システム構造をつくることが肝要である。
それは、学者的な理論説明より、自企業を取り巻く脅威の認識からリスク感度を高められるからである。
すれば体感できる。
そしてそれは、常時「危機感情報」の自動入力体制につながり、かつ「不良データのパターン分析」に役立ってゆく。

読んでいただく前に！　モーニング珈琲のひとときを　

　　

「包丁」や「自動車」「航空機」など人間が作り、それら工作物を人間が操り・利用し、便益を受けているが、事一大事になると「欠陥」を指摘したり「瑕疵」を問題にしたり、罵りあったりする。金融分野では ^※１
（訴訟は法律要件で争われ、製造物責任や予測知見の可能性、真実の蓋然性を事後検証しているにすぎない）。

事件となり自分に都合が良い点のみ強調され相手工作物に責を求めるいらだちが、IT訴訟場面にも見られる。
事故が起きてから包丁製造（殺人罪起訴で包丁の持ち方）の悪さや自動車製造過程（ブレーキ優先設計でなかった）の欠陥、航空機事故では航空機制御方式と人間の認知思考のアヤ等で設計や安全基準が表面化したのである。（名古屋空港中華航空事件がある）

ソフトウエアが５年も６年も実用に供してきて、異常状態時にそこにプログラム瑕疵があったとして過失を問われたら、誰もプロクラム作業を引き受けられないのでないか。証券会社の訴訟は「儲かった時」は黙んまりで（自分の懐入り）「損した時」は相手が悪くて損害を被ったとのダダをこねている事象に見られる。
　東証とみずほ証券事件^※２も、事件発生時に個人投資家が○億儲けたインターネット利用者のいる。
同時刻発生時に一個人客が、損を出してみずほ証券会社を訴えた事件があるが「そもそも株社会は損もあれば得も生じる場である事を認識して参加している」・･・と至極もっともな（常識的な？）判示で結審した事件もあるよ。

一体全体「プログラム工作物」は、「製造物」であるか？　「商品」でないのか？
経産省「モデル契約」があるらしいが、そもそも目的物が確定しない契約（債務）は法的に存在するのか？
拙者には、ますます　わからんばい！

　※１　拙筆：『週刊金融財政事情』誌「増加する金融IT訴訟」2008年11月17日号33頁
　 ※２　東京地平21･12・4　平成18年（ﾜ）第23958号、（上告中）
　読後は「午後の紅茶」で一服ください。　

このページの先頭へ

　
　
その４　ＩＴ業務のアウトソーシング

米国では、アウトソーシング（Outsourcing）から、インソーシング（Insourcing）へ逆戻りもあるようである。
EDS社にアウトソーシングしていたバンクオブアメリカ銀行（BOA）の、逆戻り（昔の里帰りと同様か？）の背景には、M&Aとそれに伴う経営戦略の具現化（事業分野の再編成）があるようである。
事業の規模に見合った再構築は効果追求として当然のこととして、大幅なIT構成の再編成は避けられない。

本邦に見られるような、ただ単に足しただけでは非効率経営が請け合いで、それに伴う人員最適化など根本的経営土台を弄らない、単に足すのみでは「Scale of Economy」を享受できる環境にないことは分かりつつも、
そのままシステム統合に入るのも（単にApplicaion接続ブリッジで凌ぐ）現場事務のBPRからみれば、摩訶不思議なことである。
現場の事務処理（人の動き＝企業文化）を変えるのがM&Aの基本でないか。
このように経営土台が変わる時、当然システム基盤（受け皿）も変わるのである。
また、その柔軟性がアウトソーシング時にも要求される。

如何に最新の方法であるとされるアウトソーシングになっても、『経営の魂』『志し』が合わないと、外注方式のアウトソーシングは契約破棄となる。
表向きな解約条項が明確化されていないと、気まずい関係（訴訟）に陥り易い。
上記のような根本的経営基盤の変革がない時にも、アウトソーシングして数年経つとギクシャクすることがある。
料金問題、メンテの柔軟性、アウトソーシング企業自体の浮気（経営路線変更）等が主要因のようであり、「ベンチマーク条項」で白黒峻別せざる得ないが、これまたやっかいな問題である。

第三者が入り仲裁もどき自体に遭遇した時は、双方後戻りできない「条文を楯にする」と「うま」が合わなくなり、契約破棄まで走らざる得ない。第三者がそんなに双方の経営理念の本音まで入り込まないのである。
また、「SLA契約」も万能薬でない。

前述のような最悪自体にならないためには、SLA契約に伴う詳細項目（KPI：Key Performance Indicator）の完全なる理解（これが出来ないが、非機能部分の仕様化※１で次第の道標が見えてきているが文言を眺めただけでは駄目）に難がある。
それは『SLA契約すれば安心で安価になる・・・』とする経営者の丸投げで安心できるとする経営文化が先行すると、一番先に判断する事項の相手企業と波長が合うかの、大前提である検討が「ぼやけている」からである。
以後詳細検討で現場は妥協が入ってしまう。まして契約条項に慣れていない人を担当させるのは、リスク要因となろうる。※２

大切なのは、SLA契約が誕生した英国の背景である「Win-Winの関係」構築は、如何にあるべきかを知ると納得できる。
これは、英国で衰退企業と称された建築業界の成長を促すキッカケ提示の成功例がある。※３　

建築業を長期視点で相手企業も成長維持される「心」が双方にないと、どんな条項を造っても（魂がはいらないと）いつかは表面化するであろう。

　　　※１　JUAS(日本情報システム・ユーザー協会）発行，「非機能要求仕様定義ガイドライン」
　　　　　　　　非機能要求に正面から取り組んだのが、UVC研究プロジェクトIIであり，「非機能要求仕様定義ガイドライン」だ。
　　　　※２　ITの契約自体に、「目的物の段階的順次の特異性」があるとする見解がある。　http://www.lt-law.or.jp/pdf/090325_Seminar_it-cpr.pdf
　　　　※３　(社)建築・設備維持保全推進協会　BELCA NEWS 106号　『特集　性能発注方式とSLA/KPI』
　　　　　　　　　　--英国におけるSLA/KPIの活用とわが国への導入--

その５　機密情報と説明責任　『学問吟味』

　　　　四択設問　
　　　　機密情報にアクセスするデータベースユーザーに対して、
　　　　説明責任を負わせるための最も効果的なコントロールは次のうちどれか？
　　　　
　　　　　　①ログ管理プロセスを導入する。
　　　　　　②二要素認証を導入する。
　　　　　　③機密情報にアクセスするためテーブルビューを用いる。
　　　　　　④データベースサーバーとアプリケーションサーバーを分離する。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(出典：ISACA　2010　CISA Manual）

　この設問が終わったら、そのまま「その13」に進んでみましょう！

このページの先頭へ

その６　「湯で蛙」状態を知るには？

日本航空が法的整理に追い込まれた背景を考えると日本全体に通じる問題が見えてくる。
各国航空会社との競争が激化するなか、経営者の怠慢もあって業務改革が遅れた。中年社員や退職者は既存権に固執。また公的な融資に安易に依存してきた。
官僚や政治家も、地方空港を乱造して、そこへの運航を日航に半ば強制した。

要すれば世界大競争という現実を前に、過去の成功体験にとらわれ、予防的に手を打つのが遅れた。^※１

人間は、「気がつかない程度の変化に弱い」そして事が起きてから後講釈で評論家の餌になる。
また、企業内力学で「気がついても」言えない、言い出せない雰囲気を組織内部で保有するものである。
ほんの少しの変化、予兆を無視する行動が続くと『湯で蛙』状態と称するらしい（私は蛙で実験したこと無いが）。

緊急の危機対応やBCP開始のときは多大な体力を要するものであり、資金的にも窮地に陥るケースもある。
緊急時の資金ほど高くつくものはない。

防ぐには、常日頃、センシティブになる体制^※２を持ったり、時には『How risky is your Company？』のリスクエクスポージャー計算^※３を試みるのもよい機会となろう。

　　　　　　※１　朝日新聞2010年1月18日［核心　論説委員長　平田育夫氏］（５面）
　　　　　　※２　社内品質管理委員会態勢（PDF約16KB)
　　　　　 ※３　Harvard Business Review Report　当サイト内「図書紹介」に掲載

このページの先頭へ
　
　

その７　事故予防システム考

事故が起きればその代償は、商品利益がすっとんで経営基盤に大きな影響を与え場合があり事によれば、決定的に企業レピュテーションにダメージを与えることになる。
医学分野や製造業は、このために永年の経験で『転ばぬ先の杖』を保有している。

『転ばぬ先の杖』！　それが事故予防（ＡｃｃｉｄｅｎｔＰｒｅｖｅｎｔｉｏｎ）行動であり、会社内に専門部署を持ち、そこには「事故予防システム」を持つ姿がある。（医学は「予防医学」、一般企業ではトヨタ自動車、日立製作所等）そして、会社員が自由にアクセスできる態勢を持つ。
また、業界全体として古くから「競争と協調」の精神が経営を継続させる知恵の一つとなり、「品質保持」「品質に対する取組み」でボトムアップのQC運動や国際的な業界横断的共有知識機能をも持つことになった。^※１

システム事故にはその予兆があり、「品質委員会」で見抜けるケースもある。そして小さなシステム障害でもその要因を洞察する事により「リスク感度」を常に向上させたい。また業界別障害一覧表などでから『他山の石』となる宝が含ませているものであるから、各参加者は「目と耳」を研ぎ澄ますのが寛容であろう。

一方、ITシステム屋業界を眺めると、ベンダーであるシステム構築会社の自己のための機械化進展は遅れている。特にベンダー側にとってコアコンピテンスである要求定義の仕方、プロジェクト管理、プログラム開発等自らの作業は、どうも相変わらずの手工業社会で丁稚奉公がまかり通っているようだ。自らの機械化はWBSとPMBOKであとはプロジェクト集団のポータルとe-Mailぐらいであり『紺屋の白袴』でなかろうか。

グローバルに展開している米国EDS社（HP社の戦略でM&A）や英国金融界でBPO/KPOまで手掛けているTata社はプロジェクト開発事業で、多数遠隔地で同時進行する大型プロジェクトは、複雑・大型化ゆえの仕事が複雑な入れ込みがあるので、本社には大型デスプレーが並んだ部屋で一目瞭然に進行状態が把握できる「集中監視室」と装置で常時管理体制にある言われる。
緊急時にば、その時の会社リソースをスピード感もって最大限有効に活用できるのである、各プロジェクトが今「どのような状態にあり」「どこでイエローカードを出すべきか」、時に現場負かせでない総合的知見を活用して事故の「予知」に挑んでいるのである。

本邦でも新商品開発時に、その時の世の知識を集めて、多面的角度から事故が起きないか、また、事故が起きた時の免責点を考慮して事にあたっている歴史を重ねている。そのツールが事故情報DBのコンピュータ・サポート体制^※２（事故予防システム）を持っている。
日立製作所の統計によると、事故の約７０％（件数比）は設計に起因したものであるが、それらのなかでは情報不足^※３によるものがはるかに多いと判断されている。
ベンダー企業自身による「事故予防システム」のコンピュータ体制を早急に確立すべきであり、当局も産業界育成のためこの視点の方向づけが欠かせない（英国建設業界のSLA誘導策）。
また、ベンダー側の企業をサポートする業界横断的な「真の事故要因分析」や「障害回避研究」の知恵を積まねばならない。

我々は、以心伝心の社会であると錯誤しているが、コミニケーション不足が企業内のみならず、ユーザーと決定的な局面に遭遇し失敗を重ねていないか？　何も大型デスプレー監視装置の形でなく、今すぐにでも（e-Mailでよい）現場で起こりつつある「気づき」「小さな失敗」や「個人のちょっとした予感やアイデア」を集積する仕組みをつくるチャンスが来ているのでないか。

※１　EXACT、GIDEP；Walker,W.B.,Proc [1976 Annual Reliability & Maintainability Symp] 、Richards,E.T.,
※２　「製品の設計段階で、信頼性に関し未経験で不明な問題については、徹底した事前検討が必要なことはいうまでない。また過去に一部分でも類似の経験があったり技術の蓄積があれば、それらを有効に活用する事が必要である」：日本機械学会誌第83巻第739号715頁「信頼性情報検索と事故予防システム」；日立製作所種田氏他より
※３　事故現象とともにその技術的要因や動機的要因を記載した各種の事故資料のなかから、それらの技術的要因または動機的要因が現在進行中の条件に近い例があり、それらを類推的に問題のポテンシャルを掘り起こすために必要となるヒント情報

CIOは、常に『カタカナ用語と英語の３文字の進言』に攻撃されている。
システム担当者のみならず、管理職までもだ。
その人達は真面目で、専門家らしき人ほど、「むつかしく、何を言いたいか」わからない。
判るのは、突きつけられた投資金額と期日のみで、悩まされる日が多い。

時には、すぐ激論となり、気まずい雰囲気が組織に残り、最悪、喧嘩（システム屋さんは自説を覆替えするのは「恥」と思っている）になれば、自己修復の難しい群像相手でもある。
そこで、CIOは、決裁が多少遅れても『一服の静観』を持ちたいものである。

一昔前ならば、組織内の人の動きや顔を見ていれば「判断」はぶれなかったが、今や経営要素が人・物・金から、人・物・金に情報処理力（目に見えなく黙って端末に一日中座っている？何をやってて、その成果も見られない）が加わって来ている。
それは、複雑化、巨大化し複雑怪奇な巨大構造物になってしまっている。
そして、今やITは、合理化追求のための特別視された域を超え、今や「ITは経営運営の一部であり、電気や電話と似てきた」（それにしては金食い虫で高価だ）組織内の「情報処理能力」が経営成果の主要要因で方向性を決める環境に到達している。
よって、全体を俯瞰するため、一歩高い山から眺める余裕を持ちたい。

それには、貴方のそばに「監査人」が一生懸命勉強して、監査役マインドでITを眺めようと日々努力されている。
ですから、まず監査人と本音で語れる関係をつくれば、心に余裕がでますょ。

監査人は、昔の会計監査（不正防止観点）中心から、今やJ-SOXではIT統制（IT分野の係わりが多いので日本だけ独自に追加）が規定され、金融商品取引法の遵守状況はじめ取締役善管注意義務違反（適切なITｼｽﾃﾑ構築支援を履行しているかの監査）　まで取締役行動に監査の目を行き届かせそれが適切に運営されていなければ、（いわばＩＴシステムが職務の中で機能しているか）ならないまでに、守備範囲が広くなっている。

それが保証されないと『ガバナンス』なかんずく「株主代表訴訟」にその責務を果たせないからである。
自分の組織の「ITシステム」を客観的に、時に第三者的そして醒めた目で、もの言う人が経営内部に必要になっている。
監査職務も、IT面の監査ウェートが求められる「新しい監査役」になってきたのだから、力強い見方が監査室にはあるはずである。

人間の知恵で会計監査が法律によって担保されているように、システム監査もその重要な役目を担う日がその歩を近づけている。
「監査の目」、「監査マインド」は、農耕民族に慣れ親しんだ風土では火急に備えられないし馴染まない（これからは「トンボの複眼」が必要か）

ＣＩＯは、監査人と親しくすれば、補完情報満載の強力な味方であり、孤独感からも救われる。
そして、時にトップや他役員の『時代を見る目』や『独特の商売感』を翻訳してシステム担当に伝えられれば、この上ない快感を感じる役職でないか。誰からも賞賛の言葉はかけられないが、頑強な基盤システムが構築された暁には、「１人ニンマリできる至福の一時を」感じることが出来る冥利がある。

このページの先頭へ

その９　今、求められるIT人材の育成

我が国ではその昔から、「宮大工」や「頭領」がいて『匠』の術が継承され、大きなプロジェクトを成してきた。
また、我々日常生活面でも「庭師」は、最初に訪問すると朝早くから日が沈むまで煙草を吸い雑談しながら庭を眺め、１日は全く仕事を手にせず眺めるのみで夕暮れ家路に帰る姿があった。翌日も、やおら「庭鋏み」を研いだり、どっかりと縁側に座り込み茶飲みながら雑談していた姿を思い出す。（鋏研ぎは、なぜ自宅で準備してこないんだ！お客のお茶飲みで雑談話では日当がもったいない・・・と思ったものだ）

しかし、やおら枝先手に入ると一寸の狂いもなく、見事に庭全体と家屋をマッチさせ顧客に悦ばれたものだ。しかも顧客は時間が経つにつれ嬉しさがこみ上げ、報酬額以上の感謝の念が滲みでたものだ。

一方、IT業界は、世界全体のリーマンショック後の構造的世界経済停滞期に影響され、システム案件は凍結され、SEも３K職種に数えられるに至っている。ユーザーのIT利用が組織運用に電気や電話と同様に不可欠な道具になって、動かねば組織体も壊滅することが分かって来たにもかかわらず、経費削減の波に晒されている。
この間、システムは老朽化し対顧客要望とのギャップを深め、究極的に訴訟も多くなっている。
　（顧客の要望は自己中心で際限のないサービス要望が噴出している、時にはリスク世界でありながら自己損のみヒステリックに行動する姿もある）
大幅改訂や新規案件が乏しいなかでのシステム開発も、ベテランと一緒に体感しながら技術向上も待てない環境で１人「クラウド」が先遣されるのみである。しかし、プログラムを人間がつくってゆく限り、人間の「技」によらねばならない点を忘れがちでないか。

さて、
プロジェクト開発の現場をみると、相変わらず「カタカナ」と「英語の略語」で、こんなの知らないのッ・・態度で迫ってくる勢いで当惑するケースもある。彼らの根底には研修や資格試験で習ったことの至上主義がある。
しかし、PMBOKやCMM、WBSなどと威張ってみても、所詮20年も30年も前のIT環境で生まれたもので苦悩の中から「いいとこ取り」されたマジョリティー（ベストプラクティスと称す）をかっこよく体系化した米国文化に基づく方法論である。
今信奉ししているプロジェクト技法なるものは、米国式発想で限りなく細分化し、それをマネージするのは別の人間が行うという簡素な思考である。

PARTにしても品質曲線にしても大体が２次元で表記し、その進捗を見る事に注力するのが良い管理と夢見させられ称されている。ITのハード、OS、そして言語まで全て「洋式」でしょうがないが、プロジェクト頓挫を目の前にすると何かしっくり行かないところが心に残る。
それは、システムに心が通っていない、洋物管理手法であり限界を感じる。

『スカイツリー』が完成近い！
その基本構造に「心柱」があることを再認識したい。　そして現代版「宮大工」が正三角形から上部にゆくと美しい円形に工作している。
日本の伝統文化に見られる「そり」と「むくり」という形状であるらしい。三角形の頂点が描く稜線は日本刀の持つ「そり」を、円形に変化する部分からは、奈良・平安時代の寺院建築の列柱がもつ中央がゆるやかに膨らんだ「むくり」というデザインを持つことになったとある。
　（http://www.nikken.co.jp/ja/skytree/concept/concept_03.php）

設計には、時間の他人数がかかわりその費用も桁外れの投入と考えるが、後世に名を残す仕事であろう。
我々は、洋物を少し囓っただけで、高額を請求したり威張っているのでないか？
技法も猿真似で自己満足していないか？
アウトソーシングで肩の荷が降りた・・・とか、そして組織内に「丸投げ体質」が忍びこんでいないか？
自省させられるところがある。

我国では、昭和４０年代経団連が派遣した米国コンピュータ視察団の恩恵で今の日本経済をここまで牽引してきた知恵がある。
また直輸入のみでなく、漢字を輸入しひらがなを工夫し独自文化をしつらえた知恵もある。
そして、古来、釘なしで五重塔を造り、CADなど無しで城垣をこしらえてきた。
大きなプロジェクトを成してきたのである。

団塊の世代のSE職経験者は、その昔、伝票に色短冊を添付し、その流れと人の導線を１日中眺めてからシステム設計に取り組んだものである。そしてSE各人の振る舞いや顔色、そしてエンドユーザーの評価をためらった後の一言、コンピュータのこと分からないと言いながら譜とした一言「これからは地上戦だな～」」など、体感を積み重ねたものである。今、回顧主義でないが、事を成すための古来から伝承された匠の技とその継承術（今は、何でもマニュアル化すれば事足りるとする風潮）を、遠慮無く若者に吐き出すべく責務もあるのでないか。

体感の蓄積を方法記憶^※（自転車の乗り方など無意識で記憶されたもの）と称すらしい、今、その方法記憶を気付き整理してみませんか！
団塊の世代のSE経験者は、その貴殿の隠れてたスキル（SE独特の勘）を伝承すべき何かをお持ちである。
米国の資格試験に連動した各種フォーミュラ（団体が発表するモデルに基づく）も、なにか黄名臭い。
ある理論体系が他の理論に置き換わったとしても、敗れた理論の中核的な原理が生きながらえ新たな装いで蘇ることはよくあることである。
我々は、欧米流の横文字管理技法には含まれない東洋的？な、何かが存在するのを、今まで体感してきたのである。
合理性の名の元に組織の「丸投げ体質」で、現場は「ITガバナンス」の企画立案も困難な世情に来てしまった。
どこかで欧米流の思考を絶対視する習性が身についていないか？
確かにISOや世界標準への起動は、慣れていないかもしれないが、グローバル思考では律し切れない何かがある。

我々は、「気づき」そして、その「勘」や「何か」の重要性を見直し、貴方の組織で集積したいのがこのサイトです。
　
※記憶構造には、経験記憶（自分の過去の経験に絡んだ記憶）、知識記憶（知識や情報などの記憶）、と方法記憶の３つの種類があるとされています。・・・財団法人河野臨床医学研究所理事長　医学博士築山節
※「勘とは経験の蓄積である」（勘というのは、棚ボタ式に出てくるものじゃない。それまでに経験したことが体中に残っているから、ピンとくるんです）：名城大学大学院理工学研究科　飯島澄男教授　　

その10　重大インシデントと「知恵の集積」仕組みを

原子力事故や航空機事故、JR脱線事故などが起きた場合、その事故概要から重大インシデントと認識され（報告）た場合直ちに「事故調査委員会」が設置され真の原因究明がなされる。そして専門家がその見識を生かして当事者の聴取やログ記録など多方面から要因を探り原因を突き詰めて報告書にまとめられる。

本来安全装置であるべき機械装置（航空機のTCAS、鉄道のATS等自動事故防止装置）と機械全体を操る人間による操作・運転の葛藤場面のミス（ヒュマンエラー）に起因する事故も散見される。
その原因を概観すると、自動車・航空機の装置自身の中にコンピュータ制御によって（主に組込みソフト）運転が可能でまた会社組織や電力・水道等社会的システムもコンピュータによって運営維持されている。これは主にエラー制御技術として組み込まれて、その装置によって安全・安定運転が保証されてきたのである。
が、
昨今の事故を眺めるとその自動制御装置と人間の判断・人間の誤った指示による自動制御装置との葛藤の姿がある。全体像を眺め見ると、TCASやATSの自動制御装置を作ったのも人間でありその仕組みを動かすのも人間である。
共に人間と人間の戦いの場面でないか！
そして、「人間はミスを犯すものである」尊い命を失なざるえない局面に遭遇されるまた社会的増大な経済損失を発生させ続けている。

２管制官による「日航ニアミス」事件が最高裁で判決が確定された。これなどは典型的機械と人間の葛藤でありその根は解明し真の原因を追究する過程で新たな方策方法を見出して行くのが良策でないか。
「予見可能性」判断で、その時の技術水準やその時の規範・経済合理的判断や教育で、それに類似する事象は克服できたとしても、次の世代や類似のITシステムにその時の収集された原因解明の労力・知恵は今後のシステムに流用・転用されてしかるべきでないか。

コンピュータ障害や事故にこのような、原因解明そして対策検討を積み重ねる仕組みがあるのだろうか？
社会全体で、ITコンピュータシステム（特にプログラミング技術やシステムデザイン：Fail Safe概念）にこのような知恵集積のサイクルを組み込んでゆく方向が必要でないか。
ともすれば、コンピュータ障害は直ったからそれでよし、経営者は頭を下げた記者会見と現場責任者の更迭や世間のうわさも○○日で、まして外部には真の原因を出すなの風潮では、人間のヒューマンエラーとコンピュータ制御による自動装置の「あや」の高度化は望めない。

経産省でもどこでもよいが、コンピュータシステムの重大なコンピュータ障害時の真の原因状況を解明する「第3者調査委員会的」な組織とそれを蓄積し活用するデータベース制度の必要性を痛感する。多数のEDPを活用せざる得ない社会でこのような仕組みを持たないのはコンピュータ領域だけであり、現に稼動している他のコンピュータシステム品質維持や新システム構築時のバイブルとしても役立って、社会的効率化にも使役するのでないか。

※JCOの核燃料加工施設内、高速増殖実験炉「常陽」のウラン溶液による核分裂連鎖反応が発生した。（平1･9･30)）
※「日航ニアミス事故」2001年1月管制官の指示でJAL958とJAL907の２機が高度差約10mまで接近した事故（最高裁第1平22･10.26）
　→最高裁１平22/10/26に対する異議申し立ては棄却され有罪が確定したが、５人の裁判官のうち１人は反対意見であった。
　　　　いわゆる「うっかりミス」が、刑事罰を科すべきかが問われた事件であった。
※全日空系ANK機に管制官の誤指示で異常接近（平22･10･26管制官の失念と報道されている）
※「JR西日本宝塚線脱線」事故現場で、ATSが作動して非常停止した。（平22･10･14運転手は考え事をしていてブレーキ操作が遅れた）
※東京証券取引所とみずほ証券の１円誤発注事件
※参考文献：『ヒューマンエラーは裁けるか』安全で公正な文化を築くには　原著　Sindney Dekker　『JUST CULTURE』　:　Balancing Safety and Accountability　』

その１１．法情報学『学問吟味』^※１

設問１：ITシステム訴訟の判決文(判例)から『真実』を見出せているか？

では

設問2：ITシステム事故一般公開情報で、(裁判ルート以外の新聞や雑誌、当事者広報等から)『真実』を見出せているか？

　参考図書『システム開発契約の裁判実務からみた問題点』東京高裁判事滝澤孝臣「判タNo.1317号2010.4.15」

皆様の見解･意見をお寄せください。２Ｗａｙで討議しませんか！
　
※１　幕府の昌平坂学問所が幕臣子弟に対し行った試験で、かなり実践的な時事問題が出たらしい。

このページの先頭へ

その１２．ＩＴ部門と監査・内部統制

監査は、ゴミの山から「ダイヤモンド」探しだ！

『監査・内部統制』と聞くと、その前に取り組みに「暗いイメージ」が先行し、また、後付の作業で「人の粗探し」の「食」が進まないものである。そして監査は「重箱の隅をつつく」「システム設計時のミスを顕在化するのみ」「前向きの生産的業務でない」との頭が過ぎると楽しくない仕事になる。このようなCIOに作業命令される担当者は、前向きにな良いシステムデザインは生み出し得ない。しかし、CIOはこの世間的風評・誤解のから少し目を逸らせば「見えて」くる。

今までの『ITシステムデザイン』は、開発サイド側の立ち位置で喧伝されてきた。事務合理化面志向が強く異例値は除くのが当然、監査立場からは違例はサンプリングによる保証業務から外れるのを当然として扱われてきた。経営者がITを馴染めないものと感じているのはどうも基本的設計概念から再考したほうがよいのでないか？従来、要求仕様はユーザー側の責務として当然ユーザーが書くものとして表記できないものは開発者に分かるはずない････と逃避してきた帰来がある。

それは、トランザクション取引データ（以下TR）自身のデータの中に「美味しい発見がある」事を無視してきた。属性が規定・規則に合わないとエラー処理でデータを捨ててきた。が、『ホカロンの成功物語』では、ある小さな店が夏に「ホカロン」が売れた伝票が上がってきた、冬場なら当然であるが「何故、夏に売れたのか？」の１件の伝票から商売の原点を見出したのである、異常の要因を見出し顧客行動の背景解明がその後経営の理念としてその延長線に今があるとされる。

イトーヨーカ堂はじめコンビニのPOSは、店計数の合理化や棚管理面もあるが商品の売筋を一はやく早い段階での商品揃えが店長の肌感覚との合致が成功の秘訣とされる。

そして昭和40年に遡上るが『GE顧客相談システム』^※１を取り入れた住友銀行、花王石鹸の顧客相談窓口データの活用は企業の成長要因でありその成功業績はあまりにも有名である。

また、堅い銀行筋でも①TRエラーの裏には、不正もあればヒューマンエラーもある、また自分自身が気付かない操作ミスも内在するのでその人特有のTR振る舞いを解析し、自身の能力に依拠しているならば研修候補として深層能力向上策に役立てている福井銀行。②外国為替や金融派生商品を扱う顧客業務のリスク管理は難しい理論を振りまいても真の顧客診断にならない････と毎日のTRの振る舞いのなかからリスク管理技法を見出していた銀行（旧三和銀行）の成功例もある。

このように取引データが集約されてしまった管理計数データの段階では、マクロ分析の納得材料（後つけ理論）利用であり、まして財務データとなってはもう過去のトレンドであって、もう生きた商売のヒントは見出せないのである。
また、同様に内部監査面からの眺めのみではデータが死んでしまう。違例取引は不正・不良データとみなされているが、取引データの中は『ゴミの山から「ダイヤモンド」！』を探しえるのである。

CAAT^※２思考でシステム内任意の場所に監査ポイント網^※3を張れば、マネロンや外部不正アクセス監視のみでなく「監査や内部統制業務」に重複する楽しい商売領域を見出せるものである。

^※１「米国GE社の白物家電復活の裏仕組みで、顧客の苦情や相談の中に真の要望が隠されている････」として、相談窓口者は企画担当部署が担当し、産業心理学手法を使い深層心理の像を探り出す会話と、コンピュータによるデータ解析を駆使した手法。「真理は現場にある」コンセプトを体系的に実現した。昨今ではトヨタ自動車社長の「検査でいい車はできない」の格言に生かされている。

^※２CAAT（Computer Assisted Audit Techniques：コンピュータ利用監査技法）と称されて旧来から監査業務の効率化のためコンピュータを使った手法が提言され、ITシステムが組織経営体と一体化した現在ではTRや企業データの大半が機械内に存在しコンピュタなくして精緻な監査が行われないほど必要不可欠なツールとなっている。そのツールは監査用専門の視点からソフトウエア化されGAS:Generralized Audit Software：汎用化された監査用商用ソフト（ACL、IDEA、KnoweledgeSTUDIO等）が販売されている。
　データ分析、データマイニングの手法では、「どういったデータを抽出するか」、「何をもって異常値とするか」、それらを分析し、「何をもって不正の兆候と判断するか」といった設定が非常に重要な鍵になっている。

※３不正・不良取引にかかわる判例のページ　５：GASソフトウエアの利用概要図を参照ください。

その13 機密情報漏洩問題に対する防御策は？

内部職員の不正操作による機密情報漏洩が問題となっている。
海外でもWikiLeaksによる機密情報の露呈が外交問題となっている。
これは、組織外部からの不正アクセス・コントロールが、組織体による個人情報保護法やJ-SOXの準拠態勢整備で、セキュリティポリシーの見直しとその予防策の徹底による認識の高まりにあるなかでも、内部組織・内部システムに「穴」があり、防ぎきれていない査証でないか？

機密情報の漏洩は
　①日本原子力発電従業員による「敦賀発電所」技術・業務資料の拡散
　②日本銀行支店職員からの漏洩で風評による企業倒産事件
③防衛省官による「イージス艦情報」漏洩
　④警察庁の「機密テロ情報漏洩」
　⑤尖閣列島映像露呈問題
　　　※当頁は、漏洩コンテンツ内容の吟味でなく、事案の起点である「人間による手口」に注視したものであり、この事案事件を判断特定するものでありません。
等内部からの犯罪行為が絶えない。
そこで、各組織はその対応に勤しんでいられる段階であろうが、その計画案にも「穴」がないか？
「知恵の運動」をしてみませんか？

ある組織では、IPAセキュリティーセンターが発表している「情報漏洩発生時の対応ポイント集」を参考に下図の改良案を作っている。
この例題から、貴方の気づく脆弱性の箇所をポイントください。

　

　上図の設計図が示された、貴方は脆弱性が機密情報ファイルの漏洩にあると考えている。対応策としての追加すべき箇所はあるでしょうか？
見落としている視点がありましたら、貴方様の指摘・意見をお寄せください。
拙者の推挙する「論理アクセスによる機密情報漏洩対策方法」の資料をご参照ください。

その１４　神奈川県不正経理をめぐる詐欺事件^※１

不正防止の第一歩は、経理の「仮払い、借り受け」の仮勘定科目の伝票の動きをみる事にあるとされる。

その昔、銀行のオンラインの黎明期に、店舗間による月末日の未達勘定（隣店間の月末日の貸借両建てによる架空のかさ上げ＝月末残高崇高時代のなごりであった）を注視しるのが、経営者の目の付けところであった。
月末、期末日のみ残高が上がったが、収益は生まないのである。(表面上,計数上の背丈が高く見せられたのみ）

正確さを要求される金融機関事務処理にあって『Fraud 』（※不良取引）の研究は、本格的に米国FSTC^※^２で、CitiBank：ＣＴＯリードによるプロジェクトによる業界横断タスクフォース組織で始まった。クレジットの不正利用が過誤できない程度に多くなり（悪貨が良貨を駆逐する！）、またインターネットのFB/EB普及でヨーロッパや中南米諸国からの米国金融機関（CityBank, BOA, Nation Bank, Wachvia等）が、本体EDP処理にアクセスされ、その被害が膨大になり銀行業務のインターネットチャネルが脅威に晒されている背景があった。

「Fraud」とは、本邦で馴染みがないが、１トランザクション（以下TR）である１取引は正しいルールに則った事務処理（例：１TRが＄10の出金事務）であるが、この取引が一定時間内に数十件発生（同一口座で同じ出金がｎ回も続くのは、普通の人間行動でない）するようなケースが、不正とは断定できないが「不良取引」であるとされるのである。
よって、
どの様な取引パターンが正常で、どんな取引パターンが不正を生むかを峻別して、良質なTRのみを内部EDP処理に負かせる形態のFEP機能（単に通信機能だけを司るだけでない）を充実するコンセプトが生まれたのである。
今や、このTRパターンを入口での防御策として、FEP機能でこのFraudデータパターンを搭載し、常時更新・監視するのが普遍化しつつある。（自分のPCにウイルスセキュリティーソフトによって、起動時に自動D/Lすると同様である）

この「Fraud」研究は、今後、より精緻化し常時体制を敷かねばならない。
特に、企業間でEDP対多数EDP接続によるビジネスモデルが避けて通れないネットワーク時代にあって、CPtoCPなかんずく、株取引にまつわるアルゴリズム取引（一定の論理でコンピュータ自動取引させる・・・これは曖昧な人間判断の隘路を見出しやすく収益の源泉でもあるが

不正取引やFraud（犯罪と裏腹であるが）データの入りやすい分野である。^※３
相手に企業倫理を求めても、人間の強欲には所詮他人様にはコントロールできない）に一層の研鑽が求められる時代になり、株式取引分野のみならずオークションや企業間ネット取引の全盛社会では共通の課題となって来た。

提言：企業内にあって、その道の専門知識や専門技能を生かすべき！
　教訓①泥棒を駆逐する前に自分達の部屋に「鍵」を設置するのが先決である。
　教訓②『週間金融財政事情』誌2008年1月14日号「新システムで１５分おきに異常取引・不正口座をチェック」名古屋銀行
　教訓③１企業内では限界がある（経済的合理性）→業界の横組織で協調して共同開発すべき

　※１　県職員による「預け金」勘定の架空発注取引を繰り返したFaudによる。2009年12月23日朝日新聞朝刊横浜１３版
　※２　FSTC　Financial System Technology Consortium　http://www.fstc.org/
　※３　内外資本市場動向メモ　NRIレポート　No.09-15　「HFT（高頻度売買）とフラッシュ・オーダー」--何が問題なのか--　このレポートが正確に解説されている！

追記（2010/01/21）
上記、この事件にかかわらず岩手県、千葉県、愛知県、島根県や警察不正経理では北海道、福岡、静岡、熊本等そして東京大学はじめとした中央官庁統括の機関に多発と会計検査院が発表（一部が表面化したのみか？）総額ウン百億越える事態である。
これは、一般庶民の目線では上記した「預け金」処理と「年度越え」処理が基本的な問題であり、民間ならば普通の会計処理プログラム作成時は当然のシステム要件であった、これが蝕まれると経営の屋台骨まで響くので、会計スステム設計者はとうの昔に卒業している問題と思われているのでないか。

官庁直下組織、地公体、自治体等税金を扱う人達は、昔の『現金主義』、『単位年度会計』の腐れ理念が、まだそのまま生きているからでもある（組織文化化）。
「３月３１日に予算は全額使って±０で着地が優良なる部署、来年は足らなければ補正だ！次年度に付届けする業者が可愛い」の成績評価文化から改めないと直らないものでもある。
今、全国的に上記の会計システム構築することは無論であるが、公会計制度で早く透明性を確保し連結決算、複数年度会計の整備を急がせなければならない。

追記（2010/02/03）
また、不幸な事件が表に出た。「農水省による不正経理」である。手順は実際には翌年度に納入されたのに、年度内に装う手法であったらしい。これば前述の最も幼稚な、そして（我々もこの誘惑に乗りやすい習癖があったのも事実であり、予算と消化率100%の誘惑に填りやすい習性の核には、税金は黙ってても入ってくる、また反対に税金は少しでも払いたくない心情が蠢いているのであった。現に大学内の高度なアカデミック人材養成の現場でも、予実決算合わせのため１２月頃の海外/学会出張の集中や年明けてからの「書籍購入額」が年度予算消化のピークを迎える経済波動があった。来年予算がきつくなる前の予防本能が腕の良いマネージャと見なされて、部下達への腕のみせどころでもある）小市民感覚の悪魔の魔が差した非合理的経済行動であるが、以下の点でも許されない事件である。
　その１：こんな幼稚な手法（Fraudパターンの類型化の第１歩）は、誰にでも見抜け且つ世に沢山あるのに、何故会計検査や内部統制が働かないか？
　その２：農水省事件は、2004～2008年度に処理された不正経理が427件、1億363万円に上るとされているが、この幼稚な手法が何故複数年も検査で見抜けないか？
　その３：経済活動の報告すら公認会計士や監査人、そしてJ-SOX、果ては金融商品取引法まで保有しながら、全体でうまく機能していない。のは何故か？
　その４：このようにこの記事書き出してからも、国の機関、県、市までいろいろなレベルで散見されるが、全国汚染されているのでないか？（尻抜けの会計システム）

今、全国的に公会計制度が浸透しつつあるが、その時のシステム化に当たって同時作業すれば、廉価に上記の「Fraud処理ロジック」を汲み込む事が可能である。

追記(2010/07/23)
もうこの項は、お役目ご免で削除対象を考えてた矢先、またまた続事件が発覚してしまった。
全国新聞でも地方欄での記載事項であり、当件も埋没する事となろうから、しばらく掲載を継続することにする。
上記までは、神奈川県不正経理総額が約２７億円の事件で、開示内容も上述の通りであったが、新たに約２．８億円の不正経理が発覚し、不正経理総額は約３３億円。
しかも、お膝元の県税務課や県警察組織も係わっているのは、開いた口が塞がらない。
ここでは「会計システムの設計概念を変える」提言をしてきたが、会計ソフトや抜き打ち検査、会計監査など事後の対処療法では、もはや打つ手無しの状況である。
悪しき習慣の意識を一掃すべく、全職員の総替え（公務員として聖域設けすぎ住民へのガバナンス感覚麻痺人間は、道路の空き缶清掃や介護支援１ヶ年の重労働を課す）
しか道ない。単なる減給や実費返還で済む問題でもない域に達したのでないか。
神奈川県は「不正経理による破綻団体」を宣言し、全員退職。代わりに隣県から数年職員の応援派遣を受入れる（すれば、隣県も職員人件費削減できる）なにより若い人達が、新しい仕事を体感するチャンスが到来する。住民はその間耐える。

神奈川県は幸い高齢者と言われる経験豊富な退職者が多数住居していてお手伝いする態勢が可能である。
その間で経理システムや関連付随システムの抜本的システムデザインを行う余裕を生み出さねばならない程、ITの活躍する「場」は無いのである。
自治体の首長は、今、自治体を民間が運営する都市（米国サンディ・スプリングス市のPPP;Public Privata Partnership）がある。その成功要因を解明し、そのコンセプト導入ができれば全面的意識改革となろう。
　※『自治体を民間が運営する都市』オリバー・W・ポーター著東洋大学PPP研究センター訳時事通信社刊ISBN978-4-7887-0967-6

【事件の顛末】
その１：岐阜県庁組織体全体を舞台に約45億の裏金つくりが裁判判決文中で記載されている。住民監査請求訴訟であったので敗訴されているが、判例には認識（全体の悪しき暗黙風土）・その裏金作りの方法も記載されている。監査機能をすり抜けたその方法は今後の「目の付け所」であろう。
その２：当神奈川県不正経理問題は、平成22年8月25日公金流用事件として詐欺罪に問われ、県税務課幹部２名に懲役3.5年、2年の懲役判決が言い渡された。（執行猶予は無い実刑判決）。（注）今回の裁判は、公金不正の全体組織態の行動を問うのでなく、立証に必要な私的流用の詐欺部分が裁かれているのみである。

またまた【残念なこと】
残念なことに、この欄を閉鎖しようと考えていた矢先に
「全国都道府県で不正経理」が発覚した・・・と朝日新聞（2010/10/4朝刊）が伝えている。
会計検査院の調べによると、平成20、21年度で、３８道府県と２政令指定都市で計約４０億円、平成19、20、21年度３ヶ年で約５０億円。
そして
2003～2008年度での不正経理要因を
　①将来の物品購入に流用するための架空発注して取引業者に金をプールさせておく「預け」
　②複数の物品を買った後に別名目でまとめて支払う「一括払い」
　③契約とは違う物品を納入させる「差し替え」
　④翌年度に買う物品を当年度に買う「翌年度納入」
　⑤前年度に買った物品を当年度に買ったことにする「前年度納入」
などの手口（古典的な決算越えの不正処理）を例示している。
これらは、不正を顕在化させる氷山の一角であろう、が、たとえ少額で自治会計の硬直性があろうとも何故このような初歩的ことが、内部・外部の毎年繰り返される監査で見出せなかったのか？不思議である。

仮にまだ続けられているとすれば、現場の知恵（？）は悪しき習慣であり、やはり不正経理の根本を助長する不正が常態化し感覚が麻痺しているのでないか。
『蟻の小さな穴でもダムは崩れる』。
高額な税金を使った会計監査員がこのような初歩的手口で翻弄されていては、大局を忘れさせる。また「監査」の質向上を期待する。平成22年10月10日記

このページの先頭へ
　

その15「入力ミス」と「ソフトを操る」組織風土

九州電力は、原発ストレステスト過程での耐震性評価に関する解析モデルで「入力ミス」によるテスト行程の追試を与儀なくされている。
　
報道^※１によると、『原発の耐震性に直結する非常に重要なデータが「誤入力」され、　誤ったデータは、九電が２００８年に国に提出した耐震安全性評価結果の中間評価で既に含まれており、九電も国もチェックが甘く３年以上も誤りに気づかなかった。その「誤入力」とは、重量を「２６００トン」とすべきところを「２６０トン」と入力。その１０倍も違う「誤入力」を保安院は「チェックすることができなかった」とされている。
そして『これまで原発を推進してきた経済産業省。その中にある「原子力安全保安院」が原発の安全性を評価しているという根本的な問題が浮き彫りになっている』と報道されているが、この問題に対しどこまで「対処療法的な手当」で終わるか？または真の「根本的解決」に迫ることができるか注視して行きたい。

素人目には「入力チェック」論理ロジックが甘かったようにみえる。一般的（恣意的な行為を除けば）にはこの「入力ミス」とまとめられてしまう現象は、３段階の工程でプログラムに送られる。①データそのものが全く間違えた価を扱った、②入力する時に原票にある認知情報を読み間違え：７と９、１と７等の手書き文字の読み間違い、そして頭では正しく認知したが「入力キー操作」時に頭と手操作が不一致であった「ヒューマン・エラー」、そして③入力チェック論理回路の要求範囲を逸脱したプログラム不完全による偽データの通過の３段階における機能を識別して語らねばならない）

データチェック論理回路は、その入力ルーティンの範囲幅を厳しくしたり、他の入力値との相関チェックを入れたりしてプログラムは修正されるであろうと誰も考えるであろうが、そこに大きなソフトを設計する人間とそのソフトを使う（操る）行為の人間行動に基本的な問題が隠されているのでないか。（ヒュマンエラーに関しては別項で考察）

そもそもコンピュターは、入力した価（データ）に従い、０か１で計算をし、結果を出力する簡単な道具である。入力値はデータ検知器でヂジタルに変換して機械的や、または人間が業務処理のために入力するのである。入力値が誤れば当然そのまま計算しそのまま処理結果をアウトプトすのがプログラムである。このことは最新処理技法といわれるデータを処理する「MapReduce」分散処理法や「CEP」(複合イベント処理)、ストリームデータ処理方法とて同じことである。

そしてこの入力部分は誤処理の元であるから、設計時の要件定義段階や詳細設計書でも定義書に事細かく記載（説明）される。ﾌﾟﾛｸﾞﾗﾏｰや設計者は機械オンチであり業務のプロでないから、現場で想起される誤入力例を書き繋ながれる、それはプログラム開発の最終段階のテストケースで生かされ品質保証の礎とのなるからである。このように入力データが本番業務処理を正しく処理するために設計段階から最大の注意が払われているのである。そして米国ISACAや本邦監査試験でも「監査の目の付け所」として重視されるポイントである。不正取引や不良行為のデータをも入口段階（フロントプロセッサ）で発見・補足し対応するのがEDP処理の常識パターンである。

よって「１桁違うデータの入力が業務処理まで通過してしまう」のは、普通の常識で考えれられない。そのプログラムを使う人間達がそこを通過するよう改竄しているまたは改良（改悪）している・・・と推測される由縁である。

そこでこのプロセス処理を一つのBoxに見立てそれを操作操る人間系を図示すると

　
　　

永年に渡る玄海原発での恣意的なデータ誤入力やみずほ証券１円誤発注事件、みずほ銀行大規模障害事象は、上図概要のように全く同一事象であり誤りを繰り返している。人間は誤りを犯す動物である、しかし「ドライバー」は、ネジ回しの道具であり武器ではない。マスコミ報道は単にコンピュータプロセスだけに注目が移っているが、処理結果を使う側のプレッシャに負けた赤線部分が存在する。事務処理効率化目的や許認可基準のクリアの為に恣意的な人間行動が原因になっている。

また東京電力は、福島第1原発事故の情報開示５月上旬なでの放射性物質分析結果発表に誤りがあったと、2011年08月30日驚くべき発表を行った（事故発生から５ヵ月超すぎ、広報発表から３ヵ月も経過）している。その内容は１㌔当りのセシウム放射線量の換算を１立方cmを１キロcmと換算した、またデータの転記ミスや誤った計算式を用いたケースがあった。とされ、いまさらながら。松本原子力立地本部長代理は「過去の資料を踏襲して間違いが継続した。ダブルチェックの仕組みをつくり再確認したい」と話している」
原子力を扱う「村人」は、原子力技術に長けていると過信し、このような基礎的な技術を蔑ろにする風土があるのでないか？

組織上層部は、組織態がこのような行動を採る企業文化と個人の倫理観に委ねたシステム全体の姿（統合デザイン）の隘路は（ともすれば人の挙動や振る舞い、場の空気を読む、モティベーションの有無等に注視するアナロジー）企業存続の危機に立たされることを識別して行きたいものである。

　※１玄海３、４号機に続き高浜原発３、４号機でもデータの入力ミスがあったと経済産業省原子力安全・保安院が2011/08/22発表した。
　　　さすがにマスコミ発表にも「データに入力や解析手法の再検討を指示」とある。と少し小出しにした。肝心のメルトダウン論理回路に入る入口でこんな状況では「ストレステスト」全体の品質が問題視される時がくるであろう。
　そもそも、基礎データである地震の「Ｍ：マグニチュード」表記は、気象庁が国際的批評を受け、日本独自基準から大衆には黙ってその基準を変えているのである。
　参考：気象庁ﾏｸﾞﾆﾁｭｰﾄ　http://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%B0%E3%83%8B%E3%83%81%E3%83%A5%E3%83%BC%E3%83%89

　※２　東京電力発表　『福島第一原子力発電所における核種分析結果の確報版の一部訂正について』　http://www.tepco.co.jp/cc/press/11083002-j.html

その16　文系のITバカと理系のITバカ

ITトラブル紛争の裁判沙汰をみると、
　　　①プログラム開発段階における紛争、
　　　②プログラム納入段階での顧客とベンダーの目標の違いが体感や計測されて齟齬が見えてきた段階、
　　　③納入後の運用段階において事故が顕在化しその要因をめぐる問題、
とコンピュータを動かすプログラムに起因する紛争が続いている。

※2012-06-21 （c） JA2ANX　n.inagaki IT-CPR研究会にて

とある紛争沙汰（東京地平16･3･10）では、PM遂行面でからプロジェクト遂行義務とユーザーの協力義務が争点となって本格的プログラム開発過程のPM遂行方法の対応性で争われているが、その裁判そののもを冷静に考えるに、それは「開発段階での技術力：Procese Technology」の問題であり、徹底的に実態を明らさまにし後続案件に教訓となれば良い。開発段階でのPM論は本邦におきPM資格の普及とその仕組みを取り入れるベンダーの仕事の合理性をもとめた活動でもあって習熟しつつある段階である。しかし、事件ではプロセス過程よりもそもそも双方の抱いている「夢」が異なっていた（恣意的に相手にダメージを与えるつもりでなくても結果裁判沙汰になって、その正当性を主張するため（自己の主張を立証するため））事に、起因しているケースが多と思われることが散見される。

そもそも、それはトップ同志の同上異夢であったり、美しい誤解であったりする事に起因することがあるのでないか！
ベンダー企業の上層部が理系出身が多く、ベンダー企業のトップは文系出身が多く、すれば本質的にIT案件にたいする基本的視点が異なっているのでないか？

例えば、ツルガ銀行-IBM事件（東京地平24･3･29）は超上流といわれる部分（契約時点での夢の錯誤にある：筆者の独断の見立て）原点の齟齬が内在したままプロジェクトが進めば進むほどその乖離は大きくなり双方の余裕度は無くなり「頓挫」が必然的に起きた事案である。
基幹系システムを海外系ソストパッケージを適応しようとしたところ、それを見抜けず容認してしまったところに原因がある。

トップ同士の握手は、美しい誤解をいだいたまま（水と油で美味しいケーキを夢見た：BPR、Fit&Gap、BRDだの美しい用語で作業を繰り返しているが所詮混ざり合うものでない）。その齟齬なぜ起きたか！
　　
失敗を再び繰り返さないため「IT判例の行間から読み取るべき教訓を知見としたい」
日本人の行っている契約行為や合意像が「如何に曖昧いであったか」。
その美しい「あいまいさ」を生んだ素は、どうも日本人特有の日本文化に宿る源流にあろう。

※2012-06-21 （c） JA2ANX　n.inagaki IT-ADRセンター IT-CPR研究会にて

その17　プロジェクト頓挫における真の原因

IT裁判ではプログラム開発を伴うプロジェクト頓挫が多い。双方がプロジェクト運用の可否を相手の義務違反として争点となっているケースが多い。また、裁判にならなくともプロジェクトの失敗は多いと聞く、それらを眺めていると、走りだしたプロジェクトは双方の企業・組織内に持つ余裕度を越えた場合コンフリクト状態になり、そもそも争点になる要因はKick-offパーティ（プロジェクト参加者の心を一つにモティベーション向上策と称されているが、このような形をとる処がもめている皮肉さが存在している）以前に、真の問題が潜在していたことがわかる。
　
双方に保有するプロジェクト余裕度（さすが最近１円受注は陰を潜めているが開発現場は原価割れで、営業は見積り技法を磨いている企業もある。またユーザーは当初契約期間が大幅に遅れたすえ２～３倍の価格を支払わされているケースも多い）を越えた場合パンクするのである。

プロジェクト頓挫は、そのプロジェクトの余裕度曲線（1/3図参照）で説明できる。
その真の原因は、源流にあり双方の『夢』が異夢であったことが後付けで分かってくる。（2/3図参照）
　　（恋愛は美しい誤解であり結婚は惨憺たる理解である）では高い授業料代となる。
IT技術者は、機械やOSが欧米コンセプト設計であるので、その中間ソフトも欧米製品が担いでいる、その上に業務アプリも設計や開発手法がPMBOKやBABOKなど欧米文化を基礎とした借り物であり、日本的論理構造に馴染まない部分がある。
「見える化」と称して、多大の書類を山にして満足感を味わっていると、J-SOX導入時と同じ失敗を重ねる。
プロジェクトの失敗と成功を対比して、何が違うか外観したい。（3/3図参照）

その18　テーマ：銀行業業務のクラウドに対する不安と「銀行業の信頼性」の研究

まず「不安」が何んであるか？何を意味しているか？この抽象的な語彙を解剖してみる必要がある。
まず「銀行」なのか? 「銀行業」なのか、を峻別せねばならない。

「銀行業」は
①：銀行組織が国家体制として法的な（保護と縛り）で成立っている。
　　最後の砦の倒産防止（預金保険加入が義務、監督官庁の指導行政庇護、国際的BIS体制下）
　　　　　→弱いところはどんどん吸収合併で市場から排除され、クリームスキミングが有効利

②：顧客行動が、同一人の顧客リテンション構造に支えられているので効率的経営が可能
　　　　　上層客セグメント内の繰り返し（収益）行動がコンピュター処理にマッチしている。
　　　　　派手な過剰利益主義に走らないとの失敗の知恵が生かされている
　　　　　→（トヨタの石田語録を銀行が愚直に行っているだけ）

③：国民生活の最後の「お尻」である決済機能をになっている。
　　　　　このため永年の紙の洪水処理や１円まで間違わない企業文化の醸成、永年維持結果。
　　　　　 →世の中、誰もやらない汚い尻拭きを愚直に続けるが結果として信頼になる

こんなところが拙者の銀行業に対する信頼性イメージの基盤・源泉です。
よって、これらを形態を支えるデータクラウド技術は必須でしょう。

そして「銀行」は
① 倒産する自由をもっていない。
　　　　監督官庁の検査で、財務面から債務超過状態に陥れば指標改善の努力が優先された経営となり、最終の姿は「吸収合併」。
　　　　逆に他業界からの参入障壁は高いので、サービスが劣化しない限り顧客が激減することはない。
　　　　 →戦後の銀行行政下でバブル期の犯罪的融資毀損以外に、危機に陥った銀行は「風評被害」による取付け騒ぎしかない。

② 業務の新規開発は制約が多く、独自性は同業他社も容易に追随されやすいので差別化が見出し難い組織態である。
　　　　経営は永年蓄積の信頼性安心性の資産があり、金利体系で利ザヤが確保され、手数料競争は硬直的で競争的でない。
　　　よって如何に物件費が縮小できるかが経営の主要なコントロール領域である。物件費の大宗を占めるのがコンピュータ費用である。
　　　そのコンピュータ費用はシステム要員や機械化投資のタイミング利用の巧妙術が鍵となる。（サービス水準は顧客から横並びを要求されている）
　　　　→物件費割合を時系列展開でみると、機械化が経営における自由度を増している事が鮮明にわかる。
　　　　　※『「資金決済」「電子債権」の２法律が銀行に与える影響』　５頁第１表　地銀対都銀の物件費比率の項･･･・ PDF約1MB

③ 長期思考で組立てられた銀行業信頼のシステム構築とは！
　　　銀行行に対する庶民の期待は、証券業務と異なっており「儲けるた時は自分の能力、損した時はあなたが悪い」の感情はない
　　　　　　・・・安心して取引できるシステムだ。
　　　　　過剰サービスとも思われるほど愚直ば業務（逆ふり伝票処理、高額平残保有の高所得層も部落問題も公平なサービス時間で対応している）の積重ね。
　　　　　裏に隠れた伝票類や申込書等証憑類の巨大アーカイブ保存データの保有（皆様の睡眠口座もいつでも解約できる）国民の資産のひとつである。
　　 ※金融業のコンピュータ利用の歴史から展望する柔軟構造の銀行システム構造（証券業と比較して））　・・・・・　PDF約170KB

銀行のコンピュターシステムは、３大業務（預金・貸金・為替）の派生商品で１００種類程度の商品群を扱い、非機能部分と称される機能は、数百万から数千万口座の元帳を、オンライン応答は数秒で返事、深夜、日が変わるときの日繰処理（数分間で日付を全て替える処理）且つ日中のオン処理中にその数倍のオン中引き落としトランザクション処理、そして７D24H運用し、ダウンしたら新聞沙汰で庶民の批判を浴びる、決済金額が３時に到達しないと相手が残高不足で倒産（債務超過）の危険性が発生する。このようなシステム予件に加え保守や１円誤差を許されない品質維持が絶対のシステムである。国民が安心してお金のやり取りのこのシステムは「クラウド」のごとくである。
　一方、米国社会では相変わらず個人家庭で個々の小切手引落としの金額をチェックしなければならない風習（銀行処理を信用しなく、最終的責任は自分が判断する権利身に体感しなければ納得感が得られない風習）この時間負担を国民全体が割いている。決済になにも疑問を感じなく自分の口座から安心して引落としする（MicroPayment部分はICカードでトランザクションの収集、正当性が別組織で精製されるウエートが増えつつあるが、最終尻は銀行口座が担っている）この金融基盤シシテムは国民経済的な労力負担軽減は「空気」のようであるが、図りしれない国の生産効率化機能を支えているのである。
　人間の「体内血流」と同じ、国の資金流を引受けている姿が、たとえハードウエア機械がどこにあろうが庶民感覚では関係ないのであり、機械がどんな場所や形態変化でクラウド化があっても、その役割は見失う事はなかろう。

クラウド業も、「利用側に立った信頼性を確保できた上でその提供がクラウドをアクセスできる鍵」とも見えてきませんか。

その19　本邦司法界も「ウォーターフォールの呪縛」から抜け出そう！

残念であるのは、プログラム開発に係わるＩＴ紛争の争点が、数KステップのＮＣ工作機や遊戯機器の組込ソフトであろうと、業務処理プログラムであろうと、国のクリティカル部分を担う数百万ステップの根幹巨大システムであろうと、「プログラム開発」の手法がウォーターフォール型開発手法の概念一つで論議が進んでいることに慚愧に耐えない思いがある。
本邦では、ITの紛争トラブルが生じても裁判前の経済合理的かどうか？の判断で現場で「大人の解決」を選択し、最後の砦である裁判俎上に上がる例は極めてまれである。
事の収束は、技術論の戦いは司法の場に馴染まないとしてほとんど和解で結末を迎える。
しかし、ITの判例も少しずつであるが、積み重ねられている。

本格的なIT判例の解説・評釈が無い。
拙者の手元にあるのでは
　１：『コンピュタ・プログラム関係判例概観(上)(下)』千葉地方裁判所判事補夏井高人判タ No.670(1988.9.15)
　２：『システム開発契約の裁判実務からみた問題点』東京高等裁判所判事滝澤考臣判タNo.1317(2010.4.15)
　３：『ソフトウェア開発に関する法的紛争処理について』日本弁護士連合会　日弁連特別研修テキスト 2007/11/27
がある。

判例解説も技術的進化に伴い時代変化で３代目に突入している。
第１世代に相当する書籍１は、余りにも技術的背景が古典的なシステムを基盤として（オフコンと称す事務用機や装置のROMに焼き着けるアセンブラー内臓型等）で開発規模や開発手法も手作業で汗かきかき手作りの俗人的SEが支えていた時代的事案であり、昨今の紛争と同一視点で語れない。
第２世代に相当する書籍２は、コンピュータの利用形態が、自社組織内に設置されそのソフト開発をベンダーが支える。また利用形態が同業の企業同士がてを結んで開発そして運用で１/ｎの経済効率性を求めた共同型。請負契約形態から委託開発、そしてマネージメント義務が認識され争点の中核となってその解釈で判断が分かれている。
そして
主張、立証に困窮を極め、争点まとめすら弁護士が提示しないと長時間の無駄が生じてきた。また著名なIT事件がセンセーショナルに報道されたのを受け、またユ＾ザーベンダーともにますます肥大化、複雑化し要求レベルが上がる、その反面SEの質は３K職場と称されコンフリクトが生じやすくなってきたので、弁護士のIT技術スキル向上を目指した弁護士研修テキストが出版された。ただ第１世代の古典的事案もの、規模・複雑性も運用（時間つきぬけ、や連携プロトコルそしてUSBメモリーなど外部持ち出し等想像外の利用道具の広がり）面から起因する紛争も目だってコンフリクト形態も多様化してきた。

上記の判例を眺めていると、米国の判例法理念基づく判決と本邦成文法化のシステムに係わる紛争の裁きが大変苦労されているのがわかる。
ITのtecnologyは、日進月歩そしてその立証を裏付けるに必要なる法的適応（解釈）に困窮を極めている。
それは、上記書籍資料の判例の争点を眺めその結論では、しっくりと腹にしまうことが出来ないもどかしさを抱えたまま決着をみている姿がある。
その大きな要因に『プログラム開発』の手法に「SDLC開発」が金科玉条のごとく扱われているところに起因する。

本邦のプログラム開発頓挫の主張・反論のプログラム開発案件は、この「SDLC：System development life cycle」が司法に携る方々の考え方のベースとなっている。
この手法は米国で約4～50年前に開発頓挫問題が多発し、開発案件に一定のルールを見出しその手法を広めるところに意義を認めようとベンダーのリスク回避策の合理的判断でその流行があつたので、古典的な典型的開発手法とされているところにある。
SDLC開発手法が成功するのは→「時間がたっても変化しない正確な情報に基づいて計画されたときのみである」。つまり作業が十分に理解されており、比較的安定して、計画が変わらないときだけ有効だ。この開発プロセスは未知で予測不可能なものに対応するために作られたものでない。伝統的な製造業の多くはこのSDLC開発モデルが有効理に導入されている。・・・この根本を対象とする事案が適切な業務形態であるか？の基本軸の検証を忘れては、すべての絵は砂上の楼閣となろう。

本邦法曹界は、早くこのSDLCの呪縛から開放され、いつまでも「要求定義が固まれば開発案件の品質がよくなる」思考から脱却すべきであろう。
現実に成功プロジェクトのケースを分析し、新しい規範・ルール作りにもコンピュータ学者・学会も注目すべきでないか。
製造業の強みは、テラーのラインコントロールから脱却し、Sonyの小牧工場（小林）スタイルそしてJITやかいぜん運動運動、サプライチェン等組織運用を米国文化のように細分化しその小ロットを上から目線で制御する管理者がいて、金が人を動かすプロジェクトを成功させる主要因と考える狩猟民族文化にない、モチベーション向上が人間行動の要であるとする日本の文化に注視すべきでないか。
その意味で「アジャイル開発」手法の現場適用の有効性に注視した『スクラムによるアジャイルな組織変革”成功”ガイド』は司法界、パラリーガル人間のみならず、ITに携っている人達もおおきな視点変革をあたえてくれるであろう。

司法界の関係者の方々「ウォーターホール型開発」、「V型モデル」は過去技術遺産であり、その呪縛から、早く抜け出そう！でありませんか。