![見出し画像](https://assets.st-note.com/production/uploads/images/141221115/rectangle_large_type_2_2031ccf2489e4ee2df0e24681b5d7fb8.png?width=1200)
ヤバいリーダーについて話したい
フリーランスは孤独だと思われがちだ。
ただ、少なくとも僕はプロジェクトを一人で完遂したことはない。
あくまでチームの一員として、プロジェクトがうまくいくように力を尽くしている。
長年(といっても10年ほどだが)フリーランスという立場で仕事をしていたが、本当にいろんな人に出会った。
とても仕事のできるエンジニアに助けられたことなど山ほどある。
僕自身はお世辞にも優秀なエンジニアとは言えなかった。
中の下くらいだろう。
ただ、僕みたいな中の下くらいの凡人エンジニアから見ても、
「この人は(悪い意味で)異常だ、ヤバい」と思った人もたくさんいた。
そして、その「ヤバい人」の中でもレベルがあって、プロジェクトをかき回すレベルでヤバい人だっている。
逆に言えば、炎上プロジェクトの火種はだいたい1~2人のごく一部の人間であることが多い。
今回は僕が出会ったヤバい人を紹介したい。
自意識過剰系マネージャー
とあるシステム開発の現場で、はつらつとしてふくよかな30代半ばくらいのPM(プロジェクトマネージャー)がいた。
以下、見た目で決めて申し訳ないが、ワリオ氏とする。
見るからに楽しそうに仕事をしているのが印象的だった。
内線での社員との会話の8割が笑い声だったほどだ。
ワリオ氏は中途入社の人らしく、最初からPMとして入社したわけではなかった。
最初は開発プロジェクトのメンバーとして、普通に設計、コーディングといった手を動かす作業もやっていた。
ヤバそうなコード
当時僕が任されたのは、ワリオ氏がかつて開発に携わっていたシステムの仕様追加対応だった。
Javaで作られたシステムで、設計パターンはMVCモデル。
JSP(JavaServer Pages)は主にHTMLで画面周りを表現し、細かいロジックはControllerが担う。
当時よく見かける構成で作られた、EC一元管理システムだった。
僕はそのシステムのほんの一部の改修作業を担当することに。
ほんの一部ではあったが、別の仕様追加・改修作業もたくさんあったため、今後に備えてまずは全体構成を掴もうとした。
前述したように、JSPの大部分はデザイナーが作るのが一般的だった。受注による在庫数の変動、管理のロジックはControllerが担うのでJavaプログラマーが作成する。僕の担当だ。
ただ、JSPを見ていると
何やら様子がおかしい。
Javaのコードもゴリゴリに書かれている。
むしろJavaのコードの方が圧倒的に多い。
当時の開発を知る他の社員に話を聞くと、昔にワリオ氏が書いたものらしい。
JSPはHTMLファイル扱いなのだが、HTMLの中にJavaのコードを埋め込むこと自体は可能だ。
なので、設計パターンを度外視するなら、JSP一枚で画面周りもロジックも両方書くことはできる。
でも、両方書いてしまうと激しく読みづらくなる。
画面デザインをちょっとだけ変えたいのに、大量のJavaコードが邪魔をしてしまい、どこを変えればいいのか分かりにくくなる。
ロジックを変えたい場合も然り。
よって、開発生産性が落ちる。
これは理由や経緯を聞いておかないと、後々大変なことになりそうだ。
と思っていたものの、当時の僕は自分のスキルに自信がなく、業務委託の立場は弱いと思い込んでいたので、聞くことができなかった。
最悪の事態へ
そして、想定していた最悪の事態が起こったのだった。
仕様追加のスケールが大きく、JSPの書き方を大きく変えなければならない状況になってしまったのだ。
もちろん、書き直すのはワリオ氏が作ったJSPだ。
数千行に及ぶ地獄のJSPのコードを読み解く必要があった。
む、無理だ…
読み解くだけで1週間くらいは平気で溶かしそうだ。しかも血を吐きながら。
その後、現行踏襲で一度書き直し、それからやっと仕様追加のためのコード改修を入れていく。
途方もなさすぎて、工数見積もりにすら時間がかかりそうだ。
下手に少ない工数で報告して後で責められても困る。
かといって、大量のバッファ(=何かあったときに備えた予備の工数)を見込んだ工数を出すと、ロースキルと見られて契約継続自体が危うくなる。
まぁ、ロースキルだったんだけど(笑)
結局まともに工数を見積もることなどできなかった。
ただ、クライアントが求める納期はあった。
エグいくらいタイトなスケジュールだ。
でも、ワリオ氏はただ
「頑張ってください、ガハハ!」
と笑うだけだ。
くそぅ、この人プロジェクト管理する気全然ねぇ…
コードを見せながら、状況を説明したこともあったが…
あーこれですね!大変だったんですよ!
でも苦労した甲斐あって、今はこれを”テンプレ”として流用できるんで、
他の開発案件の生産性上がりますよ!
テンプレの名前つけないとなぁ… ガハハ!!
…すごい。
状況を打破するための助言をするどころか、昔話と「テンプレの名前付け」というどうでもいいタスクを自分に課して、話が終わってしまった。
徹夜の作業
結局、納期直前の時期は会社に泊まり込み、徹夜で作業した。
そして、なぜかワリオ氏も徹夜した。
世界一分かりやすい無駄な人件費である。
徹夜の作業中、かつて自分の書いたJSPのコードについて一言も解説がなかった。
おそらく、下手に解説してしまった結果、自分にも責任が生じてしまうのが嫌だったのだろう。
既存バグを自分のせいにされたくない。
あわよくば僕の出した不具合にしてしまえれば、ワリオ氏本人としては気持ちがラクだと考えたのだろう。
実際、既存バグは多々あったのだが、ワリオ氏はまったく我関せずだった。
椅子に座って、やんわり作業をあおる。
たまにコンビニでスイーツを買うという重要な仕事をやっていた。
食べるのに忙しそうで、とても声を掛けられる雰囲気ではなかった。
今の僕が思うこと
他責思考の塊。
ワリオ氏のことを周りの社員もそう思っていたようで、ちょっと困っているようだった。ただ、仕事が絡まなければ良い人だった。
僕が子どもを持ちたいと思ったきっかけになった人物でもあった。
あれから10年ほど経ったが、元気にしているだろうか。
ワリオ氏のおかげで、油断すると他責思考で楽になろうとする自分がいることにも気づいた。
今となっては、ワリオ氏も僕の23本の指に入る師匠の1人だ。
(ただし、反面教師)
この記事が気に入ったらサポートをしてみませんか?