Spring案件の新着情報を見ていると、ゼロから設計する新規開発よりも、すでに動いている仕組みに手を入れる仕事のほうが目につきます。持ち込まれる資料は仕様書と過去の変更履歴が中心で、触れてよい範囲がどこまで及ぶかは案件ごとに幅があります。この記事では、IPAの調査データをもとに、保守が中心になる現場で何を確かめ、担う範囲をどこで線引きするかを整理します。

1. 新規開発より保守と修正の仕事が中心になります

レガシーを抱える企業がいまも半数程度います

動いているシステムに関わる仕事では、ゼロから作る場面よりも、すでにある仕組みを保ちながら直す場面に出会う機会が増えています。IPAの調査でも、ユーザー企業の半数程度が、いまもレガシーシステムを抱えています¹。

レガシーという言葉は、古さそのものを指すわけではありません。長く動き続けてきた分だけ、どこを直すと何に響くかが読みにくくなった状態を指します。保守の案件を受けるときは、まずこの前提を踏まえて仕事の進め方を組み立てます。

たとえば同じ画面を直す作業でも、書かれてから日が浅いコードなら一から追いやすい一方、長く手が入ってきた画面は過去の修正が幾重にも積み重なっています。読み解く時間を見積もりの中に含めておくと、着手後に慌てずに済みます。

保守を専門にする案件では、修正1件あたりの規模は新規開発より小さくても、確認にかかる手間が仕上がりの速さを左右します。手間の配分を早めに把握しておくと、進行の見通しが立てやすくなります。

開発の型はいまもウォーターフォールが主流です

開発の進め方についても、依然としてウォーターフォール型の手法が主流です²。段階を踏んで進める型は、途中の仕様変更に弱いというより、決まった手順の中で確認する場面が多いという特徴として理解しておくと扱いやすくなります。

短い周期で見直しながら進める開発に慣れていると、この段取りの重さに戸惑うこともあります。ただ、手順が決まっているということは、どこで何を確認すればよいかがあらかじめ見えているとも言えます。段取りを知ることから始めると、進め方の見通しが立ちやすくなります。

見積もりや進捗の報告も、決められた区切りごとに求められる場面が増えます。短い周期で区切って進める開発に慣れている場合は、報告のタイミングと粒度を早い段階ですり合わせておくと、後の齟齬を防げます。

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

2. 仕様はドキュメントから読み解く仕事になります

要件定義と設計はいまもドキュメントが軸です

要件定義と設計は、いまもドキュメントを中心に進められています³。案件に入ってまず手にするのは、動いている画面や機能そのものではなく、それを説明する紙とファイルです。読み解く力が、実装の速さと同じくらい仕事の質を左右します。

ドキュメントを読むことよりも、ドキュメントと実際の挙動を照らし合わせることのほうが、保守の仕事では手がかりになります。書かれた仕様と、いま動いている挙動がずれている場面は珍しくないため、両方を確かめる姿勢が必要です。

ドキュメントが古い場合でも、更新履歴の欄や設計書の余白に残ったメモが、次の手がかりになることがあります。目についた記述を読み飛ばさずに拾っておく姿勢が、後の確認の手間を減らします。

情報源によって読み取れることが違います

情報源が複数に分かれている案件ほど、最初にどこから見ればよいかを整理しておくことが、後の手戻りを防ぐ近道になります。

仕様を確かめる手段は一つではありません。要件定義書や設計書、変更履歴やチケット、実際に動いているコードの挙動、そして担当者への確認では、それぞれ読み取れることと注意点が違います。下の表に、確認の手段ごとの違いを整理しました。

確認の手段	読み取れること	注意点
要件定義書・設計書	当初の仕様と全体の構成	更新されていない場合があります
変更履歴・チケット	その後に加わった修正の経緯	記録の粒度は案件によって差があります
動いている挙動の確認	いま実際にどう動いているか	ドキュメントと一致しない場合があります
担当者への確認	記録に残っていない前提	窓口が誰かを早めに確かめておきます

一つの手段だけに頼ると、抜け落ちる情報が出てきます。ドキュメントで全体を把握し、履歴で経緯を追い、挙動で答え合わせをする。この順番を踏むことで、仕様の解像度が上がっていきます。

確認した内容は、そのつど短いメモに残しておきます。読み解いた仕様を自分の言葉で書き直しておくと、後から見返したときの理解が早くなり、担当者への質問も的を絞りやすくなります。

3. 影響範囲の地図が無いという前提で入ります

構成管理や設計の整備は道半ばです

構成管理のツールを導入している企業は、利用する側で約3割、開発・提供する側で約4割にとどまります⁴。導入していても運用が徹底されているとは限らず、変更の記録が一部しか残っていない状態も起こり得ます。

モジュール性やデータモデルを意識した設計に取り組む企業も、利用する側を中心にいまも少ない状態です⁵。つまり「どこを触ると何に響くか」を一目で見渡せる地図は、最初から用意されていないと考えておいたほうが安全です。

ツールを導入している現場でも、対象がプロジェクトの一部にとどまっている場合があります。導入の有無だけでなく、どこまでの範囲を管理しているかを合わせて確かめておくと、思い違いを防げます。

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

地図の有無で仕事の進み方が変わります

地図が無い状態で仕事を始めると聞くと、身構えてしまうかもしれません。ただ実際には、この前提で進む案件は珍しくなく、進め方さえ整えれば大きな支障にはなりません。

地図があるかないかで、変わるのは技術の難しさよりも、確認にかける時間の配分です。地図が無い前提に立つと、着手前に関連箇所を洗い出す時間を、最初から工程に組み込めます。下の表に、地図がある場合とない場合の違いをまとめました。

観点	地図がある場合	地図が無い場合
変更前の確認	関連する箇所を先に洗い出せます	触ってみないと分からない部分が残ります
見積もりの精度	想定外の手戻りを減らせます	着手後に影響が広がりやすくなります
引き継ぎのしやすさ	資料を渡せば経緯が伝わります	引き継いだばかりの担当者には伝わりにくくなります

地図を最初から完璧に作る必要はありません。関連しそうな箇所を触れるたびに短いメモへ残していくだけでも、次にその案件へ関わる人への引き継ぎ材料になります。

図の作成：Remogu編集部。影響範囲を確認する手順の違いを整理したもので、統計データではありません

4. 外部のサービスとの境目を先に引きます

外部サービスの活用は6割強に及びます

外部のサービスや製品は、一部の利用を含めて6割強の企業が活用しています⁷。保守を受ける仕事の中には、自社で作った部分だけでなく、外部から取り込んだ部分の面倒を見る場面も含まれます。境目を先に把握しておくことが欠かせません。

境目を意識せずに手を動かすと、直したつもりの箇所が実は外部側の仕様に依存していた、という事態が起こります。着手の前に「これは自社の領域か、外部の領域か」を分けて考える習慣をつけておきます。

境目は契約書の文言だけでは見えにくいこともあります。実際の画面や帳票を動かしながら確認すると輪郭がはっきりするため、触れる前に担当者と一緒に境目を洗い出す時間を取っておきます。

外部サービスの契約内容や利用規約を確認できる場合は、着手前に目を通しておきます。改修の範囲がその外部サービスの仕様に触れるかどうかを見分ける材料になります。

利用方針を持つ企業は約半数にとどまります

外部サービスの利用に関する方針を整備している企業は、全体の約半数です⁸。方針を確かめようとしても、明文化されたものが手元に無い現場は珍しくないという前提で臨みます。

方針が無ければ作らないのではなく、担当する範囲について自分の側で確認を取りながら進めます。外部サービス側の仕様変更に自社の実装が引きずられていないかは、変更に着手する前に確かめておきたい点です。

方針が定まっていない現場では、外部サービス側の仕様変更に気づく仕組みも整っていないことがあります。変更の通知がどの経路で届くのかを、参画の早い段階で確認しておきます。

5. 決める人がいない現場で起きること

責任者を置いていない企業は約半数です

意思決定を担う責任者を置いていない企業は、約半数に上ります⁹。仕様の判断に迷ったとき、誰に確認すればよいかがはっきりしていない現場に入る可能性は、思っているより高いと考えておきます。

確認する相手が定まっていない状態は、担当者の能力とは関係のない、体制側の事情です。ここで手が止まってしまうより、確認の窓口をどう作るかを早い段階で相談したほうが、後の進み方が安定します。

小さな判断まで持ち帰って確認する必要がある現場では、進行の速さよりも、確認先を把握していることのほうが仕事の進めやすさにつながります。誰に何を聞けるかを、参画のごく初期に整理しておきます。

確認先が定まっていない状態は、体制が整うまでの一時的な状況であることもあります。窓口が途中で変わる可能性も踏まえて、定期的に確認し直す姿勢が助けになります。

責任者の有無で確認の道筋が変わります

責任者がいる現場といない現場では、同じ質問をしたときの答えの出方が変わります。下の表に、決める人がいる場合といない場合で何が変わるかをまとめました。

場面	責任者がいる場合	責任者がいない場合
仕様の判断	短い時間で結論が出ます	複数人に確認して回ることになります
例外的な対応	誰の了承で進めるかが明確です	確認先を探すところから始まります
外部サービスの選定	判断の基準を共有できます	都度手探りで進めることになります

責任者がいない現場では、判断を待つより、確認の記録を自分の側で残していく進め方が向いています。誰にいつ何を確認したかを残しておくと、後から範囲が広がったときの説明材料にもなります。

決裁の窓口が複数に分かれている現場もあります。その場合は、どの順番で確認を通せばよいかを最初に聞いておくと、後になって手続きが往復する事態を減らせます。

6. 止まる備えは整っているか確かめます

リスク管理と業務継続計画は5〜6割程度の整備です

ITのリスク管理と業務継続計画は、全体の5〜6割程度の企業が整備しています⁶。裏を返せば、残りの企業では、システムが止まったときの動き方があらかじめ決まっていない可能性があるということです。

保守の案件を受けるときは、平時の直し方だけでなく、止まったときにどう連絡が回り、誰が判断するのかも合わせて確認しておきます。計画が整っていない現場ほど、この確認が仕事の質を左右します。

業務継続計画が整っている現場では、障害が起きたときの役割分担があらかじめ文書に残されています。参画の前に、その文書が存在するかどうかを尋ねてみる価値があります。

文書が用意されていない場合でも、過去に障害が起きた際にどう対応したかを聞いておくと、実際の動き方を知る手がかりになります。

自社と外部サービスの両方について備えを確認しておけば、止まったときにどちらの窓口へ先に連絡すればよいかも判断しやすくなります。

外部サービス側の不安要素も併せて見ます

外部のサービスについても、保守や運用に不安を抱える企業が多く見られます¹⁰。自社側の備えを確かめるだけでなく、依存している外部サービス側の運用体制まで視野に入れておくと、止まったときの動き方がより具体的になります。

止まる場面を想像することよりも、止まったときに誰が最初に動くかを確認しておくことのほうが、実際には役に立ちます。備えの中身を尋ねる質問を、参画の早い段階で用意しておきます。

外部サービス側の対応窓口や保守契約の有無も、確認しておきたい材料です。自社のシステムだけでなく、依存している先の体制まで含めて把握しておくと、止まったときの動きに迷いが減ります。

7. 担う範囲に線を引く順番

構成管理と設計の状況から確認します

ここまで見てきたとおり、構成管理のツールは利用する側で約3割、開発・提供する側で約4割の導入にとどまり⁴、モジュール性を意識した設計に取り組む企業もいまだ少数派です⁵。担う範囲を決める前に、まずこの土台がどこまで整っているかを確かめます。

土台の整備状況を知ることよりも、その整備状況を前提にどこまで自分が動いてよいかを言葉にすることのほうが重要です。整っていない前提で境界を引けば、後から「そこまでは聞いていない」という食い違いを防げます。

確認の順番を守ることは、担当する領域を狭く見せるためではありません。むしろどこまで自分が引き受けられるかを、根拠を持って示すための土台になります。

確認した内容は、口頭で終わらせず短いメモにまとめておきます。次の工程に進む前に読み返す材料にもなり、担当者との認識のずれに早い段階で気づけます。

書面で確かめておくことをまとめます

担う範囲を口頭のやり取りだけで済ませると、記憶違いや解釈の差がそのまま後に残ります。構成管理の状況、外部サービスとの境目、意思決定の窓口、止まったときの連絡経路。この4点は、参画前に書面で確かめておきたい項目です。

確認した4点をすべて集めてから動き出す必要はありません。分かった範囲から着手しつつ、不明点はそのつどクライアントと協議して埋めていく進め方でも十分に機能します。

案件の90%以上がフルリモート可能です。場所に縛られずに参画できる分、こうした確認は対面の雑談任せにできません。まず自分の経験に合う条件を確かめ、そのうえで担う範囲を書面に落とし込む順番で進めてみましょう。

図の作成：Remogu編集部。担う範囲を確かめる手順を整理したもので、統計データではありません

見積もり前にどこまで確認すればよいですか

構成管理ツールの導入状況、外部サービスとの境目、決裁の窓口の3点は、見積もりを出す前に確認しておきたい項目です。この3点が不明のまま作業量を見積もると、着手後に想定外の確認作業が積み重なりやすくなります。

この3点さえ押さえておけば、残りは着手しながら確認しても大きな支障にはなりません。最初からすべての情報がそろうことを前提にしないほうが、見積もりを滞らせずに進められます。

保守と新規のどちらに向いているかを見分ける基準はありますか

断定できる基準はありませんが、ドキュメントと実際の挙動を照らし合わせる作業を負担に感じるか、手がかりを探す作業として楽しめるかは、一つの目安になります。保守の仕事は、新しく作る力よりも、すでにあるものを読み解く力が問われる場面が多くなります。

明確な基準があるわけではありませんが、変更の理由を後から説明できる形に整理する作業に苦を感じないかどうかは、一つの判断材料になります。まず1件受けてみて、進め方が自分に合うかを確かめる方法もあります。

参画後に担う範囲が広がった場合はどうすればよいですか

範囲が広がったと感じた時点で、最初に確認した書面と照らし合わせ、どこからが追加の依頼かをクライアントと協議します。記録を残しておけば、この協議は感情的な押し問答ではなく、条件の確認として進められます。

こうした場面は珍しくないため、最初に交わす書面に「範囲外の依頼が出た場合の扱い」を一文入れておくと、後の協議がよりスムーズになります。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年8月確認）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月・2026年8月確認）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」構成の把握（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まる備え（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」利用の広さ（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」方針の有無（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」不安の所在（2025年4月・2026年8月確認）