PMが「仕事を任せにくいメンバー」を抱えたときの対処法｜プロジェクトを壊さず立て直すマネジメント実務

プロジェクトマネージャーやリーダーをしていると、期待した水準に届かないメンバー、指示を守れないメンバー、成果物の品質が安定しないメンバーがプロジェクトに入ることがあります。こうした状況では、本人を感情的に評価するよりも、何ができていないのかを行動と成果物の単位に分解し、プロジェクト側のリスクを先に制御することが重要です。

「能力が低いから外す」「厳しく言えば改善する」といった単純な対応では、かえって報告の遅延や隠蔽、チーム内の不信感を生むことがあります。一方で、本人の成長を待ち続けて納期や品質を犠牲にするのもPMとして適切ではありません。

実務では、役割の縮小、成果物の分割、レビュー頻度の引き上げ、完了条件の明文化、エスカレーション基準の設定を組み合わせながら、改善可能性とプロジェクト影響を同時に判断していきます。

「失格な人」ではなく、まず問題行動を具体化する

最初に避けたいのは、「使えない」「失格」「仕事ができない」といった人物評価だけで判断することです。この表現では問題点が曖昧なため、対策も曖昧になります。

例えば「設計書の品質が低い」ではなく、「レビュー1回あたり必須項目20個のうち5個以上が未記入」「同じ指摘が3回続いている」「期限当日まで進捗が報告されない」のように観察可能な事実へ変換します。

具体化できると、本人の能力不足なのか、要件理解不足なのか、指示の曖昧さなのか、経験不足なのか、単純な作業量過多なのかを切り分けやすくなります。PMに必要なのは人の格付けではなく、プロジェクト上の障害を特定することです。

最初にやるべきなのは仕事を小さくすること

成果が安定しないメンバーへ、いきなり大きな機能や重要工程を丸ごと任せると、問題が発見された時点ですでに手遅れになりやすくなります。そのため、まず担当範囲を小さく分割します。

例えば「ログイン機能を完成させる」という5日間のタスクではなく、「画面項目を確定する」「入力チェックを実装する」「単体テストを作る」のように半日から1日程度の成果物へ分けます。

この方法の目的は管理を細かくして本人を監視することではありません。問題が発生した場合の影響範囲を小さくし、早期に軌道修正できるようにすることです。プロジェクト管理では、失敗しないことよりも失敗を小さい段階で検知できる構造を作るほうが現実的です。

「分かりました」を完了条件にしない

経験の浅いメンバーや認識齟齬が多いメンバーを扱うときは、口頭で「分かりました」と返事をしたことを理解確認として扱わないほうが安全です。

例えば作業依頼時に、「何を作るか」「期限」「完成条件」「確認方法」を明文化します。そして本人に、これから行う作業と完成条件を自分の言葉で説明してもらいます。

具体的には、「明日15時までにCSV出力機能を実装してください。完了条件は、指定3パターンのテストが通り、レビュー用PRが作成されていることです」とします。単に「CSV機能をお願いします」と伝えるより、認識差を大きく減らせます。

レビューを最後にまとめて行わない

問題のある成果物が頻繁に出る場合、完成後にだけレビューする運用は危険です。3日かけて作ったものが根本から間違っていれば、3日分の手戻りが発生します。

そこで、最初の10％から30％程度の段階で一度確認します。設計書なら章立てとサンプル1ページ、プログラムなら方針やインターフェース、テストなら代表ケースだけ先に確認します。

例えば100件のテストケースを作成してもらう場合、最初の10件をレビューして形式と観点を合わせてから残り90件を作成してもらいます。最初の10件が間違っていれば修正コストは小さく済みます。

チェックリストで属人的な指導を減らす

同じミスを何度も指摘している場合、口頭注意だけでは改善しにくいことがあります。その場合は、作業前または提出前に本人が確認できるチェックリストを作ります。

例えば設計書なら「必須項目が埋まっている」「エラーケースが記載されている」「命名規則を守っている」「関連仕様へのリンクがある」といった項目です。コードレビューなら、ビルド、テスト、例外処理、ログ、命名などを項目化できます。

チェックリストは能力の低い人だけに使う仕組みではありません。航空、医療、開発、運用など、ミスの再発防止が重要な現場で広く使われる考え方です。個人の記憶力に頼らず、品質基準をチームの仕組みに移せます。

担当させる仕事のリスクを下げる

メンバーの能力が現時点で不足している場合、重要なクリティカルパス上の仕事から一時的に外すことも必要です。これは罰ではなく、プロジェクトリスクの管理です。

例えば本番データ移行、決済処理、セキュリティ設定、リリース判定など失敗時の影響が大きい作業では、十分なレビューなしに単独で担当させるべきではありません。一方、影響範囲が限定された改修、テスト、ドキュメント整理などから実績を積ませる方法があります。

重要なのは「簡単な仕事だけ永遠に与える」ことではなく、安定して完了できたら少しずつ難易度を上げることです。担当範囲を段階的に広げれば、改善の有無も判断しやすくなります。

報告ルールを変えるだけで改善するケースもある

実務上は、能力不足に見えて実は「相談が遅い」ことが最大の問題というケースもあります。分からない状態で2日間悩み、期限直前に「できませんでした」と報告されれば、PMから見ると致命的です。

そこで「30分調べても方針が見えなければ相談」「予定工数の50％を使った時点で進捗が半分未満なら報告」「期限に遅れる可能性を感じた時点で連絡」といった具体的なエスカレーション基準を決めます。

「困ったら相談してください」だけでは、人によって困ったと判断するタイミングが異なります。報告の基準を数値や条件にすると、問題を早く検知できます。

フィードバックは人格ではなく事実・影響・期待で伝える

改善を求める場面では、「やる気がない」「仕事が雑」「向いていない」といった人格評価を避けます。本人が反論しやすいうえ、何を直せばよいか分からないからです。

例えば「昨日提出された設計書で必須項目が6か所抜けていました。そのためレビューが予定より2時間延びています。次回から提出前チェックリストの全項目を確認してから提出してください」と伝えます。

この形なら、事実、プロジェクトへの影響、次回期待する行動が明確です。改善状況を後から比較することもできます。

教育で改善する問題と配置変更が必要な問題を分ける

すべての問題を教育だけで解決できるとは限りません。経験不足ならレビューやペア作業で改善する可能性がありますが、役割に必要な基礎能力と本人の現在地が大きく離れている場合は、配置そのものを見直す必要があります。

例えば上級設計者として参画しているのに基本的な設計経験がほとんどない場合、短期間の指導だけで契約上期待される役割まで引き上げるのは難しいことがあります。この場合は担当変更、ロール変更、増員、交代を検討します。

逆に、「説明を一度聞けばできる」「レビュー指摘が次回から減る」「相談が早くなる」といった改善が見えるなら、育成に投資する価値があります。改善可能性を感情ではなく実績から判断します。

改善期限を曖昧にしない

問題が長期間続く原因の一つが、「もう少し様子を見る」を繰り返すことです。改善支援をする場合でも、確認期間と評価指標を決めておく必要があります。

例えば「今後2週間、1日単位のタスクで進め、期限遵守率、レビュー指摘数、報告遅延を確認する」とします。2週間後に改善していれば担当範囲を広げ、変化がなければ配置変更を検討します。

こうすると本人にも期待値が伝わり、PM側も感覚だけで判断しなくて済みます。重要なのは罰として期限を設定することではなく、改善支援を無期限に続けないことです。

外部ベンダーやSESなら契約上の役割も確認する

外部企業やSES、業務委託のメンバーが期待水準を満たしていない場合は、個人への指導だけでなく契約・体制の問題として扱う必要があります。

例えば「上級SE」として契約しているにもかかわらず、実際には常時他メンバーの支援が必要なら、PMが内部で抱え込むより、ベンダー側の責任者へ事実を整理して相談します。交代、追加支援、役割変更などを協議します。

この際も「この人は使えない」と伝えるのではなく、「契約上求めている役割」「現在発生している具体的な不足」「プロジェクトへの影響」「必要な対応」を整理すると話が進みやすくなります。

できる人に全部尻拭いさせない

問題のあるメンバーを支えるために、優秀なメンバーへレビュー、修正、再実装を集中させると、今度は優秀層が疲弊します。短期的にはプロジェクトが回っているように見えても、長期的には大きなリスクです。

例えばAさんが作った成果物を毎回Bさんが全面修正しているなら、実質的にはBさんが二人分の仕事をしている状態です。この状態を「チームで助け合っている」と評価して放置してはいけません。

支援工数もプロジェクトコストとして計測し、「本人の成果を完成させるために周囲が何時間使っているか」を確認します。本人の作業時間だけ見ていると、実際の生産性を誤認します。

PM自身の指示や体制にも原因がないか確認する

成果が出ない原因をすべて本人へ帰属させるのも危険です。要件が頻繁に変わる、責任範囲が曖昧、複数の上司から異なる指示が出る、必要な権限や情報がないといった環境では、優秀な人でも成果が安定しません。

例えばPMはA仕様だと思っている一方、テックリードがB仕様を指示していれば、メンバーの成果物が間違うのは当然です。問題発生時には、本人だけでなく指示経路やレビュー体制も確認します。

「この人だけ同じ条件で成果が出ていない」のか、「複数人が同じ箇所でつまずいている」のかを見ると、個人問題か仕組みの問題かを切り分けやすくなります。

改善が難しい場合は交代もマネジメントの一部

支援、役割調整、レビュー強化を行っても改善せず、納期・品質・安全性への影響が大きい場合は、担当変更やプロジェクトからの交代を検討する必要があります。

PMの役割は、すべてのメンバーを必ず一人前に育てることではありません。育成も重要ですが、それ以上にプロジェクトの目的、品質、納期、チーム全体を守る責任があります。

特に重要工程で同じ重大ミスが繰り返される、虚偽報告や隠蔽がある、改善指示を継続的に無視するといった場合は、単純なスキル不足とは分けて扱うべきです。必要に応じて上長、人事、契約責任者など正式なルートへエスカレーションします。

実務で使いやすい対処の順番

仕事を任せにくいメンバーがいる場合は、次のような順序で対応すると整理しやすくなります。

1. 人物評価ではなく具体的な問題行動と成果物を記録する
2. タスクを半日～1日程度まで小さくする
3. 期限・成果物・完了条件を明文化する
4. 作業途中で早期レビューを入れる
5. チェックリストを用意して同じミスを減らす
6. 相談・エスカレーションの条件を明確にする
7. クリティカルな仕事から一時的に外す
8. 一定期間で改善状況を測定する
9. 改善がなければ担当変更・増員・交代を検討する

この順番で進めると、「厳しく叱るか、我慢するか」という二択になりません。プロジェクトリスクを抑えながら、本人に改善機会を与えることができます。

まとめ：人を手なずけるのではなく、仕事の仕組みを制御する

PMが能力や経験に不安のあるメンバーを抱えた場合、重要なのはその人を「手なずける」ことではありません。タスク、成果物、レビュー、報告、権限、役割を設計し直し、失敗の影響を小さくすることがマネジメントの中心になります。

具体的には、タスクを小さくする、完了条件を明文化する、早期レビューを入れる、チェックリストを使う、相談基準を決めるといった方法が有効です。同時に、本人へのフィードバックは人格ではなく事実と期待行動に基づいて行います。

それでも一定期間で改善が見られず、周囲の支援コストやプロジェクトへの影響が大きい場合は、担当変更や交代も選択肢です。育成とプロジェクト保護を両立させるためには、「何となく様子を見る」のではなく、改善基準と期限を明確にして判断することが重要です。