Javaの保守案件でまず求められるのは、動いているコードを壊さないことです。「影響範囲を確認してから直す」とよく言われますが、その材料は現場に用意されていないことがあります。構成管理のツールを導入している企業は、利用する側で約3割にとどまります¹。境界が引かれていない前提に立ち、自分で線を引いて合意を取る手順を整理します。

1. 影響範囲を確認できない現場の実態

構成の全体像が見えないまま保守が始まること

保守案件で最初に欲しいのは、システムがどんな部品で構成され、どこがどこと繋がっているかという地図です。ここが見えないまま直すと、直した先で思わぬところが動かなくなります。構成管理のツールを導入している企業は、利用する側で約3割にとどまっています¹。地図が無いところから仕事が始まる前提で臨むことになります。

作る側の企業でも導入は約4割にとどまり¹、構成管理は当たり前の備えとは言えません。整っていない現場を前提にしたほうが、見通しを立てやすくなります。備えを自分で補う場面を、あらかじめ想定しておく形です。

図の作成：Remogu編集部。受け持つ範囲と影響が届く範囲の関係を整理したもので、統計データではありません

中身の一覧が無いまま手を動かすリスク

構成の次に欲しいのが、何が使われているかという部品の一覧です。SBOM（ソフトウェア部品表）を導入している企業は1割未満にとどまり¹、何が入っているかを外から確かめる手段がほとんど整っていません。

一覧が無い現場では、直す前に「これは触ってよい部品か」を判断する材料自体がありません。保守に入った直後は、直すより先に、今ある構成を自分の目で棚卸しする時間を確保する選択肢があります。最初の数日を棚卸しに使うかどうかで、後の作業の見通しは変わりえます。

棚卸しをせずに直接コードへ手を入れると、変更した箇所以外への影響に気づくのが不具合の後になる場合があります。事前に気づける流れと事後に気づく流れとでは、対応にかかる時間が変わってきます。

地図も部品の一覧も整えている企業は、調査の数字で見ると少数にとどまります。最初にすることは、無い状態を嘆くことではなく、今ある情報をつなぎ合わせて自分なりの地図を仮に作ることです。続く節では、その地図の境界がそもそも引かれていないという、もう一段深い前提を扱います。

2. 境界が引かれていないという前提

モジュール性やデータの持ち方が整っていないこと

地図があっても、部品同士の境界線がはっきり引かれていなければ、どこまでが自分の担当かを決められません。モジュール性やデータモデルを意識した設計に取り組む企業は、特に利用する側を中心に依然として少数にとどまります¹。境界という考え方そのものが、まだ現場に根づいていない可能性があります。

境界が無い設計では、一つの機能を直すつもりが、離れた画面の表示や別のバッチ処理にまで影響が及ぶことがあります。触った場所と、実際に効果が及ぶ場所が一致しないという状態が、保守を難しくする要因の一つです。

図の作成：Remogu編集部。境界が無い設計で変更が伝わる経路を整理したもので、統計データではありません

つなぐ部分への関心は別に存在すること

一方で、外部とのやり取りにあたるAPIの活用や、標準的なデータの形式への対応には、作る側の企業を中心に比較的高い関心が向けられています¹。境界の中身は整っていなくても、境界の入口だけは意識されているという、ねじれた状態です。

調査では、内側の設計よりも、外に見える接続部分のほうに関心が向いている様子が読み取れます。保守に入るときは、接続部分より内側の境界に、自分で注意を向ける場面を想定しておく形になります。

比較で見る、境界の内と外の温度差

同じ調査の中でも、内側の設計に関する取り組みと、外とつながる部分の取り組みとでは、企業の関心の向き方が違います。表にすると、どこが手薄でどこに関心が向いているかがはっきりします。中の境界を引く作業を、後から自分が引き受ける場面がある、という見通しにつながります。

観点	状況	出典
モジュール性・データモデルを意識した設計	利用する側を中心に取り組みが少ない	3
API活用・標準的なデータ形式への対応	作る側を中心に意識が高い	13

内と外で関心に差があるなら、境界を引く作業の多くは、外からは見えない内側に残ります。保守に入ったときに最初に確かめたいのは、この内側の境界がどこにあるかです。次の節では、その境界を誰が決めるのかという、もう一つの空白を扱います。

3. 決める人の不在

意思決定を担う責任者が不在であること

境界を自分で引いたとしても、それを最終的に承認してくれる相手が必要です。ところが、意思決定を担うCxOクラスの責任者を設置していない企業は、約半数に上ります¹。承認を求めても、誰が承認者なのかがそもそも定まっていない可能性があります。

責任者が不在の現場では、窓口が分散していることがあります。誰かの一存で決まらない場合、合意は複数の相手から少しずつ集めていく作業になります。

優先順位そのものが決まっていないこと

投資の配分やデータの使い方について方針を明確にしている企業は少なく、対応の遅れが目立っています¹。何を先に直すかという優先順位自体が、組織としてまだ決まっていない場合があります。

優先順位が決まっていない場所では、保守に入ったエンジニアが暫定的に順番を提案する場面が出てきます。提案は越権ではなく、決まっていない空白を埋める役割として位置づけられます。

誰に確認すればよいかを知るには、まず「誰が困っているか」から逆算する方法があります。日々の運用で不便を感じている担当者、過去の変更履歴を持つ担当者、外部とのやり取りを窓口にしている担当者——この並びで話を聞くと、責任者が不在でも合意の材料を集められます。

図の作成：Remogu編集部。確認する順番の一例を整理したもので、統計データではありません

誰に聞けば決まるのかという道筋が見えてくると、次に気になるのは、その相手が持っている知識そのものの中身です。知識が特定の人に偏っている現場では、聞く相手を間違えると話が進みません。

4. 人に付いた知識

技術情報が個人任せになっていること

システムの経緯や癖といった技術情報は、体系的な仕組みを持たず、個々のメンバーに任せている企業が多くを占めます¹。マニュアルより先に、特定の人の記憶を頼る場面が出てきます。

知識を持つ人が異動や契約終了で現場を離れると、情報は引き継がれないまま失われることがあります。保守を任されたエンジニアがまず声をかける相手は、マニュアルよりも、長く現場に関わってきた人が候補になります。

属人化した現場と、仕組み化された現場の違い

知識の持ち方には、大きく分けて二つの型があります。一つは特定の人に情報が集まる型、もう一つは記録や手順として仕組みに残す型です。今の保守案件がどちらに近いかを最初に見分けておくと、情報の集め方の見当がつきます。表で二つの型を並べて整理します。

型	情報の持ち方	保守での動き方
人に付く型	経緯や癖が特定のメンバーの記憶に残る	まずその人に会って話を聞く
仕組みに残る型	変更履歴や設計判断が文書に残る	文書を確認してから要点を人に確かめる

調査では、体系的な仕組みを持たず個人に任せる企業が多いため¹、前者の「人に付く型」から始まる現場を想定できます。最初の数週間を情報を集める期間と位置づけ、直す量より聞き取った内容を記録する量を増やす進め方があります。

集めた情報は自分のためだけに使わず、次に保守を引き継ぐ人のために残す発想もあります。属人化した現場に入って属人化を増やすのではなく、次の一歩を残す関わり方です。

知識の持ち方が見えてきたところで、次に見るのは、この現場がどんな進め方の前提で動いているかです。開発の進め方が混ざっている現場では、知識の集め方も変わってきます。

5. 工程の前提の混在

いまも主流はウォーターフォールであること

保守案件に入る前提として知っておきたいのが、開発の進め方です。いまも主流なのはウォーターフォール型の手法です¹。区切られた工程を順番に進める前提で作られたシステムが、保守の対象になっていると考えられます。

区切りを前提にしたシステムには、後から変更を加えることを想定していない設計が残っていることがあります。変更のたびに影響範囲を洗い出す手間がかかるのは、この前提の違いが理由になっている場合があります。

アジャイルやノーコードが部分的に混ざっていること

一方で、アジャイル開発も一部を含めれば全体の2〜4割程度の企業が取り入れています¹。ノーコードやローコードも、一部利用を含めると約4割の企業が取り入れている状況です¹。

古い前提で作られた部分と、新しい手法で足された部分が同じシステムの中に同居している——同じシステムの中にこうした前提が混ざる場合があります。複数の手法が一部でも取り入れられている以上、前提が混ざる可能性は十分にあります。

前提が混ざっている場所を保守するときは、「この部分はどちらの前提で作られたか」を先に見分ける作業が要ります。見分けがつけば、影響範囲を洗い出す手間のかけ方も、部分ごとに変えられます。

前提が混ざっていることが分かると、次に見るのは、その混ざった前提を自動で確かめる仕組みがどれだけ用意されているかです。ここが薄い現場では、確かめる作業も自分で組み立てる必要が出てきます。

6. 自動で確かめる土台の薄さ

自動で確かめる仕組みが薄いこと

変更が意図しない影響を起こしていないかを自動で確かめる仕組みについても、状況は同じです。DevOpsやモデルベース開発は、作る側の企業を除くと導入している企業は少なくなっています¹。自動で確かめる土台そのものが、多くの現場でまだ薄いということです。

土台が薄い現場では、変更のたびに人の目で確認する作業が中心になります。自動化された確認を前提にせず、人による確認を組み込む場面が出てきます。

AIの活用は現場によって温度差があること

開発にAIを取り入れる動きについても、企業によって温度差があります。表にして、利用する側と作る側のそれぞれの状況を並べておきます。この差を知っておくと、AIを使った確認作業がどこまで現場に根づいているかの見当がつきます。

立場	AI導入の状況	出典
利用する側の企業	検討中・試行中を含めて約2割が導入を意識	14
作る側の企業	約4割が導入を意識	14

数字だけを見ると差は大きく見えますが、どちらの立場でも、導入を意識する企業は半数に届いていません¹。AIによる確認を前提にできる現場は、今のところ限られる可能性があります。

自動で確かめる土台が薄いなら、確かめ方そのものを自分で用意する発想に切り替える必要があります。小さく変更して都度確認する、変更前の状態を記録しておく、といった手順を自分の作業の型として持っておくと、土台の薄さを補えます。

図の作成：Remogu編集部。自動化の土台が薄いときの進め方を整理したもので、統計データではありません

自分の手元での確かめ方が整ったところで、最後に見るのは、自分が直接触る部分の外側、外部のサービスまで含めた範囲です。保守の範囲は、社内のコードだけにとどまりません。

7. 外部サービスと止まったときの備え

外部サービスにも不安が残っていること

保守の対象は、自分たちが手を入れられるコードだけではありません。外部のサービスについても、維持や運用に不安を抱える企業は多く見られます¹。自分の担当範囲の外側にも、確かめる対象となる境界があります。

外部サービスが止まったときにどう動くかは、コードを直す技術とは別の準備です。担当する範囲の中だけを見ていると、この外側の備えが抜け落ちる場合があります。

リスク管理と業務継続の計画は半分程度で整っていること

ITのリスク管理や業務継続計画については、全体の5〜6割程度の企業が整えています¹。半分以上は備えがある一方で、残りの4〜5割は整備できていない計算になります。

備えがある現場では、止まったときの動き方を確認すれば足ります。備えが無い現場では、保守に入ったエンジニアが「止まったらどう連絡するか」を最初に確かめる意味があります。

地図が無く、境界も引かれておらず、決める人も定まらず、知識は人に付き、前提は混ざり、確かめる土台も薄い。調査の数字は、こうした条件が保守の現場に広く残っていることを示しています¹。だからこそ、直す前に自分で線を引き、合意を取る手順そのものに価値が生まれます。

線を引く経験は、影響範囲が読みにくい保守の案件で役立ちます。Remoguは、案件の90%以上がフルリモート可能です。まずは登録して、自分のこれまでの経験に近い保守案件がどれくらいあるか、確かめてみましょう。

8. よくある質問

保守の範囲について出やすい疑問のうち、調査の数字で答えられるものを取り上げます。

外部のサービスの保守まで、自分の担当に含めて考える必要はありますか

含めて考える余地があります。外部のサービスの維持や運用に不安を抱える企業は多く見られ¹、直接手を入れられない部分でも、止まったときの連絡先や動き方は担当範囲の外側として確かめる対象になります。

リスク管理や業務継続の計画は、どのくらいの会社で整っていますか

全体の5〜6割程度の企業が整備しています¹。残りの4〜5割は整備できていない計算になるため、計画の有無を最初に確かめ、無い場合は止まったときの連絡先を先に決める進め方があります。

AIを使って影響範囲を確認する方法は、どのくらいの企業に広がっていますか

利用する側では検討中・試行中を含めて約2割、作る側では約4割が導入を意識している段階です¹。今のところは、人の目による確認を併用する前提で臨む形になります。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」影響範囲の材料（2025年4月・2026年10月確認）