豊洲：震災影響と関東計画停電

地震とその災害被害が凄まじいですね．．．

（2011.3/14 10:05追記）
第一第二グループの計画停電は中止だとか。10時のｔｖｋ放送で発表。
ということは通電はやってるのに神奈川は電車だけが止まっている状態。
川崎駅の状況↓
http://plaza.rakuten.co.jp/ntdtks/diary/201103140000/
ｔｖｋ中継の横浜駅も現在大混雑でした。
10:02の茨城県沖地震は、エリアメールが1秒前にちゃんと警報してくれた。機能するとは珍しい。

■豊洲では地面が割れて泥が吹き出す

３／１１の大震災のとき、豊洲の職場で仕事してました。
比較的新しいビルなので耐震構造になっているだろうと勝手に思い込んで避難とかしませんでしたが
あまりにも揺れが大きくて床に座り込んでいました。立っているのが難しい。
ちゃんと机の下に隠れる人も居ましたが、天井崩落は無かったし、
蛍光灯も割れないし吊り下げ型でなくシャンデリアのように落ちなかった。
中には椅子に座って会議続行するグループも（汗
しかし近所の駐車場が避難場所なんですが、臨海の宿命か道路が割れたり地中から泥水が吹き出ていた。
水道管破裂か透明な水を大量に吹き出しているところも。
これでは避難場所にならない。
なので、周りのビルでもあまり人が外に出てこなくて、中に居ろとビルから指示されたのが多いようで。
高層ビルなんか階段で降りての避難は難しいでしょうし。
そのあと余震が続く中、みんな仕事を続けました。
なんせ電気が途絶しなかったのは大きい。東京電力頑張った。
それにうちの提供システムは全国規模なので、すぐに全都道府県のサーバ死活をチェック、
当然のように東北被害地域は遠隔モニタ不能。電話も繋がらない。
そんな中、週末で全国のサーバ入れ替え作業がもともと計画されており、それは実施することに。
無事な地域だけでもデータ移行とかするわけですが、
当初金曜夜間から来る予定のメンバが出社できない。
そこで首都圏で職場待機になった私たちが代理で対応することに。

土曜に外を見ると、ＮＢＦビル付近は泥やコンクリートで灰色水だらけで隆起や陥没してました。
タイル舗装が弱いっぽい。
浦安あたりも液状化現象なっていたようだし。
玄関に段差になっているビルもあった。＞ＴＧＦビル
建物の床に免震構造があって地表と寸断されたんでしょう。
以前にデータセンターを見学したとき、地下一階の免震を見たのですが、
ゴム支柱に支えられて浮いているんですね＞一階より上は。
一階と地下一階の階段は非接触になっていました。くっついていると引っ張られますからね。
ＴＧＦビルは割れ目を見ると免震床っぽいのが地中にみえてました。

みんな考えることは同じのようで帰宅をあきらめ籠城戦、
金曜からコンビニとかは食料からっぽ。私はたまたまカップ麺とか残業多いので貯めこんでました。
職場では非常食も振舞われ？ました。いつもは期限切れで捨てていたのが役に立つ。

ＪＲ東が金曜の復旧を断念したのはびっくり。地下鉄のほうが再開早いとは。
地下の方がダメージ小さいのか？
翌朝もなかなかＪＲが始発計画を発表しないので、始発での帰宅はできず、昼に帰りました。
京急も土曜朝に再開で東京から神奈川に行く鉄道がなかったので
土曜昼は地上鉄道は混雑してました。
東京は食料がなかったので、川崎駅で降りたら、駅ビルＢＥは営業停止してるし、
松屋やオリジン弁当も食材無しで売ってない。やよい軒やガスト、なか卯は営業していた。
そこは在庫の差だったのだろう。
日曜に入荷できたところもあるが、日曜でもパンや弁当はどこもすぐ売り切れて私は買えず。
電池とかも無い。
帰宅しての自宅の被害は、観葉植物が落下で鉢が２個割れただけでした。
パソコンとかよくまぁ机から落ちなかったなぁ．．．

■計画停電　at　神奈川

食料不足のなか、私の地区はグループ４の計画停電に。
昼間は会社に居るのでなんとかなるかな。ＪＲは別電源なので運転するんだよね？
一番電気食いそうな東京都区は首都機能や本店機能があるのでさすがに停電できないのも仕方ない。
ほんとヤシマ作戦として心をひとつにして乗り切らないと。
しかしいつまで続くのか。停電だと冷蔵庫で長期保存ができないし、
コンビニとかの冷凍冷蔵ものも停電時間帯はお店どうするんだろう？
地震でも桜は綺麗に咲いています
壁紙は震災ネット募金するとniftyでもらえた壁紙。

ＩＴとして悲しい岡崎市中央図書館事件

今更感のある話ですが、逮捕のニュース以降ずっと見守っている事案です。
逮捕するほど、容疑者を長期間に渡り取り調べるほど、すごいクラッカー犯罪かと思ったら、実はそうでなかった、よくあるプログラム情報収集であった、と。

■警察はなんでそんあ意地になって逮捕したのか
自動巡回で収集して逮捕なんてひどい。県警のＩＴへの無知さ、一人くらい「このアクセスで応答不能になるシステムはおかしい」と警察で思う人が居なかったのか。

■MDISのバグ
状況証拠だけながらも「念力デバッグ」という手法で応答不能の事実を突き止めることに成功。その裏付けにはアノニマスで全世界に公開中であった図書館システムのプログラム本体というオマケ付き。
三菱も図書館も不具合でない！と主張するなら、他県でのバージョンアップ版はあれは改修ではないのか。改修でなくインターフェースで色を変えた程度の「変更」だと言うのか。
自社プログラムがまっとうなら変更する必要は皆無だろうに。
そうした修正の履歴をMDISに問うたらなんと答えるのだろう。誰か訊いてないのかな。

■図書館長も愛知県警も逃げ切ってしまうのか
ネットでさんざん非難をあびせられても逮捕に仕向けた側は痛い思いも反省訂正もしない。
岡崎市、市議会、市民レベルでおかしいという動きにならないのだろうか。議会では話題に上がったようですが．．．どうだろうなあ。
ネットでどう言っても、朝日新聞に載っても、逮捕した者勝ちで終わりそうで悲しいです。
館長の許可無いＷＥＢアクセスは逮捕されるかもってひどすぎで、これだけはさすがに訂正したようで。

こういうふうに疑念側で書いてますが、私もエンジニアの端くれであり、自分のシステムの不手際で、エラーのトリガーを引いた利用者を逮捕、自分のバグを「ネットに提供するけどネットの情勢を見極めきれ無かった結果としての仕様です」なんて名誉にかけて言えない、そんな恥ずかしいことは。
うちの会社の今の担当のシステムだって膨大なデータアクセスなのでレスポンスが悪いのだけど、どんなデータ量だろうがすぐに返答できるように、バグではないしちゃんと動いているがＤＢ構成とかクエリとか見直ししてよりよくしようとしているのに。
MDISのＷＥＢに公式見解でも「バグを隠して逮捕に　仕向けましたごめん」と言わなかったので、社長含めてそういう体質だと理解した。
つか、そう他社ＳＩerから理解されてしまうの分かってるのに、ああいう見解を掲載したというのが怖い。
うちの会社では協業したくない．．．＞ＭＤＩＳ
うちの会社だってシステム不具合で時々にニュースに出されて、不具合でご迷惑おかけしましたと謝っているが、予算や仕様決定で反論したい余地はあるが、うちが悪い直そうと思う気持ちがちゃんとあるわけで。
それなりに歴史のあるコンピュータシステム、異常データや想定値超えでシステムがダウンすることがあり、そのたびにダウンの原因を見つけて改修してきているはず。コンピュータもプログラムもリプレースや変更がしやすい性質だから。
この会社は1000セッションを超えた1001番目のアクセス処理予防することなく、1001番目のアクセス者を犯罪者として指差すのか。（で、裏でこっそりロジック直す）

■念力デバッグ
私も、このハングアップは、ＣＰＵやディスクの物理的リソースパンクではないなあと思ってましたが、論理的な設計ミスで論理的に１００％再現できる不具合が原因のようで＞当のMDISは説明してないけど。
「サーバ管理者日誌」で推論でシステムの概要を見事とらえ、問題点を指摘した「念力デバッグ」は興味深い。
警察ドラマでのプロファイリングと同じか。いやあれよりも論理的に進めることができる。
設計書仕様書読んでもわからんことはよくあって、挙動からルーチンを推測するってエンジニアにはよくあることではないでしょうか。

■『サーバ管理者日誌』LibraHackカテゴリ記事一覧
http://www.nantoka.com/~kei/diary/title.cgi?CAT=LibraHack
なんとか株式会社代表のブログ、高木氏も感心する念力デバッグな洞察力と、ＩＴコンサル的に問題の根幹への鋭い指摘はなかなかのもの。
代表の前田氏は、長崎県のビジネスコンペで優秀賞を取って資金提供を受け事業を起こしたこともあったんでしたっけ。

■自治体のＩＴ能力
図書館長さんがＩＴに詳しくないのは仕方がないが、おかしいことへの気づきや訂正は別問題でしょう。
市のＩＴ推進課も「逮捕したれー！」と押せ押せだったんでしょうか。少しはＩＴに通じるなら、自治体職員なら変な評判立てたくないから慎重に穏便にで逮捕まではしないとかならなかったのでしょうか。

私はアドバイザーで自治体ＩＴ推進支援もしてましたが、これの歯止めができていたらなぁ。
私が居た県では、市や町のシステムトラブルが上がってきて、そのたびにそれなりに助言をしてきたつもりですが、中ではクラッキングもありましたけど防護とか、なんでつけこまれたか、は考えましたが、逮捕するというベクトルには向かなかったけどなあ？
だって、犯人探しで警察とか新聞沙汰とか日経あたりの取材とか、総務省ＩＴ担当者が来るとか、オオゴトになるのを避けるベクトル、ハッキングされて恥ずかしいからむしろ隠したい、システムを作ったベンダーには怒りをもって早く改修対策させる！ベンダーもオオゴトいやなので追随　って流れかと思ってました。
今回のMDISはログとか警察に提示しながら、被害者ぶっていかにアクセス者が悪者かをＩＴに詳しくない警察に協力していたわけで。
あとで自社でとうの昔に不具合として改修してるのバレるのに。
ほんと、恥ずかしいバグじゃないならなんで直したのか、全システムに改修してまわらずひっそり流通させてたのかとMDISに問いたい。

わたしの居た自治体やベンダーのようなところばかりでないのですねぇ。悲しい時代です。

またもATM提携障害。システム統合でトラブル 三菱東京ＵＦＪ銀

http://headlines.yahoo.co.jp/hl?clu=20080512-00000907-san-bus_all
事故は検討会議室じゃない、現場ＡＴＭで起こってしまったんだ！

6000人のエンジニアとかあり得ない規模での移行作業、膨大な検討とチェックをしたはずなのに初日にすぐに起こりえる発生条件を誰も予想もテストもしていなかったそうで。
空港システムとかSUICAとかメモリのアドレス参照障害とか、機器の能力不足でボトルネックとか、そういうのよりもカバーしやすい範疇だと思うのです＞漢字とカタカナの文字不整合
それでも気付かなかったんですねぇ。
きっとみんなたいへん仕事頑張ってきたんだろうなぁと同業者として応援する立場でしたので、万単位の顧客にトラブルとは残念な結果です。

自称疫病神な谷島編集長のジンクスがここでも発動したのでしょうか…（汗
http://itpro.nikkeibp.co.jp/article/OPINION/20080423/299886/
前に取り上げたＡＴＭトラブルでのあの話…やはり歴史は繰り返すのか。
2004.03　テストではバグがあることは示せるがバグがないことは証明できない
ポイントは、今回もテストが悪いんじゃない。テストにすら乗らなかったというもっと前段階でハズしていたんですね。
谷島編集長の恐れたとおり、マスコミはこのニュースたくさん取り上げているようです。

明日は我が身…ガクブル

新銀行東京のシステムの問題

■新銀行東京は金を食う
　
http://headlines.yahoo.co.jp/hl?a=20080317-00000055-yom-soci&kz=soci
「新銀行東京、システム費用に１２４億円…過大投資の指摘も」読売新聞

経営難に陥っている新銀行東京（東京都千代田区）が、預金や融資業務用システムの費用として、総額１２４億円を投入していたことが都の調べでわかった。
　システムは、２００５年の開業前、都が作った基本計画に基づき設計されたが、預金や融資規模が当初の想定を大きく下回ったため必要性は薄れている。「過大なシステム投資が赤字の一因」（都議）との指摘があり、４００億円の追加出資案を審議する都議会でも焦点の一つに浮上している。
　新銀行のシステムは、預金と融資、ＡＴＭ（現金自動預け払い機）や、顧客の電話相談などに応じるコールセンターが取り扱う情報などを管理している。

本業で儲かってない話と並行して、運営自体の経費がかかりすぎている問題、人件費がかかっているニュースがありましたが、今度はシステムも過剰だという話。
建物やＡＴＭや人員は減らし始めているようですが、システムも縮小するのだろうか。
機器のグレードやソフトウェアの処理能力を下げるのもひとつの改修なので費用取られるだろうし。
そうした費用の問題とは別に、システムの構造や運営に問題アリと実は昔から指摘されている話。

■銀行システムはＮＴＴコミュニケーションズらしいが…

http://slashdot.jp/~von_yosukeyan/journal/299467

新東京のＩＴシステムを調べると上記日記を見つけました。
開発委託はＮＴＴコミュニケーションズのようで、これまた典型的な問題ある銀行システムの造りをしているようで。
システムはパッケージ日立製「NEXTBASE」で、これの元はＮＴＴデータからのライセンスでＮＴＴコミュニケーションズが拡張改造しているらしい。
それはいいとして、ネットバンキングの造りが甘いというかやばいというか、注意喚起を新銀行でないドメインからメールするし、メール内に顧客情報を管理用に載せているし、データセンタのドメインも違うので折角セーフティパスでセキュアログインしても接続先が偽サイトかどうかを証明書やＵＲＬで確認できないという。

http://slashdot.jp/journal.pl?op=display&id=298348&uid=3718
http://slashdot.jp/journal.pl?op=display&uid=3718&id=298204

ＵＲＬアドレス欄を隠すのは止めて欲しいものです。
クロネコヤマトでパスワードとＩＣカードリーダが送付されてきたようですが、機器とパスワード情報が一緒に送られてくるのも良くない気がしますが、パスワードは信書の配達に抵触する気が私もします。
さらに新銀行とＮＴＴコミュのネットバンク設定に対するサポート電話対応振りがこれまた典型的な…（以下略
これは２００５年５月の情報ですので、今は改善されているのでしょうか。
高木先生も地方銀行のネットバンキングのお粗末振りを昔から繰り返し指摘していますが、開発する側は知ったことではないようで。

NTTが救った東証CIO、公募するも応募者ゼロの窮地

これがまさに『火中の栗を拾う』ってやつでしょうか。

- nikkeibp.jp - 企業・経営
NTTが救った東証CIO、公募するも応募者ゼロの窮地

トラブル続きの東京証券取引所に2月1日、CIO（最高情報責任者）としてNTTデータ・フォース出身の鈴木義伯氏が就任する。
昨年12月に東証の西室泰三社長兼会長が突然発表した「CIOを公募」という異例の人事は、約1カ月であっさり決着したように見える。
だがその舞台裏は、応募者が誰もおらず、西室会長自らNTTに依頼してようやく決まった難航人事だった。しかもNTT内でも「誰もやりたがらない」（NTTグループ幹部）という状況下で、関係者が奔走して決めたドタバタ劇だった。

ただの偉い人を招聘しても実効性がないので、偉い＋実績＋第三者な資格もあるという人材が必要。そんな人がいたら東証に派遣せずに自社に置きたいでしょう(笑)。
今回はデータフォースの社長さんなのですから、その自分の城を離れてまで救援に行く心境察してあまりあるところです。
国際監査資格もある実力のある人を社外に出すのは人財的損失で痛いところ。

記事では「これでＮＴＴデータが東証に食い込めるビジネスチャンス」と書いていますが、実際はそうはいかないものです。
大手ＩＴ企業の人ならおわかりでしょうが、大手ベンダーは開発で官公庁にお伺いするのとは別に、社員を公務員として官公庁に派遣、逆に公務員を社内に受け入れて社員として従事させる、という交流人事をやっています。

総務省２００５年の交流状況
http://www.soumu.go.jp/s-news/2005/050330_4.html

さすがにCIOレベルでは滅多にやりませんが、お付き合いのためにお客様にノウハウを提供貢献するという、江戸時代の参勤交代な習慣があります。
「これで大手ベンダーが有利になるのだからずるい」と言われそうですが、実際はそのように後ろ指さされるので自重するのが実態かと。
自社が職員派遣した部署では自社のシステムの売り込みは消極的になってしまいます。その社員出向がいかに社会的貢献で儲け主義でないという自社の懐の広さをアピールするためには、営業をセットにできないわけです。
派遣社員は公務員職員の名刺＆身分で従事し、時にはライバル会社の提案システムを審査することもあり、当然職員になりきって出向先の最適ソリューションを求める行動をとります。イジワルとかせずに。
（イジワルせずとも無責任な営業には反撃を。MSaccess97当時の業務アプリをXPで動かすに改造何百万円とか言ってくる。「へぇ、じゃあなんでaccess97のmdbはXPでそのまま動かないの？」と返すと答えられない。そういう用心棒？として公共団体は人材受入したりしてるわけです）
そういうふうにできるのも、大企業からの派遣だから自分ひとりがライバル会社に有利に融通したところで自社から文句は来ない保証があるから。
ライバル会社も「なんで職員の中にやたらＩＴに詳しい奴がいるんだ？これはうかつな事言えないぞ」とか緊張してくれる＆騙せない効果もあり。
官公庁以外でも、外郭団体や地方公共団体でもそういう人事交流をやっています。
程度は小さくても民間同士の交流もあります。
外国から日本企業に技術研修に来ますが、あれもタダ当然で外国に技術を渡しているわけですが、国家間交流として特許や国際競争とか言ってられない事情があるわけで。
なのでライバル企業でも敵対視ばかりしてなくて部分的には社会全体のために協同したりする。

ＮＴＴグループもそういう交流の伝統があるので、
あんまり旨みがない、いや、逆にリスクが高いだろう派遣を今回ＯＫしたんでしょうね。
元から証券システムに強いわけじゃないし、東証のシステム作るとなったらＮＴＴの名誉にかかわるので採算度外視してでも完成度を非常に高める必要があるし。
ＣＩＯの下には何人かＮＴＴ社員を付けて派遣するらしいですが、彼らの給与は東証が負担するとしても、ＣＩＯ活動でつぎ込むノウハウやマンパワーはＮＴＴデータ側の手弁当自前持ちになるんでしょうねえ。

最上級人材提供による機会損失＆儲からない話ですが、そういう話も請け負うことで社会的貢献し間接的に自社のアピールになる。そうしたまどろっこしい活動ができるのも大企業ならでは。
私も、とある身分で活動しておりますので、今回の話を「うわあ、大変そうだなぁ」と人一倍感じている次第です。

今の東証社長さんも東芝由来なわけで、東証自体に本当に自力で責任取れる人材が社内に居ないの？というところからして東証の体制の弱さが垣間見え、そんな組織に重要システムを任せている日本も…。
あまりにも心許ないのでＩＴベンダーや証券会社もゆくゆくは自分のためにと協力しそうですが、まさかＣＩＯ公募がゼロだったとは。

拾おうとしている火中の栗は、炭化しちゃっているので誰も欲しがらないのかもしれない…

東証システムとガソリンスタンド裏の原子炉

相変わらず手厳しい大前先生で、ネットでも先生の記事にはツッコミが多かったり、一方で友人が熱心なファンだったりします。
そんな大前さんの最新コラムで先の東証トラブルでシステム構築についての話題。
企業リスク対策（第13回）[大前研一氏]/SAFETY JAPAN 2005/日経BP社
現場で作業をする者にとっては指示や激励が「ちゃんとやれ」「しっかりやれ」とか冠がついていると聞く側は、やれと言うのと比べて何が違うのかと小一時間問いたいところ。そんな指示よりも、もっと具体的な仕様をくださいよ…。

だから一連の報道で「東証のシステムはけしからん」というのは正しくはあるが、普通に当たり前を言っているわけであって、それを読む庶民と同じレベル。社説に「しっかりしてほしいものだ」とか書かれても、東証側も「わかっとるわい！」と言い返したいでしょう(笑)。
そんな中で大前さんは具体的な従来体制の構造を指摘し、どのように刷新すべきかを提言しており、単純批判記事ばかりな中で光っています。
特にシステム仕様機能の策定に外国の意見をも取り入れたほうがいいというのは他では見かけなかったアイデア。
今や日本だけの利用ではないシステムですから外国銀行や証券の意向も聞く分には意味があるでしょう。

今回の記事で一番印象に残ったのは、原子炉建設の安全性担保の手法のエピソード。
法律とか規則とかに即したシステムづくりではなく、実際に使った立場からのシステムづくりとして興味深い。
ルールにだけ従った原子炉システムを貴方は自分の裏庭に建設許可できるだろうか？
ちなみに私なんかがプログラムやハードを調達するときは将来の変更拡張を見越して、コンポーネントに小分けした機構にします（余力があれば、ですけど）。こうすれば部分的に差し替えて対応できるからです。別にお客様の改修コストを抑えようとかでなく、自分が変更作業するのでラクをしたいからなんですけどね。エラーメッセージも発生箇所を特定できるように細かく分類したり。
だから言われたとおりに作るのは長い目で見て損だと、現場の誰もがとうに気付いてはいるのでしょうがなかなか…。

MITの原子力工学部の名物教授で、マンハッタン計画にも参画しているトムプソン教授の言葉を思い出す。彼は私達大学院の学生に原子炉の安全に関しての講義の中で、「一番基本的なことは開発技術者としての知識を云々するよりも、当該原子炉を自分の家の裏に作る、という前提で物事を考えること」という教えであった。自分の裏庭なら、絶対にやらないこと、法律にあるから、とか、依頼主の要望だから、と言うのではなく最愛の家族の住む家の裏に建てられないようなものは設計してはいけない、という教えである。彼は実際にMITの原子炉を後者の隣、ガソリンスタンドの裏に建設した。

証券取引所の能力格差

(2006.1.22補足)
朝日によれば、今回の限界の理由は売買でなく清算システムの上限にかかっていたためで、
そのシステムは日立で１０年前のシステムらしい。
http://www.asahi.com/business/update/0122/002.html
１０年前の機種って、本当に１０年前のままなの？１０年前に開発されてハードは徐々に更改されてるので実は新しいというのでもない？？
公共団体さえも汎用機は５年経てば新機種に替えているのに東証ほどの企業が変えないのも？？
汎用機は名前が汎用だけあって、１０年前のプログラムを単純に新機種の上で走らせるだけでも高速化できそうなのに？価格が高いぶん互換性もメーカーが保証してくれるだろうに？
私が触ってきた富士通のはＭＳＰからＸＳＰへＯＳ自体が変わってもCOBOLはリコンパイルで動いたし。（ＪＣＬはコマンド名変わったので置換したけど）。
HITACHI製もそれくらいできそうなもの。それさえも東証はケチってたのだろうか？
サーバの台頭で汎用機も値下げ圧力で「高性能だけど変わらない価格」な相場なので、リースやレンタルなら同じ利用料金で新機種に変更できるので、リプレースも進みやすいと思っていたのですが…

(2006.1.20)
アメリカ、日本、イギリス、そこは世界でも取引量が多い地域ですが、
1/20日経紙面によれば、その国の有名どころ証券取引所の「処理能力」は
（約定件数ベース）
ＮＹＳＥ（ニューヨーク）　２１００万件
東証　４５０万件
（注文件数ベース）
ＬＳＥ（ロンドン）　１０００万件超
東証　９００万件
※こっちは差が無いが取扱高はＬＳＥが低いので相対的に余裕がある。
　あとＬＳＥは分散型システムのため全停止リスクが低く増強も容易。
※ＮＨＫのニュースでは「止まらない」と専門家っぽい人が得意げに答えてましたが
　サーバ１台ダウンするとその余波が残存サーバに→そこも負荷増停止→…
　という連鎖事件は日本のネット証券でも起きていたはず。

とにかく、本来の最高性能では差があるそうです。
東証は去年９月平均２３１万件、１２月２９４万件、そして先日停止した時に４３８万件。
一応２００５年では倍の能力と見なしていたようです。それが昨今の個人投資家小口注文、大手証券のスライス取引（小出し）で件数は指数的に増えるのに追いつかれてしまった形に。
今週末から五月雨的に東証は早めに増強をしていくそうですが、間に合うか？
とりあえず富士通と縁を切って別物システムに急に置き換えるのはリスクが高いので契約は継続かな。

私は汎用機とかＣＯＢＯＬのほうが、余計な機能（音楽とかマウス操作とかユーザインタフェース、多色とか多彩な周辺機器ドライバ…業務では使わない機能のためにＯＳは肥大化している）が無くてシンプルに四則計算やってくれるので、Ｃやjavaは相対的に便利ではあるが処理結果信頼性で優れているとは思えないのです。
UNIXで開発するとゾンビプロセス大量発生とか、winで開発すると書込命令成功してるのにＨＤＤに無いという摩訶不思議体験を何度も。再起動すれば直ってしまうので再現性も無く。
だから言うとおりに動いてくれる点では汎用機が一番なのですが、さすがにそればかり開発提供できない時代になりました。

一方、ＮＹＳＥはマザーズと新規上場企業獲得で争い、ＬＳＥも欧州取引所から買収対象になっているなど、今に満足せずにさらに増強を進めているとか。ＮＹＳＥは投資額は年間１億ドルだそうで。
なんか覚悟の違いの差があります。

まあ今回は「おまえら釣られすぎ」って感じでしたので、緊急措置も今回限りだと思いたいところ。

自治体の93%は電子投票の予定無し

２００５年12月末総務省発表（８月調査）によれば、全国の市区町村自治体では「電子投票を採用しない」と答えたのは９３％だったとか。
自民党のワーキンググチームは２００７年参院選での電子投票導入を進めていたが、理解が進んでない状況。

その理由は、
＊費用が高い
＊システムが信頼できない
＊国政選挙で採用されてない
等

私は特に２番目の『信頼性』が気になってまして、
過去の国内の地方選挙で導入されたときのトラブルの多さにびっくりしてました。
確率的にゼロではないのは仕方ないとしても多すぎ。しかもほとんどがハード的「動かない」トラブル。
特に熱暴走とか聞くと「はぁ？なんで？」となります。
たかがタッチパネルで名前を選んでＣＦに記録保存するコンピュータが熱暴走するのだろうか。
ベンチマーク走らせているわけでもないし、ビデオカードやＣＰＵに最上級の周波数が必要でもないし。
扇風機で機器に風を当てながら対処したとかの記事を読んで悲しくなりました。
グループウェアやＷＥＢサーバが「熱暴走で某県庁サーバが」とか聞いたことが無いのに。たかが選挙システムで暴走するって、選挙システムってどんな仕様やねん！みたいな。
あまりにも情けないトラブルであり、かつ、頻発させてきたからには、２００６年のいまになってもこれだけ不信度が高いのは当然か。
ＷＥＢとかメールとかグループウェアとかＩＴ化推進は自治体必須事項になって、データセンター共同化とかシステム共通基盤とか高度化も進んでいる中で、投票システムだけは９３％もそっぽ向かれている。

ハードメーカさんも「動かない投票システム」を早く解消…って、
やっぱり私にはたかが投票で熱暴走するシステムって想像できない。
私の自宅パソコンは解析ソフトが一年中常駐して２４時間１００％ＣＰＵ使用率で運転してちゃんと動いているのに。アスロンのFX55で２２万円なデスクトップ。
投票時間内すらも持ちこたえきれないハードってどんなだ？

情けないなぁ…

総務省が地方自治体のＩＴシステム情報を大公開？

なかなか過激なデータが発表されましたね。

リンク: 市町村の業務システムの導入及び運用に要する経費等の調査.

これは地方自治体全市町村にアンケート調査した、各市町村が保有するコンピュータシステムの状況を名前付きで公表しています。
しかもそのITシステムに投入した運営費用や契約ベンダー業者名まで細かく。
さらに担当の部署を電話番号付きで載せています。

こういう、どこがどんなシステムを開発しどれだけお金を使っているかは公共団体内でしょっちゅう調査しあっているため（各団体が全国に調査問い合わせをかける。比較して検討しないと導入や改善案に説得力ないから。だけどそのせいでアンケートが年中どこからか回ってくるわけで回答大変）、情報自体は社外秘でないとしても、公共団体内を出て一般公開されるのは初めてじゃないでしょうか。
「金額は税金なんだから住民に公開すべきだ！」と言われますが、契約は当事者同士のものであり、例えば内緒の手紙を相手が勝手に公開すれば道義的に気分良くないですよね？契約金額だって原則は自治体規模に比例して変動しますが、仕様や能力でも差が出るし、営業が「貴団体様だけ特別に勉強させていただきます価格」をやっている場合、その戦略価格がオープンにされるし、その安価な価格をネタに「ウチもその値段に下げてよ」な圧力食らうだろうし。総務省やLASDECの助成を受けて実験名義で開発した場合はタダ同然だし。
まぁ正攻法で行くなら、極端に高い安い業者はそれの説明責任を負えばいいってことでしょうね。
高くてもそれに見合う理由があるなら高いままで納得してもらえるはず…。

だいたい契約時に「この金額は後日オープンに晒しますよ」とかあらかじめ断っていたのか？＞地方公共団体
業者側も雑誌インタビューでは進んで価格を出してますが、あれは自信があるスポット的なものだし。

この情報は、ＩＴベンダー、システムインテグレータ会社がのどから手が出るほどに欲しかった全国横断的なクリティカルな情報でしょう。
営業担当が、これを見て高い保守費な団体に営業をかけられますね。電話番号も載ってるし(笑)。
業者としては金額は『自分は他社を知りたいが、他社には自分のを知られたくない』というシロモノでしょう。
担当業者名は記号で表示されてますが、だいたい想像がつきますよね。
各地域で勢力のあるメーカーが違うのでそれに当てはめればＩＴ業界の人なら想像つくかと。

こんなぶっちゃけた情報を出すのは、「他所とかけ離れている自分」を自覚してもらって改革を促すため。
同じベンダーと契約しても費用には大きな差が--システム費用の調査結果を公表
（日経BP）
ここで公表されたベンダーも大変でしょうね。同じ税務システムで自社だけ高いと、それを運用中の自治体は納得の上だとしても、ライバルが営業をかけてくるし、自治体住民から「無駄遣いだ！」とオンブズマンが批判してきて自治体も改革せざるをえなくなる＝値切りが全国で加速する、
というデフレの嵐がくる予感…

資料のあるLASDECサイト：
http://www.lasdec.nippon-net.ne.jp/rdd/kyo/k-chousa/index.htm
経費が各社横並びでないのは、自治体の規模や仕様が異なるとはいえ談合してない証拠になるかな？
しかしこれで高い値段だった会社への圧力は高まるだろうなぁ。晒されたベンダーも青ざめているかも？
開発や運用業者は契約時に記載の金額はよもやこうして全世界に晒されるとは夢にも思ってなかったでしょうから。
競争が起きれば自治体側にはありがたいでしょうが、
あまり値段下げると、システムの質はますます低下しますよ…

最終報告：東証システム障害を検証

東証と名証の原因、ITProに詳しい説明記事が掲載されましたが、
なんかもう判らないといいますか…。実際に富士通汎用機を触ってきた私すら「結局何が悪いのか？」の核心が掴めません。
名証の事件だって最初はパスワードがどうこうと報道されていたのに、下の記事では一変し、オラクルをリネームして動けなくしてしまった、と？どうしてこうもクルクル変わるのだろうか。私はUNIXではＮＥＣのEWSやUPでオラクル使ってましたが、リネームでexport運用って世間常識なのだろうか…。
2005年11月18日　名証システム障害、原因は外注先オペレータの“操作ミス”
（富士通製UNIXサーバー＆Oracle）
2005年11月18日　東証ダウン、真の原因はプログラムの破損
ひとつだけ判ったのは、原因は人為的ミスであり、マシンやアプリの仕様や性能のせいではないってらしいこと。
性能の問題なら同じアーキテクチャの全世界のマシンが故障のリスクを負うことになり、他のシステムも緊急点検する必要が出てきます。（まぁ運用も我が身振り直す必要はあります）
結局『破損』のところがわからない。記事でも「おいそれと不具合が出るツールでない」というぐらいなのだから。
オラクルや汎用機に詳しい記者さんにレポートして欲しいですね。
上記記事でも読者コメントではツッコミ多数でしたし。

■関連で新聞記事でのレポート

このサイトはすぐ記事が消えるのでメモ。
日経産業新聞の記事のデジタル。これが原因の最終的解説となるのでしょうか。
結局ここでも「コンデンスやデフラグでなぜインデックスがこわれるのか？Windowsでデフラグしたらファイルの中身が壊れるものなのか？」の私の疑問は解消できず。
元リンク: 日経ナビ：日経の就活・キャリア情報サイト.

情報処理・ソフトウェア
「東証システム障害を検証、１つの「バグ」から始まった。」
　　東京証券取引所で十一月一日に発生した売買システムの障害は十日、社外役員を除く全役員の減俸処分という処分で一応の決着をみた。前場と後場の途中まで、三時間にわたって全二千四百銘柄の取引ができなくなるという、前代未聞の大規模トラブルはどのように起きたのか。不完全なプログラムがシステムに搭載されて障害が発生した経緯を振り返る。
１０月８日―１０日
発端
システム拡張を前倒し
別ソフトに問題
　東証一部市場は九月、二十営業日のうち十九日の売買高が二十億株を超える大商いに沸いた。ネット証券各社は増え続ける注文件数に対処するため、基幹システムの処理能力を相次いで増強。東証も先を見越して処理できる注文件数を引き上げるため、売買システムの拡張を前倒しで行うことにした。
　十月八日土曜日、証券会社からの注文を処理する売買システムを止めて、注文データを保存する記録装置の設定を変更。一日あたりに処理できる注文を六百二十万件から七百五十万件に引き上げる作業を行った。
　翌九日には試験用のデータを使って模擬的に大量の注文を発生させるテストを実施。売買システムが計算通り、一日七百五十万件の負荷に耐えられるかどうかを確かめた。
　このときソフトウエアに一つの欠陥（バグ）が見つかる。東証の売買システムには、起動時にデータベースから証券会社の識別コードを読み込んで、売買注文や取り消し注文の受付結果を証券会社に通知するためのプログラムがある。バグは、注文件数が増えるとその機能が停止してしまう危険なものだった。
　八日のシステム増強作業がこのバグの原因だったわけではない。東証によると、「少なくとも前回に売買システムの増強を実施した今年五月から存在していた」（天野富夫常務）。バグがあったままでも、一日の注文件数が六百万件を超えなければ異常は出ない。このため最大でも一日五百五十万件程度だった今年十月まで、発覚しなかった。
　東証はただちに、売買システムの開発と保守を担当する富士通に注文受付の通知用プログラムの修正を依頼した。東証に常駐している富士通のシステム技術者は即座に作業にとりかかった。修正したプログラムは十日夜までには動作検証を終え、問題なく動作することが確認された。
１０月１３日
誤処理
プログラムに「空白」
富士通の指示書に不備
　一般にバグなどを修正したプログラムは、他のプログラムに予想外の影響を及ぼす可能性がある。そのため修正直後はいったんハードディスク内の別領域に保存し、他のプログラムとは隔離する。この「仮登録」の状態でしばらく使って動作の安定性が確認できると、他のプログラムと同じ格納領域に移して「本登録」する。
　東証もこの手順通り、修正した注文受付の通知用プログラムを十月十一、十二日の間は、売買システムの特定領域に仮登録して使用した。二日間、他のプログラムに異常がなかったことから、本登録に移行することにした。
　本登録に当たり、東証は富士通に作業手順をまとめた指示書の作成を依頼した。実際の作業は、東証の基幹系システム全般の運用を手がける東証コンピュータシステム（ＴＣＳ）が担当。十三日、ＴＣＳのシステム技術者が富士通の指示書の通りに作業を進めた。
　ところが、富士通が作成した指示書そのものに不備があった。本来なら修正したプログラムを本登録する時に、「エイリアス」（別名や仮称の意）と呼ぶ別のプログラムに、修正したプログラムの名称などを書き込む必要がある。指示書は、その作業項目が完全に抜け落ちていた。
　エイリアスとは、パソコンで言えば、デスクトップ画面に配置された「ショートカット・アイコン」のようなものだ。エイリアスを使えば、それに対応したプログラム本体が起動するだけでなく、検索・読み込みといった複数の命令を一度に実行できる。
　コンピューターはエイリアスに書き込まれた情報を基に、どのエイリアスがどのプログラムに対応するかを一覧にした索引リストをつくる。その索引リストを参照してプログラム本体を特定し、実行する仕組みだ。だが本登録されたプログラムに対応するエイリアスは、索引リストの基になる肝心のプログラム名が「空白」のままだった。
１０月３１日
秒読み
偶然の連動断ち切る
　本登録が終わった翌日の十月十四日朝。東証の売買システムは通常通り、起動時にデータベースから証券会社の識別コードを読み込み、正常に動き始めた。エイリアスに不備があったにもかかわらず障害が起きなかったのは、コンピューター内の古い索引リストがまだ生きていたからだ。
　このリストでは、問題のエイリアスはまだ注文受付の通知用プログラムと結びついた状態。コンピューターは以後もそのリストを参照して、通知用プログラムを一見問題なく実行し続けた。
　だが月末の三十一日、時限装置が秒読みを始める。
　東証は毎月末、売買システムに格納してあるプログラムやデータの整理を自動的に実行している。パソコンでは「デフラグ」と呼ぶ処理に当たる。プログラムやデータを何度も登録したり更新したりしていくと、ハードディスクの空き場所にとびとびに記録されたり、使えない無駄なすき間ができたりする。これを整理し直し、システムの動作を安定させるのが目的だ。
　このときコンピューターは一つ一つのエイリアスを自動的に読み取って、どの本体プログラムと結びついているかを確認する。それを基に、各エイリアスに対応したプログラムがハードディスク上のどこにあるかを記した索引リストを最新の内容に作り直す。
　問題のエイリアスは、どのプログラムに対応するかを示す情報が欠落していた。コンピューターは索引リストを更新する過程で、それまで偶然にもつながっていたエイリアスとプログラムを「無関係」と判断して、両者の結びつきを断ち切ってしまった。
１１月１日
売買停止
途中で動作不能
残る甘えの構造
　十一月一日午前六時三十分、東証は普段通り売買システムを起動した。売買システムは複数のプログラムを次々に実行して、注文処理に必要な機能やデータをシステムに登録。そして六時四十七分、問題のエイリアスが作動したとき、約三週間潜んでいた障害が起こった。
　エイリアスと注文受付の通知用プログラムとの結び付きが分からないコンピューターは、ハードディスクのプログラム格納領域の中から実行すべきプログラムを見つけ出せない。その結果、証券会社の識別コードを読み込む処理ができず、システムは起動途中で動作不能に陥った。
　すぐに障害時のバックアップシステムが起動を始めたが、それも失敗に終わった。本番用のシステムとまったく同じプログラムを搭載しているから当然だった。
　東証は七時四十六分に証券各社に障害の発生を連絡し、八時四十分には売買の停止を正式に通知。障害発生直後から原因究明にあたったが、復旧のメドが立たないまま十時十五分に午前の取引停止を決定した。
　原因が判明したのは十二時ごろ。富士通のシステム技術者が注文受付の通知用プログラムを正しく実行できるように、エイリアスを手作業で修正してシステムを再起動、十二時五十五分に障害が復旧した。
　東証は一日から七日までに四度の記者会見を開き、現状と原因を説明した。五回目の会見となった十日には鶴島琢夫社長を筆頭に九人の役員報酬を最大六カ月五〇％カットする処分を発表。再発防止とシステムの安定稼働に向けて開発と運用の体制を見直すことを決めた。富士通も同日、黒川博昭社長などの減俸処分を実施すると発表した。
　もっとも、これで問題が片づいたわけではない。〇二年にみずほ銀行で大規模トラブルが発生したにもかかわらず、「プログラムにはバグがつきもの」というＩＴ（情報技術）業界の態度は変わらない。東証の鶴島社長も七日の会見で「相当綿密なテストをしてもバグは残る」といった趣旨のコメントをした。
　この甘えを断たない限りいくら体制を見直しても意味はない。今回の障害を教訓に、バグや作業ミスを一つでも減らしていく地道な取り組みが求められる。
（栗原雅）
東証システム障害の主な経緯　　
１０月８−１０日　　売買システムの一日あたりの注文処理件数を６２０万件から７５０万件に増強
　　　　　　　　　　注文受付の通知用プログラムのバグが見つかり緊急修整　　
　　　　　１３日　　修整したプログラムを売買システムに登録する作業中、同プログラムを実行するための簡易プログラムの設定を誤る
　　　　　３１日　　売買システムの月次処理によって、注文受付の通知用プログラムと簡易プログラムの連動が無効となる
１１月１日午前６時３０分　　通常通り売買システムの立ち上げを開始
　　　　　午前６時４７分　　システムが異常を検知、障害が発生
　　　　　午前８時４０分　　証券会社に売買を停止すると正式に通知
　　　　　午前９時４５分　　与謝野馨経済財政・金融相が会見で遺憾の意を表明
　　　　午後１２時５５分　　システムが復旧、午後１時３０分に取引を開始すると発表
　　　　　　　　　　　　　　金融庁が東証に、１５日までに障害の原因や再発防止策の報告を要求
　　　　　　　　　　夕方　　インド出張中の鶴島琢夫東証社長が帰国の途に
　　　　　　２日午後７時　　鶴島社長が謝罪会見
　　　　　　４日　　　　　　鶴島社長が金融庁に出向き与謝野経財・金融相に謝罪
　　　　　　７日午後４時　　会見で障害の原因を公表、富士通が作成した資料に不備があったことが判明
　　１０日午後４時３０分　　会見で鶴島社長ら役員９人の減俸処分を発表
　　　　　　　　　　夕方　　富士通が黒川博昭社長と担当役員を減俸処分にする方針を表明
［11月14日/日経産業新聞］