なんだこのプログラマ、この程度のことも頭使って対処できねえのかよ、と思っているプロジェクトマネージャーも多いことだろう。
さえずるな、バカが。
この程度のこともできねえのか、と思った時、それは貴様がプログラマの実力に応じた指示出したり、すり合わせをできなかった結果、あるいはプロジェクトに見合ったメンバーさえ雇えなかった人事、それらすべての失敗が貴様らの愚痴となって吐き出されたにすぎない。
この業界では「この程度のこともできねえのか」というプログラマは最初からはじくのが原則だ。そんなのがメンバーに入っているということは、貴様の目が腐っていたにすぎない。単なる能力不足について語ることはない。最初から雇うな、以上。
だが、こいつはどうして進捗が遅くなったのか、この程度の見落としをするのか、と思うこともあるだろう。なるほど、そんなときでさえ、やっぱり使えねえ野郎だ、と思うべきではないのだ。一体なぜだ、何が抜けているのか、何が難しいのか、それらを考えてコミュニケーションをとり、進捗を改善するのがマネージャーの役割。つかえねえ、と切り捨てたくなった時、それはマネジメントの敗北である。つまり使えない理由とは、そもそも使えない状態にしているということでもある。自分自身の例を出してやろうじゃないか。
僕の仕事をそこそこ進めて、気分良く帰宅した金曜日から休み明け。意気揚々とマンデーブルーの会社に来てみると、障害票にメタクソ大量の記述がある。
なんじゃあ、こりゃぁ！
と松田優作ばりの声を上げたいのをこらえて、一つ一つチェックする。そして最後のエクセルの行を見終えた時、僕はキレた。何も言わずキレた。徹底抗戦してやろうと思った。最後の行には入力チェックがちゃんとできてないので全部やり直せ、というように書かれていた。PMがご丁寧に土曜出社してまで、書きたかったことがこれだ。お前は何も見ていないんだぞ、と。憎悪がこもっている気がした。
入力チェックができていないというから、なんのこっちゃと思った。全部やり直せというからにはやらねばならないわけだが、おわかりだろうか、内部設計書がないのである。入力チェックをやらんねばならないが、入力チェックの設計一覧には僕の担当画面のチェックも存在せず、内部設計もないのに作った画面である。
年末、エンドユーザーがひたすら突貫で重要な画面の設計書だけを作ったのが、僕の担当画面だ。僕は忖度した。哀れなエンドユーザーの設計者に配慮して、軽い2画面分の内部設計は免除したのだ。何も言わず口頭ベースで作ってやった。これがいけなかった。そんな優しさを知らない、僕を嫌うマネージャーは憎悪爆発で、ちゃんとチェックしろと来た。ねーんだよ。再チェックのための資料が。何が正しいのか、何を見てチェックをすればいいのか、存在しないのだ。大雑把には正しい動きをするが、細かい動きは定義が存在しねえんだ。そこに配慮して、後から時間をもらえるだろう、画面が完成したころに足りない部分は優しく指摘してくれるだろう、そう思っていた。
テストフェーズとは、ある程度完成をして以降のフェーズである。それは建前だ。僕らプログラミングの完成よりも先に、貴様らが、設計を、方針を、決めて共有して、常にそれらを確認することで入れるフェーズだ。それらを怠り、口頭ベースで作るなんてことが起こったなら、それは不具合の温床、行き違いの原因、不満と不安のランデブー。
validationチェックはプログラミングの基本だ。しかしそれをいつやるか、ちゃんと定義されているかはまた別である。例えば検索画面の番号入力欄に「田中」とか「TEST」とか入力しちゃう愚か者を配慮すべきだろうか。
番号って書いてるだろーが。
セキュリティホールになるかも？親切設計にすべき？
営業しか使わない社内アプリに親切設計か。だったらどこまで親切にするか、定義しろや。ぶっちゃけ番号に「田中」と入力しても検索結果がでないだけなんだよな。それでも親切設計にするならどこまで親切にやるか決めろや。内部設計書さえちゃんと書かない野郎どもが偉そうに指摘しやがって。
ぼく「XXさん（別の開発者）、番号だとかの入力チェックでめっちゃ指摘受けたので他の画面を見たら、特に入力チェックないんですが、どうなってますか。」
XXさん「最初は入れたのですが、去年の話なのでいろいろ変更があって今は機能してないんです。共通処理修正しております。急ぎでやらないといけないのですけれど。」
クソが。なんで共通処理の変更さえ終わってないし、他の画面もチェック入ってないのに僕だけに強気のご指摘したんだ、アホか。誰も仕様確定理解してねーじゃねえか。そこを統一すんのがてめえらマネージャーの仕事だろうが、僕にマウントとりにきてんじゃねーぞ。僕だって共通処理を修正しているってことぐらい知ってて、残しておいたところを不具合扱いしやがってこのポンコツが。仕様フワっとした状態でバグ指摘として処理するとか、おめープロジェクト管理してねえだろ。
あと緊急タグつけて、APIの不具合をこちらの検索不具合として扱ってんじゃねえよ。これも僕が忖度して甘く見てやったけれど、てめえんとこのエンドユーザーが作ったAPIが何度も不具合おこしてんだよ、なぜかわかるか？単体テストしてねえからだ。
そこで連携部分の担当の僕がまるで不具合起こしたみたいに画面上では見えるかもしれないが、てめんとこの金主エンドのせいだ。てめーが偉そうにご指摘なさらなければ、黙っといてやったがもう許さねえ。エンドにAPIの単体テスト要求してやったわ、ただでさえ忙しいエンドユーザーの仕事増やしちゃったぜ。本来なら貴様らがコストを支払うところをやってこなかったからね、しょうがないね。
とまあこういうことだ。いいかい？プログラマはそれぞれ違う人間なんだ。仕様の統合、連携、通知。特に共通処理に関しては「せーの」が必要なんだな。こいつは気が利かないとか、不具合を起こすってのは、本当に単なる確認不足と言い切れるか？マネージメントのできる範囲で改善できないか？不具合原因を切り分けやすい環境を提供できているか？
ぼく「APIを利用する画面はローカル環境だと動かないです(VPN必須のため)。だけどテスト環境のmasterブランチは一時間に一回しか更新されませんが、なんかうまい方法ないですか」
サブリーダー「みんなやってますけど、直接ソースコードをテスト環境に上書きすることで対応できませんか？」
？？！？！？！？？ｗｗｗｗｗｗｗｗｗｗ
みんなやってるんだｗ
エターナルサーバーダイレクト更新！
プログラマは死ぬ
とまあこんな感じだ。
この状態で僕が使えるプログラマ足りえるだろうか？
歯を食いしばって頑張るなんてとてもとても。
そうしてゴミみたいな評価でここを去る羽目になるのだ。
だがそれでいいじゃないか。どうせ二度とは戻らない
何故あなたのチームのwebプログラマは不具合を起こすのか - フロイドの狂気日記
