システムエンジニアという肩書きだけでは、案件でどこからどこまでを担当するのかが分かりません。同じ肩書きの案件でも、何を作るかを決める工程を任される場合もあれば、決まった仕様を動くものに組み立てる工程だけを任される場合もあります。担当する工程の位置によって、日々の判断の重さも中身も変わります。ここでは公的な調査データをもとに、受ける前に見分ける手がかりを整理します。

1. 担当する工程で変わるシステムエンジニア案件の中身

「何を作るか」と「どう動かすか」を分ける工程

システムエンジニアという言葉は、何を作るかを決める工程から、決まった仕様を実際に動くものへ組み立てる工程まで、幅広い範囲を指します。案件情報に「システムエンジニア」とだけ書かれていても、その一文だけで担当する範囲を判断することはできません。

開発の進め方には、要件を固めてから設計、実装、テストへと段階を追って進むやり方がいまも広く使われています¹。この進み方が前提になっている案件では、参画する時点がどの段階かによって、任される判断の重さが変わります。

要件を固める段階に近い案件ほど、何を作るかという判断そのものに関わります。逆に実装やテストに近い案件では、すでに固まった仕様をどう正しく動かすかという判断が中心になります。どちらが重い軽いという話ではなく、性質が違う判断だということです。

図の作成：Remogu編集部。工程と役割の関係を整理したもので、統計データではありません

案件情報の文面だけでは判断できない理由

要件定義と設計の場面は、いまも文書を中心にして進められています¹。会話や画面共有だけで仕様が固まるのではなく、要件定義書や設計書という文書に落とし込む作業自体が、工程の中心に位置づけられています。

文書を作る側に立つのか、文書をもとに組み立てる側に立つのかで、日々の作業の中身は大きく変わります。文書を作る側は関係者との調整や言葉の定義に時間を使い、組み立てる側は実装とその確認に時間を使います。

案件情報の職種名だけでこの違いを読み取るのは難しく、募集の文面にある担当工程の記載を具体的に確認することが、参画後の行き違いを防ぐ最初の手がかりになります。

参画前の面談では、要件を固める場面にどれだけ関わるのか、すでに固まった仕様をもとに進めるのかを、具体的な作業内容で尋ねる方が実態に近づきます。「システムエンジニア」という職種名だけでなく、実際に何を任されるのかを言葉にしてもらうことが手がかりになります。

同じ案件でも、参画する時期によって関わる工程が変わることもあります。案件の始まりに近い時期に参画するのか、すでに設計が固まった後に参画するのかで、求められる判断の中身は変わってきます。

工程のどの位置に立つ案件なのかをつかんでおけば、参画してから戸惑う場面を減らせます。次の章では、この工程が前から順に進む前提そのものを見ます。

2. 工程が前から順に進む前提

確定済みの内容と後戻りの難しさ

要件を固めてから設計、実装、テストへと段階を追って進む前提の案件では、前の工程で決まった内容をもとに次の工程が組み立てられます。前提が崩れると、後の工程すべてに影響が及びます。

前の工程で決めた内容を後から変えると、すでに組み立てた部分をやり直す必要が出ます。段階を追って進む前提の案件ほど、後戻りにかかる手間は大きくなります¹。

次の表は、工程ごとに主に決まる内容と、後から変える難しさを整理したものです。参画する工程が分かれば、後戻りの起きやすさも見えてきます。

工程	主に決まること	後から変える難しさ
要件定義	何を作るか、その範囲	高い。前提が変わり後の工程全体に影響する
設計	どう作るか、仕組みの組み立て方	中程度。実装のやり直しにつながりやすい
実装	決まった仕様を動くものにする	中程度。部分的な直しで済む場合が多い
テスト・運用	正しく動くかどうかの確認	低い。直しは限られた範囲で済むことが多い

開発の進め方の主流の流れと、担当の位置の関係を図に表します。段階を追って進む流れ自体は一本道になりやすく、担当する工程によって、前工程の内容にどれだけ依存するかが変わります。

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

一本道の流れに途中から関わる案件では、前の工程で決まった内容を前提として受け取ることになります。前提に疑問があっても、まずはその前提を確認するところから始めることになります。

決める人がいない案件で起きやすいこと

ところが、意思決定を担う責任者を置いていない案件は約半数に上ります¹。決める人がいなければ、前の工程で固まるはずの内容がいつまでも仮のままになります。

仮のままの内容の上に次の工程を組み立てることはできません。段階を追って進む前提そのものが、決める人の不在によって止まってしまう場面が出てきます。

経験の長さよりも、決める人がその案件にいるかどうかが、参画後の進めやすさを左右します。決める人が明確な案件と、そうでない案件とでは、同じ工程名でも実際の進み方が違います。

決める人がいない場合に具体的に何が起きるのか、次の章で見ていきます。

3. 決める人がいない場合に起きること

疑問が出た後、誰も決めない状態

意思決定を担う責任者を置いていない案件は約半数に上ります¹。責任者がいれば、疑問が出たときにその場で決められますが、いなければ疑問は宙に浮いたままになります。

状態	疑問が出たときの進み方	参画する側が受ける影響
決める人がいる場合	その場で決めて次に進む	疑問を抱えたまま作業を続けずに済む
決める人がいない場合	疑問が宙に浮いたまま止まる	自分の判断で仮に進めるか、待つかを迫られる

決める人の有無による進み方の違いを、図に並べます。決める人がいる場合は、疑問が出てから決めて次に進む流れが続きます。決める人がいない場合は、疑問が出た後、誰も決めずに先へ進めない状態が続きます。

図の作成：Remogu編集部。決める人の有無による進み方の違いを整理したもので、統計データではありません

参画する側から見ると、決める人がいない案件では、自分の判断で仮に進めるか、止まったまま次の指示を待つかの二択を迫られる場面が増えます。どちらも本来は避けたい状態です。

疑問が宙に浮いたまま作業を続けると、後になって前提が変わり、すでに進めた部分をやり直す場面につながります。早い段階で疑問を言葉にして渡すことが、後戻りを減らす手がかりになります。

役割や範囲があいまいな状態

役割分担や担当する範囲が不明確という課題は、企業が挙げる課題の中でも上位に位置づけられています²。決める人の不在と、役割の不明確さは、別の調査項目でありながら同じ現場で重なって現れやすい課題です。

役割の境目があいまいな案件では、任された範囲を超えて判断を求められる場面も出てきます。任された範囲を都度言葉にして確認しておくことが、あいまいさをそのままにしないための手がかりになります。

決める人がいるかどうかと、役割の範囲が言葉にされているかどうかは、案件情報の文面だけでは分かりにくい部分です。参画前の面談で、この2点を具体的に尋ねる価値があります。

次の章では、こうした進み方の前提とは別に、利用する企業が何を優先しているのかを見ていきます。

4. 品質が最優先という前提

速さよりも品質を優先する利用企業の姿勢

利用する側の企業は、システムの品質を最も優先する事項として捉えています¹。速く仕上げることよりも、正しく動き、壊れにくいことの方が優先されるという前提です。

品質を優先する前提のもとでは、確認や検証の工程は、削る対象にされにくいという特徴があります。参画する側にとっては、確認作業の丁寧さが問われる環境です。

速さよりも品質という優先順位は、進め方が段階を追って進む前提とも結びついています。前の工程の内容を確定させてから次に進むやり方は、品質を優先する考え方と相性が良いためです。

品質を優先する前提のもとでは、速さより正しさが先に問われます。参画する側は、根拠を示しながら進めることが求められます。

技術情報の収集が個人任せになりやすい理由

一方で、技術情報の収集は体系的な仕組みを持たず、個人に任されている企業が多いという課題もあります¹。品質を優先する姿勢と、新しい技術情報を追う仕組みの有無は、別の話です。

技術情報の収集が個人任せになっている現場では、新しい手法や道具を持ち込めるかどうかが、参画する側の経験や普段の情報収集に委ねられます。会社の仕組みに頼れない分、自分で確かめる姿勢が求められます。

品質を優先する姿勢を歓迎する現場は多くても、その品質を支える技術情報の更新は、現場ごとの差が大きい部分です。案件を選ぶときは、この2つを分けて捉える方が実態に近づきます。

技術情報の収集が個人任せの現場では、外部から参画する側が持ち込む情報が、現場の判断材料になる場面も出てきます。

内製化が進む現場では、この技術情報の扱いがさらに立ち位置に影響します。次の章で見ていきます。

5. 内製化が進む現場での立ち位置

内製化を進める企業は約半数

約半数の企業が開発の内製化を進めています¹。自社の担当者だけで開発を完結させる動きが、利用する側の半数近くまで広がっているということです。

内製化が進む現場では、外部から参画する側の立ち位置も変わります。すべてを任される案件ではなく、自社の担当者が担う部分と、外部に委ねる部分とを分けた案件が増えます。

次の表は、内製化を進める企業が挙げる課題と、そこで参画する側に問われやすいことを整理したものです。

内製化の課題	企業が挙げる内容	参画する側に問われやすいこと
人材の確保	担う人材が十分にそろっているとは限らない1	自社にない専門性を補う役割
新技術への対応	新しい技術を追う体制が整っているとは限らない1	新しい技術を持ち込み、伝える役割

内製化の程度は企業によって差があります。すべてを自社で担う企業もあれば、要となる部分だけを自社に残し、それ以外を外部に委ねる企業もあります。案件情報からこの程度を読み取るのは難しく、面談で具体的に尋ねる方が近道です。

内製化の課題は人材確保と新技術対応

内製化の課題として、人材の確保と新技術への対応を挙げる企業が多くなっています¹。内製化を進めたくても、担う人材が十分にそろっているとは限らず、新しい技術を追う体制が整っているとは限りません。

この2つの課題は、外部から参画する側にとって出番につながる部分でもあります。人材の確保が難しい部分を補う形や、新しい技術への対応を持ち込む形で、案件に関わる余地が生まれます。

内製化が進む現場ほど任せきりにはならない一方、自社だけでは補いきれない部分を明確に持っています。案件情報を読むときは、内製化の程度と、そこで空いている部分の両方を確かめる方が実態に近づきます。

続いて、内製化と並んでよく挙がる、古いシステムを抱える現場の話に移ります。

6. 古いシステムを抱える現場

レガシーシステムを抱える企業は半数程度

利用する側の企業の半数程度が、いまもレガシーシステムを抱えています¹。新しく作る案件だけでなく、すでにある古いシステムと付き合いながら進める案件も、同じくらいの割合であるということです。

古いシステムを抱える現場では、新しい仕組みを一から作るよりも、既存の仕組みを理解し、影響が及ぶ範囲を見極める判断が中心になります。真新しさよりも、既存の作りへの理解が問われます。

古いシステムに関わる案件では、動かしている仕組みの記録が十分に残っていない場合もあります。まず現状を把握するところから始まる案件もあれば、記録が整っていて把握しやすい案件もあり、案件ごとの差が大きい領域です。

古いシステムと新しい要望をどう両立させるかという判断は、要件を固める段階に近い工程で特に重くなります。動かし方だけでなく、既存の仕組みとの整合をどう取るかまで含めて考える場面が増えます。

案件ごとの都度になりやすい契約の単位

契約の面では、取引ごとに手間や工数がかかる点を課題に挙げる企業が多くなっています¹。案件が単発の取引として都度組まれる形が多く、まとまった期間を前提にした契約になりにくいという事情です。

古いシステムを抱える現場と、契約が都度の取引になりやすい事情は、別々の課題でありながら、参画する側から見ると同じ現場で重なって現れることがあります。長く付き合う前提の契約なのか、都度の契約なのかは、進め方にも影響します。

都度の契約が多い事情は、古いシステムを抱える現場に限った話ではありません。ただし既存の仕組みに関わる作業は影響範囲の見極めに時間がかかりやすく、都度の契約と相性が良くない場面も出てきます。

古いシステムに関わる案件を選ぶときは、契約の単位が案件ごとの都度なのか、一定期間続く前提なのかを、参画する前に確かめる価値があります。

では、受ける前に何から確かめればよいのでしょうか。

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

確認の3点と順番

役割分担や範囲が不明確という課題は、企業が挙げる課題の中でも上位に位置づけられています²。この不明確さは、参画してから気づくのではなく、参画前に確かめる部分です。

次の図は、受ける前に確かめる3つの順番を表しています。決める人がいるかどうか、担当する工程の範囲、契約の単位という順に確かめると、あいまいな部分を残さずに進められます。

図の作成：Remogu編集部。確かめる順番を整理したもので、統計データではありません

契約の面では、取引ごとに手間や工数がかかる点を課題に挙げる企業が多く¹、案件ごとの都度契約になりやすい事情があります。この3点を確かめておくことが、参画後の行き違いを防ぐ手がかりになります。

3つの確認は、案件情報を読むだけでは終わりません。参画前の面談で、決める人は誰か、担当する範囲はどこまでか、契約の単位はどうなっているかを、順番に言葉にしてもらうことが、確かめる作業そのものになります。

8. よくある質問

役割分担や範囲の不明確さを課題に挙げる企業は、どのくらいありますか

DXの課題として、役割分担や範囲が不明確を挙げる割合は27.4％です²。

システム開発で、利用する側の企業が最も優先する事項は何ですか

利用する側の企業は、システムの品質を最優先事項として捉えています¹。

技術情報の収集は、企業でどのように行われていますか

体系的な仕組みを持たず、個人に任されている企業が課題として挙げられています¹。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」工程の前提（2025年4月・2026年10月確認）
＊2 総務省「令和7年版 情報通信白書（デジタル活用の動向）」範囲の曖昧さ（2025年7月・2026年10月確認）