「タチの悪いエージェント」と「業務委託契約」という契約形態の相性の良さについて
最近、PM兼バックエンドリーダーとして関わったプロジェクトにて、フロントエンドが凄まじい状況になりました。
具体的には、フロントエンド開発は、フロントの仕事を丸ごとを別会社に一任していたのですが、全く成果が上がらないどころか、依頼した内容をほったらかしにしてあさっての方向に進み、頼んでもいない機能やライブラリを作ったりしていました。
いくら何でもひど過ぎたので、何度も何度も軌道修正をしたのですが、いくらテコ入れをしてもプロジェクトの完成に向けて進んでくれず、２ヶ月経ってもモック画面の１つすら完成させる事ができなかったので、プロダクトオーナー（クライアント）と相談して「この開発会社やべーっす！早急にチームを再編成しましょう！」と提案したところ、プロダクトオーナーも同じ意見だったため、チーム再編成という事でフロントエンドエンジニアの募集および面談も担当することになりました。
そういった経緯で、エージェント経由で紹介されたエンジニアを採用して行ったのですが、ネタとしか思えないような CHAOS-☆ な状況が生まれてしまいました。
プロジェクトがデスマーチ化する事は珍しい事では無いのですが、コレと同じ事は人生で二度と経験できなさそうなエピソードがてんこ盛りの素敵なプロジェクトに発展しました。
多分、プロダクトオーナーはお祓いに行った方がいいと思う。（本人も言っていました）
以下、歴代のフロントエンドエンジニアです。
エンジニア１（開発ベンダー）
それなりに経験があるので、フロントエンドの技術相談役兼バックエンドという役割でジョイン。
態度はデカいが実力は伴っておらず、最終的な進捗はゼロ。（プルリクを送ったコードの完成度が低く、全てを書き換える事になった。）
本人はバックエンドを重点的にやりたいと言っていたが、フロントの進捗がヤバすぎたのでフロントに比重を置いて欲しいと伝えるも、頑なにフロントを拒否。フロントエンドチームは自分の会社の直属の部下だが、それを面倒見るのを拒否というのはどういう事やねん。（はっきり拒否した訳ではなく、「分かりました」とその場では返事するものの、結局は何もしなかった）
ある日、結構なやらかしをしたので、その事を指摘して次回からの改善を求めるも、まるで第三者が何かをしたかのように淡々と語り、自分に全く非がないかのような無礼な発言と対応をして全く反省する様子も謝る様子も無かったため、「この人は、プロジェクトで成果を上げるのは無理だ」と判断し、プロダクトオーナーに相談して退場してもらう事になった。
エンジニア２（開発ベンダー）
「こういうタスクをお願いします」と依頼するも、ガン無視して全然違う事をやってたり、それに３日〜４日も費やして本来やってほしかったタスクが全く進んでいない事に特に危機感を持たず、「ちょっと進め方が良くないのでは？」とテコ入れするも、プロジェクトの完成を目指のではなく、ひたすら自分がやりたい事だけをやっていた。
考え方もやや特殊で、既存の UIコンポーネントを使えば解決する事をわざわざ自前で作成していたり、要件に全く必要ないにもかかわらず、ツリービューにjsonを渡してメニューを動的表示できる機能を自前で作成したりしていた。（しかも MUI標準のツリービューにその機能は存在する）。
しかも最終的には完成せず、こちらで預かる事になった。
また、全ての MUIをラップして “MuiXXX” という名称でコールできるように、全ての MUIをラップしたコンポーネントを自前で１つずつ作成するという冗談みたいな謎アーキテクチャをせっせと作成しており、とんでもない技術負債となっていたので、全て破棄するに至った。
遅刻も多く、その時の言い訳がバリエーション豊富で、まるでのび太くんの言い訳を聞いているようなエンタメとしての要素があった。例えば、こんな感じ。
「寝坊してました」
「新居に引っ越ししたばかりで、電車に乗り間違えました」
「急遽、回線工事の予約が入りました」
ちょっと酷かったので、彼の会社の営業担当の窓口に相談すると、彼の上司がサポートとして入る事になり、惨状を伝えるために代表とも話をしたが、何一つ改善されないままだった。
というか、そのサポートとして入った上司も問題アリアリだった。
その上司のプロフは、
「プロジェクトマネジメントの天才です。炎上案件を終わらせる事が、シャンクスよりも得意です」
と豪語していたが、何を言っても全く改善されず、やらかしても全く謝る様子が無かったので、
「それ、シャンクスじゃなくて、麦わらの一味がウォーターバークを後にする時、意地張って絶対に謝らないウソップが、そのまま置いて行かれるルートやぞ！」
と、プロダクトオーナーとネタにしていた。（実際、最終的には船を降りてもらった）
テックブログを持っており、ブログには、「ミスを認め、新たな視点を探求する環境を作り出すことが重要です」といった意識高い感じの事が書いてあったが、「書いた本人が実践できてねーじゃん」と、反論内容に本人の書いた記事のリンクでも張っておうかという衝動に駆られた。
最終的にはモックページの１つすら完成させる事ができず、大量の技術負債を残したまま、全ての責任を放り投げて途中からフェードアウトしてしまった。
話は変わるが、最近、「辛いことがあったら逃げてもいいよ。逃げるのは恥ずかしい事じゃないよ。」みたいな風潮がある気がするけど、その裏側には逃げた人が放り投げた仕事をカバーしている人がいるし、逃げずに目の前の問題と向き合っている人もいるので、そういった人を称賛する風潮もあっていいと思う。
今回のプロジェクトでは、PM兼バックエンドリーダーという役割に加え、一時的にフロントエンドリーダーも兼ねてフロントのアーキテクチャ再構築したりと、地獄みたいなタスクを抱え込む事になった。（その後、無事にフロントエンドリーダーは見つかりました）
というか、「辛いことがあったら逃げてもいいよ」と言ってる人でも、「辛い事から逃げてきた人」と「逃げずに困難に取り組んできた人」が採用面談に来た時、後者を採用すると思う。
エンジニア３（エージェント経由のフリーランスエンジニア）
「こんな感じで作ってください」と完成イメージ図を用意するも、全く違う物が出来上がり、コミュニケーションに非常に頭を悩ませる事になる。
具体的には、ツリービューで作って欲しいとお願いしていた部分をハンバーガーメニューで作って来たりと、かなり難があり、レスポンスも異常に遅かった。
最初は副業で入ってもらっていて、レスポンスが悪いのは本業との兼ね合いのせいかと思っていたが、フルタイムで参加してからも変わらなかったので、勤務形態は関係なかった。
技術検証が必要な機能の作成を依頼すると、数日後に「私には難しいです。代わりに引き取ってください！」というメッセージを投げ、『ちょっと待ってください！何が難しいのか、どこまで調べたのか教えてください！』と返信するも、「今日は体調不良なので帰ります」という返信があった後、その後は二度と戻ってくることは無く、そのままフェードアウトしてしまった。
結局、ほとんどの仕事を別のメンバーで引き取る事になった。
最終的には、進捗ほぼゼロという状況だった。
エンジニア４（エージェント経由のフリーランスエンジニア）
ジョインして１週間程度経過した頃に、「コロナにかかってしまい、数週間入院することになりました。」と言い残すが、コロナは嘘っぱちで歌舞伎町でホストとして働いている事が判明。
エージェント会社に、「そっちが紹介したエンジニア、『コロナで休みます』と言っておきながら、ホストクラブのスタッフとして働いているんだけど？」と、彼がホストクラブのスタッフである事の証拠を送り、最終的には契約が無かった事になり、そのまま退場となった。
エンジニア５（エージェント経由のフリーランスエンジニア）
職務経歴書上は、もの凄い経験豊富なうえ現在のプロジェクトに必要なスキルセットも持ち合わせおり、多数のプロジェクトでプレイングマネージャーを経験しており、面接の受け答えでも申し分なかったが、実際にジョインしてもらうと全く成果を上げられず、ひたすら進捗を上げられなかった理由を積み上げていく、口だけのタイプだった。
口は達者で、難しいタスクを振っても、「任せてください！」と物怖じする様子もなかったので、実際は実力が全く伴っていない事を見抜くのに、そこそこ時間がかかってしまった。
経験豊富なエンジニアでも見抜くには時間がかかるレベルだったので、多分、詐欺師や活動家の才能もあると思う。
ジョインしてしばらく経った後、「（職務経歴書上は）こんなに物凄く経験豊富な人が、こういう行動をしたり、こんな発言をしたりするのだろうか？」と疑問を持ち、再度詳しく職務経歴書を細かく見直してみると、妙な部分がいくつかある事を発見。
よくよく分析すると、「この部分は明らかにおかしい！」という箇所をいくつか発見し、さらに詳細に調べ上げると、職務経歴書の特定の部分は、経歴詐称なのではないかと思われる部分を発見した。
プロダクトオーナー（クライアント）に、分析結果とその内容を説明すると、「これ凄いですね。次の面談では、この手法を使ってみましょう」と納得してもらう事ができた。
単価に見合う成果が全く上がっていなかったため、契約終了となった。
.
.
.
「4」 の歌舞伎町でホストやってたエンジニアが、明らかに異質なオーラを放っていますが、今回メインで取り上げたいのは「５」の経歴詐称疑惑があったエンジニアと、その対策について。
ちなみに、最終的にはマトモなエンジニアにジョインしてもらい、プロジェクトを完了まで持って行く事ができるチームを編成する事ができました。
成果を出せないエンジニアがジョインしてしまった時の事前対処案
今回の場合、経歴詐称の疑いがあるレベルの凄まじいエンジニアを招き入れてしまったのですが、そこまで行かなくとも、「職務経歴書は立派だし、面接でも問題なさそうだったのに、何故？」というエンジニアが採用されてしまうのは珍しくないと思います。
そんなエンジニアがジョインしてきたとしても、多くの場合は「契約終了は、１ヶ月前に告知してください」という内容が契約書に盛り込まれているため、いきなり「来週から来なくていいです」「契約は今月で終了です」と申し入れる事はできない事が多いと思う。
そのため、スペシャリストとしての動きを期待したエンジニアのはずが、インターンの学生程度の成果も出せないような地雷が来てしまったとしても、最低２ヶ月は在籍してもらう事になる。
マネージャークラスだと単価90万とか100万を越えるぐ事も珍しくないので、地雷１個で 200万近くの損失が出てしまうだけでなく、その人へのマネージメントコストを考えると、さらに損失は大きくなる。
これはいくら何でも、プロジェクトへの被害が甚大過ぎる。
かといって、地雷が来るのを完全に回避するのは、なかなか難しいと思う。
エンジニアが面接を受ける時、「いかに自分を人材価値が高いように見せるか」と言う事は多かれ少なかれ誰でもやっている事だろうし、それが「ちょっと盛っている」というレベルなのか、「経歴詐称レベル」なのかを見抜くのは、なかなか難しい。
（実際、今回ジョインしてもらったエンジニアも、面接での受け答えは申し分なく、その時点では特に問題があるようには見えなかった。）
そんな感じで、実際にジョインしてらったエンジニアが地雷だった場合、少しでもダメージを軽減できるように、あらかじめ契約内容によってガードできないかと考えてみた。
１． 職務経歴書に虚偽の内容があった場合、確認できるようにする
契約の条文は、こんな感じ。
職務経歴書に、虚偽の内容があると思われる時、甲は事実確認を求める資料の請求ができるものとする。
乙は資料の請求に対して、迅速に提出する義務を負うものとする。証拠の提出を拒否した場合、これまでの稼働を含めて、乙は支払を拒否できるものとする。
証拠の提出を求めて、それに対する返信が無いまま14日が経過した場合、資料の提出を拒否したと見なす。
例えば、
「◯◯社で、X年間、テックリードとして勤務し、チームを牽引してきました。」
といった内容が職務経歴書に書かれていたとする。
が、仕事の進め方が、とてもチームをまとめ上げた経験があるとは思えないほどに悪く、技術力や知識を取っても明らかにテックリードを務められると思える力量を持ち合わせて無い場合、過去に在籍していた会社や契約があった会社に問い合わせて、履歴書のファクトチェックができる、という内容。
具体的には、
「テックリードとしてチームを引っ張ってきて、JavaScript の経験は10年以上、Reactの経験は5年以上あるにも関わらず、同期処理と非同期処理の違いがわからないというのは、いくら何でもおかしいだろ！」
といった違和感が出てきた時、被害を最小限に抑えるための内容。
英語圏の採用だと、「この人はマトモな求職者なのか？」という事をチェックするために、前職の上司や同僚にコンタクトを取り、履歴書の内容や面談で話した事が本当なのかをチェックする事はよくあるらしい。
それの日本版。
使う場面が無い事を祈りたいとは思うが、経歴を詐称レベルで盛ったエンジニアが来てしまった場合のお守り程度に追記しておいても良いのではないだろうか。
やましい事が何もない人なら、こんな条文あったところで痛くも痒くもない訳だし。
２． パフォーマンス次第で、稼働時間を変更できるようにする
契約の条文は、こんな感じ。
乙の成果が、甲の望む成果を大幅に下回り、改善も見られない場合、稼働時間の調整を申し入れる事ができる。
また、乙が甲の依頼に反し、業務命令を無視して別の作業に従事していた場合、その分の作業は勤務時間に含めないものとする。
契約時、1ヶ月の勤務の時間幅を、140時間～180時間といった感じで時間幅が設定されている事も多いが、「これ以上仕事してもらっても、何の成果も上げられない。管理コストを考えると、むしろマイナス」と感じる程にアウトプットの質が悪い場合、稼働時間の上限に制限をかける事ができる、という内容。
契約終了の時期には影響しないので、被害を抑えるには有効なのではないかと思う。
実際、「居ても居なくても変わらない」でなく、「居ない方がマシ（余計な発言をしてチームの雰囲気を悪くしたり、変な事をしてリカバリ作業が発生したり、どうでもいい事を針小棒大に話して対応するのが面倒だったり）」というレベルだった場合に適用する。
改善を求めるも、言い訳を繰り返すばかりで特に反省する様子も無く、しかもそれが 40代後半ともなれば、さすがに教育するという発想よりかは、早期退場をお願いしたくなると思う。
３． 出社要求できるようにする
おそらく一番現実的で、効果がありそうな内容。
契約の条文は、こんな感じ。
乙の成果が、甲の望む成果を大幅に下回り、改善も見られない場合、出社を要求する事ができる。
その際に発生する交通費・宿泊費は、契約金額に含まれるものとする。
また、乙がこれを拒否した場合、それ以降の稼働については、甲は支払義務を負わないものとする。
これは割と現実的なんじゃないかと思う。
今回のような問題で何が面倒だったかというと、タチの悪いエージェントとタチの悪いエンジニアの利害が一致しているという点だった。
今回ジョインしてもらったエンジニアは、明らかにプロジェクトで成果が出せない事が確信できたので早期の退場を申し入れたが、エージェント会社は契約を盾に「いや、でも今月はフル稼働するという契約なんで～」といった感じで、「紹介したエンジニアが、全く成果を出せていない」とい事には全く悪びれもなく、強気に出るだけだった。
エンジニア側も、「成果が全く出せていない」「期待するアウトプットに、全く到達ていない」という事実に向き合い、
「どうやったらクライアントに満足してもらるか」という事を真剣に考えて仕事に向き合ってくれるのであれば再考の余地はあったが、
彼が取った行動は、「いかにしてアウトプットが出ていない理由を作り上げるか」「いかにして、他のエンジニアがやった事を、自分の成果のように見せるか」という事ばかりに力を入れるという凄まじい状況だった。
しかも、「他のエンジニアがやった事を、自分の成果のように見せる」という部分については、実際は PM（ブログ主）がやった仕事を、あたかも自分がやったかのように堂々と報告するという、とんでもない強心臓っぷりだった。何故そんな資料を作って報告した事に対してブチ切れられないと思ったのかは謎だ。「クライアントには、開発の細かい状況は分からないだろう」と、騙せると思ったのだろうか。というか、その打ち合わせ、俺も参加してるんだけど。
さすがにそんな行動をいつまでも許すわけにもいかないので、言い逃れができないレベルの粒度にタスクを落とし込み、もはやスキル的にはインターン以下のつもりで仕事をチェックしていたら、「全く仕事してないじゃないか！」といった批判をギリギリ避けられるだけのアウトプットを出して契約の即時終了を回避するという、何とも頭痛くなるような状況だった。
すると、エンジニアは「仕事してまっせ」とエージェントにアピールする事ができるし、エージェントは「ほら。仕事してるでしょ？」とアピールする事ができて、実際は全く単価に見合わないアウトプットしか出せなかったとしても、契約の即時終了ができない、という状況が発生してしまっていた。
どう言う事かと言うと、
・エージェントはマージン料を取るために、エンジニアには長く在籍して欲しいと考え、強引な手段を使ってでも在籍させる交渉をする
・エンジニアは報酬を得るために、途中退場せずに月末まで在籍したいと考える。（退場してくれるエンジニアも多いと思うが、今回はそのケースに当てはまらなかった）
という感じで、タチの悪いエージェントとタチの悪いエンジニアの双方の利害が一致しているため、互いを助け合う状況が生まれて、クライアント（発注側）にとっては非常に厄介な状況が生まれる。
ならば、その利害を分断してしまうのはどうだろう。
出社する事を条件に加えると、エンジニアの交通費は自腹となり、エンジニア側からの手出しと通勤の手間が発生する。
エージェント側は多くの場合、交通費を出す契約にはなっていないので、エンジニアが自腹で交通費出そうが知ったことでは無い、という状況が生まれる。
つまり
エンジニア側は「交通費を手出しするぐらいなら、契約を終了したい」と考え、
エージェント側は「交通費を手出ししてでも、契約終了まで在籍して欲しい」と考える。
県外からのリモート勤務であれば、これに宿泊費も乗るため、その威力はさらに増大する。
これらの費用を負担してまで仕事を続けたい、と思えるエンジニアはごく少数と思われるので、その時点でエンジニアからの申し入れにより、契約は無事終了となり、大事なプロジェクトの予算へのダメージを抑える事ができる可能性が上がると思うのだが、どうだろう。
職務経歴書の分析手法について（具体的な内容は伏せ）
「経歴詐称疑惑って何やねん。いくら何でも失礼過ぎるだろ。」
と思われたかもしれないが、もちろん言いがかりなどでなく、なぜその可能性が高いのかをロジックとして説明できる材料を揃える事ができました。
優秀なエンジニアでも、新規に参入したプロジェクトではパフォーマンスが出るまでに時間がかかる事はある。
しかし、それを差し引いても、発言や行動に違和感を覚える事が多々あり、日に日に違和感は大きくなっていったので、後で何かの役に立つかもしれないと思い、気になった事があればその都度メモとして残していた。
特に違和感を感じたのは、主に以下のような内容。
- Makefile のコマンドを叩くだけで１発で完了するはずの開発環境が、２日かけてもできていなかった（Readme にも記載済み。他のエンジニアはすぐに終わらせる事ができた）。しかも、その事に対して全く悪びれる様子も無かった。
- １日目、開発環境が構築できなかったのは彼のマシンスペックが貧弱過ぎて Out of Memory でエラーとなっている事が原因だった。そのため、後日に新しいマシンを用意してもらう事になった。自前のPCだったので 100% 彼自身の責任のはずだが、それをリカバリしようとする姿勢が全く無かった。
- １日半かけても開発環境の構築すら出来てい状態で、「困っている事があるので、少し話よいでしょうか。」とメッセージがあったので話してみると、真っ先に出てきたのは夏季休暇がいつなのかという話題だった。
- 夏季休暇の相談をするにしても、「こういうのって、会社側から連絡来ないものなんですかね？ 今までの会社では、夏季休暇については、会社から連絡があったんですよ。」「こういうのを周知してくれた方が、みんなも働きやすいと思うんですよね。」「前の会社では、カレンダーがあって、そこにみんなが休みを登録するようになってたんですよ。」といった感じで、自分からはアクションを起こさず、他の人に何とかしてもらおうという意思が感じ取れた。
- パフォーマンスが出せなければ、すぐに契約終了となる可能性がある事を全く考えておらず、危機感がまるで無かった。
- フリーランスという立場で、しかもフロントエンドリーダーとして案件を請ける以上、求められるのはプロとしての知見・知識・成果のはずだが、「私にも知らない事はたくさんあります！」と堂々と発言し、まるで新入社員のような扱いを望んでいるかのような印象を受けた。（知らない事があるのは問題無いが、持ってる知識を活用して成果を出す様子が見られなかった）
- 稼働5日間（40時間）での成果：「作成したドキュメント数：0」「プルリクの数：0」「プルリクのレビュー数：0」「プロジェクト管理ツール上の活動：0」
- 稼働11日間（88時間）での成果：「作成したドキュメント数：0」「プルリクの数：0」「プルリクのレビュー数：2」「プロジェクト管理ツール上の活動：0」
- パフォーマンスが出ていなかったので、その事について打ち合わせをしたところ、「私は頑張っています！まだプロジェクトに入って日が浅いんですよ！」と、特に自身で改善する様子は見られなかった。（一部、彼の言い分には納得できる箇所はあったので、その時は経過観察という事で落ち着いた）
なかなかのボリュームだが、これでもほんの一部。
そして、別のエンジニアに、一緒に仕事をする事になる彼の経歴を説明するために、改めて職務経歴書を見直してみると、面談時には見落としていた、おかしな点に気づくことができた。
思い付きで、ちょっと視点を変えた分析してチェックしてみると、本当の事を書いているとは思えない内容が存在する事をに気が付き、
「この職務経歴書は絶対におかしい！全てが嘘で塗り固められているとまでは言わないが、絶対にフェイクが含まれている！そうでないと説明できない部分がある！」
という事を確信できた。
しかし、この時点では、「職務経歴書の、どの部分がフェイクなのか」という事までは特定できなかった。
そこで、彼の職務経歴書を、キャリア１年目から辿っていく事にした。
自分の場合、通常は職務経歴書を注意深く読み込む時、遡ってせいぜい５年、長くても１０年ぐらいまでで、それ以前のキャリアは流し読みする程度だが、今回に限り、彼の２０年以上の職務経歴を、キャリアの１年目から注意深く読み込んでみた。
すると、彼の経歴の１０年目ぐらいまでは、「ある傾向」が存在する事が分かり、その「ある傾向」を直近のキャリアにも当てはめて、「本当の職務経歴は、こんな感じなのでは？」と仮定すると、違和感なく説明できる部分がいくつか出てきた。
他にも、
「この時期はコロナが流行し始めた頃のはずだ！その時期に、この会社がこういう仕事を発注するのはおかしい！」
という視点や、
「この時期は、同時に複数の案件を請けている。この年代に、この企業がフルタイム以外の勤務形態を許容しているのは考えにくい。」
という視点でも職務経歴書のおかしな点を見つける事ができた。
こういった点を精査し、「実際の職務経歴書は、こんな感じでは？」と仮説を立ててみると、今まで違和感を感じていた様々な部分が、まるでパズルのピースを当てはめるかの如く、矛盾なく説明できるようになった。
まるで推理小説の謎を解き明かして行くかのような面白さがあった。
ここまで整理できると、もう十分に人に説明できる資料になったので、プロダクトオーナー（クライアント）に説明し、晴れて退場の運びとなりました。
思いついた分析手法については、今回は絶大な威力を発揮しましたが、注意すれば割と簡単に回避できるうえ、詳しく説明するには実際の職務経歴書が必要となり、それを使うと個人情報的に問題があるので、これは自分自身のノウハウ＆飲み会のネタとして保持し、地雷回避の１つの武器として留めておく事にします。
経歴詐称を続ける事が可能なのか
条件さえ揃えば、恐らく可能です。
もちろん、ある程度のIT業界での就業経験と知識は必要となりますが。
具体的には、以下の行動を取ります。
- 自分の能力を過大評価させるように、堂々と振る舞う
- 難しいタスクは部下もしくは他のエンジニアに任せ、自身は簡単なタスクのみを選択できる状況を整える。
- 些細な問題を、実際よりも過大に表現し、致命的で重大な問題に取り組んでいるかのように見せる。
- 実力がはっきりと推し量れてしまうタスクは絶対に着手せず、部下や他のメンバーに任せる。もしくは適当な理由を付けて途中から別のタスクに着手し、そのタスクを別のメンバーに依頼する。
- タスク着中に発見した問題は、些細な出来事でも大げさに表現し、延々と調査を続ける。見つけた課題の解決はせず、「その問題を調査していたので、遅延が発生していました」と言い訳をする材料を揃える事に労力を割く。
- 簡単な課題を数多く消化し、大きな成果を上げているように見せる。
- 常に評価者目線で物事を語り、詳しい事情を知らない人からは、あたかも彼がマネジメントをしているかのように錯覚させる。
- 間違った事を言っても、決して謝ったり非を認めたりしない。言葉巧みに会話を誘導し、 ミスをせずに進めているように見せる。
- 周りから実力を疑われる事に感付いていても、強引に推し進める事ができる胆力と度胸、そしてハッタリを最後まで貫き通す強さを持つ。
- ほとんどアウトプットを出していない事を自覚しつつも、退場にならないギリギリの成果を狙って仕事ができる。もしくは、仕事をしているように見える振る舞いができる。
- 「個人の成果」に重点を置かず、「チームとして成果を上げる事ができれば、それでよい」という主張を展開する。（自分自身が何もしなくてもバレないため）
そして、労働環境としては、以下の条件を満たしてる必要があります。
- 上司は開発業務については詳しくない。もしくは、第一線を退き、技術的な知見には疎い。
- 優秀な部下が揃っている。（優秀なエンジニアの居る部署の上長として配属されている）
- メンバーが多く、一人一人の成果を測る難易度が高くなっている。
上司が開発業務の知見に疎く、予算が潤沢にある大企業の大規模プロジェクトなら、この動きでも十分に生き残れる可能性はあります。（実際、彼がこれまで関わってきたプロジェクトは、大手企業の案件が中心だった）
実際、プロダクトオーナーは、アウトプットが出ていない間も、「異常なスロースターターなだけかもしれない。エースの復活を信じるような気持ちで待ってみたい」と、どこか信じている様子でした。
というか僕自身も、彼の話している内容そのものは大きく間違っているものではなく、会話スキルは相当なものだったので、「もう少し様子を見たら、成果が出せるようになるかも」と思わされました。
しかし、これまで感じた違和感を記録として残して分析していく事で、「やっぱり、彼が成果を出す事は無い」と、確信する事ができました。
最終結論を自分で出せるように、判断材料を集めておく事の重要さを実感した事件でした。
ちなみに、こういう仕事の進め方をするメンバーが居ると、プロジェクトは非常に厄介な事になります。
アウトプットが出ていない事も問題でしたが、それ以上に、他のメンバーに余計な手間を取らせてしまう事になったり、報告内容した内容からプロジェクトの状況を正確に把握する事が難しくなっていた事も大きな問題となっていました。
例えば、以下のような感じです。
- 報告内容は、「プロジェクトの状況を正確に伝える事」よりも、「彼自身が成果をアピールする事」に重点が置かれているため、正確に状況が伝わらなくなっていた
- 他のエンジニアがやった事を、あたかも彼がやった、もしくは彼自身が指示してさせたかのように成果をアピールするため、他のエンジニアにファクトチェックを入れる作業が発生していた
- 実際は簡単なタスクでも、あたかも難しい問題に取り組んでいるようにアピールするため、タスクの実際の難度と適切と思われる工数を、わざわざ調査する作業が発生していた
簡単に言えば、彼の言う事はどれも疑ってかかる事が前提となってしまっており、全ての報告にファクトチェックの作業が発生していた事が遅延の原因の１つとなっていました。
時々、妙なやらかしをしていたり、間違った事を言っていたりもしていたのですが、その度に彼が発揮する会話の誘導スキルは結構凄いものもありました。
特に凄いと思ったのは、彼の退場が決まったため（まだ正式通知はしていない状態）、「もう彼のマネジメントに使う労力は、最小限にしておこう」と、対応を適当にこなしていたら、彼がプロダクトオーナー（クライアント）に、こんな感じの連絡を入れていました。
「彼（PM）は、自分側の人間と、そうでない側の人間を、はっきり分ける傾向があるようです。」
「彼（PM）は自らを傭兵と言っていますが、私はモノ作りを楽しみ、良いものを作り、社会貢献している人間です。
そういうアイデンティティが全く違う事が、私が入り込めていない原因でしょう」
ちなみにプロダクトオーナーとは、プロジェクトのメインチャンネルとは別のチャンネルで、
『＜雑談 ☆超特ネタ☆＞
100%の自信を持って、Kさんを大爆笑の渦に叩き込む事ができる、超ド級のネタをお届けします-☆』
といったメッセージと共に、コロナで数週間入院しますと連絡してきたエンジニアが歌舞伎町でホストとして働いている証拠を送ったり、東京行っていた時には一緒に食品サンプル作りに行ったりVR脱出ゲーム行ったりと、カジュアルな連絡も含めて密に連絡をやり取りするぐらいの関係が出来上がっていたので、彼の行動は全て筒抜けだった。
彼に対して塩対応となってしまったのは、「ありがとう」と「ごめんなさい」が言えなかったのが原因なんだが、プロダクトオーナーと日常的に話す中で、何度もそれについては触れていたので、実情はバレバレだった。
というか、「ありがとう」と「ごめんなさい」を言えない人間が、チームからどう評価されるかというのが、客観的に判断できないのだろうか。
評価が低い理由について、自分自身が全く成果を出せていない点から完全に目を背けている事はとりあえず置いといて、凄いと感じたのは、PMが自分自身を『傭兵』と表現した部分について。
確かに、僕は彼との会話の中で、『傭兵』という表現を使用した事がある。
しかし、それは
『僕らはこのプロジェクトを完了させるために集められたメンバーで、自社の人間ではない。そのため、福利厚生を求める立場ではない』
という意味で話しており、
『まぁ、僕ら、このプロジェクトのために集められた傭兵部隊みたいなものですからねー。（フリーランスだったり、協力会社だったり）
夏季休暇とかが欲しければ、直接交渉してみては？』
といった会話で出てきた言葉だった。
にもかかわらず、
「私は社会貢献したいだけの人間です」という主張と、
「彼は自分の事を傭兵だと言っています」という主張を同列に並べて使う事で、
「私は、社会やプロジェクトに貢献したい、という考えを持っています」
「彼は、傭兵として働いているだけで、社会貢献性は無く、お金さえ稼げればよいという考えを持っています」
という印象を読み手に持たせる構成になっていた。
嘘をついていないにもかかわらず、事実のみで意図的に全く異なる印象を持たせようとする巧みな手法。
見事過ぎる。エンジニアよりも活動家の才能があるんじゃないかと思った。
そもそも社会貢献したいアピールというのは、どういう意図やねん。
社会貢献したいならフリーランスエンジニア以外に適した職業がいくらでもありそうだぞ。少なくとも、僕はこれまでそんな事を前面に出すエンジニアに会った事がない。
というか、クライアントは成果を出して欲しい、ひいては会社の利益に貢献してほしいと思っているわけで、「社会貢献したい」といった個人の精神は、多くの場合はクライアントにとっては優先的に考えてほしい事ではないと受け取られるのではないだろうか。社員として働くなら 100歩譲って分からなくは無いけど。
そういえば、社会貢献と言うなら、以前、とある NPO法人に１万円を寄付した事があるぜ。
あとで、そのNPOの代表は実は詐欺師だった事が発覚し、現在複数の人から被害届が出されている状況だけどな！
今回のプロジェクトとは直接は関係のない事件だったけど、「社会のために！」と声高に叫ぶ人が、本当に清廉潔白で後ろめたい事が無いことなんてほぼ無いんじゃないかと思った出来事だった。
その他のプロジェクトの影響
当方、フリーランスエンジニアとして仕事ををしており、他のクライアントから別の案件の打診を受けていました。
『このプロジェクトが終わったら、その案件をお請けできます！ X月に納品なので、○月から入れそうです。』
と伝えていたのですが、前述の通り、プロジェクトが非常に CHAOS-☆ な状況だったので、
『すみません！ちょっとプロジェクトがひどい事になっていて、納期が延びそうです！』
と何度も伝える事になってしまっていました。
チーム編成をするも、カオスな状況が改善されるまでは随分時間がかかったため、その案件を紹介してくれたクライアントには、
『すみません！ プロジェクトが、また酷い状況になり納期がさらに延びそうです。
開発ベンダーがアレだったので新しくエンジニアを募集したのですが、１人は速攻でフェードアウトして、１人は「コロナでしばらく休みます」と言っておきながら実は歌舞伎町でホストやってて、１人は経歴詐称疑惑のあるヤベー奴でした。』
と、連絡を入れる事になりました。（内容が酷過ぎるので、文字だけで伝えようとせずに、オンラインで話しました）
上記の内容を伝えると、
「え？ ちょっと待って。何が起こったの？ 頭の中で上手く情報を繋げる事ができなかった。どういう事？」
という反応をされました。
俺もそう思う。
が、これが事実である事をちゃんと伝えておかないと、仕事を請けたくないがために適当な理由を並べてプロジェクトの遅延を何度も話していると受け止められる危険性があるので、包み隠さずに伝える事にしました。
さすがにこんなイレギュラーで珍しい事が起こると、それらが事実である事を裏付ける話の１つや２つぐらいは話しておかないと、とても信じてもらえないと思ったので、経歴詐称疑惑のエンジニアについては、経歴書のどんな点に違和感を持ち、どんな分析手法を使って矛盾を洗い出したのかという手法を説明しました。（個人情報にあたるので、個人を特定できる情報はフィルタリングしました）
その手法について説明すると、結構いい反応が返ってきたので、自分がまた採用の仕事をする機会があれば活用してみようかと思います。
ちなみに、コロナでの休みが嘘っぱちで実際は歌舞伎町でホストをやっていたエンジニアについては、ホストクラブのWebサイトもスタッフリストもSNSも全世界のユーザがアクセスできるオープンな状態だったので、別に共有しても法的に何か問題のある内容ではないと判断し、普通にシェアして事情を説明しました。
歌舞伎町に消えたエンジニアの話は、これだけで１本の記事にできる壮絶なネタになったので、個別のエントリにしたいと思います。
（追記：書きました）
コロナで入院しているはずのエンジニアが歌舞伎町でホストをやっていた話
※現在はホストクラブのスタッフリストから名前と写真は消え、SNSも削除されています
案件と探す側としてエージェントを利用する事について
今回、プロダクトオーナーが利用したエージェント会社は、めちゃめちゃタチが悪かったので、「二度とこの会社は利用しない」と話していました。
私もその意見には賛成で、エンジニアのとして仕事を探す立場の場合も、ここは利用しないでおこうと決めました。
また、エージェント会社は、別のエージェント会社を経由する事もあるので、念のため「商流に、この会社が入る場合、ちょっと遠慮させてください」と、警戒レベルを上げておこうかと思いました。
（規模がそう変わらない会社のエージェント間でも商流を挟む事があります。何故こんな事が起こっているのかはよく分かりませんが。エージェント会社さんは、同業他社を経由しないように、もう少し営業頑張ってほしいと思っています。というか何で同業他社に営業に行くのかが謎ですが。）
さすがに、「コロナで入院します」と報告したエンジニアが実は歌舞伎町でホストやってたにもかかわらず、しれっとこれまでの稼働を請求して来たり、地獄みたいなパフォーマンスしか出せないうえに経歴詐称の疑惑まで出て来るような特級呪物を紹介しておきながら、何の悪びれも無く契約を盾に契約満了まで滞在させようとするのは、どう考えても悪質だと思います。
コロナの影響でリモートワークが一般的になり、リモート案件を多く扱うエージェントが増えたものの、今まで利用したエージェントは「２度と利用しない」と「悪くはなかったけど、特に積極的に利用したいと思う理由は無い」の２種類のみで、今後も優先的に利用したいと思えるエージェントには出会えていないというのが正直な感想です。
エージェントを介さずにお仕事が取れてくる事が増えてきたものの、海外移住を考えいるので、現地での仕事が無くとも日本から仕事を取って来るルートを確保してのはビザの問題で強制的に退去という心配を減らす事ができるので、そのためには信頼できるエージェントを見つけておきたいと思っています。
その件についての詳細は、こちらをご参照ください。
スペイン在住の日本人に聞いた、ヨーロッパの就業事情と、ビザ取得に苦労したという話と、女性なら有利に働くケースもあるという話
特に「２度と利用しない」と思ったエージェントのうちの１社は、契約書をよく読むとこっちは消費税を請求できない契約になっていたが、クライアントにはちゃっかり消費税を上乗せして請求していました。
つまり、本来はエンジニアに支払うべきお金を、会社の利益として計上していました。
（クライアントとも良好な関係が築けていたので、その辺の話もしやすかった。）
さすがにこれは酷いんじゃないかと思って問い詰めたところ、
「いやー、ウチは非課税事業者には消費税を払わない方針なんすわー」
とワケの分からない事を言っていたので、
「いや、課税事業者かそうでないかを判断するのは、アンタらじゃないよね？」
と、言ってることの何がおかしいのかを、１つ１つ証拠付きで指摘する事になりました。
最終的には、契約更新時に消費税分も払ってもらう契約に切り替えたが、過去の分はどうにもならなかった。
結果的に、合計20万以上請求し損ねる事になりました。
「いや、契約書をよく読めば回避できただろ！」という突っ込みが入るのは当然ですが、今までいくつかエージェントを利用してきましたが、こういう事は無かったので、ちょっと油断していました。
勉強代だと思って、諦める事にします。
※インボイス開始前の話です。インボイス開始以降は、どうなっているのかは分かりません。ちなみに結構大手です。
あとは、「悪くはなかったけど、特に積極的に利用したいと思う理由は無い」というエージェントなので、リモート案件を扱うエージェントは、「今後も積極的に利用したい」と思ってもらえるようにサービスの品質を向上していってほしいと思っています。
コロナが流行するまでは、PE-BANK さんをよく利用していましたが、リモート案件があまり得意ではないという点と、自分のスキルセットがエンプラ系・.NET系から、Web系に寄ってきたため、マッチする案件が少なくなってきたことから、利用する事が少なくなってきました。
（PE-BANK さんはエンプラ系案件を得意としており、Web系はあまりカバーしていない）
ただ、今まで利用したエージェントの中では、ぶっちぎりで仕組みとしてよく出来上がっていると感じているので、ご縁があれば、また利用したいとは思っています。
特に僕が PE-BANKを利用し始めた頃からお世話になっている営業の Yさんは、
「エンジニアとエージェントが対立する状況になった時、エンジニア側に立つのが真の営業だ！」
まるでバクマンのような考え方を持っており、それ以外にも芯の通った考え方と行動をしていたので、とても頼りにしていたのですが、最近はちょっと疎遠気味です。
少し前に、
「久しぶりです。今、私がPMやってる案件で人が足りないんですけど、スキル的にマッチする人がいたら、PM-BANKさんから紹介ってできます？」
と連絡を取ってみるも、特に返信がありませんでした。
去年、合コンメンバーの紹介と橋渡し役までやったのに、ちょっと冷たくないですか？ Yさん。（当方は既婚者のため不参加）
コメント