【この「プロジェクトの人間学」投稿シリーズは（後略） 初回投稿：
はじめに（プロジェクトの人間学）】
マネジメント層にも当然現場感覚がある(あるいは少なくともあった)はずである。しかし、出世し、金を計算し、自社のために働くことによって、その感覚が失われてくる。またわけの分からない技術や方法論、ツールが山ほど出てくる。現場で働くエンジニアやプログラマはまっとうなコミュニケーションができない。偉くになるにつれて、プロジェクトの現場から意識が離れるのも当然である。
だからこそ現場メンバーの現場感覚が重要である。もはやマネジメント層は頼りにならない。マネジメントはトラブルが起こった後でしか対応ができないのだから。
前にも少し述べたがトラブルの気配はどこにでもある。問題はどの気配に、どう対応アクションを取るか、である。気配は気配に過ぎない。トラブルそのものではない。自分にとっては重要に見えるかも知れないが、他の人からするとまったく重要ではないように見えることは、ざらである。時々「これほど明々白々なトラブルの予兆に、なぜ他の人は気が付かないのか！」と絶望することもある。そしてその直感が完全に誤っている（回りの人が正しい）こともまたしょっちゅうである。
要するにトラブルの気配を潰すことは、あがくことであり、騒ぐことであり、周りを（特に経験が豊富で度胸があり頭の切れる人間を）巻き込むことである。
「確かにトラブルの気配を発見した」という主張に対しては、反論も必要である。仮にその発見が誤りだった場合、そこに投入したリソースがムダになるからである。トラブルが起こってから慌てふためくより今できるだけコストを掛けておく方がマシ、という主張は危険である。単に不安に駆られただけ、というケースは案外多いものである。手当たり次第に思いついたものが、不安の対象となりかねない。本当にそれはトラブルの予兆なのか、複数人でチェックする必要があるし、もし予兆でないとしたら、そこからはいかなるタスクも発生させてはならない。
トラブルの予兆を発見するためには問題意識が必要である。問題意識の裏には不安が潜んでいる。不安とは常に将来への不安である。その不安が発端となってトラブルの萌芽を潰すことができる。従ってプロジェクトをうまく運ぶには不安が必要である。だが不安は諸刃の剣でもある。不安によって盲目になることがある。具体的には不安に駆られて我を忘れ誤った意思決定をしてしまう。あるいは冷静な優先順位付けができなくなる。だから不安はコントロールされなければならない。不安はコントロール可能なのである。
不安には実に底がない。人間は死ぬまで不安から解放されることはない。その度合いをコントロールすることができるだけである。その意味では不安は苦痛や絶望と似ている。いずれも「どん底」というものがない。いくらでも下に掘ることができる。そうとは知らずに自分の足元を掘り下げてて行くのが人間である。自ら不安を増幅し、しかも自分が増幅しているとは気が付かない。不安をコントロールするのはある意味では容易である。単に足元を掘ることを中止し、その穴から出ればよい。具体的には不安を具体化することである。それから不確定情報の確度を上げること。
漠然とした不安は何も生まない。せいぜい無駄なタスクを生じさせるのが関の山だ。何が不安なのか。まずはできるだけ具体化しなければならない。具体化できない不安は妄想でしかないと割り切る勇気も必要だ。アプリケーションの障害が不安である。これではアクションが取れない。具体的にどんな障害か。先だって発表されたミドルウェアのセキュリティ脆弱性に由来する、顧客情報の漏洩が不安である。OK。これでアクションが取れる。まずは脆弱性の詳細を押さえる。どのような条件でどのような影響があるか。プログラムによる作り込みで対応するためにはどうすればよいか。今の実装状況をチェックするためのチェックシートを作り、チェックする。必要があれば対応する。対応後のセキュリティについてレビューし、制約や注意事項があればチェックする。以上。最初のきっかけ以外不安に出る幕はない。
トラブルを事前に潰そうとする試みは、常に「空騒ぎ」に陥る可能性がある。しかし不安から課題が明らかになったのであれば、空騒ぎを恐れてはいけない。トラブルが事前に潰せれば、結局は体力の節約になるからである。
