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

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

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

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

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

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

１．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の機能が全然見えません
・ドキュメント貧弱すぎ。リファレンスマニュアルだけじゃ作れっこない

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

少し脱線しました。

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

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

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