ドツボにハマったトラブル処理の「土壇場テク」


	変化が激しく、不慮の事態が多発しがちな今の時代。だからこそ「起きてしまったことにどう対処するか」――トラブルシューティングの腕前こそは、エンジニアとしての真価を問われる重要ポイント！　そんな実例、集めてみました。（取材・文/河馬田英毅総研スタッフ/木下ミカエルイラスト/森俊憲）作成日:04.04.28

「備えあればうれしいな」……じゃなくて、「備えあればうれいなし」とはいうものの、いくら備えても降りかかってくるトラブル。見事解決、むしろプラスに変えて拍手喝采！――それともますます傷口を広げて地獄落ち。その運命の別れ道は、いったいどこに？


		「うわっ、しまった！　やっちゃった！」はだれにでもある経験。設計ミスに発注ミス、説明不足や思い込み……。落とし穴は、エンジニアの日常のそこかしこに潜んでいるもの。そこで慌ててはさらにドツボに……。



	試作した装置の部品が図面どおりできていなかったのに、良品として受け入れＯＫしてしまった。そのため、組み立てのときに所定の性能がでなかった。



	データの加工に関して、他システムにおけるデータ形式を誤認し、受け渡し先のシステムがダウン。納期が非常に短かったとはいえ、連携テストをしっかりやっておくべきだった。


	●対処テクニック発注元に対し、自分の見落としを正直に認め、やり直すチャンスをもらった。具体的には、誤ってできてしまった形状に合わせてバネを再発注してしのいだ。


	●対処テクニック３時間程度で復旧できると思い作業にかかったものの、結局一日かかってしまい、最終成果物の作成が遅れ、エンドユーザーから苦情が殺到した。



	プログラムの一部を修正作業中に処理が起動してオンラインが停止。にもかかわらずその停止していることに気づかず、オンライン２時間停止で、甚大な被害をもたらした。



	あるシステムでデータベースが壊れた。何とか稼働していたのでバックアップを取って再構築を試みたが、その前に、前提となった作業結果をきちんと確認してから行うべきだった……。


	●対処テクニック顧客が望んでいることを考えながら、誠意をもって打てる手は先に打つこと。作ることのできる資料はすべて作成、再発防止処理に力を入れていることを顧客にアピールし続け、何とか怒りを収めることができた。


	●対処テクニック再構築の手順を間違え、それに気づかなかったため、一部データが消失！約40時間かけ、できる範囲でデータ修復を行ったが、一部は顧客が一から作り直すことに。


		ミスは部下に押しつける上司、嫌な仕事からは逃げちゃう後輩……「なんでアイツのミスを！」と思っても、それが組織で働くうえでの宿命。潔く諦めて、では、そこで打つ「次の一手」は？　うまく対処できれば、周囲の評価も格段にアップ？



	担当者が突然退職。仕事を引き継いだが、あまりにもいい加減だったため、振り出しに戻ることに。納期面で顧客に迷惑をかけた。



	社内異動後に前任のミスが発覚！そのフォローと顧客の信頼を取りもどすのに半年もかかった。


	●対処テクニック確実に進行しているということが顧客にはっきりわかるように、進行状況を細かく伝えるようにした。起きてしまったことを悔やむより、できることに対して全身全霊を注げば、相手も人間、わかってくれる。


	●対処テクニックとにかく毎日お客様のところに出向き、ご機嫌うかがいの毎日。なによりも人間関係を構築・修復することに力を注いだ。「コイツならしょうがないか、許してやるか」と早く思わせることが大切だと思う。



	大々的な販促キャンペーンの資料の記載内容にミスがあり、社内外からその問い合わせが相次いだ。


	●対処テクニックすぐに担当の営業部門に対し訂正のメールを入れたが、営業があまりメールをチェックしておらず、ほとんど連絡が伝わらなかった。大量のメールに埋もれてしまうことを考慮して、販促キャンペーンのリーダーに報告し、そこから連絡をしてもらうべきだった……。


		どんなに綿密に考え抜いても、トラブルは起きるもの。「これまでにない、新しい何か」を生み出すエンジニアだけに、予期しない出来事もまた不可避。そんなときこそ問われる力量とは？



	あるシステムの最終動作テスト中、開始まであと30分というときになってエラー発生。データベースが壊れてデータが読めなくなった。



	社内イントラを設計・稼働させたが、アクセスの集中に耐え切れず、システムがまともに動かずにダウンした。


	●対処テクニック会社に問い合わせ、原因の特定方法を確認。一人で解決できるトラブルには限界がある。いざというときにどれだけの支援を受けられるかどうか、常日ごろのギブ＆テイクが大切。


	●対処テクニックサーバのスペックアップで耐え切れるという業者の言い分を信じてさらに投資したが、改善できず投資は無駄に。実は初期設計段階の見積もりミスにすべてが起因していた。



	一括受託案件で、ユーザーから、仕様変更といえるバグ報告が続出。予算も期間もなくお手上げ状態となった。



	パッケージソフト開発にあたることになったが、集まったメンバーが、業務知識のない人ばかりだった。


	●対処テクニックバグと仕様変更の切り分けを明確に実施。バグは連日徹夜で改修、仕様変更は別途予算とスケジュールをとって実施。顧客には可能な限り譲歩するが、譲れない部分は曖昧にせず、キッパリ切ることが大切だと思う。


	●対処テクニック知識不足を人で補おうと、増員をお願いしたが、知識がない人ばっかり集まってしまった。すぐ上のボスがまったく頼りにならかったので、もう少し違った角度から、人の手配をお願いすればよかった。


		「人は石垣、人は城」というように、チームで動くなら、その綿密な協力と人間関係こそが、仕事を円滑に進める第一条件。とはいえ、その人間関係こそが、一筋縄ではなく難しい……。



	顧客側の担当者の一人が「業者いじめ」。プロジェクトに参加したこちらのグループメンバーに無意味な嫌がらせをし続け、人材がどんどん失われた。



	部署を異動した際、後任者が仕事に対する意欲に欠ける人物で、せっかくそれまでいい状態だった職場の士気がすっかり下がってしまった。


	●対処テクニック客側とは稼働日を変えて、その人と接触しないですむように環境を整えた。一時の顧客より大切なのは人材。人材を失えば、次の仕事につながらない。


	●対処テクニック前任者として、できうる限りのサポートをしようとしたが、かえって反感を買ってしまった。後任人事について、あらかじめ、もっと積極的に意見を上申すべきであった。

「厳しい状況でどう考え、動いたかを知れば、その本人のポテンシャルがわかる（某社人事担当）」とか。もちろん、いろいろな事態をあらかじめ想定しておくことは大切。でも、どうしても不測の事態は起きるもの。それに対処する能力は、事前の綿密さと両輪をなす、エンジニアにとっては必要不可欠なものといえそう。

　さて、今回の調査で見えたトラブルシューティングの第一条件は、当たり前ではあるけれど、「まず、動転しない」こと。「なんとか乗りきった」ケースに他人のミスに対処した事例が多く、「裏目に出た」ケースには自分のミスに関する事例が目立ったのも、他人のミスほど冷静に対処できるからではないだろうか。「原因が自分でも、スパッと気持ちを切り替える」――これがなかなか難しいのも、また、確か。

　もう一つ、どうしても外せないのが、コミュニケーション能力。トラブルが大きいほど、迷惑をかける人、協力を仰ぐ人も多くなる。ここでムスッと黙り込んだり、周りに当たったりしたら、ますます傷口を大きくするだけ！　信頼を回復するにも、処理を手伝ってもらうにも、「よい人間関係」は基本中の基本。普段、周りのだれかがトラブルに困っていたら助けるよう心がけるのも、「もしも」のための保険になるかも。……もちろん、自分ではできない「助け」まで買って出てしまうのは、余計なトラブル源になってしまうけれど。

　先行き不透明なこの時代。企業でも、ますます「いざというときの対処能力」＝「土壇場力」は高く評価される。トラブルは起きないに越したことはないけれど、起きてしまったトラブルは、そんな「土壇場力」のスキルを磨く機会だとも考えよう！