引き継いだRubyのアプリケーションを開いて、まず戸惑うのは規模の大きさではなく、何が入っているか分からないという感覚です。誰が何のために組み込んだのか分からない部品が並び、更新が止まった依存を見つけても、その先の判断材料がありません。保守を担うエンジニアが最初に向き合うのは、直すことより先に、全体を把握する作業です。この記事では、構成を把握する手順と、更新の判断を安全に進める順番を整理します。

1. 何が入っているか分からないという前提

一覧を持たないまま保守が始まる

保守の案件に入って最初に手を伸ばすのは、コードの修正ではなく、そこに何が組み込まれているかを確かめる作業です。ところが、その一覧を渡されないまま作業が始まることは珍しくありません。構成管理のツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています¹。前任者が把握していたはずの情報は、引き継ぎの時点で半分ほど失われている状態です。

ここで見えてくるのは、依存が多いこと自体が問題ではないという点です。問題は、動いている依存と、更新が止まった依存を見分ける手がかりが手元に無いことにあります。手がかりが無ければ、どこから手を付けても手探りになり、保守という仕事の輪郭がぼやけてしまいます。

だからこそ、最初の仕事は直すことではなく、数えることになります。動いているものと止まっているものを分けて並べたあとで、次に何を確かめるかが見えてきます。

組み込んだ理由が残っていない部品ほど後回しになる

SBOM、つまりソフトウェア部品表を導入している企業は1割未満です²。部品表が無い現場では、なぜその部品を組み込んだのか、誰が判断したのかという経緯が残っていません。経緯が無い部品は、更新するかどうかの相談すら始められない対象になりがちです。

経験のある保守エンジニアほど、まず経緯を尋ねて回ることを面倒に感じません。積み上げてきた経験が教えてくれるのは、部品表が無い現場ほど、聞き取りそのものが最初の成果物になるという順序です。

部品表を後から作ることよりも、まず動いている範囲を確かめることの方が、保守の初期には効きます。目の前のアプリケーションがどこまで動いているかを確かめる作業から、この記事は始めます。

図の作成：Remogu編集部。保守案件でよく見られる状態を整理したもので、統計データではありません

2. 方針が無いという空白

方針が無いと、判断の基準がそのつど変わる

OSSを利用するときの方針や、OSPO(オープンソースプログラムオフィス)の整備は、進んでいません³。方針が無いというのは、誰が読んでも同じ基準にならないという状態です。

方針が無い現場では、依存を新しく組み込むかどうかの判断が、そのときの担当者の感覚に委ねられます。担当者が変われば、判断の基準も変わってしまいます。

保守を引き取った側から見ると、この空白は不便であると同時に、整理のしがいがある部分でもあります。まず方針を作るのではなく、今ある依存を分類する作業から、空白を埋め始められます。

空白を埋めるのは、方針よりも記録

方針そのものを一から作ることは、引き取った側の役割を越えます。委託元と協議しながら進める範囲であれば、依存を組み込んだ理由と、更新を見送った理由を記録に残すことから始められます。

記録を残す作業を積み重ねると、方針が無くても、次に同じ判断をするときの参考になります。方針を作ることよりも、記録を残すことの方が、保守の現場では先に手が届きます。

方針がある場合と無い場合を、保守の場面で比べると

方針があるかどうかで、保守の作業はどう変わるのでしょうか。依存を組み込む判断、更新を見送る理由の記録、引き継ぎのしやすさという3つの観点で、方針がある場合と無い場合を比べると、次のようになります。

観点	方針がある場合	方針が無い場合
依存を組み込む判断	誰が決めるかが決まっている	そのつど個人の判断に委ねられる
更新を見送る理由の記録	記録として残る	記録が残らない
新しく加わる人への引き継ぎ	一覧を渡せる	聞き取りから始まる

図の作成：Remogu編集部。保守案件で起こりやすい状態を整理したもので、統計データではありません

3. 更新が止まった部品を見つけたあと

止まった部品を見つけても、その場で結論を出さない

更新が止まった部品を見つけると、その場で上げるか上げないかを決めたくなります。けれど作る側のガイドが示す順番は違います。出荷したあとも、継続して情報を集め続けることが最初の作業として置かれています⁷。判断はその次に来ます。

止まっている、という状態そのものは入り口にすぎません。集めた情報をもとに、その不具合が今のアプリケーションで実際に再現するかどうかを確認する段階が続きます⁸。再現しなければ、優先度は大きく下がります。

つまり、止まっている部品の数を数えるだけでは、保守の仕事は終わりません。数えたあとに、再現するかどうかを一つずつ確かめる段階まで進んで、ようやく判断の材料が揃います。

確かめる作業は、引き取った側の仕事になる

引き取って続ける立場では、方針を決める側ではなく、確かめる側に立つことが多くなります。委託元の事業者と協議しながら、何を優先して確認するかを一緒に決めていく進め方が向いています。

積み上げてきた経験があるほど、確認の段階を省略したくなる場面もあります。けれど、集める・確かめるという順番を飛ばさないことが、あとで振り返ったときの安心材料になります。

この順番を保守の型として持っておくと、Rubyに限らず、次に引き取るアプリケーションでも同じ手順が使えます。まずは自分がどんな保守案件に向いているかを、条件から確かめてみるのも一つの道です。

4. 順番は「集める・確かめる・決める」

3つの区間に分けると、迷いが減る

集める、確かめる、決める。作る側のガイドが示す順番を三つに分けると、保守の作業は区切りやすくなります。出荷後も継続して脆弱性の情報を集めること⁷、集めた情報が今の環境で再現するかを確認すること⁸、そのうえで被害の大きさと起きやすさからリスクを分析すること⁹。この三つは順番が入れ替わりません。

保守案件では、この三区間のうち「決める」だけが目立つ場面があります。けれど決める材料は、その前の二区間で作られています。集める区間と確かめる区間を素通りすると、決める区間で使える材料がありません。

思いつきで上げる判断よりも、集めて確かめてから上げる判断の方が、あとから説明がしやすくなります。委託元に状況を伝えるときも、区間ごとに何をしたかを話せると、協議が具体的になります。

区間ごとの担当を、引き取った側の言葉で置き換える

引き取って続ける立場でこの三区間を扱うときは、集める区間を「情報源を洗い出す」、確かめる区間を「今の環境で試す」、決める区間を「優先順位をつける」と、自分の言葉に置き換えておくと動きやすくなります。

この置き換えができていると、新しく加わったメンバーに引き継ぐときも、同じ三区間で説明できます。案件が変わっても、区間の名前は変わりません。

集める・確かめる・決めるを、保守の作業として並べる

三つの区間は、それぞれ目的が違います。集める区間は情報を絶やさないこと、確かめる区間は今のアプリケーションに当てはめて考えること、決める区間は優先順位をつけて委託元に説明できる形にすることです。区間ごとにすることを表にすると、次に何をすればよいかが分かりやすくなります。

区間	すること	この記事での位置づけ
集める	出荷後も継続して情報を収集する7	止まった部品を見つけたきっかけ
確かめる	収集した情報が今の環境で再現するかを確認する8	優先度を判断する材料を作る段階
決める	被害の大きさと起きやすさからリスクを分析する9	委託元と協議して進め方を決める段階

出典：IPA「脆弱性対処に向けた製品開発者向けガイド」（2026年3月）をもとに作成

5. 利用者からの声も情報源になる

問い合わせは、情報源として扱われる

利用者からの問い合わせも、脆弱性の情報源として扱われます¹⁰。保守を引き取った側からすると、問い合わせ対応は本来の作業の合間に挟まる別の仕事に見えるかもしれません。けれど、ガイドが示す枠組みでは、問い合わせも集める区間の一部に位置づけられています。

利用者から届く言葉は、動作の不具合として書かれていることが多く、脆弱性という言葉では届きません。届いた言葉を、集める・確かめる・決めるという枠組みに置き直す作業が、引き取った側の役割になります。

声を情報源として扱うと、確認の抜けが減る

問い合わせを情報源として扱う体制が無いと、同じ内容の連絡が複数回届いても、それぞれ別の件として処理されてしまいます。積み上げてきた知見を活かせるのは、問い合わせを一か所にまとめて、集める区間の記録として残しておく場面です。

問い合わせを個別に片づけることよりも、まとめて記録に残すことの方が、次に似た連絡が来たときの確認を早くします。委託元と話すときも、記録があると経緯を説明しやすくなります。

この記事で見てきたような、保守の現場で起きていることを型として持っておくと、Rubyに限らず次の案件でも同じ考え方が使えます。案件によって前提は変わりますが、情報源を広く捉える姿勢は変わりません。

利用者の声を情報源として扱えるようになると、保守という仕事の見え方も変わります。直す仕事ではなく、情報を集め続ける仕事として捉え直すと、引き取った側としての役割がはっきりします。

6. 確認の自動化が薄い現場で

自動化の土台になる手法にも差がある

DevOpsやモデルベース開発は、作る側を除くと導入している企業は少なくなっています⁵。継続して確認する仕組みを自動化する土台が、現場によってはまだ整っていません。

一方でアジャイル開発は、一部を含めると全体の2〜4割程度の企業が導入しています⁶。開発の進め方が変わりつつある現場と、これまでどおりの現場が、はっきり分かれている状態です。

自動化された仕組みを新たに整えることよりも、今の現場がどちらに近いかを見極めることの方が、保守を引き取った直後には役立ちます。仕組みが薄い現場ほど、確認を人の手で丁寧に行う必要が出てきます。

確認の自動化が薄い現場での進め方

自動化の仕組みが薄い現場では、集める・確かめる・決めるという三区間を、人の手で一つずつ進めることになります。時間はかかりますが、順番を守っていれば、あとから振り返っても筋が通ります。

委託元と協議するときも、自動化されていない部分をどこまで人の手で補うかを、早い段階ですり合わせておくと、後の作業が進めやすくなります。

確認の自動化がどれくらい広がっているかを、2つの手法で比べると

DevOpsやモデルベース開発と、アジャイル開発。同じ「新しい進め方」でも、広がり方はそろっていません。導入の広がりと、保守案件で意味することを表に整理すると、次のようになります。

手法	導入の広がり	保守案件での意味
DevOps・モデルベース開発	作る側を除くと少ない5	自動で確かめる仕組みが薄い現場に入る場合がある
アジャイル開発（一部を含む）	全体の2〜4割程度6	確認の手順が定着している現場とそうでない現場が分かれる

出典：IPA「脆弱性対処に向けた製品開発者向けガイド」（2026年3月）をもとに作成

7. 外部のサービスへの不安も同じ形で出る

自社のコードだけでなく、外部のサービスも同じ形で確認する

外部のサービスについても、保守や運用に不安を抱える企業は多く見られます⁴。自社で書いたコードだけでなく、外部のサービスに任せている部分についても、同じように把握できていないという感覚が広がっています。

ここまで見てきた、集める・確かめる・決めるという順番は、自社のコードだけでなく、外部のサービスに対しても同じ形で使えます。窓口が違うだけで、確かめる対象があるという点は変わりません。

保守という仕事は、地味に見えて、把握する範囲を丁寧に広げ続ける仕事です。この考え方を持って案件を探すと、Rubyの保守に限らず、引き取って続ける立場の案件全体に応用できます。Remoguでは案件の90%以上がフルリモート可能です。まずは自分の経験に近い保守案件がどんな条件で並んでいるか、確かめてみましょう。

気になる案件があれば、まずは条件を見比べるところから始めてみませんか。

Rubyのバージョンが古いと、案件自体が難しくなりますか

バージョンの新旧だけで、保守案件を引き取れるかどうかが決まるわけではありません。まず必要になるのは、動いている依存と止まっている依存を分けて、確認する範囲を数えることです。

構成管理のツールを導入している企業自体、利用する側で約3割にとどまっています¹。整った状態で引き継げる案件は、むしろ少数派です。整っていない前提から始める案件だからこそ、集める・確かめる・決めるという順番が役立ちます。

SBOMが無いプロジェクトでは、何から手をつければよいですか

SBOMを導入している企業は1割未満です²。無いことを前提に、まず動いているものを一覧化する作業から始めます。SBOMを新たに作ることよりも、今動いている範囲を確かめることの方が、保守の初期には優先されます。

一覧化したあとで、更新が止まっている部品を見つけたら、その場で判断せず、継続して情報を集める区間に置きます⁷。順番を守ることが、遠回りに見えて堅実な進み方になります。

委託元に方針が無いとき、引き取った側から方針を決めてよいですか

OSSの利用方針や、OSPOの整備は進んでいない現場が珍しくありません³。ただし、この記事は引き取って続ける立場を前提にしています。方針そのものを決める役割ではなく、委託元と協議しながら、確認した内容を材料として渡す役割です。

外部のサービスについても、保守や運用に不安を抱える企業は多く見られます⁴。自社のコードと外部のサービス、どちらについても同じ順番で確認を進められることを伝えられると、協議がしやすくなります。

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

出典・参考情報

＊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「脆弱性対処に向けた製品開発者向けガイド」監視の継続（2026年3月）
＊8 IPA「脆弱性対処に向けた製品開発者向けガイド」確認の段（2026年3月）
＊9 IPA「脆弱性対処に向けた製品開発者向けガイド」優先順位（2026年3月）
＊10 IPA「脆弱性対処に向けた製品開発者向けガイド」情報源の広さ（2026年3月）