Tech総研
2009/8/12
| あなたには、懺悔（ざんげ）したい過去があるだろうか。Tech総研が調査した、エンジニアたちの「懺悔」を聞いて、己を振り返り、戒めとしよう。（Tech総研／リクルートの記事を再編集して掲載） |
| はじめに 懺悔したい過去、ありますか？ |
エンジニア懺悔室では、心に引っ掛かっている仕事の過ちを吐き出して、すがすがしいエンジニアライフを送ってもらいたいという願いから、「仕事ではたらいた悪事」の告白を大募集した。掲載ができないような恐ろしい悪事ばかりが寄せられたらと、ドキドキハラハラしながら待っていた懺悔室だったが、「繁忙期の残業時に、外部からの電話を取らなかった（37歳 男性 業務アプリケーション作成）」といったささやかな悪事から、「コーディングのバグを隠すために、ユーザーの操作がおかしかったことにした（39歳 男性 Web系SE）」という限りなくブラックな告白まで、さまざまな懺悔の声が集まった。
結果、懺悔にどのような傾向があったかというと、やはり正々堂々と（？）悪意を持って行った行為より、「仕方なしにやってしまった」「結果的に悪事だった」という嘆きの告白が大半だった。内容をグラフで表してみると、いちばん多かったのは「報告義務を怠った（21％）」というもの。続いて「書類改ざん・虚偽の報告（20％）」と、こちらも報告義務に関連した過ちである。合わせて全体の約4割にもなる報告義務違反。これにはなにやら深くて暗い事情がありそうだ。
 |
図1 エンジニアの懺悔内容 |
次いで多かったのは、「未完成品を納品（17％）」！ まだ完成していない製品をリリースするとは、大問題に発展しそうな話だが、懺悔しているということは公にならなかったということなのか。それでは、悪事に至った詳しいいきさつを紹介していこう。
| 懺悔その1 報告義務を怠った |
| 本番間近にこっそり新規開発 |
引き継いだプログラムが、メンテナンス性・パフォーマンス両面から見て良くなかったので、本番間近にもかかわらず新たに作り直した。重大な問題に発展しないよう、デグレの面ですごく緊張しました。作っている間は、作業がバレないよう必死でした。
もともとあったプログラムのメンテナンス性が悪いので、修正作業を行うに当たって責任が持てず、作り直すしかないと思った。しかも作り直したらそのプログラムの信頼性がアップして、顧客に思いのほか感謝されました。（26歳 女性 アプリケーション開発）
| 緊急連絡は、内容が分かる人だけに |
顧客のサーバに問題が発生した場合は、連絡先の順番が決まっているが、毎回絶対に出ない担当はこっそり飛ばして次の人に連絡している。また、問題の内容を伝えても分からない人にも電話していません。分からない担当者に電話に出られても意味がないし、長くなるから仕方ないかと……。（30歳 男性 サーバ運用、保守）
| 説明よりも被害拡大の防止を優先 |
本稼働開始後に発覚した仕様ミスを、ユーザーが気付いていない段階で勝手に改修し、データ復旧も行った。本来は説明してから行うべきだが、説明をしている時間がなかったのと、時間がたてばたつほど被害が広がるので、なるべく早期に対応すべきと思った。悪意はないので、取りあえず失敗のないことだけを祈った。（39歳 男性 自社パッケージ製品の開発、導入）
| 懺悔その2 書類改ざん・虚偽報告 |
| 実現可能な機能でもNGに |
実装するのは可能な機能だが、プロジェクトの工程上、期日までの完了が不可能な案件を、「実装不可能」として稟議（りんぎ）した。プロジェクトの本筋の機能は充足していたため、特に問題にはならなかったし、プロジェクト自体は好評だった。
ITに対して理解は少ないのに要求ばかり大きい経営陣に、実装するためのコストとリスクを説明すること自体がリスクだと思った。工数は多いのに実益の少ない要求をのんでいたら、プロジェクト本体の進ちょくに影響を及ぼしかねない。結果としては良かったと思う。仕方ない。（35歳 男性 社内PCの総合管理）
| バグを水増し報告 |
バグがないにもかかわらず、当初から決められたバグ数があるため、バグがあることにしてユーザー向け結果報告書を書いた。融通の利かない品質管理体制が問題である。書いていてバカみたいだと思った。（38歳 女性 プログラマ）
| 分析装置の設定を甘くし、規格に合格 |
規格に合わないと製品がお蔵入りになってしまうため、分析装置の設定をぎりぎりまで下げて合格とした。かなり厳しい規格設定なので、幸いトラブルには至っていない。分析値は操作していません。設定を甘くしているだけです……。規格設定自体が厳しいんだから、顧客と規格変更の話をすればいいのに。（36歳 女性 工程製品の分析業務）
| 懺悔その3 未完成品を納品 |
| 信頼性は推測し、スピード納品 |
顧客から新製品の短期入庫要望に対して、長期間の信頼性において100％の結果が出る前に、その過程などから推測して「OK」と上司が判断し、入庫。しかし心配していた長期間信頼性に問題点が見つかり、更なる短期間での改良を余儀なくされた。徹夜を含むサービス残業の結果、問題点は改良したが、競合他社に勝つためいまだに100％の結果が出る前に入庫している。
このようなことは日常茶飯事なので、問題点が出たことに対してはなんの反応もなかった。ただ、開発者個人として、新製品を売るために競合他社よりも短期での提出が求められることに大きな疑問を感じている。100％完成してから新製品を提出したい。（34歳 男性 商品開発、製品改良）
| 変なメッセージが出たままに…… |
提出したシステムの現地調整期間に不具合が発覚したが、実害がない不具合なので修正せずそのままに。1年に一度出るか出ないかの頻度で変なメッセージを出力してしまいますが、実害はないのでご勘弁を……。ただ、不具合は不具合なので心が痛んでいます。（34歳 男性 制御系システム開発）
| 足りない分はパッチで補完 |
作業の納期が足りず、完全に検証できていないプログラムをパッケージとしてクライアントに納入してしまった。月例パッチのときに、少しずつ検証してない部分や足りない部分などを補完したためバレなかった。全部検証したいが、人も時間も足りないんです。（30歳 男性 プロダクトマネージャ）
| 情報漏えい、セキュリティ違反、見積もり額上乗せ |  |
| » ＠IT自分戦略研究所 トップページへ |
＠IT自分戦略研究所は2014年2月、＠ITのフォーラムになりました。
現在ご覧いただいている記事は、既掲載記事をアーカイブ化したものです。新着記事は、 新しくなったトップページよりご覧ください。
これからも、＠IT自分戦略研究所をよろしくお願いいたします。
