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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

閑話休題

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

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

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

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

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

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

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

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

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

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

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

閑話休題。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どう「見せる」か（プロジェクトの人間学)

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

下手に話をややこしくしないこと。これに尽きる。Simple is the best. 真理は単純である。ただしむやみに抽象化・汎用化してはならない。適用範囲が広がってしまう。具体的な前提を定義することが重要である。具体的かつ単純。これがコツである。自分を利口に見せることにこだわってはならない。バカでした。ごめんなさい。これで話が早く済むのならさっさと謝ってしまうのがよい。

Javaで開発しているプロジェクトで障害が発生した。障害の原因がNullPointerExceptionだった。NULLチェックを入れ忘れていた。このように見せてしまうと、影響範囲は甚大である。NULLを取りえる全てのコードにチェックが必要となる。Javaが分かっている人間であればNULLチェックはするし、ほとんどのは単体テストか結合テストで分かる判明するはずのトラブルである。しかしNullPointerExceptionが一人歩きしてしまうとただひたすらこの例外にフォーカスが当たってしまう。原因への対処には不釣合いな、膨大なリソースが投入されてしまう。NULLチェック漏れではなく、さまざまな要因が重なっているはずである。条件があるはずである。そこをちゃんと見せなければならない。そうすればそのトラブルをクローズし、次のトラブルにリソースを投入することが出来る。

また政治的な問題を軽視してはならない。現場から見れば大したことがない修正でもマネジメント層や顧客からすると大変なハードルとなることがある。現場が「大した変更じゃない」と思っても、政治的にはその選択はありえない、という可能性がある。例えば顧客の他の部署に依頼する必要がある変更である。絶対に変更を受けつけてもらえない。顧客はまず青い顔をし、次に現場を恨み始める。現場は「顧客の問題であって俺たちは知ったこっちゃない」と思う。どんどん関係が悪化し、プロジェクトがまずい方向に進む。健全にプロジェクトを運営したいなら、決して政治を軽視してはならない。

見せるにあたってはスコープを広げないこと。むしろ狭めるよう努力する。スコープとはタスクの範囲を指す。タスクの範囲を下手に広げてしまうと、完了させることが出来なくなる。あれはどうなった？と聞かれて常に状況を報告する羽目になる。タスクはシンプルに、ピンポイントで定義すること。そして何をどうしたら完了できるか、そこまであらかじめ射程に入れておくこと。完了までの道筋を見極めることなく、課題を定義しないこと。ついうっかり不安をそのまま課題にすると、却って政治的に厄介になる。重要度が最終的に低いと判明したとしても、だ。また課題を提起する際にその完了条件まで射程に入れておくと課題をクローズする効率が全く違ってくる。スコープを広げないこと。特に広げさせないこと。これが重要である。

やたらと宿題のキャッチボールをしないこと。決定事項のやり取りをキャッチボールに例えた。顧客に決定権をゆだねるとさしあたりは自らのタスクではなくなるため安心する。また待ち状態となるため、責められることがない。少なくとも決定を依頼すれば、作業を進める責任は顧客にある。だがこれは単なる作業の先送りに過ぎない。未来から時間を借りているだけである。下手に先送りすべきではないのだ。顧客への意思決定依頼は最小限にする。適切に提案し迅速にクローズ。結局はそれが一番早くて体力が掛からない。

管理されるが故に完了困難になることもある。重箱の隅が突付かれ、優先度の低いタスクが山ほど発生する。課題のクローズに完璧さが求められる。なんてことはない課題がどんどん広がり、収集がつかなくなる。最後には原型を留めないほどに課題が変質してしまう。そんなことにならないよう、出来る限りクローズを急ぐことだ。

数値化は見える化ではなくむしろ見えない化である（プロジェクトの人間学)

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

数値化の危険もメリットも抽象化にあることはすでに述べた。だから過度の数値化は危険である。細かい情報がそぎおとされる上に意識が数字という現象＝みせかけに強くこだわる傾向があるからだ。

何のための「見える化」か。それはトラブルの予兆に気が付くためである。数字を眺めてトラブルの予兆に気付くか。進捗の遅れやトラブル数から分かるのはせいぜい「今トラブルが起こっている」程度であろう。その発見すら遅れるかもしれない。数字の向こうを見なければトラブルの予兆は分からない。いや今起こりつつあること全ては数字だけからは分からない。数字は意識的に抽象化された結果に過ぎないからである。すなわち質的な事象を意識的にそぎおとすことができてしまう。数字だけを信頼できないのはそのためである。トラブルを抱えたチームのテスト消化数も極めて順調に進んでいるチームのそれも「同じ一件」である。しかしその質は大きく異なるはずである。例えば前者のテストはテスト結果の確認が甘いかもしれない。前提環境の整備ができていなかったかもしれない。これが後から手戻り作業の大小につながる。順調に行っているプロジェクトですら予定外作業や小さなトラブルが日常茶飯事なのだ。そこに前フェーズ由来の手戻りが発生すると簡単にタスクオーバーフローとなる。後は品質が下がり納期が遅れて行くだけである。

ましてやメールの本数、ソースチェックイン回数、バグに関する数、そんなものをムリヤリ数値化したデータを使って、何かが出てくるはずがない。むしろ現状が隠れるだけである。日本の自殺者年間何万名。内何％が経済的理由でうんぬん。年齢別内訳が・・・そのデータで自殺者が救えるのか。残された人間の何が分かる。数値化しなければ始まらないではないか。そしてあらゆる方法でデータの分析を行う。それをお役所仕事という。他にやるべきことなど、いくらでもある。

プロジェクトを一度徹底的に数値化して管理してみれば、結局何も分からないことが分かるであろう。そればかりか下手をすればプロジェクトが壊れる可能性すらある。

「数値化＝見える化」したい要求の裏にはプロジェクトに対する無理解がある。すなわちそのままのプロジェクトを見ても分からない、評価できない。現場の人間と話をしたくない。何を言っているか分からないから。トップマネジメントも一度ありのままのプロジェクトを見てみたらどうか。たまにはメンバーといっしょにプログラムを書いてテストしてみるのも悪くはない。メンバーの抱えている作業負荷が、実感として分かるであろうから。またプロジェクトの状況も、下手に数字の分析に体力をかけるよりは良く見えるのではないだろうか。

「心ここにあらざれば 見れども見えず 聞けども聞こえず」という。気が付く力が重要である。何か変だと気がつく。納得が行かない。どうして？と思う。だがその先に行くのが難しい。ま、いっか。俺知らねーぞ。私のせいじゃない。思考停止である。次が重要なのだ。それは間違っていると思います。何故ならこれこれこうだからです。確かに嫌味なしに指摘するのは難しい。だが指摘しなければ、将来のトラブルはなくならない。「見える化」の前には「気づき」があり、次に「見せる化」があるのだ。問題を取り出し、顕わにすること。おかしいと指摘し、その理由を示すこと。それが「見える化」の本質なのだ。数値化は現象の解釈に過ぎない。しかも極端に抽象化した解釈である。ゆえにほとんどの数値化に認識としての力はなく、射程も浅い。だからよく考えられていない数値化は単なる「見えない化」なのである。「見える化」の本質は人間の有限なパースペクティブ（見晴らし）をチームで共有化することなのである。

パースペクティブとは何か。人間は一時にすべてを見渡すことが出来ない。現象は常にある立場から見た現象に過ぎない。人の立場にはさまざまな制約が働いている。時間（いついつか）、空間（どこで）、バイアス、偏見、好み、経験 etc。おのおののパースペクティブから課題あるいはトラブル以前の課題を引き出し、言葉にして共有化するのが見える化である。そして課題を正しく言語化することが出来れば、問題は解決したも同然である。あとは管理可能なTODO（いつまでに誰が何をするか）が残るだけである。

「見せ方」というとなんだかネガティブなイメージがあるかもしれない。客観的な事実をある政治的観点から「見せる」。偽りのイメージ。プロパガンダ。そうではない。事象が発生するとまずは解釈しなければならない。神であれば解釈の必要はないであろう。あるがままを全方位から捉えることが出来るに違いない。しかし人間は神ではない。その人の持っている背景（制約。時間空間バイアス・・・）からその事象を解釈せざるを得ない。数式を眺めて相対性理論を思いつくか否か。人によってそのくらいの違いがある。ウィスキーが半分残っている。まだ半分あると思うか、もう半分しかないと思うか。人は皆年を取る。４０歳になったとしてどう生きるか。何も思わないか。それともそれをきっかけにまったく新しいチャレンジをするか。「客観的」な事象などない。「見せる」前には「解釈」がある。そして「解釈」は力なのだ。力を持った人が解釈し得るのである。すなわち（残念ではあるが）力を持たない人間に力強い解釈はできない。力のない人間は力のある人間の認識を鵜呑みにするか、弱々しい自らの認識にすがる他はない。解釈とは自分を変え、世界を変えることなのだ。解釈にはそれほどの力がある。極端を言えば資本主義だって経済学だって物理学だってそれぞれが世界の解釈なのだ。

今そこにあるトラブルに気が付くこと（プロジェクトの人間学)

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

トラブルの原因は、トラブル発生の後に分かる。「後になって分かる」それが実は「原因」という概念の本質的な属性である。あの判断が誤っていた。あのドキュメントをチェックすべきであった。全て後から作られる「物語」である（原因も結果も存在しない、ことは以前にも述べた）。

こういった「原因と結果」物語によって意識化された経験は、実を結ぶ時期の早い遅いはあるにせよ、その人固有のノウハウとして蓄積される。そのノウハウが次のトラブルの予知につながる。しかし性急な意識化はトラブルの予知能力には結び付かない。ある程度の熟成期間が必要である。方法論だけではトラブルを事前につぶすことはできない。「何か変だな」と気が付くこと、そしてその「おかしい」という感覚を言語化する能力が必要である。さまざまな予兆がある。誤った意思決定。問題の先送り。担当者が全く見落としている場合もあれば隠している場合もある。ある種のトラブルは不可避である。事前に全ての情報を得ることも、全ての可能性を検討することもできないから。早い話が「やってみるまでわからない」そういう状況が確実にある。だったらトラブルは起こって当たり前じゃないか。その通り。トラブルを許容しなければ、先に進まない。リスクも同様である。
全てのトラブルが不可避だなどと言っている訳ではない。予防できるトラブルがあり、マネージできるリスクがある。だったらそっちに注力したらいい。起きてしまった事は起きてしまった事である。しかるべき対応をとり、妥当な再発防止案を検討したらよい。

予防できるトラブルとは何か。それは事前にトラブルの予兆を知りえたトラブルである。からかっているのか。そうではない。一寸先は闇と昔から言うではないか。未来は未だ来ぬ故に存在しない。だから未来は分からない。だが将に来るべき将来なら分かることがある。どのようにして分かるのか。過去も未来も存在しないと前に述べた。すべてのヒントは現在にある。妙な流れに向かっているミーティング。本質から離れた論点で執拗に繰り返される議論。担保の取れていない不確定情報を垂れ流すメンバー。その不確定情報を元に意思決定されそうになっている。オーバーワークで深夜残業を繰り返すメンバー。すでにその品質に疑義がある。以上の事象は数字には決して現れない。すべてがトラブルの予兆である。その中のどれが実際のトラブルになるか。それはその時になってみなければ分からない。だが経験と勘がそれを助けることがある。筆者の経験では上の例はすべて明確なトラブルの前触れであり、後のトラブル発生は必至である。

筆者の妻が皿を洗う時、洗い終わった皿を水きりカゴにやたらと積み上げる。そんなに積んだら崩れるぞと何度も警告するのだがほとんど言っても無駄である。たいてい聞き流されるし、ひどい時には逆切れされる。何ヶ月かに一度、皿の山が崩れ妻の悲鳴と共に皿が割れる。これもまた仕方がない。見る目が無かった。それだけの話である。「どうしてあの人と結婚したの？」これもまた因果律の本性を省みない、厳しい質問である。だってもう仕方がないじゃないか。

だから何とか我慢しようとしてみる。頑張ってミーティングの流れを補正しようとする。議論を本質的な流れに戻そうと頑張ってみる。不確定情報は「確認しろ」と指示を出す。意思決定ではなるべくリスクとコンチプランを検討する。それで上手く行くこともある。だが残念ながらすべてが上手く行くわけではない。所詮は人間のやることである。

また予兆を知ったとしても必ずしも手を取れるわけではない。明らかにオーバーワークのメンバーがいたとしても、コストがない、権限がないなどの理由で体力の投入ができない場合がある。その場合は今できることをできるだけ行い（例えばそのメンバーをできるだけ雑用から守るなど）、大きなトラブルが次のフェーズで発生するのを覚悟するほかはない。

PDCA(Plan Do Check Action)だけでは足りない。Planの前に問題に感覚的に気が付かなければならない。そして問題を正確に定義しなければならない。また最後のActionは余計である。事後作業が不要になるようにPlanし、念のためCheckして問題が無ければクローズである。だから正確にはFPDC(Feel Plan Do Check)である。PDCAで回るほどプロジェクトは簡単ではないし、悠長でもない。Feelとは、今現に何が起こっているのか把握することでもある。これは会議では把握できない。会議で把握できるのはこぎれいに抽象化された情報であり、生のデータではない。だから現場で実際に見る必要がある。

しかし残念ながらマネジメント層や顧客は、現場を見ても何が起きているのか分からない。不祥事を出す会社の役員が、現場を知らないのと同じである。現場を見ても分からないし、解釈もできない。だから現場から適切な情報も上がらなくなる。確かにシステムは余りにも複雑である。だがマネジメント層もなるべく低いレベルまで状況を押さえるべきなのである。

ドキュメント軽視の理由（プロジェクトの人間学)

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

なぜある種の開発方法論がドキュメント軽視を生むのか。時間をフェーズで区切りそれぞれの成果物を定義する。あるフェーズの終わりに納期が来る。プロジェクトのある一時点の状況を考えてみる。それは詰められた要件と漠然とした希望レベルの要件が混在する状況であろう。プロジェクトの途中で全ての話が煮詰まっているなどありえない。そして設計書の記載レベルは当然粒度の粗いほうにできるだけ合わせることになる。要するに煮詰まっている要件でも細かいレベルまでは記載しないような動機付けが働いてしまう。

ウォーターフォール型プロジェクトがドキュメント軽視を生む理由がもう一つある。それはドキュメントの納期が過ぎた後の修正作業に負のインセンティブが発生することである。成果物は納期を過ぎると一旦FIXしたものと見なされる。一般に過去の蓄積に対する変更は好まれない（前述のトラブルの定義参照）。つまりドキュメントの変更が好まれないから、詳細に設計を紙に落とすことも、まめにメンテナンスすることも結局は好まれないのである。これもまた本末転倒の類であろう。

システム構築プロジェクトが必然的にドキュメント軽視を生むとは思わない。ただし、そうしないためにはリリース直前までドキュメントの変更を励行しなければならない。それができるマネージャがいるだろうか。そんなことをしたらウォーターフォール型開発の前提が崩れるではないか。筆者はそこは崩しても問題ないと思っている。事実、マイクロソフトの開発プロジェクトはリリース直前まで設計書を更新すると「ジョエル・オン・ソフトウェア」（オーム社）にあった。正しいと思う。常に設計書を最新にしておくことは、最善の実践としか思えないではないか。

トラブルを恐れるからさまざまな本末転倒が生まれるのだ。トラブルを自然なものと受け入れ、その上でベストの対応を取ればよい。設計書の修正もその一つである。

常に質が重要である（プロジェクトの人間学)

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

本日のコーディング進捗。予定数20本に対して21本。妥当な人員（スキルと人数）、期間、作業量で回っているプロジェクトならば問題ない。しかし普通は何がしかのトラブルを抱えているものである。プロジェクトの状況を押さえなければこの数字は評価できない。例えばメンバーのスキル。働いているときの顔色や帰宅時間。会話の内容。質的なものを考慮すれば数字の中身が見えてくる。

最も重要なのがトラブルの質である。単純ミス、製品障害、設計ミス、コミュニケーションミス、さまざまなトラブルがある。そして時期によってトラブルの評価は変わってくる。

初期設計フェーズで潰しておきたいトラブルの一つはグランドデザイン上鍵となる技術のフィージビリティである。要するに例えば「JavaとDBでそれができるんだっけ？」とか「データのサイズが5年後に5TBを超えるけど、運用回るんだっけ？」という確認である。「そもそもサポートされていない」とか「このグランドデザインでは実現は困難」という事実はこの時期に発見しなければならない。確定情報を掴みきれなかった場合には代替プランも必要である。

新しいテクノロジーを採用する際のリスクをある程度はここで潰すことになる。最近は技術の実体が見え難い。その理由はニッチな規格の乱立、分かったような分からないような営業トークである。Javaでいえば初期のEJBまではまだ何とかなった（使わないけど）。WebServicesだの何だの出てきてからがひどい。素晴らしいソリューションだとかなんだとかいうから見てみたらただのリモートプロシージャコールじゃないか。実績があるから、話題だから、というだけの利用で採用し、フィージビリティ検討が甘いと後でひどいことになる。

それから最初の設計方針に制約があるかどうかも事前に押さえておかなければならない。例えば「並列に作業できる要件に対応して、子画面を複数立ち上げて操作可能とする」という設計にした場合、画面遷移が複雑怪奇となり、また組み合わせによってはデータの受け渡しの関係上使えない子画面が出てくる可能性がある。それを最初にリスク・懸念として顧客と共有し、次のフェーズで対応して行く必要がある。

初期設計フェーズでは、以下のトラブルの種が植えられる。
－フィージビリティ系トラブル（プロジェクト成立の根幹に関わるものから軽いものまで）
－グランドデザインから発生する制約の見落とし

当たり前だが後の工程になるほど上記トラブルのインパクトは大きくなる。

詳細設計フェーズのトラブルは、基本設計がそれなりに出来ていたとすれば、あまり深刻なものではない。フィージビリティやデザインを詰めて行くだけである。しかしもちろん基本設計がうまく行くプロジェクトはそんなにない。だから大抵は根本的なフィージビリティが詳細設計フェーズでも課題となる。

またグランドデザインの検討が進み、追加の機能が必要になることが分かってくる。大抵は止むを得ない追加となる。

開発、テストフェーズ初めてロジック上のトラブルが出てくる。このCD/UTフェーズでのロジックトラブルは必然的であり、自然である。表に出ないためあまり騒がれることもない。この時期にフィージビリティ検証の甘さが露呈する場合もある。結合テストで出るよりはましである。この時期は時間が足りないことで品質が下がるリスクがある。またコミュニケーションミスによる実装漏れがある。詳細設計で詰めて書かれていないため、この手の実装漏れは直接コードを見るしか確認できないのが実情である。ただし全コードをレビューする時間などないから、うまくサンプリングしてレビューしなければならない。レビューワは専任の方がよい。開発者に片手間にレビューさせると、体力の関係で開発者が担当するコードの品質が落ちる。詳細設計でロジックまで詰められていない、かつレビューに十分な時間が取れなかったまま結合テストに進んだプロジェクトは、通常大きなトラブルに遭遇することになる。

CD/UTで判明するロジックのトラブルは理想的には詳細設計フェーズで潰されるべきである。しかしもちろんそんなことにはならない。現実には詳細設計はせいぜい「ロジックに落とし込めないほど大雑把な手順」あるいは「顧客の漠然とした希望」が記載されるに留まる。その理由は２つある。一つは開発者が陥りがちな設計書の軽視である。コーディングしてUTするのが一番早いんですよ。一理ある。だが仕様と品質がきちんと守られドキュメントがメンテナンスされる必要がある。別に優等生ぶるつもりはない。引き継ぎ体力の節約と余計なトラブルの防止を防ぐためだ。CDUTを優先する開発者はドキュメントを軽視する傾向がある。面倒くさいのと日本語が苦手だからであろう。だが実はこれは開発者だけの責任ではない。ウォーターフォール型方法論の厳格な適用もドキュメント軽視を生むのである。

数値化の罠（プロジェクトの人間学)

【この「プロジェクトの人間学」投稿シリーズは、昔私が出版社に持ち込んだ原稿からコピーしたものです。某出版社でページ数を増やすことを条件に書籍化の話を頂いたのですが、いろいろあって何となく立ち消えになってしまいました。しばらく音沙汰もないので、少しずつ投稿して行こうと思います。】

進捗状況やトラブルが数値化されないプロジェクトはほとんど考えられない。しかし数値化には実にさまざまな危険がある。

－過度の抽象化
本日の交通事故死者１名。これで何が分かるか。数値化は究極の抽象化である。数字以外のすべてが削ぎおとされる。

－測定対象を誤る危険
数値化には必ず測定方法が先立つ。何をどのように測定するか。測定できる、というのは測定する理由にはならない。これを「データの罠」と呼ぶ。数えるべきでないものを数えてしまう。数えた結果を分析し、報告書にまとめなくてはならなくなる。無用なデータに不釣合いな体力が掛けられることになる。

プロジェクトを論じた本に「メールの数を計測してコミュニケーションがうまくいっているかどうかの指標にしたらよい」という記載を見て仰天したことがある。単なるお礼メールがあり、連絡メールがある。無駄な作業とコミュニケーションを引き起こすメールがある。あるいは一本で仕事をクローズする優れたメールもある。日に1000通メールが飛び交ったからといってそこから何も導けやしない。単に混乱しているだけかもしれないではないか。

－数値化の観点
数値化するためには観点もまた必要である。切り口によって見えるものが違ってくる。何を目的として数えるのか。目的のない数値化はプロジェクトにおいては単なるオーバーヘッドである。

－数値にとらわれてしまう
数値には曖昧さがない。そして足算と引算は誰がやっても同じ結果が返る。昨日までの累計が１００だった。本日１０追加された。故に本日は１１０となる。当然そうならなければならない。ところがそうはならないことがある。勘違いがあった。あるいは本来であれば数に入れるべきものでない項目が含まれていた。数を取り出すには抽象化が必要であり、抽象化には解釈の入る余地がある。しかしマネジメント層にはこれが気に入らない。数字の不整合を許容することは意識にとっては非常に難しい。するとどうなるか。現実の方を数字に合わせ始めるのである。整合性のない数字が隠蔽やウソを引き起こす。

優秀な人間は数字に強いリアリティを感じる傾向がある。また数字に強いということは、会社で出世するための重要な能力の一つである。優秀な人間や出世した人間がプロジェクトを管理することが多い。従ってこの数値化偏重傾向は潜在的にプロジェクトに存在していると思ってよい。数字の使い方を誤ると、現実の方を数字に合わせること、具体的には数字の見せ方や出し方に大きな体力がかけられることになる。

カントは正しい。プロジェクトそれ自体は決して認識できない。認識できるのは単なる現象である。そして数字は現象に投げ入れる概念の一つに過ぎない。今風にいえばただのクオリアである。その数字にプロジェクトが踊らされている。プロジェクトの目的は何か。この問いは常に価値がある。果たして数字合わせと化したマネジメントに何が貢献できるのだろうか。

トラブルを予防する（プロジェクトの人間学)

トラブルを出さない、出したくない。これもまた自然な感情である。しかし前に述べた通りここからトラブルへの拒否反応を導いてはならない。トラブルを防ぐ効果的な方法を実践する必要がある。

トラブルを出さないためにはどうすればよいか。メンバーにできるだけまとまった時間を与えることである。そして今作っているシステムについて考えさせる。プレッシャーは与えない。それだけ。まともなエンジニアは大抵極めて真面目である。ハードワークを辞さず、トラブルには深刻に真剣に対応する（無論たまには厄災と表現する他はない人材がいるがここでは無視する）。プレッシャーにも慣れてはいる（頼みもしないのに自分でプレッシャーを感じて苦しむものもいる）が、だからといって必要もないのに与えることはない。プレッシャーを与えても頭は良くならない。デマルコが言った。割り込みのないまとまった時間を与えるのが管理者の仕事であり一番有効なトラブルの予防策である。