その状況で巻き取ったほうが間に合う可能性が高いなら巻き取った方が良さそうと思いました。

- 成長に投資する価値がある若手社員

- 少しサポートしたらそれなりにバリュー出せる見込みがある

以外は個人的には付き合う気になりません。会社にとってもチームにとっても不利益なので。

過去にそう言った人々を根気強くサポートしたこともありますが無駄だったなとしか思っていません。

外注？なんてなおさら育てる義務も責任もないですから、落ち着いたらすぐに担当変更させるか切るかしますね。

発動してオッケーかと。

ただそれは私がクライアントワークをしていて、メンバーの成長の前にクライアントに価値を提供する責務があるため。

事業会社だと機会損失を防ぐためって感じでしょうか。結果的に社員の給料にはねます。

クライアントワークでも遅延すればその分を自社持ち出しでやろうが他の案件ができなくなりますし、顧客もリリースが遅れた分だけ機会損失を生むのてま、結局機会損失に帰結。

発動条件は交渉の余地がない&自分が手を出したらギリギリ終わるタイミング(チームのケツを拭けるタイミング)だと考えています。

二度とその人とは仕事をしない、今後可能な限りその人とは仕事をしないようにする、そしてそれは今のプロジェクトの状況やこれまでの経緯を踏まえると客観的に妥当な判断だと言える、となったら発動しますね。そこまでの決意を持ったらけっこう平気で言います。

ただ、私は仕事は協調性でなく目的と結果ベースで動くべきと考えており、与えられたタスクができないなら別のタスクをやるかめちゃくちゃ努力するのが当然で、それができないやつに任せられる仕事なんてないと思っていますので、投稿者さんとは価値観が違うと思います。

コミュニケーションや協調性を大切にするタイプなら、一度本人とその上司と話し合って、どうするか会話するのがいいかもですね。

発動しちゃっていいと思います。

発動条件は持ってません。

あなたがAさんの上司や教育係でAさんの成長に責任を負う立場ならいざしらず、業務委託スタッフをそこまでケアして使い続ける意味も必要もないのでは。

人件費を捨てるかわりに、邪魔をさせない・あなたとプロジェクトメンバーの時間を奪わせないように、「何もさせない」ことがプロジェクトの成功に最も貢献する、とすらいえそう。

とはいえ「何もするな」とは言いづらいと思うので、プロジェクトのリリースに一切寄与しないがブロッカーにもならない類のタスクを作って与えるのが良いと思います。

おすすめは単体テストコードのリファクタリング（もし単体テストがないプロジェクトなら、単体テストの作成）です。Aさん専用ブランチを用意し、プロジェクト終了までそのブランチのみで作業。Pull requestは作らせないし、作っても決してマージしない。

モノになりそうならあとでマージすればいいですし、ブランチごと捨てるのも楽です。名目が必要なら「リリース後の開発の安定を見据えて」とかそんな感じで。