フリーランスの上流工程案件｜PMOへ移る5つの道筋

実装の経験を積んだフリーランスのエンジニアが単価を上げる道として、上流工程やPMOの案件に移るのは有力な選択肢です。いきなりPMを名乗る必要はなく、要件定義の一部や顧客との調整など、実装の現場で上流に近い仕事を少しずつ引き受けるところから始められます。この記事では、上流工程・PM・PMOの役割の違い、実装の経験から移る5つの道筋、求められるスキル、スキルシートと面談での見せ方、注意点をお伝えします。

上流工程・PMOの案件が評価されやすい理由

上流工程やPMOの案件が評価されやすいのは、作業の難しさよりも、任される責任の範囲と、意思決定への関わり方が違うためです。

実装の仕事は、決まった仕様を正しく形にすることが中心です。品質の高い実装は欠かせませんが、発注する側から見ると「仕様が決まっていれば、できる人を探せる」仕事でもあります。一方で上流工程は、そもそも何を作るのか、どこまで作るのか、いつまでにどの順で進めるのかを決める仕事です。ここでの判断を誤ると、後工程でどれだけ丁寧に実装しても、手戻りや作り直しが起きます。

発注企業が上流やPMOに外部の人を入れたいのは、次のような場面です。

• 業務部門と開発チームの間に入り、要件を言葉にしてまとめる人が社内にいない場面です。
• 複数のベンダーや社内チームが関わり、進捗と課題を横断して見る人が必要な場面です。
• 新しい技術（生成AIなど）を使う計画で、何をどこまで試すかを決められる人がいない場面です。

どの場面も、プロジェクトの結果を左右する判断に関わります。影響が大きい分、任せられる人は限られ、経験のある人ほど選ばれやすくなります。実装から上流へ移ることが単価を上げる道の一つになるのは、この「判断の重さ」を引き受ける側に回るからです。

上流工程・PM・PMOの役割の違い

求人や案件票では「上流」「PM」「PMO」という言葉が混ざって使われます。応募の前に、それぞれが何を担う役割なのかを押さえておくと、自分の経験とのつながりが見えやすくなります。

役割	主に担うこと	主な成果物・関わる場	実装経験とのつながり
上流工程（要件定義・基本設計など）	業務の課題を整理し、システムで何を実現するかを決めます	要件定義書、業務フロー、基本設計書、顧客との打ち合わせです	仕様の矛盾や実現の難しさに気づける点が強みになります
PM（プロジェクトマネージャー）	プロジェクト全体の目標・範囲・予算・体制に責任を持ち、最終的な判断をします	計画書、体制図、ステアリング会議での報告です	見積や技術的なリスクを自分で見積もれる点が強みになります
PMO（プロジェクトマネジメントオフィス）	PMや責任者の判断を支えるために、進捗・課題・リスクを横断して管理し、会議体や報告の仕組みを整えます	進捗報告、課題管理表、会議の運営、標準化された資料です	開発の現場で何が遅れの原因になるかを理解できる点が強みになります

PMは「決めて責任を持つ」役割、PMOは「決めるための材料と仕組みを整える」役割と考えると分かりやすくなります。ただし実際の案件では、PMOが要件定義の取りまとめまで担ったり、PMが実装チームのリードを兼ねたりと、境界は案件ごとに違います。案件名の肩書ではなく、案件票の「業務内容」に何が書かれているかを読むことが大切です。

なお、IPA の DX推進スキル標準（DSS-P）概要では、人材類型の一つとして「ビジネスアーキテクト」を挙げ、変革の目的を定め、業務プロセスを設計し、関係者を調整しながら全体を牽引して成果を出す役割として説明しています。上流やPMOの仕事は、まさにこの「目的の定義」と「関係者の調整」に重なる部分が多く、自分の目指す姿を言葉にするときの参考になります。

実装の経験から上流へ移る5つの道筋

いきなり「上流の専任」として参画するのは、未経験だと難しいのが実情です。多くの場合、実装の案件の中で上流の仕事を少しずつ引き受け、その経験を次の案件で前面に出す形で移っていきます。足がかりになるのは、次の5つです。

1. 要件定義に一部関わる

実装の担当でも、仕様のあいまいな点を顧客や業務部門に確認する場面はあります。そこで「確認して終わり」にせず、確認した内容を要件として文書に残し、関係者の合意を取るところまで引き受けると、要件定義の経験になります。最初は一機能・一画面の範囲で十分です。

2. 顧客折衝の場に出る

打ち合わせに同席し、技術的な質問に答える役から始めると、顧客の言葉の背景にある業務の事情や、意思決定の進み方が見えてきます。議事録を書き、決まったこと・決まっていないこと・次に誰が何をするかを整理して送る役を引き受けると、PMOに近い経験として説明しやすくなります。

3. 見積と計画を作る

自分の担当範囲の作業を分解し、工数と順番を見積もって計画にする経験は、PMの基礎になります。見積がずれたときに、何が原因だったかを振り返って次の見積に反映した経験も、面談で話せる材料になります。

4. レビューを担う

設計書やコードのレビューを担当すると、他の人の成果物を「要件に合っているか」「後で問題にならないか」という視点で見る力がつきます。レビューの観点を決めて、チームに共有した経験があれば、品質管理の仕組みを作った経験として示せます。

5. ドキュメントを整える

仕様書・運用手順書・引き継ぎ資料など、チームの誰もが参照する文書を整える仕事は、地味に見えて上流の力を鍛えます。読む人に合わせて情報の粒度を変え、決まったことを誤解なく伝える力は、要件定義やPMOの報告で欠かせない力と同じものです。

どの道筋も、今の案件の中で「自分から一歩引き受ける」ことから始められます。案件を変える前に、まず今の現場で上流の仕事の実績を一つ作ることを目標にすると、次の応募で語れることが大きく変わります。

上流・PMOの案件で求められるスキル

上流やPMOの案件で求められるのは、特定の言語やフレームワークの知識よりも、次のような力です。

スキル	具体的に求められること
業務理解	顧客の業務の流れ、誰が何に困っているのか、何を変えると効果が出るのかを理解することです
言語化	あいまいな要望を、要件・論点・選択肢として文書にまとめることです
合意形成	立場の違う関係者の意見を整理し、判断の材料を示して、決めるべき人に決めてもらうことです
進捗・課題管理	計画と実績の差、課題とその担当・期限を見える形にし、遅れの兆しを早めに伝えることです
ベンダーコントロール	外部の開発会社の作業範囲・品質・進捗を確認し、発注側の立場で調整することです

実装の経験が長い人は、ベンダーコントロールや進捗・課題管理で強みを出しやすくなります。開発の現場で何が遅れの原因になるか、どの説明が本当でどれが楽観的かを、肌感覚で判断できるからです。逆に、業務理解と合意形成は、意識して経験を積まないと伸びにくい力です。打ち合わせで「技術的にできるか」だけでなく「業務として何が変わるか」を聞く習慣をつけると、少しずつ身についていきます。

スキルシートと面談での見せ方

上流やPMOの案件に応募するとき、スキルシートが「担当した作業」の列挙になっていると、実装の経験としてしか読まれません。上流の経験として伝えるには、自分が判断したこと・決めるために動いたことを書くのが効果的です。

「作業」ではなく「判断したこと」で書く

同じ経験でも、書き方によって伝わる役割が変わります。

作業の書き方	判断したことの書き方
受発注画面の設計・実装を担当しました	受発注画面の仕様のあいまいな点を業務部門に確認し、例外処理の扱いを3案にまとめて、責任者の判断を得たうえで設計に反映しました
週次の定例会議に参加しました	定例会議の議事録と課題管理表を担当し、期限を過ぎた課題を毎週洗い出して、担当者と次の対応を決める運用にしました
外部ベンダーとの連携を担当しました	外部ベンダーの成果物の受け入れ基準を決め、レビューで見つけた不備を優先度付きで返す流れを作りました
工数見積を行いました	担当範囲の作業を分解して見積を作り、実績とのずれを振り返って次の見積の前提を見直しました

右の列のように書くと、読み手は「この人はどこまで任せられるか」を具体的に想像できます。数字を入れられる場合は入れてよいのですが、実際の値だけにし、盛った数字は書かないようにしてください。面談で深掘りされたときに説明できないと、かえって評価を下げます。

面談で聞かれやすいこと

上流やPMOの面談では、次のような質問がよく出ます。答えを準備しておくと、未経験の部分があっても、考え方で評価してもらいやすくなります。

• 関係者の意見が割れたとき、どう整理して決めてもらいましたか。
• 計画が遅れたとき、何を見て遅れに気づき、誰にどう伝えましたか。
• 要件があいまいなまま進みそうになったとき、どう対応しましたか。
• 実装の経験は、上流の仕事のどこで役に立つと考えていますか。

「経験がない」と答えるより、「実装の立場で、こういう場面でこう動いた」と近い経験を具体的に話すほうが伝わります。足りない部分は正直に伝え、どう補うつもりかを添えると、誠実さとして受け取られます。

商流や契約の形によって、面談で伝えられる情報や参画後の役割の範囲が変わることもあります。応募前の確認の仕方は、案件の商流を見極めるチェックポイントで詳しくお伝えしています。

狙い目は生成AI案件の上流

これから上流へ移るなら、生成AIの案件の上流は狙い目の一つです。生成AIを業務に取り入れる計画では、従来のシステム開発とは違う論点を、最初に決める必要があるからです。

• どの業務の、どの作業を生成AIに任せるのかを決めることです。
• 回答や出力の良し悪しを、何を基準に、誰が判断するのか（評価の設計）を決めることです。
• 誤った出力が出たときに、人がどこで確認し、どう直すのかという運用を決めることです。
• 社内データのどこまでを使ってよいのか、権限や情報の扱いを整理することです。

特に評価の設計は、まだ決まったやり方が定着しておらず、技術を理解したうえで業務の側と話せる人が求められやすい領域です。実装の経験がある人は、生成AIで「何ができて、何が難しいか」を実際に触って判断できるため、要件や評価の議論で強みを出しやすくなります。

自分で生成AIを使った小さな仕組みを作り、評価の観点を決めて改善した経験があれば、それ自体が上流の経験として話せます。生成AI案件の種類や、参画の前に身につけておきたいことは、生成AI案件に参画するための準備で詳しくお伝えしています。

上流・PMOへ移るときの注意点

いきなり大規模なPMは避ける

上流へ移りたい気持ちが強いと、条件のよい大規模プロジェクトのPM案件に目が向きがちです。しかし、多くの関係者と大きな予算を動かすPMは、判断を誤ったときの影響も大きく、未経験で引き受けると自分も顧客も苦しくなります。最初は、小さめのプロジェクトの上流や、PMを支えるPMOの立場から入り、判断の経験を積んでから範囲を広げるほうが、結果として長く評価される道になります。

肩書より実際の役割を確かめる

「PMO」という肩書の案件でも、実際の業務は会議の資料作りや議事録の作成が中心で、判断に関わる場面がほとんど無いこともあります。逆に、肩書は「エンジニア」でも、要件定義や顧客折衝を任される案件もあります。次の点を、案件票や面談で確かめるようにしてください。

• 誰に報告し、どこまでの判断を任されるのかを確かめます。
• 顧客や業務部門と直接話す場面があるかを確かめます。
• 成果物として何を作るのか（要件定義書、課題管理表、報告資料など）を確かめます。
• 実装の作業とどの程度兼ねるのかを確かめます。

肩書だけで選ぶと、次の案件で「上流の経験」として語れることが増えないまま、時間が過ぎてしまうことがあります。自分が次に何を語れるようになりたいかを先に決め、その経験が積める案件を選ぶことが大切です。

実装の力を手放さない

上流に移っても、実装の経験は強みとして残ります。技術の変化が速い領域、特に生成AIのように新しい技術が次々に出てくる領域では、自分で触って確かめられる人の判断は信頼されやすくなります。上流の仕事を増やしながらも、新しい技術に触れる時間は意識して残しておくと、上流と実装の両方を語れる人材として選ばれやすくなります。

まとめ

• 上流工程・PMOの案件が評価されやすいのは、責任の範囲が広く、プロジェクトの結果を左右する判断に関わるためです。
• PMは「決めて責任を持つ」役割、PMOは「決めるための材料と仕組みを整える」役割です。案件ごとの境界は、肩書ではなく業務内容で確かめます。
• 実装から上流へは、要件定義への一部参加、顧客折衝、見積と計画、レビュー、ドキュメントの5つを足がかりに、今の案件の中で経験を作るところから始めます。
• 求められるのは、業務理解・言語化・合意形成・進捗と課題の管理・ベンダーコントロールの力です。
• スキルシートと面談では、担当した作業ではなく「判断したこと・決めるために動いたこと」で経験を示します。
• 生成AI案件の上流（要件と評価の設計）は、実装の経験が強みになりやすい狙い目です。
• いきなり大規模なPMは避け、肩書より実際の役割を確かめて、語れる経験が積める案件を選びます。