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

■この仕事のグチを私が酒飲みながらしゃべるんで、酒飲みながら聞きたい奇特な人を募集しています

超大企業が抱えるクソ

えー、私の勤めている会社はSEの人材派遣業みたいなのを生業にしてます。カッコつけて言うとSESってヤツですわ。

今の現場に着任して、いま5ヶ月ぐらいですかね？
誰もが名前を知っているレベルの大企業に常駐で仕事してるんだけども、もうここの開発者のレベルが考えられない低さでブッたまげた。
もうね、「コーディングが悪い」とか「設計が悪い」とか、そういう技術者的な観点で文句を言う所までたどり着かない。仕事としての体をなしてない。
大学のサークル活動の方がまだマシなんじゃないかってレベル。マジだよ。

繰り返し言うけど、東証一部上場で株価総額1兆円の世界的大企業の話だよ。
それが、そんなレベル。問題点に気づかないか、気づいても何もしないか、そのどちらかしかいないクソ。

というわけで、どんなアホが開発名乗ってるかという話で愚痴らせてもらいます。

↓このエントリの続き

私の立場の説明

私がどういう立場なのか説明しないと、なんで怒ってるか良く分からないと思うんで先に。

ビジネスモデル

あるwebサービスの開発と販売をしているんですけども、まぁザックリと以下の図のような担当になってるわけです。

こんなカンジのビジネスモデル

開発部が作ったソフトウェアを、営業＆運用担当の子会社が売り、運用する形。
まぁこれは大きな会社なら良くある構図かなと思うんだけども。

開発、営業、運用と大きく分けて3つの業務があるんだよと言うことが伝わればOK。

担当業務

俺は営業＆運用の子会社所属。
「え、なんでそっちの会社に開発者が必要なの？」
って思うだろうけど、これには深い深い、卵焼き用のフライパンよりも深い理由がある。

運用業務の説明で「顧客データの登録」があると書いたんだけども、まぁ簡単に言えば
「システムだけでは顧客データの登録ができない」
状態なんですわ。
何言ってんのか意味分かんないでしょ？ 俺もなんでこうなってるのか分かんねぇもん。分かるのは開発者がアホってことだけ。

このサービスは客の登録の時に、その客が使うデータも合わせて登録しないといけないんだよね。
で、そのデータ登録の時に色々問題があって、技術者じゃないと最後までデータ登録できないんだよね。
具体的にはSQL使って直接データベース更新できないとデータ登録できないの。
だから、営業＆運用の会社がSE雇ってるんだよ。それも複数人。

なーんじゃそら！

って話でしょ。だってシステム直せば毎月200万とか300万とかってレベルでコストカットできるのにさ、しないんだぜ？
Why Japanese people!? だよね。
まぁコストカットされると私は追い出されるワケだけども。

ま、とにかくだよ。
私は顧客データの登録をするためにいるわけ。

襲いくるバグ津波

ソフトウェアのバージョンアップ

この現場の仕事は至極楽だった。データ登録の依頼がきて、定常的な操作しておしまい。だから毎日定時帰り。
ただイレギュラーなdb操作を度々求められたりはしたけどね。客の要望に応えるため、dbちょこちょこ弄ってデータ加工したりは結構してた。

そんな中、開発から
「ソフトウェアのバージョンアップしまーす」
との案内が。今から2ヶ月前。

「受入試験」というものをする

こういう時に営業＆運用会社の立場としては、開発が納入してきたソフトウェアの妥当性を確認するために「受入試験」ってやつをやるんですわ。
このプロセスはとても一般的で、どこの開発会社でも「納入完了」イコール「依頼主の受入試験完了」を意味しているハズ。

ただ営業＆運用会社の立場でできる試験って何？っていうと、大したことはできなくて。
一応開発の出してきた修正差分の仕様書を基に試験項目作って実施したんだけども、結局は「その機能が動くこと」を確認する程度しかできない。派手な条件組み合わせとか、そもそもやれない。
開発機材無いしね。試験用のデータがっつり作るような時間もないし。
ま、ま、受入試験が正常系をひと撫でして終わりってのも世の中ではありがちな話で。

サラッと正常系だけの受入試験実施。
ボロボロっとバグを3つほど検出。
……え？ただの正常系をやっただけですよ？試験してんの……？
大丈夫なんかいな、この開発……。

そう思いつつ、修正されたソフトウェアで再試験して無事合格。

そして爆弾は破裂する

リリースから2日。
客から1本のクレーム電話が入る。
「今まで使ってたデータが無くなったんだけど」
凍りつく営業と我々SE。

一応ピンと来ない人向けに説明すると、webサービスにおいて（いや、どんなシステムでもそうだけど）、データを消失する障害はあってはならない。
Excelならファイルをこまめにバックアップしておけば避けられるが、webサービスはそうはいかない。壊れちゃったからデータベースを少しロールバックしましょう、なんてやったら全顧客のデータがロールバックしてしまう。そんなことしたら客から鼻フックされたまま強烈なビンタを食らうので、できない。

だから、どんなタイミングでブラウザが閉じられようが、ネットが突然切断されようが、更新ボタンを連打されようが、アプリケーションがクラッシュしようが、データが消えてはならないんですねぇ～。大変ですねぇ～。

それぐらいに「データが消えてしまう」は避けなければならない事態。それが、なんだか知らんけどあっさり発生したと。
そういう理由で我々一同は凍りついたワケ。

深夜まで続く「現状把握」

このシステムはサーバーとモバイルアプリを連動させて顧客の情報を管理しているんで、一報を受けてすぐさまサーバーの情報を確認する。

データは合った。無くなってはいなかった。

まずは胸を撫でおろす我々。
ただのモバイルアプリ側の問題のようだ。では、なぜ表示されないのか解析すればすぐ分かるだろう。少なくとも俺はそう思ったよ。

しかし、そこに開発側からのコメントが突き刺さる。
「リリース版のアプリからは解析できない。これは OS の仕様だ」

は？？
いやいや……んじゃ世の中のモバイルアプリはリリース版で発生した不具合どうやって直してるの？

「アプリの利用するエリアは外部からアクセスできないので……」

いやいや……今できないとしてもリリース時の署名手元にあるんだからデバッグ用のアプリをビルドしてインストールすればデータひっこぬけるでしょ？

「それはできません」

えぇ、できないの……。
うーん……まぁそのモバイルOS俺は詳しくないから、そこまで自信持って言うならそうなんだな……。そりゃアホみたいな OS だなぁ。俺の知ってるモバイル OS ならできるけどなぁ。そっちの開発者は大変だねぇ。

なんて思って納得して。

しかし、それじゃ周辺の情報集めていって原因の場所を狭めて行くしかない。
問題発生したデータやモバイル端末を、発生していないものと比較して差分を出す作業。それもただ推論のための。
不毛だが、他にやれることもない。
深夜まで「これじゃね？」なんて言って、テストデータ作って試して、やっぱ違うか……なんて事を繰り返して。結局私は終電逃して会社にタクシー代出して貰ったりして。

そんな大騒ぎは、 2 日後に解決する。
ソースの差分を 1 つずつ確認していた開発がバグ箇所を特定した。
とりあえずデータをいじって、バグをかいくぐって表示されるように暫定対処。

結局深夜まで残った意味はあまり無かった。

バグの原因

原因が分かったと言われて、当然みんな気になるよね。
聞いてみると
「ユーザーの管理テーブルの扱いに誤りがあって……」
とか要領を得ないふわっとした話。

僕は個人的には「は？」って感じだったけど、聞いてる側には技術者いないので細かいロジックを言っても伝わらない。だから打ち合わせの場で言わないのは正しいよ。

周りの営業の人は結局原因はどうでもよくて
「どういうお客さんに被害が及ぶのか？」
って所を早く聞きたがっていたしね。ま、そりゃ当たり前。だってどう間違えたか気になるのは、ソフトウェア開発の品質気にする技術者だけだし。

でもねー、なんか「どういうケースで不具合が出るのか」の説明も、なんかいまいちスッキリしないんだ。
なんというか「え、結局なに？」みたいな。
こういう時って技術者なら分かると思うんだけど
「ははぁーん、さてはコイツら根本原因の把握が曖昧だな？」
って感じ取れるんだよね。不思議なもんだ。

しかしながら、僕はしがないただの外注ですからして、なかなかそこで声をあげるのははばかられるわけですよ。
というわけで、その場では「コイツらナメてんな」という怒りだけを胸に抱えて黙ってたワケです。

次々とやってくるバグ

さて、数日経って。
ある日、お客のデータをたまたま閲覧してて気付く。
「ん？なんか日付のフォーマットがおかしくなってね？」
なんか客指定の日付フォーマットとモバイルアプリで表示される日付フォーマットが異なるのだ。

登録しているデータを確認して、正しいデータが入っていることを目視してから開発に問題としてあげた。

信じられない低レベルなバグ

もちろんこれもバグだった。
しかもこれはおっそろしく低レベルなバグ。

簡単に言うと……

今まで設定ファイルはcsvでした。
その設定ファイルの途中に新しい設定を追加しました。
しかし、すでにデータ登録済みの既存顧客のデータには、当然古いフォーマットのcsvが保存されています。
ですが、既存のデータのことを何も考えていなかったので、csvの読み込む列がズレてしまって結果的に日付フォーマットが狂っていました。

みたいなバグ。

たとえば 3 行目の意味を「球場キャパ」から「球場名」に変えちゃったカンジ。 昔からのデータに手を入れなかったせいで「球場名 30000」になっちゃう。

はぁー？？
いや、バカじゃん、ただの。
設定ファイルがその仕組みだったら、途中にいれたらそうなるの分かるよね？ 何にも考えてないのかよ。ていうか誰も設計レビューしてないのかよ。コードレビューもしてないだろ。
してたとしたら、その開発にはバカしかいないってことになるから余計やべーんだけど！

もうね、ガックリよ。
しかもこんな低レベルなバグ出しといて開発側の誰一人として「申し訳ない」的な態度を示さない。
いや、あのね、体育会系なヤクザ的な「誠意みせんかい！」って話じゃなくてさ。
「これが極めて低レベルなんだ」
っていう意識は共有したいわけよ。
なのに「こんな不具合です」みたいなカンジで説明して、しれっとしてんの。

「あー完全にナメてるわ」
って内心キレてた。

キレてたから「これ、混入原因はなんですか？再発防止策は？」って打ち合わせで聞いてしまったの。つい。

そしたら、なんか開発がキョトンとしてんだよ。
「？？？？」
って俺を見るの。
俺も
「？？？？」
って見つめ返したんだけど。

そしたら、周りの偉い人が「まぁ今そういう話は置いとくとして、回避策の話しましょう」なんて話題ずらして。
内心「 1 番大事なのは再発防止策だけどなぁ」なんて思いながらも、偉い人が話題そらした以上ツッコミできずに黙ってた。
イライライライラしながら。

さらに飛び出る考えられないバグ

その翌日。
また日付フォーマットが設定と違う。
しかも前回のバグとは異なり、たった今登録したデータで表示がおかしい。つまり設定ファイルのズレではない。今の新しいフォーマットの設定ファイルで発生している。

日付フォーマットのズレ方も違う。
簡単に言えば「西暦表示の設定なのに、和暦で表示される」という問題だった。

とんでもない理由を堂々と書いてくる

これも当然バグだった。
また打ち合わせが開かれる。

……うーん、そもそもバグが出たらとりあえず関係者みんなで集まって打ち合わせするっていう文化はなんなんだ？ てんとう虫の冬ごもりか何か？ みんなで慰め合う会なのかしら。

まぁそれはさておき、打ち合わせでバグについての資料が提示された。
ちなみに、この資料は事前に配られないし、後からどこか共有されることもない。ただ開発が打ち合わせ用に作って、ただそのまま放置される謎の資料。

で、その資料にとんでもない事が平然と書いてある。
「実装当初の要件定義書にはモバイルアプリの設定で変えられると書いてあったので、顧客データは無視して、そちらに合わせました」

は？？？
すでに実サービスしてて客が使ってるんだぞ？？
なのに実動作を確認もせず、その実装になった経緯も確認せず、誰にも相談せず動作仕様を変更して、しかもそれを「変更点一覧」に載せず、さらにその仕様変更をコードレビューでも設計レビューでも見落としたって言うんだな？

そうね、君らが絶望的に仕事できないってことが良く分かったよ。

要件定義書には、こう書かれていたそうですよ。
「モバイルアプリの設定『和暦表示』がオンだと和暦表示、オフだと西暦表示とする」
だからすでに運用されている仕様をガン無視して勝手に変えちゃったんですって。アホだよ。

しかも原因が間違ってるし、逆ギレする

しかも。
バグには2種類あって。
1つは「設定は西暦なのに、モバイルアプリの設定が『和暦表示』をオンにしていたら顧客データを無視して和暦表示になる」というバグね。
モバイルアプリの『和暦表示』ってのは、本来は全く別の用途の設定なんだけどさ。勝手に混同して勝手に仕様変えちゃったのね。
だから、これは資料にあった原因の通り。

でも、その逆があってさ。
「モバイルアプリの『和暦表示』がオフになっていたら、顧客データの通りに表示される」
っていう動作なのね。

いや、待てよと。
おめー「要件定義書に沿って変更しました」って言ってんのに、オフの時の動作は要件定義書とちげぇじゃねぇか！！
おめー自分でこの資料作ってて矛盾に気付かねぇのかよバカなのかよ？？？

まぁバカなんだけど。間違いなく。

設定オフのときも、顧客データを無視して西暦表示になるんならね、原因は言ってる通りだよ。
でも、なんで片方だけなのよ。
これ要件定義書に従ったんじゃなくて、担当者が勘違いして実装して、それがそのままなんにもチェックされずにコミットされたんだろ？？　もっともらしい言い訳すんじゃねぇよ、素直に原因書かなきゃ改善できねぇだろがアホだな、と怒りの感情止まらずですよ。

さすがに黙っていられないのでその場で指摘を。
「原因にこう書いてありますけど、これ片方はそうですけど、もう片方は違いますよね？」

至極まともな指摘よ。誰がどう見ても正論。
それに対して、開発の課長がなんて言い返したと思う？

「私はここに言い訳をしにきているんではなくて、現状どうなってるかを伝えに来ているだけなんで！」
と半ギレ。

は？？？？
おめーにキレる権利微塵もねぇだろが、バカかよ。まぁバカなんだけど。

しかし打ち合わせで「は？」とか「バカかよ」とか言えるわけもなくて、言葉を選んで伝えなきゃいけないワケ。
「いや、そりゃそうなんですけど……」
なんて伝えればいいんだ……。ここで原因間違って書いてしまうことで、その後の解析や影響範囲、再発防止策すべてに関わるので、ここは正確に書く必要があるんですよ、とか新人くんに教えるような事を噛んで含めて言わなきゃ伝わらないんだろうか……。

なんて悩んでたら、なんか課長が半ギレなのを見て、別の部の部長クラスがなだめにかかった。
「原因はさておき、今どんな事がおきるのかの整理をまずやろっか」
うーん、また棚上げするっていう選択か。
でもさすがに部長クラスにまで逆らうと、俺の存在そのものが消いし飛ぶかもしれないので自重。

ここの開発は、こんな初歩的な間違い（担当者の勘違い）すら気づけない、ピックアップすることすらできない能無し集団なんだということを心に深く刻み付ける出来事になったんだよね。

あまりに長いので次回に続く

もうね、コンパクトに書ききれない。長くなるので次回に続く。
さーて来週のクソ開発は？

• さらに襲い来るバグの波
• 結局リリース版でもデバッグできるんじゃねぇか
• バグチケットの書き方も知らない人たち
• 開発の中に自社の社員がいる
• バグを出しまくってるくせに、人からのアドバイスをガン無視するクソマインド
• 開発以外はみんな分かってる
• 外注なのに関連部署それぞれに掛け合って外堀を埋める活動をする俺

の 7 本だてです！
いや、全部次回で書けるかもわからんし、もっとテーマ増えるかもしれないんだけど。
なにより現在進行形の話だからね。日々テーマは増えていくんだ。それが恐ろしいんだけども……。

だって、もう 21 世紀だよ！？ それがこんなバカ開発がまだ生存していて、しかもバグを山ほどだしているくせに品質向上策を「うぜぇ」っていうだけでシカトするんだぜ！？ もう信じられないよね……。

というわけで、このグチはしばらく続いていきます。次回乞うご期待。

↓このエントリの続き

↓私の一番好きな「ソフトウェア設計とは何か？」を考えるための入門書。
実に分かりやすくタメになる。今でもうちの本棚に置いてある。