Angularで作られた画面の保守を打診されると、まず気になるのは作業量よりも、どこまで引き受けるかという線引きです。新しい版へ追いつく作業を誰が持つかが決まっていない案件は、期間も範囲も読めないまま進みがちです。国内の開発現場を対象にした調査では、部品の管理や設計に取り組む体制が整っていない企業がまだ多いことが分かっており、保守に入ってから想定外の作業が見つかることも珍しくありません。この記事では、保守で負う範囲をどう見極め、引き受ける前に何を確かめるかを、調査の結果に沿って順番に整理します。

1. 版の追従を誰が持つかを決める

打診された時点で範囲が曖昧だと起こること

Angularの保守を打診される場面では、まず「今の状態を保つ」ことだけが仕事に見えます。しかし実際に手を動かすと、新しい版へ追いつく作業が、保守を続けるうちに発生します。最初は小さな確認作業でも、積み重なると全体の工数を押し上げます。

この作業を誰が持つかが最初に決まっていないと、見積もった期間の中に収まらない作業が後から積み上がっていきます。保守側が黙って引き受けた分だけ、実際の稼働は見積もりから離れていきます。

前提として管理体制が薄いと考えておく

国内の開発現場を対象にした調査では、オープンソースの利用方針や、それを専門に見る体制(OSPO)が整っていないことが分かっています¹。方針を持つ組織自体が少ないという結果です。

方針を持つ組織が少ないという前提に立つと、保守を引き受ける側が最初に「今どの部品を、どの版で使っているか」を確認する作業から始まる場合があります。この確認作業自体が、見積もりに含まれていないことも珍しくありません。

加えて、部品を分けて管理したり、データの持ち方を意識した設計に取り組んでいる企業は、使う側の企業を中心に、依然として少ないです⁴。設計の段階で整理されていない画面ほど、後から手を入れる範囲が広がります。

設計の段階から整理されていない案件ほど、追いつく作業の範囲は担当者の裁量に委ねられやすくなります。引き受けてから調整するよりも、引き受ける前にこの範囲をクライアントと言語化しておく方が、後の作業量を左右します。

言語化する内容は難しいものではありません。追従作業を発生のたびに保守側が担うのか、発生を知らせるところまでを保守側の役割とし、実施はクライアント側が判断するのか、この二択を打診の段階で確認するだけで十分です。どちらかが決まっていない案件ほど、後になってから範囲を巡るやり取りが増えます。

図の作成:Remogu編集部。保守で挙がりやすい作業を整理したもので、すべての案件に当てはまるとは限りません

2. 部品の一覧が無いという前提を疑う

導入が広がっていない管理の道具

保守を始める前提として、使っている部品の一覧(SBOM)や、部品同士のつながりを整理するグラフデータベース、事前に動きを試すシミュレーションといった道具の導入は限定的です²。これらが揃っているかどうかで、保守の作業量は大きく変わります。

部品の一覧(SBOM)とは、画面や仕組みを組み立てるときに使っている外部の部品を、名前と版ごとに書き出した記録のことです。保守を引き受ける前にこの記録があるかを尋ねるだけで、作業の見通しが変わります。

一覧が無い状態から保守が始まる

一覧が無い状態で保守に入ると、まず何を使っているかを洗い出す作業から始めることになり、想定していた作業時間を圧迫します。洗い出しには画面を一つずつ確認する手間がかかります。

開発と運用を素早く繰り返す進め方(DevOps)や、設計図をもとに動きを確かめるモデルベースの開発についても、作る側の企業を除くと、導入している企業は少ないです³。変更を試す仕組みが無いまま、本番に近い環境で確認する場面が増えます。

洗い出す作業を後回しにするよりも、保守に入る前に部品の一覧の有無を確認する方が、想定外の遅れを防げます。尋ねる相手はクライアント側の担当者で構いません。

一覧が無い場合、部品を洗い出す作業をどちらが担うかも合わせて決めておきたい点です。保守側が洗い出しごと引き受けるのか、クライアント側が既存の資料を探して渡すのかで、最初の数週間の作業内容は大きく変わります。

下の表は、道具の導入状況と、保守を引き受ける側が確かめておきたい点を整理したものです。項目ごとに尋ね方を変えると、聞き漏らしを防げます。

項目	導入状況	保守で確かめておきたい点
使っている部品の一覧(SBOM)	導入は限定的2	一覧があるかどうかをまず尋ねる
部品のつながりを整理する仕組み(グラフデータベース)	導入は限定的2	変更したときの影響範囲をどう追うか確認する
事前に動きを試す仕組み(シミュレーション)	導入は限定的2	変更後の確認方法を尋ねる
開発と運用を素早く繰り返す進め方(DevOps)	作る側を除くと導入は少ない3	変更を反映する頻度を確認する

尋ねるときは「一覧はありますか」だけで終わらせず、「一覧が無い場合、どこまでを保守側で作りますか」まで踏み込んで聞くと、後の作業量の見通しがはっきりします。

図の作成:Remogu編集部。調査で報告された導入の程度を帯の長さで整理したもので、統計データではありません

3. 弱点の情報をどこまで追うか

出荷後も情報を集め続ける

保守で負う範囲を考えるときに欠かせないのが、弱点(脆弱性)の情報をどこまで追うかという点です。保守は、画面を作って終わりではありません。むしろ公開した後も情報を追い続ける作業自体が、保守の一部として想定されています。

開発者向けの指針では、構成管理の資料をもとに、製品を出荷した後も継続して弱点の情報を収集します⁵。出荷した時点で作業が終わるわけではないという考え方です。

集めた情報をそのまま使わない

同じ指針では、集めた情報について、実際の画面や仕組みで再現するかどうかを確認します⁶。情報を集めるだけでは、対応が必要かどうか判断できません。

情報を集めるだけで終わらせず、自分たちの状況に当てはまるかを一つずつ確かめる作業まで含めると、想定より工数がかかります。確認の手順を誰が担うかも、保守の範囲に関わる点です。

下の表は、この二つの作業を分けて示したものです。範囲に含めるかどうかは、引き受ける前に言葉にしておくと後の認識違いを防げます。

収集と確認を同じ作業だと考えていると、契約に含めたつもりのない工数が実際には発生することになります。二つを分けて考えることが出発点です。

特に「確認」の作業は、情報を読むだけでは終わりません。実際の画面を動かして再現するかどうかを確かめる分だけ、稼働時間として積み上がります。収集の頻度と確認の手間は、別々に見積もっておく方が安全です。

作業	内容	引き受ける側が確認したい範囲
情報を集め続ける	構成管理の資料をもとに、出荷後も継続して情報を収集する5	どの頻度で、誰が確認するか
当てはまるかを確認する	集めた情報が実際の画面や仕組みで再現するかを確認する6	確認した結果をどこに残すか

4. 使う人からの連絡を受ける範囲を決める

問い合わせも情報源のひとつ

弱点の情報は、公開された資料だけから集まるわけではありません。日々の運用の中にも、情報の手がかりは存在します。

同じ指針では、使う人からの問い合わせも、弱点の情報源として扱います⁷。問い合わせの窓口自体が、情報を集める仕組みの一部になっているという考え方です。

これは、画面を使っている人から届く「動きがおかしい」といった連絡の中に、弱点に関わる手がかりが含まれている場合があるためです。連絡の内容を軽く扱うと、見落としにつながります。

連絡そのものは技術的な内容とは限りません。使う人の言葉で伝えられる違和感を、保守側が技術的な確認に翻訳する作業も、この範囲に含まれると考えておくと準備がしやすくなります。

使う側が優先しているもの

保守を引き受ける側にとっては、こうした連絡をどこまで受け、どこから先をクライアントに戻すかという線引きが必要になります。窓口が曖昧なままだと、対応の抜け漏れが起こりやすくなります。

使う側の企業を対象にした調査では、システムに優先して求める事項として品質が最も多く挙げられています¹⁰。品質への意識が高いほど、連絡への対応も丁寧さが求められます。

問い合わせを黙って受け続けるよりも、対応する範囲とクライアントへ戻す境目を先に決めておく方が、後の負担を抑えられます。窓口の役割は、契約の段階で言葉にしておく価値があります。

連絡の受け方も具体的に決めておくと安心です。誰が最初に受けるか、どの範囲までを自分で判断して答えてよいか、判断に迷う内容はどこへ回すか。この三つを打診の段階で確認しておくと、実際に連絡が来たときに迷わずに動けます。

5. 古いという認識が薄い現場を見る

レガシーではないと考える現場が多い

保守の現場でよく起こるのが、古い仕組みだという認識そのものが薄いという状態です。使われ続けている画面ほど、古さが意識されにくくなります。

各国の開発現場を比べた調査では、「レガシーシステムはない」と答えた割合は、日本が最も高いという結果が出ています⁸。周囲からは古いと見える画面でも、現場の認識は異なる場合があります。

古いという自覚が無いまま使われ続けている画面や仕組みほど、保守に入ってから想定外の作業が見つかりやすくなります。見た目が動いていても、内側の部品は追従が遅れていることがあります。

設計への取り組みは少ないまま

一方で、部品を分けて管理したり、データの持ち方を意識した設計に取り組んでいる企業は、依然として少ないです⁴。認識だけでなく、設計の実態も追いついていないという結果です。

「古いという認識が薄い」ことと、「設計への取り組みが少ない」ことは、別々の調査結果ですが、並べて見ると現場の実態が近づいて見えます。二つの結果が重なる場面が、保守の負担が増えやすい場面でもあります。

打診の場で「古い部分はありますか」とだけ尋ねても、答えは「特にない」で終わることがあります。設計に取り組んだ範囲を具体的に尋ねる方が、実態に近い答えが返ってきます。

古いという前提を疑わないよりも、認識と実態のずれを引き受ける前に確かめる方が、見積もりの精度が上がります。下の表は、この二つの結果を並べたものです。

認識と実態のずれは、期間の見立てにも影響します。古くないという前提で短く見積もると、部品を洗い出す作業や設計を読み解く作業が後から追加され、当初の期間では収まらなくなる場面が出てきます。

観点	調査結果	保守での見え方
古さへの認識	「レガシーシステムはない」と答えた割合は日本が最も高い8	古くない前提で見積もると想定外の作業が出やすい
設計への取り組み	部品を分けたりデータの持ち方を意識した設計に取り組む企業は依然として少ない4	一覧や設計図が無いまま保守に入る可能性がある

6. つなぐ側は進んでいるという前提を疑う

クラウドやAPIは比較的進んでいる

ここまで見てきた内容だけを読むと、国内の開発現場全体が遅れているように見えるかもしれません。ただし、進んでいる部分もあります。

調査では、クラウドやつなぐ仕組み(API)の導入は、作る側の企業を中心に比較的進んでいます⁹。外部の環境とやり取りする部分は、比較的整備が進んでいます。

つまり、外部とのつながりを作る部分は整っていても、部品の一覧や管理の道具の導入は限定的だという結果と合わせて見る必要があります²。進んでいる部分だけを見て全体を判断すると、実態を見誤ります。

進んでいる部分と遅れている部分が混在する

進んでいる部分と遅れている部分が同じ現場に混在しているため、保守を打診されたときに「全体として進んでいるか」を確認しても、実態はつかみにくいです。

全体として進んでいるかを一括りに聞くよりも、つなぐ仕組みと部品の管理を分けて尋ねる方が、実態をつかみやすくなります。質問を分けるだけで、聞き取れる情報の量は変わります。

質問を分けることは、追加の作業量ではなく、後の認識違いを防ぐための最初の一歩です。打診の段階でこの二つを分けて尋ねておくと、後の見積もりが立てやすくなります。

尋ねる順番としては、先に外部とのつながりの整備状況を聞き、次に部品の管理の状況を聞くと、話がかみ合いやすくなります。クラウドやAPIの話から始めると、担当者にとっても答えやすい入り口になります。

図の作成:Remogu編集部。一覧の有無による手順の違いを整理したもので、統計データではありません

7. 引き受ける前に確かめる順番

確かめる順番

ここまでの内容を踏まえると、Angularの保守を打診されたときに確かめておきたい順番が見えてきます。順番を決めておくと、確認漏れを防げます。

まず、部品の一覧があるかどうかを尋ねます。無ければ、洗い出す作業から始まる前提で範囲を考えます。この時点で作業量の見立てが大きく変わります。

次に、弱点の情報をどこまで追うかを確認します。構成管理の資料をもとに情報を集め続ける作業まで含むのか⁵、含むならその頻度も合わせて尋ねます。

続いて、使う人からの問い合わせをどこまで受けるかを確認します。問い合わせも情報源として扱う場合があるため⁷、受けた後の連絡先も決めておきます。

分からない場合の書き方

どこまで含まれるかがその場で分からない項目は、無理に決めず「後日確認する」と記録に残します。その場で答えを作らないことが、後の食い違いを防ぎます。

数字や条件を推測で埋めるよりも、分からない点は記録に残す方が、後の認識違いを防げます。この順番で確かめておくと、引き受けた後に範囲が膨らんでいく事態を防ぎやすくなります。

四つの確認は、いずれも打診を受けたその場で終わらせられる分量です。時間をかけて調べ直す必要はなく、担当者に順番に尋ねるだけで、保守で負う範囲の輪郭がはっきりしてきます。

逆に、この四つを尋ねずに引き受けてしまうと、範囲の解釈がずれたまま作業が進み、途中で条件を見直す話し合いが必要になります。最初の数十分の確認が、後の数週間の進め方を左右します。

図の作成:Remogu編集部。確認の順番を整理したもので、すべての案件に当てはまるとは限りません

版への追従作業は保守の範囲に含まれますか

含まれるかどうかは案件ごとに異なります。打診された時点で、追従作業を誰が持つかを言葉にして確認しておくと、後の認識違いを防げます。曖昧なまま引き受けると、後から範囲が広がりやすくなります。

弱点の情報はどこまで集めれば十分ですか

指針では、構成管理の資料をもとに出荷後も継続して情報を収集します⁵。集める範囲と頻度は、引き受ける前にクライアントと合わせておく点です。合わせておかないと、対応の抜け漏れが後から見つかります。

部品の一覧が無い案件は避けたほうがよいですか

一覧が無いこと自体は珍しくありません²。無い場合は、洗い出す作業から始まる前提で期間と範囲を見積もり、その分を条件に含めて協議します。避けるかどうかより、条件をどう調整するかが実際の判断になります。

むしろ一覧の有無を最初に確認できたこと自体が、案件の中身を早い段階で把握できたという意味を持ちます。何も尋ねずに引き受けるより、確かめてから判断する方が、後の負担を見通しやすくなります。

保守を打診される場面が増えている人にとって、参画先を自分で選べるかどうかは気になる点です。案件の90%以上がフルリモート可能です。まず自分の経験に近い案件がどのくらい並んでいるか、登録して確かめてみるのも一つの進め方です。

保守の打診を受けたら、まず部品の一覧の有無と、版の追従作業を誰が持つかの二点から確認してみてください。それだけで、引き受けた後の見え方が変わります。

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

出典・参考情報

＊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「脆弱性対処に向けた製品開発者向けガイド」監視の継続（2026年3月・2026年8月確認）
＊6 IPA「脆弱性対処に向けた製品開発者向けガイド」確認の段（2026年3月・2026年8月確認）
＊7 IPA「脆弱性対処に向けた製品開発者向けガイド」情報源の広さ（2026年3月・2026年8月確認）
＊8 IPA「DX動向2025」古い仕組みの見え方（2025年6月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」進んでいる領域（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）