Nuxtの案件は、ゼロから画面を組み立てる仕事として紹介されることがあります。参画してみると、すでに動いている画面を少しずつ置き換えていく途中から加わる案件だったという場合が目立ちます。置き換える範囲と残す範囲の境目は、案件ごとに決め方が違います。この記事では、その境目がどこで詰まりやすいかを、公開されている調査をもとに整理します。

1. 途中から入る形が多い理由

半数程度の企業がレガシーを抱えたままの状況

ユーザー企業の半数程度は、いまもレガシーシステムを抱えています¹。ゼロから新しい仕組みを組み立てる案件よりも、すでに稼働している画面や機能を少しずつ置き換えていく案件のほうが、実際には数多く生まれています。

レガシーという言葉は、古い技術という意味だけではありません。長く使われてきたことで、担当者の異動や引き継ぎを経て、なぜその作りになっているのかという経緯が薄れている状態を指すことが多くなります。

Nuxtの案件を紹介されたときに感じる「ゼロから作る自由度」よりも、実際に問われるのは「すでにある仕組みとどう折り合いをつけるか」という調整力です。この違いを最初に押さえておくと、参画後の戸惑いを減らせます。

境目があいまいなまま参画すると、思っていた作業の範囲と実際に求められる範囲がずれ、責任の所在で戸惑う場面が出てきます。この記事で扱う観点を先に押さえておくと、参画前の面談で確認したい内容がはっきりします。

要件定義と設計がドキュメント中心で進む理由

要件定義と設計は、いまもドキュメントを中心に行われています⁶。仕様が会話やチャットのやり取りに散らばっている案件もあり、確認したい内容がどの資料に書かれているかを探す作業自体が発生します。

ドキュメントが中心という状態は、悪いことではありません。ただし、そのドキュメントが最新の状態を反映しているとは限らず、画面の実装が先に変わっていて資料が追いついていない場合があります。

資料と実装がずれている案件では、画面を見ながら仕様を推測する作業が発生します。この推測にかかる時間は、参画前の段階では見えにくく、稼働してから初めて分かる負担になりやすい部分です。

推測にかかる時間をあらかじめ見込んでおくと、スケジュールへの影響を小さくできます。逆に、推測の作業自体が経験の見せどころになる場合もあり、負担と機会は表裏一体です。

だからこそ、参画の初期段階で最新のドキュメントがどこにあるかを確かめる作業は、後工程の手戻りを防ぐ土台になります。次の章では、この境目がなぜ設計として決まっていないのかを見ていきます。

2. 境目が設計として決まっていない

モジュール性を意識した設計に取り組む企業は少数派

モジュール性やデータモデルを意識した設計に取り組む企業は、利用する側を中心にいまも少数にとどまっています²。画面や機能をどの単位で区切るかという考え方自体が、組織の中で共有されていない状態です。

区切り方が決まっていないと、Nuxtの案件で「ここからここまでを置き換える」という線引きが、担当者の感覚に左右されやすくなります。同じ案件の中でも、聞く相手によって答えが変わることがあります。

線引きが感覚に左右される状態は、途中から入る側にとって不利なだけではありません。区切り方の提案を自分から示すことで、あいまいだった範囲を明文化する役割を担える場面でもあります。

境目の把握と技術情報の管理を、2つの観点で比べる

下の表は、設計の単位をどう区切るかという観点と、技術情報をどう管理しているかという観点について、現状としてよく見られる状態と、Nuxtの案件で確認しておきたいことを並べたものです。表を先に眺めてから、技術情報の収集について詳しく見ていきます。

観点	現状としてよく見られる状態	案件で確認しておきたいこと
設計の単位	モジュール性やデータモデルを意識した設計に取り組む企業は、利用する側を中心に少数にとどまっています2	置き換える範囲がどの単位で区切られているか
技術情報の管理	技術情報の収集は体系的な仕組みを持たず、個人の判断に委ねられがちです10	過去の決定の経緯がどこに残っているか

技術情報の収集が個人の判断に委ねられている

技術情報の収集は、体系的な仕組みを持たない状態で行われています¹⁰。誰が何を根拠にその技術を選んだのかという記録が、個人の中にしか残っていない案件があります。

Nuxtに関わる案件でも同じことが起こります。以前の担当者がなぜその構成にしたのかを知る手がかりが少ないまま、置き換えの範囲を決めなければならない場面が出てきます。

手がかりが少ない状態を補うには、現在の画面から逆にたどって仕様を書き起こす作業が有効です。時間はかかりますが、書き起こした内容そのものが次の担当者への引き継ぎ資料にもなります。

境目が設計として決まっていない状態は、組織としての情報整備が追いついていないことの表れです。次の章では、その画面の方針を誰が決めているのかを見ていきます。

図の作成：Remogu編集部。モジュール性を意識した設計への取り組み状況を整理したもので、統計データではありません

3. 画面の方針を決める人がいない

UI・UXに関わるデザイナーの在籍が少ない

UI・UXに関わるデザイナーが在籍している企業の割合は、日本で20.8%にとどまり、他国では約55%から70%に達しています⁵。画面の見え方や使い勝手を専門に検討する役割を、社内に置いていない企業がうかがえます。

この差は、Nuxtの案件で「画面の方針を誰が最終的に決めるのか」が曖昧になりやすい背景の一つです。エンジニアが実装しながら見た目の判断まで担うことになる場面が出てきます。

見た目の判断まで担うことは、負担であると同時に、裁量が広がる場面でもあります。決める人がいないなら、根拠のある選択肢を示して合意を取り付けるという進め方が、双方にとって現実的です。

デザイナーの在籍割合を、日本と他国で比べる

下の表は、UI・UXに関わるデザイナーが在籍している企業の割合を、日本と他国とで比べたものです。数字だけを見ると差は大きく見えますが、実際の案件では、この役割の空白をエンジニア側が引き受けることになる点が重要です。

項目	日本企業	他国企業
UI・UXに関わるデザイナーが在籍している割合	20.8%5	約55%〜70%5

品質を最優先にする企業の判断基準

ユーザー企業は、品質を最も優先する事項として捉えています⁹。動作の正しさや安定性が優先される場面が多く、画面のデザインに関する判断が後回しになりやすい構造があります。

だからこそ、Nuxtの案件で画面の方針を尋ねられたときに「決まっていない」と返ってくることは、珍しいことではありません。決まっていないことを前提に、確認する順番を自分で組み立てる姿勢が求められます。

確認する順番をあらかじめ用意しておくと、担当者が変わっても同じ質問を繰り返さずに済みます。参画初期のやり取りが少ない段階でこそ、この準備が効いてきます。

画面の方針を決める人がいない状況は、裁量が大きいという見方もできます。次の章では、この状況の中で置き換える範囲と残す範囲をどう分けるかを整理します。

出典：令和7年版情報通信白書（総務省）をもとに作成

4. 置き換える範囲と残す範囲を分ける

ノーコードやローコードを取り入れる動き

ノーコードやローコードは、一部での利用を含めると全体の約4割の企業が取り入れています³。画面の一部を簡易な仕組みに任せ、残りをNuxtのようなフレームワークで組み立てるという分担が、現実の選択肢になっています。

この分担を踏まえると、置き換える範囲を考えるときの基準は「技術的にできるかどうか」だけではありません。どの画面を作り込む価値があり、どの画面を簡易な仕組みに任せてよいのかという線引きが先に必要です。

作り込む価値がある画面とは、利用者との接点が多く、細かな挙動の違いが業務に影響する画面です。逆に、社内の一部だけが使う定型的な画面は、簡易な仕組みに任せても支障が出にくい部分です。

下の図のとおり、残す範囲・つなぐ範囲・置き換える範囲という3つに分けて考えると、境目の話がしやすくなります。つなぐ範囲を挟むことで、残す部分に手を入れずに置き換えを進められる場合があります。

図の作成：Remogu編集部。置き換える範囲の考え方を整理したもので、統計データではありません

クラウドやAPIの導入は作る側を中心に進む

クラウドやAPIの導入は、作る側の企業を中心に比較的進んでいます⁷。既存の仕組みをAPI越しに呼び出す形にできれば、内部の作りに深く踏み込まずに新しい画面をつなげられます。

つなぐ範囲を厚くできるかどうかは、既存システムがAPIを外に出せる作りになっているかに左右されます。API化が進んでいない部分は、残す範囲として切り分けたほうが、期間内に収まりやすくなります。

API化されていない部分を無理に置き換える範囲へ含めると、想定していなかった調整が後半に集中しやすくなります。範囲を決める段階で、この見極めを先に済ませておく価値があります。

置き換える範囲を広げるより、つなぐ範囲を丁寧に設計するほうが、途中から加わる案件では成果につながりやすいと言えます。次の章では、データの側の整備がどこまで進んでいるかを見ていきます。

5. データの側の整備が追いついていない

データ利活用の方針が定まっていない

データ利活用に関する方針を明確にしている企業は少なく、対応の遅れが目立ちます⁴。画面を新しくしても、その裏側にあるデータの持ち方や更新の仕組みが整理されていなければ、置き換えの効果は限られたものになります。

Nuxtの画面側から見ると、表示するデータの粒度や更新タイミングが定まっていないという形で、この遅れが表面化します。デザインを整えるより先に、データの出どころを確認する作業が発生します。

データの出どころが複数のシステムにまたがっている場合、どちらの値を正とするかという判断が必要になります。この判断が画面の設計より前に決まっていないと、置き換え作業が途中で止まりやすくなります。

データと設計、2つの遅れを並べて確認する

下の表は、データ利活用の方針と、モジュール性を意識した設計という2つの観点について、現状としてよく見られる状態と、案件で確認しておきたいことを並べたものです。どちらも、画面を作る前の土台に関わる部分です。

観点	現状としてよく見られる状態	案件で確認しておきたいこと
データ利活用の方針	方針を明確にしている企業は少なく、対応の遅れが目立ちます4	表示するデータの定義がどこにあるか
設計の単位	モジュール性やデータモデルを意識した設計に取り組む企業は少数にとどまっています2	新しい画面がどのデータに依存しているか

2つの遅れが重なっている案件では、画面の実装よりも先に、データの持ち方を確認する時間を確保したほうが、後工程の手戻りを防げます。

確認する相手は、一人に決まっているとは限りません。データの管理者と画面の担当者が分かれている組織では、両方に話を聞く必要が出てきます。

話を聞く相手が複数にまたがるときは、誰にどの質問をしたかを記録しておくと、後から見返したときに答えの食い違いに気づきやすくなります。小さな手間ですが、効果は積み重なります。

データの整備状況を早い段階で把握しておくと、置き換えの範囲を現実的な大きさに調整しやすくなります。次の章では、外部のサービスとの境目について見ていきます。

6. 外部のサービスとの境目

外部サービスや製品を活用する企業の広がり

外部のサービスや製品は、一部での利用を含めて6割強の企業が活用しています⁸。決済や認証、通知といった機能を自前で作らず、外部のサービスに任せる判断は、すでに珍しいものではありません。

Nuxtの案件でも、画面の裏側で外部サービスと連携している部分に出会う場面が増えています。この部分は、既存システムの内部構造を知らなくても、外部サービス側の仕様を確認すれば対応できることがあります。

外部サービス側の仕様書が公開されている場合は、既存システムの古い資料を探すより早く、正確な情報にたどり着けることがあります。まず外部サービス側から手をつける進め方も選択肢になります。

複数の外部サービスが組み合わさっている案件では、どのサービスがどの機能を担っているかを一覧にしておくと、後から関わる人にも状況が伝わりやすくなります。

ただし、外部サービスとの連携部分が「残す範囲」に含まれているのか「つなぐ範囲」に含まれているのかは、案件によって扱いが分かれます。最初に確認しておかないと、途中で担当の境目があいまいになります。

クラウドやAPIの導入が進む領域との重なり

クラウドやAPIの導入は、作る側の企業を中心に比較的進んでいます⁷。外部サービスとの連携がAPI経由で行われている場合、その入り口を押さえておけば、内部の実装に深入りせずに済む場面が多くなります。

一方で、外部サービスとの連携がまだAPI化されていない部分では、画面側の実装だけで完結しない調整が発生します。関係する部署や担当者を早めに確認しておくことが助けになります。

調整が発生しやすい部分をあらかじめ洗い出しておけば、見積もりの段階で余裕を持たせる根拠になります。曖昧なまま進めるより、範囲を狭くしてでも先に確定させたほうが結果的に早く進みます。

外部サービスとの境目を先に洗い出しておくと、置き換える範囲の見積もりが立てやすくなります。次の章では、これまで見てきた境目を、参画前にどの順番で確かめればよいかを整理します。

7. 引き継ぐ範囲を書面で確かめる順番

書面で確かめておきたい4つの順番

要件定義と設計がドキュメントを中心に行われている以上⁶、口頭でのやり取りだけに頼らず、書面で残しておくことが、参画後の認識のずれを防ぐ土台になります。

下の図のとおり、確認する順番を「現状の画面の棚卸し」「置き換える範囲の合意」「外部接続の確認」「書面での取り交わし」の4段階に分けると、抜け漏れが減ります。

図の作成：Remogu編集部。引き継ぐ範囲を確かめる進め方を整理したもので、統計データではありません

品質への優先度を踏まえた確認の仕方

ユーザー企業は品質を最優先事項として捉えています⁹。確認の順番を組み立てるときも、見た目の調整より先に、動作が壊れないための境目を固める判断が優先されます。

この優先度を踏まえると、書面で確かめる内容は、デザインの好みではなく、どこまで触ってよいかという範囲そのものになります。範囲が明確であれば、品質を保ちながら置き換えを進めやすくなります。

ここまで見てきた境目は、いずれも参画してから初めて分かるものではなく、参画前の確認で見えてくるものです。自分の経験がどの部分で活きるかを、事前に照らし合わせておくことができます。

書面での確認を面倒に感じるかもしれませんが、確認した内容そのものが、次の案件を選ぶときの判断材料としても残ります。同じ質問を案件ごとに繰り返せば、比べるための基準ができていきます。

置き換える範囲はいつ確認すればよいですか

参画が決まる前の段階で、書面に残る形で確認しておくと安心です。要件定義と設計がドキュメントを中心に行われている案件では⁶、後から資料を探す手間も減らせます。

画面の方針を決める担当者がクライアント側にいない場合はどうすればよいですか

UI・UXに関わるデザイナーが在籍していない企業も一定数あります⁵。方針が固まっていないことを前提に、確認したい項目をこちらから提示し、合意を得る進め方が現実的です。

外部サービスとの境目はどこまで確認すればよいですか

外部のサービスや製品を活用する企業は6割強にのぼります⁸。連携部分が残す範囲かつなぐ範囲かを最初に確認し、担当の境目を書面に残しておくと、後からの認識のずれを防げます。

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

出典・参考情報

＊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 総務省「令和7年版 情報通信白書（デジタル活用の動向）」設計する人の不在（2025年7月・2026年8月確認）
＊6 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月・2026年8月確認）
＊7 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」進んでいる領域（2025年4月・2026年8月確認）
＊8 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」利用の広さ（2025年4月・2026年8月確認）
＊9 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」評価の軸（2025年4月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月・2026年8月確認）