Vue.jsの案件は、真っさらな画面を最初から作るものばかりではありません。すでに動いている画面を少しずつ作り替えている途中で、エンジニアが加わるケースが目立ちます。案件情報の文面だけでは、どこまでの範囲を任されるのかがはっきりしないことがあります。読み解く手がかりを押さえておくと、参画前に任される範囲の見当をつけやすくなります。

1. 作り替えの途中に入るという前提

Vue.jsを使った案件の多くは、白紙の状態から画面を組み立てる仕事ではありません。すでに稼働している画面を少しずつ作り替えている途中の案件に、エンジニアが途中から加わる進み方が目立ちます。案件情報には「作り替え」「置き換え」といった一言しか書かれていないことも珍しくありません。

要件定義と設計は、いまもドキュメントを中心に行われています⁷。つまり、何を作るかという整理そのものは、ある程度文章として残っている場合が多いということです。まったく手がかりがない状態から始まるわけではありません。

一方で、部品として分けたりデータの持ち方を意識した設計に取り組む企業は、依然として少ない状況です⁴。特に開発を依頼する側の企業でこの傾向が強く見られます。文章の記録はあっても、実際の作りそのものが整理されているとは限らないということです。

この2つを合わせると、次のような姿が見えてきます。何を作るかという説明は残っているものの、どう作られているかという中身までは整理されていない案件が一定数あるということです。参画してから初めて気づく差は、ここから生まれます。

だからといって、任される範囲が広がること自体が不利になるわけではありません。整理されていない部分に触れるからこそ、任される作業の幅も広くなりやすいという見方もできます。大切なのは、その幅を参画前にある程度予測しておくことです。

Vue.jsを使った画面は、機能ごとの部品に分けて組み立てる考え方が基本になっています。しかし、部品として分ける設計に取り組む企業が少ない状況を踏まえると、画面の内部がこの考え方に沿って整理されているとは限りません。

つまり、案件情報に「Vue.js」という技術名が書かれていても、画面の内部がどれだけ整理された状態にあるかは、案件によって差があります。この差こそが、参画前に確かめておきたい部分です。

この記事では、案件情報の文面だけでは読み取りにくい範囲を、3つの手がかりから確かめる方法を整理します。見た目の決め方、作り替えの進み具合、元の作りの資料の有無という順に見ていきます。

2. 見た目まで任される

UI・UXに関わるデザイン担当が在籍している企業の割合は、日本では2割程度にとどまります¹。他国の企業では5割から7割程度に達しており、日本との開きは小さくありません¹。デザイン担当が社内にいない案件では、見た目の判断そのものが開発を担当する側に委ねられやすくなります。

あわせて、スマートフォンの利用率はパソコンを大きく上回っています。74.4%と46.8%という開きがあり、27.6ポイントの差になっています³。画面を確かめる場面では、パソコンでの見え方よりもスマートフォンでの見え方を優先して確認されることが増えます。

この2つの傾向が重なると、任される作業は「決められた見た目を画面に組み込む」だけでは終わりません。配置や余白、文字の大きさといった細部の判断まで、開発を担当する側の裁量に委ねられる場面が増えます。

デザイン担当が少ない案件ほど、画面の細かな調整まで開発を担当する側の判断に委ねられやすくなります。ボタンの大きさや余白の取り方といった、一見小さく見える部分の判断も含まれます。

参画する前に、こうした判断がどの程度自分の裁量に委ねられるのかを知っておくと、参画後にどこまで自分で決めてよいのか迷う場面を減らせます。

デザイン担当がいるかどうかで、確認する範囲が変わります

案件情報だけでは、デザイン担当が社内にいるかどうかまでは読み取れないことがほとんどです。面談の場で、見た目に関する判断を誰がどこまで行っているのかを尋ねておくと、参画後の作業の幅を見誤りにくくなります。

特に、スマートフォンでの見え方をどこまで細かく確認しているかを尋ねておくと、参画後に求められる確認作業の量を予測しやすくなります。パソコンでの見え方だけを基準にしていると、後から手戻りが増えることがあります。

確認する観点	デザイン担当がいる案件	デザイン担当が少ない案件
画面の見た目を決める人	デザイン担当が案として示す	開発を担当する側が形にしていく
表示を確認する機器	案件によって異なる	スマートフォンでの見え方を優先して確認されやすい
任される作業の範囲	示された見た目を画面に組み込む作業が中心	配置や見え方の判断まで含みやすい

図の作成：Remogu編集部。作り替え案件で参画しやすい段階を整理したもので、統計データではありません

3. 作り替えの進み具合を確かめる

構成管理のツールを導入している企業は、利用する側で約3割、作る側で約4割にとどまっています⁸。導入している企業がまだ半数に届いていない状況です。作り替えの進み具合を外から確かめる目印として、まずこの点を見ておく価値があります。

あわせて、DevOpsやモデルベース開発についても、開発を請け負う側の企業を除くと導入している企業は少ない状況です⁶。変更を自動で確かめる仕組みが整っていない案件では、進み具合の把握そのものに時間がかかりやすくなります。

こうしたツールが入っていない案件では、変更した内容を口頭やメッセージのやり取りで確認する場面が増えます。参画したばかりの時期は、この確認に想定より時間がかかることがあります。

ツールの有無は、案件情報の文面には表れにくい部分です。面談の場で、変更の記録をどのように残しているかを具体的に尋ねておくと、参画後の進め方を想像しやすくなります。

構成管理のツールが入っているかどうかで、作業の見え方が変わります

ツールが入っている案件では、これまでの変更の記録をたどって確認できるため、どこまで作り替えが進んでいるかをつかみやすくなります。入っていない案件では、担当者への聞き取りで補う場面が増え、進み具合の把握に時間がかかります。

引き継ぎの場面でも差が出ます。記録が残っている案件では、資料を読めば経緯をたどれますが、記録が薄い案件では、担当者に直接尋ねながら経緯を組み立てていく作業が必要になります。

確認する観点	ツールが入っている場合	入っていない場合
変更履歴の追い方	記録をたどって確認できる	聞き取りで補う場面が増える
確認の自動化	一部の確認が自動で行われる	手作業での確認が中心になる
引き継ぎにかかる時間	短く済むことが多い	説明を受ける時間が長くなりやすい

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」をもとに作成

4. 元の作りの資料があるか

要件定義と設計は、いまもドキュメントを中心に行われています⁷。この点だけを見ると、元の作りに関する資料は一定の割合で残っていると考えられます。参画前に確かめておきたいのは、資料が「何を作るか」の説明にとどまるのか、「どう作られているか」まで含むのかという違いです。

部品として分けたりデータの持ち方を意識した設計に取り組む企業は、依然として少ない状況です⁴。要件を書いた資料は残っていても、画面の内部がどう組み立てられているかまでは資料に反映されていない案件があるということです。

この差は、参画してすぐの作業量に直結します。資料が要件の説明にとどまる案件では、実際の画面を見ながら中身を確かめる作業から始めることになりやすく、資料が作りの整理まで含む案件では、その分の確認を省いて本題に取りかかれます。

面談の場では「要件をまとめた資料があるか」だけでなく、「画面の作りを整理した資料があるか」まで分けて尋ねておくと、参画後に想定と違う作業量に驚くことを避けやすくなります。

資料が薄い案件が任せる範囲が狭いとは限りません。むしろ、資料が薄い分だけ、画面を読み解いて整理し直す作業まで任される案件もあります。資料の有無は、良し悪しではなく、参画直後にどこから手をつけるかを左右する材料として捉えると扱いやすくなります。

資料の有無を尋ねるときは、資料そのものの存在だけでなく、いつ作られたものかもあわせて確認すると安心です。画面が繰り返し手直しされている案件では、古い資料と現在の画面がずれていることがあります。

資料が更新されていない場合でも、それだけで参画を避ける理由にはなりません。現在の画面を確認しながら、資料とのずれを整理していく作業として捉えると、任される内容をつかみやすくなります。

画面の作りが整理されていない案件では、既存のコードを読み解きながら、どこを直せば影響が少ないかを見極める作業も含まれます。資料と実際の画面の両方を照らし合わせる時間を、参画直後のスケジュールに織り込んでおくと安心です。

次の章では、この資料の有無とあわせて確認しておきたい、開発の進め方そのものの違いを見ていきます。

5. 自社主導かどうかで変わる

システム開発を自社主導で行っていると答えた企業は、日本では3割台にとどまります²。つまり、多くの案件では開発の進め方そのものを外部に委ねる形が前提になっているということです。

あわせて、外部のサービスについて、維持や運用に不安を抱える企業は多い状況です⁹。開発を外部に委ねる形が多いにもかかわらず、その先の運用まで安心して任せられているとは限らないということです。

自社主導かどうかは、参画後にどのくらいの頻度で判断を仰ぐ必要があるかにも関わります。自社主導の案件では、細かな判断もその場で確認しながら進めやすい一方、外部に委託している案件では、確認の手順そのものが決まっていることが多くなります。

どちらが進めやすいということではなく、進め方の性質が異なるということです。参画前に、日々のやり取りがどちらの形に近いのかを知っておくと、参画後の働き方をイメージしやすくなります。

システム開発を自社で進めているかどうかで、相談する相手が変わります

自社主導で進めている案件では、疑問点を社内の担当者に直接尋ねられる場面が多くなります。外部に委託している案件では、委託先を通じて確認する形になりやすく、回答までに時間がかかることがあります。参画前に、確認の窓口がどちらにあるかを尋ねておくと、日々のやり取りの想像がしやすくなります。

委託先を通じたやり取りが中心の案件でも、確認の窓口が明確に決まっていれば、大きな支障にはなりません。窓口がはっきりしているかどうかも、あわせて確認しておきたい点です。

確認する観点	自社主導で進めている場合	外部に委託している場合
質問への回答	社内の担当者から直接得られる	委託先を通じて確認することが多い
判断のスピード	その場で決まることがある	確認に時間がかかることがある
引き継ぐ相手	社内のメンバー	委託先の担当者

6. つなぐ側は決まっていることが多い

APIの活用や、標準的なデータの形式をそろえることは、開発を請け負う側の企業を中心に意識が高い状況です⁵。外部のサービスや他の仕組みとやり取りする方法そのものは、参画前の段階ですでに決まっている案件が多いということです。

あわせて、「レガシーシステムはない」と答えた割合は、日本が最も高くなっています¹⁰。古い仕組みに縛られていると考えている企業自体は少ないということですが、これは古い仕組みと接続する作業が発生しないという意味ではありません。

やり取りの方法が決まっているというのは、参画するエンジニアにとって良い面と、確認が必要な面の両方があります。決まった形式に沿って進められる点は取り組みやすい半面、その形式がなぜそう決まったのかまでは、資料に残っていないことがあります。

参画前には、外部とのやり取りの方法が「すでに決まっている」のか「これから決める」のかを確認しておくと安心です。すでに決まっている場合は、その形式に沿って作業を進めることになり、これから決める場合は、提案する場面も出てきます。

どちらの場合も、任される範囲は案件情報だけでは読み取りにくい部分です。面談の場で具体的に尋ねることが、参画後の見通しを立てる近道になります。

つなぎ先が決まっている案件では、外部のサービスとどのようにデータをやり取りするかという設計そのものを一から考える場面は少なくなります。決まった形式に沿って、画面側の実装を進める作業が中心になります。

一方で、つなぎ先が固定されているからこそ、その形式に合わせて画面の作りを調整する必要が出てくることもあります。案件情報だけでは分からない部分なので、面談で具体的に尋ねておくと安心です。

つなぎ先の形式を確認する際は、データの受け渡し方だけでなく、更新の頻度や確認の手順もあわせて尋ねておくと、日々の作業のイメージがつかみやすくなります。

ここまでの4つの章で見てきた手がかりを、次の章で参画前に確認する順番として整理します。

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

ここまでの内容を整理すると、参画前に確認しておきたい観点は4つに絞られます。見た目を誰が決めるか、作り替えの進み具合、元の作りの資料があるか、システム開発を自社主導で進めているかどうかです。

構成管理のツールが入っているかどうかは⁸、進み具合を確かめる手がかりであると同時に、要件定義と設計がドキュメントを中心に行われているかという点とも重なります⁷。この2つを面談の早い段階で尋ねておくと、後の3つの観点も答えやすくなります。

順番としては、まず見た目の決め方を尋ね、次に作り替えの進み具合とツールの有無を尋ね、続けて元の作りの資料の有無を確かめ、最後に開発を自社主導で進めているかどうかを尋ねる流れが整理しやすくなります。

この順番で尋ねておくと、参画してから「思っていたより任される範囲が広かった」「想定より確認に時間がかかる」といった食い違いを、面談の段階である程度減らせます。

面談で尋ねる際は、抽象的に範囲を尋ねるよりも、この記事で挙げた4つの観点をひとつずつ具体的に尋ねるほうが、答えを引き出しやすくなります。

図の作成：Remogu編集部。ここまでの内容を確認の順番として整理したもので、統計データではありません

案件情報だけで、どこまで任されるか分かりますか

案件情報の文面だけで判断するのは難しい場合があります。見た目の決め方や、元の作りの資料の有無といった点は、文面には表れにくい部分です。面談の場で具体的に尋ねることで、任される範囲の見当をつけやすくなります。

記録がない案件は避けたほうがよいですか

記録が薄い案件を避ける必要はありません。記録が薄い分だけ、画面を読み解いて整理し直す作業まで任されることもあり、任される範囲が広がる案件として捉えることもできます。参画前に、その分の作業量をどう見込むかを尋ねておくと安心です。

開発の進め方は、面談でどう尋ねればよいですか

この記事で挙げた4つの観点を、順番に尋ねてみるとよいでしょう。見た目を誰が決めるか、作り替えの進み具合、元の作りの資料の有無、システム開発を自社主導で進めているかどうかです。具体的に尋ねることで、参画後の作業の幅を想像しやすくなります。

Vue.jsの経験がまだ少ない場合でも、作り替えの案件に参画できますか

経験がまだ少ない場合でも、参画できる案件はあります。見た目の判断や資料の有無、開発の進め方といった観点を面談で確認し、自分が任される範囲を具体的にイメージできれば、経験の量だけで判断する必要はありません。

図の作成：Remogu編集部。想定される進み方を整理したもので、統計データではありません

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

出典・参考情報

＊1 総務省「令和7年版 情報通信白書（デジタル活用の動向）」設計する人の不在（2025年7月・2026年8月確認）
＊2 総務省「令和7年版 情報通信白書（デジタル活用の動向）」内製の実際（2025年7月・2026年8月確認）
＊3 総務省「令和7年版 情報通信白書（デジタル活用の動向）」使う道具の偏り（2025年7月・2026年8月確認）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」境界の不在（2025年4月・2026年8月確認）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」つなぎ目の意識（2025年4月・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「DX動向2025」古い仕組みの見え方（2025年6月・2026年8月確認）