Hatena::ブログ(Diary)

novtan別館 このページをアンテナに追加 RSSフィード Twitter

2008-05-18

想像力についていくつか

人の気持ちを読む際の想像力ってのは多分に勝手読みの原因なんだよね。もちろん、相手の気持ちを斟酌しないよりはしたほうがよりよいコミュニケーションをとることはできるだろう。けれども、想像というものは所詮自分の枠の中にしか及ばないものであるから、正確な推測はほぼ不可能だ。

だから、想像力を働かせてよ、と他人に要求するのは無理筋。精々わかってもらえたらいいなあ、というところが関の山である。

「俺は大丈夫」を他人に適用しない - novtan別館

踏み込んだり、踏み込まれたり - novtan別館

想像力の問題でもなく - novtan別館

想像力にも限界が - novtan別館

Webプログラミングってジャンルなんだっけ

Webプログラミングって簡単なのを作るのはすごく簡単だけど(所詮テキストデータ出すだけだしね)、それをきちんとしたアプリケーションにして、データの整合性を取って、トラブルに対応し、となるとどんどん難しくなるよね。それをフレームワークでなんとか吸収しているけど、未だに認証のところなんて決定版出ないけど、ものすごく致命的なところだし。公開しているから攻撃対策もしなきゃならないし、ちゃんとしたものを作るのは難しいですよ。

なぜこうなのだろう。 Web プログラミングおよび Web プログラマーの程度が低いことには多分相関がある。 Web プログラミングの程度が低いから Web プログラマーの程度が低いのか、 Web プログラマーの程度が低いから Web プログラミングの程度が低いのか。実際には両方が組み合わさって、現状に至るのだろう。

はてなダイアリー

違うよ。職業プログラマというものの限界がそこにあるだけ。今の業務プログラムのかなりの部分がWebプログラミングなわけで、それだけの話だと思う。そして、良く出来たプロジェクトであればあるほど、業務ロジック以外のところは精鋭チームでこなしちゃうからね。

Web プログラマーの程度は低くない? まあそうかもしれないね。その「程度」とやらを計る明確な基準は今のところ存在しないもの。しかし、ソフトウェア産業において、最も知的だと思われる集団、つまりは研究者やそれに類する人々と、正反対の文化を持っていることは確かだ

はてなダイアリー

ぶっちゃけWebプログラミングはそれそのものがアプリケーションなんだよね。RESTの方法論とか、様々なモデリングとか、成熟していない分出たり消えたりしているけれども、だからといってコアな部分が知的でないなんてとってもじゃないけど言えない。携わっている人口比でいうと確かに低レベルかも知れないけど、それは取り巻く環境の問題に過ぎない。

というわけで。

そりゃシロートが一人で書いて、一人で実行するようなアプリを作るならお手軽かもしれませんが、瞬間的に数万人のアクセスがあって、それを全て適切にさばきながら複雑怪奇な処理を行うのはとても簡単には行かないし、僕は専らゲームプログラミングをやっていた頃よりもサーバに関わるようになってからの方が遥かに勉強すべきことが多くて目が回りそうでした。三角形描いてりゃ済むほど簡単じゃない。

長文日記

Webプログラミングをあえてジャンルで括るとしたら、こういうものだと思う。サーバ技術やパフォーマンス、リカバリなどの全体を含めたものがWebプログラミング(実際にはプログラミングとはいい難いかもしれないけど)であるんだと思う。

まあ、Webプログラミングで実現できるものがWebでのサービスである以上は、できるものに限界がある。でも、動画ストリーミングが文字列処理やGUIプログラムの焼き直しだとは思わないし、検索エンジンは本質的にはWebのものではないけれども、Webという利用形態がなかったら多分生まれなかったんだよね。

酵素パワー

なかなか洗濯日和にならない週末が続きますが、辛うじて日の光もでそうだったのでお洗濯。気になっていた襟の汚れはid:aozora21さんの助言に従い専用の洗剤を買ってきたよ。

[rakuten:create-sd:10011834:detail]

Amazonにも洗剤売ってるけどポイント洗い用は弱いみたい…

んで、効果のほどは…おお、気になってた汗が流れたあととかがすっきり。もうちょっと丁寧に使えばばっちり落ちるな。

同じ皮脂汚れだからいけるかなと思い、もう捨てようかとしていた汚れネクタイを洗ってみる。おお、これもずいぶん綺麗になるなあ。ネクタイは心地が型崩れするから洗濯はしないものですが、捨てるくらいなら試してみても良いですね。

それにしても、文明の力は偉大ですな。こんなに効くとは思わなかった。洗濯かあちゃんありがとう!

めんどくさがらずにちゃんとケアするのが長持ちのコツかなあ。頑張ろうっと。

ホメオパシーと医療リソース

「痛いの痛いの飛んでけ」で直るものまで全部医者に行くことは医療費の無駄である。

とすると、ホメオパシーで直る(あるいは直った気になる)ことで医療費を使わないことはよいことである。保険使わなければ。

老人が病院に入り浸るのも、ある種の代替医療かも知れないと思ったりもする。これは保険のリソースを消費するから避けたい(だから後期高齢者という発想になるのか?)

問題は、ホメオパシーや自然療法なんかが、本来コントロール可能な医療リスク(例えば健康診断⇒精密検査⇒早期治療)をすっとばして、結果として重篤で時間も金もかかる状態にして余計にリソースを消費する可能性があるかどうか、ということだろう。

保険制度みたいなものは目的は人を上手く救うためだとしても、その運用は統計的なもので行われるわけであって、あまりにそこから外れるものが多いと成り立たない。もちろん、医療の現状を正確に掴むことは神ならない身としては不可能ではあっても、上がってきたデータから健康診断の効果や早期治療の効果というのはある程度わかった上で運用されているだろう。

となると、統計の対象にならない治療をした結果として、突如保健医療に割り込んできた重篤な症状というものの割合が増えてくると、統計的なデータにバイアスがかかり、結果として、普通に保健医療を受けている人たちのリソースを圧迫したり、本来提供されるはずの医療が提供されなくなったりする怖れがある。

保険制度がなければホメオパシーでもなんでも受ければいいとおもうんだけど、「日本では保健医療を医療政策とする」という合意がある中で、あえてそこから外れたことを行うと言うことはあまりいいこととは思えない。「代替医療で直らなかったらしかたなく普通の医者に行く」ということを公言する人もいるらしいけど、代替医療と心中して欲しいなあ。

出来るはずだからやれという体育会系気質がシステム開発をぶち壊す

例の統合についての記事が追記されてた。

記述が十分ではなく誤解を招き申し訳ありません。そもそも私が意図していたのは、トラブルが人命に関わるレベルの世界(医療、鉄道・航空管制、自動車制御系など)ではバグの発生を極限にまで減らすことに相当努力しているということは、こういった巨大システム統合においてもなし得る事ができるのではないか、という点でした。

障害発生が「当たり前」という銀行システム統合、本当にそれでいいの?:情報インフラ24時 眠らないシステム:オルタナティブ・ブログ

行員にいびられながら必死にテストをこなしてきた開発要員涙目wこんなこと言われたら一斉にメンヘラーになってしまいそうですね。

現在の銀行システムのように、行内でも多数のシステムが組み合わさっているだけでなく、多くの対外システムも含めた膨大な接続バリエーションがある巨大システムでは、鉄道や航空管制、ましてや医療機器のように、ある程度閉じたシステムとは大きく異なった難しさがあります。

そして、このような「相当努力すればバグを極限まで減らせる」という認識の下、(本質的には)無駄なテストを数多くこなすことになり、肝心の部分に時間と頭を裂く余力はなくなっていきます。

ましてやシステム統合なんて後ろ向きのシステム開発なんですよね。つまり、既存のシステムを何年も掛けてただ繋ぐだけ。本当は、新システムを作りたい。

だから、この記事で意図している目的そのものが現場の感覚からするとナンセンスで、これだけの批判が来るのです。銀行TOPとか金融庁はこう考えているかも知れませんし、コンサルとしてはターゲットはそこなんでしょうから、立場的には間違っていませんが、こういった意見が更なるシステム障害を生む土壌を育むわけですね。

大体、東京三菱なんて障害出すとベンダーが怒られるどころか「このロジックを作った奴は誰だ!」ってやられるらしいですよ。で、偉い人の前で小一時間問い詰められるという…。犯人探しがシステム開発において間違った責任の取らせ方であり間違ったプロジェクト運営方法であることなんてもうだいぶ前から常識だと思うのですが、未だに旧態依然としている。この話を聞いたのは数年前だから変わってるかもしれませんが。

もちろん、極限までバグを減らそうとするのは良いことだと思いますし、予算と時間があるならばテストをきちんと行うのも大切です。ただ、ミッションクリティカルな部分ならともかく、膨大なバリエーションを要求する対外接続の部分は限界があります。どうしても複数ベンダーになりがち(これは内も外もね)なこともあってテスト内容も統一し切れません。そこにいくら金を使うかよりもどう運用するかのプランの方が大事です。

もちろんバグをゼロにすることが現実的な選択肢ではないことも理解していますし、そのためにBCPが重要であることも強く認識しています。だから、三菱東京UFJさんの場合、どれだけしっかりとしたBCPが立てられていたか、これが重要だと考えています。

うん、じゃあプロジェクトメンバーのスキル偏差は気にしなくて良いですね。だから、じゃなくて、前の論旨とは関係ない別の問題ですね。

今回のトラブルは対外インターフェースにおける疎通確認テストに含まれる内容だと思いますが、インターフェースの仕様が誤っていたために起きた事件を想定したBCPが非常に事後対応的だったので、もう少し事前にリスクを世間(一般消費者)に示すアプローチをとった方が良かったのではないかと思っておりました。

例えば、メガバンクのシステム統合規模であれば、全国の金融機関に接続失敗時のオペレーションを何パターンか伝えておき、それを店頭や各種提携コンビニ、駅などに周知させるなど、それだけでも世間から見た障害時の影響というのは変わってくるのではないでしょうか。

疎通確認テストをそんなレベルでやるってことはないと思うんだけど。あくまで業務バリエーションじゃないでしょうか。あと、世間に対して「障害が起きるかも知れないので注意してね」というアナウンスをするというのは金融庁の方針に反していると言うか「障害が起きることを想定するならリリースを認めない!」って言われてしまって終わりでしょう。こういう政治向きも含めてシステムの効率化の足を引っ張っていますが、その根底にはやはり「頑張れば障害はゼロに出来る」という発想があるのです。

正直な感想を言うと、今回は「変更したところに対するテストが不十分」というちょっとお粗末な問題だと思います。だから、これをどうすれば防げたのか、という議論は十分にする価値のあるものだと思います。だからといって、それをもって「極限までバグを減らすためには」という議論にできるとは思えません。後でだったら何でも言えるんですけどね。本当にクリティカルな部分では「障害が起こっても上手くバックアップすればよい」という論調にならない限り、第二第三の障害は避けられないように思います。

不適切な比喩を放棄しようとしないのは何故だろう

色んなところで批判されている通り、比喩は使い方を間違えると単に議論の混乱を招きます。議論の焦点がぶれたり、比喩が否定されることでもともとの論点が否定されかけたりと、散々です。

中には親切にも「それは不適切な比喩だからやめたほうが良いですね」と指摘してくれる人もいるのですが、比喩を提示した当の本人はなぜかその比喩に固執することが多いように思えます。だから、それじゃ話が進まないんだって!

…そうか、話を意図的にそらせて議論の本質に目を向けないようにする高等テクニックなんだなコレは。

おから工事ってのは他人事か?

おからのようにスカスカコンクリを使って建物を建てることを中国ではおから工事というらしいですね。四川省の地震で学校の校舎が倒壊しまくったのは、予算を政府関係の建物に集中させ、校舎なんかはその予算を捻出するために手抜きをすると。そのベースには賄賂社会があると。

ここまで酷いのはあまり聞かないとはいえ、日本でも強度の足りないコンクリとか塩水入りコンクリとかの話には事欠きませんでした。阪神大震災の教訓をきっかけにしてなくなっていくかと思ったらヒューザー耐震偽造。結局、惨事が起こらなければ発覚しない問題なんて未だに大量にあると思うんですよね。

じゃあどうすればいいかというとわかんないんだけど、日本はちゃんと建物作っているから大丈夫という確信はないよね。せめて災害時にしなければならないことだけは確認しておこうっと。