反省

この数日で起こったシステム修正に関するごたごたについてちょっと反省してみた。

22日夕方、頓服の安定剤を飲んで頭が朦朧としているところで仕様変更が入った。既にシステムは22日朝から使用中。簡単なウェブアプリケーションであるから差し替えは難しくないのだけれど、過去の資産を代々継承してきたもう触りたくもないような汚いソースである。あちこちにグローバル変数が散在して予期せぬ副作用があり得るので恐ろしい。マネージャーは休暇中ということで私がやるしかない。

しかも、仕様変更と言うよりは、打ち合わせ段階でのこちらの仕様の把握が間違っていたらしい。顧客側との仕様の認識にギャップがあったことと、顧客側の現場のオペレータの手抜きが重なって既に貴重なデータがいくつか失われている。

幸い、当該モジュールに関しては10時-18時しか使われないし、連絡が入った時点で既に18時を過ぎていたので何とか翌23日朝までに直せば良い話。でも、私はあと数時間は薬で頭が働かないし、このスパゲティをこの朦朧状態で触ったら間違いなく事態を悪化させる。仕方がないので、お客さんには「翌朝までに確実に」ということで納得して貰って、私は回復したら修正に入ることにした。

……のだけれど、結局システムが利用される直前の23日10時5分前に修正完了というぎりぎりの状況となってしまった。原因はいくつかある。

  • 20日-22日にかけて私がパニック症状でダウンして家にいた。

    • 途中で出社すると、私の移動中はシステムトラブルに対処できる人間がいなくなるので、そのまま在宅で作業するのを選択したのだけれど、今回に限っては選択ミスだった。
    • リモートでの作業なので会社とのコミュニケーションが緊密でなかった。今回の仕様のおかしな点については予めちょっと違和感を感じてはいたのだけれど、ある意味ではあり得る仕様だったので、わざわざ会社に連絡してまで指摘はしなかった。
  • 私が復活した時点(22日21:00)ではお客さんに応対した担当者と連絡が取れず、修正後仕様の厳密な確認がとれなかった。

  • この20日から、調子を崩してるのを頓服薬でだましだまし動いてきたのがたたって、復活後また発作を起こし、気がついたら23日朝。
  • お客さんから23日朝7時になって追加の変更が入った

反省するとすれば

  • システム提供開始という状況では、システムメンテナンスのできる人間は現場にいないといけない。やっぱり、移動時間やパニック発作のリスクを冒してでも出社すべきだった。
  • リモートで作業する場合でも連絡は緊密に。メッセンジャーでも何でも使おう。やっぱり、可能なら同じ空間にいるのが最良。
  • 引き継ぎ、情報伝達、確認は十分に。

    • 21日のアプリケーションの提供はかなり前から予定されていた。にも関わらず、休暇に入る前にお客さんとの打ち合わせを行ったマネージャーや、実装を行った担当者とコミュニケーションが十分でなかった。私は直接の担当でなかったので、修正依頼が入り出すまで経緯や仕様をよく把握していなかった。
    • 20日にあったちょっとした修正依頼について、修正を行ったにも関わらず何度もお客さんから催促が入った。社内の連絡不備で、修正確認用のURLがそれ以前のものと異なるものに変わっているのがお客さんに伝わっていなかったと思われる。
    • データ喪失についても、私が20日に最初にソースを見た時点でちょっと違和感を感じた仕様が原因であった。仕様確認段階での担当者のミスと、「あり得なくはない」ので確認を取らなかった私の怠慢と、お客さんの現場オペレータの手抜きと、3重のヒューマンエラーである。
  • 23日朝になって入ったお客さんからの最後の修正依頼は、初めから社内で「この仕様で大丈夫か?」と危惧されていた部分であった。もっと積極的にプロとしての助言をすべきであった。

  • 古い資産を無理に使い回すべきでかなった。多少の修正は必要だったと思われるが、私が作ったもっとまともな作りの似たようなモジュールはあるので、そちらを使うべきであった。
  • 今回起きたような問題はこれまで、全てマネージャーがカバーしていたと思われる。現場がマネージャーに頼りすぎ。そのことに現場が気付いていなかった。