Struts2を試す（４）

引き続きStruts 2 + Spring 2 + JPA + AJAXを試しました。

まずは感想から。「詰め込みぎ」チュートリアルの一例です。せめてHibernateとの連携だけにして欲しかった。HibernateとSpringを触ったことがない人には何をやってるか分からないと思います。
Strutsのパワーを知るより、他のコンポーネントとどうやって連携させるかという点に主眼を置いたチュートリアルです。とりあえず上手く連携させることができるよ、と。

以下、作業メモです。

このチュートリアルはStruts 2.0をターゲットに書かれており、Struts 2.1で動かすためには修正が必要です。以下で出てくるエラーと併せて記載します。

いきなり"Dependencies"にあるjarで過不足ありそうな感じですが気にせず進めましょう。Spring、Hibernateのライブラリをダウンロード、名前が一致しているライブラリを適当に/WEB-INF/libに突っ込みます（後でjarライブラリのリストを載せておきます）。

ガイド通りコーディングしてTomcatで実行したところ早速以下のエラーが出ました。

アプリ起動エラー（ClassNotFound系）

Spring周りで以下のjarファイルが足りなかったようです。ClassNotFoundとなったクラスから地道にjarを探しました（そんなに大変でもなかったですが）。
log4j-1.2.15.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
以上をWEB-INF/libに入れ込めばとりあえずwarは起動します。

index.jspにアクセスすると以下のエラー群がでます。

致命的: サーブレット jsp のServlet.service()が例外を投げました
org.apache.jasper.JasperException: /index.jsp(7,0) TLDによると、タグ head の属性 debug は無効です

debug属性をはずして対応しました。

致命的: error when rendering
java.io.FileNotFoundException: Template /template/ajax/head.ftl not found.

FreeMarkerのtemplateを使うためstruts2-dojo-plugin-2.1.2.jarが必要です（地道にjarを展開して探しました）。WEB-INF/libに上記ライブラリを突っ込んで対応。

FreeMarker template error!
Expression parameters.parseContent is undefined on line 45, column 28 in template/ajax/head.ftl.
The problematic instruction:
----------
==> ${parameters.parseContent?string} [on line 45, column 26 in template/ajax/head.ftl]
----------

Troubleshooting guide migrating from Struts 2.0.x to 2.1.x にあるとおり theme="ajax" はobsoleteとのこと。移行ルールは以下の通りです。
（以下の情報は上記ページからそのまま持って来てます）

追加：<%@ taglib prefix="sx" uri="/struts-dojo-tags" %>

旧：<s:head theme="ajax"/>
新：<sx:head parseContent="true"/>

旧：<s:div id="jobStatus" theme="ajax" href="%{jobStatus}" updateFreq="5000" indicator="indicator">
</s:div>
新：<sx:div id="jobStatus" href="%{#jobStatus}" updateFreq="5000" autoStart="true" indicator="indicator">
</sx:div>
（"s"を"sx"に変更してtheme="ajax"を削除する）

これでindex.jsp画面からのPersonalデータCRUDが出来る筈です。

以下が最終的にWEB-INF/libに格納されていたライブラリ群です。

antlr-2.7.6.jar
asm-attrs.jar
asm.jar
cglib.jar
commons-collections-3.1.jar
commons-fileupload-1.2.1.jar
commons-logging-api-1.1.jar
dom4j-1.6.1.jar
ejb3-persistence.jar
freemarker-2.3.12.jar
hibernate-annotations.jar
hibernate-commons-annotations.jar
hibernate-entitymanager.jar
hibernate3.jar
javassist.jar
jta.jar
log4j-1.2.15.jar
mysql-connector-java-5.1.6-bin.jar
ognl-2.6.11.jar
slf4j-api-1.5.0.jar
slf4j-log4j12-1.5.0.jar
spring.jar
struts2-core-2.1.2.jar
struts2-dojo-plugin-2.1.2.jar
struts2-spring-plugin-2.1.2.jar
xwork-2.1.1.jar

以上。
.

MVCは作っているうちに破綻する（２／２）

次に View という位置付けについて考えてみます。実はこのViewが曲者なのです。

前回の投稿で、ModelやControllerという場所にも表示系ロジックを配置しました。私だって本当はこんなことやりたくない。表示はJSPに任せて、ModelとControllerはロジックに専念させたい。でもそうは行かないのです。

単純な例を上げてみましょう。例えば「10月4日（土曜日）」というデータがあります。このデータを画面に表示したい。JSPには例えば<c:out value="model.date"/>などと書いてある。とすれば、modelビーンのdateフィールドに"10月4日（土曜日）"をセットしてやればよい。JSPは入れ物を準備し、モデルに値をセットしているわけで、これはMVCモデルが美しく機能したと言えるでしょう。

しかし、ここで顧客が一言。「土曜日は背景色を青にしたいな。日曜と祝日は赤だ」。ロジック的には容易な変更です。従って断れない。この要件に対して以下の２つの実装パターンが考えられます。

１．JSP（以下はJSTLの例）で表示ロジックを組み立てる（以下がイメージですが多分この通りに書いても動きません）

<c:choose>
<c:when test="${model.date eq 土曜日}">
   <c:out value='<span style="background-color: blue">'/> ... </span>
</c:when>
<c:when test="${model.date eq 日曜日}">
   <c:out value='<span style="background-color: red">'/> ... </span>
</c:when>
...（祝日リストはどうするの？当日の表示は？？？面倒くさ！）
</c:choose>

２．Beanの中に表示ロジック込みでデータを入れ込む

Calendar cal = Calendar.getInstance();
cal.setDate(date);
int tmp = cal.get(Calendar.DAY_OF_WEEK);
StringBuffer sb = new StringBuffer();
if (tmp == SATURDAY) 
  sb.append("<span style="background-color: blue">");
  sb.append(date);
  sb.append("</span>");
... まあありがち。

１の案は恐らく「Viewに表示を任せるという方針に沿っている」というメリットしかありません。このようにずらずら書かれたJSPをメンテする人がかわいそうです。

２はいろんな意味で美しくはありませんが、少なくともメンテナンスはしやすい。UTもできます。

好みはあるでしょうが、私なら２の案を取ります。Viewの役割に固執するのは意味がないと考えるからです。

以上を センセーショナルにまとめると View という考え方自体現実的には破綻しているともいえます。

なぜか。

それはデータの表示方法はデータの意味と密接に関連しており、それはロジックによって制御されるべきだからです。View として独立させてしいまうのはそもそもムリがある。

もちろん単純なロジックであればJSPなりJSTLなり使ってシンプルに表示できるのが望ましい。メンテも容易だし、結果として美しいコードに仕上がります。しかしそんな容易な表示要件は残念ながら少ないでしょう。

最近MVC2という考え方も出てきていて、これはJSP＋Ajaxなどとして表示を制御するロジックをViewに持つ考えのようですが、これも完全な解決策にはなりません。恐らくはView用に最適化されたAjaxフレームワークができるまで・・・

結論として何が言いたいか。あまりMVCだとかMVC2だとかにこだわらず、センスと経験に任せてデザインするのがよい、そういうことです。

（以上）
.

MVCは作っているうちに破綻する（１／２）

MVCとはアプリケーションの内部のコンポーネントを、Model（データ） View（表示） Controller（ロジック）という３つのレイヤーに分けて考える思想です。例えばJava Webアプリケーションでは Model=JavaBean、View=JSP、Controller=Servlet などと言われたりします。

まあWebアプリを作ったことのある人であれば「こんなに簡単に分けられねーよ」ということを身をもって知っていると思います。実際に作ってみると
　▽　Model＝JavaBean + 業務ロジック
　▽　View＝JSP＋表示ロジック
　▽　Controller＝制御＋業務ロジック
と何となく曖昧に、ロジックとデータと表示が渾然一体になってしまうものです。
もちろん、例えば Actionクラスに一切業務ロジックを持ち込まず「これはコントローラだ」と気合いで分けてしまうことは可能です。しかし、それは単にロジックをファイルに分割したに過ぎない。実際のところアプリケーションは各所にロジックやデータを持つものであり、MVCという区分はあくまで便宜的なものなのです。

つまり、MVCは単なる方針として最初にざっくりと区別しておくだけに留め、それよりもロジックやJavaBeanをキレイに分けてデザインすることに注力した方が結果的にはよい設計になる、ということです。ざっくりと言ってもMとVとCの分類だけではいまいちなので、例えば

▽ Model1（データに近い系）
⇒ DB（DAO）
⇒ JavaBean (※1)
⇒ データ処理系汎用的ユーティリティ（型変換、エンコード／デコード処理など）
(※1) DAOとJavaBeanは分けた方がいいです。

▽ Model2（業務に近い系）
⇒ 業務ロジック
⇒ 業務系汎用ユーティリティ
⇒ 表示制御ロジック ※2

▽ Controller1（フレームワーク系）
⇒ 普通はフレームワークが準備してますね。StrutsのActionクラスとかSpringのControllerとか

▽ Controller2（業務に近い系）
⇒ 業務ロジックに近いController（Validationとか、ロジックによる画面の振り分けとか）
⇒ 表示制御ロジック ※2
(※2)は後述

という感じで区別するのが私の好みです。この分類でパッケージを分けてしまってもよいでしょう。
私見ではデザインの美しさは、JunitによるUTの容易さによって評価され得ると思います。つまりメソッド単位あるいはインターフェース単位で完全に独立しているのが望ましい。あまりMVCにこだわってもしょうがない。どうせMVCという枠組みは曖昧かつゴタゴタになるんだから。

（続く）
.

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

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

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

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