ソフトウェア開発者のキャリアハンドブック ―キャリアの不確実性を進み続けるためのガイド

13章敵

システムのアーキテクチャに致命的な、しかも修復不可能な欠陥が見つかったとしよう。出荷のわずか3週間前だ。損害は15万ドルにはなる。最悪の事態だ。開発チームは無能と言われても仕方がないだろう（訴訟になる恐れもある）。

ミスどころではない。大失態である。間違いなく大問題になる。考えただけで息苦しくなる。頭がずきずき痛むし、喉はからからになる。もう何も考えられない。ただ、「ひどいものを作ってしまった」という思いが頭を駆け巡るだけだ。

そういう問題は普通、誰か1人の人間の発見によって明らかになる。見つけた時は当然、大きなショックを受けるだろうが、大事なことはその先だ。最初の発見者がいかにそれを上司に伝えるかだ。個人的な思いはこの際、どうでもいい。それにどう対処するかが重要なのだ。

トラブル時の上司の態度

こういう時は、上司が常に冷静な人だと助かる。長年の経験を生かして、少しも慌てず手際よく事態を収拾してくれるような人であれば言うことはない。だが、いかに冷静な人だろうと、問題があまりに大きすぎれば、穏やかな態度ではいられないかもしれない。極度のストレスにさらされれば、どんな人でも人間性がまったく変わってしまうことがある。また、普段は誰も気づかないほどの小さな性格的な歪みが強調されてしまうこともあり得る。そうした現象について次に少し詳しく見てみよう。

質問魔

大問題が起きると、ともかく関係者にやたらに質問を浴びせる人がいる。「見つかったのはいつだ？」、「誰が見つけたんだ？」、「具体的にどういうことが起きるんだ？」、「どうすれば復旧するんだ？」などなど。

困るのは、こういう人は、色々な質問をしていても、本当に知りたいことは、たった1つである、ということも多いということだ。本当に何が知りたいのかは、いくつも発せられる質問をよく聞かなくてはわからない。すぐにミーティングをして、じっくり話し合うべきだろう。 ...