自分の仕事としては案件進めているうちに出てくる課題とか機能追加とかバグ修正とかを設計してIssueとして作って他の人に振ったり自分で作業に当たったりと色々なんだけど、
最近とあるプログラミングスクール出身の同僚エンジニア(最近同じ部署になった)が自分の案件にアサインされた。
内容としてはとあるテーブルの特定カラムのバリデーション処理が漏れているから追加してもらって、なおかつユニットテストを修正する、というもの。まあ簡単な奴。
Issueを振ってからしばらくすると同僚エンジニアから質問が来た。
「ん?」と思った。いや別に特殊なことなんて何もないIssueだし似たようなテストケースもリポジトリ上に山程あるしどうにでもなるじゃんって。
まあ特に考えず1個のテストケースを例として自分で作ってみて、「残りは○○の場合とXXの場合と△△の場合のテストケースを網羅してください」みたいな返信をした。
しばらくするとまた質問が来た。「△△の場合のテストケースの実装方法がわかりません。」
いやいや、そんなん頭使ってどうにかこうにか考えろよって。案件特有のビジネスロジックのことを聞かれるならわかるけどこんなレベルの対応どの企業のどの案件で振られても同じことやるだけやん。
この質問してるのが未経験の入社1ヶ月目の新入社員なら自分は笑顔で答えるけどこのエンジニアは俺よりキャリアが長いらしい。
その同僚エンジニアはわからないことがあるととにかく素直に「わかりません」と言ってくれる人だった。
成果物についても指摘事項があまりにも多く、自分(というかその人以外)がやったら10分くらいで終わる対応に数時間以上かけて説明して修正してもらうという感じになった。何のための仕事をしているのかよくわからくなっていた。
自分はITエンジニアが「わかりません」という言葉を使うのは例えばどうしても再現性がなくてログにも何も残ってない謎の不具合とか、コンパイラやインタプリタレベルの不具合で現時点で解消方法がどこにも載ってない奴とか、そういうマジで「参りました」的な状況だけかと思ってた。
こんな公式ドキュメントとデバッグツールだけでどうにでもなる状況で「わかりません」を使う人に遭遇するのは初めてだった。
その人はとにかく「わかりません」が多い。
レビューの指摘の意味がわからない、指摘内容はわかっても修正方法がわからない、影響反映を洗い出してほしいと言ったら影響範囲の洗い出し方がわからないと言われる。何ならわかるのか教えてほしいくらいだった。
うっすら評判悪いのは知ってたけど実際に仕事してみると尋常じゃないほど酷かった。
こっちもいろいろ対策を考えた。
Issue振るときはソース上に「↓ここの○○をXXになるよう修正してください」とコメントを書いてから仕事を振るようにする、「わかりません」が来そうな部分は先手で予想して回答を載せる。
でもダメだ。こちらの対策なんてものともしないように全てを掻い潜ってくる。
もはやその人に仕事を振るのは「この作業を担当してくれたら助かる」ではなく「この作業であれば流石に”わかる”だろう、そして単純作業の量が多いからしばらくは邪魔されないだろう」という感じにできる限り疑問点が少なく時間がかかる作業で”遠ざける”のが目的になっていた。
最低でもあと1年くらいは人事はこの状況らしい。。。
こういう状況ってどう扱うのがいいんだろうなぁ。
首に持っていけよ。無駄だから。
そのひと、たぶん仕事に興味ないんだろうな。だから前もって勉強するということをしない。 エンジニアに向いてないよね。 マニュアル覚えてその通り繰り返せば終わる仕事に転職した...
解雇が良い。解雇するまでは他の人を時間を奪わないようにするのが良い。俺も経験ある