担当エンジニアが辞めたらプロジェクトは止まるか

「このシステム、作った担当者しか中身が分からないらしい」——開発会社の営業担当からそんな一言を聞いて、背筋がひやりとしたことはないでしょうか。契約は会社と結んでいるはずなのに、実際に手を動かしているのは特定の一人のエンジニアで、もしその人が辞めてしまったら、このプロジェクトはどうなるのか。考えたくないけれど、考えずにはいられない不安です。

この不安の正体は、実は「人が辞める」こと自体ではなく、「その人にしか分からない状態」が放置されていることにあります。つまり問題の所在は退職という出来事ではなく、そこに至るまでの情報の持ち方にあるわけです。この記事では、なぜ担当者の退職がプロジェクト停止につながってしまうのか、その構造と、発注側が事前にできる備えを整理します。

なぜ「一人が辞めただけ」でプロジェクトが止まるのか

本来、システム開発は会社対会社の契約であり、担当者が変わっても会社としての責任は継続するはずです。しかし実際には、設計の意図や仕様変更の経緯、ちょっとした実装上の判断といった情報が、ドキュメントではなく担当者個人の頭の中に残ってしまうことがあります。これが「属人化」と呼ばれる状態です。

属人化が進む理由は単純で、ドキュメント化には手間がかかる一方、担当者本人が稼働している間は特に困らないからです。スケジュールに追われる現場では、「動くものを作る」ことが優先され、「誰が見ても分かる状態にする」ことは後回しになりがちです。その結果、退職や異動が発生した瞬間に、引き継ぎのための調査から作業をやり直すような事態が起きてしまいます。属人化は退職が起きてから気づくのでは遅い構造になっている点が、この不安の核心です。

これは発注形態を問わず起こり得る話ですが、特にフリーランス個人への発注では、会社組織による引き継ぎの仕組みそのものが存在しないため、リスクがより直接的に表面化します。この点はフリーランス発注、退職リスクをどう見るかでも扱っていますが、SIerなど会社組織へ発注する場合であっても、担当者個人への依存度が高いプロジェクトでは同様の構造が起こり得るという点は、押さえておきたいところです。

「担当者任せ」が生まれる構造を分解する

属人化のリスクを考えるとき、「担当者の能力」の問題と「体制の設計」の問題を分けて考えると整理しやすくなります。

• 個人のスキル依存：特定の技術や経験を持つ一人に作業が集中している状態。本人が優秀であるほど、周囲が口を出しにくくなり、結果として依存が強まることもあります。
• ドキュメントの不在：設計書や仕様変更の記録が最新化されておらず、コードを読んでも「なぜそう作ったか」が分からない状態。
• 窓口の一本化：進捗報告や質疑応答の窓口が担当者一人に固定されており、会社としての複数人体制が見えていない状態。

この3つは独立した問題ではなく、互いに絡み合って属人化を強めていきます。発注側から見ると、契約書には「株式会社〇〇」と書いてあっても、実態は担当者個人とのやり取りだけで完結しているという状況が珍しくありません。ここは、次に体制を確認するときにそのまま使える視点なので、メモしておくといいところです。

発注側が事前にできる備え、何を確認しておくか

退職そのものを防ぐことはできませんが、退職が起きても止まらない状態を作っておくことは、発注の時点から可能です。

1. 体制図を確認する：契約前に、担当者が複数人体制になっているか、バックアップ要員がいるかを確認します。一人体制であること自体が悪いわけではありませんが、把握しておくことが重要です。
2. 成果物にドキュメントを含める：設計書や仕様変更の記録を納品物の一部として契約に明記しておくと、引き継ぎの土台になります。これは要件定義の段階でどこまで取り決めるかにも関わる話で、要件定義書、誰が書くべきかで揉める理由とも関連する論点です。
3. 進捗報告のルートを複線化する：報告が特定の個人経由でしか来ない状態を避け、会社の窓口やマネージャーを経由する報告ルートを一つ作っておきます。

情報処理推進機構（IPA）が毎年公表している「ソフトウェア開発データ白書」や「DX白書」といった調査でも、IT人材の不足や特定の技術者への依存が、現場の課題として繰り返し取り上げられています。属人化は発注側・受注側どちらか一方だけの問題ではなく、業界全体で起きやすい構造だと捉えておくと、過度に自社だけを責めずに対処を考えやすくなります。

万が一、担当者の離脱が実際に起きてしまった場合も、慌てて次の発注先を探す前に、まず現状のドキュメントとソースコードがどこまで整理されているかを確認する段階を挟むと、引き継ぎ先への説明がスムーズになります。この順番を飛ばしてしまうと、新しい担当者が結局ゼロから仕様を読み解くことになり、二重のコストが発生しやすくなる点は、覚えておきたいところです。

まとめ

• 担当エンジニアの退職がプロジェクト停止につながるのは、退職という出来事そのものよりも、情報が個人に属人化している状態が放置されているためです。
• 属人化は「個人のスキル依存」「ドキュメントの不在」「窓口の一本化」という要素が絡み合って生まれます。
• 発注前に体制図・ドキュメントの納品範囲・報告ルートを確認しておくことが、退職後も止まらない体制への備えになります。