フロイドの狂気日記

時は流れ、曲も終わった。もっと何か言えたのに。

PR

何故あなたのチームのwebプログラマは不具合を起こすのか

PR

なんでテストフェーズに入ると不具合を起こしまくるのか。ここでスムーズに行けば納期に間に合うのにどうして大量の修正に時間をとられるのか。そんな風に思うプロジェクトマネージャーは多いはずだ。僕はPMでないが今すごく思っている。なんせ自分の作った機能ではないところの不具合をまんべんなく割り振られているからだ。そのおかげで対応不具合数のカウントだけ積み上がり、僕がバグを出しまくっているみたいに見える。僕が出したバグに対応するのはいいが、他人の不具合まで回されたんじゃ困る。

 

思うにプログラマというのは川で言うところの最下流に位置するので、川上から工場排水やゴミが流れてくると、一番汚染されるのが下流域である。そのためプログラマが不具合を出しまくるのは、プロジェクトの失敗の全てがそこにつまっている証拠だ。10年もエンジニアをして、少なくとも日本のIT環境で決定的にできていないものが見えてきた。

 

おおむね3つ「最初期のデザイン設計の軽視」「仕様変更」「テスト"環境"の軽視」だ。

 

最初期のデザイン設計軽視

 

最初に致命傷を受けるのがここで、どんな社内向けアプリでもエンドユーザーは好みのデザインというものが存在する。ここをキチっと詰めておかないと後からひどい目になる。個人でCSSをゴリゴリいじって作ったのに「こんな感じじゃねえな」と言われるとデザイン変更は意外なほど時間を取る。システムを作った後でデザインを適用するね、などと言われることもあるが、簡潔に2倍の時間をかかると思った方がいい。デザイン変更にもよるが、ひどかったのは別ページを表示して入力させるものを、画面内のモーダル画面(小さい画面を重ねて表示させる)にしようと言い出したクソユーザーである。これはサーバーで動いている処理さえも割と改修が必要となる。ユーザーにしてみれば別ページのものを、手前の画面でシームレスに操作したいだけなんだというが、ふざけるなである。こういう変更を起きないように、最近ではCSSライブラリを予め選定して、ユーザーに見せておき、最悪の変更をしないで済むように設計段階で対応しないといけない。だがこれをできないSIerは多い。

 

逆に不特定多数の一般ユーザー向けwebサイトはデザインの確定から始まるので、この手のトラブルは起きづらい。一般市民向けだとそもそもデザイン重視になるからだ。社内向けインフラだとデザインなんてなんでもいい、という意識があり、そのくせある程度完成を見て上層部に見てもらうと、ダサいとか使いづらいなどとクレームが出てくるのだ。そのためデザイン設計は最初期にクレームのないレベルまで落とし込むべきだ。ここが失敗するとテストフェーズに入って、細かいViewやHTMLファイルの修正がはじまり、しょぼいミスが頻発する。バカにならない時間を取る羽目になるのだ。

 

仕様変更

これは言うまでもないが、仕様変更をするなら時間を取る、という原則が通用しない点で極悪だ。プロジェクトは顧客が何をやりたいかがフワっとした状態で始まるが、設計や要望でフワっとした状態を言語化して確認を取るところまで詰めないと失敗しやすい。だいたい3月リリースというようなエンドポイントを決めるくせに、設計段階でハードワークをしない会社が多いので、リリース直前に失敗するのだ。汗をかくのはスタート地点。これでもかというぐらい顧客が言語化できていないところを言語化する必要がある。顧客も始めは見えてないが、形が作られてくると、自らで言語化し始める。そしてそれが仕様変更という形で出てくるのだが、顧客が考える前にこちらが言語化して仕様として最初に組み込めば、変更は最小限で済む。

 

テスト"環境"の軽視

これがあんまり指摘されないし、あまり重視されていないので僕はいつだって腹が立っている。要するに快適なテスト環境を整える「専門家」が必要だと思っている。たいていのBtoB案件なんて大した能力者がいないので(営業が使う社内ツール作成にイケてるエンジニアが応募するとでも思うかね)テスト環境はだいたいひどいものだ。

 

まず自分のPCでのテスト環境はXAMPP環境が結構多い(これは偽装Linuxとでも言うべきものだ。個人開発ならいいが、プロ仕様とはいえない)。本番環境に模したサーバーを一つ用意すれば関の山である。問題なのはサーバー一つであればみんながそこにアクセスするので誰かが起こした不具合が影響して、自分の担当機能が動かないなんてこともある。そうじゃなくてもテストフェーズになるとデータの登録、削除をバンバンやるので作っていたデータが勝手に編集されるなんてこともある。

 

ようするにこのように乱戦状態になったらアウトなのだ。そうなる前にテストフェーズをスムーズにやる設計と準備が必要だ。この場合、全員が限りなく本番環境に近いスペースを保有しながら自分だけが編集できる場所というのが必要になる。

 

Dockerや仮想環境はそれを実現可能であるが、その能力をキチっと持っている人じゃないと、更なる混乱を呼ぶ。仮想環境をそれぞれが一から設定するなんてのはもってのほかだ。コマンド一発で自分のPC内に組み立てられる仕組みが望ましい。面倒だが組み立てるまではフォローできる専用人材がいる方がいい。一度組み立ててしまえば、遺憾なくテストできる、余計な心配をせんでも良いという平穏が生まれる。

 

windowsに置いておくソースの場所だって、Documentフォルダの直下なのかCドライブ直下なのかだとかで迷うぐらいなら、windowsの保存フォルダ場所から名前まで最初から指定すべき。テスト環境をキチっと合わせるには、git ignoreに書く内容も、.envに設定する内容も把握して開発者同士勝手にしない様に見張る人物がいればなおよい。テスト環境と本番環境を限りなく掌握すれば、「よくわからないけど、ソースが戻っているんです」とか言う人もいなくなる(マジで言いやがったからな。そしてPM側たちはgitの知識がなさすぎて、よく確認してソースを上げましょうとプログラマひとりひとりに告げて回った。)

 

こういう一見ささいなトラブルがプログラマを苛立たせ、作業効率を落とすことになる。現場目線で言えば、この点を最初から解決していればなあ、と思うことは多々ある。できる人は個人開発環境をゴリゴリ作って、PMたちが気づかない内に作業を進めたりするし、そういう人はトラブルがあっても個人プレーで何とか解決して進捗も速いが下々のクソグラマは非効率バグを出しまくり、他人にそれを押し付ける羽目になるのだから、やはりトラブりやすいポイントはシステム運用で解決すべきだと思った。

 

テストを効率よくするために、本システムでは絶対に必要なデータをいつでもロールバックできる状態にすることも肝心だ。なんか失敗すればとりあえず正しいデータにロールバックすればいい。皆が同じデータベースで作業しているから、簡単には登録も削除処理もできねえ、とかになるぐらいなら、それぞれのPCで完璧に本番を模した環境と壊れてもいいDBで作業続行できる方が万倍いい。

 

 -----------------------

 

お分かりのように後半は僕のテストフェーズの愚痴だ。見ているかPMども。

 

てめえらがクソみたいなテスト環境しか用意できねえ交渉力、技術力のせいでみんな足踏みしながらテストしているんだ。そしてテスト不足から不具合がでている。

 

それと結合テストの不具合の全体の半分を僕に割り振っているのを今すぐやめろ。100件中10件以外は僕以外の製造担当だろうが、クソが。50件割り振るバランスどうなってるんだ。9人の開発者がいるんだぞ?この人でなしのボンクラどもが。

 

 

次週

何故あなたのチームのwebプログラマは使えないのか - フロイドの狂気日記