案件が動き出すとき、最初に渡される資料に、処理の全体像がひと通り揃っているとは限りません。データ基盤の案件で最初に発生する作業は、コードを書くことではなく、どこにも書かれていない前提を資料や関係者から拾い集めて言葉に直す作業です。この工程で何を掴めるかによって、後工程の見積もりや報酬の協議の進め方も変わってきます。本記事では、読み解きの工程がなぜ発生するのか、そして読み解いた結果を何に残せば次の担当者につながるのかを整理します。

1. データ基盤の案件は、読み解きから始まります

案件の入口にあるのは、実装ではなく読み解き

データ基盤の案件で最初に着手するのは、テーブル設計やETLの実装そのものではありません。既存の処理がどのような前提で組まれているのか、担当者が入れ替わる中で追いにくくなった経緯を、資料と会話から拾い直す作業が先に来ます。ドキュメントが整っている案件と、整っていない案件とでは、参画してから最初の数週間にかかる負荷が大きく変わります。

具体的には、設定ファイルに残る値がなぜその数値になっているのか、ログに現れる処理の順序がどの業務フローと対応しているのか、テーブル間の関連が命名規則だけでは追いきれない箇所はどこかといった点を、ひとつずつ確かめていく作業になります。設計書が更新されないまま運用が続いた期間が長いほど、コードと実態の間にずれが生まれやすく、読み解きにかける時間もそれに応じて長くなります。

情報処理推進機構が2026年3月10日に公表した2025年度ソフトウェア動向調査は、2026年2月9日時点の回答結果362件を集計したものです¹。この調査には自由記述の設問があり、その主要な意見が別の資料にまとめられています。そこに並ぶ声は、読み解きの工程が個別の案件だけの事情ではないことを確かめる手がかりになります。

読み解きの工程は、資料と向き合いながら仮説を立て、関係者への確認で裏付けていく仕事です。常駐して画面の前で待つ必要は薄く、リモートでも進めやすい性質を持っています。Remoguに掲載されている案件は、90%以上がフルリモート可能です⁸。この読み解きが発生する背景を、次の章では業界全体の声から確かめます。

図の作成：Remogu編集部。読み解きが進む一般的な流れを整理したもので、統計データではありません

2. 書かれていないのは、その現場だけの問題ではありません

現場の外でも、同じ内容の声が挙がっています

ドキュメントが整っていない状態に行き当たると、その現場の運用が甘いように見えてしまうことがあります。ただし、同じ調査の自由記述では、社会全体の共通課題として、技術や業務の属人化、ナレッジ継承の難しさ、特定個人に依存した運用体制の課題という声が挙げられています²。読み解きが必要になる場面は、個々の案件の不備ではなく、業界に広く共有された状況の一部として起きています。

属人化という言葉は、担当者個人を責める文脈で使われがちですが、実際には運用の仕組みそのものが特定の人に頼らざるを得ない形で組み上がってしまった結果であることも想定されます。日々の業務に追われる中でドキュメント化の優先度が後回しになり、気づいたときには経緯を知る人が限られていたという流れは、業種を問わず起きやすい構図です。読み解きの工程は、この構図を前提に組み立てる必要があります。

表1に、この自由記述で挙がっている声を整理しました。いずれも件数や割合ではなく、調査に寄せられた自由記述の要約であることに注意してください。

表1：共通課題として挙がっている声

担当者の入れ替わりが続く現場では、次の3つのテーマが繰り返し挙げられています。読み解きの工程は、こうした構造の上に発生する作業だと捉えると、負荷の見立てがしやすくなります。

テーマ	挙がっている声
技術・業務の属人化	特定の担当者しか把握していない処理や判断基準が残っているという声が挙げられています
ナレッジ継承の難しさ	担当者が入れ替わる際に、経緯や理由が引き継がれにくいという声が挙げられています
特定個人に依存した運用体制	運用そのものが特定の個人の対応に支えられているという声が挙げられています

この3つは、いずれも「誰かが分かっていれば回る」状態が続いた結果として起きる声です。読み解きの工程は、この状態を外部から解消していく仕事とも言えます。標準の型があれば負担は減るのか、次の章ではこの点についての声を確かめます。

外部から案件に参画する担当者にとって、この構造は不利なだけではありません。属人化した状態を言葉に直す作業そのものが、参画の初期段階で価値を示しやすい仕事でもあります。読み解いた内容を分かりやすい形で示せれば、実装に着手する前の段階でクライアントからの信頼を得やすくなります。

3. 標準が欲しいという声がある、という前提

型が無いことが、読み解きの負担を増やしている

行政機関への期待として、開発手法やプロジェクト管理の標準モデルを示してほしいという声や、システム開発・運用の標準化、官民で活用できるベストプラクティス共有への期待が挙げられています⁴。裏を返せば、現時点で組織を横断した共通の型が十分に行き渡っているとは言えない状況が背景にあるということです。

データ基盤の案件で読み解きに時間がかかるのは、担当者の力量の問題というより、参照できる標準が組織ごとに異なるためです。ある現場で通用した命名規則や設計の型が、別の現場ではそのまま通用しないことは珍しくありません。標準化やベストプラクティス共有への期待が挙がっているのは、この読み替えの負担を裏づける材料でもあります。

組織の外からデータ基盤の案件に参画する場合、最初に確かめるべきは正解となる型があるかどうかではなく、その組織が独自に育ててきた型がどこにあるのかという点です。命名規則、更新のタイミング、権限の分け方といった判断は、資料に明文化されていなくても、過去の設計の積み重ねとして現場に残っています。標準が無いことを前提に、現場固有の型を読み取る姿勢のほうが、進め方としては現実的です。

出典：情報処理推進機構「2025年度ソフトウェア動向調査」の自由記述を整理して作成（数値ではありません）

4. 機能は動いているのに、更新が必要になる理由

サポート期限の切れ目が、更新の引き金になる

レガシーシステムに関する自由記述では、OSやハードウェアのサポート切れによるシステム更新コストや、機能は十分でもサポート切れなどによりシステム更新が必要になることが挙げられています³。動いている範囲では現場が困っていない状態でも、更新を避けられない場面があるということです。「レガシーは書き直すべき」という前提ではなく、こうした期限の存在を確かめるところから、読み解きが始まります。

この構図を掴めていないと、なぜ今この案件が動き出したのかという背景を取り違えてしまいます。機能の不満より、期限という外側の事情が更新の理由になっている案件も想定しておく必要があります。

期限を起点にした更新では、現行の処理をそのまま置き換えるのか、この機会に構成を見直すのかという判断が別途発生します。読み解きの段階でこの判断材料まで揃えておけば、実装に入ってから方針が二転三転する事態を避けやすくなります。逆に、期限だけを理由に急いで着手すると、既存の前提を確かめないまま置き換えてしまい、別の不具合を生む余地が残ります。

更新の期限が近づいている案件ほど、着手までの猶予が短く見積もられがちです。しかし、猶予が短いことと、読み解きを省略してよいことは別の話です。期限が迫っている案件だからこそ、最初の読み解きにかける時間を惜しまない方が、結果として全体の作業期間を短くできることがあります。

表2：更新のきっかけになりやすい事情

きっかけ	内容
OSのサポート終了	稼働しているOSの保守期限が切れることが、更新のきっかけになるという声が挙げられています
ハードウェアのサポート終了	機能面では困っていない場合でも、ハードウェアの保守期限切れが更新の背景になるという声が挙げられています

出典：情報処理推進機構「2025年度ソフトウェア動向調査」の自由記述をもとに作成

期限が引き金になっている場合、書き換えの範囲は機能の良し悪しでは決まりません。何がいつまで動く保証があるのかを読み解いておくと、次に残す記録の内容も自然と定まってきます。

5. 読み解いた結果を、誰に残すのか

残す相手が定まらないと、読み解きは繰り返される

読み解いた内容は、誰かに引き継がれて初めて価値が続きます。ところが、人材育成・スキル継承に関する声として、人材育成が追いついていないことも挙げられており⁵、読み解いた結果を託す相手そのものが定まっていない案件も想定しておく必要があります。この点は特定の世代の話ではなく、引き継ぎの受け皿がまだ整っていない組織の状態として捉えるとよいです。

受け皿が定まっていない場合は、次の担当者の顔を思い浮かべるより先に、形として残すことを優先します。誰が読んでも経緯を追えるように書いておけば、担当者が誰になっても読み解きをゼロからやり直さずに済みます。

記録を残す際は、結論だけでなく判断の過程を書き添えることが要点です。「この設計にした」という事実だけでは、状況が変わったときに見直してよい部分なのか、変えてはいけない前提なのかが後から読んでも分かりません。当時どのような制約があり、何を優先してその形に落ち着いたのかまで書いておくと、読み手が状況に応じて判断し直せる記録になります。

表3：読み解いた内容を残す形

残す形	内容
手順書	操作の順番だけでなく、なぜその順番になったのかという判断の理由まで書き添えます
構成図・関連図	処理やテーブルのつながりを図にして、資料を読む前の状態でも全体を把握できるようにします
用語集・命名の対応表	現場ごとに異なる呼び方や略称を対応表にして、読み替えの手間を減らします

形として残す作業は、実装の作業に比べて地味に見えます。ただし、次の担当者が同じ読み解きを繰り返さずに済むかどうかは、ここにかかっています。この記録を残す作業には、費用やルールの制約も関わってきます。

記録を残す媒体は、新しい仕組みを導入して統一するとは限りません。すでに現場で使われているファイル形式やツールに合わせて残す方が、次の担当者にとって参照しやすい場合もあります。記録の形式を揃えることよりも、判断の理由まで含めて残っているかどうかを優先する方が、読み解きの積み重ねとしては効果が続きます。

6. 費用とルールの制約も読み解きに入ります

費用の制約は、構成の選び方に影響する

コスト・海外依存に関する声として、円安により海外ソフトウェアのライセンス費用が高騰していることや、海外IT企業への依存によるコスト問題が挙げられています⁷。今後の為替の見通しを語る場ではありませんが、既存の構成が海外製の製品に依存しているほど、費用の変動が構成の見直しに直結しやすいという背景は押さえておく価値があります。

読み解きの段階でこの背景を把握しておくと、既存の構成をそのまま踏襲する提案と、費用の負担を抑える形に組み替える提案とを、クライアントに並べて示せるようになります。どちらを選ぶかはクライアントの判断ですが、選択肢を示せること自体が、読み解きに時間をかけた成果として評価されやすい部分です。

ルールの制約は、扱えるデータの範囲を決める

AI活用・倫理に関する共通課題の声として、組織内でのAI利用ルール整備の必要性や、生成AI利用の著作権やセキュリティリスクの懸念が挙げられています⁶。ルールが整っていない組織では、生成AIをどこまで読み解きの補助に使ってよいのか、参画前にクライアントと確認しておく手間が発生します。費用の制約とルールの制約は、性質は違っても、読み解きの進め方を狭めるという点では同じ働き方をします。

特にデータを扱う案件では、社外に出してよい情報の範囲や、生成AIに読み込ませてよい資料の範囲があらかじめ線引きされていないと、読み解きの効率を上げる手段そのものが選びにくくなります。ルールが整備される前の組織に参画する場合は、判断に迷う場面を早めに洗い出し、都度クライアントと協議しながら進める形が現実的です。

出典：情報処理推進機構「2025年度ソフトウェア動向調査」の自由記述をもとに作成

費用とルールの制約は、読み解きが終わったあとに出てくる話ではなく、読み解きの最中から前提として組み込んでおくべき事情です。次の章では、ここまでの内容をよくある疑問の形で整理します。

制約を先に把握しておくと、読み解いた結果をどこまで実装に反映できるのかという見通しも立てやすくなります。費用の上限やルールの範囲を確認しないまま設計を進めてしまうと、後になって前提から見直す手戻りが発生しやすくなるため、早い段階でクライアントとすり合わせておく価値があります。

7. よくある質問

データ基盤の案件は、ETLの実装だけを担当する仕事ですか

実装だけで完結する案件は限られています。既存の処理がどのような前提で組まれているのかを読み解き、関係者への確認や実データでの検証を経て、初めて実装に着手できる案件がほとんどです。参画前の段階で、読み解きに充てる期間がどの程度見込まれているのかを確認しておくと、進め方の見立てがしやすくなります。ETLの設計そのものは、この読み解きの結果を反映する後工程という位置づけになります。

仕様が分からない状態から、何を最初に確認すればよいですか

まず、既存の資料がどこまで残っているのかを確認します。資料が薄い場合は、聞き取りできる関係者が誰なのかを早い段階で把握しておくことが有効です。資料と関係者の両方が乏しい案件では、実データを動かして挙動から前提を確かめる工程に、これまで以上の時間を見込んでおく必要があります。

確認の順番としては、まず全体の構成を大まかに把握し、その後で個別のテーブルや処理に絞り込んでいく進め方が負担を抑えやすくなります。最初から細部まで読み解こうとすると、全体像を掴む前に時間を使い切ってしまい、関係者への確認も的を絞れないまま進んでしまいます。

見積もりや期日の取り決めが不安なときは、どう考えればよいですか

読み解きに必要な期間は、資料の整い方によって大きく変わります。参画前に、既存資料の有無や過去の担当者に確認できる範囲をクライアントと共有し、読み解きの期間を見積もりの中に別枠として組み込めるかどうかを協議しておくと、後工程での行き違いを避けやすくなります。読み解きの途中で分かったことを都度共有しておけば、期日の調整が必要になった場合にも、早い段階でクライアントと相談しやすくなります。

読み解いた内容は、誰にどう共有すればよいですか

引き継ぎ先が明確な案件であれば、その担当者が普段参照する形式に合わせて残します。引き継ぎ先がまだ定まっていない案件では、特定の個人を想定せず、手順書・構成図・用語集のように形を分けて残しておくと、後から関わる人が必要な部分だけを拾い読みできます。共有の頻度についても、読み解きが一段落するたびに区切って渡す方が、案件の終盤にまとめて渡すよりも、内容の抜け漏れに気づきやすくなります。

共有の場では、資料を渡すだけでなく、口頭での補足も添える方が伝わりやすくなります。文字だけでは伝わりにくい背景や優先度の判断は、短い打ち合わせの中で触れておくと、資料を読む側の理解が早まります。

読み解きの工程は、記録に残らない前提を言葉に直す仕事であり、実装そのものと同じくらい価値のある工程です。案件に参画する際は、読み解きに充てられる期間や、成果物として何を残すのかを、事前にクライアントと協議しておくと、後工程の負担を軽くできます。

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

出典・参考情報

＊1 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」単純集計グラフ（2026年3月）
＊2 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」自由記述コメントサマリー（2026年3月）
＊3 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」自由記述コメントサマリー（2026年3月）
＊4 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」自由記述コメントサマリー（2026年3月）
＊5 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」自由記述コメントサマリー（2026年3月）
＊6 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」自由記述コメントサマリー（2026年3月）
＊7 独立行政法人情報処理推進機構「2025年度ソフトウェア動向調査」自由記述コメントサマリー（2026年3月）
＊8 Remoguサイト公開情報（案件の90%以上がフルリモート可能）