トラブルに対応するためにはどうするか（プロジェクトの人間学)

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

まずはトラブルをそのまま受け入れることである。起こってしまったことは仕方がない。過去を取り消すことはできない。その上で再発防止策を含めて前向きに検討すればよい。

しかしそのまま受け入れることが意外と難しい。自分は我慢できたとして上司（あるいは顧客）は我慢しない。現場を知らないとその傾向は強まる。そういう上司（顧客）からたまには怒られることになる。因果なもので怒りは伝染する傾向がある。結局トラブルが発生したらなかなか冷静ではいられない。しかしそこは何とかするしかない。怒りや不安はトラブル対応には役に立たないのだから。

まずは冷静になること。問題の影響を正確に把握すること。次に事実と推論と意見を区別すること。希望観測が確信に変わってしまう人がいる。経験の少ない人に多い傾向である。誤った前提は非常に危険である。仮説と事実は明確に区別されねばならない。ここで初めて因果関係の適用を検討する。時系列で整理しどの事象が原因たりうるのか検討するのである。また原因から逆に影響を見直してみることにも意味がある。ウォーターフォール型の開発方法論を適用するとすれば適切なフェーズで出たトラブルなのか評価しておくのは有効である。

因果関係の適用は慎重にする必要がある。事象の発生を時系列で並べた時の直前のアクションが直接的な原因である。しかしそれには大抵意味がない。バグの直接原因はコーディングミスである。しかしその背景には様々な要因が考えられる。例えば仕様が甘い、コミュニケーションが取られていない、スケジュールが厳しすぎる、などなど。

ただし原因を抽象化し過ぎたり、時系列をさかのぼり過ぎるのも良くない。バグの根本原因はプロジェクトが開始してしまったことにある。そもそもこのプロジェクトはスタートするべきではなかった。おそらくは正しい仮説である。それでどうするか。社長に直訴するか。辞表を書くか。前向きなアクションには結び付かない。有効なアクションが取り得ない原因は良い原因ではない。それに対して良いアクションが取れるものこそが真の原因なのである。もちろん有効な真の原因が存在しない場合がある。例えば時間が足りない。繰り返しミスをする人間がいる（しかも他に人がいないためクビにできない）。昨今のコンプライアンスやら個人情報保護事情でインターネットやメール環境から遮断されたプロジェクトである。これらが原因ではどうしようもない。諦めるしかない。無論代替策は検討する。しかし根本的には諦める他はない。般若心経に「転倒」という言葉が出てくる。「あべこべ」という意味らしい。障害は起こるが障害が発生してはならない。出来ないのだが、出来なければならない。転倒とはこういう思い込みを指すのであろう。そんなことを思うから変なことになるのである。遠離一切転倒夢想が望ましい。

出来ないものを何とかしようとするから苦しいのである。始めから割り切ってしまえば苦しくも何ともない。そういうものだ、と受け入れればよいのである。受け入れた上で次善の策を検討する。そうするしかないではないか。「出来ない目標が掲げられても、一歩でもそれに近づくように努力するのが大事」という考えがある。正しい実践だと思う。ただしそれはあくまで本業に対して設定すべき目標である。本質的ではないところであがくのは時間の無駄である。

真の原因を設定するにあたり、プロジェクト運営の目的は何かを明確にしておく必要がある。これはまた手段の目的化を避けるためにも重要である。大抵のプロジェクトの目的は「良いシステムを作ること」であろう。だから「良いシステムを作るためには何をすべきか」が常に問われなければならない。トラブル発生時も同じである。良いシステムを作るためにはこのトラブルをどう解釈すべきか。淡々と直せば済むのか。それともその裏にプロジェクトの目的を妨げるような大きな問題があるのか。プロジェクト全体で対応する必要はないのか。

だが真の原因分析に時間を掛けすぎることもよくないし、些細な問題をおおごとにしてしまうのも結局効率がよくない。例えば仕様書のあいまいな記載に由来する障害で、真の原因は仕様書だ、と結論付けたとする。これは「過度の抽象化」という分析失敗例でもある。ここから仕様書のあいまいな点を全て洗い出す、という悲惨なタスクを考え出してしまう自己破壊的・プロジェクト破壊的な人が存在するのだ。大抵のプロジェクトではその作業対象は膨大であろうし、作業スコープも完了基準もあいまいになるであろう。結果、却ってプロジェクトの遅延を引き起こし、品質の低下を産みかねないのである。現実的に対応可能な効率的な作業によって対応できることまで見極めた上で、原因の分析を行う必要がある。要するに具体的な作業をあいまいさなしに定義するのである。ダブルチェックしてもミスは完全にはなくならない。それを知っておく必要もあるだろう。さもなければ後で「なぜチェックしたのにまたトラブルが起こるのだ」と無駄な負の感情が生まれる。

どの設定ファイル、プログラムを、この観点でこう調査する。「全ての」対象に波及させてはならない。「全てのプログラムで確認する」。件数によっては可能かもしれない。しかし、対象が膨大であれば、目視確認は諦めてプログラムに自動チェックさせてもよい。あるいはいっそ事前チェックによる洗い出しはあきらめ、テストしてしまうことを検討した方がよい。

観点をあいまいにしてはならない。「プログラムミスがないことを確認する」。これでは確認しようがない。どのようなミスなのかポイントを絞る必要がある。例えば「データベースリソースの開放忘れがないこと」。またチェック手順（どのようなキーワードで作業対象を検索し、どのポイントを見るのか）まで見極めておく。そして重要なのはそれでもなおトラブルが発生し得る、と認識することである。トラブルが起こってはならない。意識はそう思いがちであるが、それは精神衛生上良くない思い込みである。「トラブルが起きない方が望ましい。しかし大きなトラブルがいつでも発生しうる」が正しい。覚悟という言葉を聞かなくなった。トラブルは許されない。失敗は許されない。その裏にあるのは実は逃避なのではないか。「デッドライン」のデマルコが正しい。プロジェクトは腹を決めて運営するものなのである。

知ることはガンの告知だ、知る前と後では世界のあり方が変わってしまう。養老孟司氏の至言である。トラブルもまた同じである。これまでの想定が通用しなくなる。仕様書が変わりプログラムが変わりテストが変わり運用が変わる。トラブルが起こるのが自然ならば、それを受けて変更が発生するのもまた自然である。それを受け入れたらプロジェクトマネジメントが成立しないではないか。そんなことはない。要は考え方である。トラブルはあってはならない、と決めつけるのではなくトラブルは起こりえる、と認識することである。リスク管理もそこからしか始まらないではないか。トラブルにどう立ち向かうかが問われている。「トラブルなどあってはならない」という思いは単なる現実逃避である。

トラブルは許されないという思い込みからは「（トラブルを）なかったことにしたい」あるいは「出してはならない」という誤った衝動が生まれる。そしてトラブルを出さないように強く現場に圧力をかけることになる。トラブルをだすな、というプレッシャーはトラブルを隠す負のインセンティブとなる。現場のトラブル隠しがどのような結果を生むか。ここで敢えて述べる必要もないだろう。