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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一度確定した内容は後戻りしにくい

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

役割や範囲があいまいなまま進む

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

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

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

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

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

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

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

品質を優先する前提のもとでは、確認や検証にかける時間が短く削られることは少なく、テストや検証の工程が軽んじられにくいという特徴があります。参画する側にとっては、確認作業の丁寧さがそのまま評価につながりやすい環境です。

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

品質を優先する前提は、参画する側にとって、確認作業に時間をかけやすい環境でもあります。急いで仕上げることを求められにくい分、根拠を示しながら進める姿勢が評価につながります。

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

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

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

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

新しい技術情報を自分で集める姿勢は、内製化が進む現場ほど重宝されます。会社の仕組みが個人任せである分、外部から参画する側が持ち込む情報が、そのまま現場の判断材料になる場面も出てきます。

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

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

約半数が内製化を進めている

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

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

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

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

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

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

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

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

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

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

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

半数程度がレガシーシステムを抱えている

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

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

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

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

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

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

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

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

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

ここまでの内容を踏まえて、次の章では受ける前に確かめておきたい順番を整理します。

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

3つの確認から始める

ここまで見てきた内容を、受ける前に確かめる順番として整理します。役割分担や範囲が不明確という課題は、企業が挙げる課題の中でも上位に位置づけられています⁹。この不明確さは、参画してから気づくのではなく、参画前に確かめておきたい部分です。

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

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

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

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

案件情報だけで担当する工程を判断できますか

案件情報の文面だけでは判断が難しい場合があります。開発の進め方は段階を追って進む前提がいまも主流で¹、要件定義と設計は文書を中心に進められています²。参画前の面談で、担当する工程の範囲を具体的に尋ねると、実態に近づけます。

決める人がいない案件は避けた方がよいですか

意思決定を担う責任者を置いていない案件は約半数に上ります⁵。避けるかどうかより、決める人が誰なのかを事前に確認し、疑問が出たときにどこへ確認すればよいかを把握しておく方が現実的です。

古いシステムを抱える案件は、経験がまだ少なくても関われますか

古いシステムを抱える企業は半数程度に上ります⁸。既存の仕組みへの理解が問われる場面が多く、経験がまだ少ない場合は、まず担当する範囲を絞った案件から関わる進め方もあります。自分に合う案件を確認しながら、任せられる範囲を広げていく道もあります。

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

出典・参考情報

＊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 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 総務省「令和7年版 情報通信白書（デジタル活用の動向）」範囲の曖昧さ（2025年7月・2026年8月確認）
＊10 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」知識の持ち方（2025年4月・2026年8月確認）