現場リアル物語③：過去の惨劇を超えて

前回までのあらすじ

前回までの私は、古の仕様書と正しさを証明しないエビデンスで、正解を探す旅をしながらテストを通して祈っていた。
…仕方なく単体テストは「今の挙動が正」という謎エビデンスだけを残し、一旦幕を閉じた。
そして次に来たのが、現新比較──現行環境と新環境の結果が一致するか確認する、だけのはずだったが…

あれから数日。

最近の社内は社員の溜息や悲痛がBGMと化した。

私はというと、どの角度が一番祈り届きやすいかを試行錯誤し分かってきたところだ。(努力の方向性おかしい)

…現新比較の環境替え…未だに受け入れられない現実。あの準備してきた日々は何だったんだろう…いや、問題ない。実は横展開できるようにもしてある。

私は個人開発で知っているんだ。エンジニアは聞いたことがあろう、SOLID原則のO、OCPを活用し、多方面で使えるように準備してきたではないか。¹

そうと思いながら出社し、届いてたSlackの通知。渡したデータが壊れていたと判明。

よかった…

最初にそう声が漏れた。色々漏れそうだった。
脳汁は漏れていたと思う。

どうやらあの方針発表後に再調査が入ったそう。
そこで本番環境と今のテスト環境に差異は認められなかった。再テストする必要はなくなった。

色々と差分の発生箇所を見ていくとテストで使う本番データは別のディレクトリと判明した。
つまり今回の原因は拾ってきた本番データの加工前がしっかり取れていなかったことが確定したのであった。

大きく安堵した。いや、だか私は知っている。こういう時にまた変なものが発生するんだ。いつもそうだったんだ。構えておこう。

そう思い、テストを回す。　

エラー0件　正常終了

あ、問題なく動作した、良かった良かった。

だがこれは今回から変わったテスト環境ではない。それでも、今までの自分の頑張りテストを認めたくて、信じたくて。例え今回のテスト環境でなかったとしても無事に本番データが通り、テスト含め問題なかったと証明された瞬間である。心が躍った。跳ねていたかもしれない。

いや、待て待て待て。
普通に本番環境からの逆デプロイだから通って当たり前やん。何感動しとんねん。危ない危ない。

などと頭の中で会話しながら、
今回のテスト環境の詳細とテストの方向性を報告ついでに上司に確認する。

テストの内容はこうだ。

• 今までGUIで動作していたものをCLIからshellをキックすることで動作させる。²
• それを現新の両環境で差分がないか確認する

以上。

え、あの性能、負荷テストとかは？！

と聞く前にこう言われた。

他は特に決まっていないけれど、とりあえず先進めてね。ｺﾞﾒﾝﾈ。

何いうとるん？つまりどこかで決まり次第、再テスト確定やん。つら。

とか思いつつも、周囲の疲労しきった青ざめしった社員たちの様子を見て、とても言えない、仕方ないと二つ返事で作業に入った。

いざ新環境で動作させると、エラーになる。
もう慣れたわ。もはや予定通り。

いつも通り報告する。
いつも通り返答くる。
いつも通り…じゃない返答だった。
ﾔﾊﾞｲﾔﾊﾞｲﾔﾊﾞｲと上司はテンパっている。

どうした、落ち着け。

話を聞くと、今の環境でShellを動かすと、なぜかhttpsでなくhttpで動作するようになってるらしい。³ やばいやん、普通に。

どういうことかというと、

HTTP通信ということは動作するShellから指定の環境間での「通信の暗号化が解除され、情報漏洩や通信改ざんのセキュリティリスクが劇的に高くなるということ。情報生データがダダ漏れシステムと化しているのである。

オワタ。

いや、正確にはこの対象のShellではAPI⁴を叩いたりしないし、暗号化されてなくても問題ないやつからﾀﾞｲｼﾞｮｳﾌﾞﾃﾞｽﾖ

とか言うてる。
まぁ大丈夫ならいいけど、と思いながらもテストを進めることに。

とりあえず新環境はダメそうだし
現環境で同じデータを使ってみる。無事に通った。

と思ったが今度はログが出力されない。

え、正常終了しているのになぜ？

とりあえず上司に報告。
再びﾔﾊﾞｲﾔﾊﾞｲﾔﾊﾞｲと上司テンパる。

最初は、誰がこんな設計にしたよ！って思った。

どうしてそう思ったかというと、
今テストしたい環境を動作させると私の対象のシステムだけ、意図せず他の環境へ指示を飛ばして動作する仕様になっているのであった。

で、どこ向いているかって？
本番環境。オワタ。

いや、正確には本番環境と言っても、問題ない環境だからﾀﾞｲｼﾞｮｳﾌﾞﾃﾞｽﾖ

と言われたが、そもそも過去に結合テストも受け入れテストも完了して今問題なく本番環境が動いているやないんか…

と色々思った瞬間、ふと走馬灯のように思い出す。

…今までのずさんなテスト仕様書、特に意味もなさそうな確認報告…。そうだった…そもそも色々テキトーやったわ。

全て察した私は、無意識に祈っていた。
神様、どうか私に、平穏という名のブレがないテスト仕様書をください。と。

そこからは再び会議の連続。
単体テストでさえ、ボロボロだったんだ。結合テストなんてもっとヒドイに決まっていたわ。

私は心身、頭も空っぽにして、
再テストが確約された意味のない謎テストを回し、どうにでもなれとエビデンスを残す機械と化していた。

何処かが解決すれば溢れてくる不具合、
触らなければ一生そのままだったエラー、
探し始めると残っていないエビデンスの数々。

あとこれがいつまで続くのだろうか。
エラーと一緒にスケジュールの遅延だけが増えていく毎日に、私もいつか唱えるのだろうか。ｲｶﾞｲﾀｲ

これは普通じゃない（でも、起きる）

さて、ここまで色々とあったが当然これは普通の状態ではない。あるべき姿より他を優先したツケが回ってきただけである。

こうならないためのアドバイスも合わせて伝えたい。

エビデンスはバージョン管理で残す

どれが最新か分からないは許されない。
これだけでもやっておけば「いつから変わったか」が明確になる。

• 成果物（ログ・結果・設定・テストデータ）の置き場を決める
• 変更の理由をコミットメッセージに残す
• 「あとで誰かが見て復元できる」ことをゴールにする

仕様を常に最新にする

特に今後主流となるであろうAI駆動開発や仕様駆動開発においては、自然言語がプログラミング言語となる。
だから、仕様が古いというだけで、未来の自分とAIが同時に迷子になる。

• 仕様は“完成品”じゃなく“生き物”として扱う
• 変わったら更新する、更新できないなら「変わった事実」を残す

テストコードを書く

何が正しいか、正しくないか。どこまで影響するのかが明確になる。
いつかくるリファクタリング⁵をする日が来た時の目印となるように。

• 「期待する入出力」を機械に覚えさせる
• 人間の気合を減らし、再現性を増やす
• 仕様変更のとき、壊れた箇所を最短で特定できる

おわりに

さて、ここまでのお話はどうだっただろうか。
これは内容には多少フィクションを入れ、面白さとIT業界のリアルが伝わればと思い、今の現場のことを書き連ねてみたものである。

正直なところ3割は盛った。
でも7割は本当にあった怖い話である。

きっと別のIT業界の現場では
違う形でトラブルに遭ったり
想定外なことに巻き込まれたりと
大変なこともあるだろう。

だがそれ以上に
根本の原因を見つけ、解決に導き、
誰かにとっての助けになると思うと
巡り巡って達成感を感じられる業界だ。

変化も激しく、業界も歪だが
それ以上に得られるリターンも大きい。

少なくとも、どこの業界でもITスキルは重宝される。これを読んだ貴方がいつか、ITを活用してより素晴らしい未来に導いてくれることを、祈る。

脚注