3ヶ月の案件が終わった。引き継ぎ資料は1枚もなかった——。
SES現場でこの状況に出くわしたエンジニアは、おそらく1人や2人ではない。Heydayでも年間100件以上のキャリア相談を受ける中で、「前任者が突然抜けて、誰も仕様を知らなかった」「自分が抜けるとき、何を残せばいいか分からなかった」という声は何度も聞いてきた。
そしてこの問題には、ほぼ必ずこういう自己批判がついてくる。
「自分がもっとちゃんとドキュメントを書いていれば」
「前任者がだらしなかった」
「現場の文化が悪かった」
しかし、SES現場で引き継ぎ資料が残らないのは、個人の怠慢でも文化の悪さでもない。準委任契約・客先NDA・知的財産権という3つの構造的な壁が重なった結果として、ほぼ必然的にそうなるよう設計されている。
この記事では、なぜSES現場に引き継ぎ資料がないのかを構造から解き明かしたうえで、その制約の中でもエンジニアが自分を守るために「作れる記録」と「作れない記録」の境界線、そして次の現場・次のキャリアに持ち出せる形での記録術を、テンプレート付きで解説する。
なぜSES現場には引き継ぎ資料が残らないのか
引き継ぎ資料がないのは、突き詰めると「誰も書く責任を負っていない」からだ。そしてその「誰も責任を負わない」状態が、SESの契約構造から自然に生まれている。原因は4つある。
原因1：準委任契約には「成果物」がない
SES契約の大半は、民法656条にもとづく準委任契約だ。これは「業務の遂行そのもの」が契約の目的であり、設計書・コード・手順書といった成果物の納品義務は契約上発生しない（請負契約とはここが決定的に違う）。
行政書士・弁護士の解説でも「準委任契約（履行割合型）にはソフトウェアコード・設計書・テスト仕様書・手順書を成果物として納品する義務がない」点が明記されている。つまり、エンジニアが現場で書いたドキュメントは、「契約上の納品物」ではなく「業務の副産物」という扱いになる。
副産物である以上、それを誰が書くか・どの粒度で書くか・どこに残すかは、現場の運用と個人の善意に委ねられる。書かなくても契約違反にならないのだから、忙しい現場で後回しになるのは当然だ。
SES契約の法的な全体像については SES法律・契約完全ガイド で詳しく解説している。
原因2：客先NDAと知的財産権の壁
仮にエンジニアが丁寧な引き継ぎ資料を書いたとしても、その資料の所有権は誰にあるのか——という問題が次に出てくる。
業務上で作成した設計書・仕様書・運用手順書は、原則として業務委託元（多くの場合エンドクライアント）の知的財産として扱われる。SES契約書には通常「業務上知り得た情報の守秘義務」と「業務上作成した成果物の権利帰属」が明記されており、エンジニアが個人で持ち出すことはできない。
具体的にいうと、こういう資料は持ち出せない。
- 顧客固有の業務フロー図
- システム構成図（IPアドレス・サーバ名を含むもの）
- データベースのテーブル定義書
- 運用手順書（社内システム名や顧客名が入っているもの）
これらは「現場に置いてくる」しかない。そして、現場には次に入る人のための引き継ぎフォルダはあっても、3次請け・4次請けの末端の現場になるほど、その引き継ぎフォルダ自体が機能していないことが多い。
原因3：多重下請け構造で引き継ぎ先が不明確
SES業界では、エンドクライアント→元請け→2次請け→3次請けと商流が深くなるほど、各レイヤーの会社が別々のエンジニアを送り込む構造になる。詳しくは SES商流とは｜エンド直・元請け・多重下請けの違い で解説しているが、この多重構造が引き継ぎを破綻させる。
例えば、3次請けの会社からあなたが送り込まれた現場で、契約終了後に同じ3次請けの会社が後任を送れるとは限らない。プロジェクトの状況や人材のアサイン状況によっては、別の会社（別の3次請け、または2次請けが直接抱える別案件）の人間が後任になることがある。
このとき、
- あなたが書いた引き継ぎ資料は、所属会社経由で渡せない（あなたの会社と後任の会社は別法人）
- 客先のフォルダに置いていくしかない
- 客先のPMが「引き継ぎ会の場をセットアップする責任」を負っているとは限らない
という構造になり、誰も責任を持たないまま「とりあえず資料はあったらしいけどどこか分からない」という状態が量産される。
原因4：ドキュメントを書いても評価されない
最後の原因が、おそらく一番根が深い。
SESエンジニアの評価軸は、所属会社の評価制度（自社で年1〜2回ある）と、客先での評価（契約更新の判断材料）の2つだ。
このどちらの評価軸にも、「丁寧な引き継ぎ資料を残したか」は通常含まれていない。所属会社は現場の中身を詳しく見ていないし、客先は契約期間内のパフォーマンスを評価する。退場後の引き継ぎ資料の質は、双方にとって直接の評価対象ではない。
評価されない仕事は、忙しさの中で必ず後回しになる。これは個人の怠慢ではなく、評価設計の構造的な問題だ。
引き継ぎ資料が「作れる部分」と「作れない部分」
ここまでが「なぜないのか」の話。ここからは「ではどうすればいいか」の話に移る。
最初に押さえたいのは、引き継ぎ資料には作っていい部分と作ってはいけない部分の境界線があるという事実だ。これを混同すると、契約違反のリスクが出てくるか、逆に何も書けなくなって思考停止する。
持ち出せない（NG）：客先の知的財産にあたるもの
- システム仕様書（顧客固有）
- 業務フロー図（社内ルールが具体的に書かれているもの）
- 顧客データ・テストデータの実物
- データベースのテーブル定義・カラム名
- 顧客名・案件名が特定できる構成図
これらは現場のフォルダに残すべきもので、個人のPCや個人のクラウドストレージに保存してはいけない。退場時にローカルから削除する義務もある（契約書の守秘条項を読み返してほしい）。
持ち出せる（OK）：あなた自身の判断・学び・経験
- あなたが下したアーキテクチャ判断の理由（顧客名や具体的構成を伏せた抽象化レベルで）
- 学んだ技術スタック・ツール・フレームワークの名前と使用期間
- 設計判断の意思決定プロセス（一般化した形で）
- 詰まった問題と解決アプローチ（顧客固有情報を伏せて）
- ロール・チーム規模・期間・上流/下流工程の関与度
つまり、「何の業務を、どの規模で、どんな技術で、どんな判断で進めたか」という抽象化された経験ログは、あなた個人の知的資産として持ち出してよい。これはスキルシート・職務経歴書に記載できる範囲そのものだ。
境界線の判断基準
迷ったときの判断基準はシンプルだ。
その情報を会社の朝礼や勉強会で話せるか？
話せるなら持ち出してよい。話せないなら現場に残す。これが守秘義務違反かどうかの実務的な線引きになる。
エンジニアが実践できる記録術（テンプレート付き）
「持ち出せる範囲」が分かったら、次は「どう記録するか」だ。退場前夜にあわてて書くのではなく、案件中から少しずつ蓄積する習慣にしないと続かない。
習慣1：週次の30分メモ（金曜の業務終了直前）
毎週金曜の業務終了10〜15分前に、個人のクラウドメモ（NotionでもObsidianでもメモアプリでも何でもよい）に以下を書き留める。
【YYYY-MM-DD 週次メモ】
■ 今週やった主な業務
- （例）認証基盤のリファクタリング設計レビュー
- （例）バッチ処理のパフォーマンス改善（処理時間40%削減）
■ 使った技術・ツール
- 言語: Java 17
- フレームワーク: Spring Boot 3.x
- インフラ: AWS（EC2 / RDS / S3）
- ツール: GitHub Actions / Datadog
■ 学んだこと・詰まったこと
- （例）非同期処理のデッドロックを再現する手順を確立
- （例）チームのレビュー文化に学んだ：PRに必ず「設計判断」を書く
■ 来週の予定
- （例）データ移行のリハーサル参加
ポイントは、顧客名・案件名・サーバ名を一切書かないこと。書くのは「自分が何をしたか」「どんな技術を使ったか」「何を学んだか」だけだ。
習慣2：スキルシート変換用の業務実績メモ
週次メモが3〜4本貯まった月末に、それを「スキルシートに転記できる粒度」に変換する。これが業務実績メモだ。
【業務実績：YYYY/MM〜YYYY/MM】
■ 業界・規模
- 業界: 金融（保険）
- システム規模: 月間トランザクション◯◯万件
- チーム規模: バックエンド5名 / 全体15名
■ ロール
- バックエンドエンジニア（中堅ポジション）
- 担当範囲: API設計 / 実装 / レビュー / 運用支援
■ 技術スタック
- 言語: Java 17, TypeScript
- FW: Spring Boot 3.x
- DB: Aurora MySQL
- インフラ: AWS（ECS Fargate / RDS / S3）
- CI/CD: GitHub Actions
■ 主な実績
1. （定量）バッチ処理時間を40%削減（◯時間→◯時間）
2. （定性）レビュー基準のドキュメント化を主導
3. （定量）月次インシデント数を◯件→◯件へ低減
■ 工夫・学び
- 設計判断の言語化：PR時に「なぜこの構造にしたか」を必ず書く文化を提案
- 障害対応：再現手順を残すことで再発を防ぐ仕組みを作った
■ 関与した工程
- 要件定義: △（一部参加）
- 基本設計: ◯
- 詳細設計: ◯
- 実装: ◎
- テスト: ◯
- 運用: ◯
これはスキルシートの下書きそのものだ。次の案件選びや転職時に、ここから具体的なエピソードを抽出できる。詳しい書き方は SES案件の選び方 と合わせて読むと、案件選定との結びつきが見えてくる。
習慣3：契約終了の3週間前から「持ち出し可能な引き継ぎメモ」を準備
退場時に客先に残す引き継ぎ資料は、客先の知財として現場のフォルダに置く。それとは別に、自分のための引き継ぎメモを作る。これは将来の自分（次の現場で似た技術を使うとき）への手紙のつもりで書く。
【自分用引き継ぎメモ】
■ 案件概要（一般化）
- 業界: 金融
- システム種別: 顧客向けWebアプリ
- 期間: ◯ヶ月
■ 採用したアーキテクチャ判断と理由
- 例：マイクロサービスではなくモジュラーモノリスを選んだ理由
- 例：非同期処理にSQSではなくEventBridgeを選んだ理由
■ 詰まったポイントと解決アプローチ
- 例：バッチ処理の重複実行問題 → 冪等性の担保で解決
- 例：レビュー文化の停滞 → PRテンプレートで解決
■ もう一度同じ案件をやるなら最初に整備する3つのこと
1. ...
2. ...
3. ...
このメモはあなただけの資産で、誰にも渡さなくていい。3年後、似た現場に入ったときに見返すと、過去の自分が確実に助けてくれる。
引き継ぎを依頼されたとき（後任エンジニアの立場）
ここまでは「自分が抜けるとき」の話だった。逆に「自分が引き継がれる側」になったとき、前任者から渡された資料が薄かったり、口頭引き継ぎだけだったりするケースもよくある。その場合の対処を整理する。
最低限確保すべき情報リスト
口頭引き継ぎでも、最低限以下は必ず聞いて自分でメモする。
- システムの全体像：何のためのシステムか、誰が使うか、主要な機能は何か
- 主要コンポーネント名と役割：APIサーバ・バッチ・管理画面など、それぞれ何をするか
- デプロイの仕組み：本番リリースの手順と承認フロー
- 障害時の連絡網：誰に連絡するか・優先順位は何か
- 直近で起きたインシデントと対応：ここに業務知識が詰まっている
特に「直近のインシデント履歴」は、システムのクセが一番現れる場所だ。ここを聞き出せれば、ドキュメントが薄くても3割くらいは埋められる。
口頭引き継ぎの記録方法
口頭引き継ぎを録音するのは契約上難しいケースが多いので、手書きのノート＋すぐにテキスト化する習慣で対応する。
- 引き継ぎミーティング中はとにかくキーワードだけ書く
- 終わったら30分以内に自分のメモアプリで構造化する
- 不明点は翌日までに前任者に質問する（前任者が現場にいる期間は限られている）
- 1週間後、自分の言葉で「現状理解メモ」を書いて前任者に確認してもらう
この最後のステップが特に大事で、自分の言葉で書いてみると理解の穴が露呈する。前任者がまだ現場にいる間に「これで合ってますか」とすり合わせできる時間は、ほぼ最初の2週間しかない。
引き継ぎ後の現場での立ち回り方は 客先常駐でのコミュニケーション術 で詳しく解説している。
よくある疑問
Q1：引き継ぎ資料を作らずに案件を抜けてもよいか？
法的には、準委任契約に成果物としての引き継ぎ資料の納品義務はない。ただし、契約書に「契約終了時の業務引き継ぎ義務」が明記されている場合は別で、その場合は契約上の義務が発生する。契約書を読み返してほしい。
実務上は、引き継ぎを雑にすると次の評価・次の案件紹介・業界での評判に影響する。法的義務がなくても、自分のキャリアのためにできる範囲でやるのが合理的だ。
ただし、ハラスメントや契約違反などで関係が破綻した現場の場合、引き継ぎを完璧にやる義務感に縛られる必要はない。契約条項に従う最低限で十分だ。詳しくは SES案件を断る方法 を参照。
Q2：前任者の引き継ぎがなくて困ったらどうするか？
3つのアクションがある。
-
客先のPMに状況を報告する：「前任者から引き継ぎを十分受けられていません。立ち上がりに通常より時間がかかります」と早めに共有する。これを後出しにすると、立ち上がりの遅さが評価ダウンにつながる。
-
自社の営業に状況を報告する：自社経由で客先に状況を伝えてもらう。これが偽装請負の話につながる場合もあるので、自社の判断を仰ぐ。
-
コードを読んで仕様を逆算する：最終手段。テストコード・ログ・直近のPR・障害対応履歴から、システムの実態を推測する。地道だが、これができるエンジニアは現場で重宝される。
Q3：自分が抜けたあと、客先に「資料がない」と苦情が来たら？
契約終了後に届いた苦情に、エンジニア個人が対応する義務はない。所属会社経由で対応すべき問題だ。
ただし、契約書に契約終了後の質問対応義務（例：終了後30日以内の質問にはメールで回答する）が明記されている場合は別。契約書の最後の方に書かれていることが多いので、退場前に必ず確認しておく。
まとめ：引き継ぎは「持ち出せる資産」に変換する仕事
SES現場で引き継ぎ資料がないのは、エンジニアの怠慢ではない。準委任契約・客先NDA・知的財産権・評価設計の4つの構造が重なって、誰も書く責任を負わない状態が生まれている。
しかしその制約の中でも、エンジニアが自分のキャリア資産として持ち出せる記録は必ず作れる。週次メモ・業務実績メモ・自分用引き継ぎメモの3つを習慣にすれば、3ヶ月後・6ヶ月後・3年後の自分を必ず助ける。
引き継ぎ資料を「客先のために書く義務」と捉えると後回しになる。「次の現場の自分のために書く資産」と捉え直すと、続けられる。
そしてその習慣が、SESエンジニアとしての市場価値の差になる。同じ現場で同じ技術を使っていても、記録を残せているエンジニアと残せていないエンジニアでは、3年後のスキルシートの厚みが大きく違う。
「自分の現場でこの記録術が回せるか不安」「次の案件選びでドキュメント文化のある現場を選びたい」という方は、Heydayのキャリア相談で具体的な状況をヒアリングしながら方針を一緒に整理することもできる。
関連記事：
