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割には、止まったときの動き方がまだ決まっていません。

備えがある現場に当たれば、止まったときの動き方を確認するだけで済みます。備えが無い現場に当たったときこそ、保守に入ったエンジニアが「止まったらどう連絡するか」を最初に確認しておく価値が高まります。

ここまで見てきたように、地図が無く、境界も引かれておらず、決める人も定まらず、知識は人に付き、前提は混ざり、確かめる土台も薄いというのが、保守の現場ではむしろ普通の状態です¹。だからこそ、直す前に自分で線を引き、合意を取る手順そのものに価値があります。

ここまでの流れを踏まえると、保守の範囲について実際によく聞かれる疑問にも、事実をもとに答えられます。

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

直接手を入れられない部分でも、止まったときにどう動くかは確認しておきたい範囲です。外部のサービスについても維持や運用に不安を抱える企業は多く¹⁰、自分の担当の外側にも目を配る価値があります。

リスク管理や業務継続の計画がある会社なら、保守の範囲は安心して任せられますか

全体の5〜6割程度の企業が整えているとはいえ¹¹、残りの4〜5割では計画自体がまだ整っていません。計画の有無を最初に確認し、無ければ止まったときの連絡先だけでも先に決めておくと安心です。

AIを使って影響範囲を確認する方法はもう定着していますか

利用する側では検討中・試行中を含めて約2割、作る側では約4割が導入を意識している段階です¹⁴。まだ定着したとは言えず、今のところは人の目による確認が中心になります。

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

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」影響範囲の材料（2025年4月）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」部品の一覧（2025年4月）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」切り分けの前提（2025年4月）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人の不在（2025年4月）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」混在する現実（2025年4月）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」隣にあるもの（2025年4月）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」確認の仕組み（2025年4月）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」外への依存（2025年4月）
＊11 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」止まったときの備え（2025年4月）
＊12 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」優先順位の不在（2025年4月）
＊13 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」つなぎ目の意識（2025年4月）
＊14 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」道具の広がり（2025年4月）