リプレイス案件に入る前に、先に確認したい「前任者が抜けた理由」
「前の人が抜けました」だけで、なんとなく嫌な予感がする
「それ、どうして前任者が抜けたんだろう…」
リプレイス案件の話を聞いた時、こんな引っかかりが残ることありませんか？ 条件は悪くない。単価もそこそこ。急募と言われているぶん、参画までの話も早い。でも、前任者が抜けた理由や引き継ぎ状況がぼんやりしていると、なぜか少し身構えてしまう。
この違和感は、大事にした方がいいです。前任者が抜けたこと自体が悪いわけではありません。家庭の事情、別案件への移動、契約期間の満了など、健全な理由はいくらでもあります。
ただ、現場で怖いのは、離脱理由が本人の事情に見えて、実は案件の構造に原因があるケースです。仕様が決まらない。判断者が遠い。受け入れ体制がない。役割が契約上の範囲より広い。こういう状態のまま新しい人を入れても、同じことがもう一度起きます。
IPA の「情報システム・モデル取引・契約書（第二版）」も、取引構造の透明化や、ユーザ企業とITベンダが各段階で担う責務を整理するための資料です。第二版の見直しポイントには、プロジェクトマネジメント義務、協力義務、再構築対応も含まれます。つまり、うまく進まない開発は、誰か一人の能力だけでなく、役割、責務、協力の置き方から見る必要があります。
この記事では、リプレイス案件を「前任者が良くなかった案件」ではなく、前任者が抜けるほどの構造が残っていないかを見る案件 として整理します。聞きづらいことを詰問する話ではなく、同じ火種を抱えないための確認です。
抜けた理由には、案件の構造がかなり出る
リプレイス案件で最初に見たいのは、前任者の評価ではありません。前任者が抜けるまでに何が積み上がっていたかです。ここを間違えると、「技術的に合わなかったんですね」「忙しかったんですね」で終わってしまいます。
でも、現場の離脱理由は、だいたい一言では閉じません。技術的に難しかった背景には、仕様や判断材料の不足があるかもしれません。忙しかった背景には、調整や問い合わせ対応まで流れ込んでいた可能性があります。相性が悪かった背景には、最終判断者と現場の距離が遠かったことがあるかもしれません。
「技術的に難しかった」で終わらせない
「前任者は技術的に合わなかったようです」と聞くと、つい自分なら大丈夫かを考えたくなります。経験年数、使える技術、得意領域。もちろん確認は必要です。でも、そこで止まると危ないです。
技術的に難しかった案件ほど、本当に足りなかったのは技術力ではなく、情報の透明性だった可能性があります。既存仕様がまとまっていない。判断履歴がチャットの奥に埋まっている。なぜこの設計になったのかを誰も説明できない。こういう状態だと、どれだけ実装力がある人でも手探りになります。
Scrum Guide でも、透明性の低い成果物は価値を下げたりリスクを増やしたりする判断につながると説明されています。スクラムを使っているかどうかに関係なく、リプレイス案件ではここが効いてきます。引き継ぎ資料、決定履歴、受け入れ基準が見えないまま「技術的にお願いします」と言われたら、それは技術課題というより、透明性の課題です。
「忙しかった」には、役割の膨張が隠れやすい
もう一つ多いのが、「前任者が忙しくなって抜けた」という説明です。これも一見すると、本人側の都合に見えます。でも、忙しくなった理由を分けて聞かないと、同じ負荷が次の人に流れてきます。
たとえば、実装者として入ったはずなのに、気づけば仕様整理、問い合わせ対応、障害調査、会議の論点整理まで持っていた。こうなると、稼働が増えるのは自然です。しかも、この手の負荷は「ちょっと相談していいですか」「ついでに見てもらえますか」という形で積み上がるので、契約上の範囲としては見えにくいんですよね。
ここを確認しないまま入ると、最初は歓迎されます。「助かります」「頼りにしています」と言われる。でも数週間後には、前任者と同じように、実装以外のものがどんどん自分のところに寄ってくる。忙しかった理由が残っているなら、担当者が変わっても忙しさは消えません。
「相性が悪かった」には、判断者の遠さが隠れる
「前任者と現場の相性があまり良くなかった」という説明も注意したいところです。本当に相性の問題だった可能性はあります。ただ、その言葉で判断構造の問題がぼかされていることもあります。
たとえば、目の前の担当者は話しやすいけれど、最終判断者は別にいる。現場で合意したはずの仕様が戻る。優先順位が変わるのに、誰が決めたのか分からない。こういう状態だと、前任者がどれだけ丁寧に話しても摩擦は起きます。
IPA の「DX動向2025」では、日本企業のDXには部門間連携や外部組織との連携、ステークホルダーへの共有が弱く、サイロ化が進んでいるという特徴が指摘されています。リプレイス案件でも同じです。担当者との相性だけを見るのではなく、誰が判断し、どこで情報が止まり、どこで変更が決まるのかを見る必要があります。
入る前に聞くのは、責める質問ではない
前任者の離脱理由を聞く、というと少し気まずく感じます。相手を疑っているように見えないか。前の人を悪く言わせる質問にならないか。面倒な人だと思われないか。
その不安は自然です。だから、聞き方を「前任者はなぜ辞めたんですか？」だけにしない方がいいです。目的は人の評価ではなく、次に同じ詰まりを起こさないための引き継ぎ条件と運用変更の確認です。
前任者の担当範囲を、まず事実で聞く
最初に聞きたいのは、離脱理由そのものより、前任者が何を担当していたかです。「前任の方は、実装以外にどこまで見ていましたか？」「問い合わせ対応や仕様整理も含まれていましたか？」「引き継ぎ後も残る役割はありますか？」くらいの聞き方なら、人格評価になりにくいです。
ここで相手が具体的に答えられるなら、少なくとも現場は負荷の中身を把握しています。逆に、「まあ、いろいろ見てもらっていました」「臨機応変にお願いしていました」だけなら注意が必要です。役割が曖昧なまま便利に使われていた可能性があります。
この確認は、自分の身を守るだけではありません。発注側にとっても、次の人に何を期待するかを整理する機会になります。
引き継ぎ資料と決定履歴を確認する
次に見たいのは、引き継ぎの材料です。ソースコードがあるかどうかだけでは足りません。README、設計メモ、運用手順、未決事項、判断履歴。こうした材料がどこまで残っているかで、参画後の負荷はかなり変わります。
Google Cloud の DORA 2025 レポートは、AIの効果はツール単体ではなく、組織の既存の強みや弱みを増幅すると整理しています。これはAIの話ですが、リプレイス案件にも似ています。新しい人を入れても、情報が散らばった組織では散らばりが増幅されます。逆に、資料や判断履歴がある現場では、新しい人の立ち上がりも速くなります。
だから、「引き継ぎ資料はありますか？」だけで終わらせず、「どの資料を見れば、過去の判断理由まで追えますか？」と聞きたいです。ここで答えがあるかどうかは、かなり大きなサインになります。
同じことを繰り返さないために、何を変えたか
最後に聞きたいのは、前任者が抜けたあとに何を変えたかです。ここが一番大事です。前任者が抜けた理由が何であれ、現場が何も変えていないなら、次の人も同じ状況に置かれます。
たとえば、判断者を明確にした。仕様変更の窓口を一本化した。問い合わせ対応の範囲を切った。未決事項を棚卸しするようにした。こうした変更がセットで出てくるなら、リプレイスは前向きな立て直しになり得ます。
反対に、「次はうまくやれる人を探しています」だけなら、かなり危ないです。便利な言葉ですが、構造を変えずに個人の能力へ期待しているだけかもしれません。人を変えるだけでなく、進め方を変えたか。 ここを見ると、入るべき案件かどうかが見えやすくなります。
危ない返答と、入ってもよい返答を分ける
リプレイス案件は、全部避けるべきではありません。整理できれば入りやすい案件もあります。課題が見えていて、次の人への期待が明確で、現場が変える意思を持っているなら、チャンスになることもあります。
大事なのは、返答の温度ではなく中身です。担当者が感じよく話すかより、離脱理由、引き継ぎ、運用変更がセットで説明されるか。ここで見ると、見極めがラクになります。
危ないのは、理由が人格で閉じる返答
危ない返答は、前任者の人格や能力だけで話が終わるものです。「スキルが足りなかった」「コミュニケーションが合わなかった」「主体性がなかった」。こういう説明自体が必ず悪いわけではありません。でも、その後に構造の説明が続かないなら注意です。
本当にスキル不足だったとしても、どの技術要素が足りなかったのか、期待値はどう伝えていたのか、相談導線はあったのかを確認したいです。コミュニケーションの問題だったとしても、誰と何をどの頻度で合わせる必要があったのかを確認したい。ここが曖昧なままだと、次の人も同じ評価を受ける可能性があります。
人格で閉じる説明は、聞いている側も楽です。「自分はちゃんとやれば大丈夫」と思いやすいからです。でも、案件選びではそこが危ない。前任者を下げて安心するのではなく、前任者が詰まった条件が残っていないかを見た方がいいです。
入ってもよいのは、問題と変更がセットで出る返答
逆に、入ってもよい可能性がある返答は、問題と変更がセットで出てくるものです。「前任者に仕様整理まで寄ってしまっていたので、今回は窓口をPMに戻します」「判断者が曖昧だったので、優先順位はこの人が決める形にしました」「引き継ぎ資料が薄かったので、まず2週間は調査と整理を契約範囲に入れています」。
こういう返答があると、少なくとも現場は何が起きていたかを構造で見ています。完璧でなくても大丈夫です。むしろ、完璧な現場ならリプレイスで急募にはなっていないかもしれません。大事なのは、火種を認識し、次の進め方に反映しているかです。
ここまで聞けると、こちらも条件を出しやすくなります。「最初の2週間は仕様把握とリスク整理に使いたいです」「問い合わせ対応は窓口を通してください」「未決事項は週次で棚卸ししましょう」。こういう話ができる案件なら、リプレイスでもかなり入りやすくなります。
条件に落としてから判断する
最後は、違和感を条件に落とします。なんとなく危ない、で終わらせると判断が揺れます。逆に、何が揃えば入れるかを先に決めておくと、相手の返答を冷静に見られます。
たとえば、入る条件を3つに絞るなら、前任者の担当範囲が説明されていること、引き継ぎ資料と決定履歴の所在が分かること、前任者が抜けた後に運用変更があること。この3つです。全部が完璧でなくても、どこが弱いか分かれば契約条件や初期タスクで補えます。
逆に、この3つがすべて曖昧なままなら、単価が良くても慎重に見た方がいいです。高い単価は魅力ですが、火消し、調整、説明責任、再整理が全部乗っているなら、実質的にはかなり重い案件かもしれません。
最後に
リプレイス案件で確認したいのは、前任者が良かったか悪かったかではありません。前任者が抜けるまでに、どんな構造が積み上がっていたかです。
技術的に難しかったのか、情報が見えなかったのか。忙しかったのか、役割が膨らんでいたのか。相性が悪かったのか、判断者や窓口が曖昧だったのか。ここを分けて見るだけで、案件の見え方はかなり変わります。
聞きづらいことを全部聞く必要はありません。まずは、前任者の担当範囲、引き継ぎ資料と決定履歴、同じ状態を繰り返さないための変更。この3つだけで大丈夫です。質問の目的は相手を責めることではなく、自分が同じ火種を抱えないための前提確認です。
リプレイス案件は、怖い案件にも、立て直しのチャンスにもなります。違いは、前任者の話を人の問題で閉じるか、構造のサインとして読めるかです。次に似た案件を見たら、条件の良さだけで急がず、抜けた理由を少し落ち着いて分解してみてください。そこから判断すれば、入る前の不安はだいぶ具体的になります✨
