プロジェクトの「ほんとう」を把握する（プロジェクトの人間学）

数字は単なる現象であり、プロジェクトの「ほんとう」ではない。それがしばしば「ほんとう」と解釈される。そして数字というむやみにリアリティがあるクオリアが「ほんとう」となってしまい、現実を数字から把握しようとする「あべこべ」が起こる。プロジェクト定量化の試みは「あべこべ」に他ならないのである。数字は現れの一つであり、本質ではない。現れとして重要ではあるが、数字を時系列でトラッキングしても「結果」としてのトラブルしか把握できない。「結果」として把握されたトラブルは、もはや「原因」を後付けする他はなく、既に起こってしまったものとしてトラブルはすでに「仕方がない」ものである。

【数字を元にしたプロジェクト分析での認識の流れ（時系列）】
数字　→　トラブル（事後）　→　原因（事後）　→　後付けのアクション（事後）

以下があるべき認識の流れである。

【あるべき認識の流れ】
（事前）トラブルの匂い　→　（事前）思い切ったアクション　→　（事前）トラブルの回避

あるべき流れには数字の入る余地がないことがよく分かるだろう。数字は気づく発端に過ぎない。しかも「過去」に気が付くだけである。また、意識は「数字に捕らわれ易い」という性質を持っているが故に非常にミスリードである。プロジェクトの「ほんとう」を把握するためには却って邪魔になりかねない。数字で構成された世界観が人間を圧迫する。これは物理学的世界観が現代の人間を圧迫しているのと同じ構造を持っている。

物理学的世界観で生きる人間が息苦しさを感じる。それは物理学的な世界は法則と計測でがんじがらめの世界だからである。数字と因果関係は実のところ単なるクオリアに過ぎない。しかしそれを無理やり自然に適用し、石油の力を借りて、脳の中の構造と因果関係を外に出して構造にしてしまった。それが都市であり、意識の作った世界である。ところが意識の作った世界は実は生き難い社会である。まず自然が破壊された結果、意識が素朴に把握できる「原因と結果」を超えた影響（例えば温暖化現象）を地球環境に与えている。今となっては「二酸化炭の排出が温暖化の原因である」という有力な仮説が成立しているが、これも「事後的な」原因分析に過ぎないことがお分かりだろう。また意識が世界をゆがめたおかげで子供たちにとって非常に息詰まる社会になってしまった。子供はまだ自然に近い存在だからである。

閑話休題

プロジェクト管理がプロジェクトのオーバーヘッドを増し、場合によってはプロジェクトを破綻させるのも同じ構造を持っている。数字が先にあり「こうあらねばならない！」とマネジメント層や顧客が叫ぶ。しかし実際には決してそうならないのだ。ただトラブルの隠蔽やプロジェクトの破綻が引き起こされるだけである。

プロジェクトの「ほんとう」を把握するのは事実上不可能に近い。たくさんの人間がそれぞれ情報を抱えて自らのパースペクティブからプロジェクト観を構成している。どれが正しいとか正しくないとか、そういうことは言えない。もちろん全員が合意できるラインは存在する。だがそれは厳密な意味での客観的事実の羅列に過ぎない。それは数値化され誰も否定できない実在感を帯びる。だがその数字は先に述べた通りプロジェクトの「ほんとう」を示すものではない。

各人がそれぞれのプロジェクトの「ほんとう」を持っていて、どれが正しいかは分からない。では全ては相対的なのか。それは違う。現実のプロジェクトを見れば分かる。そこでは最終的に「正しい」（「ほんとう」と「正しい」を区別していることに注意）のは常に顧客でありマネジメント層なのだ。「最終的に」というのが重要である。最初から最後まで彼らが正しいならメンバーは不要であろう。プロジェクトで発生する事象や情報を取りまとめプロジェクト観を構成する。彼らが事実上プロジェクトの「正しい」「公式見解」を発表する。必ずしも「ほんとう」ではない。むしろ彼らは政治的に「正しい」ことを求めている。

しかしこの政治的な「正しさ」はプロジェクトを*事前に*コントロールするためには役に立たない。それはすでに発生してしまった事象についての解釈でしかないからである。起きたことをきれいに解釈し、原因を明らかにし、きれいにレポーティングする。これによって結果を「正しく」解釈し、今後につなげることはできる。だがまさにこの事象の発生をコントロールできるものではない。マネジメント層の「正しさ」は常に事後的である。

なぜマネジメントが常に「正しい」か。理由は２つある。一つは情報が集まるから。情報は力である。情報をもっともよく知り得た人間にもっとも正しい判断ができる。それから権力と正しさは表裏一体だからである。強力な認識が正しい。「正しさ」にはそういう側面がある。ニーチェは「認識とは力への意志である」と説いた。ニーチェを引き合いに出すまでもなく「強い人間が正しい」というのはサラリーマンには理解しやすいはずである。多少の反感はあるにせよ、誰が敢えて社長の言葉に歯向かうであろうか。

「正しさ」と「ほんとう」の違いは、前者が事後的であるのに対し、後者が生き生きとした現在を対象としている点にある。プロジェクトの「ほんとう」はメンバーが今まさに設計し、メールし、会議し、あるいは雑談している、都度その場にある。それらは今、この瞬間は計測不能である。計測可能なのは過去だけである。今現在の事象はただ質的なものとして感じられる。だからプロジェクトの「ほんとう」は眼、耳、鼻で感じるものなのである。現場慣れしたサブリーダーやメンバーは、文字通りトラブルが近づく足音を聞き、その臭いをかぐのである。

コントロールできるものとコントロールできないもの（プロジェクトの人間学）

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

ちょっと長いがモンテーニュから引用する。

自分に選択の自由のないものについて、これは自分にとって善いとか悪いとか考えるとすれば、こんなに悪いことが身にふりかかったとか、こんなに善いことが失敗したとかいって、君は神々にたいして呟かずにはいないだろう。また他人がこの失敗や災難の責任者であるといって、またその嫌疑があるといって、人間を憎まずにはいないであろう。まったくこのようなことを重大視することによって我々は実に多くの不正を犯してしまうのである。しかるにもし我々が自分の自由になることのみを善いとか悪いとか判断するならば、神に罪を被せる理由もなく、人間にたいして敵の立場を取る理由ももはや残されていないのである

話はそれるが昨今のマスコミは人々の憎しみを煽ってばかりいるような気がする。われらが業界で発生するシステム障害叩き。公務員叩き。政治家叩き。相手の立場に対する理解が欠けていないか。単純な憎しみの二元論を展開するだけでは世の中が窮屈になるばかりである。モンテーニュは非常に優れた常識人である。マスコミにも世の中を変える他の方法があるのではないか。記事を売るにしても他の売り方があるのではないか。

閑話休題。

プロジェクトでも起こる事象を二つのものに区別することが可能である。すなわち自分がコントロールできるものとコントロールできないもの。この２つを区別することで２つの大きなメリットがある。一つは精神衛生上のもの。もう一つは効率である。

前者は要するに諦めがつく、ということである。頑張ったってどうしようもない。何もしてあげられることがない。カンボジアに地雷が埋まっていて毎年子供たちが犠牲になっている。見捨ててもいいのか！例え効率が悪くともできることはやるべきだ！ちょっとまて。いま筆者はプロジェクトの話をしているのだ。そこまで悲壮になることはない。プロジェクト運営が悪くで人が死ぬこともあるがそれはむしろ割り切るべきタスクを割り切らなかった、つまりプロジェクトのリストラに失敗したからである。また冒頭の引用にもある通り、諦めてしまえば他人の失敗を恨んだり、許せないと思うことも無くなる。すなわちトラブルに対処するのに無用なマイナス感情が無くなる。
後者については自分でコントロールできないタスクを割り切り、より有効な作業にリソースを割り当てることができる。たとえば他人が自分に関する悪口を言いふらしていたとして、それをいちいち訂正して周るよりも、なすべきこと正しいことを粛々と実行し、適宜正当な主張をすればよい。つまり自分のできる範囲のことを精一杯すればよい。自分で勝手に作業スコープを広げる必要はない。できる範囲でベストを尽くすのだ（ただし若い時は限界に挑戦してみること！）。

簡単に諦めがつかない状況もある。例えばマネジメント層や顧客の誤った意思決定。現場からはコントロールが難しい。ほとんど不可能と言ってもよい。マネジメントへ直訴するのが精一杯である。言いくるめられるのが関の山だが。

その場合でも意思決定後に自分のコントロール可能な範囲でタスクを切り直せばよい。マネジメント層の決定は抽象的である。現場が身動きも取れないほど具体的にタスクが定義されてしまうことはほとんどない。そこから何とか身を守って、具体的にタスクを定義しなおすのだ。やはり自分でコントロールできる範囲を明確にし、そこに注力するのが何事につけても効率がよい。

自分で決断して提案すること（プロジェクトの人間学）

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

提案力のない営業にほとんど存在価値はない。現状を説明する。さてどうしましょう。こんな会話をして顧客が怒らないのはエンジニアくらいだろう。顧客も結局エンジニアに意思決定を期待していないのだ。

現状こうです。課題はこれです。対応策は２つでそれぞれのメリットデメリットはこの通り。長期的視点からこの選択肢をお勧めします。

社会の一般常識からするとここまで提案できなければ、まともなSEとは言えないと筆者は考える。だって課題まで見えているのだから。課題が分かれば後はほとんど機械作業なのだ。営業は見えない課題まで発見し、顧客を説得せねばならない(もちろん接待で酒も飲まなければならない)。それに比べれば、まだ楽な話である。きちんと課題を定義しさえすればその課題は９割方解決したも同然なのだ。課題の定義を怠るのは思考停止に近い。

それにしても興味深いのは、頭がよいエンジニアでも自分で決断したり提案する能力に必ずしも恵まれている訳ではないということである。現状を整理する能力はある。筋道だって説明もできる。でも最後のセリフが「どうしましょうか」。「どうしたいの？どうあるべきなの？」と聞けばちゃんと答えが返ってくるから、別に考えていないわけではない。ただ決断を避けている。恐らく理由は二つある。一つは責任の回避である。もう一つが重み付け能力の弱さ。つまり、単に決められない。二つの同じ量が入った飼葉桶の前で飢えてしまうロバである。もっとも実際に飢えるのであれば決めるだろうが。

メンバーに責任を回避する傾向があるとすれば、リーダーに責任の一旦がある。責任はリーダがとる。それは正しい。だからといってリーダが１から１０まで判断する必要はない。リーダーもメンバーに任せてしまえばよいのだ。それが出来ない。なぜか。リーダーの仕事がなくなるからである。細かいところもリーダが意思決定しようとする。

リーダが細かいところを決定するのもあながち悪くはない。リーダが細かいレベルまで把握できるし、リスクもリーダが取ることができる。しかしその結果メンバが萎縮してしまうようなことがあると、プロジェクトの生産性が下がってしまう。そこは注意が必要である。

重み付けにはセンスが必要である。何を選択するか。最終的には直感に依存する。プロジェクトにおける意思決定でいちいち投資対効果を定量的に計測するわけには行かない。判断のリスク、将来性、美しさ、好みといった定性的な質から決めてしまわなければならない。何でもよいから重み付けの能力は重要である。意思決定とその結果が全てである。プロセスが長ければ長いほど、悪い結果が起きる。結果を恐れて決められないのは、事態を悪くしているだけである。

重み付けの能力は残念ながら一朝一夕には身に付かない。たとえば美しさなど直観的、感性的要素から意思決定できるかどうか。単なる好みで選択できるかどうか。できない人はできる人よりも、人生から多くの時間が失われる。

決断とは自己の肯定であり将来に対する覚悟である。それができない人はつまるところ自己が肯定できないか覚悟ができない人である。残念ながら、この定義は多くのエンジニアの個性に当てはまるような気がしてならない。

適正なコストと時間を掛けるべき大事な決断がある。だがコストも時間も掛けすぎないようにしなければならない。いつまで待ってもどれほど努力しても全ての情報は集まらない。当りの番号を知ってから宝くじを買うわけにはゆかない。どこかで決断しなければならないのだ。

二つの選択肢に差異が無ければないほど、その選択は難しくなる。この法則を逃れるためには二つの選択肢に差異がないことが分かった段階でサイコロに決めてもらうことである。冗談ではない。本気である。実際、本当にどうでもよい意思決定に30分も1時間も時間がかかりかねない。その反対に重要な意思決定がろくに議論もされずになされることがある。しかもたいていは将来に悪影響を及ぼすことになる。違いが大きいため決断しやすいのだ。例えばある管理タスクをやるかやらないかの意思決定。やらない、という意思決定が難しいことは先に述べた。その理由からの管理タスクが始まる可能性が高い。そして将来余計な体力が発生し、現場に混乱と不平が生まれることになる。最初に気が付くべきだったのだ。だが、このような重要なタスクがマネージャやリーダの思いつきでいとも簡単に決まってしまうことが多い。

重要な意思決定からの疎外感。これもまたエンジニアの提案能力を削いでいる要因なのである。

だがエンジニアがプロジェクトで主要な役割を演じるためには提案能力は不可欠である。状況を判断し、自身の確信に則って顧客に提案しなければならない。もちろん顧客の言うことにも耳を傾けなければならないのは言うまでもない。さもなければ単なる独善となり、信頼感の醸成どころではなくなる。

顧客との信頼関係が常に重要である（プロジェクトの人間学）

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

よいシステムとは顧客にとってのよいシステムである。もちろん開発者にとってよいシステムが顧客にとってもよいシステムであり得る。開発者のその気概は重要である。しかし最終的にシステムの良し悪しを判断するのは顧客であり、大抵の顧客はちゃんとそれが判断できる。故に常に顧客の立場を理解して協力して進めることが重要である。当たり前ではないか。そうだろうか。自分の会社の上司、社長と今自分が構築しているシステム、どちらが大事か。あなたにとって、会社のリアリティとシステムのそれは、どちらが強いだろうか。顧客にも上司がいてその会社の社長がいる。だが、あなたにとって顧客の上司や社長がどれほど大事だろうか。ホンネを言ってしまえば顧客の上司など大して重要ではないだろう。そこに壁があることに気が付く必要がある。

もちろん、上司に説明できないからという理由で変な意思決定をしそうな顧客にはちゃんと「その判断はおかしいです」と主張すべきである。顧客も短期的な面倒臭さを嫌って長期的なメリットのある意思決定ができないことがある。その判断はお客さんのためにはなりません。的確に発言できるようになると、顧客との関係も必然的に良くなってゆく。

またエンジニアも顧客のために働いているのか、上司のために働いているのか分からないようではダメである。マネージャーが絶対に正しいという訳でもない。顧客は何をしたいのか。顧客にはどのような目的がありどのような利害関係があるのか、そこにフォーカスを当てなければならない。

なぜこんな当たり前のことをことを繰り返し言っているかというと、顧客がエンジニアの味方になるかどうかによって、プロジェクト運営が全然違ってくるからである。顧客が味方になってくれると、一緒になってトラブル対応を考えてくれるようになる。トラブルに対して怒ったり絶望したりすることは無駄である、と前に述べた。顧客が絶望し怒る様子はまた格別にエンジニアの心に染み入るものである。しかし顧客と一緒にプロジェクトを進める体制ができると、その辺の消耗がずいぶん楽になる。当たり前のことを積み重ねるだけなのだが、実際にはなかなか難しいのが顧客との信頼関係の構築である。

それから顧客との関係が上手く行っていないと「敢えて悲惨な意思決定」が行われることが増える。要するにいじめである。お互いに（つまり顧客にとっても）あまり利益にならない、つらいだけの作業にＧＯサインが出る。あるいは明らかに手間が掛かるだけでメリットの少ない方向にプロジェクトが動き出す。このような悲惨な意思決定に向かう理由はいじめだけではなく、他にも優先付けの誤りや時間リソースの軽視というものがある。しかし顧客と良好な関係を持っていなければ、その意思決定を変えさせることは難しい。

信頼関係を構築するためにはさまざまなハードルを越えなければならない。プロフェッショナルとして業務知識・技術知識を備えておかなければならない。また一時的な成果物（報告書など）も、たまには相手を唸らせるものを出したい。普段のコミュニケーション、メールも大事である。当然ウソをついてはいけない。約束は必ず守らなければならない。このような当たり前の行為の積み重ね、これが信頼関係を産むのである。そして信頼関係の構築が難しいのはまさに当たり前の積み重ねが難しいからなのである。

優先順位をつける（プロジェクトの人間学）

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

トラブルやタスクに優先順位をつけないプロジェクトはない。優先順位を付けてどうするか。何もしやしない。せいぜいその優先順位が適切がどうかを議論するだけである。何のアクションにも結び付かない。いやむしろ無駄な議論が生まれるだけ、その優先付け作業が無駄である。最初から優先付けしなければ適切な優先付け度合は何かという議論をせずに済む。

重要度と優先度が混同されることも多い。優先度は重要度とは違う。重要度は気分の問題であり優先度は抜き差しならぬ選択である。何のために優先付けをするのか。それは限られたリソースを重要なタスクやトラブルに投入するためである。どういうことか。すなわち優先順位の低いタスクは切り捨て、思い切って他の課題に人をあてる。重要でないトラブルは割り切る。その決断をするため優先順位を付けるのである。

最近は「トリアージ」という言葉が使われている。トリアージとは「負傷者を重症度、緊急度などによって分類し、治療や搬送の優先順位を決める」という医療用語である。全てを救おうとして全てを死なせてしまう。それが普通のプロジェクトで発生している事態であろう。結局は全部執拗に追い求めるのである。しっかりしたマネジメントであればトリアージという概念を利用できるかもしれないが、筆者の感覚からすればほとんど望み薄な気がしないでもない。プロジェクトが緊急事態に陥るまでは、普通マネジメントがタスクを切り捨てることはない。

成果を産まないタスクから手を引き成果を最大限にするタスクにリソースを投入する。優先付けはいわばプロジェクトのリストラクチャリングの基礎とならねばならない。なぜそれができないのか。プロジェクトのリソースが金銭とは違って目に見えないからである。金銭＝人月として数値化してもその生産性が分からない。人によって生産性が余りにも違う。個人の生産性が５倍違う（尺度は時間）などざらである。また人を投入したからといって楽になるとは限らない。むしろ逆で投入した当初はオーバーヘッドが増えるだけで生産性は却って落ちるだけである。だから正確な作業見積が難しい。「なあに、ちょっと土日出勤すれば追い付きますよか」若手のお気楽な楽観論は２度目の土日出勤でもろくも崩壊してしまう。

金銭や人月よりも貴重な時間というリソースが、プロジェクトでは忘れられる傾向にある。１日１６時間は働けますよ。徹夜すれば何とかなると思います。残業しても休日出勤しても生産性は上がらない。文字通り少しも上がらない。なぜなら残業してもプレッシャーを与えても頭はよくならないし、集中力は残業すればするほど減る一方だからである。休日出勤している社員のモチベーションや働き振りを見てみたらよい。ネットサーフィンに時間を潰してないか。だらだらとおしゃべりをしていないか。残念ながらマネジメント層にも時間を忘れる傾向はある。夜遅くまで働くメンバーを見て、時間はふんだんにある、と思い込んでしまうのだ。

時間が貴重で限られたリソースであるという認識がなければ、そのリソースをどうして慎重に配分するかという問題意識もないであろう。ましてや、リソース配分のために障害を割り切ったり、タスクを削るなどという考えは出てこない。ただし、それも実際にプロジェクトが火を噴くまでは、の話ではあるが。

それをしなかったとしてどのような結果になるかを考える。優先度が低い作業を切り捨てるに当たって必要な考え方である。それが分からないから、不安だ。確かに先のことは分からない。だが不安とタスクは切り離して考えなければならない。さもなければリスクは少ないにも関わらず、そのリスクに対応するような作業が発生しかねない。例えば意味もなく頻繁に取得するバックアップなど。落ち着いて考えよう。不安はその対象を具体化すれば消える。不安とはそういうものである。あるいは不安は究極的には死の不安である。ハイデガーが言った。第二次世界大戦という背景はあるが、あながち的を外してはいないように思える。不安にとらわれる必要はない。それをしなかったとしてどうなるか。システムに対して、どういう時に、どのような影響が発生するか。例えばシステムが止まるか。あるいは次に保守するメンバが困るのか。システムが止まるのであれば当然対応しなければならない。しかしそうでないならば、作業を行うかどうか、踏みとどまる値打ちがある。帰宅して子供と食事を取って寝るのとどちらがよいか。一度検討してみてもよいのではないだろうか。

これまで何の疑念もなく行ってきた作業や手順についても、再度「今これを行わなかったとしてどうなるのか、検討してみるのは悪くない。その際、最初の認識を変えたがらない人間の習性に留意すべきである。もはや「おまじない化」している場合がある。ロジックで理詰めで動くように思われるかもしれないが、実はIT業界ではよくある話だ。以前この手順でうまく行ったから。必要ではないが念の為。そういう作業が多いのもこの業界の特徴である。実はどっぷりと呪術的な慣習に浸っているのである。

このような実績のある作業や設計をひっくり返すのは極めて困難である。敢えてやらない理由を見つけ（これは難しくない）、周りを説得する（これが大変）、こちらの方が体力がかかる。「こんな作業いらないっすよ」「いや昔この手順で事前に障害が食い止められたことがある」。ミドルウェアのバージョンも違う。開発環境も違う。だが否定はできない。ぶつぶつ言わずに実施してしまった方が早い、そういうことも多い。ある作業が実績化されそうな場合（繰り返される可能性がある場合）無駄な作業をなるべく省く努力が重要である。

Java + Mysql5.0で日本語を扱う基本設定

my.iniでdefault-character-setをcp932にする。サーバ用設定とクライアント用の二つがあるので注意。サーバをutf-8にしても問題ない模様。

以上。

Spring frameworkで添付ファイルを含むFormの処理がスカるとき

submitしても何も言わずに元の画面に戻ります。

SimpleFormControllerの"onSubmit"までも至りません。

デバッグで見ると「StringをMultipartFileに変換できない」とかなんとかの型エラーが出たりします。

それは<form:form>タグにenctype="multipart/form-data"が抜けているからです。

以上。（これもハマると数十分が消えるたぐいのチョンボです）

Eclipse ganymede で tag library エラー

Eclipse europa で動いていた JSP を ganymede に持ってきたとたんに

Cannot find the tag library descriptor for "http://java.sun.com/jsp/jstl/..."

というエラーが出ました。

Webアプリは使えることは使えるようでした。

いろいろ調べても埒があかなかったのですが、何のことはない

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

を

<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt" %>

としたら直りました。(jsp/を削ったわけです）
もしやと思ってもう一度元に戻しても

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@ taglib prefix="fmt" uri="http://java.sun.com/jsp/jstl/fmt" %>

エラーは出ませんでした。

ほとんどゴミ投稿ですがこの情報が誰かの時間を節約できればありがたい。

無駄な作業を捨てる（プロジェクトの人間学）

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

何のためのプロジェクトか。良いシステムを作るためである。では良いシステムを作るために、何をなすべきか。良い問いである。そしてこの時重要なのは、何をなすべきでないのか、を意識することである。例えば重箱の隅を突付いてばかりでは絶対に良いシステムはできない。つまり良いシステムを作るためには、やるべきでない仕事をやらないことが重要である。無駄な作業を効率的に行うことほど無駄なことはないとドラッカーがどこかで言っていた。また80対20の法則というものがある。この法則を適用すればプロジェクトで実施する作業の80%は無駄である。残りの20%が品質の80%を決定する。実感にも合う。何でこんな無駄なことばかりさせやがる。プロジェクトでこう思わないエンジニアはいない。

とすれば現実的に有効な問いは「何をなすべきでないか」である。この問いに答えるのは実は難しい。何故ならこの問いに答えるためには作業に対する負の価値判断（つまり否定）が必要だからである。なぜ作業の否定が難しいか。君が今やっている（やろうとしている、あるいはやろうと思いついた）仕事はまったく無意味で無駄だから今すぐ止めて他のことをした方がよい。ああ、まったくだ。そう思えるだろうか。大きなお世話だ、と思うのではないだろうか。あるいは人によっては、それをやりとおすことに意味がある、とムリヤリ意味を見つけてしまうかもしれない。

仕事を切り捨てるのは感情的にはなかなか受け入れがたいものなのだ。その仕事は無駄だ。そうかもしれない。でもやってみなければ分からないじゃないか。それにもしこの仕事をやらないとして、大きな問題が発生したら、どうしてくれるのだ。そう言ってまじめなワーカは徹夜でその仕事を続けるものなのである。

何か問題が発生したら、その責任は俺が取る。だからその仕事は*するな*。そう言えるマネージャがいるだろうか？マネージャとは脳内タスクテーブルに載ってしまったタスクは、たとえそのタスクがある時点から無意味になったとしても、プロジェクトが完了するまで執拗にトラッキングするものである。途中で「やらなくてもよい」と言うマネージャはほとんどマネージャではない。宇宙人である。

しかし実際のところ、無駄ではない作業がどれほどあるのだろうか。会議、一時的成果物（トラブル報告書、技術説明報告書、パフォーマンス分析、障害解析うんぬん）。後に振り返ってみればすべてがそれなりに意味を持っていたように思える。あの時あの作業をしていて良かった安心だ、とすら思えてしまう。ただし、われわれ人間は仕事に意味を求めている、という事実を考慮に入れる必要がある。仕事に意味を感じられない人間は転職するか淘汰されてゆく。だから我々の意識には、意味を見つけようとする強い重み付けが存在するのだ。それを忘れてはならない。

では、無駄な作業とはどのようなものか。それは「やらなくてもよい作業」である。そんなの、当たり前じゃないか。ではやらなくてもよい作業を、あなたはしていないのか。ピントの外れた長電話をしていないか。どちらを選択しても結果に大した違いが出ない意思決定について、30分以上議論を続けていないか。表向き、形式的に必要だが、その内容はまったくどうでも良い報告書の作成。低レベルの作業でも無駄な作業はいくらでもある。ホストの経験しかないマネージャがソースコードのステップ数を出せと言ってくる。Javaの行数をどこまで精緻に数えるのか。あなたにまじめに*数えない*ことができるか。

プロジェクトで働く人間は（特にある種の人間は）実にまじめでやや近視眼である。腰を据えて大局や本質をじっくり見る前に、とりあえず目先の仕事に全力で取り掛かってしまう。不安(仕事がなくなる不安＝自分が必要とされなくなる不安、プロジェクトの先行きに対する不安)に駆られるという理由が大きいのではないかと思う。だがこれでは仕事が趣味という人間以外は淘汰されてしまう。もう少しうまい進めかたはないのか。ハードワークに疲れ果てる前に考えてみることはないのか。

排中律を意識的に活用する（プロジェクトの人間学）

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

排中律とは「ＡはＢか非Ｂかのいずれかである」という式であらわされる古典論理学の法則である。何だ当たり前じゃないか。それがそうでもないのだ。排中律をどう適用するかによってプロジェクトにおける判断が異なってくるのだ。

常識的な世界で排中律が成立するかどうか見てみよう。「ＡはＢか非Ｂかのいずれかである」。Ａにりんご、Ｂにみかんを代入してみよう。「りんごはみかんかみかんでないか、いずれかである」。正しい。りんごはみかんではない。では次はどうか。「脳死は死であるか、死でないかいずれかである」。ほれ。難しくなった。答えは「なんとも言えない」あるいはシニカルに言えば「政治が決める」であろうか。以前はやかましかったこの議論であるが、現在はどのようになっているのだろう。では次はどうだろう。「アプリケーション障害は将来起こるか起こらないかのいずれかである」。どうも起こりそうな気はする。でも起こって欲しくはないし、アプリケーションの完成度からすると起こらなそうな気もする。ようするに「分からない」のである。排中律はこのように「分からない」状態を排して、二つに割り切ってしまう。ある意味で非常に乱暴な論理なのである。

実は排中律は現実的な論理ではない。「どっちなんだ」。「わかりません」。それが正しい。だが、そこを逆手にとって利用することが可能である。すなわち「現在得られている情報では、ＡはＢか非Ｂのいずれかであり、定義より非Ｂなのです」と言い切ってしまうことができるのだ。これで何がうれしいか。「違う」ことが説明できるのがうれしいのである。なぜわざわざ「違う」ことを示さねばならないか。ある障害が起きたとする。「またですか」と顧客がうんざりした声で言う。これって前に発生した障害と「同じ」じゃないですか。なぜまた「同じ」ような障害を繰り返しているのですか。いえ。前に発生した障害とは違います。何故なら、以前の障害はこれこれこういう前提の元で発生したものです。今回は前提が全く違います。故に別の障害なのです。ある程度抽象度のレベルを上げてしまうと本来「同じ」とすべきでないものまで「同じ」に見えてしまう。それは意識のもっているバイアスである。細かい現実を正確に把握しようとする時に「全てが違う」と世界観を構成する際の邪魔になる。だから「違う」ことを排中律を用いて明示することが重要である。

排中律を意識的に適用することで、物事をきっぱりと割り切ることができる。本来事象はきれいに二つに分かれるものではない。だが条件と前提をはっきりさせればスパっと分けることができる。排中律は、あいまいさを許せないというマネジメント層・顧客層を上手く説得するテクニックなのである。