トラブルに対応するためにはどうするか（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】

まずはトラブルをそのまま受け入れることである。起こってしまったことは仕方がない。過去を取り消すことはできない。その上で再発防止策を含めて前向きに検討すればよい。

しかしそのまま受け入れることが意外と難しい。自分は我慢できたとして上司（あるいは顧客）は我慢しない。現場を知らないとその傾向は強まる。そういう上司（顧客）からたまには怒られることになる。因果なもので怒りは伝染する傾向がある。結局トラブルが発生したらなかなか冷静ではいられない。しかしそこは何とかするしかない。怒りや不安はトラブル対応には役に立たないのだから。

まずは冷静になること。問題の影響を正確に把握すること。次に事実と推論と意見を区別すること。希望観測が確信に変わってしまう人がいる。経験の少ない人に多い傾向である。誤った前提は非常に危険である。仮説と事実は明確に区別されねばならない。ここで初めて因果関係の適用を検討する。時系列で整理しどの事象が原因たりうるのか検討するのである。また原因から逆に影響を見直してみることにも意味がある。ウォーターフォール型の開発方法論を適用するとすれば適切なフェーズで出たトラブルなのか評価しておくのは有効である。

因果関係の適用は慎重にする必要がある。事象の発生を時系列で並べた時の直前のアクションが直接的な原因である。しかしそれには大抵意味がない。バグの直接原因はコーディングミスである。しかしその背景には様々な要因が考えられる。例えば仕様が甘い、コミュニケーションが取られていない、スケジュールが厳しすぎる、などなど。

ただし原因を抽象化し過ぎたり、時系列をさかのぼり過ぎるのも良くない。バグの根本原因はプロジェクトが開始してしまったことにある。そもそもこのプロジェクトはスタートするべきではなかった。おそらくは正しい仮説である。それでどうするか。社長に直訴するか。辞表を書くか。前向きなアクションには結び付かない。有効なアクションが取り得ない原因は良い原因ではない。それに対して良いアクションが取れるものこそが真の原因なのである。もちろん有効な真の原因が存在しない場合がある。例えば時間が足りない。繰り返しミスをする人間がいる（しかも他に人がいないためクビにできない）。昨今のコンプライアンスやら個人情報保護事情でインターネットやメール環境から遮断されたプロジェクトである。これらが原因ではどうしようもない。諦めるしかない。無論代替策は検討する。しかし根本的には諦める他はない。般若心経に「転倒」という言葉が出てくる。「あべこべ」という意味らしい。障害は起こるが障害が発生してはならない。出来ないのだが、出来なければならない。転倒とはこういう思い込みを指すのであろう。そんなことを思うから変なことになるのである。遠離一切転倒夢想が望ましい。

出来ないものを何とかしようとするから苦しいのである。始めから割り切ってしまえば苦しくも何ともない。そういうものだ、と受け入れればよいのである。受け入れた上で次善の策を検討する。そうするしかないではないか。「出来ない目標が掲げられても、一歩でもそれに近づくように努力するのが大事」という考えがある。正しい実践だと思う。ただしそれはあくまで本業に対して設定すべき目標である。本質的ではないところであがくのは時間の無駄である。

真の原因を設定するにあたり、プロジェクト運営の目的は何かを明確にしておく必要がある。これはまた手段の目的化を避けるためにも重要である。大抵のプロジェクトの目的は「良いシステムを作ること」であろう。だから「良いシステムを作るためには何をすべきか」が常に問われなければならない。トラブル発生時も同じである。良いシステムを作るためにはこのトラブルをどう解釈すべきか。淡々と直せば済むのか。それともその裏にプロジェクトの目的を妨げるような大きな問題があるのか。プロジェクト全体で対応する必要はないのか。

だが真の原因分析に時間を掛けすぎることもよくないし、些細な問題をおおごとにしてしまうのも結局効率がよくない。例えば仕様書のあいまいな記載に由来する障害で、真の原因は仕様書だ、と結論付けたとする。これは「過度の抽象化」という分析失敗例でもある。ここから仕様書のあいまいな点を全て洗い出す、という悲惨なタスクを考え出してしまう自己破壊的・プロジェクト破壊的な人が存在するのだ。大抵のプロジェクトではその作業対象は膨大であろうし、作業スコープも完了基準もあいまいになるであろう。結果、却ってプロジェクトの遅延を引き起こし、品質の低下を産みかねないのである。現実的に対応可能な効率的な作業によって対応できることまで見極めた上で、原因の分析を行う必要がある。要するに具体的な作業をあいまいさなしに定義するのである。ダブルチェックしてもミスは完全にはなくならない。それを知っておく必要もあるだろう。さもなければ後で「なぜチェックしたのにまたトラブルが起こるのだ」と無駄な負の感情が生まれる。

どの設定ファイル、プログラムを、この観点でこう調査する。「全ての」対象に波及させてはならない。「全てのプログラムで確認する」。件数によっては可能かもしれない。しかし、対象が膨大であれば、目視確認は諦めてプログラムに自動チェックさせてもよい。あるいはいっそ事前チェックによる洗い出しはあきらめ、テストしてしまうことを検討した方がよい。

観点をあいまいにしてはならない。「プログラムミスがないことを確認する」。これでは確認しようがない。どのようなミスなのかポイントを絞る必要がある。例えば「データベースリソースの開放忘れがないこと」。またチェック手順（どのようなキーワードで作業対象を検索し、どのポイントを見るのか）まで見極めておく。そして重要なのはそれでもなおトラブルが発生し得る、と認識することである。トラブルが起こってはならない。意識はそう思いがちであるが、それは精神衛生上良くない思い込みである。「トラブルが起きない方が望ましい。しかし大きなトラブルがいつでも発生しうる」が正しい。覚悟という言葉を聞かなくなった。トラブルは許されない。失敗は許されない。その裏にあるのは実は逃避なのではないか。「デッドライン」のデマルコが正しい。プロジェクトは腹を決めて運営するものなのである。

知ることはガンの告知だ、知る前と後では世界のあり方が変わってしまう。養老孟司氏の至言である。トラブルもまた同じである。これまでの想定が通用しなくなる。仕様書が変わりプログラムが変わりテストが変わり運用が変わる。トラブルが起こるのが自然ならば、それを受けて変更が発生するのもまた自然である。それを受け入れたらプロジェクトマネジメントが成立しないではないか。そんなことはない。要は考え方である。トラブルはあってはならない、と決めつけるのではなくトラブルは起こりえる、と認識することである。リスク管理もそこからしか始まらないではないか。トラブルにどう立ち向かうかが問われている。「トラブルなどあってはならない」という思いは単なる現実逃避である。

トラブルは許されないという思い込みからは「（トラブルを）なかったことにしたい」あるいは「出してはならない」という誤った衝動が生まれる。そしてトラブルを出さないように強く現場に圧力をかけることになる。トラブルをだすな、というプレッシャーはトラブルを隠す負のインセンティブとなる。現場のトラブル隠しがどのような結果を生むか。ここで敢えて述べる必要もないだろう。

意識と自然 ～ 原因と結果は存在しない（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】

自然の大雑把な定義が終わった。プロジェクトで発生する意識にとって好ましくない事象を自然と定義したわけである。次に出てくるのは意識の定義である。これについて正面から立ち向かうのは大変である。しかしここではプロジェクトの観点から意識を捉えることにして無理やり話を簡単にする。

これまでの文脈より、意識はまず「自然と対立するもの」と定義できる。発生した障害に対して、意識は感覚的には不快感を覚える。そして理解しようとする。文脈を整理し、因果関係を調べ、原因を究明する。そして障害への対応を行う。すなわち意識には以下の作用がある。

・トラブル（障害含む）に対する強い負の重み付け（障害は不快である）
・現在のトラブル対応への強い志向（不快であるが故に済ませてしまいたい）
・将来のトラブル対応への強い志向（今後あってはならない）
・政治的な関係に対する強い志向

また、意識には以下の機能がある

・抽象化能力
・因果関係適用能力
・論理的能力（推論、ロジック組み立て能力）
・その他重み付け能力（正しい美しい）　などなど

意識の能力にはさまざまであるが、ここでは特に抽象化能力と因果関係適用能力に注目する。両者をもう少し噛み砕いて説明する。前者の代表的なものは異なったものを「同じ」と判断する能力である。後者は「ああしたからこうなった。すなわち、ああすればこうなる」と文脈を判断し予測する能力である。抽象化能力はプロジェクト状況把握の基礎となり、因果関係適用能力はプロジェクトをコントロールする際の基礎となる。

ここで因果関係適用能力について補足する。原因と結果は頭の中にしかないんだ、と話すと理系の人間（に限らないのかもしれないが）は大抵きょとんとしている。存在すると思っているのであろう。そういう人間に「だったら原因と結果を取り出して見せてくれ」とまでは言わない。そういう意地悪をしていると、だんだん相手にされなくなるからである。

原因も結果も実体として存在するものではない。だとすればどこにあるか。頭の中である。つまり原因も結果も概念でしかない。概念は現実に存在するものではない。ゆえに原因も結果も存在しない。明らかである。そう思えない人は原因と結果に強い実在感を持っている、それだけのことである。確かに原因と結果は重要な概念である。これがなければ意識的な日常生活は立ち行かない。働いているから給料がもらえている。それを信じているから今日もまた嫌々ながらも仕事に行く。

話はそれるがこの手の議論にはいろいろなバリエーションがある。例えば「会社」の存在である。筆者が最初に就職した会社で、新人研修があった。その場で常務から「会社なんてもんは存在しない。君たち一人一人が会社なんだ」という話があり、非常に納得した記憶がある。だがそれが気の利いた訓示足り得るということは、会社に強い実在感を抱いている人も多いということであろう。あるいは「国家」が存在するのか。国家公務員にとっては間違いなく存在すると思われる。だが普通社会で生活している人はあまり「国家」を意識しないであろう。存在を疑うまでは行かないであろうが。一般的には、国家は例えば総理大臣であったり国会であったり税務署であったり、ある具体的な対象であって決して何らかの実体として存在しているものではないはずである。実は言葉上は存在している対象が、実際には五感で感じることができない、といったことが非常に多い。例えば「猫」だってそうである。あの猫、この猫は存在するが単なる「猫」は存在しない。「猫」もまた意識の抽象の結果なのである。

あの猫、この猫を抽象化して猫というカテゴリーに入れ込む。これは意識の「同じ」と判断する能力によって可能となっている。これについて少々補足する（興味ある方は養老孟司氏の本を読まれた方が話が早い。例えば「無思想の発見」（ちくま新書））。例えばOSがある。Windows、UNIXさまざまなOSがある。OSによって、その機能は異なるが実際に関わる人以外は「要はOSだろ」と言うことができる。「同じだ」と。Windowsにも種類があるし、UNIXにも種類がある。HP-UX、AIX、Soralis、そしてLinuxがあり、Linuxにも種類がある。だが、どれも「要はUNIXなんだろ。だったら同じだ」と言うことができるのである。抽象化することによって理解と判断が早くなる。Soralisに精通した人であればその他のUNIX系OSの学習も早いはずである。「同じ」を出発点としてアナロジー（「似ている」）によって理解を進められるからである。

閑話休題。

以上からプロジェクトにおける意識と自然を整理するとこうなる。

意識
　成功への正の重み付けと非成功への負の重み付け、ならびにツール（抽象化能力、因果関係整理能力など）を持つもの

自然
　意識の活動から必然的に生まれる事象で意識が負の重み付けをしているもの。

ここで一旦われわれ「人間」に戻ってみよう。意識にとって好ましくない事象を引き起こすのは自然な人間の行為である。つまりここで意識と自然という二元論は人間という要素に一元化される。人間は意識であり、かつ自然である。プロジェクトを回すのは人間。ということはプロジェクトは結局人の活動であり問題は人が引き起こすものである。要するに人間のすることだろ。上手く行くかどうかは人次第。トラブルに関して言っても、要するに人が何かやってうまく行かないことに、腹を立てている、とこうなる。そうなれば話は簡単で腹を立てなければよいのである。トラブルが発生しても粛々と対応すればよい。うまく行っている時は腹も立たない。それだけの話である。

それを大騒ぎするから体力がかかってしょうがない。はじめから腹を立てなければ話は早いのである。完全にコントロールできると思わなければ諦めもつく。そうすれば無力感だって生じない。

MySQLコマンドラインクライアントメモ

use データベース名
　⇒　指定したに接続

show tables
　⇒　テーブルをリスト

describe テーブル名
　⇒　テーブルのカラムを表示

プロジェクトの中の意識と自然（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】

何かを二つに分けて理解しようとする。例えば人という存在を意識（脳）と自然、あるいは脳と身体に分ける。これを二元論という。

二元論は便利である。なぜなら分けることは判断することであり、また理解することだから。分ける、とは分類する、つまり差異化することである。赤を赤と薄い赤に分ける。そして薄い赤をピンクと名づける。これによってピンクという質を理解する。これが意識が「理解」する方法である。すなわち意識が世界を理解する機能は二元的に働く。意識は対象を分けることで世界を再構築している。だから二元論は分かりやすい。デカルトも精神の世界と物質の世界を分けて考えてキリスト教と物理科学を共存させることができた。二元論は実に使える理論なのである。

プロジェクトを「意識と自然」という枠組みで把握してみよう。プロジェクトは人間が運営する。そして徹底的にリスクや偶然が嫌われる。その意味ではプロジェクトは極めて「意識的」なものである。すなわち事象は理解され、コントロールされなければならない。それが顕著なのがいわゆる「マネジメント」「えらい人たち」レイヤである。ではプロジェクトの現場レイヤはどうか。無論現場も同じ。事象や進捗のコントロールが志向され、リスクは排除しようとする。しかし２つのレイヤには決定的に違うポイントがある。それはありていに言ってしまえば無力感である。現場レイヤではしばしばコントロール不能状態になる。どうしようもない、しようがない、しかたない、そうとしか言いようのない事態が起きる。

属人的理由から発生するミス。やるべきことはやっていたにも関わらず発生する手戻り作業。起きることは分かっていた。しかし何も手を打てなかった無力感。やるべきことはやっていたにも関わらず発生してしまったという無力感。

無力感の多寡こそが現場とマネジメント層を分ける一つの指標に違いない。なぜならマネジメント層に伝わる情報にはほとんど無力感などは含まれてはいないだろうから。そしてマネジメントの仕事はもっぱら解釈であって現実との衝突ではないから。

この無力感の源はどのプロジェクトでも発生する障害、作業ミス、トラブル、コミュニケーション不全、予定外作業などなどである。意識にとっては受け入れがたいこれらの事象をなんと呼ぶか。この本ではこれを自然と呼ぶことにする。つまり自ずから然あるのがトラブルである。放っておけばそう成る。だから自然である。人が集まって何か働く。すると秩序なり製品が生まれ、それと同時に無秩序と廃棄物が生まれる。これをエントロピーが増大すると表現してもよい。要するにトラブルは自然にかつ必然的に発生する。

土地を放っておけば雑草が生える。それが気に入らないなら方法が２つある。一つはアスファルトで覆ってしまうこと。もう一つは手入れをすること。残念ながらプロジェクトをアスファルトで覆うことはできない。だから手入れをするしかない。しかし一般にはトラブル対応としてアスファルトで覆うようなラディカルな対応を行っていることが多い。行き過ぎたコントロールや数値化志向がそれである。ものには限度がある。行過ぎた対応はプロジェクトを破壊するか、強烈なオーバーヘッドを生むだけである。ある種のトラブルと共存するという発想も、必要なのではないか。冗談じゃない、失敗は許されない、そう言いたい気持ちも分かる。全ての失敗を許し、共存するとは言っていない。許されない失敗はある。その区別が重要である。あらゆる失敗が許されない、と考える人はここから先は読まないほうがよい。

ctagsメモ

Webで検索すると、ctrl - ] と ctrl - t は紹介されていますが、:ts はあまり出てないですね。

ctrl - ] では、とにかく同名の関数に飛んでくれますが、Javaでオーバー（ロード｜ライド）しまくっていると目的の場所に届かないことがままあります。そんなときに :ts です。

:ts とすると関数の候補が出ます。行きたい関数の数字を打てばOK。

eclipse だと結構探してくれますが、ctags では自分で候補を探す必要があります。（eclipseも完ぺきではないので、候補を自分で探す方が結果的に早いということもあります）

以上

はじめに（プロジェクトの人間学）

※　この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。

はじめに
システム構築プロジェクトに関係するステークホルダーには３つある。
ひとつは顧客である。プロジェクトの品質を要求し、正しいプロジェクト運営を求める。
もうひとつはマネジメントである。技術的なことはほとんど分からないのだが（それゆえにこそ顧客とマネジメントが対等なのであるが）プロジェクトを管理しようとする。
もうひとつは現場である。「マネジメントではない」存在として定義されたメンバーで構成されている。

前者二つは「こうであるべきだ！」「こうでないのはおかしい！」と声高に叫ぶ。そして管理という名の雑用を増やし、プロジェクトの混乱を促進する。現場はコンピュータが産む理不尽なトラブルと、マネジメントならびに顧客からの要求に耐え、絶望的に、だが粛々と作業を進める。「だったらお前がやってみろ」という呪いの言葉を飲み込んで。

筆者は現場の人間である。現場の視点からいくつかプロジェクトに関する本を読み、ほとんどすべてに対して「ウソだろ？」と顔をしかめてきた。デマルコなど一部を除いて。世のプロジェクト本は、それぞれの著者の脳内プロジェクトシミュレーションを扱っているに過ぎなかった。生きたプロジェクトを扱っている本はどこにもないように思えた。

現実のプロジェクトを対象にしたものでも、やたらと数値化を利用してプロジェクトを分析いる。だが大抵の場合は脳内のプロジェクトモデルにデータを寄り添わせるために数値を利用したに過ぎなかった。その計測方法も欲しいデータを得るために恣意的な切り口で計測したものが多かったように思う。つまりは自らのプロジェクト観を補強するために数字をもてあそんでいるに過ぎない。

あるいは中には無用にプロジェクトの悲惨さを訴えるものがある。悲惨さをユーモアとするにしても、戯画化されすぎていて、中途半端である。別の本では著者の方法論があまりに完璧なので、注意して管理すればプロジェクトの失敗などありえない、と述べる。また別の本では訳の分からないプロジェクト進捗（リスク）定量化ソフトウェアを使え、と言ってくる。どれもこれも全く生のプロジェクトを扱っていない。

筆者は現場で働きながらプロジェクトを扱った本を読み「プロジェクトを一度現場の視点で定義しなおす必要があるんじゃないの」とぶつぶつと考えてきた。考えた結果がこの本である。中にはマネジメント層や顧客層からは容認しがたい記述があるに違いない。しかし、これは偽らざる現場感覚である。ソフトウェア工学でプロジェクトを計測し、評価した結果が真実であると主張するのと、同じ権利を持って真実と主張できると筆者は自負している。

マネジメント層や顧客に訴える書籍が多いのはある意味で当然である。何故なら彼らには金があるから。彼らに気に入る理論でなければお金儲けは難しいに違いない。教授たちやコンサルタントがプロジェクトをサンプリングし、数値化、分析する。そして「プロジェクトはこうあるべきなんです」とマネジメントや顧客に訴える。それもよかろう。しかし、筆者は現場の人間である。敢えて現場から見たプロジェクトの真実を書きたい。

この著作がほんの少しでも現場エンジニアの喝采を浴びることができたら、筆者にとってはこれほどうれしいことはない。

では早速だが、まずプロジェクトを二元論的な観点から見てゆこう。

崖の上のポニョ（宮崎駿インタビュー）

昨夜ＮＨＫの番組で宮崎駿インタビューを見ました。

宮崎監督がイメージボードだか絵コンテを書きながら「子供たちにこの映画を通して生きていてもいいんだ、ということを伝えたいんだ」（正確ではない）とブツブツ言っていたシーンが凄みがありました。

言葉にしてしまうとありきたりですが、彼のつぶやきには彼の人生や、トラウマがしっかりと刻み込まれていました。それがこの言葉にただならぬ重さを与えていた気がします。

他には「僕は映画の奴隷だよ」という言葉も印象に残りました。

仕事や会社の奴隷なら普通にいますが、そうではありません。映画が「もっとできる。もっと凄いものが作れる」と彼を駆り立てるのでしょう。

夏目漱石の夢十夜だったか、木から仏像を作るのではない。仏が木に埋まっているのを掘り出すんだ、という話があったかと思います。
その人が頭で作るのではなく、その人にしか見えない何かがあって、その何かが人を動かすのです。芸術には芸術家を超えた何かがあるということなのでしょう。

しかし、宮崎監督の話は面白いですね。ポニョを見るのが楽しみです。

JavaMail は5年遅れている

このブログにしてはなかなかキャッチーなタイトルです。

JavaMailは現在バージョン1.4。1.1のリリースから10年近く経ちますが、本質的な機能は変わっていません。

つまり（かなりアクロバティックな展開ですが）JavaMailの本質は10年ほど変化していないのです。

言い換えると、

１．JavaMail 1.1 のリリースが10年近く前

２．JavaMail 1.4 と 1.1 の機能は本質的には変わっていない

３．ゆえに JavaMail 1.4 の機能は本質的には10年ほど変わっていない

すばらしく乱暴な展開ですが、私は結構確信を持ってこれを書いています。

なぜ確信を持っているか。

それは、JavaMailが依然としてクラサバ型のメールクライアントを意識した仕様だからです。

なぜそう思うか。

Folderがメッセージをキャッシュすべきである、とか、そもそも「フォルダー」という概念がクラサバチックなのです。

Swingで作るメールクライアントならFolderがメールをキャッシュするのもよいでしょう。しかしServletではどうするか。Folderがメールをキャッシュしたところで、じゃあそのFolderをどこにキャッシュするのか。FolderはSerializableではない（javax.mail.Messageすらも！）のでSessionにPUTすることはできません（してもいいけど仕様に反する）。じゃあServletContext？？それは何だかみっともないなあ。

それからgmailやdel.icio.usで採用されているような（「フォルダ」という概念ではなく）「タグ」という概念が、JavaMailでは実装不可能であること。つまり「フォルダ」という概念をそのまま「javax.mail.Folder」に落としてしまったという痛恨のミス。これらがJavaMailが5年以上前のレベルにとどまっている証拠だと私は思うのです。

3層Webアーキテクチャ（というのも古い言葉なのかな）でメールシステムを作るとすれば、JavaMailの仕様は結構無視してしまうしかない、と私は確信するものであります。

かなりマニアックな話題を中途半端に終わらせるのもなんですが、以上です。

GPL・・・

GPLというソフトウェアのライセンスがあります。
このページを見るような方であれば名前くらいはご存知かと思います。私も厳密には理解していないと思うのですが、大体以下のような特徴を持つライセンスです。

（１）著作権は書いた人にある
（２）GPLのソースコードは変更が自由である
（３）GPLは継承されなければならない
（４）GPLのライセンスを含むソースコード・ライブラリを含むアプリケーションのソースコードは無償で公開されなければならない

この（４）の制限が強烈です。

GPLとは言わば「ソースコード公開原理主義」です。GPLはソフトウェアの対価として金銭を受け取ることを認めてはいるものの、商用ソフトウェアでは事実上GPLのライブラリやソースを利用できないことになります。

結構厄介なもので、ちょっと気の効いた、自分では作るのがちょっと難しいようなライブラリがGPLだと、困ったことになります。GPLを含めるわけにはいかないので、既に優れた実装が存在するものをわざわざ0から自分で作る羽目になるのです。これはかなりの「しょうがねーなー」感があります。

LGPLやMITライセンスやApacheライセンスなど、もう少し利用しやすいライセンスが流行るのが当たり前だと思います。

学生の頃は「GPLいいじゃん」などと思っていたのですが、最近では「GPL困ったもんだね」派に傾いています。何につけても原理主義というのはよろしくないと思います。

Ajaxなるもの

今回もゴミ投稿です。
地味に忙しい毎日です。
残念ながら世の悪いニュースも目立ちますし、楽しい話題というものが見当たりません。

最近JavaScriptでいろいろ試しているのですが、Ajaxは本当に大変ですね。
JavaScriptであれだけモノを作れるGoogleという企業のスゴさが分かります。

誰かエクセレントなJavaScriptフレームワークを作ってくれないかしら・・・（おまえが作れって？ムリムリ）

トム・デマルコ 「デッドライン」

もう半年以上前に「デッドライン―ソフト開発を成功に導く101の法則」（日経BP社）を楽しく読んだのですが最近になってこの本に対する私なりの意見がまとまって来たので書評です。（遅いよ）

【この本のポイント】
プロジェクトで重要なのは人であり、コミュニケーションである。
重要な仕事（設計）に、集中してもらうこと。これがプロジェクト成功の秘訣。プレッシャーや残業は無意味！
プロジェクトでもっとも大きいコストは手戻り作業。故に当初の要求定義／設計作業に多くの時間リソースをつぎ込むべき。そうすればコーディング以降一気呵成に出来上がる。

【感想】
著者の人重視の姿勢には好感が持てます。本当にそうだと思う。

プロジェクトの運営論については設計フェーズをあまりに重視しすぎ。

・柔軟に対応できる設計と取り返しのつかない設計があると思う
⇒　手戻り覚悟で進めた方が結果的に早い／コストが安い場合があります。設計が完全に固まるまでコードを書かないのではなく、覚悟してコードに着手してしまった方がよい場合もある。（もちろんセンスと経験が必要な賭けではありますが・・・）

・技術的な実現可能性（フィージビリティ）を机上で検証するより、作って見たほうが早い。その結果手戻りが発生してもそれはしょうがない、という割り切りも必要。

私の経験では、旧来のウォーターフォール型を緩やかに運営するのがベストと思います（凡庸な意見だけどね）。スパイラル型の開発はやはり手戻りが痛い（※）・・・小規模なプロジェクトで優秀なコーダーが揃っている場合はスパイラル型が有効かもしれませんが、ちょっと画餅っぽい気がします。

（※）手戻りに強いのがスパイラル型ではないのか、と疑問に思われるかもしれません。確かにJunitで再帰テスト可能なレベルのちょっとした変更ならば問題ありませんが、設計変更レベルの手戻りはやはり厳しいものがあります。

以上。

JavaScriptメモ

JavaScriptは厄介ですね。
Ajaxと呼ばれるモノを最初にコーディングした人は天才に違いない。

以下、個人的な私のしょうもないチョンボメモ。普通の人には常識に違いない。

■ フォームのエレメント名に"."が含まれる場合、以下の記述では動きません。FireFoxでは完全にダンマリ状態になります。
フォーム名:MY_FORM_NAME
エレメント名（テキストボックスなど）:INCLUDE.DOT.ELEM
駄目な例

document.MY_FORM_NAME.INCLUDE.DOT.ELEM.value = arg;

正しくは

document.MY_FORM_NAME.elements["INCLUDE.DOT.ELEM"].value = arg;

■ RADIO入力項目の値を取る時は添え字[i]を忘れないように！さもなければundefinedが返ります。

var hoge = RADIO_ELEM.value;
alert(hoge); // ← "undefined"

hoge = RADIO_ELEM[i].value;
alert(hoge); // ← "期待通りの値が戻る"

■ 親画面のJavaScriptを呼ぶ方法

window.opener.myFunction(arg);

Eclipseカスタマイズ

ほとんど個人的メモです。

Eclipseの新規作成メニューや右クリック"New"のコンテキストメニューが気に入らないときは、Window → Customize perspectiveで追加／削除ができます。

以上。

大阪橋本知事の改革で気になること

「民間はもっと苦労している。公務員の方も理解して欲しい」というのがasahi.comで橋本改革関連のニュースでよく取り上げられている決めゼリフです。ネットを巡回していても（私の巡回範囲なぞ狭いものですが）この言葉を支持する書込みが多々見られます。

もう少しこのスローガンを補足すると「大阪は民間で言えば債務超過の大赤字であり、ほとんど倒産状態である。民間であれば潰れて皆が路頭に迷っていてもおかしくはない。公務員だからといって安穏とせず、リストラに協力して欲しい」といったところでしょうか。

大阪の公務員の方からすれば受け入れがたいロジックだと思います。民間民間ってこっちは公務員なんだから知らないよ。民間の人が苦労しているからって、それは民間企業を選んだその人の責任でしょうが。

一方で一部のWeb上での大阪公務員バッシングは激しいものがあります。「子供がいるから給料が貰えないと困るとはなんだ。民間でそんな理由が通用するか。こっちは金も時間もなくて子供すら作れないんだ」。公務員は甘い。民間じゃ考えられない。俺たちは大変な思いをしているのに。

それぞれの立場にはこれ以上は立ち入りませんが、私が気になるのはWeb上の公務員バッシングにどうしようもないルサンチマン（怨恨）が感じられることです。

そのルサンチマンが「民間は苦しいのに公務員が楽してはいかん」という単純な図式を強烈に支持しているように見えてしまう。

薄給でハードワークをこなしながら、会社が潰れやしないか、リストラされやしないか、と不安を抱えるサラリーマンや派遣社員の人が公務員を叩いている。この状況が悲しく見えてしまうのは私だけでしょうか。

民間は民間でそれなりの、公務員は公務員でそれなりの人生が送れる社会が、本来あるべき社会ではないでしょうか。今の社会がおかしいからルサンチマンを持たざるを得ない人が増えているのではないでしょうか。

何かによって搾取されている若い世代の人たちも、橋本改革の図式に表面的に感情移入するのではなくて、その裏にある本当の問題（それが何かは私にもはっきりとは分かりませんが）を考えてみてもよいのではないでしょうか。

Hibernateはすごい！

今更ですがHibernateはすごいです。BeanとDBにマッピングするXMLを記載するだけでDAOが作れる。DAOだけなら別にどうってことはありませんが操作が直感的で、XMLにこう定義したからこうなったらいいなあ、という希望をビシビシ実現してくれます。

これはすごい。DAOはHibernateで止めを刺す、という印象です。

（しょうもない投稿ですが以上）

Spring Web Flow 1.0.5 でサンプルアプリの作成（中断）

一旦検証を中断します。

理由は優先度が下がったためです。
（もともとほとんど意地で取り組んだものだったし）

今のところの感想。

■デポーさんのページは非常によくできています。

■XMLに依存しすぎ
メソッドコールをXMLで定義するあたり「やりすぎ」という気がしますが趣味の問題かもしれません。SWFコアのデバッグ出力がしっかりしているので慣れてしまえば問題ないとは思います。
私の好みではInterfaceを定義してそれを実装する方が直感的でやりやすい（私だけじゃないと思うけどな・・・）。

以上

高コスト低リターンのテスト

低リターンのテストにやたらに体力を掛けてしまい、成果物の品質が悪くなる。そんなプロジェクトが珍しくありません。

なぜ低リターンのテストに体力が掛けられるような事態に陥ってしまうのか。その理由はプロジェクトが効率的に回っていないからです。

プロジェクトを効率的に回すためには、重要で効果の高いタスクに適切にリソースを配分し品質のよい仕事をさせることです。
重要な仕事を思いついてそこにリソースを回すくらい誰だって出来ます。だから効率的なプロジェクトとは、ちゃんと無駄な作業を定義しそれを行わないという判断ができるプロジェクトなのです。あるタスクを「行わない」とする判断こそが重要なのです。

言葉にすると簡単ですが、実行するのは実に難しい。普通のプロジェクトではタスクの優先付けをするのが精一杯だと思います。そこから一歩進めて「優先度の低いタスクを行わない」という意思決定ができるマネージャやリーダーはなかなかいません。それどころか「あれもこれも」とムダな作業を思いついてどんどんタスクを積み上げて行く人の方が多いくらいです。
人はとにかく作業に意味を見出したがりますし（そして大抵何らかの意味は見出せます）、自分の思いつきを他人から「意味がない」と言われることを嫌います。だからタスクは増える一方でなかなか減らない、ということになってしまいます。

話をテストに戻しましょう。
やるべきではないテストにはどのようなものがあるでしょうか。私が真っ先に思いつくのは以下の二つです。

１．OSのシステムクロック変更（時間を進めたり戻したりする）テスト
２．バッチ／オンラインカレンダー変更

まず１の時間を進めたり戻したりするテスト。

【無駄な理由１】システム的に無意味
まずシステムクロックは時間ではありません。UNIXを知っている方なら誰でもご存知かと思いますが、1970年1月1日、00:00:00からの秒単位のカウンターに過ぎません。
だから例えば「システムのカットオーバーが1年後だからシステム時刻を1年進めよう」という思いつきで時刻を進めたとしても、カウンターが数千万先に進んだ、というただそれだけの話なのです。しかも「カウンターを先に進める」というカットオーバー時にあり得ない設定変更を加えてテストをしている。
特にカウンターを意識してコーディングしなければ、プログラムはカウンターに依存せずに動きます。プログラムに関係のない設定変更をしてテストをするのは、全くのムダです。そんなことに体力を使うくらいだったらテストを2回した方がよほどましでしょう。

【無駄な理由２】時間の概念を全く考えていない
時間とは何でしょうか。昔から哲学者や物理学者が考えてきた深い問題です。生きられる時間。運動としての時間。物理学上のモデル化された時間。
時間というものを少し考えてみれば、システムクロックなどとは全く無関係であることにすぐ気がつくはずです。時間を進めることは人には不可能です。私にはこれほど自明なことはないと思えます。
システムクロックを先に進めて「今日は一年後だ」などと考えるのは、日めくりカレンダーを10枚めくって「10日たった」と考えるのにも等しい。進んだのは時刻ではない。単にカウンターを進めるというあり得ない操作をしただけです。あるいは日めくりカレンダーが10枚分余計にめくれた、それだけのことです。
これをテストの前提にするなど、全く意味がないと言えるでしょう。

【無駄な理由３】それこそ時間がもったいない
何台もあるサーバーの時間を変更する作業と、時間を戻してログをチェックする作業がもったいない。

２のバッチ／オンラインカレンダー変更。「明日は実際には水曜だけど日曜だ」というやつですね。それも人が勝手に思い込んでいるだけならいいのですが、システムに定義されているカレンダーを変更してまでテストをするから始末に悪い。

無駄な理由については先に述べたこととほとんど変わらないので割愛しますが、ようするに何をテストすべきかがちゃんと把握されていないために無駄なテストが行われてしまうことになるのです。

私はテストの計画時には以下の項目を押さえておくべきだと思います。

１．優先度を考慮すること
２．インターフェースを考慮すること
３．不安駆動や思いつき駆動になっていないか反省すること

１はテストに限らず重要なことです。無駄なテストは行わないこと。それによって時間と人という貴重なリソースを、例えばテストの結果照合やテスト手順の精緻化というもっと大事な仕事に回すことができます。それからテスト中に発生するであろう障害や問題に対応するための、余力も確保して計画しておくべきでしょう。

２はシステムに無関係なファクターをテストに持ち込まないことです。
オブジェクト指向という文脈でのインターフェースという言葉は、プログラミング以外のエリアでも有効です。すなわちインプットとアウトプットを明確に把握すること。システムに影響を与え得るファクター（＝インプット）は何か。そのファクターのうちでテストをしておくべきものは何か。そしてそのパターンは。期待されるアウトプットは何か。
システムクロックやカレンダーはほとんどのシステムではインプットにはなりません。そのような要素をテストに持ち込んでも意味はありません。

３は単なる思いつきや不安を、簡単にタスクに落としてはならないということです。不安のスコープと原因と解消、それぞれに道筋をつけた上で、さらに優先付けし、必要があれば切り捨てなければなりません。不安から生じた思いつきのタスクをいちいち持ち込んでも、現場が疲弊するだけなのです。

以上。今回はなんだか熱くなってしまいました・・・

Spring Web Flow 1.0.5 を試してみる

挫折して悪口を言っているだけでは悔しいので昔のSpring WebFlwo（以下SWF）バージョン（1.0.5）から勉強しなおしてみます。

なぜバージョン1.0台か。
SWF2.0からJSFやAjaxとの連携が教化された旨の情報をどこかで読んだからです。その画面＝Viewの対応強化にともなって設計の不透明さが増大したことは確かです。だとすれば1.0をみればSWFの設計コアがより分かり安いのではないか、と。

1.0には以下のような参考サイトもあります。かなりしっかり解説されていますね。大したものです。
Spring Web Flow解説(1)
2.0よりも少しは状況がマシではないかと期待しています。

（Spring WebFlowが今のままでは主流にならないという確信は変っていません。それでも勉強するのはほとんど意地です）

1.0.5はsourceforgeから辿って取得しました。

まずはphonebooksサンプルのビルドです。（パスが"/"なのはcygwinだからです。）
readmeにあったようにant distしてみます。

[phonebook/] $ pwd
/spring-webflow-1.0.5/projects/spring-webflow-samples/phonebook
[phonebook/] $ ant dist

無事にtarget/artifacts/war/swf-booking.warが作成されました。（このあたりも2.0よりはずいぶんスムースな気がします）

すぐにtomcat6.0で動かすこともできました。DBも不要のようです。
サンプルはこうでなくちゃいけません。

今回はここまでとします。できれば次回以降でシンプルなアプリを作成し、SWF2.0につなげたいと思っています。

Spring Web Flowを試してみる（３）～ だめだこりゃ

※挫折・負け惜しみの記録です。

サンプルアプリ（swf-booking-mvc）は結局ほとんど役に立ちませんでした。
機能使いすぎ。どれがswf必須で、どれがオプションなのかが分かりません。しょうがないので０からアプリの作成に挑戦してみます。

（３日ほど経過）

ダメです。シンプルな画面遷移だけのサンプルすら作れません。

「Developing a Spring Framework MVC application step-by-step」のようなドキュメントがない。付属のbooking-mvcサンプルとリファレンスマニュアルをつきあわせて読んでみても、どう作ればいいのかさっぱり分かりません。

最後の手段でソースをごりごり読んでみましたが、さっぱり理解できない。設定ファイルをロードしておいて、リクエストのパラメータからコントローラとビーンを引っ張って処理をしているんだろうな、という程度の認識で読んでも全く分かりませんでした。Struts 1.0はシンプルで分かりやすかったのに・・・

【まとめ】

・サンプルひどすぎ。あんなリッチなサンプルではWebFlowの機能が全然見えません
・ドキュメント貧弱すぎ。リファレンスマニュアルだけじゃ作れっこない

このテクノロジーはいずれ消えるだろうな、というのが今のところの感想です。

「障害を許さない」プロジェクトが破綻する理由（５）

■ システム障害はコントロールできない

ストア派の哲学者がかつて言ったそうです。「自分のコントロールできないものは諦めろ。自分がコントロールできる対象に集中しろ」と。

一応権威付けにストア派を持ち出してみましたが、実にまっとうな考えだと思います。

確かヤンキース松井だったと思いますが「不調の時いくらマスコミに叩かれても僕は気にしません。ぜなら僕はマスコミをコントロールできないから。自分がコントロールできること（つまり練習）をひたすらやるだけです」という旨のことをどこかで言っていた気がします。（例によってソースはありません）

まさにストイックな考え方ですね。自分がコントロールできる対象に集中すること。コントロールできないことは対象としない。

ではコントロールできないものとコントロールできるものとの違いはなんでしょうか。何を以って区別したらよいのでしょうか。

判断のセンスが問われるところです。

ヤンキース松井はマスコミをコントロール不能の対象としました。
でもひょっとしたらそう考えない人もいるかもしれません。悪口を言われたら言い返せばいい。論争によって黙らせることもできるかもしれない。裁判に訴えるという手もある。あるいはマスコミの指摘が正しいならばそれを受け入れてもいい。こっちがおとなしくなればそれ以上叩かれない可能性もある。

微妙なところですね。いずれも効果的ではないように見えます。それに挑発に乗らされていらぬ体力を使わせられている感もある。マスコミに迎合するのも美しくない。

マスコミをコントロールできないものとする判断には二つの価値観がキーになっているようです。

一つ目は美学。しょうもないバッシングにいちいち反応するのも迎合するのもカッコ悪い。

もう一つは経済学。マスコミをコントロールしようとして必死になっても、出来ることもその効果も限られているでしょう。それよりもひたすら自分が納得行くまで練習する方が効率的だし、体力の使い方としても有効です。

そろそろ本題に入りましょう。

システム障害がコントロール可能できるか。間違いなくコントロール不能です。コントロール不能という属性がシステム障害という概念に必然的に含まれていると言ってもよいでしょう。テストで意図的に障害を発生させる場合などを除けば、コントロール可能な障害という言葉がほとんど自己矛盾だからです。

システム障害は常に不意にこちらの意志とは無関係に発生するものです。そういう意味では天災に例えてもいいでしょう（世の中には富士山の噴火を止めるために日夜頑張っている人もいるそうですが）。

違和感を持つ人もいるかもしれませんね。システム障害は少なくとも人災であって天災ではない。コントロールできるのではないか。

では具体的に何ができるでしょうか。設計書を読み返す？プロジェクトのメンバーに「障害は許さない」とプレッシャーを掛ける？いずれも無意味です。

人は往々にして「将来をコントロールできる」と考えたくなるものです。そこには人間の本性に備わっている強い欲望がある。あるいは未来に対する不安を何とかしたい、という焦燥が隠されている。その不安に「原因と結果」というスキームを持ち込むとこうなります。

「今」は間違いなく次の瞬間につながっている。つまり、未来の原因は、今である。今が分かれば未来が分かる。

そもそも「原因と結果」というスキームが人間的な尺度に過ぎないことに気がつくべきです。あなたは自分がいつ死ぬのか、分かりますか？自分が死ぬ原因は今の自分に全て含まれている。本当でしょうか。それはただの人間的な解釈に過ぎないのではありませんか？

「原因と結果」は全て事後的な人間にとっての認識の枠組み＝解釈に過ぎないのです。生きるために必要な誤謬としての真理。もし運が良ければ、前提が変らなければ因果の法則通りに物事が進むこともあるかもしれません。しかし必ずしも物事はそうはならないことの方が多い。

もう少し穏当な表現を使えば「原因と結果」という枠組みは慎重に適用されなければならないし、その内容ももっと慎重に検証されるべきなのです。あくまで人間が長い進化の過程で培ってきた概念に過ぎない。極めて有効に働くこともあるかもしれませんが、そうでない場合だって多い。
「原因と結果」というスキームは常に事後的であることに常に注意すべきです。未来への不安を覆い隠すために安直に時系列を逆転させてはなりません。

未来は原因と結果という時系列で理解できるよりももっと豊かで、もっと不確実なものなのです。

少し脱線しました。

しかし明らかにシステム障害は好ましくない。ではそれを防ぐために何をしたらよいのか。

答えは明らかです。同じようなことを繰り返しますが「入念にテストをしておくこと」「システムの状態を常に把握できるようにしておくこと」それから別の次元になりますが「システム障害を業務の障害に直結させないように、システム障害を折り込んだ業務を準備しておくこと」。

障害はコントロールできない。そこがプロジェクトの出発点だと私は思います。