作業ミス論

蓋しIT技術者にとって作業ミス撲滅は永遠の課題である

それは、企業の人的コストや、政治的なしがらみや、人間関係や、様々な事情の絡み合いからふと生じる歪みを狙ってくる。複雑な大人の事情が絡み合う中、現れるべくして現れた脆弱性をついてくる。会社の膨大な情報の、ほんの一部しか知りえない現場の人達は、人智の限りを尽くして再発防止策をひねり出す。それは声出し確認程度かもしれない。指さし確認程度かもしれない。増員の要望かもしれない。マネージャ層の防止策案は、既存のオペレーションの自動化かもしれない。そのための開発費用や追加コストを算出して、経営層へのプレゼンを作り込んでいるかもしれない。しかし企業の全財務状況まで把握している経営層は、そんな部署の頑張りには目もくれず、彼らが所属する部署自体をアウトソースしてしまうかもしれない…。部署ごと消えてしまうかもしれないのである。

しかし、作業ミスをきちんと分析し改善策を講じることで、会社としての質も上がっていくのは事実だ。その会社の作業マニュアルや承認印欄の数は、その会社のミスとその対応の歴史を物語っている。
断っておくが、こと作業ミスに関しては、ピンチをチャンスに変えるなどというポジティブ・シンキングはやめたがよい。お客様にご迷惑をお掛けした上に、これをチャンスに変えてやろうなどとは虫が良過ぎるというものだ。ポジティブ・シンキングもここまでくると厚かましいを通り越して穢らわしい。作業ミスが発生したら、張本人が誠心誠意対応し、お許しを得るのだ。そして、再発防止を誓うのだ。そのためにも、徹底的にミスを分析するのだ。そこで全力で責任逃れをするような視点の狭い近視眼的な人間は、以降永久にIT機器にログインしてはいけない。

これから紹介するいくつかの失敗談は、秘密保持契約に抵触する恐れから、いずれもインターナップでのそれではない。が、いずれも実話である。国内及び海を越えて集まったインターナップのエンジニア達の過去の職場に於いて発生したインシデントのうち、最も示唆に富むものを厳選し、臨場感を出すために私がストーリー風に仕立てたものだ。物語としても充分楽しめると思う。が、再度断っておくが、実話である。

---

事例1 テストメールの恐怖
A君が勤める、某企業の情報システム部のある日のこと。問い合わせもなく午後の平穏なひとときを、一通のメールが破った。
「テストメール。吉田だよんびろ～ん」
A君は思わずコーヒーを吹いた。
犯人は、業務システムの開発を委託している、担当ベンダーの技術者である。この日、犯人の吉田君は客先であるA君の会社に朝からお邪魔して、バージョンアップ前の試験をしていた。そして問題のメールを、業務システムの試験環境から誤って送信したものである。
今までは試験環境では、外部へはメールが飛ばない設定になっていた。ところが月次処理の後に送られるメール本文が、文字種によって文字化けすることがあるとのことで、試験環境のメールも一部の関係者にだけは飛ぶようになっていたのだ。
そんなことはつゆ知らず、相変わらずメールはローカルに保存され、外部へは飛ばないものと思っていたのだろう。報告を受けて泡を食らったベンダーの上長が、即日誤りに来たそうだ。びろーんの吉田君も一緒だったのは言うまでもない。

教訓）
ここで、テストメールでふざけてはいけない、などとしてしまうとせっかくの失敗が敷衍されず非常にもったいない。ここは是非、テストという行為の本質を考えるべきだ。
そもそも、なぜ「テスト」をするのか。動作に確証が持てないからだ。確証が持てないからこその「テストメール」なのに、従来通りローカルに保存されるだろうと前提するのが間違っている。テストなのだから最悪のケースでは全世界の人達に送信されるかも知れないと考えるべきだ。

---

事例2 期待の新人の暴走
B君は以前、IT人材派遣会社に勤めていた。そこでB君の直属の部長と新人コンビが、常駐先で起こした不祥事である。B君はこの部長と特に親しく、部長はこの貴重な失敗談を居酒屋で愚痴混じりにB君に語ったそうだ。ビール片手に、目の前の皿には唐揚げがてんこ盛りである。B君は部長の脂肪肝も心配だった。
彼らはUNIXシステムのインフラ担当であった。お得意様企業の業務システムである。その日、何らかの構成変更作業のため、部長と若手の新人の二名体制で作業をしていた。部長が作業手順書を作成。訓練を兼ねて新人がUNIXコマンド実行者であった。

あるコンフィグファイルを変更しようとしたところ、permission deniedで変更できない。ちょっとお客さんに確認してくるわ、と部長は席を外した。
悲劇はこの数分のうちに起こった。UNIXを覚えたばかりだったのであろうか。新人はroot権限で、もしくは限りなくそれに近い権限だったろう、問題のコンフィグファイルのファイル所有者を、自分達の外部ベンダー用アカウントにchownした。「こうすればできますよ、部長！」とばかりに。
コアなファイルの所有者が、業務システムユーザーからペーペーアカウントにまで格下げされたものだからたまったものではない。このファイルを参照していた業務システムのプロセスが異常停止し、業務システム全体も止まった。その後の復旧にも相当時間がかかったらしく、社長も謝罪に出向く大惨事となった。
…B君は、部長に掛ける言葉もなかった。皿に残った最後のから揚げを譲ってあげるのが精いっぱいだったそうだ。

教訓）
これは難しい。ツッコミ所が満載である。インフラを構築したベンダーだからと言って、rootパスワードを握ったままであったこと。前後の影響も顧みず、新人が暴走し手順書に記載がないことをやったこと。コマンドの使い方は知っていても、その操作が及ぼすシステム全体としての影響までは、勉強していなかったこと…
しかし、だからこそ2名体制のOJTだったのだ、とも言える。同じ手順書を見ていながら、新人の方は何を見ていたのか。部長が覗いている望遠鏡を、新人は大きいレンズの方から覗いていた感がある。

私が部長なら、こうだ。この手の新人には、仕事と遊びの違いを骨身に徹するまで理解させる必要がある。学生と社会人の違いを叩き込むのだ。お前がログインするマシンは、お前の所有物じゃあない。顧客企業の物だ。そもそも、ビジネスの場に於いてお前の所有物などない。コピー用紙一枚に至るまで会社の物だ。この作業により、作業費用が発生しているんだぜ。ビジネスの場では、いかなるペーペー社員であろうとも、一人の人間が動けば金が動くのだ。こいつまだ新人なんで、タダで使ってやってください、えへへ、なんてケースは絶対あり得ない。否、先方は金を払ってでもマトモな奴を望むだろう。できる・できないではない。ビジネスの場では、「やる」しか選択肢はない。お前ができなければ、できる者を探すだけの話だ。替りはいくらでもいるのだ。そこにお前の自由意思はない。UNIXコマンドの練習は、自宅で思う存分やってくれ。自宅にSun Fireがあればの話だが。

さて、新人君も今や社会の厳しさを知って、半べそ気味である。だが、ここで手を緩めてはいけない！この手の若い奴は、注意を受けている場では意気悄然として見せ、おや？少々厳しく言い過ぎちゃったかしら？などと逆に心配気を起こさせて「ガム食べる？一枚あげるよ」なんてよく分からない気を使わせておき、その後同僚と飲み屋で大いに私をやり玉に上げているものなのだ。私の手厳しい教育は続く。

手順書が何のためにあるか、分かるか。この手順に登場するコマンドは、検証環境で正常動作を確認したものだ。お客様にも、この手順で行きますよ、と承認を得たものだ。逆に言うと、ここに書かれた順序・手順以外のことはしませんよ、約束したこと以外のことはしませんよ、ということなのだ。ほら、ここにお客様承認印があるだろう？お客様は、我々が知らない彼らの業務システムの開発ベンダーにも、この手順に問題がないか確認してくれたことだろう。だから承認に1週間かかったのだ。遊んでいたわけじゃないんだ。
なぜここまで慎重になるか分かるか？第一に業務システムありきで会社全体が動いてるからだ。これが止まると、会社全体の仕事が止まるのは分かるだろう。ひょっとすると海外の支店とも連携しているかもしれない。日本支社だけ周回遅れになるだろう。

今回のシステム停止がそのまま失注につながるようなことはないかもしれないが、パソコンでやっていた仕事をFAXや紙ベースでやるんだから購買チームの方達の残業は確定だろう。子供の保育園の送り迎えにも差支えが出るかもしれないぜ。保育園のお迎えの時間を遅れるとどうなるか知ってるかい？先生に嫌味を言われるんだぜ！いや、話をそらしてはいけない、残業代もかかる。つまり想定外のコストが発生するのだ。
第二にシステムもここまで大きくなると、一つの構成変更の影響がどこに及ぶか？我々一社だけでは予測がつかないのだ。何故なら我々はインフラという一部分を受け持っているだけで、その上で動く主役の業務アプリの事はまったく知らん。我々インフラチームは、インフラの事しか見えない。パズルの一ピースに過ぎないのだ。だからこそ、全体を見渡し統括しているエンドユーザーに承認を得たのだ。

…ここに至って新人も、一つのITシステムに纏綿と絡まる蔦のような関係が、商流が、利害関係が、見えてきたようだ。本当の意味で学校を卒業した、とも言えよう。

---

事例3 英語読めない事件
C君は以前、この業界では有名なデータセンターでデータセンター長をしていた。現場オペレーター数人を管理していた。
有名な外資系企業のデータセンターの、立ち上げ事業。にも関わらず、募集要項は未経験者OK、学歴不問、しかしシフト制で一日12時間労働、時給は最低賃金すれすれといった過酷なものだった。
集まるべくして集まったメンバーは、予想通りのつわもの達であった。一人は極度の近視で視界がほぼゼロにも関わらず、生活苦のために眼鏡を持っていなかったそうだ。つまりパソコンのモニターが見えていなかったわけだ。一人は栄養不足のために終日うつろな目をしていた。つまり、常にメール誤送信やオペレーションミスと背中合わせの状況だった。目が見えてもいなければ、注意力も散漫なのだから。C君はとんだ現場に投げ込まれたと震え上がったそうだ。そして、センター長として彼らの一挙手一投足に目を配った。メールも当然、送信前にC君がチェックした。

しかし事件はメール誤送信よりも、意外な形で現れた。オペレーターの一人が月次バックアップテープの交換で、違うテープを挿入してしまいバックアップデータが消えた、というものだ。Julyのテープを入れるところを、誤ってJuneのテープを挿入したのだ。
作業ミスの一連のフローを再現し、事実ベースで事故調査をすると、意外な事実が見えてくるものだ。C君は早速お客様へのインシデント報告のために、担当者を捕まえて当日のオペレーションを再現してもらった。

「ここでワンビシのケースを開けると（手順書に）あるね。開けてみようか」とC君。ケースをぱかっと開けると、なるほどLTOテープが6本所狭しと並んでいる。手順通りだ。
「今月は7月なので、ジュライ（July）のテープを入れるとあるね。Julyのテープを出してみようか」とC君。
「あ、これジュライて読むんですか」とオペレーター。
「へ？そう、ジュライだよジュライ。7月ね。今月は7月でしょ」
「あ、Julyって7月って意味なんですね」
「ちょっと待った！あなた英語読めないの！？じゃあこのずらっと並んだテープのラベル名が月を意味してるってのも、知らなかったの！？」
「なるほど、そうなんですね。これ、全部月を意味してるんですか。はい、まったく知りませんでした」
C君は卒倒したそうな。よく見ると、手順書にはJanuaryやFebruaryとあるが、テープのラベルだと書き込むスペースが狭いのでJanやFebと省略形で書かれている。しかもサーバ名や何やら手順書にはないアルファベットが犇めいている。英語が理解できない彼にとっては象形文字を読み解く感があったろう。
C君は顧客に対し、手順書とLTOテープのラベルの表記を一句違わず合致させるよう要求した。外資系を謳うデータセンターで、さすがに英語分からない奴がいるので、とは言えなかったそうだが。

教訓）
私が冒頭で、複雑な大人の事情が絡み合い云々と書いたのを思い出して欲しい。その後C君が現場のオペレーター達とカイゼンに取り組んでいる或る日のこと、電撃的にC君の会社が世界的に有名なIT企業に買収されたというニュースが、IT業界を驚かせた。そんな大きな話が背後で進行していたなど、C君は知る由もなかった。そして、あれよあれよという間に、その年の忘れもしない8月1日の朝イチのメールで、C君はじめオペレーターもろとも、馘首されたのである（幸いC君は子会社からの出向だったので、出戻り先があったそうだ）。
つまり、C君チームは時間稼ぎだったのである。買収のニュースが公になるまで、最も安いコストで形だけデータセンターが回っておればよかったのだ。データセンターのその後は、C君も知らぬという。ほんの数社だったが、お客様のラックが入っていたそうだ。少ないこのお客様達も、大人の事情で別のセンターに移ったか手切れ金でデータセンターからの引き上げを余儀なくされたかもしれない。C君チームの存在条件が時間稼ぎなのだから、現場レベルでカイゼンに励んでも、まったく一人芝居だったのである。回し車を回すハツカネズミの如しだ。

いかがであろうか。皆さんもぜひ、作業ミスのない平和な現場を実現すべく奮闘して欲しい。作業ミス撲滅は、複雑な社会的関係との闘いでもある永遠の課題なのだから。

技術部 間庭