運用を引き継ぐ案件で、事前にもらえる資料に目を通しても、実際に触り始めると分からないことが次々に出てくることがあります。要件定義書や設計書は揃っていても、いま何がどう動いているかを示す一覧までは残っていないことがあります。この記事では、引き継ぎで受け取れるものと受け取れないものを整理し、判断の理由や意思決定を担う人がどこまで一緒に渡されるのかを見ていきます。最後に、条件を決めていく順番も具体的にまとめます。

1. 引き継ぎでまず受け取れる要件定義書と設計書

運用の引き継ぎが決まった直後は、何が届くのか見当がつかないまま案件を受けることになりがちです。実際に多く残っているのは、要件定義書と設計書です¹。書面という土台がある分、最初の数日は読み込む作業から始められます。

文書を確認する作業は、要件定義書と設計書を並べて読み合わせるところから始まります。画面の並びやデータの流れが文書どおりに動いているかを見ておくと、その後の面談で聞きたいことも具体的になります。

文書が残っていても動かせない部分

要件定義と設計はいまもドキュメントを中心に行われています¹。そのため、機能の目的や画面の構成、データの流れといった大枠は文書から追えることが多く、まったくの手探りで始めるよりは負担が軽くなります。

一方で、文書に書かれているのは設計した時点の姿です。稼働してからの変更や、運用しながら加えた調整までは反映されていないことがあります。文書を読み終えた段階では、まだ「いま」の状態を確認できていません。

「運用しながら直す」という前提

運用フェーズも含めて日々改善していくことを前提に、予算や体制、スケジュールを計画する必要があると示されています²。この前提に立つと、引き継ぎの時点で渡される文書は完成形の記録ではなく、その後も手を入れ続けることを見込んで作られたものだと分かります。

受け取った文書をそのまま最終形として扱うと、運用を始めてからの変更点との差分に気づきにくくなります。文書は出発点であって、到達点ではありません。

参画が決まってから最初の面談では、渡される文書がどの時点のものかを尋ねておくと、その後の確認作業の見通しを立てる材料になります。設計時点のまま止まっている文書なのか、運用しながら更新してきた文書なのかで、読み合わせにかける時間の配分や、稼働確認に回す日数の見立てが変わってきます。

図の作成：Remogu編集部。引き継ぎ時点で残っているものと残っていないものの傾向を整理したもので、統計データではありません

2. 受け取れない「いま何が動いているか」の一覧

文書の次に欲しくなるのが、いま実際に何が動いているかを示す一覧です。ところが、この一覧は最初から用意されていない場合があります。

構成管理の仕組みを持つ企業の割合

構成管理のツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています¹。導入していない企業では、構成の記録が仕組みとして残らない場合があります。

文書に書かれた構成と、いま実際に動いている構成が一致しているとは限りません。突き合わせを仕組みとして行える環境が整っている企業は、まだ一部にとどまっている状況です。

個人任せの技術情報の集め方

調査は、技術情報の収集が体系的な仕組みを持たず、個人に任されている企業があると示しています¹。この場合、担当していた人が把握していた情報は、その人の中にとどまり、一覧という形には残らない場合があります。

受ける側から見ると、引き継ぎの初日に一覧を求めても、渡せる一覧がそもそも存在しない場合があります。その場合は、稼働確認が最初の作業になります。

一覧が無い状態から始める場合は、稼働しているサーバーや連携先を、動かしながら一つずつ拾っていく進め方になります。最初の期間は新しい機能を作るより、いま何が動いているかを確かめる作業に時間を使うことになります。その前提は、契約の期間に織り込んでおきます。

受け取れるものと受け取れないものの比較

引き継ぎの時点で手元にあるものと、まだ無いものには差があります。文書は残っていても、構成の記録や技術情報の一覧は仕組みとして整っていないことが多く、受ける側が最初に埋めていく部分になります。

区分	引き継ぎ時の状況	根拠
要件定義書・設計書	文書として残っていることが多い	要件定義と設計はドキュメント中心1
構成管理の記録	仕組みとして残っていないことが多い	導入企業は利用側約3割・作る側約4割1
技術情報の一覧	個人の記憶に依存し一覧化されていない	収集は体系的な仕組みを持たない1

文書を先に読み、そのあとで一覧の有無を確かめる順番にすると、限られた時間の中でも確認の抜けを減らせます。

3. 設計の理由が文書に残っていない状況

文書を読み込んでも、なぜこの設計にしたのかという理由までは書かれていないことがあります。

理由が残っていない状態は、良し悪しの判断がつかないまま作業を進めることにつながります。まずどこに理由が欠けているかを洗い出す作業から始めると、優先して確認する箇所が絞れます。

個人任せの収集と、個人の中に残る理由

技術情報の収集を体系的な仕組みに乗せず、個人に任せている企業があります¹。同じ状況では、ある実装を選んだ判断の背景も、担当していた人の記憶に残るだけになる場合があります。

文書には「何を作ったか」は書かれていても、「なぜその方法を選んだか」までは残らないことがあります。理由が分からないまま手を加えると、後から見直したときに前の判断との整合が取れなくなる場面が出てきます。

設計の意識づけが広がっていない領域

モジュール性やデータモデルを意識した設計に取り組む企業は、特にユーザー企業を中心に依然として少ないと示されています¹。設計の単位を意識して作られていない部分は、変更の影響がどこまで及ぶかを追いにくくなります。

理由の記録が無いことと、設計の単位が意識されていないことは別の問題ですが、どちらも触ってみないと分からない状態を生む点は共通しています。引き継ぐ側は、この2つを分けて確認しておく必要があります。

面談の場では、なぜその設計にしたのかを聞くだけでなく、それを判断したときの制約条件まで尋ねておくと役立ちます。当時の事情が分かれば、いまの視点で不自然に見える設計であっても、背景を踏まえたうえで変更を検討できます。

判断の理由が残っているかの整理

理由の記録と設計の単位は、どちらも文書の外側にある情報なので、引き継ぎの初期段階で確かめておくと、後の手戻りを減らせます。

観点	引き継ぎ時の状況	根拠
技術情報・判断理由	体系だった記録がなく個人の記憶に依存	収集は体系的な仕組みを持たない1
モジュール性・データモデルの設計	意識した設計に取り組む企業はまだ少ない	取り組みは依然として少ない1

4. 一緒には引き継がれない意思決定を担う人

文書と理由の次に抜けやすいのが、決める人の存在です。

意思決定を担う責任者を置いていない企業の約半数

意思決定を担う責任者を設置していない企業は、約半数に上ります¹。最終的に判断する立場が明確でない体制のまま、運用が続いている企業があります。

受ける側からすると、変更の可否を誰に確認すればよいのかがはっきりしないまま作業を進める場面があり、確認のたびに問い合わせ先を探す手間がかかります。

面談の段階で、変更の可否を最終的に誰が判断するのかを、具体的な名前や役割まで確認しておくと、稼働が始まってから迷う場面を減らせます。窓口の人と決裁する人が別の場合は、両方の名前を押さえておきます。

外部サービスの扱いに残る不安

調査は、外部のサービスについても、メンテナンスや運用に不安を抱える企業があると示しています¹。外部の仕組みの維持や運用が、引き継ぎの確認範囲に加わる場合があります。

決める人がはっきりしないうえに、外部サービスへの不安も残っていると、引き継ぎの初期に確認する相手や範囲が広がります。誰に何を確認するかを、早い段階で書き出しておきます。

外部サービスに不安が残っている場合は、その不安の中身が契約や更新の手続きにあるのか、動作そのものにあるのかを分けて確認しておきます。分けて考えると、自分の経験のどの部分が生きる場面なのかを見極められます。

決める人がはっきりしない案件と、外部サービスへの不安が残っている案件が重なっているときほど、契約前の確認に時間をかけておく価値があります。

5. 受け取るより作り直す作業に近い引き継ぎ

引き継ぎで用意されているのは文書だけで、一覧・理由・決める人という3つは自分たちで作り直す部分になります。

運用を変えないままの刷新と効果

刷新をしても運用が従前のままでは、コスト削減の効果は十分に出ません²。仕組みを新しくすることと、運用の進め方を変えることは別の作業だという点が、ここに表れています。

引き継ぎも同じ構造です。文書を受け取っただけでは、これまでの運用の進め方までは変わりません。一覧や理由、決める人を自分たちの手で整えて初めて、運用の中身が変わり始めます。

文書を受け取った時点では、運用の進め方はまだ変わっていません。実際に変わり始めるのは、一覧や理由を自分たちの手で整えたあとになります。

改善を続けることが前提の計画

運用フェーズも含めて日々改善していくことを前提に、予算や体制、スケジュールを計画する必要があると示されています²。引き継ぎの時点で完成された状態を期待するより、その後も手を入れ続ける前提で条件を組み立てるほうが実情に合います。

受け取る作業だと考えると、渡されていない部分ばかりが目につきます。作り直す作業だと考えると、何を新しく用意するかが見えてきます。とらえ方を変えるだけで、次に手をつける順番も変わってきます。

作り直す作業だと考えたときに、まず手をつけるのは一覧です。稼働している範囲を書き出す作業は、最初の成果として示せます。

受け取る前提と作り直す前提の比較

同じ引き継ぎでも、受け取る作業だと考えるか、作り直す作業だと考えるかで、想定する作業量も進め方も変わります。

前提の置き方	想定する作業量	進め方
受け取る作業だと考える場合	文書の読み込みが中心になる	渡された内容をそのまま踏襲する
作り直す作業だと考える場合	一覧・理由・決める人の整備を含む	運用フェーズの改善を前提に組み立てる2

出典：2024年度ソフトウェア動向調査 簡易分析レポート（IPA、2025年4月）をもとに作成

図の作成：Remogu編集部。引き継ぎで自分たちが作り直すことになりやすい範囲を整理したもので、統計データではありません

6. 契約の場面にもかかる手間

引き継ぎの中身だけでなく、契約の結び方にも同じような前提が表れています。

契約の話は、稼働を始める前の段階で決着させておくほど、その後の進め方が安定します。稼働しながら契約を詰めていく進め方は、双方にとって負担が大きくなります。

取引のたびにかかる手間という課題

調査は、システム開発の契約で、取引ごとに手間や工数がかかる点を課題として挙げる企業があると示しています¹。引き継ぎのたびに契約の形式から確認し直す状況は、双方の負担になります。

受ける側にとっても、契約の手間は運用の手前で発生する見えにくいコストです。ここを見込まずに日程を組むと、実際の作業に入る前の段階で予定がずれ込みます。

契約の手間を見込むときは、初回の契約だけでなく、条件を見直すたびに同じ手間がかかる前提で日程を組んでおきます。更新のたびに一から確認し直す状況が続くなら、最初の契約で決める項目を厚めにしておく判断もできます。

モデル契約を知らない企業の存在

調査は、モデル契約そのものを「知らない」とする企業もあると示しています¹。契約の型が共有されていない場合は、個別に条件を詰めるやり取りになります。

型が共有されていない分、契約の内容は案件ごとに差が出ます。引き継ぎを受ける側としては、契約の段階で確認する項目をあらかじめ自分の中で持っておきます。

モデル契約を知らない企業を相手にする場合は、こちらから条件の叩き台を示す進め方も選べます。型が共有されていない分、先に具体的な案を出したほうが、話が早く進む場面もあります。

7. 引き継ぎの条件を決めていく順番

引き継ぎの条件は、思いつきで決めるのではなく、確認する順番を決めてから話を進めます。

最初に確かめる、一覧が仕組みとして残っているか

構成管理のツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています¹。まずこの割合のどちら側に当たる案件なのかを確かめると、以降にかかる時間を見積もれます。

仕組みとして一覧が残っていない場合は、稼働確認の期間を長めに見込んでおきます。逆に一覧が整っている場合は、判断の理由や決める人の確認に時間を割けます。

次に確認する、改善を前提にした体制

運用フェーズも含めて日々改善していくことを前提に、予算や体制、スケジュールを計画する必要があると示されています²。この前提に沿って、引き継ぎ後にどのくらいの頻度で変更が発生しそうかを、契約の条件に反映させておきます。

一覧の状況と改善の前提という2つを先に確認しておけば、契約の内容や報酬の協議も、根拠を持って進められます。

順番を決めておくと、面談で何を尋ねるかも整理できます。一覧の有無、判断の理由の残り方、決める人の所在という3つを、契約前の確認事項としてあらかじめリストにしておくと、当日の話が具体的に進みます。

図の作成：Remogu編集部。引き継ぎの条件を決めていく進め方の順番を整理したもので、統計データではありません

引き継ぎの条件を決める場面では、資料の量よりも、一覧・理由・決める人の3つがどこまで揃っているかを先に確認しておくと、契約の内容も報酬の協議も根拠を持って進められます。案件の90%以上がフルリモート可能です。自分の経験が生きる引き継ぎ案件がどこにあるか、まず登録して条件を確かめてみる進め方もあります。

8. よくある質問

決める人がはっきりしない場合はどうすればよいですか

意思決定を担う責任者を置いていない企業は約半数に上ります¹。変更の可否を最終的に誰が判断するのかを、契約の初期段階で名前や役割まで確認しておきます。

契約の手間が大きい案件はどう考えればよいですか

取引ごとに手間や工数がかかる点を課題として挙げる企業が、調査で示されています¹。この手間を見込んで、日程に余裕を持たせておきます。

モデル契約を知らない相手とは、どう条件を詰めればよいですか

モデル契約そのものを「知らない」とする企業もあります¹。契約の型が共有されていない場合は、こちらから条件の叩き台を示す進め方もあります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年10月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」計画の作り方（2026年・2026年10月確認）