Struts2を試す（３）

一通りReady, Set, Go!を試しました。

引っ掛かった点は全てblogに書きました。全体的にかなり順調に行った感じがします。

【Ready, Set, Go! 総評】

ぱっと触っただけなので今後変るかもしれませんが、今の所欠点が見当たりません。Spring MVCよりもイケてんじゃないか、というのが印象です。

SpringではXMLの編集、コントローラの作成、Beanの作成を一通り完了しないと画面遷移が作れないところが面倒でしたが、Struts2ではXMLで汎用的な設定をしておけば（下記設定）JSPのガラだけでとりあえずの画面遷移の確認ができます。これは結構便利です。考えられてるな、という気がします。

<action name="*">
  <result>/{1}.jsp</result>
</action>

とりあえずコーディングして、動かして、UTして、という開発手法であれば SpringMVC よりも効率がよいのではないか、と思います。

それに、SpringMVC もそうでしたが、触っていて楽しい。具体的に楽しさとは何かと言えば「こうすればこうなるんだろうな、という予測がビシビシ当たる」それから「よく考えられた設計であることが肌身で感じられる」ことです。フレームワークには非常に重要な要素だと思います。

ただし、柔軟さ、容易さと成果物の複雑さは表裏一体です。言い換えれば、いろいろと柔軟に出来てしまうフレームワークを使うと出来上がったものが複雑になりがちなのです。その点、SpringMVC は適度な窮屈さがあって良いデザインだったと思います。Struts2の便利さが仇にならないか、もう少し見て行こうと思います。

【おまけ】

Localizing Outputで、package.propertiesの日本語版を下記手順で作成しました。（まあ大した手順じゃありません）
dosプロンプトから

> native2ascii.exe　（当然パスが通っているのが前提です）
パスワード
\u30d1\u30b9\u30ef\u30fc\u30c9
ユーザー名
\u30e6\u30fc\u30b6\u30fc\u540d

などと変換。生成された文字列を"package_ja_JP.properties"に貼り付け（以下のイメージ）

requiredstring = $\{getText(fieldName)} \u304c\u5fc5\u8981\u3067\u3059\u3002
password = \u30d1\u30b9\u30ef\u30fc\u30c9
username = \u30e6\u30fc\u30b6\u30fc\u540d
HelloWorld.message = Struts\u306f\u8d77\u52d5\u3057\u3066\u3044\u307e\u3059 ...
Missing.message = \u5de5\u4e8b\u4e2d\u3067\u3059\u3002

package.propertiesと同じ場所に置く。

以上の手順で問題なく日本語が表示されました。

参考サイト）Javaリソース・プロパティーメモ(Hishidama's Java resource/property Memo)
これは便利）www.Javable.Jp - Tools　（プロパティファイルエディタです。面倒くさいnative2ascii変換が不要となります）

「プロジェクトの人間学」完了のお知らせ

「プロジェクトの人間学」 全ての草稿をアップロードしました。

３０を過ぎてから感じること

今回は本当にどうでもいいような話題です（当人にとっては重要なことですが）。
歳を取るにつれて心身が変ってくることが分かります。３０の半ばとなった今の状況をまとめてみました。

▽ （悪い）秋、冬、春はフケが大量に出るようになりました。
シャンプーしてドライヤーで乾かした直後から一日中、かなりの量が出ます。シャンプーをいいもの（ケミカル合成品ではなく自然石鹸系）に変えても効果なし。恐らく乾燥が原因なのでしょう。頭も痒いです。
乾燥を押さえるため、妻の保湿化粧用品などを試していますが、少しは効果がありそうな感じです。

▽ （悪い）皮膚が痒い
夏と秋に痒さを感じることが増えました。
夏の痒さは格別です。汗かアレルギーかは分かりませんが、そのいずれかだと思っています。
関係があるかどうかは分かりませんが花粉症っぽい症状も出始めました。今の所有効な対策は見えません（というかまだ真剣に対策を考えていません）。
秋は乾燥系の痒さだと思います。体の一部がピリピリして痒い。夏よりはマシです。

▽ （悪い）直近の記憶力の衰え
残念ながら顕著です。何気なく置いたボールペンや書類を忘れて焦って探すことが多くなりました。

△ （良い）
若いときよりもある種の理解力がよくなりました。

－　本質をつかむ力
悪く言えば大雑把に、よく言えばこまごまとしたことに惑わされずに、問題の構造をすばやく把握する力がついたように思います。経験が蓄積されたのでしょう。

－　人の気持ちが分かるようになった
歳を取った人が考えることや、昔の偉人が考えたことが理解できるようになりました。
若い人の気持ちも、若いときは若いなりに理解していたのですが、今は別の角度から見られるようになりました。こいつも大変なんだなあ、とか。

幸いまだ大丈夫そうなこと

△ 体力の衰え
数年前から簡単なワークアウト＋柔軟体操を始めたせいだと思います。軽い運動＋本当に軽い柔軟ですが効き目はあるようです。体は大事ですね。

以上です。

「プロジェクトの人間学」に一件追加しました

標準化が達成すること
そろそろ終わりそうです。

Struts2を試す（２）

引き続き Ready. Set. Go! 通りに試しました。

まずは以下のエラー。

/HelloWorld.jsp TLDによると、タグ url の属性 var は無効です

以下のタグで出ています。

<s:url var="XXX" action="XXXXXXX"> 

リファレンスを見ると、id はdeprecated なので var を使えと書いてありました。deprecated ったって var が使えないんだったらしょうがないわけで、逆にvar ではなく id を使ったら動きました。struts-2.0.11.2(GA版)の標準機能をdeprecatedとして、存在しない機能を推奨しているとは、Tutorial と ドキュメントがずいぶん先走っているようです。
しかし、JavaScriptやCSSで多用する id 属性は確かに使いたくないですね。

途中で com.opensymphony.xwork2.ActionSupport のソースが読みたくなって探して見たのですが、、xwork-2.0.5.jar のソースが見当たりません。
http://www.opensymphony.com/xwork/download.action
Internet Archive で過去を辿っても 2.0.5 が公式にリリースされた形式がありません。（正直結構嫌気がさしました）

ということで2.0.11.2の検証を中止し、ベータの2.1.2で検証を続けることに。

これまで作ったWebプロジェクトのjarのみを入れ替えてすんなり行くかと思ったら、Tomcat起動時に以下のエラーが出てダメでした

Unable to load configuration. - bean - jar:file:/C:.../workspace/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/webapps/Struts2Tutorial/WEB-INF/lib/struts2-core-2.1.2.jar!/struts-default.xml:46:178

Tomcat（あるいはEclipse）にゴミが残っているのではないかと思ってプロジェクトを削除／新規作成してもダメ。
調べてみるとException in struts2 server startupのページがヒット。ガイド通りにcommons-fileupload-1.2.1.jarをWEB-INF/lib追加したら解決しました。

次は <s:include> で日本語を含むファイルのincludeに失敗。チュートリアルでは当然英語なんですが、ためしに日本語入れてみたら見事に文字化けです。pageEncoding とかContentType とか設定してもダメ。日本語が消えたり、化けたりする事態は変わりません。
<jsp:include>では化けないので <s:include> に問題ないかいろいろ調べてみました。しかしWebには有用な情報はありません。（過去に8Kを超えるDBCSテキストで文字化けが発生するというバグはあったそうですが、今回の事象とは関係ありません）
ステップ実行などでソースを追ってみると、 org.apache.struts2.components.Include#getEncoding() でUTF-8でエンコードしているのが化けた原因であると判明。JavaDocによるとstruts.propertiesに指定する'struts.i18n.encoding'を見ているとのこと（基本ですかね。私としてはTutorialに一言欲しいところです）。ここで'Windows-31J'を指定すればよさそうなことが分かりました。どうやらstruts.xmlで指定できそうです。（参考）[Struts2] struts.propertiesが不要に

以下をstruts.xmlに追加すると、

<constant name="struts.locale" value="ja_JP" /><!-- ← 恐らく不要だがついでに -->
<constant name="struts.i18n.encoding" value="Windows-31J" />

<s:include>タグの文字化けは無事解消しました。

今日はここまで。

IT業界で効率を押し下げているもの（３）

▽　技術への無理解

技術が複雑になるにつれ、顧客／マネジメントにはますます理解不可能なものとなって行きます。

上手く行っていればまだいい。でも一度障害が起きるとその事象を説明するだけでも大変です。結果、現場の説明体力が非常に重くなる。エンジニアはますます勉強する時間を失い、くだらない資料の作成に追われることになるわけです。

技術を実際に触ったことがなくても、技術について語ることができれば（それも長ければ長いほど）エンジニアが評価される。出世ができる。そういう事態が続いています。

「エンジニアに必要なのは技術力ではなくコミュニケーション能力だ」という言葉を聞いたことがないでしょうか。これは明らかに間違いです。しかしそのスローガンがまかり通った時代が確かにありました（ひょっとしたら今でもそうかもしれません）。しかしエンジニアには両方の力が必要なのです。

技術がむづかしいが故に技術を使いこなせる人間よりも、まことしやかに技術を語れる人間の方が重視される。その風潮がIT業界の効率を押し下げている要因の一つだと思います。

IT業界で効率を押し下げているもの（２）

▽　技術のオープン化

これは逆説的な要因です。

Java、SQLなどオープンな技術が主流になることは基本的にはよいことだと思います。いろんな技術が生まれ、淘汰され、結果的によいものが残って行く。開発効率もよくなる筈です。
実際 Apacheを筆頭に、枚挙にいとまがないほど見事なソフトウェアが公開されています。かくいう私も今では Tomcat と Eclipse がなければ仕事になりません。

しかし、少し冷静に考えてみましょう。

例を上げてみます。
Struts は Webアプリケーションフレームワークという概念を一般に広めた、優れたアプリケーションです。Servlet, JSP, Bean というシンプルなMVCモデルを拡張し、大規模な開発と運用に耐える構造にしました。XMLによってMVCそれぞれを疎結合するという非常にエレガントなデザインとなっています。
その後、優れたWebアプリケーションフレームワークが他にもいろいろと出てきました。そしてStrutsもバージョンアップが重ねられています。つまり一口にWebアプリケーションフレームワークといっても、相当な数の選択肢があるのです。
これは裏返して言えば学習体力の増大とスキルの蓄積が困難であることを示しています。（Strutsのプロでも入ったプロジェクトでSpringを使っていたら一から勉強しなければならない、など）
しかし私は思います。今 Struts 0.9 で何が悪いのか。別に悪いことなどありはしません。多分、ほとんどのアプリケーションがStruts 0.9で開発できるはずです。しかし、今敢えてStruts 0.9を選択するプロジェクトなど存在しないでしょう。

次々に新しい技術が生まれ、そして消えて行きます。そしてエンジニアは新しい技術を追い続けなければならない。

その結果今どうなっているか。エンジニアによって持っている知識がずいぶん偏っている状況が生まれています。今流行りの「格差」という言葉を使ってもよいでしょう。好きでいじる人はどんどん詳しくなるし、そうでもない人はついて行けない、という事態です。

今、一口に「Webアプリケーションフレームワーク」と言っても実にさまざまなコンポーネントがあり選択肢がある。代表的な技術を使いこなすだけでも結構大変になっています。

技術のオープン化は確かに必要だと思います。しかし、その結果副作用が生まれていることに、エンジニアは注意が必要でしょう。すなわち、我々は新しい技術を追いつづけなければならない、ということです。逆に言えば能力のあるエンジニアにとってはチャンスでもあります。新しい技術を追いかける限り、先頭の一握りになれる可能性があるのですから。

IT業界で効率を押し下げているもの（１）

さまざまな潮流が業界全体の効率／品質を押し下げているように思います。

▽　セキュリティの重視

モバイルＰＣやインターネット接続が禁止されるプロジェクトが増えてきました。
外部から断絶された環境でコーディングを行うのは極めて非効率的な作業です。
Ｗｅｂ上にはコーディングサンプルや障害情報、技術解説、サンプルライブラリ（継承を要求するライセンスには気を付けなければなりませんが）など大量の有用な情報があります。それらの情報にアクセスできない環境でのコーディングは、かなりやりづらいものです。結果的に成果物の品質を押し下げるのは間違いありません。

そのリスクを考慮せず「セキュリティ」という大義名分だけで外部とのネットワークを遮断するのは単なる無思考といえます。セキュリティを重視して運用を定めるのであれば、納期／品質にリスクがあることを理解しなければなりません。（偉い人たちは決して理解しようとしないでしょうね・・・）

いたずらにエンジニアを縛っても何もいいことはありません。重要なシステムのコーディングを任せるほどエンジニアを信頼するのであれば、インターネットにアクセスするのだって任せればよいのです。めちゃくちゃにプレッシャーを掛けたりいじめない限り、悪いことなんかしやしません。開発用のネットワークと外部を接続するのが嫌ならば、ＡＤＳＬでも何でも引いて別のネットワークを準備すればいい話です。「セキュリティ」を絶対視して杓子定規に運用を定めるのは成果物の品質を押し下げるだけです。

エンジニアが設計／コーディングに集中できる環境を準備すること。その視点が必要だと思います。

「プロジェクトの人間学」に一件追加しました

追加しました。
http://sites.google.com/site/itzattamemo/Home/projectningengaku/shinzenbi

Struts2を試す

久しぶりの検証系投稿です。
Strutsの0.9や1.X系は昔触ったことがあるので、2.X系にチャレンジしてみます。

Springがじわじわと企業向けサービス重視に向かったということで、もう一方の勇Strutsのシェアが結果的に広がるんじゃないか、と思ったのが動機の一つです。↓

※ SpringSource Enterprise Maintenance Policy によると、企業で有償で利用している顧客は最新バージョンとバグ・セキュリティフィックスが即座に提供されますが、コミュニティ版は基本的に３ヶ月遅れになるようです。コミュニティが非活性化するのは明らか？？

本当は復習も兼ねて1.3からいじってみたかったのですが、ざっとみる限り1.X台は本質的に変ってない様子（当たり前か）。Struts2.0からコアが書き変ったということで若干の違和感はありつつも、試してみたいと思います。

とりあえずReady. Set. Go!は以下のトラップに引っかかったものの、ほぼ問題なくOK。

▽トラップ
アクセスするといきなり"There is no Action mapped for namespace / and action name HelloWorld"と怒られる

▽対応
struts.xmlはsource folderになければならないとのこと。eclipse かに座 ではソースフォルダにstruts.xmlを移動できなかったので、WEB-INF/classes フォルダを作成し、そこに struts.xml を放り込むと解決。

やはり質の良いドキュメントがあると早いです。
本日は以上。

携帯小説

「あたし彼女」という携帯小説が評判になっています。

私もちょっと読んでみました、こりゃ凄いですね。ちょっとしんどくて読みとおすことはできなかったのですが、それにしても「すげえなあ。ここまで来たか」という感じです。

といってもさかしらにこの手の表現をあざ笑おうというつもりはありません。

ちょっと乱暴な連想ですが、俳句という表現形式もまたシンプルで奥深いものがあります。短い単語を連ねる文学表現は、日本語に案外マッチするのかもしれません。

それにしても考えさせられるのはケータイというインプット／アウトプットツールが生み出す形式です。何を言いたいかというと、メディアによって人の表現形式も異なってくることを、ケータイ小説は如実に示しているということです。

ケータイ小説は恐らく手書きでは生まれなかった表現形式でしょう。「いや*ケータイ*小説なんだから当たり前だろ」というツッコミは勘弁して下さい。そうではなく、ここまで短い文章を、感覚的な口語体で連ねる、という表現形式です。

つまり、極端を言えばツールやメディアが表現形式の制約となるのではなく、むしろ積極的に表現形式を生んでいるとも言える訳です。
あらかじめ型が決まっていて、その型をどう自分のものにするか、そこで表現の質が決まってくるように思います。

振り返ってみれば、昔から毛筆から鉛筆、万年筆、ボールペン、ワープロと表現ツールは変って来ています。特に手書きからワープロへの進化は、文学という表現形式に大きな影響を与えているに違いありません。（この雑文だってＰＣがなければ生まれなかったことでしょう。）

また連想が飛びますが、村上春樹の「風の歌を聴け」という短編小説があります。これもまた短い文章を連ねて表現された文学です。この小説が発表されたときも「こんなの文学じゃない」「あれならオレだって書ける」などと言った人もいたそうです。新しいものが出たからと言って、安易に批判してはいけない、ということでしょう。

しかし、ケータイ小説をチラっと読んで、やはり重厚で体系的なスゴイ小説を読んで見たいなと思う人も多いのではないでしょうか。ひょっとして「カラマーゾフの兄弟」の新訳が売れているのも、ケータイ文化への反動だったりして。

「プロジェクトの人間学」に一件追加しました

「～でなければならない」思い込み
を追加しました。

「プロジェクトの人間学」に一件追加しました

良いミーティング／悪いミーティングを追加しました

村社会としての会社

日本の会社の特徴を表すのに、終身雇用制とか家族主義といったキーワードが用いられます。

その良し悪しはさて置き、プロジェクトに入って仕事をしているとやはり同じ会社のメンバーが強い連帯感によって結ばれていることがよく分かります。

例えばトラブル対応やミスの対応。例え直接的な関係はなくても、同じ会社のメンバーが起こしたトラブルには、他のメンバーも自分は役に立たないと分かっていても一緒に対応するとか、同じ会社のメンバーのミスはかばってあげるとか。

いや、当たり前と言えば当たり前なのですが、異なる会社のプロジェクトメンバー同士でかばい合うよりも濃い絆がそこにあることがはっきり分かります。

中には「同じ会社とはいえ、とばっちりだよな」と思っている人もいるようですが、祭りのように楽しんでいる人もいます。

そういうのを見ていると、やはり日本の企業というのは村社会的な結束があるなあ、という印象を持ちます。

村社会という観点から言えば、「ちょっとおかしいな」と思っても「村八分＝リストラ」が怖いから断れないとか、そういう束縛もあるのではないか、「オレは違う」とはなかなか言えない。単独行動が取りにくい。そういう特徴もあるように思います。

そういう会社＝村社会の中では、何とか楽しくやって行ける人と、ちょっと息苦しいなと思う人とに分かれるはずです。

さて、あなたはどちらのタイプに属するでしょうか？

早く帰る仕事術（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

プロジェクトの目的はよいシステムを作ることである。よいシステムを作るためにやらなければならないことは、実はさほど多くはない。プロジェクトが終わった後でほんとうに必要だった会議、電話、報告書がどれほどあったか、考えてみればよい。いかに仕事をしないか。これがよいシステムを作るコツなのである。

呆れる方もいるだろう。全てのタスクに全力で取り組んでこそ品質が上がるのではないか。100%を目指すことは理念としてはよいが、現実的ではない。ドラッカーの有名な言葉にもある。「正しくないことを効率的に行うことほど無駄なことはない」。品質にも落としどころが必要である。100%安全な車が作れるだろうか。作れたとしていったいコストと期間はどれだけ掛かるか。それよりも妥当な品質と価格の顧客ニーズに合う車を目指すほうがよほど現実的であるし、結局顧客もそちらの方を選ぶであろう。

80対20の法則（パレートの法則）が極めて有効である。この法則をプロジェクトに当てはめると、2割のタスクがシステムの品質の8割を決定する、ということになろう。この数字は実感に合うのではないだろうか。日々の割り込み電話、障害報告書、設計書作成、ーティング、それらのTODOやタスクや割り込み仕事がどれほどシステムの品質に貢献しているだろうか。

2割のタスクが品質の8割を決定し、8割のタスクは2割の品質しか決定しないと仮定してみよう。すると上位2割のタスクの重要度は4(8/2)であり、下位8割の重要度は0.25(2/8)となる。その比率は実に16倍である。すなわち、あるタスクが他のタスクよりも16倍重要でありうる。単純に言えばあるタスクに1時間かけることは、他のタスクに16時間かけるのと同じ価値がある。プロジェクトが進行する中で一定のまとまった時間を確保することは非常に難しい。だから重要なタスクに集中しなければならない。

有効なタスクよりも1/16も効果的でないタスクにリソースを投入することは、時間のムダであり、仕事もどきであり、貴重な人生のムダ使いである。それが他人の人生のムダ使いであるとすれば、ほとんど犯罪的である。

そうは言ってもやるべきことはいくらでもあるような気がする。だから捨てることを優先して考えるのである。将来を見据えてタスクを捨てて行かねばならない。では無駄な作業とは何か。いくらでも思いつくはずである。ミーティング、障害報告書、重箱の隅を突付くような細かい仕事。無駄な作業の洗い出しは簡単である。難しいのはいかにして作業を切り捨てるか。実際に忙しい時には断りやすいが「その作業はムダだからやりません」というのではカドが立つ。余りそのようなことを繰り返していると相手にされなくなる可能性がある。うまくムダな仕事から逃げなければならない。

意外に簡単なのはミーティングを断ることである。ほんとうに必要とされるミーティングがどれほどあるか。ぜひこの会議には出て欲しい、と言われることは稀であろう。実際「今日はかくかくしかじかのためミーティングは出られません」とか「ここ２週間一切無関係だったし、今後も関係あるとは思えないので次回以降のミーティングは出ません」というのは案外通り易い。思い切って言ってみたらよい。確かにミーティングをキャンセルすることによって最新情報に触れることができなくなる。だがそこは割り切るべきであろう。関係がありそうな話題については、ミーティングに出た人に聞いてみればよいのだ。うまく行けばまともなサマリー情報が短時間で得られる。その人から得た情報の恩はまたどこかで返せばよい。

仕事を頼まれたときに「それは重要でないからやりません」と答えるのはさすがに難しい。だが言えるのならはっきり言った方がよい。その人が次に仕事を振るときに、少しは考えるようになることを期待して。

プロジェクト内で信頼され、自分で仕事を見つけて自由に動けるようになった時、自分でタスクの優先順位がつけられるようになる。前にも述べたが、優先順位の策定とは実は重要でないタスクを切り捨てる意思決定である。ここから自らの不安との戦いが始まる。本当にこのタスクを切り捨ててよいのか。将来後悔することはないのか。本当に迷ったとき、可能ならそのタスクを先送りにするのがよい。数日後あるいは数週間後には全くタスクの重要度が変わることがよくあるからだ。それ以外についてはそのタスクをしなかったとしてどうなるか、を考えその結果が許容できるのであれば、思い切って切り捨てるべきである。

タスクを切り捨てる準備として、自分の時間の使い方を一度調査してみたらよい。いついつか何時何分～何分何をしたか。これを朝から5分単位で記録して行くのである。実際に仕事や大事な調査をしている時間がいかに短いかが分かる。割り込み電話、雑談、重要でない議論、ぼーっとしてしまう時間がいかに多いか。時間が足りないのではない。単にムダ使いしているのである。まず時間がムダに使われている現状を認識する。それから自分が日々何をしているか把握し、切り捨てることができるタスクに当たりをつける。そして「仕事モドキ」となる可能性の高いタスクを切り捨てる。不要なタスクを切り捨てることは、時間を有効に使うもっとも効果的な手段なのである。

リスクと不安の哲学的考察（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

未来にはあらゆる可能性がある。そして未来の可能性は未だ現実化していないものである。可能性は現実化されていないが故に可能性であり、未来は未だ来ぬが故に未来だからである。

また、人間は常に不安と共にある（時には潜在的ではあるにせよ）。不安を持たない人間はいない。そして、未来の可能性の中には「意識にとって好ましくないもの」もある。不安とこのような好ましくない未来の可能性が結合する。するとそれはリスクと呼ばれることになる。不安の無い人はリスクに気が付かない。気が付く人がいなければ、リスクは顕わにならない。

リスクとは、不安と共に生きる人間が措定するものである。つまり不安の外出しがリスクなのである。その意味ではリスクもまたクオリアに過ぎない。それ自体で存在するものではない。これはリスクの定義からも明らかである。つまりリスクは可能性であり、可能性は現存しない。

リスクが課題として扱えるレベルまで具体化されたとする。それは常に「もしこうなったら、どうするか」という問いに帰着する。要するにリスク、リスクと騒いだところで具体化すれば大したことではない。単なる好ましくない可能性が、「リスク」というクオリアとして現れている、それだけの話である。

ビジネスの世界では、リスクに対して事前にアクションを取ることが求められる。自分がいつ死ぬかも分かっていないのだが、リスクに対しては「ああすればこうなる」式の対応が求められるのである。原因は常に時系列から見ると後に来る、と先に述べた。つまり常に結果が先に起こり、原因は後付けなのだ。しかし意識はそうは思わない。事象の時系列を逆転し、原因を先に持ってきたがる。そして事象を解釈し直し、あの時ああしなければこんなことにはならなかった、と嘆く。意識は未だ発生しないところリスクに対してすらも、その原因への対応を求める。今こういうリスクが分かっているのだから、事前に対応を取らなければならない、意識はそう主張する。もっともである。しかし問題はトラブルがすでに起こってしまった事象であるのに対し、リスクはまだ発生していない、という点にある。だからはっきり言って語の厳密な定義から言ってしまえば、事前に正確にそのリスクを潰す対応を取ることはできないのである。だってリスクの対象は未だ存在していないのだから。要するに「リスクに対応する」とは、リスクが発生したとしてどうするか、という事後的な対応を検討することに他ならない。

トラブルの種が存在するのは「今」である。だがリスクはトラブルとは違う。「不安」と関係するだけ、もう少し形而上的なものである。「想定通り行かない可能性がある」。これがリスクの本質である。だからリスクは「今」よりもむしろ「未来」にある。具体的な感性で把握できるものではなく、不安から生じた抽象的な概念である。だから具体的に対応しにくい。具体的に対応しにくいから作業スコープと完了基準が明確にならない。だから例えば「リスクを潰す」旨のタスクを定義したとすると、いつまでたってもクローズできないことになる。何をすればよいのか分からないタスクになる。

だが事後的な対応にならざるを得ないとは言え、リスクをある程度まで定義できたのならば手をこまねいている訳には行かない。人として何らかのアクションを取らなければならない。みすみす犠牲を出す訳には行かない。だが、どこまで対応するかはあらかじめ考えておく必要がある。リスクの対象が具体的でない以上、それへの対応もきりがない可能性があるからである。いつまでたってもリスクはなくならない。それはいつまでたっても不安がなくならないのと同じである。どこかで対応を完了させなければならない。だから費用対効果を意識してリスクに対応する必要がある。

恐るべき敵と思われた存在が、後になって実は何でもないと判明することがある。風車と死闘を繰り広げたドン・キホーテのように。ただ少なくとも、プロジェクトにはドゥルネシア姫は存在しない。従って我々はドン・キホーテより冷静に計算できるはずである。つまり風車と戦う必要はないのだ。だからリスクには冷静に対応すべきであろう。

手段と目的が逆転する（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

人が仕事するとき、常に手段と目的が逆転する危険がある。本来の目的が失われ、手段や組織の維持が目的となる。この例を上げるとすれば、わが国の官僚組織だけで十分であろう。

プロジェクトでも官僚組織ほどの規模ではないにせよ、同様に手段と目的の逆転が発生する。例えば以下のようなものがある。

－ツールとその目的
　何のためにツール（プロジェクト管理ツール、開発支援ツール）を導入したのか。
－障害対応とその目的
　何のために障害解析をしているのか。
－会議とその目的
　何のための会議か。
－成果物とその目的
　何のために作っているのか。

手段こそが目的となる。なぜそういうことになるのか。理由はいくつかある。忙しすぎて当初の目的を忘れてしまう。あるいは手段をもてあそんでいると仕事をしている気になり、不安がまぎれる。あるいは手段に集中していると楽しい。などなど。

手段と目的が入れ替わることで優先順位を見失う。本来リソースを投入すべき作業が後回しとなり手段に拘泥することになる。手段があったとして「何のために」が少なくとも２回問われなければならない。そしてそれをしなかったとしてどうなるのか、とさらに問わなければならない。

例にそって考えてみよう。プロジェクトの雰囲気がよくない。状況把握のためにメンバーの士気を調査しようとする。調査するためにヒアリングシートを作成、配布し、記入して貰う。そのヒアリングシートを元に面談をする。

以上、プロジェクトの現場をご存知ないマネジメントが思いつきそうなストーリーを例に見てみよう。「プロジェクトの状況を把握する」ためだけに、これだけのタスクが発生してしまう。コスト対効果を考慮して諦めるか別の方法を検討する方が正しいように思われる。少なくとも筆者ならそうする。しかし、プロジェクト運用を指南した書籍には副作用や体力を一切考慮せず山ほど体力と時間をかけてプロジェクトの状況を把握させようとするものがある。ここではマネジメント層がこのストーリーを採用し、実行に移したとしよう。このタスク群の中に多くのトラップがあることに気が付いて頂きたい。

1. ヒアリングシートの作成が目的となってしまう
ヒアリングシートの作成に無駄な体力を掛けてしまう。最初の目的からすれば面談の取っ掛かりになればよいはずである。それは最低限の基準かもしれないが、最低限の基準だからいけない、ということはない。コストを掛けても掛けなくても効果がさほど変わらないのであれば、コストを掛けない方がよい。その意思決定が出来るかどうか。

2. ヒアリングシートの記入が目的となってしまう
今度はヒアリングシートを展開された側の話である。本来の目的は面談のネタだったはずのヒアリングシートであるが、記入が依頼されたが故にヒアリングシート用ストーリーの作成に体力が掛けられてしまう。

3. ヒアリングシート（面談結果）の分析が目的となってしまう
なぜ山に登るのか。そこに山があるからだ。なぜ分析するのか。そこ数字があるからだ。ある種の人間は、数字を見るとどうしてもグラフを書いたり分析したい衝動に駆られてしまうらしい。だがデータが存在するからといってそれを分析してもよい、ということにはならない。

4. 面談プロセス自体が目的となってしまう
プロジェクトの状況を把握する当初の目的が忘れられ、面談自体が問題となる。「あーよい面談だった」で終わってしまい、付け刃的なアクションプランが取られる。当然効果はない。一時的に親交が深まったかもしれない。でも、ただそれだけ。最初に目的を措定した段階で、次のアクションまでの射程を持っておくべきであった。

手段と目的の逆転は上記に限らない。全ての作業／成果物が逆転し得る。

コスト対効果をちゃんと考慮すればよいなどという単純な話ではない。いちいち細かい意思決定にコスト対効果を考慮する時間などない。そしてタスクというものは一度走ってしまうと、止められなくなってしまう。細かいタスク一つ一つについて、手段と目的を意識するべきである。

例えば上司やマネジメントから作業指示を受けたとしても、必ず最初に目的を明確にしてから指示を受けた方がよい。特に彼らは思いつきで「それっぽい」だけのタスクを思いつきがちだからである。「それは何のためですか？」「とすれば最終的にはこうなることを目的としているわけですね？」「目的からすると成果物はこういうトーンでまとめる方向ですね？」。そしてたたき台として８割型の完成度のものをレビューしてもらう。受けた指摘を修正し、９割５分の出来まで完成、タスク終了となる。上司（マネジメント）の指示だからといって絶対視する必要はない。

なんというトラップ Tomcatでの文字化け（続報）

GETパラメータに日本語を渡すとTOMCATで化ける件、 別の環境では以前の対応ではダメでした。

別の環境と言っても違いはマーナーバージョン位なのですが・・・
上手く行った環境 tomcat 6.0.16
ダメだった環境 tomcat 6.0.18
JREのマイナーバージョンも違うと思いますが、さすがにそこは関係ないでしょう。

しょうがないので回避しようとしていろいろやってみた結果、以下のコーディングで文字化けを復元することができました。
JSPのエンコーディングはWindows31-Jです。

String nihongo = request.getParameter("name");
nihongo = new String(nihongo.getBytes("iso8859_1"), "Windows31-J");

つまり、、、何という先祖がえり。

＃ request.getCharacterEncoding() したら"Windows31-J"でした。わけ分からん。

本末転倒（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

プロジェクトではさまざまな本末転倒が起こる。例えば十分条件の必要条件化。確かにそこまで出来れば素晴らしい。十分である。だがやる必要があるのか。他にやるべきことがあるのではないか。そういった要件に意識がとらわれてしまう。

例えばウィルスに感染した場合にどのような対応を取るか。確かに重要だ。ウィルスの種類や拡散状況によっては信用問題となる。すなわち経営レベルのリスクだ。だが、それを例えば設計フェーズで議論するか。設計が十分煮詰まっているのならまだよい。だがまだなすべきことがある段階で「ウィルスが発生したら」という仮定の元に議論するのはほどんど無駄である。

「むやみに仮定を増やしてはならない」というのはオッカムの格言である。一般には自然科学について用いられるが、議論する時にもこれは有効である。一般にはシステム開発の前提で二重障害には対応しないと謳われる。議論や会議にもこの原則は当てはめるべきである。全くありそうなケースにもう一つ二つ仮定を積み重ねるのは構わないが、可能性の低いケースにさらに仮定を置くのは無駄である。また障害や不安を誘導する方に仮定を置く人がいる。「ウィルスがまさにこのシステムで検知されたとしたら」という仮定も、今このフェーズで議論すべきなのかどうか。冷静に優先順位をつけるべきであろう。

あるいは「あるべき論」にこだわり過ぎて、却って不自然な運用やルールを定めてしまう。挙句のあてには「あるべき」の目的（何のための「あるべき」か）が忘れられ、単に厄介な運用とルールのみが残る。具体例を上げると「システムテストは全て自動化されるべきだ」という主張。正しい。もっともである。確かにオンライン打鍵以外は全て自動化出来るシステムもある。しかしそうは行かないシステムも存在する。制約や現状をちゃんと評価せず、あるべき論が一人歩きする。その結果システムテストのためだけに自動運用を作りこむことになる。まさに本末転倒である。そもそも本番を想定した自動運用でのテストがシステムテストの目的である。システムテストのためだけに自動運用を作りこんでしまえばシステムテスト本来の目的からは逸れてしまうことになる。むやみに細部や手段にこだわり目的を忘れてしまうと、容易に本末転倒が起こりうる。いつでもどこにでも存在し得る落とし穴である。

トラブルを感じて、アクションを取る（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

マネジメント層にも当然現場感覚がある(あるいは少なくともあった)はずである。しかし、出世し、金を計算し、自社のために働くことによって、その感覚が失われてくる。またわけの分からない技術や方法論、ツールが山ほど出てくる。現場で働くエンジニアやプログラマはまっとうなコミュニケーションができない。偉くになるにつれて、プロジェクトの現場から意識が離れるのも当然である。

だからこそ現場メンバーの現場感覚が重要である。もはやマネジメント層は頼りにならない。マネジメントはトラブルが起こった後でしか対応ができないのだから。

前にも少し述べたがトラブルの気配はどこにでもある。問題はどの気配に、どう対応アクションを取るか、である。気配は気配に過ぎない。トラブルそのものではない。自分にとっては重要に見えるかも知れないが、他の人からするとまったく重要ではないように見えることは、ざらである。時々「これほど明々白々なトラブルの予兆に、なぜ他の人は気が付かないのか！」と絶望することもある。そしてその直感が完全に誤っている（回りの人が正しい）こともまたしょっちゅうである。

要するにトラブルの気配を潰すことは、あがくことであり、騒ぐことであり、周りを（特に経験が豊富で度胸があり頭の切れる人間を）巻き込むことである。

「確かにトラブルの気配を発見した」という主張に対しては、反論も必要である。仮にその発見が誤りだった場合、そこに投入したリソースがムダになるからである。トラブルが起こってから慌てふためくより今できるだけコストを掛けておく方がマシ、という主張は危険である。単に不安に駆られただけ、というケースは案外多いものである。手当たり次第に思いついたものが、不安の対象となりかねない。本当にそれはトラブルの予兆なのか、複数人でチェックする必要があるし、もし予兆でないとしたら、そこからはいかなるタスクも発生させてはならない。

トラブルの予兆を発見するためには問題意識が必要である。問題意識の裏には不安が潜んでいる。不安とは常に将来への不安である。その不安が発端となってトラブルの萌芽を潰すことができる。従ってプロジェクトをうまく運ぶには不安が必要である。だが不安は諸刃の剣でもある。不安によって盲目になることがある。具体的には不安に駆られて我を忘れ誤った意思決定をしてしまう。あるいは冷静な優先順位付けができなくなる。だから不安はコントロールされなければならない。不安はコントロール可能なのである。

不安には実に底がない。人間は死ぬまで不安から解放されることはない。その度合いをコントロールすることができるだけである。その意味では不安は苦痛や絶望と似ている。いずれも「どん底」というものがない。いくらでも下に掘ることができる。そうとは知らずに自分の足元を掘り下げてて行くのが人間である。自ら不安を増幅し、しかも自分が増幅しているとは気が付かない。不安をコントロールするのはある意味では容易である。単に足元を掘ることを中止し、その穴から出ればよい。具体的には不安を具体化することである。それから不確定情報の確度を上げること。

漠然とした不安は何も生まない。せいぜい無駄なタスクを生じさせるのが関の山だ。何が不安なのか。まずはできるだけ具体化しなければならない。具体化できない不安は妄想でしかないと割り切る勇気も必要だ。アプリケーションの障害が不安である。これではアクションが取れない。具体的にどんな障害か。先だって発表されたミドルウェアのセキュリティ脆弱性に由来する、顧客情報の漏洩が不安である。OK。これでアクションが取れる。まずは脆弱性の詳細を押さえる。どのような条件でどのような影響があるか。プログラムによる作り込みで対応するためにはどうすればよいか。今の実装状況をチェックするためのチェックシートを作り、チェックする。必要があれば対応する。対応後のセキュリティについてレビューし、制約や注意事項があればチェックする。以上。最初のきっかけ以外不安に出る幕はない。

トラブルを事前に潰そうとする試みは、常に「空騒ぎ」に陥る可能性がある。しかし不安から課題が明らかになったのであれば、空騒ぎを恐れてはいけない。トラブルが事前に潰せれば、結局は体力の節約になるからである。