フロイドの狂気日記

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

PR

仕事は全員が醜悪な上に無能という前提でするべき

PR

何故あなたのチームのwebプログラマは不具合を起こすのか - フロイドの狂気日記

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

 

読者というものはとてもよく見ている。冷静に書いた上記事はバズりスターをもらえた。怒りに任せて支離滅裂に書いた下記事はスターさえ普段よりもらえなかった。僕は怒りを誰かにぶつけるというのはあまりしない。モノに当たることもしない。だがブログに怒りをこめることはある。それで自分の思いをぶちまけたら頭の整理になる。

 

1か月前に今の仕事の契約は打ち切っているから、残り時間を過ごすのみだった。だが週末からの未設計部分を不具合として指摘してくる仕打ちを腹に据えかねた僕は、PMと戦ってやるぞ、面と向かって仕事ぶりを指摘してやるぞ、という気になっていて、朝の通勤ラッシュの中でシャドー議論を繰り返していた。言うことの要点の順番をまとめて、反論に対しての反論も考える。

 

体温が上がったまま会社につき、朝会で「ちょっと相談したいことがあるので後ほどよろしくお願いいたします」と宣戦しておいて、その後すぐにPM二人の席の間に入る。

 

要点は3つ

入力チェックの仕様は書いていないのはPMのミスだ(それを意識しろ)

だから「障害票」の中で仕様未確定分は別のエクセルなりにわけてくれ。

デザイン修正に伴う指摘も管理を分けて、全体を一度に対応する時間を設けろ。

テストサーバーを一本だけではなく、少なくとも外部API連携用に一つ作ってくれ。

 

明らかにキレた態度で臨む僕の要望でPMの一人が開口一番

「いやです」

このPMは今まで接点を持たなかったが、いろいろ把握している人物だった。

 

「これ以上管理を分けるなんて、めんどうだから嫌です。」

10人が開発をしている全ての機能の不具合を一つのエクセルでSVN管理することの労力は彼らも理解した上で、その言葉が出たのだ。

 

面食らった。多少の配慮があるかと思ったがゼロだ。場所を変えて(エンドユーザーの前で不手際を指摘したかった僕の戦略も消えた)彼らの方からも僕に言いたいことがあったんだ、と。

 

「その都度、言えばいいじゃないですか」

 

という一言に集約された。

「validationの設計がないと気づいた時点で言えばいいじゃん」

意表を突かれて、僕はなんで言わなかったんだ?と大急ぎで論点整理を行う。

 

そもそも設計の一部が抜けているのではなく丸ごと抜けている点、全体の共通仕様に含まれる取り決めが必要な点、未だにvalidation共通関数の差し替えをプログラマのサブリーダーがコード全体に適応している最中という点。

 

「決まっていないのだからやらなくていい。そもそも単体テストに入る前に決めること決めていないということは、後から実装時間を与えられるように段取りしているのだろう」と僕は結論付けていた。

 

「勝手に考えないで言えばいいじゃん」

ギャルかよ。

「○○さんはすごいよ、コード書きながら疑問点指摘しまくって、設計書の半分以上書き換えさせてさ、設計書がほとんど真っ赤なのよ。そういう動きを期待していますよ」

 

なるほど○○さんは優秀な女性というのは知っていたが、確かにそれは便利だろうね。だが設計書が半分書き直すレベルだとすれば、設計担当者は何をして、PMは何を管理するというのだ。これ前にもあったな、ということをふと思い出した。切羽詰まって設計とテストの「順序が入れ替わる」というプロジェクトでありがちなPMの認識。

 

「テストフェーズに無理やり繋げたらアガリ

そこからの不具合は半ば下流に押し付ける。もちろんプロジェクトの始末は上が引き受けるが、会議中にXXさんとこの不具合が多くて、という話はできる。そういう時、デバッグ時の不具合と、設計ミスの不具合をごちゃ混ぜにすることで自分の責務でないという空気を作れる。そしてその切り分けしない非対称性が僕をひたすら苛立たせる。

 

最も肝心な、全員が同じサーバーとURLでテストをすることを避ける、という要望も無意味だった。

「僕らもテストがやりにくいことは認識しているけど、お客さんがどうにもなりません、と白旗上げたからどうにもならないじゃん」

 

クソが。要するに、仕様未確定もテスト不具合も、すべてを一枚のエクセル管理をして、一本のテストサーバーとURLで確認するという現実は変わらないけれど、不具合はキチっと直して、設計の不備、不足は随時指摘しろというのだ。肝心なことは何一つ変わらないのに、彼らにコミュニケーションを取りに行かなければならない。

 

google docならブラウザでの同時アクセスが可能だが、彼らは使いたがるまい。サーバーは一つでもパスは分割できるが、グダグダ設定する方がいやだ、と却下された。技術と権限さえあれば解決できる問題も、彼らは技術がなく速やかにできないから古典的な状態でプログラマに負担を押し付けるのだ。

 

彼らの中では設計段階は過ぎ、指摘がなければ自ら見直すこともない、待ちである。もうこうなったらひたすら頑張るしかない、という状態になったのだ。だってお客には単体テストも終わり、完成間近ですって報告しているんだから。例えプログラミングをしながら設計の半分を書き換えても、なんの報酬もない。お褒めの言葉の一つはあるだろうが、それ以外は僕のように塩対応をされないというだけだ。

 

契約を切って正解だった。そしてまたもや僕は、苦い記憶でプロジェクトを去る。自分のコミュ障具合を理解したのみだ。周りができていないから、向こうが準備するだろう。準備していないのだから、まだ決められないのだろう。そういう風に自分基準でやることをつぶすのではなく、相手基準でまだ待つべきと勝手に判断するのはよくなかったのだ。そして上流がキチっと準備していれば下流も楽ができるという当然のセオリーを信じて、実行できるというのは望むべきもない。

 

上はたいていダメだから下から毎日突き上げるという覚悟をもって仕事に取り掛かるべきだった。それは相手が準備できているかどうかは問題ではない、こちらが要望したいことを探す戦いだ。自分基準がないといのはコミュ障の一形態。結局彼らは無能を棚に上げて、こちらを叩きはじめるのだから。最初から殺す覚悟が必要だった。そこに基準を持つべきだった。

 

クソみたいな残業をする前の休憩でエレベーターに乗るとき、開発のサブリーダーのフリーランスの男と一緒になった。

 

「もう帰られるってことは、順調なんですね」

「忙しいけれど、帰ります」

その男は少し笑った。

「そうですか。僕は今月で終わりなんで、がんばってください」

僕がそういうと

「僕もですよ。契約した時から今月までと決めていましたから。残る理由もないですしね」

僕はほくそ笑んだ。使える人材が少なくとも一人は抜けるんだから。苦しめばいいんだこの無能ものどもが、と思いつつもすぐにむなしくなった。

 

何故なら目の前の彼は遅刻もせず、不平も言わず言われず、予定通りに仕事を終えて次に行くのだ。コミュ強とはこういうバランスを持っている。僕にはないが。

 

彼も僕も戻るまい。だがそこには不愉快さが残るかどうかだけに違いがある。