【この「プロジェクトの人間学」投稿シリーズは（後略） 初回投稿：はじめに（プロジェクトの人間学）】
何のためのプロジェクトか。良いシステムを作るためである。では良いシステムを作るために、何をなすべきか。良い問いである。そしてこの時重要なのは、何をなすべきでないのか、を意識することである。例えば重箱の隅を突付いてばかりでは絶対に良いシステムはできない。つまり良いシステムを作るためには、やるべきでない仕事をやらないことが重要である。無駄な作業を効率的に行うことほど無駄なことはないとドラッカーがどこかで言っていた。また80対20の法則というものがある。この法則を適用すればプロジェクトで実施する作業の80%は無駄である。残りの20%が品質の80%を決定する。実感にも合う。何でこんな無駄なことばかりさせやがる。プロジェクトでこう思わないエンジニアはいない。
とすれば現実的に有効な問いは「何をなすべきでないか」である。この問いに答えるのは実は難しい。何故ならこの問いに答えるためには作業に対する負の価値判断（つまり否定）が必要だからである。なぜ作業の否定が難しいか。君が今やっている（やろうとしている、あるいはやろうと思いついた）仕事はまったく無意味で無駄だから今すぐ止めて他のことをした方がよい。ああ、まったくだ。そう思えるだろうか。大きなお世話だ、と思うのではないだろうか。あるいは人によっては、それをやりとおすことに意味がある、とムリヤリ意味を見つけてしまうかもしれない。
仕事を切り捨てるのは感情的にはなかなか受け入れがたいものなのだ。その仕事は無駄だ。そうかもしれない。でもやってみなければ分からないじゃないか。それにもしこの仕事をやらないとして、大きな問題が発生したら、どうしてくれるのだ。そう言ってまじめなワーカは徹夜でその仕事を続けるものなのである。
何か問題が発生したら、その責任は俺が取る。だからその仕事は*するな*。そう言えるマネージャがいるだろうか？マネージャとは脳内タスクテーブルに載ってしまったタスクは、たとえそのタスクがある時点から無意味になったとしても、プロジェクトが完了するまで執拗にトラッキングするものである。途中で「やらなくてもよい」と言うマネージャはほとんどマネージャではない。宇宙人である。
しかし実際のところ、無駄ではない作業がどれほどあるのだろうか。会議、一時的成果物（トラブル報告書、技術説明報告書、パフォーマンス分析、障害解析うんぬん）。後に振り返ってみればすべてがそれなりに意味を持っていたように思える。あの時あの作業をしていて良かった安心だ、とすら思えてしまう。ただし、われわれ人間は仕事に意味を求めている、という事実を考慮に入れる必要がある。仕事に意味を感じられない人間は転職するか淘汰されてゆく。だから我々の意識には、意味を見つけようとする強い重み付けが存在するのだ。それを忘れてはならない。
では、無駄な作業とはどのようなものか。それは「やらなくてもよい作業」である。そんなの、当たり前じゃないか。ではやらなくてもよい作業を、あなたはしていないのか。ピントの外れた長電話をしていないか。どちらを選択しても結果に大した違いが出ない意思決定について、30分以上議論を続けていないか。表向き、形式的に必要だが、その内容はまったくどうでも良い報告書の作成。低レベルの作業でも無駄な作業はいくらでもある。ホストの経験しかないマネージャがソースコードのステップ数を出せと言ってくる。Javaの行数をどこまで精緻に数えるのか。あなたにまじめに*数えない*ことができるか。
プロジェクトで働く人間は（特にある種の人間は）実にまじめでやや近視眼である。腰を据えて大局や本質をじっくり見る前に、とりあえず目先の仕事に全力で取り掛かってしまう。不安(仕事がなくなる不安＝自分が必要とされなくなる不安、プロジェクトの先行きに対する不安)に駆られるという理由が大きいのではないかと思う。だがこれでは仕事が趣味という人間以外は淘汰されてしまう。もう少しうまい進めかたはないのか。ハードワークに疲れ果てる前に考えてみることはないのか。
2008年8月25日月曜日
排中律を意識的に活用する（プロジェクトの人間学）
【この「プロジェクトの人間学」投稿シリーズは（後略） 初回投稿：はじめに（プロジェクトの人間学）】
排中律とは「ＡはＢか非Ｂかのいずれかである」という式であらわされる古典論理学の法則である。何だ当たり前じゃないか。それがそうでもないのだ。排中律をどう適用するかによってプロジェクトにおける判断が異なってくるのだ。
常識的な世界で排中律が成立するかどうか見てみよう。「ＡはＢか非Ｂかのいずれかである」。Ａにりんご、Ｂにみかんを代入してみよう。「りんごはみかんかみかんでないか、いずれかである」。正しい。りんごはみかんではない。では次はどうか。「脳死は死であるか、死でないかいずれかである」。ほれ。難しくなった。答えは「なんとも言えない」あるいはシニカルに言えば「政治が決める」であろうか。以前はやかましかったこの議論であるが、現在はどのようになっているのだろう。では次はどうだろう。「アプリケーション障害は将来起こるか起こらないかのいずれかである」。どうも起こりそうな気はする。でも起こって欲しくはないし、アプリケーションの完成度からすると起こらなそうな気もする。ようするに「分からない」のである。排中律はこのように「分からない」状態を排して、二つに割り切ってしまう。ある意味で非常に乱暴な論理なのである。
実は排中律は現実的な論理ではない。「どっちなんだ」。「わかりません」。それが正しい。だが、そこを逆手にとって利用することが可能である。すなわち「現在得られている情報では、ＡはＢか非Ｂのいずれかであり、定義より非Ｂなのです」と言い切ってしまうことができるのだ。これで何がうれしいか。「違う」ことが説明できるのがうれしいのである。なぜわざわざ「違う」ことを示さねばならないか。ある障害が起きたとする。「またですか」と顧客がうんざりした声で言う。これって前に発生した障害と「同じ」じゃないですか。なぜまた「同じ」ような障害を繰り返しているのですか。いえ。前に発生した障害とは違います。何故なら、以前の障害はこれこれこういう前提の元で発生したものです。今回は前提が全く違います。故に別の障害なのです。ある程度抽象度のレベルを上げてしまうと本来「同じ」とすべきでないものまで「同じ」に見えてしまう。それは意識のもっているバイアスである。細かい現実を正確に把握しようとする時に「全てが違う」と世界観を構成する際の邪魔になる。だから「違う」ことを排中律を用いて明示することが重要である。
排中律を意識的に適用することで、物事をきっぱりと割り切ることができる。本来事象はきれいに二つに分かれるものではない。だが条件と前提をはっきりさせればスパっと分けることができる。排中律は、あいまいさを許せないというマネジメント層・顧客層を上手く説得するテクニックなのである。
排中律とは「ＡはＢか非Ｂかのいずれかである」という式であらわされる古典論理学の法則である。何だ当たり前じゃないか。それがそうでもないのだ。排中律をどう適用するかによってプロジェクトにおける判断が異なってくるのだ。
常識的な世界で排中律が成立するかどうか見てみよう。「ＡはＢか非Ｂかのいずれかである」。Ａにりんご、Ｂにみかんを代入してみよう。「りんごはみかんかみかんでないか、いずれかである」。正しい。りんごはみかんではない。では次はどうか。「脳死は死であるか、死でないかいずれかである」。ほれ。難しくなった。答えは「なんとも言えない」あるいはシニカルに言えば「政治が決める」であろうか。以前はやかましかったこの議論であるが、現在はどのようになっているのだろう。では次はどうだろう。「アプリケーション障害は将来起こるか起こらないかのいずれかである」。どうも起こりそうな気はする。でも起こって欲しくはないし、アプリケーションの完成度からすると起こらなそうな気もする。ようするに「分からない」のである。排中律はこのように「分からない」状態を排して、二つに割り切ってしまう。ある意味で非常に乱暴な論理なのである。
実は排中律は現実的な論理ではない。「どっちなんだ」。「わかりません」。それが正しい。だが、そこを逆手にとって利用することが可能である。すなわち「現在得られている情報では、ＡはＢか非Ｂのいずれかであり、定義より非Ｂなのです」と言い切ってしまうことができるのだ。これで何がうれしいか。「違う」ことが説明できるのがうれしいのである。なぜわざわざ「違う」ことを示さねばならないか。ある障害が起きたとする。「またですか」と顧客がうんざりした声で言う。これって前に発生した障害と「同じ」じゃないですか。なぜまた「同じ」ような障害を繰り返しているのですか。いえ。前に発生した障害とは違います。何故なら、以前の障害はこれこれこういう前提の元で発生したものです。今回は前提が全く違います。故に別の障害なのです。ある程度抽象度のレベルを上げてしまうと本来「同じ」とすべきでないものまで「同じ」に見えてしまう。それは意識のもっているバイアスである。細かい現実を正確に把握しようとする時に「全てが違う」と世界観を構成する際の邪魔になる。だから「違う」ことを排中律を用いて明示することが重要である。
排中律を意識的に適用することで、物事をきっぱりと割り切ることができる。本来事象はきれいに二つに分かれるものではない。だが条件と前提をはっきりさせればスパっと分けることができる。排中律は、あいまいさを許せないというマネジメント層・顧客層を上手く説得するテクニックなのである。
2008年8月23日土曜日
メールのデザインについて考えてみた
たまたまJavaMailを実装してみる機会があり、メールのデザインについていろいろ考えさせられました。デザインといってもメールの仕様（設計といってもいいですね）についてです。
少し突っ込んでメールの仕様を見てみると分かりますが、インターネットメールのデザインは非常に興味深いものがあります。
その特徴をざっくり一言で表せば「歴史的にややこしい。数学的には美しい。実用的にはいまいち」というところに落ち着くでしょうか。
どのあたりが歴史的にややこしいのか。
あまり突っ込んで調べてはいませんが、BASE64とかMIMEのあたりがややこしいですね。メールは基本的に7bitの文字しか送れなかったとか（これは技術的な制約だったのかそれとも初期の誤った意思決定によるものなのか・・・）、その辺に由来すると思われます。
どのあたりが数学的に美しいのか。
メールは複数の部分（MULTI-PART）を持つものとして定められています。メッセージの本文自体がPARTであり、そのPARTが別のPARTを含むことができます。PARTはさらに別のPARTを含むこともできます。
いわばファイル－ディレクトリ階層に似た再帰的な階層を取ることができるわけです。そしてプログラムで処理する場合も、再帰的アルゴリズムでメールメッセージを処理することができます。（再帰的アルゴリズムイメージ）
例）メールにファイルを添付したり、別のメッセージを添付したり（そして添付されたメッセージが添付ファイル／添付メールを持つことも可能）
実用的にいまいちなのはなぜか。
メールの仕様によればいくらでも添付ファイル／添付メール／添付ファイル付きメールの添付ができてしまいます。
誰が100個の添付ファイルを必要とするでしょうか。誰が100階層の添付ファイル階層を必要とするでしょうか。
再帰的に処理できるのは確かに美しい。しかし、日本語の文字化けの問題やMIME指定のわずらわしさ、それにブラウザやメーラによる（勝手な）解釈を考慮に入れるとはっきり言ってカオス状態です。
確かにデザインは美しい。しかしその結果メールシステムの実装をややこしくしているとすれば、そのデザインは「美しくない」と言わざるを得ないのです。
ではなぜこのようなことになったのか。予期できない偶然によってか。結果的にややこしいと（日本の一開発者から）言われるようになったメールのデザインが、優れたデザインだと呼ばれる可能性はあったのか。
何だかわけの分からない問いになってしまいました。
私の思うところ、メールの仕様にはひとつ問題があります。それは「割り切らなかった」ということです。
例えば「メール本文はUNICODEテキストとして送ること。添付できるファイルは1個だけ。」という仕様だったとして、誰が困るでしょうか？
#まあUNICODEは極端ですけどね。欧米の科学者が7bitASCIIしか頭にないのは残念ながらしょうがないですしょう。あくまでおとぎ話です。
おそらく誰も困りません。それにメールの実装が簡単になり、誰でもメールソフトが作れるようになります。
#それがいいことかどうかも微妙ですけどね。
まあ、結論として言いたいのは、よいデザイン（＝結果的に成功するデザイン）というのは必ずしも数学的に美しいかどうかそれだけではなく、どう割り切ったか、どこを切り捨てたか、という観点も重要になるのだなあ、とそういうことなのです。
まさにセンスですね。
少し突っ込んでメールの仕様を見てみると分かりますが、インターネットメールのデザインは非常に興味深いものがあります。
その特徴をざっくり一言で表せば「歴史的にややこしい。数学的には美しい。実用的にはいまいち」というところに落ち着くでしょうか。
どのあたりが歴史的にややこしいのか。
あまり突っ込んで調べてはいませんが、BASE64とかMIMEのあたりがややこしいですね。メールは基本的に7bitの文字しか送れなかったとか（これは技術的な制約だったのかそれとも初期の誤った意思決定によるものなのか・・・）、その辺に由来すると思われます。
どのあたりが数学的に美しいのか。
メールは複数の部分（MULTI-PART）を持つものとして定められています。メッセージの本文自体がPARTであり、そのPARTが別のPARTを含むことができます。PARTはさらに別のPARTを含むこともできます。
いわばファイル－ディレクトリ階層に似た再帰的な階層を取ることができるわけです。そしてプログラムで処理する場合も、再帰的アルゴリズムでメールメッセージを処理することができます。（再帰的アルゴリズムイメージ）
parseMessage(Message) {
if (Message.isMimeType("text/plain")) {
print(Message.getText());
} else {
parseMessage(Message.getContent());
}
}
例）メールにファイルを添付したり、別のメッセージを添付したり（そして添付されたメッセージが添付ファイル／添付メールを持つことも可能）
実用的にいまいちなのはなぜか。
メールの仕様によればいくらでも添付ファイル／添付メール／添付ファイル付きメールの添付ができてしまいます。
誰が100個の添付ファイルを必要とするでしょうか。誰が100階層の添付ファイル階層を必要とするでしょうか。
再帰的に処理できるのは確かに美しい。しかし、日本語の文字化けの問題やMIME指定のわずらわしさ、それにブラウザやメーラによる（勝手な）解釈を考慮に入れるとはっきり言ってカオス状態です。
確かにデザインは美しい。しかしその結果メールシステムの実装をややこしくしているとすれば、そのデザインは「美しくない」と言わざるを得ないのです。
ではなぜこのようなことになったのか。予期できない偶然によってか。結果的にややこしいと（日本の一開発者から）言われるようになったメールのデザインが、優れたデザインだと呼ばれる可能性はあったのか。
何だかわけの分からない問いになってしまいました。
私の思うところ、メールの仕様にはひとつ問題があります。それは「割り切らなかった」ということです。
例えば「メール本文はUNICODEテキストとして送ること。添付できるファイルは1個だけ。」という仕様だったとして、誰が困るでしょうか？
#まあUNICODEは極端ですけどね。欧米の科学者が7bitASCIIしか頭にないのは残念ながらしょうがないですしょう。あくまでおとぎ話です。
おそらく誰も困りません。それにメールの実装が簡単になり、誰でもメールソフトが作れるようになります。
#それがいいことかどうかも微妙ですけどね。
まあ、結論として言いたいのは、よいデザイン（＝結果的に成功するデザイン）というのは必ずしも数学的に美しいかどうかそれだけではなく、どう割り切ったか、どこを切り捨てたか、という観点も重要になるのだなあ、とそういうことなのです。
まさにセンスですね。
2008年8月20日水曜日
これもJava （小ネタ）
これもまたJavaのパワーです。
さあ、皆さん、これから遠慮なくクラス名、変数名、メソッド名に日本語を使いましょう！！
え？嫌？
どうして？？
日本語でプログラミングできたら楽しいでしょう。だからどんどん使うべし。
つーか、Javaベースの日本語プログラミング環境作ったらウケるんじゃないかな。え？お前が作れ？
すみません。軽率でした。
C:\cygwin\home\hoge\java>dir
ドライブ C のボリューム ラベルがありません。
ボリューム シリアル番号は A884-83CA です
C:\cygwin\home\hoge\java のディレクトリ
2008/08/20 23:29 <DIR> .
2008/08/20 23:29 <DIR> ..
2008/08/20 23:22 202 あ.java
1 個のファイル 202 バイト
2 個のディレクトリ 37,727,498,240 バイトの空き領域
C:\cygwin\home\hoge\java>type *.java
あ.java
public class あ {
public static void main(String args[]) {
String 文字列変数 = "こんにちは";
出力(文字列変数);
}
private static void 出力(Object obj) {
System.out.println(obj.toString());
}
}
C:\cygwin\home\hoge\java>javac *.java
C:\cygwin\home\hoge\java>java あ
こんにちは
さあ、皆さん、これから遠慮なくクラス名、変数名、メソッド名に日本語を使いましょう！！
え？嫌？
どうして？？
日本語でプログラミングできたら楽しいでしょう。だからどんどん使うべし。
つーか、Javaベースの日本語プログラミング環境作ったらウケるんじゃないかな。え？お前が作れ？
すみません。軽率でした。
なんというトラップ Tomcatでの文字化け
今更文字化けでハマるとは・・・
しかもトラップのような仕様です。
以下が条件です。
▽ jstlのc:url c:paramなどを使って日本語のパラメータをJSPのエンコーディングでエンコードする。
▽ GETで送信する
▽ JSPのエンコードがwindows-31jである （おそらくUTF-8以外はダメでしょう）
TOMCAT5以降は、GETで送信された文字列は問答無用でUTF-8で解釈するそうです。
@IT Javaの文字化け対策FAQ（3）
何という・・・
しかもトラップのような仕様です。
以下が条件です。
▽ jstlのc:url c:paramなどを使って日本語のパラメータをJSPのエンコーディングでエンコードする。
▽ GETで送信する
▽ JSPのエンコードがwindows-31jである （おそらくUTF-8以外はダメでしょう）
TOMCAT5以降は、GETで送信された文字列は問答無用でUTF-8で解釈するそうです。
Tomcat 5.xにおいてこの問題を解消するには、同コンテナの設定ファイルserver.xmlのConnector要素にて、useBodyEncodingForURI属性を以下のように指定すればよい。詳細は以下参照
@IT Javaの文字化け対策FAQ（3）
何という・・・
どう「見せる」か（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは（後略） 初回投稿：はじめに（プロジェクトの人間学）】
下手に話をややこしくしないこと。これに尽きる。Simple is the best. 真理は単純である。ただしむやみに抽象化・汎用化してはならない。適用範囲が広がってしまう。具体的な前提を定義することが重要である。具体的かつ単純。これがコツである。自分を利口に見せることにこだわってはならない。バカでした。ごめんなさい。これで話が早く済むのならさっさと謝ってしまうのがよい。
Javaで開発しているプロジェクトで障害が発生した。障害の原因がNullPointerExceptionだった。NULLチェックを入れ忘れていた。このように見せてしまうと、影響範囲は甚大である。NULLを取りえる全てのコードにチェックが必要となる。Javaが分かっている人間であればNULLチェックはするし、ほとんどのは単体テストか結合テストで分かる判明するはずのトラブルである。しかしNullPointerExceptionが一人歩きしてしまうとただひたすらこの例外にフォーカスが当たってしまう。原因への対処には不釣合いな、膨大なリソースが投入されてしまう。NULLチェック漏れではなく、さまざまな要因が重なっているはずである。条件があるはずである。そこをちゃんと見せなければならない。そうすればそのトラブルをクローズし、次のトラブルにリソースを投入することが出来る。
また政治的な問題を軽視してはならない。現場から見れば大したことがない修正でもマネジメント層や顧客からすると大変なハードルとなることがある。現場が「大した変更じゃない」と思っても、政治的にはその選択はありえない、という可能性がある。例えば顧客の他の部署に依頼する必要がある変更である。絶対に変更を受けつけてもらえない。顧客はまず青い顔をし、次に現場を恨み始める。現場は「顧客の問題であって俺たちは知ったこっちゃない」と思う。どんどん関係が悪化し、プロジェクトがまずい方向に進む。健全にプロジェクトを運営したいなら、決して政治を軽視してはならない。
見せるにあたってはスコープを広げないこと。むしろ狭めるよう努力する。スコープとはタスクの範囲を指す。タスクの範囲を下手に広げてしまうと、完了させることが出来なくなる。あれはどうなった？と聞かれて常に状況を報告する羽目になる。タスクはシンプルに、ピンポイントで定義すること。そして何をどうしたら完了できるか、そこまであらかじめ射程に入れておくこと。完了までの道筋を見極めることなく、課題を定義しないこと。ついうっかり不安をそのまま課題にすると、却って政治的に厄介になる。重要度が最終的に低いと判明したとしても、だ。また課題を提起する際にその完了条件まで射程に入れておくと課題をクローズする効率が全く違ってくる。スコープを広げないこと。特に広げさせないこと。これが重要である。
やたらと宿題のキャッチボールをしないこと。決定事項のやり取りをキャッチボールに例えた。顧客に決定権をゆだねるとさしあたりは自らのタスクではなくなるため安心する。また待ち状態となるため、責められることがない。少なくとも決定を依頼すれば、作業を進める責任は顧客にある。だがこれは単なる作業の先送りに過ぎない。未来から時間を借りているだけである。下手に先送りすべきではないのだ。顧客への意思決定依頼は最小限にする。適切に提案し迅速にクローズ。結局はそれが一番早くて体力が掛からない。
管理されるが故に完了困難になることもある。重箱の隅が突付かれ、優先度の低いタスクが山ほど発生する。課題のクローズに完璧さが求められる。なんてことはない課題がどんどん広がり、収集がつかなくなる。最後には原型を留めないほどに課題が変質してしまう。そんなことにならないよう、出来る限りクローズを急ぐことだ。
下手に話をややこしくしないこと。これに尽きる。Simple is the best. 真理は単純である。ただしむやみに抽象化・汎用化してはならない。適用範囲が広がってしまう。具体的な前提を定義することが重要である。具体的かつ単純。これがコツである。自分を利口に見せることにこだわってはならない。バカでした。ごめんなさい。これで話が早く済むのならさっさと謝ってしまうのがよい。
Javaで開発しているプロジェクトで障害が発生した。障害の原因がNullPointerExceptionだった。NULLチェックを入れ忘れていた。このように見せてしまうと、影響範囲は甚大である。NULLを取りえる全てのコードにチェックが必要となる。Javaが分かっている人間であればNULLチェックはするし、ほとんどのは単体テストか結合テストで分かる判明するはずのトラブルである。しかしNullPointerExceptionが一人歩きしてしまうとただひたすらこの例外にフォーカスが当たってしまう。原因への対処には不釣合いな、膨大なリソースが投入されてしまう。NULLチェック漏れではなく、さまざまな要因が重なっているはずである。条件があるはずである。そこをちゃんと見せなければならない。そうすればそのトラブルをクローズし、次のトラブルにリソースを投入することが出来る。
また政治的な問題を軽視してはならない。現場から見れば大したことがない修正でもマネジメント層や顧客からすると大変なハードルとなることがある。現場が「大した変更じゃない」と思っても、政治的にはその選択はありえない、という可能性がある。例えば顧客の他の部署に依頼する必要がある変更である。絶対に変更を受けつけてもらえない。顧客はまず青い顔をし、次に現場を恨み始める。現場は「顧客の問題であって俺たちは知ったこっちゃない」と思う。どんどん関係が悪化し、プロジェクトがまずい方向に進む。健全にプロジェクトを運営したいなら、決して政治を軽視してはならない。
見せるにあたってはスコープを広げないこと。むしろ狭めるよう努力する。スコープとはタスクの範囲を指す。タスクの範囲を下手に広げてしまうと、完了させることが出来なくなる。あれはどうなった？と聞かれて常に状況を報告する羽目になる。タスクはシンプルに、ピンポイントで定義すること。そして何をどうしたら完了できるか、そこまであらかじめ射程に入れておくこと。完了までの道筋を見極めることなく、課題を定義しないこと。ついうっかり不安をそのまま課題にすると、却って政治的に厄介になる。重要度が最終的に低いと判明したとしても、だ。また課題を提起する際にその完了条件まで射程に入れておくと課題をクローズする効率が全く違ってくる。スコープを広げないこと。特に広げさせないこと。これが重要である。
やたらと宿題のキャッチボールをしないこと。決定事項のやり取りをキャッチボールに例えた。顧客に決定権をゆだねるとさしあたりは自らのタスクではなくなるため安心する。また待ち状態となるため、責められることがない。少なくとも決定を依頼すれば、作業を進める責任は顧客にある。だがこれは単なる作業の先送りに過ぎない。未来から時間を借りているだけである。下手に先送りすべきではないのだ。顧客への意思決定依頼は最小限にする。適切に提案し迅速にクローズ。結局はそれが一番早くて体力が掛からない。
管理されるが故に完了困難になることもある。重箱の隅が突付かれ、優先度の低いタスクが山ほど発生する。課題のクローズに完璧さが求められる。なんてことはない課題がどんどん広がり、収集がつかなくなる。最後には原型を留めないほどに課題が変質してしまう。そんなことにならないよう、出来る限りクローズを急ぐことだ。
2008年8月19日火曜日
数値化は見える化ではなくむしろ見えない化である（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは（後略） 初回投稿：はじめに（プロジェクトの人間学）】
数値化の危険もメリットも抽象化にあることはすでに述べた。だから過度の数値化は危険である。細かい情報がそぎおとされる上に意識が数字という現象＝みせかけに強くこだわる傾向があるからだ。
何のための「見える化」か。それはトラブルの予兆に気が付くためである。数字を眺めてトラブルの予兆に気付くか。進捗の遅れやトラブル数から分かるのはせいぜい「今トラブルが起こっている」程度であろう。その発見すら遅れるかもしれない。数字の向こうを見なければトラブルの予兆は分からない。いや今起こりつつあること全ては数字だけからは分からない。数字は意識的に抽象化された結果に過ぎないからである。すなわち質的な事象を意識的にそぎおとすことができてしまう。数字だけを信頼できないのはそのためである。トラブルを抱えたチームのテスト消化数も極めて順調に進んでいるチームのそれも「同じ一件」である。しかしその質は大きく異なるはずである。例えば前者のテストはテスト結果の確認が甘いかもしれない。前提環境の整備ができていなかったかもしれない。これが後から手戻り作業の大小につながる。順調に行っているプロジェクトですら予定外作業や小さなトラブルが日常茶飯事なのだ。そこに前フェーズ由来の手戻りが発生すると簡単にタスクオーバーフローとなる。後は品質が下がり納期が遅れて行くだけである。
ましてやメールの本数、ソースチェックイン回数、バグに関する数、そんなものをムリヤリ数値化したデータを使って、何かが出てくるはずがない。むしろ現状が隠れるだけである。日本の自殺者年間何万名。内何％が経済的理由でうんぬん。年齢別内訳が・・・そのデータで自殺者が救えるのか。残された人間の何が分かる。数値化しなければ始まらないではないか。そしてあらゆる方法でデータの分析を行う。それをお役所仕事という。他にやるべきことなど、いくらでもある。
プロジェクトを一度徹底的に数値化して管理してみれば、結局何も分からないことが分かるであろう。そればかりか下手をすればプロジェクトが壊れる可能性すらある。
「数値化＝見える化」したい要求の裏にはプロジェクトに対する無理解がある。すなわちそのままのプロジェクトを見ても分からない、評価できない。現場の人間と話をしたくない。何を言っているか分からないから。トップマネジメントも一度ありのままのプロジェクトを見てみたらどうか。たまにはメンバーといっしょにプログラムを書いてテストしてみるのも悪くはない。メンバーの抱えている作業負荷が、実感として分かるであろうから。またプロジェクトの状況も、下手に数字の分析に体力をかけるよりは良く見えるのではないだろうか。
「心ここにあらざれば 見れども見えず 聞けども聞こえず」という。気が付く力が重要である。何か変だと気がつく。納得が行かない。どうして？と思う。だがその先に行くのが難しい。ま、いっか。俺知らねーぞ。私のせいじゃない。思考停止である。次が重要なのだ。それは間違っていると思います。何故ならこれこれこうだからです。確かに嫌味なしに指摘するのは難しい。だが指摘しなければ、将来のトラブルはなくならない。「見える化」の前には「気づき」があり、次に「見せる化」があるのだ。問題を取り出し、顕わにすること。おかしいと指摘し、その理由を示すこと。それが「見える化」の本質なのだ。数値化は現象の解釈に過ぎない。しかも極端に抽象化した解釈である。ゆえにほとんどの数値化に認識としての力はなく、射程も浅い。だからよく考えられていない数値化は単なる「見えない化」なのである。「見える化」の本質は人間の有限なパースペクティブ（見晴らし）をチームで共有化することなのである。
パースペクティブとは何か。人間は一時にすべてを見渡すことが出来ない。現象は常にある立場から見た現象に過ぎない。人の立場にはさまざまな制約が働いている。時間（いついつか）、空間（どこで）、バイアス、偏見、好み、経験 etc。おのおののパースペクティブから課題あるいはトラブル以前の課題を引き出し、言葉にして共有化するのが見える化である。そして課題を正しく言語化することが出来れば、問題は解決したも同然である。あとは管理可能なTODO（いつまでに誰が何をするか）が残るだけである。
「見せ方」というとなんだかネガティブなイメージがあるかもしれない。客観的な事実をある政治的観点から「見せる」。偽りのイメージ。プロパガンダ。そうではない。事象が発生するとまずは解釈しなければならない。神であれば解釈の必要はないであろう。あるがままを全方位から捉えることが出来るに違いない。しかし人間は神ではない。その人の持っている背景（制約。時間空間バイアス・・・）からその事象を解釈せざるを得ない。数式を眺めて相対性理論を思いつくか否か。人によってそのくらいの違いがある。ウィスキーが半分残っている。まだ半分あると思うか、もう半分しかないと思うか。人は皆年を取る。４０歳になったとしてどう生きるか。何も思わないか。それともそれをきっかけにまったく新しいチャレンジをするか。「客観的」な事象などない。「見せる」前には「解釈」がある。そして「解釈」は力なのだ。力を持った人が解釈し得るのである。すなわち（残念ではあるが）力を持たない人間に力強い解釈はできない。力のない人間は力のある人間の認識を鵜呑みにするか、弱々しい自らの認識にすがる他はない。解釈とは自分を変え、世界を変えることなのだ。解釈にはそれほどの力がある。極端を言えば資本主義だって経済学だって物理学だってそれぞれが世界の解釈なのだ。
数値化の危険もメリットも抽象化にあることはすでに述べた。だから過度の数値化は危険である。細かい情報がそぎおとされる上に意識が数字という現象＝みせかけに強くこだわる傾向があるからだ。
何のための「見える化」か。それはトラブルの予兆に気が付くためである。数字を眺めてトラブルの予兆に気付くか。進捗の遅れやトラブル数から分かるのはせいぜい「今トラブルが起こっている」程度であろう。その発見すら遅れるかもしれない。数字の向こうを見なければトラブルの予兆は分からない。いや今起こりつつあること全ては数字だけからは分からない。数字は意識的に抽象化された結果に過ぎないからである。すなわち質的な事象を意識的にそぎおとすことができてしまう。数字だけを信頼できないのはそのためである。トラブルを抱えたチームのテスト消化数も極めて順調に進んでいるチームのそれも「同じ一件」である。しかしその質は大きく異なるはずである。例えば前者のテストはテスト結果の確認が甘いかもしれない。前提環境の整備ができていなかったかもしれない。これが後から手戻り作業の大小につながる。順調に行っているプロジェクトですら予定外作業や小さなトラブルが日常茶飯事なのだ。そこに前フェーズ由来の手戻りが発生すると簡単にタスクオーバーフローとなる。後は品質が下がり納期が遅れて行くだけである。
ましてやメールの本数、ソースチェックイン回数、バグに関する数、そんなものをムリヤリ数値化したデータを使って、何かが出てくるはずがない。むしろ現状が隠れるだけである。日本の自殺者年間何万名。内何％が経済的理由でうんぬん。年齢別内訳が・・・そのデータで自殺者が救えるのか。残された人間の何が分かる。数値化しなければ始まらないではないか。そしてあらゆる方法でデータの分析を行う。それをお役所仕事という。他にやるべきことなど、いくらでもある。
プロジェクトを一度徹底的に数値化して管理してみれば、結局何も分からないことが分かるであろう。そればかりか下手をすればプロジェクトが壊れる可能性すらある。
「数値化＝見える化」したい要求の裏にはプロジェクトに対する無理解がある。すなわちそのままのプロジェクトを見ても分からない、評価できない。現場の人間と話をしたくない。何を言っているか分からないから。トップマネジメントも一度ありのままのプロジェクトを見てみたらどうか。たまにはメンバーといっしょにプログラムを書いてテストしてみるのも悪くはない。メンバーの抱えている作業負荷が、実感として分かるであろうから。またプロジェクトの状況も、下手に数字の分析に体力をかけるよりは良く見えるのではないだろうか。
「心ここにあらざれば 見れども見えず 聞けども聞こえず」という。気が付く力が重要である。何か変だと気がつく。納得が行かない。どうして？と思う。だがその先に行くのが難しい。ま、いっか。俺知らねーぞ。私のせいじゃない。思考停止である。次が重要なのだ。それは間違っていると思います。何故ならこれこれこうだからです。確かに嫌味なしに指摘するのは難しい。だが指摘しなければ、将来のトラブルはなくならない。「見える化」の前には「気づき」があり、次に「見せる化」があるのだ。問題を取り出し、顕わにすること。おかしいと指摘し、その理由を示すこと。それが「見える化」の本質なのだ。数値化は現象の解釈に過ぎない。しかも極端に抽象化した解釈である。ゆえにほとんどの数値化に認識としての力はなく、射程も浅い。だからよく考えられていない数値化は単なる「見えない化」なのである。「見える化」の本質は人間の有限なパースペクティブ（見晴らし）をチームで共有化することなのである。
パースペクティブとは何か。人間は一時にすべてを見渡すことが出来ない。現象は常にある立場から見た現象に過ぎない。人の立場にはさまざまな制約が働いている。時間（いついつか）、空間（どこで）、バイアス、偏見、好み、経験 etc。おのおののパースペクティブから課題あるいはトラブル以前の課題を引き出し、言葉にして共有化するのが見える化である。そして課題を正しく言語化することが出来れば、問題は解決したも同然である。あとは管理可能なTODO（いつまでに誰が何をするか）が残るだけである。
「見せ方」というとなんだかネガティブなイメージがあるかもしれない。客観的な事実をある政治的観点から「見せる」。偽りのイメージ。プロパガンダ。そうではない。事象が発生するとまずは解釈しなければならない。神であれば解釈の必要はないであろう。あるがままを全方位から捉えることが出来るに違いない。しかし人間は神ではない。その人の持っている背景（制約。時間空間バイアス・・・）からその事象を解釈せざるを得ない。数式を眺めて相対性理論を思いつくか否か。人によってそのくらいの違いがある。ウィスキーが半分残っている。まだ半分あると思うか、もう半分しかないと思うか。人は皆年を取る。４０歳になったとしてどう生きるか。何も思わないか。それともそれをきっかけにまったく新しいチャレンジをするか。「客観的」な事象などない。「見せる」前には「解釈」がある。そして「解釈」は力なのだ。力を持った人が解釈し得るのである。すなわち（残念ではあるが）力を持たない人間に力強い解釈はできない。力のない人間は力のある人間の認識を鵜呑みにするか、弱々しい自らの認識にすがる他はない。解釈とは自分を変え、世界を変えることなのだ。解釈にはそれほどの力がある。極端を言えば資本主義だって経済学だって物理学だってそれぞれが世界の解釈なのだ。
2008年8月18日月曜日
今そこにあるトラブルに気が付くこと（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは（後略） 初回投稿：はじめに（プロジェクトの人間学）】
トラブルの原因は、トラブル発生の後に分かる。「後になって分かる」それが実は「原因」という概念の本質的な属性である。あの判断が誤っていた。あのドキュメントをチェックすべきであった。全て後から作られる「物語」である（原因も結果も存在しない、ことは以前にも述べた）。
こういった「原因と結果」物語によって意識化された経験は、実を結ぶ時期の早い遅いはあるにせよ、その人固有のノウハウとして蓄積される。そのノウハウが次のトラブルの予知につながる。しかし性急な意識化はトラブルの予知能力には結び付かない。ある程度の熟成期間が必要である。方法論だけではトラブルを事前につぶすことはできない。「何か変だな」と気が付くこと、そしてその「おかしい」という感覚を言語化する能力が必要である。さまざまな予兆がある。誤った意思決定。問題の先送り。担当者が全く見落としている場合もあれば隠している場合もある。ある種のトラブルは不可避である。事前に全ての情報を得ることも、全ての可能性を検討することもできないから。早い話が「やってみるまでわからない」そういう状況が確実にある。だったらトラブルは起こって当たり前じゃないか。その通り。トラブルを許容しなければ、先に進まない。リスクも同様である。
全てのトラブルが不可避だなどと言っている訳ではない。予防できるトラブルがあり、マネージできるリスクがある。だったらそっちに注力したらいい。起きてしまった事は起きてしまった事である。しかるべき対応をとり、妥当な再発防止案を検討したらよい。
予防できるトラブルとは何か。それは事前にトラブルの予兆を知りえたトラブルである。からかっているのか。そうではない。一寸先は闇と昔から言うではないか。未来は未だ来ぬ故に存在しない。だから未来は分からない。だが将に来るべき将来なら分かることがある。どのようにして分かるのか。過去も未来も存在しないと前に述べた。すべてのヒントは現在にある。妙な流れに向かっているミーティング。本質から離れた論点で執拗に繰り返される議論。担保の取れていない不確定情報を垂れ流すメンバー。その不確定情報を元に意思決定されそうになっている。オーバーワークで深夜残業を繰り返すメンバー。すでにその品質に疑義がある。以上の事象は数字には決して現れない。すべてがトラブルの予兆である。その中のどれが実際のトラブルになるか。それはその時になってみなければ分からない。だが経験と勘がそれを助けることがある。筆者の経験では上の例はすべて明確なトラブルの前触れであり、後のトラブル発生は必至である。
筆者の妻が皿を洗う時、洗い終わった皿を水きりカゴにやたらと積み上げる。そんなに積んだら崩れるぞと何度も警告するのだがほとんど言っても無駄である。たいてい聞き流されるし、ひどい時には逆切れされる。何ヶ月かに一度、皿の山が崩れ妻の悲鳴と共に皿が割れる。これもまた仕方がない。見る目が無かった。それだけの話である。「どうしてあの人と結婚したの？」これもまた因果律の本性を省みない、厳しい質問である。だってもう仕方がないじゃないか。
だから何とか我慢しようとしてみる。頑張ってミーティングの流れを補正しようとする。議論を本質的な流れに戻そうと頑張ってみる。不確定情報は「確認しろ」と指示を出す。意思決定ではなるべくリスクとコンチプランを検討する。それで上手く行くこともある。だが残念ながらすべてが上手く行くわけではない。所詮は人間のやることである。
また予兆を知ったとしても必ずしも手を取れるわけではない。明らかにオーバーワークのメンバーがいたとしても、コストがない、権限がないなどの理由で体力の投入ができない場合がある。その場合は今できることをできるだけ行い（例えばそのメンバーをできるだけ雑用から守るなど）、大きなトラブルが次のフェーズで発生するのを覚悟するほかはない。
PDCA(Plan Do Check Action)だけでは足りない。Planの前に問題に感覚的に気が付かなければならない。そして問題を正確に定義しなければならない。また最後のActionは余計である。事後作業が不要になるようにPlanし、念のためCheckして問題が無ければクローズである。だから正確にはFPDC(Feel Plan Do Check)である。PDCAで回るほどプロジェクトは簡単ではないし、悠長でもない。Feelとは、今現に何が起こっているのか把握することでもある。これは会議では把握できない。会議で把握できるのはこぎれいに抽象化された情報であり、生のデータではない。だから現場で実際に見る必要がある。
しかし残念ながらマネジメント層や顧客は、現場を見ても何が起きているのか分からない。不祥事を出す会社の役員が、現場を知らないのと同じである。現場を見ても分からないし、解釈もできない。だから現場から適切な情報も上がらなくなる。確かにシステムは余りにも複雑である。だがマネジメント層もなるべく低いレベルまで状況を押さえるべきなのである。
トラブルの原因は、トラブル発生の後に分かる。「後になって分かる」それが実は「原因」という概念の本質的な属性である。あの判断が誤っていた。あのドキュメントをチェックすべきであった。全て後から作られる「物語」である（原因も結果も存在しない、ことは以前にも述べた）。
こういった「原因と結果」物語によって意識化された経験は、実を結ぶ時期の早い遅いはあるにせよ、その人固有のノウハウとして蓄積される。そのノウハウが次のトラブルの予知につながる。しかし性急な意識化はトラブルの予知能力には結び付かない。ある程度の熟成期間が必要である。方法論だけではトラブルを事前につぶすことはできない。「何か変だな」と気が付くこと、そしてその「おかしい」という感覚を言語化する能力が必要である。さまざまな予兆がある。誤った意思決定。問題の先送り。担当者が全く見落としている場合もあれば隠している場合もある。ある種のトラブルは不可避である。事前に全ての情報を得ることも、全ての可能性を検討することもできないから。早い話が「やってみるまでわからない」そういう状況が確実にある。だったらトラブルは起こって当たり前じゃないか。その通り。トラブルを許容しなければ、先に進まない。リスクも同様である。
全てのトラブルが不可避だなどと言っている訳ではない。予防できるトラブルがあり、マネージできるリスクがある。だったらそっちに注力したらいい。起きてしまった事は起きてしまった事である。しかるべき対応をとり、妥当な再発防止案を検討したらよい。
予防できるトラブルとは何か。それは事前にトラブルの予兆を知りえたトラブルである。からかっているのか。そうではない。一寸先は闇と昔から言うではないか。未来は未だ来ぬ故に存在しない。だから未来は分からない。だが将に来るべき将来なら分かることがある。どのようにして分かるのか。過去も未来も存在しないと前に述べた。すべてのヒントは現在にある。妙な流れに向かっているミーティング。本質から離れた論点で執拗に繰り返される議論。担保の取れていない不確定情報を垂れ流すメンバー。その不確定情報を元に意思決定されそうになっている。オーバーワークで深夜残業を繰り返すメンバー。すでにその品質に疑義がある。以上の事象は数字には決して現れない。すべてがトラブルの予兆である。その中のどれが実際のトラブルになるか。それはその時になってみなければ分からない。だが経験と勘がそれを助けることがある。筆者の経験では上の例はすべて明確なトラブルの前触れであり、後のトラブル発生は必至である。
筆者の妻が皿を洗う時、洗い終わった皿を水きりカゴにやたらと積み上げる。そんなに積んだら崩れるぞと何度も警告するのだがほとんど言っても無駄である。たいてい聞き流されるし、ひどい時には逆切れされる。何ヶ月かに一度、皿の山が崩れ妻の悲鳴と共に皿が割れる。これもまた仕方がない。見る目が無かった。それだけの話である。「どうしてあの人と結婚したの？」これもまた因果律の本性を省みない、厳しい質問である。だってもう仕方がないじゃないか。
だから何とか我慢しようとしてみる。頑張ってミーティングの流れを補正しようとする。議論を本質的な流れに戻そうと頑張ってみる。不確定情報は「確認しろ」と指示を出す。意思決定ではなるべくリスクとコンチプランを検討する。それで上手く行くこともある。だが残念ながらすべてが上手く行くわけではない。所詮は人間のやることである。
また予兆を知ったとしても必ずしも手を取れるわけではない。明らかにオーバーワークのメンバーがいたとしても、コストがない、権限がないなどの理由で体力の投入ができない場合がある。その場合は今できることをできるだけ行い（例えばそのメンバーをできるだけ雑用から守るなど）、大きなトラブルが次のフェーズで発生するのを覚悟するほかはない。
PDCA(Plan Do Check Action)だけでは足りない。Planの前に問題に感覚的に気が付かなければならない。そして問題を正確に定義しなければならない。また最後のActionは余計である。事後作業が不要になるようにPlanし、念のためCheckして問題が無ければクローズである。だから正確にはFPDC(Feel Plan Do Check)である。PDCAで回るほどプロジェクトは簡単ではないし、悠長でもない。Feelとは、今現に何が起こっているのか把握することでもある。これは会議では把握できない。会議で把握できるのはこぎれいに抽象化された情報であり、生のデータではない。だから現場で実際に見る必要がある。
しかし残念ながらマネジメント層や顧客は、現場を見ても何が起きているのか分からない。不祥事を出す会社の役員が、現場を知らないのと同じである。現場を見ても分からないし、解釈もできない。だから現場から適切な情報も上がらなくなる。確かにシステムは余りにも複雑である。だがマネジメント層もなるべく低いレベルまで状況を押さえるべきなのである。
ドキュメント軽視の理由（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは（後略） 初回投稿：はじめに（プロジェクトの人間学）】
なぜある種の開発方法論がドキュメント軽視を生むのか。時間をフェーズで区切りそれぞれの成果物を定義する。あるフェーズの終わりに納期が来る。プロジェクトのある一時点の状況を考えてみる。それは詰められた要件と漠然とした希望レベルの要件が混在する状況であろう。プロジェクトの途中で全ての話が煮詰まっているなどありえない。そして設計書の記載レベルは当然粒度の粗いほうにできるだけ合わせることになる。要するに煮詰まっている要件でも細かいレベルまでは記載しないような動機付けが働いてしまう。
ウォーターフォール型プロジェクトがドキュメント軽視を生む理由がもう一つある。それはドキュメントの納期が過ぎた後の修正作業に負のインセンティブが発生することである。成果物は納期を過ぎると一旦FIXしたものと見なされる。一般に過去の蓄積に対する変更は好まれない（前述のトラブルの定義参照）。つまりドキュメントの変更が好まれないから、詳細に設計を紙に落とすことも、まめにメンテナンスすることも結局は好まれないのである。これもまた本末転倒の類であろう。
システム構築プロジェクトが必然的にドキュメント軽視を生むとは思わない。ただし、そうしないためにはリリース直前までドキュメントの変更を励行しなければならない。それができるマネージャがいるだろうか。そんなことをしたらウォーターフォール型開発の前提が崩れるではないか。筆者はそこは崩しても問題ないと思っている。事実、マイクロソフトの開発プロジェクトはリリース直前まで設計書を更新すると「ジョエル・オン・ソフトウェア」（オーム社）にあった。正しいと思う。常に設計書を最新にしておくことは、最善の実践としか思えないではないか。
トラブルを恐れるからさまざまな本末転倒が生まれるのだ。トラブルを自然なものと受け入れ、その上でベストの対応を取ればよい。設計書の修正もその一つである。
なぜある種の開発方法論がドキュメント軽視を生むのか。時間をフェーズで区切りそれぞれの成果物を定義する。あるフェーズの終わりに納期が来る。プロジェクトのある一時点の状況を考えてみる。それは詰められた要件と漠然とした希望レベルの要件が混在する状況であろう。プロジェクトの途中で全ての話が煮詰まっているなどありえない。そして設計書の記載レベルは当然粒度の粗いほうにできるだけ合わせることになる。要するに煮詰まっている要件でも細かいレベルまでは記載しないような動機付けが働いてしまう。
ウォーターフォール型プロジェクトがドキュメント軽視を生む理由がもう一つある。それはドキュメントの納期が過ぎた後の修正作業に負のインセンティブが発生することである。成果物は納期を過ぎると一旦FIXしたものと見なされる。一般に過去の蓄積に対する変更は好まれない（前述のトラブルの定義参照）。つまりドキュメントの変更が好まれないから、詳細に設計を紙に落とすことも、まめにメンテナンスすることも結局は好まれないのである。これもまた本末転倒の類であろう。
システム構築プロジェクトが必然的にドキュメント軽視を生むとは思わない。ただし、そうしないためにはリリース直前までドキュメントの変更を励行しなければならない。それができるマネージャがいるだろうか。そんなことをしたらウォーターフォール型開発の前提が崩れるではないか。筆者はそこは崩しても問題ないと思っている。事実、マイクロソフトの開発プロジェクトはリリース直前まで設計書を更新すると「ジョエル・オン・ソフトウェア」（オーム社）にあった。正しいと思う。常に設計書を最新にしておくことは、最善の実践としか思えないではないか。
トラブルを恐れるからさまざまな本末転倒が生まれるのだ。トラブルを自然なものと受け入れ、その上でベストの対応を取ればよい。設計書の修正もその一つである。
タガの外れた面白さ （崖の上のポニョ）
崖の上のポニョを見ました。
凄かったです。
言葉で語られるべきではないですね。あれは。
ぶっとんでいるというか、脳みそが海水に浸ったような面白さでした。
何で？どうして？？あれあれあれ？？？？
すさまじいばかりのおとぎ話パワーと申しましょうか。
そこかしこで広がりのあるイメージが爆発しています。
あっという間にぐいぐい引き込まれて、最後もあれれれれ？とにかく何だか凄かったな、という余韻が２，３日は続きます。この歳になってこんなインパクトを受ける映画はそんなにない。
さかしらに言えば突っ込みどころ満載なのでしょが、あのパワーとセンスは凄い。トータルのインパクトも凄い。あの作品を語る言葉は存在しないのでは、という気がします。
踏み込めば宮崎さんのトラウマまで行くと思いますが、そんなことをしてもしょうがない。
とにかく面白かったです。
凄かったです。
言葉で語られるべきではないですね。あれは。
ぶっとんでいるというか、脳みそが海水に浸ったような面白さでした。
何で？どうして？？あれあれあれ？？？？
すさまじいばかりのおとぎ話パワーと申しましょうか。
そこかしこで広がりのあるイメージが爆発しています。
あっという間にぐいぐい引き込まれて、最後もあれれれれ？とにかく何だか凄かったな、という余韻が２，３日は続きます。この歳になってこんなインパクトを受ける映画はそんなにない。
さかしらに言えば突っ込みどころ満載なのでしょが、あのパワーとセンスは凄い。トータルのインパクトも凄い。あの作品を語る言葉は存在しないのでは、という気がします。
踏み込めば宮崎さんのトラウマまで行くと思いますが、そんなことをしてもしょうがない。
とにかく面白かったです。
2008年8月15日金曜日
常に質が重要である（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは（後略）初回投稿：はじめに（プロジェクトの人間学）】
本日のコーディング進捗。予定数20本に対して21本。妥当な人員（スキルと人数）、期間、作業量で回っているプロジェクトならば問題ない。しかし普通は何がしかのトラブルを抱えているものである。プロジェクトの状況を押さえなければこの数字は評価できない。例えばメンバーのスキル。働いているときの顔色や帰宅時間。会話の内容。質的なものを考慮すれば数字の中身が見えてくる。
最も重要なのがトラブルの質である。単純ミス、製品障害、設計ミス、コミュニケーションミス、さまざまなトラブルがある。そして時期によってトラブルの評価は変わってくる。
初期設計フェーズで潰しておきたいトラブルの一つはグランドデザイン上鍵となる技術のフィージビリティである。要するに例えば「JavaとDBでそれができるんだっけ？」とか「データのサイズが5年後に5TBを超えるけど、運用回るんだっけ？」という確認である。「そもそもサポートされていない」とか「このグランドデザインでは実現は困難」という事実はこの時期に発見しなければならない。確定情報を掴みきれなかった場合には代替プランも必要である。
新しいテクノロジーを採用する際のリスクをある程度はここで潰すことになる。最近は技術の実体が見え難い。その理由はニッチな規格の乱立、分かったような分からないような営業トークである。Javaでいえば初期のEJBまではまだ何とかなった（使わないけど）。WebServicesだの何だの出てきてからがひどい。素晴らしいソリューションだとかなんだとかいうから見てみたらただのリモートプロシージャコールじゃないか。実績があるから、話題だから、というだけの利用で採用し、フィージビリティ検討が甘いと後でひどいことになる。
それから最初の設計方針に制約があるかどうかも事前に押さえておかなければならない。例えば「並列に作業できる要件に対応して、子画面を複数立ち上げて操作可能とする」という設計にした場合、画面遷移が複雑怪奇となり、また組み合わせによってはデータの受け渡しの関係上使えない子画面が出てくる可能性がある。それを最初にリスク・懸念として顧客と共有し、次のフェーズで対応して行く必要がある。
初期設計フェーズでは、以下のトラブルの種が植えられる。
－フィージビリティ系トラブル（プロジェクト成立の根幹に関わるものから軽いものまで）
－グランドデザインから発生する制約の見落とし
当たり前だが後の工程になるほど上記トラブルのインパクトは大きくなる。
詳細設計フェーズのトラブルは、基本設計がそれなりに出来ていたとすれば、あまり深刻なものではない。フィージビリティやデザインを詰めて行くだけである。しかしもちろん基本設計がうまく行くプロジェクトはそんなにない。だから大抵は根本的なフィージビリティが詳細設計フェーズでも課題となる。
またグランドデザインの検討が進み、追加の機能が必要になることが分かってくる。大抵は止むを得ない追加となる。
開発、テストフェーズ初めてロジック上のトラブルが出てくる。このCD/UTフェーズでのロジックトラブルは必然的であり、自然である。表に出ないためあまり騒がれることもない。この時期にフィージビリティ検証の甘さが露呈する場合もある。結合テストで出るよりはましである。この時期は時間が足りないことで品質が下がるリスクがある。またコミュニケーションミスによる実装漏れがある。詳細設計で詰めて書かれていないため、この手の実装漏れは直接コードを見るしか確認できないのが実情である。ただし全コードをレビューする時間などないから、うまくサンプリングしてレビューしなければならない。レビューワは専任の方がよい。開発者に片手間にレビューさせると、体力の関係で開発者が担当するコードの品質が落ちる。詳細設計でロジックまで詰められていない、かつレビューに十分な時間が取れなかったまま結合テストに進んだプロジェクトは、通常大きなトラブルに遭遇することになる。
CD/UTで判明するロジックのトラブルは理想的には詳細設計フェーズで潰されるべきである。しかしもちろんそんなことにはならない。現実には詳細設計はせいぜい「ロジックに落とし込めないほど大雑把な手順」あるいは「顧客の漠然とした希望」が記載されるに留まる。その理由は２つある。一つは開発者が陥りがちな設計書の軽視である。コーディングしてUTするのが一番早いんですよ。一理ある。だが仕様と品質がきちんと守られドキュメントがメンテナンスされる必要がある。別に優等生ぶるつもりはない。引き継ぎ体力の節約と余計なトラブルの防止を防ぐためだ。CDUTを優先する開発者はドキュメントを軽視する傾向がある。面倒くさいのと日本語が苦手だからであろう。だが実はこれは開発者だけの責任ではない。ウォーターフォール型方法論の厳格な適用もドキュメント軽視を生むのである。
本日のコーディング進捗。予定数20本に対して21本。妥当な人員（スキルと人数）、期間、作業量で回っているプロジェクトならば問題ない。しかし普通は何がしかのトラブルを抱えているものである。プロジェクトの状況を押さえなければこの数字は評価できない。例えばメンバーのスキル。働いているときの顔色や帰宅時間。会話の内容。質的なものを考慮すれば数字の中身が見えてくる。
最も重要なのがトラブルの質である。単純ミス、製品障害、設計ミス、コミュニケーションミス、さまざまなトラブルがある。そして時期によってトラブルの評価は変わってくる。
初期設計フェーズで潰しておきたいトラブルの一つはグランドデザイン上鍵となる技術のフィージビリティである。要するに例えば「JavaとDBでそれができるんだっけ？」とか「データのサイズが5年後に5TBを超えるけど、運用回るんだっけ？」という確認である。「そもそもサポートされていない」とか「このグランドデザインでは実現は困難」という事実はこの時期に発見しなければならない。確定情報を掴みきれなかった場合には代替プランも必要である。
新しいテクノロジーを採用する際のリスクをある程度はここで潰すことになる。最近は技術の実体が見え難い。その理由はニッチな規格の乱立、分かったような分からないような営業トークである。Javaでいえば初期のEJBまではまだ何とかなった（使わないけど）。WebServicesだの何だの出てきてからがひどい。素晴らしいソリューションだとかなんだとかいうから見てみたらただのリモートプロシージャコールじゃないか。実績があるから、話題だから、というだけの利用で採用し、フィージビリティ検討が甘いと後でひどいことになる。
それから最初の設計方針に制約があるかどうかも事前に押さえておかなければならない。例えば「並列に作業できる要件に対応して、子画面を複数立ち上げて操作可能とする」という設計にした場合、画面遷移が複雑怪奇となり、また組み合わせによってはデータの受け渡しの関係上使えない子画面が出てくる可能性がある。それを最初にリスク・懸念として顧客と共有し、次のフェーズで対応して行く必要がある。
初期設計フェーズでは、以下のトラブルの種が植えられる。
－フィージビリティ系トラブル（プロジェクト成立の根幹に関わるものから軽いものまで）
－グランドデザインから発生する制約の見落とし
当たり前だが後の工程になるほど上記トラブルのインパクトは大きくなる。
詳細設計フェーズのトラブルは、基本設計がそれなりに出来ていたとすれば、あまり深刻なものではない。フィージビリティやデザインを詰めて行くだけである。しかしもちろん基本設計がうまく行くプロジェクトはそんなにない。だから大抵は根本的なフィージビリティが詳細設計フェーズでも課題となる。
またグランドデザインの検討が進み、追加の機能が必要になることが分かってくる。大抵は止むを得ない追加となる。
開発、テストフェーズ初めてロジック上のトラブルが出てくる。このCD/UTフェーズでのロジックトラブルは必然的であり、自然である。表に出ないためあまり騒がれることもない。この時期にフィージビリティ検証の甘さが露呈する場合もある。結合テストで出るよりはましである。この時期は時間が足りないことで品質が下がるリスクがある。またコミュニケーションミスによる実装漏れがある。詳細設計で詰めて書かれていないため、この手の実装漏れは直接コードを見るしか確認できないのが実情である。ただし全コードをレビューする時間などないから、うまくサンプリングしてレビューしなければならない。レビューワは専任の方がよい。開発者に片手間にレビューさせると、体力の関係で開発者が担当するコードの品質が落ちる。詳細設計でロジックまで詰められていない、かつレビューに十分な時間が取れなかったまま結合テストに進んだプロジェクトは、通常大きなトラブルに遭遇することになる。
CD/UTで判明するロジックのトラブルは理想的には詳細設計フェーズで潰されるべきである。しかしもちろんそんなことにはならない。現実には詳細設計はせいぜい「ロジックに落とし込めないほど大雑把な手順」あるいは「顧客の漠然とした希望」が記載されるに留まる。その理由は２つある。一つは開発者が陥りがちな設計書の軽視である。コーディングしてUTするのが一番早いんですよ。一理ある。だが仕様と品質がきちんと守られドキュメントがメンテナンスされる必要がある。別に優等生ぶるつもりはない。引き継ぎ体力の節約と余計なトラブルの防止を防ぐためだ。CDUTを優先する開発者はドキュメントを軽視する傾向がある。面倒くさいのと日本語が苦手だからであろう。だが実はこれは開発者だけの責任ではない。ウォーターフォール型方法論の厳格な適用もドキュメント軽視を生むのである。
2008年8月14日木曜日
数値化の罠（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】
進捗状況やトラブルが数値化されないプロジェクトはほとんど考えられない。しかし数値化には実にさまざまな危険がある。
－過度の抽象化
本日の交通事故死者１名。これで何が分かるか。数値化は究極の抽象化である。数字以外のすべてが削ぎおとされる。
－測定対象を誤る危険
数値化には必ず測定方法が先立つ。何をどのように測定するか。測定できる、というのは測定する理由にはならない。これを「データの罠」と呼ぶ。数えるべきでないものを数えてしまう。数えた結果を分析し、報告書にまとめなくてはならなくなる。無用なデータに不釣合いな体力が掛けられることになる。
プロジェクトを論じた本に「メールの数を計測してコミュニケーションがうまくいっているかどうかの指標にしたらよい」という記載を見て仰天したことがある。単なるお礼メールがあり、連絡メールがある。無駄な作業とコミュニケーションを引き起こすメールがある。あるいは一本で仕事をクローズする優れたメールもある。日に1000通メールが飛び交ったからといってそこから何も導けやしない。単に混乱しているだけかもしれないではないか。
－数値化の観点
数値化するためには観点もまた必要である。切り口によって見えるものが違ってくる。何を目的として数えるのか。目的のない数値化はプロジェクトにおいては単なるオーバーヘッドである。
－数値にとらわれてしまう
数値には曖昧さがない。そして足算と引算は誰がやっても同じ結果が返る。昨日までの累計が１００だった。本日１０追加された。故に本日は１１０となる。当然そうならなければならない。ところがそうはならないことがある。勘違いがあった。あるいは本来であれば数に入れるべきものでない項目が含まれていた。数を取り出すには抽象化が必要であり、抽象化には解釈の入る余地がある。しかしマネジメント層にはこれが気に入らない。数字の不整合を許容することは意識にとっては非常に難しい。するとどうなるか。現実の方を数字に合わせ始めるのである。整合性のない数字が隠蔽やウソを引き起こす。
優秀な人間は数字に強いリアリティを感じる傾向がある。また数字に強いということは、会社で出世するための重要な能力の一つである。優秀な人間や出世した人間がプロジェクトを管理することが多い。従ってこの数値化偏重傾向は潜在的にプロジェクトに存在していると思ってよい。数字の使い方を誤ると、現実の方を数字に合わせること、具体的には数字の見せ方や出し方に大きな体力がかけられることになる。
カントは正しい。プロジェクトそれ自体は決して認識できない。認識できるのは単なる現象である。そして数字は現象に投げ入れる概念の一つに過ぎない。今風にいえばただのクオリアである。その数字にプロジェクトが踊らされている。プロジェクトの目的は何か。この問いは常に価値がある。果たして数字合わせと化したマネジメントに何が貢献できるのだろうか。
進捗状況やトラブルが数値化されないプロジェクトはほとんど考えられない。しかし数値化には実にさまざまな危険がある。
－過度の抽象化
本日の交通事故死者１名。これで何が分かるか。数値化は究極の抽象化である。数字以外のすべてが削ぎおとされる。
－測定対象を誤る危険
数値化には必ず測定方法が先立つ。何をどのように測定するか。測定できる、というのは測定する理由にはならない。これを「データの罠」と呼ぶ。数えるべきでないものを数えてしまう。数えた結果を分析し、報告書にまとめなくてはならなくなる。無用なデータに不釣合いな体力が掛けられることになる。
プロジェクトを論じた本に「メールの数を計測してコミュニケーションがうまくいっているかどうかの指標にしたらよい」という記載を見て仰天したことがある。単なるお礼メールがあり、連絡メールがある。無駄な作業とコミュニケーションを引き起こすメールがある。あるいは一本で仕事をクローズする優れたメールもある。日に1000通メールが飛び交ったからといってそこから何も導けやしない。単に混乱しているだけかもしれないではないか。
－数値化の観点
数値化するためには観点もまた必要である。切り口によって見えるものが違ってくる。何を目的として数えるのか。目的のない数値化はプロジェクトにおいては単なるオーバーヘッドである。
－数値にとらわれてしまう
数値には曖昧さがない。そして足算と引算は誰がやっても同じ結果が返る。昨日までの累計が１００だった。本日１０追加された。故に本日は１１０となる。当然そうならなければならない。ところがそうはならないことがある。勘違いがあった。あるいは本来であれば数に入れるべきものでない項目が含まれていた。数を取り出すには抽象化が必要であり、抽象化には解釈の入る余地がある。しかしマネジメント層にはこれが気に入らない。数字の不整合を許容することは意識にとっては非常に難しい。するとどうなるか。現実の方を数字に合わせ始めるのである。整合性のない数字が隠蔽やウソを引き起こす。
優秀な人間は数字に強いリアリティを感じる傾向がある。また数字に強いということは、会社で出世するための重要な能力の一つである。優秀な人間や出世した人間がプロジェクトを管理することが多い。従ってこの数値化偏重傾向は潜在的にプロジェクトに存在していると思ってよい。数字の使い方を誤ると、現実の方を数字に合わせること、具体的には数字の見せ方や出し方に大きな体力がかけられることになる。
カントは正しい。プロジェクトそれ自体は決して認識できない。認識できるのは単なる現象である。そして数字は現象に投げ入れる概念の一つに過ぎない。今風にいえばただのクオリアである。その数字にプロジェクトが踊らされている。プロジェクトの目的は何か。この問いは常に価値がある。果たして数字合わせと化したマネジメントに何が貢献できるのだろうか。
トラブルを予防する（プロジェクトの人間学)
トラブルを出さない、出したくない。これもまた自然な感情である。しかし前に述べた通りここからトラブルへの拒否反応を導いてはならない。トラブルを防ぐ効果的な方法を実践する必要がある。
トラブルを出さないためにはどうすればよいか。メンバーにできるだけまとまった時間を与えることである。そして今作っているシステムについて考えさせる。プレッシャーは与えない。それだけ。まともなエンジニアは大抵極めて真面目である。ハードワークを辞さず、トラブルには深刻に真剣に対応する（無論たまには厄災と表現する他はない人材がいるがここでは無視する）。プレッシャーにも慣れてはいる（頼みもしないのに自分でプレッシャーを感じて苦しむものもいる）が、だからといって必要もないのに与えることはない。プレッシャーを与えても頭は良くならない。デマルコが言った。割り込みのないまとまった時間を与えるのが管理者の仕事であり一番有効なトラブルの予防策である。
トラブルを出さないためにはどうすればよいか。メンバーにできるだけまとまった時間を与えることである。そして今作っているシステムについて考えさせる。プレッシャーは与えない。それだけ。まともなエンジニアは大抵極めて真面目である。ハードワークを辞さず、トラブルには深刻に真剣に対応する（無論たまには厄災と表現する他はない人材がいるがここでは無視する）。プレッシャーにも慣れてはいる（頼みもしないのに自分でプレッシャーを感じて苦しむものもいる）が、だからといって必要もないのに与えることはない。プレッシャーを与えても頭は良くならない。デマルコが言った。割り込みのないまとまった時間を与えるのが管理者の仕事であり一番有効なトラブルの予防策である。
トラブルの意味を考える（プロジェクトの人間学)
プロジェクトは取り返しのつかない決断の連続である。そして状況は変わって行く。以前は重要だったことが全く問題ではなくなることがある。またその逆もしかり。過去に発言した言葉は変わらない。だが誤りを認めることはできる。
プロジェクトは過去の積み重ねに他ならない。トラブルとは過去の積み重ねの否定である。すなわちトラブルはプロジェクトの（少なくとも部分的な）否定である。過去の積み重ねとして定義されたプロジェクトには、人間の活動全般が含まれる。すなわち人々がプロジェクトを過ごした時間そのものが、またプロジェクトには含まれている。
過去は過ぎ去ったものである。ゆえにもはや存在しない。存在するのは現在のみである。過去は例えば仕様書や議事録、記憶という形で残って「いる」。その過去によって現在の我々が脅かされる。トラブルにはそういう心理的側面がある。この心理状態が悪化すると鬱病になる。だからトラブルを「自然」と理解することは精神衛生上もよい。
起きてしまったことはしかたがないのである。怒ろうが泣こうが喚こうが取り消されるものではない。鬱病になってトラブルが解消するはずがない。だったら前向きに対応するほかはないではないか。どうせなら笑顔で対応してやろう。まだまだトラブルは出てくる。実にトラブルに終わりというものはないのだ。
プロジェクトは過去の積み重ねに他ならない。トラブルとは過去の積み重ねの否定である。すなわちトラブルはプロジェクトの（少なくとも部分的な）否定である。過去の積み重ねとして定義されたプロジェクトには、人間の活動全般が含まれる。すなわち人々がプロジェクトを過ごした時間そのものが、またプロジェクトには含まれている。
過去は過ぎ去ったものである。ゆえにもはや存在しない。存在するのは現在のみである。過去は例えば仕様書や議事録、記憶という形で残って「いる」。その過去によって現在の我々が脅かされる。トラブルにはそういう心理的側面がある。この心理状態が悪化すると鬱病になる。だからトラブルを「自然」と理解することは精神衛生上もよい。
起きてしまったことはしかたがないのである。怒ろうが泣こうが喚こうが取り消されるものではない。鬱病になってトラブルが解消するはずがない。だったら前向きに対応するほかはないではないか。どうせなら笑顔で対応してやろう。まだまだトラブルは出てくる。実にトラブルに終わりというものはないのだ。
2008年8月13日水曜日
テストの難しさ
最近システムトラブルを起こした会社がバッシングされることが多いです。
人のミスをあげつらうのはあまり趣味のいいこととは思えませんね。それから、プロとしてはあまり大きな声では言えないのですが「おいおいシステム作るのってそんな簡単じゃねーんだよ。分かってるのかね」とも思ってしまいます。
だからそれを何とかするのがプロだろ？システム屋だろ？と言われると悔しいのですが。
一応反論してみましょう。
例えばコーディング。簡単な仕事ではありません。ウソだと思うならAjaxで何か組んで見てください。JavaやPHPでWeb掲示板でも作って見てください。なかなか簡単には作れないものです。
最近プログラマがの売値が安いですが、その結果優秀なプログラマが減っているような気がしてなりません。実際にモノを作るのはプログラマなのに。（というかプログラマに限らずよい人材が減ってる？）
自動でコードを生成するツールもありますが、そのツールを操作／設定するのも簡単ではないですし、そもそもプログラミングの知識が前提されている場合が多いのです。
システムのテストが難しいことは理論的にも説明できます。
例えば５つのメソッドを持つプログラムが一つあるとします。
それらのメソッドはそれぞれ４個のif文を含むとします。
するとif文の数は20個。if分岐のテストに関して言えば、2の20乗＝100万以上の選択肢が存在するのです。
さらにそのプログラムに20個の変数が存在するとします。そしてその変数が、それぞれ4つの値を取る可能性があるとしましょう。言い換えると、それぞれが0,1,2,3いずれかの値を持つとします。
すると、変数の組み合わせは20の4乗＝16万ケースが考えられます。
次に変数の組み合わせとif文の組み合わせです。変数の組み合わせ一つに対して、100万以上のif文組み合わせがあるので、可能性としては1700億弱のテストケースが存在します。
一ケーステストを行うのに２ミリ秒（2/1000秒）掛かるとしても、970日ぶっ通しでテストする必要があります。
それに変数の状態が4通りしかないことは普通あり得ません。例えばint型だって4億以上のパターンありますらかね。
つまり簡単なプログラムですら完ぺきにテストすることは不可能なのです。
そしてプログラマはほとんど無限といってもいいテストの可能性からいくつかを選び、テストしなければならないのです。
最近、この業界で長く仕事をしているはずの偉い人たちですら「試験は全パス通します」などと軽々しく言うことが多い気がします。だからムリだって。
まあ、大抵の場合、偉い人たちが考えているのは順列組み合わせではなくてif文個別に見てその両方の分岐を通す程度なのですが。（つまり20個のif文で40ケース）
それにしても、昨今システムに関する無理解が進んでいるような気がしてならないのは私だけでしょうか。
人のミスをあげつらうのはあまり趣味のいいこととは思えませんね。それから、プロとしてはあまり大きな声では言えないのですが「おいおいシステム作るのってそんな簡単じゃねーんだよ。分かってるのかね」とも思ってしまいます。
だからそれを何とかするのがプロだろ？システム屋だろ？と言われると悔しいのですが。
一応反論してみましょう。
例えばコーディング。簡単な仕事ではありません。ウソだと思うならAjaxで何か組んで見てください。JavaやPHPでWeb掲示板でも作って見てください。なかなか簡単には作れないものです。
最近プログラマがの売値が安いですが、その結果優秀なプログラマが減っているような気がしてなりません。実際にモノを作るのはプログラマなのに。（というかプログラマに限らずよい人材が減ってる？）
自動でコードを生成するツールもありますが、そのツールを操作／設定するのも簡単ではないですし、そもそもプログラミングの知識が前提されている場合が多いのです。
システムのテストが難しいことは理論的にも説明できます。
例えば５つのメソッドを持つプログラムが一つあるとします。
それらのメソッドはそれぞれ４個のif文を含むとします。
するとif文の数は20個。if分岐のテストに関して言えば、2の20乗＝100万以上の選択肢が存在するのです。
さらにそのプログラムに20個の変数が存在するとします。そしてその変数が、それぞれ4つの値を取る可能性があるとしましょう。言い換えると、それぞれが0,1,2,3いずれかの値を持つとします。
すると、変数の組み合わせは20の4乗＝16万ケースが考えられます。
次に変数の組み合わせとif文の組み合わせです。変数の組み合わせ一つに対して、100万以上のif文組み合わせがあるので、可能性としては1700億弱のテストケースが存在します。
一ケーステストを行うのに２ミリ秒（2/1000秒）掛かるとしても、970日ぶっ通しでテストする必要があります。
それに変数の状態が4通りしかないことは普通あり得ません。例えばint型だって4億以上のパターンありますらかね。
つまり簡単なプログラムですら完ぺきにテストすることは不可能なのです。
そしてプログラマはほとんど無限といってもいいテストの可能性からいくつかを選び、テストしなければならないのです。
最近、この業界で長く仕事をしているはずの偉い人たちですら「試験は全パス通します」などと軽々しく言うことが多い気がします。だからムリだって。
まあ、大抵の場合、偉い人たちが考えているのは順列組み合わせではなくてif文個別に見てその両方の分岐を通す程度なのですが。（つまり20個のif文で40ケース）
それにしても、昨今システムに関する無理解が進んでいるような気がしてならないのは私だけでしょうか。
AbstractWizardFormController（以下AWFC）で中間のページをスキップする方法
例えば以下のような処理があったとします。
何らかの項目を、複数ページに渡って選択しながら削除する処理です。
１．条件抽出
２．表示・選択
３．詳細確認
４．削除
こういう時SpringではAWFCを使います。
でも３の詳細確認をスキップしたいケースもままあるでしょう。別に詳細を見たくない。そのまま削除しちゃいたい。
運のいい人は単に２つ目の画面でtype="submit" name="_finish"すれば出来てしまいますが（どういう人が運がいいかは後述）、ハマってしまうとややこしいことになります。
以下の投稿者はハマってしまった人のようです。AWFCのいくつかのメソッドをオーバーライドしてスキップさせるように作りこんだそうです。
Skip to _finish in a AbstractWizardFormController
しかし_finishまで処理を飛ばすもっと簡単な方法があります。
それは全てのBean(=command)に対応する全ての項目を、_finishにスキップさせるページにhiddenか何かで埋め込んでおくことです。
どうやらAWFCは、Bean(=command)に含まれている全ての項目が画面経由で埋められていないと、次に進ませてくれないようなのです。
（AWFC内部のチェックで引っかかり、強制的にshowFormでカレントのページに戻されてしまう）
逆を言えば、Bean(=command)の項目を無害な値で埋めてしまい、_finishで無視すればよい、それだけのことでした。
以上。
何らかの項目を、複数ページに渡って選択しながら削除する処理です。
１．条件抽出
２．表示・選択
３．詳細確認
４．削除
こういう時SpringではAWFCを使います。
でも３の詳細確認をスキップしたいケースもままあるでしょう。別に詳細を見たくない。そのまま削除しちゃいたい。
運のいい人は単に２つ目の画面でtype="submit" name="_finish"すれば出来てしまいますが（どういう人が運がいいかは後述）、ハマってしまうとややこしいことになります。
以下の投稿者はハマってしまった人のようです。AWFCのいくつかのメソッドをオーバーライドしてスキップさせるように作りこんだそうです。
Skip to _finish in a AbstractWizardFormController
しかし_finishまで処理を飛ばすもっと簡単な方法があります。
それは全てのBean(=command)に対応する全ての項目を、_finishにスキップさせるページにhiddenか何かで埋め込んでおくことです。
どうやらAWFCは、Bean(=command)に含まれている全ての項目が画面経由で埋められていないと、次に進ませてくれないようなのです。
（AWFC内部のチェックで引っかかり、強制的にshowFormでカレントのページに戻されてしまう）
逆を言えば、Bean(=command)の項目を無害な値で埋めてしまい、_finishで無視すればよい、それだけのことでした。
以上。
トラブルに対応するためにはどうするか（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】
まずはトラブルをそのまま受け入れることである。起こってしまったことは仕方がない。過去を取り消すことはできない。その上で再発防止策を含めて前向きに検討すればよい。
しかしそのまま受け入れることが意外と難しい。自分は我慢できたとして上司（あるいは顧客）は我慢しない。現場を知らないとその傾向は強まる。そういう上司（顧客）からたまには怒られることになる。因果なもので怒りは伝染する傾向がある。結局トラブルが発生したらなかなか冷静ではいられない。しかしそこは何とかするしかない。怒りや不安はトラブル対応には役に立たないのだから。
まずは冷静になること。問題の影響を正確に把握すること。次に事実と推論と意見を区別すること。希望観測が確信に変わってしまう人がいる。経験の少ない人に多い傾向である。誤った前提は非常に危険である。仮説と事実は明確に区別されねばならない。ここで初めて因果関係の適用を検討する。時系列で整理しどの事象が原因たりうるのか検討するのである。また原因から逆に影響を見直してみることにも意味がある。ウォーターフォール型の開発方法論を適用するとすれば適切なフェーズで出たトラブルなのか評価しておくのは有効である。
因果関係の適用は慎重にする必要がある。事象の発生を時系列で並べた時の直前のアクションが直接的な原因である。しかしそれには大抵意味がない。バグの直接原因はコーディングミスである。しかしその背景には様々な要因が考えられる。例えば仕様が甘い、コミュニケーションが取られていない、スケジュールが厳しすぎる、などなど。
ただし原因を抽象化し過ぎたり、時系列をさかのぼり過ぎるのも良くない。バグの根本原因はプロジェクトが開始してしまったことにある。そもそもこのプロジェクトはスタートするべきではなかった。おそらくは正しい仮説である。それでどうするか。社長に直訴するか。辞表を書くか。前向きなアクションには結び付かない。有効なアクションが取り得ない原因は良い原因ではない。それに対して良いアクションが取れるものこそが真の原因なのである。もちろん有効な真の原因が存在しない場合がある。例えば時間が足りない。繰り返しミスをする人間がいる（しかも他に人がいないためクビにできない）。昨今のコンプライアンスやら個人情報保護事情でインターネットやメール環境から遮断されたプロジェクトである。これらが原因ではどうしようもない。諦めるしかない。無論代替策は検討する。しかし根本的には諦める他はない。般若心経に「転倒」という言葉が出てくる。「あべこべ」という意味らしい。障害は起こるが障害が発生してはならない。出来ないのだが、出来なければならない。転倒とはこういう思い込みを指すのであろう。そんなことを思うから変なことになるのである。遠離一切転倒夢想が望ましい。
出来ないものを何とかしようとするから苦しいのである。始めから割り切ってしまえば苦しくも何ともない。そういうものだ、と受け入れればよいのである。受け入れた上で次善の策を検討する。そうするしかないではないか。「出来ない目標が掲げられても、一歩でもそれに近づくように努力するのが大事」という考えがある。正しい実践だと思う。ただしそれはあくまで本業に対して設定すべき目標である。本質的ではないところであがくのは時間の無駄である。
真の原因を設定するにあたり、プロジェクト運営の目的は何かを明確にしておく必要がある。これはまた手段の目的化を避けるためにも重要である。大抵のプロジェクトの目的は「良いシステムを作ること」であろう。だから「良いシステムを作るためには何をすべきか」が常に問われなければならない。トラブル発生時も同じである。良いシステムを作るためにはこのトラブルをどう解釈すべきか。淡々と直せば済むのか。それともその裏にプロジェクトの目的を妨げるような大きな問題があるのか。プロジェクト全体で対応する必要はないのか。
だが真の原因分析に時間を掛けすぎることもよくないし、些細な問題をおおごとにしてしまうのも結局効率がよくない。例えば仕様書のあいまいな記載に由来する障害で、真の原因は仕様書だ、と結論付けたとする。これは「過度の抽象化」という分析失敗例でもある。ここから仕様書のあいまいな点を全て洗い出す、という悲惨なタスクを考え出してしまう自己破壊的・プロジェクト破壊的な人が存在するのだ。大抵のプロジェクトではその作業対象は膨大であろうし、作業スコープも完了基準もあいまいになるであろう。結果、却ってプロジェクトの遅延を引き起こし、品質の低下を産みかねないのである。現実的に対応可能な効率的な作業によって対応できることまで見極めた上で、原因の分析を行う必要がある。要するに具体的な作業をあいまいさなしに定義するのである。ダブルチェックしてもミスは完全にはなくならない。それを知っておく必要もあるだろう。さもなければ後で「なぜチェックしたのにまたトラブルが起こるのだ」と無駄な負の感情が生まれる。
どの設定ファイル、プログラムを、この観点でこう調査する。「全ての」対象に波及させてはならない。「全てのプログラムで確認する」。件数によっては可能かもしれない。しかし、対象が膨大であれば、目視確認は諦めてプログラムに自動チェックさせてもよい。あるいはいっそ事前チェックによる洗い出しはあきらめ、テストしてしまうことを検討した方がよい。
観点をあいまいにしてはならない。「プログラムミスがないことを確認する」。これでは確認しようがない。どのようなミスなのかポイントを絞る必要がある。例えば「データベースリソースの開放忘れがないこと」。またチェック手順（どのようなキーワードで作業対象を検索し、どのポイントを見るのか）まで見極めておく。そして重要なのはそれでもなおトラブルが発生し得る、と認識することである。トラブルが起こってはならない。意識はそう思いがちであるが、それは精神衛生上良くない思い込みである。「トラブルが起きない方が望ましい。しかし大きなトラブルがいつでも発生しうる」が正しい。覚悟という言葉を聞かなくなった。トラブルは許されない。失敗は許されない。その裏にあるのは実は逃避なのではないか。「デッドライン」のデマルコが正しい。プロジェクトは腹を決めて運営するものなのである。
知ることはガンの告知だ、知る前と後では世界のあり方が変わってしまう。養老孟司氏の至言である。トラブルもまた同じである。これまでの想定が通用しなくなる。仕様書が変わりプログラムが変わりテストが変わり運用が変わる。トラブルが起こるのが自然ならば、それを受けて変更が発生するのもまた自然である。それを受け入れたらプロジェクトマネジメントが成立しないではないか。そんなことはない。要は考え方である。トラブルはあってはならない、と決めつけるのではなくトラブルは起こりえる、と認識することである。リスク管理もそこからしか始まらないではないか。トラブルにどう立ち向かうかが問われている。「トラブルなどあってはならない」という思いは単なる現実逃避である。
トラブルは許されないという思い込みからは「（トラブルを）なかったことにしたい」あるいは「出してはならない」という誤った衝動が生まれる。そしてトラブルを出さないように強く現場に圧力をかけることになる。トラブルをだすな、というプレッシャーはトラブルを隠す負のインセンティブとなる。現場のトラブル隠しがどのような結果を生むか。ここで敢えて述べる必要もないだろう。
まずはトラブルをそのまま受け入れることである。起こってしまったことは仕方がない。過去を取り消すことはできない。その上で再発防止策を含めて前向きに検討すればよい。
しかしそのまま受け入れることが意外と難しい。自分は我慢できたとして上司（あるいは顧客）は我慢しない。現場を知らないとその傾向は強まる。そういう上司（顧客）からたまには怒られることになる。因果なもので怒りは伝染する傾向がある。結局トラブルが発生したらなかなか冷静ではいられない。しかしそこは何とかするしかない。怒りや不安はトラブル対応には役に立たないのだから。
まずは冷静になること。問題の影響を正確に把握すること。次に事実と推論と意見を区別すること。希望観測が確信に変わってしまう人がいる。経験の少ない人に多い傾向である。誤った前提は非常に危険である。仮説と事実は明確に区別されねばならない。ここで初めて因果関係の適用を検討する。時系列で整理しどの事象が原因たりうるのか検討するのである。また原因から逆に影響を見直してみることにも意味がある。ウォーターフォール型の開発方法論を適用するとすれば適切なフェーズで出たトラブルなのか評価しておくのは有効である。
因果関係の適用は慎重にする必要がある。事象の発生を時系列で並べた時の直前のアクションが直接的な原因である。しかしそれには大抵意味がない。バグの直接原因はコーディングミスである。しかしその背景には様々な要因が考えられる。例えば仕様が甘い、コミュニケーションが取られていない、スケジュールが厳しすぎる、などなど。
ただし原因を抽象化し過ぎたり、時系列をさかのぼり過ぎるのも良くない。バグの根本原因はプロジェクトが開始してしまったことにある。そもそもこのプロジェクトはスタートするべきではなかった。おそらくは正しい仮説である。それでどうするか。社長に直訴するか。辞表を書くか。前向きなアクションには結び付かない。有効なアクションが取り得ない原因は良い原因ではない。それに対して良いアクションが取れるものこそが真の原因なのである。もちろん有効な真の原因が存在しない場合がある。例えば時間が足りない。繰り返しミスをする人間がいる（しかも他に人がいないためクビにできない）。昨今のコンプライアンスやら個人情報保護事情でインターネットやメール環境から遮断されたプロジェクトである。これらが原因ではどうしようもない。諦めるしかない。無論代替策は検討する。しかし根本的には諦める他はない。般若心経に「転倒」という言葉が出てくる。「あべこべ」という意味らしい。障害は起こるが障害が発生してはならない。出来ないのだが、出来なければならない。転倒とはこういう思い込みを指すのであろう。そんなことを思うから変なことになるのである。遠離一切転倒夢想が望ましい。
出来ないものを何とかしようとするから苦しいのである。始めから割り切ってしまえば苦しくも何ともない。そういうものだ、と受け入れればよいのである。受け入れた上で次善の策を検討する。そうするしかないではないか。「出来ない目標が掲げられても、一歩でもそれに近づくように努力するのが大事」という考えがある。正しい実践だと思う。ただしそれはあくまで本業に対して設定すべき目標である。本質的ではないところであがくのは時間の無駄である。
真の原因を設定するにあたり、プロジェクト運営の目的は何かを明確にしておく必要がある。これはまた手段の目的化を避けるためにも重要である。大抵のプロジェクトの目的は「良いシステムを作ること」であろう。だから「良いシステムを作るためには何をすべきか」が常に問われなければならない。トラブル発生時も同じである。良いシステムを作るためにはこのトラブルをどう解釈すべきか。淡々と直せば済むのか。それともその裏にプロジェクトの目的を妨げるような大きな問題があるのか。プロジェクト全体で対応する必要はないのか。
だが真の原因分析に時間を掛けすぎることもよくないし、些細な問題をおおごとにしてしまうのも結局効率がよくない。例えば仕様書のあいまいな記載に由来する障害で、真の原因は仕様書だ、と結論付けたとする。これは「過度の抽象化」という分析失敗例でもある。ここから仕様書のあいまいな点を全て洗い出す、という悲惨なタスクを考え出してしまう自己破壊的・プロジェクト破壊的な人が存在するのだ。大抵のプロジェクトではその作業対象は膨大であろうし、作業スコープも完了基準もあいまいになるであろう。結果、却ってプロジェクトの遅延を引き起こし、品質の低下を産みかねないのである。現実的に対応可能な効率的な作業によって対応できることまで見極めた上で、原因の分析を行う必要がある。要するに具体的な作業をあいまいさなしに定義するのである。ダブルチェックしてもミスは完全にはなくならない。それを知っておく必要もあるだろう。さもなければ後で「なぜチェックしたのにまたトラブルが起こるのだ」と無駄な負の感情が生まれる。
どの設定ファイル、プログラムを、この観点でこう調査する。「全ての」対象に波及させてはならない。「全てのプログラムで確認する」。件数によっては可能かもしれない。しかし、対象が膨大であれば、目視確認は諦めてプログラムに自動チェックさせてもよい。あるいはいっそ事前チェックによる洗い出しはあきらめ、テストしてしまうことを検討した方がよい。
観点をあいまいにしてはならない。「プログラムミスがないことを確認する」。これでは確認しようがない。どのようなミスなのかポイントを絞る必要がある。例えば「データベースリソースの開放忘れがないこと」。またチェック手順（どのようなキーワードで作業対象を検索し、どのポイントを見るのか）まで見極めておく。そして重要なのはそれでもなおトラブルが発生し得る、と認識することである。トラブルが起こってはならない。意識はそう思いがちであるが、それは精神衛生上良くない思い込みである。「トラブルが起きない方が望ましい。しかし大きなトラブルがいつでも発生しうる」が正しい。覚悟という言葉を聞かなくなった。トラブルは許されない。失敗は許されない。その裏にあるのは実は逃避なのではないか。「デッドライン」のデマルコが正しい。プロジェクトは腹を決めて運営するものなのである。
知ることはガンの告知だ、知る前と後では世界のあり方が変わってしまう。養老孟司氏の至言である。トラブルもまた同じである。これまでの想定が通用しなくなる。仕様書が変わりプログラムが変わりテストが変わり運用が変わる。トラブルが起こるのが自然ならば、それを受けて変更が発生するのもまた自然である。それを受け入れたらプロジェクトマネジメントが成立しないではないか。そんなことはない。要は考え方である。トラブルはあってはならない、と決めつけるのではなくトラブルは起こりえる、と認識することである。リスク管理もそこからしか始まらないではないか。トラブルにどう立ち向かうかが問われている。「トラブルなどあってはならない」という思いは単なる現実逃避である。
トラブルは許されないという思い込みからは「（トラブルを）なかったことにしたい」あるいは「出してはならない」という誤った衝動が生まれる。そしてトラブルを出さないように強く現場に圧力をかけることになる。トラブルをだすな、というプレッシャーはトラブルを隠す負のインセンティブとなる。現場のトラブル隠しがどのような結果を生むか。ここで敢えて述べる必要もないだろう。
2008年8月12日火曜日
意識と自然 ～ 原因と結果は存在しない（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】
自然の大雑把な定義が終わった。プロジェクトで発生する意識にとって好ましくない事象を自然と定義したわけである。次に出てくるのは意識の定義である。これについて正面から立ち向かうのは大変である。しかしここではプロジェクトの観点から意識を捉えることにして無理やり話を簡単にする。
これまでの文脈より、意識はまず「自然と対立するもの」と定義できる。発生した障害に対して、意識は感覚的には不快感を覚える。そして理解しようとする。文脈を整理し、因果関係を調べ、原因を究明する。そして障害への対応を行う。すなわち意識には以下の作用がある。
・トラブル（障害含む）に対する強い負の重み付け（障害は不快である）
・現在のトラブル対応への強い志向（不快であるが故に済ませてしまいたい）
・将来のトラブル対応への強い志向（今後あってはならない）
・政治的な関係に対する強い志向
また、意識には以下の機能がある
・抽象化能力
・因果関係適用能力
・論理的能力（推論、ロジック組み立て能力）
・その他重み付け能力（正しい美しい） などなど
意識の能力にはさまざまであるが、ここでは特に抽象化能力と因果関係適用能力に注目する。両者をもう少し噛み砕いて説明する。前者の代表的なものは異なったものを「同じ」と判断する能力である。後者は「ああしたからこうなった。すなわち、ああすればこうなる」と文脈を判断し予測する能力である。抽象化能力はプロジェクト状況把握の基礎となり、因果関係適用能力はプロジェクトをコントロールする際の基礎となる。
ここで因果関係適用能力について補足する。原因と結果は頭の中にしかないんだ、と話すと理系の人間（に限らないのかもしれないが）は大抵きょとんとしている。存在すると思っているのであろう。そういう人間に「だったら原因と結果を取り出して見せてくれ」とまでは言わない。そういう意地悪をしていると、だんだん相手にされなくなるからである。
原因も結果も実体として存在するものではない。だとすればどこにあるか。頭の中である。つまり原因も結果も概念でしかない。概念は現実に存在するものではない。ゆえに原因も結果も存在しない。明らかである。そう思えない人は原因と結果に強い実在感を持っている、それだけのことである。確かに原因と結果は重要な概念である。これがなければ意識的な日常生活は立ち行かない。働いているから給料がもらえている。それを信じているから今日もまた嫌々ながらも仕事に行く。
話はそれるがこの手の議論にはいろいろなバリエーションがある。例えば「会社」の存在である。筆者が最初に就職した会社で、新人研修があった。その場で常務から「会社なんてもんは存在しない。君たち一人一人が会社なんだ」という話があり、非常に納得した記憶がある。だがそれが気の利いた訓示足り得るということは、会社に強い実在感を抱いている人も多いということであろう。あるいは「国家」が存在するのか。国家公務員にとっては間違いなく存在すると思われる。だが普通社会で生活している人はあまり「国家」を意識しないであろう。存在を疑うまでは行かないであろうが。一般的には、国家は例えば総理大臣であったり国会であったり税務署であったり、ある具体的な対象であって決して何らかの実体として存在しているものではないはずである。実は言葉上は存在している対象が、実際には五感で感じることができない、といったことが非常に多い。例えば「猫」だってそうである。あの猫、この猫は存在するが単なる「猫」は存在しない。「猫」もまた意識の抽象の結果なのである。
あの猫、この猫を抽象化して猫というカテゴリーに入れ込む。これは意識の「同じ」と判断する能力によって可能となっている。これについて少々補足する（興味ある方は養老孟司氏の本を読まれた方が話が早い。例えば「無思想の発見」（ちくま新書））。例えばOSがある。Windows、UNIXさまざまなOSがある。OSによって、その機能は異なるが実際に関わる人以外は「要はOSだろ」と言うことができる。「同じだ」と。Windowsにも種類があるし、UNIXにも種類がある。HP-UX、AIX、Soralis、そしてLinuxがあり、Linuxにも種類がある。だが、どれも「要はUNIXなんだろ。だったら同じだ」と言うことができるのである。抽象化することによって理解と判断が早くなる。Soralisに精通した人であればその他のUNIX系OSの学習も早いはずである。「同じ」を出発点としてアナロジー（「似ている」）によって理解を進められるからである。
閑話休題。
以上からプロジェクトにおける意識と自然を整理するとこうなる。
意識
成功への正の重み付けと非成功への負の重み付け、ならびにツール（抽象化能力、因果関係整理能力など）を持つもの
自然
意識の活動から必然的に生まれる事象で意識が負の重み付けをしているもの。
ここで一旦われわれ「人間」に戻ってみよう。意識にとって好ましくない事象を引き起こすのは自然な人間の行為である。つまりここで意識と自然という二元論は人間という要素に一元化される。人間は意識であり、かつ自然である。プロジェクトを回すのは人間。ということはプロジェクトは結局人の活動であり問題は人が引き起こすものである。要するに人間のすることだろ。上手く行くかどうかは人次第。トラブルに関して言っても、要するに人が何かやってうまく行かないことに、腹を立てている、とこうなる。そうなれば話は簡単で腹を立てなければよいのである。トラブルが発生しても粛々と対応すればよい。うまく行っている時は腹も立たない。それだけの話である。
それを大騒ぎするから体力がかかってしょうがない。はじめから腹を立てなければ話は早いのである。完全にコントロールできると思わなければ諦めもつく。そうすれば無力感だって生じない。
自然の大雑把な定義が終わった。プロジェクトで発生する意識にとって好ましくない事象を自然と定義したわけである。次に出てくるのは意識の定義である。これについて正面から立ち向かうのは大変である。しかしここではプロジェクトの観点から意識を捉えることにして無理やり話を簡単にする。
これまでの文脈より、意識はまず「自然と対立するもの」と定義できる。発生した障害に対して、意識は感覚的には不快感を覚える。そして理解しようとする。文脈を整理し、因果関係を調べ、原因を究明する。そして障害への対応を行う。すなわち意識には以下の作用がある。
・トラブル（障害含む）に対する強い負の重み付け（障害は不快である）
・現在のトラブル対応への強い志向（不快であるが故に済ませてしまいたい）
・将来のトラブル対応への強い志向（今後あってはならない）
・政治的な関係に対する強い志向
また、意識には以下の機能がある
・抽象化能力
・因果関係適用能力
・論理的能力（推論、ロジック組み立て能力）
・その他重み付け能力（正しい美しい） などなど
意識の能力にはさまざまであるが、ここでは特に抽象化能力と因果関係適用能力に注目する。両者をもう少し噛み砕いて説明する。前者の代表的なものは異なったものを「同じ」と判断する能力である。後者は「ああしたからこうなった。すなわち、ああすればこうなる」と文脈を判断し予測する能力である。抽象化能力はプロジェクト状況把握の基礎となり、因果関係適用能力はプロジェクトをコントロールする際の基礎となる。
ここで因果関係適用能力について補足する。原因と結果は頭の中にしかないんだ、と話すと理系の人間（に限らないのかもしれないが）は大抵きょとんとしている。存在すると思っているのであろう。そういう人間に「だったら原因と結果を取り出して見せてくれ」とまでは言わない。そういう意地悪をしていると、だんだん相手にされなくなるからである。
原因も結果も実体として存在するものではない。だとすればどこにあるか。頭の中である。つまり原因も結果も概念でしかない。概念は現実に存在するものではない。ゆえに原因も結果も存在しない。明らかである。そう思えない人は原因と結果に強い実在感を持っている、それだけのことである。確かに原因と結果は重要な概念である。これがなければ意識的な日常生活は立ち行かない。働いているから給料がもらえている。それを信じているから今日もまた嫌々ながらも仕事に行く。
話はそれるがこの手の議論にはいろいろなバリエーションがある。例えば「会社」の存在である。筆者が最初に就職した会社で、新人研修があった。その場で常務から「会社なんてもんは存在しない。君たち一人一人が会社なんだ」という話があり、非常に納得した記憶がある。だがそれが気の利いた訓示足り得るということは、会社に強い実在感を抱いている人も多いということであろう。あるいは「国家」が存在するのか。国家公務員にとっては間違いなく存在すると思われる。だが普通社会で生活している人はあまり「国家」を意識しないであろう。存在を疑うまでは行かないであろうが。一般的には、国家は例えば総理大臣であったり国会であったり税務署であったり、ある具体的な対象であって決して何らかの実体として存在しているものではないはずである。実は言葉上は存在している対象が、実際には五感で感じることができない、といったことが非常に多い。例えば「猫」だってそうである。あの猫、この猫は存在するが単なる「猫」は存在しない。「猫」もまた意識の抽象の結果なのである。
あの猫、この猫を抽象化して猫というカテゴリーに入れ込む。これは意識の「同じ」と判断する能力によって可能となっている。これについて少々補足する（興味ある方は養老孟司氏の本を読まれた方が話が早い。例えば「無思想の発見」（ちくま新書））。例えばOSがある。Windows、UNIXさまざまなOSがある。OSによって、その機能は異なるが実際に関わる人以外は「要はOSだろ」と言うことができる。「同じだ」と。Windowsにも種類があるし、UNIXにも種類がある。HP-UX、AIX、Soralis、そしてLinuxがあり、Linuxにも種類がある。だが、どれも「要はUNIXなんだろ。だったら同じだ」と言うことができるのである。抽象化することによって理解と判断が早くなる。Soralisに精通した人であればその他のUNIX系OSの学習も早いはずである。「同じ」を出発点としてアナロジー（「似ている」）によって理解を進められるからである。
閑話休題。
以上からプロジェクトにおける意識と自然を整理するとこうなる。
意識
成功への正の重み付けと非成功への負の重み付け、ならびにツール（抽象化能力、因果関係整理能力など）を持つもの
自然
意識の活動から必然的に生まれる事象で意識が負の重み付けをしているもの。
ここで一旦われわれ「人間」に戻ってみよう。意識にとって好ましくない事象を引き起こすのは自然な人間の行為である。つまりここで意識と自然という二元論は人間という要素に一元化される。人間は意識であり、かつ自然である。プロジェクトを回すのは人間。ということはプロジェクトは結局人の活動であり問題は人が引き起こすものである。要するに人間のすることだろ。上手く行くかどうかは人次第。トラブルに関して言っても、要するに人が何かやってうまく行かないことに、腹を立てている、とこうなる。そうなれば話は簡単で腹を立てなければよいのである。トラブルが発生しても粛々と対応すればよい。うまく行っている時は腹も立たない。それだけの話である。
それを大騒ぎするから体力がかかってしょうがない。はじめから腹を立てなければ話は早いのである。完全にコントロールできると思わなければ諦めもつく。そうすれば無力感だって生じない。
2008年8月11日月曜日
プロジェクトの中の意識と自然（プロジェクトの人間学)
【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】
何かを二つに分けて理解しようとする。例えば人という存在を意識（脳）と自然、あるいは脳と身体に分ける。これを二元論という。
二元論は便利である。なぜなら分けることは判断することであり、また理解することだから。分ける、とは分類する、つまり差異化することである。赤を赤と薄い赤に分ける。そして薄い赤をピンクと名づける。これによってピンクという質を理解する。これが意識が「理解」する方法である。すなわち意識が世界を理解する機能は二元的に働く。意識は対象を分けることで世界を再構築している。だから二元論は分かりやすい。デカルトも精神の世界と物質の世界を分けて考えてキリスト教と物理科学を共存させることができた。二元論は実に使える理論なのである。
プロジェクトを「意識と自然」という枠組みで把握してみよう。プロジェクトは人間が運営する。そして徹底的にリスクや偶然が嫌われる。その意味ではプロジェクトは極めて「意識的」なものである。すなわち事象は理解され、コントロールされなければならない。それが顕著なのがいわゆる「マネジメント」「えらい人たち」レイヤである。ではプロジェクトの現場レイヤはどうか。無論現場も同じ。事象や進捗のコントロールが志向され、リスクは排除しようとする。しかし２つのレイヤには決定的に違うポイントがある。それはありていに言ってしまえば無力感である。現場レイヤではしばしばコントロール不能状態になる。どうしようもない、しようがない、しかたない、そうとしか言いようのない事態が起きる。
属人的理由から発生するミス。やるべきことはやっていたにも関わらず発生する手戻り作業。起きることは分かっていた。しかし何も手を打てなかった無力感。やるべきことはやっていたにも関わらず発生してしまったという無力感。
無力感の多寡こそが現場とマネジメント層を分ける一つの指標に違いない。なぜならマネジメント層に伝わる情報にはほとんど無力感などは含まれてはいないだろうから。そしてマネジメントの仕事はもっぱら解釈であって現実との衝突ではないから。
この無力感の源はどのプロジェクトでも発生する障害、作業ミス、トラブル、コミュニケーション不全、予定外作業などなどである。意識にとっては受け入れがたいこれらの事象をなんと呼ぶか。この本ではこれを自然と呼ぶことにする。つまり自ずから然あるのがトラブルである。放っておけばそう成る。だから自然である。人が集まって何か働く。すると秩序なり製品が生まれ、それと同時に無秩序と廃棄物が生まれる。これをエントロピーが増大すると表現してもよい。要するにトラブルは自然にかつ必然的に発生する。
土地を放っておけば雑草が生える。それが気に入らないなら方法が２つある。一つはアスファルトで覆ってしまうこと。もう一つは手入れをすること。残念ながらプロジェクトをアスファルトで覆うことはできない。だから手入れをするしかない。しかし一般にはトラブル対応としてアスファルトで覆うようなラディカルな対応を行っていることが多い。行き過ぎたコントロールや数値化志向がそれである。ものには限度がある。行過ぎた対応はプロジェクトを破壊するか、強烈なオーバーヘッドを生むだけである。ある種のトラブルと共存するという発想も、必要なのではないか。冗談じゃない、失敗は許されない、そう言いたい気持ちも分かる。全ての失敗を許し、共存するとは言っていない。許されない失敗はある。その区別が重要である。あらゆる失敗が許されない、と考える人はここから先は読まないほうがよい。
何かを二つに分けて理解しようとする。例えば人という存在を意識（脳）と自然、あるいは脳と身体に分ける。これを二元論という。
二元論は便利である。なぜなら分けることは判断することであり、また理解することだから。分ける、とは分類する、つまり差異化することである。赤を赤と薄い赤に分ける。そして薄い赤をピンクと名づける。これによってピンクという質を理解する。これが意識が「理解」する方法である。すなわち意識が世界を理解する機能は二元的に働く。意識は対象を分けることで世界を再構築している。だから二元論は分かりやすい。デカルトも精神の世界と物質の世界を分けて考えてキリスト教と物理科学を共存させることができた。二元論は実に使える理論なのである。
プロジェクトを「意識と自然」という枠組みで把握してみよう。プロジェクトは人間が運営する。そして徹底的にリスクや偶然が嫌われる。その意味ではプロジェクトは極めて「意識的」なものである。すなわち事象は理解され、コントロールされなければならない。それが顕著なのがいわゆる「マネジメント」「えらい人たち」レイヤである。ではプロジェクトの現場レイヤはどうか。無論現場も同じ。事象や進捗のコントロールが志向され、リスクは排除しようとする。しかし２つのレイヤには決定的に違うポイントがある。それはありていに言ってしまえば無力感である。現場レイヤではしばしばコントロール不能状態になる。どうしようもない、しようがない、しかたない、そうとしか言いようのない事態が起きる。
属人的理由から発生するミス。やるべきことはやっていたにも関わらず発生する手戻り作業。起きることは分かっていた。しかし何も手を打てなかった無力感。やるべきことはやっていたにも関わらず発生してしまったという無力感。
無力感の多寡こそが現場とマネジメント層を分ける一つの指標に違いない。なぜならマネジメント層に伝わる情報にはほとんど無力感などは含まれてはいないだろうから。そしてマネジメントの仕事はもっぱら解釈であって現実との衝突ではないから。
この無力感の源はどのプロジェクトでも発生する障害、作業ミス、トラブル、コミュニケーション不全、予定外作業などなどである。意識にとっては受け入れがたいこれらの事象をなんと呼ぶか。この本ではこれを自然と呼ぶことにする。つまり自ずから然あるのがトラブルである。放っておけばそう成る。だから自然である。人が集まって何か働く。すると秩序なり製品が生まれ、それと同時に無秩序と廃棄物が生まれる。これをエントロピーが増大すると表現してもよい。要するにトラブルは自然にかつ必然的に発生する。
土地を放っておけば雑草が生える。それが気に入らないなら方法が２つある。一つはアスファルトで覆ってしまうこと。もう一つは手入れをすること。残念ながらプロジェクトをアスファルトで覆うことはできない。だから手入れをするしかない。しかし一般にはトラブル対応としてアスファルトで覆うようなラディカルな対応を行っていることが多い。行き過ぎたコントロールや数値化志向がそれである。ものには限度がある。行過ぎた対応はプロジェクトを破壊するか、強烈なオーバーヘッドを生むだけである。ある種のトラブルと共存するという発想も、必要なのではないか。冗談じゃない、失敗は許されない、そう言いたい気持ちも分かる。全ての失敗を許し、共存するとは言っていない。許されない失敗はある。その区別が重要である。あらゆる失敗が許されない、と考える人はここから先は読まないほうがよい。
登録:
投稿 (Atom)