今だから笑える！完璧主義エンジニアの失敗自慢30連発

基礎データ集めに仕様設計、細部の詰めにトラブル対応、それに日常のアレコレの事務……。手早く片付けるためにも、仕事の効率化・省力化は必須！――ところがそこには、時に大きな落とし穴が……。

（取材・文／河馬田英毅　総研スタッフ／宮みゆき　イラスト／いぢちひろゆき）作成日:05.05.11

好きでなったエンジニアとはいいながら、「好き」だけでは乗り切れない、細かい仕事に忙殺されてしまうのも、また事実。「本命」の仕事に完璧を期すためにも、優先度の低い仕事は、手早く片付けたいのが人情ってもの。しかしやり方を間違えると、失敗を招くことも！ちょっとの油断が招いた大失敗30例を、エンジニアの日常業務シーン別に紹介します！

設計自体は、バッチリ完璧に完了……だったのだが、設計した自分自身では“わかりきっていること”だったため、仕事の資料を一部省略してしまっていた。（32歳／通信インフラ設計・構築）

業務を頼む他部署には、資料の欠落から、設計と作業の手順がうまく伝わっていない状態に。実際に構築を始めたあとで、資料の欠落から工事がストップ！

提案書に、安直に考えたことをそのまま採用してしまった。（33歳／コンサルタント）

いざ実際に提案の場で、お客さまからえらく突っ込まれ、訂正するのに苦労した。

理論上問題が起きないと思っていた部分のテスト確認を、簡単に済ませた。
（31歳／パッケージソフト・ミドルウェア開発）

インテグレーションがらみの問題が発生し、リリース後にバグを受け取った。

問い合わせを減らすため、保守システム変更時の戻し手順をユーザーに伝えなかった。
（35歳／テクニカルサポート）

夜間の本番処理で異常が発生し、緊急コールを受けて、大パニックになってしまった。

手間を省くために、ソースレビューを簡略化した。（34歳／システム開発）

その結果、低レベルな障害が頻発するはめに！

現場の下見に行ったのだが、優先順位の低いところは簡単に済ませた。（30歳／機械・機構設計）

しかし実際に作業に入ったら、干渉物があるのを見落としていたことが発覚。結局、後から設計をやり直すはめになった。

システムバージョンアップを一斉に行うべきときに、ある部署の端末が利用中。しかたなくその部署だけを後日に。それでも作業はちゃんとやったつもりが……。（30歳／社内情報システム）

1カ所だけバージョンアップが遅れていたことが原因で、データエラーが発生！　データ修復に、思いがけず大きな時間を割かなければいけなくなってしまった。

運用で行っているデータ変更のためのSQLのチェック。いつも実施している変更だったので、手早く済ませたら……。（33歳／システム開発）

チェックに抜かりがあって、データを誤って変更してしまっていたことが判明。徹夜での復旧作業となった。

自動実行JOBの定義方法を理解したつもりで、調査せずに作業を行ってしまった。
（34歳／システム開発）

トラブル発生！　翌日の自動JOBをすべて止めてしまった。

一見、似たような案件で、それほどコストに差はないと思い、昔のデータを引っ張り出して、素早く見積もりを作成。（36歳／システム開発）

後から、意外なほどに大きな開きが出てしまい、大汗かきながらやり直すはめに。

本来やらなければいけない、ソースのバージョン管理をアルバイトに任せた。
（31歳／システム開発）

リリース後にデグレードが発覚！　入力されたデータの整合性まで損なわれる結果に。

試験不足のまま、長年の勘と思い込みで、バグ修正をしてしまった。（30歳／システム開発）

量産が始まってから、バグ発覚！　量産後の再修正となってしまった。

ユーザー向けのシステム開発。何かと口うるさい客先で、報告をするたびに余計な突っ込みを入れられるため、それが煩わしくて、つい独断で仕事を進めてしまった。（33歳／システム開発）

システムそれ自体としては申し分ないものに仕上がった……と思ったのだが、肝心なところでユーザーのニーズから外れた部分があり、導入後に慌てて直すはめになった。時間もコストも膨大なロスに。

ほかのSEに口頭で仕様を伝え、プログラム確認をするようにと言ったのに……。
（26歳／システム開発）

プログラムが仕様どおりに作られていなかった。伝えた内容をメールやドキュメントで残していなかったので、私の責任に（泣）。

他コンポーネントのインターフェースの不明部分を、自己解釈で済ませてしまった。
（27歳／研究・特許）

大勢がかかわっている問題だったので、ほかのグループに迷惑をかけた。

上司に相談する時間を惜しんで、勝手に外注先を決めた。（32歳／システム開発）

外注先選定を失敗し、プロジェクトが回らなくなってしまった。

サーバーの設定設置作業で、うるさい上司への報告を後回しにした。（31歳／テクニカルサポート）

結局、報告するのを忘れ、社内で大騒ぎになった。顛末書を書かされた。

しばしば発生する仕様変更。当然、ドキュメントに反映させなければならないが、作業を減らすためにいくつかの仕様変更をまとめてやることに……。（35歳／システム開発）

生産物に反映されない部位が出てしまい、結果、カットオーバーが延々と延びてしまった。

まだプログラマをやっていたころの話。検証作業が終わったロジックを見直していて、試験項目では発生しない不具合があることに気がつき、『今気づいてよかった！』と自信満々、修正を加えて導入に臨んだ。（30歳／コンサルタント）

想定された動きを全くせず、導入失敗で出直しに。プロジェクトのメンバー全員で再検証したところ、自分の加えた修正が原因でほかの動作を阻害していることがわかってメンバーに迷惑をかけた。……実はその修正自体の再検証を行っていなかった。

本来、コンフィグを全部見直さないといけないところ、ざっと確認するだけで済ませた。
（32歳／ネットワーク設計・構築）

実際にはほかの人が触って変えたところがあったのだが、それに気づかなかった。ルーティングが変更されてしまっていて、問題に。

単体試験を簡略化して、絶対無理な納期に間に合わせた。
（30歳／パッケージソフト・ミドルウェア開発）

バグが多発!!　大騒動に（泣）。ユーザーへの説明およびおわびによって、見積もりの３倍近い日数が必要に。

製品の検査のうち、まずほとんどミスのないところの検査を省略した。
（30歳／品質管理、生産管理）

たまたまそこにミスが発生し、始末書を書くはめに。

ある簡単な修正を行ったが、ソースコード上で机上でのみの確認で、実機での確認をせずにリリース。（34歳／システム開発）

結局、報告するのを忘れ、社内で大騒ぎになった。顛末書を書かされた。

次から次へと開発案件が山積みされてくるので、つい確認作業に手を抜いた。
（31歳／システム開発）

実を言うと、量産品の裏テストモードに今もバグが入ったまま（！）発売中。

お客様からの報告に基づき、納入したシステムのデバッグ作業（ここまでは当初予定にしっかり組み込み済み）。なかばルーティン的なデバッグも多く、手早く済ませてしまったら……。
（36歳／システム開発）

本格稼働開始後に、重大な事故が発生。お客さまの業務に直接障害が出るものだったので、数億円の損害賠償を請求されるところまで問題が深刻化してしまった。

急ぎの作業を優先するため、顧客からの問い合わせをつい後回しにしてしまった。
（34歳／システム開発）

周りの人が回答してくれたので、難を逃れたが、そうでなかったら大変なことに……。

お客さまが気づいていない欠陥を見つけたのだが、忙しくてそのままにしてしまった。
（35歳／サービスエンジニア）

しかし間もなくお客さまのところでも発覚。数日後に電話がきた。大目玉（涙）。

トラブルが発生したものの、そのうち自然に沈静化。大きな問題とならなかったので、そのまま後処理をやらず放置していたが……。
（34歳／テクニカルサポート）

後になって再燃。早めにやっていればかけずに済んだ手間が、大いにかかった。

後輩にマニュアルを渡しただけでトラブル対応させた。（33歳／テクニカルサポート）

結果、後輩がミスをして状況が悪化！　その前にちゃんと教育しておくべきだった……。

お客さまからのクレーム案件があったのに、処理が面倒で、つい先延ばしに。
（29歳／テクニカルサポート）

結果、お客さまから対処が遅いとさらにクレーム。クレームの上塗りになってしまった。

　細かい作業の連続になることも多い、エンジニアの仕事。膨大な日常業務をこなしていくうえで、つい無意識に手抜きをしてしまったり、うっかりミスをすることもある。むしろ「完璧主義」のエンジニアこそ、そんな落とし穴にはまりやすいともいえる。

　それを防ぐには、逆説的ではあるが、「上手な手抜き術」を編み出すことが大切。緊張の連続は、無意識に気の抜ける瞬間をつくってしまうもの。むしろ、押さえるべきところは押さえながら、「意識的に気を抜いてもいい部分」をつくることが、失敗の予防線に。もちろん、「単なる手抜き」は厳禁だが……。