大企業の開発者がこんな酷いレベルだという恐怖 #2

さてさて、長々と続く私のグチですけれども。


今回は以下についてグチっていきますよ。

• なんとなく人のせいにしてバグ票をクローズ
• コミットされた経緯が不明なソース

以下のエントリの続きとなっています。
よろしければ #1 から読んで頂くとより楽しめるかと思います。

この話の続きは以下となっています。

なんとなく人のせいにしてバグ票をクローズ

さて、前回バグがたくさん押し寄せてきた事は書いたんですけど、そこからさらに数日経ったある日の話。
また客からのクレーム電話が鳴る。
「登録して貰ったデータが、一部見えないんだけど。これじゃ業務できないからすぐ直して」
また見えなくなる系か……。どうせモバイルアプリのバグだろと思いながら調査。データベースは正しいね。うん、開発で確認してね。

発生ロジックが確証とれないケース

その顧客データは、実は顧客の要望でちょこちょことカスタマイズを入れたんだよね。
「カスタマイズ」とか言うと規模が大きな話に聞こえるだろうけど、画像ファイルを差し替えたり、ちょっと業務データの名前や位置を変えただけね。システムで出来ないから、俺が db ちまちまいじってデータ差し替えたってだけ。

手動で更新するから、気をつけるのは db の各レコードにある「更新日時」というカラムも更新しなきゃいけない点。
手動でやってるから、作業ミスで更新忘れてるかもしれないからドキドキしたんだけども。実際データは特に問題なし。

まぁ後は「デバッグできない」とか言ってた開発がデバッグするしかない。何らかの方法を使ってデバッグしてくださいなと他人事な顔していた。

そうしたら開発の人が俺のデスクまできてこう言うわけ。
開発「テーブルAとテーブルBのデータ、更新日時に2時間半のズレがありますね」
俺「そうですね。その間はバグ対応の打ち合わせ出てたから」
開発「その2時間半の間にお客さんがモバイルアプリからデータの更新してると、データが不整合になるかもしれない」
俺「へぇ、そうなんだ」
開発「ただバージョンアップに伴いサーバーログ消されてしまったので確証は取れないんですよねぇ……」
俺「ふーん。まぁその可能性あるなら一旦それで収めて、同じ事が起きたときに追跡できるようにしておけばいいんじゃないですか？ できますよね」
開発「はいはい、たしかに。できますよ」

原因調査しなくていいのかって思われるかもしれないけど、実はこういう対応は良くある話。確証取れない事ってのは世の中の結構転がってて、でも現状のデータだけでは調査が難しかったりするんだよね。
そんな時はソースコードの中で疑わしい所を絞って、次に発生した時に原因キャッチできるように準備しておくんですわ。
なので、この会話でまぁまぁ安心して「とりあえず客のデータを直してその場しのげば今はいいや」ってカンジだったの。

ナチュラルに人のせい

やがて恒例の「てんとう虫の冬ごもり」こと、バグ発生の打ち合わせが実施される。

そこで開発側から資料が出てくる。

「原因：設定データに 2 時間半のズレが合ったため」
……ん？ なんか俺のテンションとは違うんだけどな。
原因って
「 2 時間半のズレがあると、○○という処理になってしまって、結果登録データの一部が見えなくなる」
でしょ？ 発生ロジックって、そういうもんでしょ？
2 時間半のズレって、ただ単に発生のトリガとなっただけで、要はモバイルアプリのバグだろ！？ なんでその点に一言も触れないんだ……？

え、もしかして自分の責任になるのが嫌で婉曲表現してんのか？
まさかね……新人じゃあるまいしね……。

しかし、聞けば聞くほど「設定データが悪い」と思わせるような誘導をしている。
ただ、明確に「データが悪い」というわけじゃなくて、詳しくない人が聞いたらデータが悪いと誤認してしまうような表現をする。
たとえば「データを修正した影響で」とか。「同一日付で揃っている前提でソフトウェアは動いているのですが」とか。「このデータの組み合わせは想定しておらず」とか。

あのさ、キミらさ、その場がしのげればいいのか！？ 不具合をちゃんと報告して、早いうちに潰しておこうとか、そういう当たり前の発想にならんのか！？
まったくもって、呆れた。あきれたとしか表現できない。

聞いてる側に技術者がいないから適当ぬかす

いやいや待てよと。
ギリうそじゃないからセーフみたいな子供の言い訳すんじゃねぇよ。
データを修正した影響じゃねぇだろ。データ修正したからバグが顕在化したんだろが！
同一日付で揃っている前提って、それは「そういうコードになっちゃってました」ってことであって、そういう仕様で最初から作ってたワケじゃねぇだろ！
想定していないかどうかなんて、そんなんどうでもいい。ソースコード調べたら、今の実装がしょぼくて処理できないパターンを見つけたんだろ？ それをさも最初からそういう仕様ですみたいな顔してさ。

それを聞いてる側に技術者がいないから分からないだろうと思って、全部データ設定のせいにしやがって。
データが悪いという事にしておけばバグの調査しなくていいからか？ だとしたら頭が悪すぎる。
こんなクリティカルなバグ、次にいつ発生するか分からない状態で置いとくのかよ。客にも迷惑だし、自分たちの首締めてるだけだぞ。もう一度発生したら、すべての作業中断して調査だぞ？ わかってんのかこのボケナスどもは。

まぁ分かってないんだろうけどさ。

人のせいにして調査もしないから、当然次に同じ事が起きた時にキャッチできるような何かを考えることもない。永遠に「原因は分かりません」と言い続けて逃れる腹積もりなんだろう。
心のどこかで「別にこのシステムがどうなろうがどーでもいい」って思ってるんだろう。プロ意識の低さが如実に表に出てしまっていて、もう同じ技術者としてひとくくりにされたくない気分だよ。

コミットされた経緯が不明なソース

あんなバグ、こんなバグ、みたいな話はとりあえず次でおしまい。
どんな低レベルなバグが出て私が頭を抱えたのかを共有したいので、例示が長くなってしまうけども。
本当はもっとグチっていたい所だけども、「こんなバグが出ました」というのを書き続けていたら次の話題に行けないかもしれないので。

もう1つ致命的なバグが出た

数日後にまたクレーム電話。
「こっちで作ったデータがアップロードできないんだけど」
この web サービスは、こっちが登録した顧客データとは別にお客さんが作った領収証データもアップロードして使うことができるんだよ。
それらを組み合わせて月次の書類処理ができる、みたいなね。

だけど、領収証がアップロードできなくなってしまったとの事。アップロードできないと、お客さん的には月末に大変困るはず。なのでさっさと直さないといけない。

アップロードできない原因ってのは開発が調べなきゃ分からない。データベースがどうなってたらエラーになるのかが分からないのだから。
発生直接原因がそもそも予想つかないので、我々にやれる事はない。
開発が 1 日調査して、原因が分かったらしい。

パラレルに作業されたらダメ

領収証ってのは、たとえば 1 回の出張だったり、 1 回の会食だったり、まぁとにかく 1 回のイベントに 1 枚必要って作りになってるのね。逆に 1 回のイベントに 2 枚以上の領収証は付けられないようになってるの。
それが便利かどうかはさておき。ここまでは仕様の問題だから。

問題はここから先の話。

たとえば出張イベント作ってホテルの宿泊費の領収証を貼っつけたとしましょう。
出張にいった A さんと B さんが同じイベントに別々の領収証を貼りました。そしてそれぞれがアップロードしました。
先にアップロードした A さんは無事にアップロードできて、後からやろうとした B さんはアップロードに失敗します。
B さんのアップロードが失敗した情報はモバイルアプリに残され続けて、このエラーを解消するまでは他のアップロードはもとより、最新データのダウンロードすらできなくなります。
でも、すでに A さんの領収証が上がっている以上、 B さんのアップロードは一生失敗し続けます。
結果として B さんのモバイルアプリは、何もできないゴミになります。

そう、このシステム、マルチアカウントなのに、パラレルに操作されるとボロボロなのだ！

うーん、何を考えて作っていたのだろうか……。
でも、今まで書いたバグよりはまだ理解できるよ。いかにもバグ、ってカンジではある。

問題は、そのバグが入ってしまった経緯

パラレルにデータをアップロードされると、片方が失敗する。
基本的な機能ができてないんだけど、まぁ今までの酷さに比べればまだマシだと思ってた。
複合条件で、すっぽり対応が抜けてしまって、しかも試験もすっぽり抜けたんだろうなぁ、って考えたらヒドイんだけども。
でも、他に比べりゃマシ。
マシな理由としては……

1. 既存の不具合の顕在化だった
2. 複数の条件が重なって初めて発生する問題だった

まぁ、だからいいよ、別に。そんな普通レベルの事ができるなんて思ってないよ、ね。

取り立てて詳細書いたのは、その混入原因。

「実はアップロードのバッティングは元々対策コードが入ってた。けど、途中のバージョンで理由よく分からないんたけどコメントアウトされてた。経緯は不明」

「なぜこうなっているか経緯不明」だとさ

はぁぁぁぁあああ？？？

ちょっと待ってくれよ。
お前ら、どんなソース管理してんだ？？
redmine とか mantis とか使ってるって言ってたよね？？ じゃ、なんでコミットとチケットが紐付いてないんだ？ っていうか、んじゃ redmine とか mantis って何に使ってるんだ？？？
ていうかソースコードレビューとかないんか？
誰も気付かずにソースがコミットされるんか？

恐ろしすぎるだろ……。

「なんか経緯わかんないんすけどコミットしちゃってましてぇ」
じゃねぇわ。
誰がコミットしたのかヒアリングしろ。そして改めさせろ。あと誰でも勝手に submit できる怖い状態をなんとかしろ。
大体なんで経緯がどこにも書いてないんだ。何のために redmine や mantis 使ってるんだ？ ていうか経緯が書いてないとしたら、何が書いてあるの？？

もう、不思議。どうしてそうなっちゃうのかが。何にも知識がない奴らしかいないのかっていう話よ。
ド素人かよ！
そんな知識のない奴らがリリースしてくるソフトウェアを、どうして信用できるというのか？

襲いくるバグ津波の話をしていたらこんな長文に

私を怒り心頭にさせるに十分なバグの数々の話をしているだけで、もうこんな長文に。
これ以外にもまだまだグチはあるんだよなぁ……。
書き残している事の中で、「バグチケットの書き方を知らない」が、本当に心底いっとうイラついたんで次回はその話がしないなぁと思う次第。

というわけで、まだ私のグチはグチグチ続きますよ。

↓このエントリの続き