フリーランスエンジニアの上流工程｜単価と実装から要件定義に広げた僕の道筋

フリーランスエンジニアの上流工程は、企画・要件定義・設計など「何を作るか」を決める仕事です。公開データでは、PM・PMO・ITコンサルタントの平均単価はプログラマーやSEより高く出ています。ただし上流の案件は数が少なく、経験を条件にした募集も目立ちます。開発の経験に上流の経験を少しずつ足して入るのが現実的です。

書いている僕は、2009年に新卒でSIerに入りました。それからずっと、.NETで業務系システムを作ってきました。2016年にフリーランスエンジニアとして独立し、開発中心の仕事を続けてきました。その後、上流やリーダーの経験を積みたくて案件を選ぶようになりました。2025年4月からは情シスの立場で、要件定義からベンダーコントロール・受入テスト・リリースまでを担当しています。業務委託の面談で、面談する側に入ることもあります。

この記事では、上流工程の中身と単価の公開データを先に整理します。次に案件の種類と、僕が実装中心から上流に広げた経緯を書きます。最後に、求められるスキル・メリットとデメリット・入り方・探し方をまとめます。対象は、開発の実務経験があるエンジニアです。開発の経験がない状態から上流の案件をめざす話は扱いません。

案件をどこで探すかから整理したい方は、先にフリーランスエンジニアのエージェントの選び方を読むとこの記事の後半がつながりやすくなります。

フリーランスエンジニアの上流工程は「何を作るか」を決める仕事

フリーランスエンジニアの上流工程とは、システム開発のうち企画・要件定義・基本設計など「何を作るか」を決める工程のことです。決まった内容をもとに作って確かめる詳細設計・実装・テストは、下流工程と呼ばれます。

どこまでを上流と呼ぶかは、会社や現場によって少しずつ違います。詳細設計まで上流に含める説明もあれば、企画と要件定義だけを上流と呼ぶ説明もあります。

僕がいま担当しているのは、図でいえば要件定義と右端の受入テスト・リリースが中心です。開発をベンダーに任せる部分では、その間のベンダーコントロールも受け持っています。要件定義から関わりつつ、開発もしています。

企画・要件定義・設計・見積もりの流れ

上流工程は、おおまかに次の順番で進みます。

1. 企画：業務の課題を整理し、システムで何を解決するかを決める
2. 要件定義：システムに必要な機能・画面・データ・性能などを、発注側と開発側で合意する
3. 基本設計：要件をもとに、画面・帳票・処理の流れ・データの持ち方など外から見える部分を決める
4. 見積もり：作る範囲が見えた段階で、工数・期間・費用を出す

見積もりは一度で終わらず、要件定義や基本設計が進むたびに出し直すことも多い仕事です。要件が固まるほど、見積もりのブレは小さくなります。

下流工程との違いは判断と責任の重さ

上流と下流の大きな違いは、決める範囲とその判断に負う責任の重さです。下流工程は、決まった仕様を正しく作って確かめる仕事です。上流工程は、その仕様そのものを決める仕事です。

上流で決めたことは、あとの工程すべての前提になります。要件の抜けや食い違いがテストやリリースの直前に見つかると、作り直しの範囲が大きくなります。だから上流の担当者には、技術だけでなく業務の理解と関係者との合意づくりが求められます。

手を動かす時間は、上流に行くほど減ります。そのぶん会議・資料作り・確認の時間が増えるのが一般的です。

発注側とベンダー側で中身が変わる

同じ上流工程でも、発注側に立つかベンダー側に立つかで仕事の中身は変わります。

• ベンダー側（SIer・開発会社）の上流：顧客の要望を聞き取り、要件と設計に落とし込んで見積もる。決まったものをチームで作る前提で動く
• 発注側（情シスなど）の上流：社内の要望を整理して、何をどこまで作るかを決める。ベンダーに開発を任せ、出てきたものを受け入れる

僕はキャリアの初めがSIerで、ベンダー側でした。いまは発注側に立っています。両方を経験して分かったことは、このあとの「求められるスキル」の章で書きます。

超上流・アジャイル・インフラの上流

上流のさらに手前を「超上流」と呼ぶことがあります。経営の課題やIT戦略からシステム化の企画を立てる段階で、ITコンサルタントの仕事に近い領域です。

開発の進め方による違いもあります。工程を順番に進めるウォーターフォール型では、上流と下流の区切りがはっきりしています。短い期間で作って見直すことを繰り返すアジャイル型では、要件を決める作業と作る作業が何度も行き来します。アジャイル型の現場では、プロダクトオーナーなどの役割が「何を作るか」を決めます。

インフラの分野にも上流はあります。サーバーやネットワークの要件定義と基本設計がそれにあたります。必要な性能や台数、可用性の考え方を決める仕事です。

上流工程の単価相場（PM・PMO・ITコンサルの公開データ）

上流工程の単価相場は、公開データの職種別の平均で月81万〜103万円です。プログラマーの66万円・SEの72万円より高く出ています。ここでは、レバテックフリーランスがWeb公開している案件の数字で比べます。

職種別の平均単価（公開データ）

上流の職種と、比べる相手としてSE・プログラマーを並べると次のとおりです。

出典：レバテックフリーランス「単価相場」。Web公開中の案件をもとにした数字で、最低単価は載っていません。基準日の記載はなく、数字はページを見た日によって動くことがあります。

プログラマーとITコンサルタントの平均の差は37万円です。PLでも、SEより9万円高く出ています。

単価が高くなる理由

上流の職種の単価が高くなる理由は、ページには書かれていません。一般に挙げられるのは、次のような点です。

• 影響の大きい判断を任される：要件や方針の誤りは、プロジェクト全体の手戻りにつながる
• できる人が限られる：開発の経験に加えて、業務の理解・合意づくり・管理の経験が要る
• 経験を積むのに時間がかかる：上流の経験は、開発の経験を重ねたうえで少しずつ増えていくことが多い

どれも「手を動かす量」ではなく「決める範囲」に値段がついている、という見方です。

上流の案件は数が少なく条件も厳しい

上流の案件は、開発の案件に比べると数が少なめです。単価相場のページの案件数を見ても、SEやプログラマーの案件の数のほうが多く出ています。

応募の条件も厳しくなりがちです。案件一覧を見ると、「要件定義の経験〇年以上」のように上流の経験年数を条件に書いた募集を見かけます。何年あれば入れるという決まりはありません。ただ上流の経験がまったく無いまま上流の案件だけを狙うと、選べる案件はかなり絞られます。

公開データの読み方

公開データの平均は、自分の単価とそのまま比べないほうが安全です。エージェントの公開単価は募集のときの単価で、実際の契約額や手取りとは限りません。案件の平均であって、何人がその単価で働いているかとも別の数字です。

公開データの読み方と自分の適正単価の考え方は、フリーランスエンジニアの単価相場にまとめました。1つの案件で100万円に届く条件は、フリーランスエンジニアの単価100万は上位層で詳しく書いています。

上流工程の案件にはどんな種類があるか

フリーランスエンジニアの上流工程の案件は、役割で分けると6つに整理できます。上流SE・PMとPL・PMO・ITコンサルタントとITアーキテクト・発注側（情シス）・ローコードの案件です。

要件定義・基本設計を担う上流SE

上流SEは、顧客から要望を聞き取って要件定義書や基本設計書にまとめる役割です。ベンダー側の立場で入ることが多く、開発チームに渡す設計まで担当します。

開発の経験がいちばん生きやすい役割でもあります。作る側の事情が分かっていると、実現できるかどうかや工数の重さを見積もりやすいからです。

PM・PL（プロジェクトを率いる）

PMは、スケジュール・予算・体制・品質に責任を持ってプロジェクトを最後まで進める役割です。PLはPMの下で開発チームをまとめ、現場の進み具合や課題を管理します。

フリーランスでPMの案件に入る場合は、大きなプロジェクトの一部を任されることもあります。いずれも、メンバーをまとめた経験を求められることが多い役割です。

PMO（PMを支える管理と調整）

PMOは、PMの横で進捗・課題・リスク・品質の管理を支える役割です。会議の運営や資料づくり、関係者との調整も担います。

PMとの違いは、最終的な判断と責任をPMが持つ点です。PMOは、PMが判断しやすいように情報を集めて整理します。公開データの案件数を見ても、PMOは上流の職種の中でPMに次いで多く出ています。金融系の案件も、基幹システムの更改・保守とPMOが中心です。金融系の案件の種類はフリーランスエンジニアの金融案件にまとめています。

ITコンサルタント・ITアーキテクト

ITコンサルタントは、顧客の業務の課題を整理してシステムでどう解決するかを提案する役割です。前の章で触れた超上流に近い仕事になります。

ITアーキテクトは、システム全体の構成と技術の選び方を決める役割です。クラウドの構成や、既存システムとのつなぎ方を設計する案件があります。公開データでは、どちらも平均90万円以上でした。

発注側（情シス）のベンダーコントロール

発注側の上流は、企業の情シスなどの立場で要件を決めてベンダーを管理する仕事です。業務委託の案件としても募集があります。

僕が2025年4月から入っているのは、この立場です。要件定義からベンダーコントロール・受入テスト・リリースまでを担当しています。ベンダー側で働いてきた人にとっては、同じ上流でも向きが反対になる仕事です。

情シスの仕事を業務委託で受ける働き方・単価・リモートの実情は、社内SEからフリーランスへに詳しく書いています。

ローコード（Power Platform）の案件

Microsoft Power Platformなどのローコードの製品で、業務のアプリを作る案件もあります。少ないコードで画面や処理を作れるので、要望を聞いてすぐ形にする仕事になりやすいのが特徴です。

僕は2024年から官公庁の案件に入り、Power Platformで申請アプリを作っていました。ローコードの案件は、実装の経験を持ったまま要望を聞いて形にする仕事に近づける入口の一つです。

僕が実装中心から上流工程に広げた経緯

僕のキャリアは、2016年に独立してからしばらく実装中心でした。その後は上流やリーダーの経験を積みたくて案件を選び、2025年4月からは情シスの立場で要件定義から関わっています。ここでは、実際にたどった順番を書きます。

開発の現場で「要件定義〜実装」を実績に書いた

僕は2009年にSIerに入ってから、.NETで業務系システムを作ってきました。言語はC#とVB.NETがほぼ半分ずつです（言語の話はC#フリーランスの単価と案件に書きました）。2016年に独立したあとも、金融系の現場で開発を続けています。

金融系の現場で単価の交渉をしたとき、僕はエージェントに実績のメモを渡しました。そのメモの「新たに身に付いたスキル」の欄に書いた一つが、「要件定義〜実装の一貫対応」です。開発の現場にいても、担当する工程が実装の手前まで広がればそれは実績として書けます。メモ全体の作り方はフリーランスエンジニアの単価交渉にまとめました。

上流やリーダーの経験を取りにいった2024年

金融系の開発の仕事は続けたまま、2024年に2本目の案件として官公庁の案件に入りました。この案件を受けた理由は、上流工程やリーダーの経験をしたかったからです。仕事の中身は、Power Platformで申請アプリを作ることでした。

振り返ると、この2本目の案件で「上流やリーダーの経験をしたい」という狙いはかないました。ただ、上流だけをしていたわけではありません。官公庁の案件では、リーダーの業務をしつつ実作業もしていました。

2025年4月から情シスの立場で要件定義〜リリース

2025年4月に、2本目の案件が情シスの立場の案件に切り替わりました。始めた経緯も、上流工程の経験を増やしたいというものでした。いまの現場でも、要件定義から関わりつつ開発もしています。

切り替えのときは、エージェントから5〜6件くらいの提案がありました。そのうち2社と面談して、どちらも合格しています。決まるまでは1か月くらいでした。

面談では、「これまでの開発経験を活かして、上流工程の経験を増やしていきたい」と説明しました。会社員時代に、要件定義やリーダーの業務を少しはしたことがありました。なので、ゼロから上流をやりたいという話ではなく「その経験をより増やしていきたい」という形で話しています。

このときの面談では、技術的なことも聞かれました。ただ僕の受け止めでは、それより「業務に関する話ができそうか」「質疑応答がズレていないか」「上流工程を任せられそうか」が重視されていると感じました。自分の話し方も、これまでの経験をよりよく見えるように話せたと思います。盛りすぎは良くありませんが、印象良く伝わるようには意識できました。

2社とも合格し、最後は単価で決めた

2024年の案件も2025年4月からの案件も、受けた理由は上流工程の経験を積みたかったからです。

2025年に合格した2社は、どちらも新しい経験ができそうな点で共通していました。そのうえで、最終的には単価で決めています。お金がすべてではありませんが、あえて自分を安売りする必要もないと思ったからです。

上流工程で求められるスキルと、発注側に立って分かったこと

上流工程で求められるスキルは、要望を伝わる形に直す力・合意を先に取る力・業務の目で確かめる力の3つが中心です。そこに立場の違う相手と落ち着いてやり取りする力と、資料を作る力が加わります。

要望を言葉にして相手に伝わる形に直す力

上流の仕事の中心にあるのは、相手の言葉を別の相手に伝わる形に直すことです。業務の人が話す言葉と、開発する人が必要とする情報は一致しません。

情シスの現場に入る直前、僕は発注側を「ただ指示するだけで楽そう」と思っていました。実際に入ってみると、思っていたより大変でした。ユーザーの要望はベンダーへ、ベンダーの説明はユーザーへ。僕はどちら向きにも翻訳しています。間に立つ人がそのまま横流しすると、伝言ゲームの一段が増えるだけになります。

合意を先に取り、あとの要望を整理する力

上流では、何をどこまで作るかを最初に合意しておくことがあとの工程を守ります。合意が無いまま進むと、あとから出る要望をどこまで受けるかで揉めやすくなります。

官公庁の案件では、最初にPower Platformで開発することに合意していました。そのため、細かい要望が出ても「Power Platformの仕様でできないです」と伝えれば話が通りました。作る手段を先に決めておくことも、立派な合意です。一般には、合意した内容を議事録や要件定義書に残しておくと「言った・言わない」を防げるとされています。

作られたものを業務の目で確かめる力

発注側の上流では、作られたものが業務で使えるかを確かめる受入テストも大事な仕事です。仕様どおりに動くかに加えて、実際の業務の流れで困らないかを見ます。

僕は、ベンダーが出してきた修正の受入テストをかなり細かくやっています。単体テストに近い粒度に加えて、業務の観点でもパターンを洗い出します。一般的な受入テストより細かいと思います。

発注側と受注側の両方の目線と、感情的にならないこと

上流の仕事では、立場の違う相手と話す場面が増えます。相手の立場を想像できるかどうかで、話の通り方が変わります。

僕はベンダー側から仕事を始めて、いまは発注側にいます。そのおかげで、発注側・受注側のどちらの目線にも立てます。以前、いつもすごく怒っているユーザーとやりとりしたこともありました。それもあって、受注側でも発注側でも感情的にならずに仕事をしようと思っています。

面談する側に入るときも、僕は質問と答えがかみ合っているかを見ています。かみ合っていない人は、仕事がしにくそうだと感じます。受け答えがしっかりしている人は、安心して任せられそうです。上流の仕事では、業務の担当者ともベンダーとも話をかみ合わせる場面が続きます。面談での受け答えも、その力を見られる場だと考えておくとよいでしょう。

設計書やテスト仕様書の作成にAIを使う

上流の仕事は、文章と資料を作る時間が長くなります。僕は仕事で、実装前の壁打ち・資料作成・設計書やテスト仕様書の作成にAIを使っています。ノートブック型のツールに設計書を読ませて、質問に答えてもらう使い方もしています。

気をつけているのは、曖昧な書き方をしないことです。曖昧なまま渡すと、AIが勝手に解釈して話が進んでしまいます。曖昧さを残さないために、壁打ちがけっこう大切です。これは、人に要件を伝えるときにもそのまま当てはまります。AIの使い方はフリーランスエンジニアはAIで仕事がなくなる？にまとめています。

上流工程のメリットとデメリット

上流工程のメリットは、単価が上がりやすく経験の幅が広がることです。デメリットは、責任と調整が増えて手を動かす時間が減ることです。どちらが合うかは、仕事に何を求めるかで変わります。

単価が上がりやすく、経験の幅が広がる

上流のメリットとしてよく挙げられるのは、次の点です。

• 単価：公開データでは、上流の職種ほど平均単価が高い
• 経験の幅：業務の理解・合意づくり・管理など、開発だけでは積みにくい経験が増える
• キャリアの選択肢：PM・PMO・ITコンサルタント・発注側など、次に選べる道が広がる
• 人のつながり：発注側や業務の担当者など、話す相手の幅が広がる

長く続く案件もあると言われます。ただ契約が続くかどうかは案件と働きぶりしだいで、上流だから続くと決まっているわけではありません。

責任と調整が増え、手を動かす時間は減る

デメリットは、判断の責任と調整の量が増えることです。決めたことの影響が大きいので、プレッシャーも大きくなります。

会議と資料が中心になり、コードを書く時間はほとんど無くなる案件もあります。上流の仕事が「つまらない」と言われることがあるのは、作る楽しさから離れやすいからだと一般に言われます。僕自身も、発注側は思っていたより大変だと感じています。ただ僕の場合は、上流に広げてからもリーダーの業務と並べて実作業や開発をしてきたので、手を動かす時間が無くなったわけではありません。

上流工程に向いている人・向いていない人

上流工程に向いているのは、次のような人だと言われます。

• 相手の話を聞いて、要点を整理するのが苦にならない
• 決まっていないことを、自分から確かめに行ける
• 技術の話を、技術を知らない人にも伝わる言葉で話せる
• 作ることより、うまく回ることに喜びを感じる

反対に自分の手で作ることにいちばんのやりがいを感じる人は、下流の専門性を深める道のほうが合うかもしれません。どちらが上ということではありません。

いまの現場で僕の周りにいるフリーランスは、経験豊富なベテランのほうが多い印象です。業界全体を調べたわけではなく、あくまで僕の周りの話です。僕自身は35歳を超えてから、自分の感覚も周りから求められるものも変わったと感じています。

実装中心のエンジニアが上流工程の案件に入るには

実装中心のエンジニアが上流工程の案件に入るには、「今の現場で範囲を広げる → 実績として書き出す → 入口になりやすい案件を選ぶ」の順番が現実的です。面談では、求められる役割を確かめるところまでが準備です。

今の現場で担当する範囲を少しずつ広げる

最初の一歩は、今の現場で上流に近い仕事に手を挙げることです。仕様の確認の打ち合わせに加わる・設計書のレビューに入る・テストの観点を考えるといった範囲から始められます。

案件を変えなくても、担当する工程が広がればそれは上流の経験になります。開発の現場でも要件の話に関わる機会はあります。

上流に関わった経験を実績として書き出す

上流に関わった経験は、書き出さないと伝わりません。スキルシートや単価交渉のメモには、担当した工程をはっきり書きます。

僕は実績のメモに「要件定義〜実装の一貫対応」と書きました。スキルシートも、途中から案件ごとの「習得スキル」と「意識したこと」を書き足すようにしています。書き方はフリーランスエンジニアの単価交渉とスキルシートの書き方にまとめました。

経歴の見え方にも気をつけたいところです。僕は面談する側に入ったとき、直近の経歴が数か月の案件ばかり続いていると不安に感じました。

入口になりやすい案件を選ぶ

上流の経験が少ないうちは、入口になりやすい案件から選ぶのが現実的です。たとえば次のような案件があります。

• ローコードの案件：画面をすぐ作れるので、要望を聞く場面と形にする場面が近い
• PMOの補佐：会議・資料・課題管理を通して、プロジェクトの進め方を間近で見られる
• 情シスなど発注側の案件：受入テストやベンダーの修正内容の確認など、開発の経験と地続きの仕事がある

僕が官公庁で入ったPower Platformの案件も、入口になりうる案件の一つです。次の案件を選ぶときに「上流の経験を積みたい」とはっきり決めておくと、提案される案件も絞られます。

面談では求められる役割を確かめる

上流の案件の面談では、自分に求められる役割の範囲を確かめておくことが大切です。同じ「要件定義」でも、顧客と決める立場なのか決まった要件を整理する立場なのかで仕事は違います。

僕が面談で実際にした逆質問の一つは、「現場で、私に求められている役割はどういうことがありますか？」です。上流の案件なら、この答えで任される範囲が見えてきます。

面談する側に入るとき、僕はスキルシートを見てまずスキルが現場に合っているかを確かめます。現場に合っていなくても、それでもいいと思える観点があれば大丈夫だと考えています。どんな観点なら「それでもいい」と思えるかは現場しだいです。上流の経験が少ないなら、開発の経験が現場のどこに生きるかを具体的に話せるようにしておくと、判断の材料が増えます。面談の準備はフリーランスエンジニアの面談対策にまとめています。

上流工程の案件の探し方

上流工程の案件は、エージェントに上流の経験を積みたいと伝えて探すのがいちばん現実的です。上流の案件は数が少ないので、複数のエージェントの案件を見比べると選べる幅が広がります。

エージェントに上流の希望を伝えて探す

エージェントの担当者には、次に積みたい経験として「上流工程」をはっきり伝えます。担当した工程とこれから担いたい工程を分けて話すと、提案が絞られやすくなります。

僕は2016年から1社のエージェントを使っていて、案件と案件の間に無収入の期間はこれまで一度もありません。案件を切り替えるタイミングの担当営業とのランチMTGでは、次にどんな案件がいいかを話しています。担当者とのやり取りは、フリーランスエージェントの担当者との付き合い方に書きました。

複数のエージェントで上流の案件を見比べる

上流の案件は、エージェントごとに持っている案件が違います。PMOに強いところやエンド直の案件が多いところなど、得意分野もさまざまです。

僕自身は、今のエージェントに不満が無かったので2社目には登録していません。それでも、つてが無いならまずは複数に登録するのが良いと思っています。案件もエージェントも、比べるから良し悪しが分かります。登録の考え方はフリーランスエンジニアのエージェントは複数登録すべきかにまとめました。

商流と直接契約の考え方

上流の案件でも、エンドの企業と自分の間に何社入っているか（商流）は確かめておきたい点です。間に入る会社が多いほど、エンドが払う額と自分が受け取る額の差は大きくなります。

僕は商流が深いと間でムダにマージンがかかっていると思ってしまうので、浅いに越したことは無いと考えています。ただ今の現場や単価で満足しているなら、それでいいとも思います。

上流の仕事をしていると、エンドの企業と直接話す機会が増えます。僕はクライアントから直接契約を持ちかけられたことはありません。法的にどうかは分かりません。それでも倫理的にNGだと思っているので、仮に言われても断ります。エージェントとの契約に引き抜きを制限する条項がある場合もあるので、気になる方は契約書を確かめてください。マージンの相場と商流の確かめ方は、エージェントのマージン相場と商流の確かめ方に書いています。

上流工程の案件を実際に見てみたい方に、エージェントを3つ挙げておきます。どれも僕は使っていないので、使い心地は書けません。会社員で、これから独立して上流の案件も視野に入れたい方はMidworksが対象です。

PM・PMO・ITコンサルタントなど、職種で絞り込んで案件を眺めたい方にはレバテックフリーランスがあります。

すでにフリーランスとして働いていて、次は上流の案件を探したい方にはITプロパートナーズもあります。

フリーランスの上流工程でよくある質問

フリーランスの上流工程について、よく聞かれる質問に答えます。

上流工程に資格は必要？

上流工程の案件に、必須の資格はありません。ただ、資格は知識を客観的に示す材料になります。上流に関係する資格には、次のようなものがあります。

• プロジェクトマネージャ試験（IPA）：プロジェクトマネジメント業務を担う人を対象にした国家試験（IPA「プロジェクトマネージャ試験」）
• システムアーキテクト試験（IPA）：要件を定義し、アーキテクチャを設計して開発を主導する人を対象にした国家試験（IPA「システムアーキテクト試験」）
• PMP：プロジェクトマネジメントの国際的な資格

IPAのページには、現行の試験制度は2026年度の実施で終わって2027年度から新しい制度に移る予定と書かれています（2026年10月16日確認）。受けるつもりの方は、最新の案内を確かめてください。

僕自身はIT系の資格がありません。基本情報と応用情報に挑戦したことはありますが、結果はどちらも不合格です。資格が要らないと思っているわけではなく、取れるに越したことはないと思っています。それでも、資格が無くて実務で困ったことはありません。

開発経験が浅くても上流の案件に入れる？

開発経験が浅いうちに上流の案件だけで入るのは、簡単ではありません。前の章で見たとおり、上流の経験年数を条件にした募集も多いからです。何年あれば入れるという決まりはありませんが、開発の現場で上流に近い仕事を重ねてから移るほうが入りやすくなります。

上流の仕事でも、開発の経験は土台になります。ベンダーの説明を理解したり、修正の影響に当たりを付けたりするのに使うからです。

AIが広がると上流工程の仕事はどうなる？

AIが広がっても、仕事がまったくなくなるというより人間がやる領域が変わるというのが僕の理解です。まったくキャッチアップしなければいずれ淘汰されるので、少しずつでもAIに触ることが大事だと思っています。

上流の仕事にもAIは入ってきています。僕も設計書や資料の作成にAIを使っています。AIの使い方と、AIで仕事がどう変わるかはフリーランスエンジニアはAIで仕事がなくなる？で詳しく書きました。

上流の案件はリモートで働ける？

上流の案件でも、リモートで働ける案件はあります。ただ顧客との打ち合わせや社内の調整が多い案件では、出社を求められることもあります。リモートの可否は案件ごとに違うので、面談で確かめるのが確実です。

僕の働き方は、2020年のコロナ禍からずっとフルリモートです。エージェントにも、フルリモートを希望として伝えています。リモート案件の割合と探し方は、フリーランスエンジニアのリモート案件にまとめています。

これから独立を考えている段階なら、独立までの全体の流れをSIerからフリーランスになるにはにまとめています。