フリーランスエンジニアが上流工程の案件に入るには、いきなり「要件定義担当」を狙うより、実装と上流が混ざった案件から入り、上流の実績を経歴書に書ける形で積むことが現実的です。上流の案件では、技術力より「業務を理解して整理できるか」を見られます。この記事では、入りやすい案件の形、職務経歴書と面談での伝え方、参画した直後の動き方を説明します。
上流の案件に入りにくい理由
実装経験が豊富でも、上流の案件にはなかなか声がかからないことがあります。理由はおおむね次の3つです。
- 実績として見せられるものがない：実装の実績はコードや成果物で示せますが、要件定義やヒアリングの実績は、経歴書に書いていないと伝わりません
- 発注側が失敗を避けたい：上流工程の失敗は後工程すべてに響くため、発注側は経験者を選びたがります
- 案件の入口が違う：上流の案件は、事業会社やコンサル会社から直接出ることが多く、実装案件と同じ探し方では見つかりにくい場合があります
一つ目は自分で変えられます。二つ目と三つ目も、入る案件の形を工夫すれば越えやすくなります。
入りやすいのは「実装と上流が混ざった案件」
上流の経験を積み始めるなら、次のような案件が入りやすい入口になります。
| 案件の形 | 上流の要素 | 入りやすい理由 |
|---|---|---|
| 小規模な業務システムの開発 | 業務の聞き取り、要件の整理 | 発注側に専任の要件定義担当がおらず、開発者が聞き取りまで担うことが多い |
| 生成AIを使った業務改善 | 何に使えるかの検討、試作 | 要件が最初から固まっていないため、試作しながら要件を詰められる人が求められる |
| 既存システムの改修・刷新 | 現行業務の把握、課題の洗い出し | 現行システムを読める実装力が、そのまま業務の把握に役立つ |
| 社内DXチームへの参画 | 部署へのヒアリング、優先順位づけ | 社内に開発経験者が少なく、作れる人が相談相手として頼られやすい |
どれも「作れる人が上流も担う」形です。これはFDEとは？で説明したFDEの働き方そのもので、実装経験があることが入口で有利に働きます。
準委任と請負の違いも押さえておく
フリーランスの業務委託契約には、大きく準委任と請負があります。請負は成果物の完成に対して報酬が支払われる契約で、準委任は業務を遂行すること自体に対して報酬が支払われる契約です。
上流工程は「何を作るか」を決める仕事なので、最初から成果物を確定させにくく、準委任で契約されることが多くなります。準委任では、何をどこまで進めたかを定期的に報告し、発注側と認識を合わせることがより大切になります。
職務経歴書には上流の経験を「工程と成果」で書く
実装中心の経歴でも、上流に近い経験は意外と含まれています。それを拾い出して、工程と成果がわかる形で書き直します。
書き方の例を比べてみます。
- 改善前：受発注システムの開発（Python、PostgreSQL）
- 改善後：受発注システムの開発。発注担当者2名に現行の受注手順を聞き取り、手入力していた商品コードの照合を自動化する範囲を提案。照合できない注文を確認待ちとして扱う運用を設計し、実装まで担当
改善後の例では、聞き取った相手、見つけた課題、提案した範囲、設計した運用が書かれています。上流の案件の発注側は、この部分を見ています。数字は、実際に確認できたものだけを書いてください。
経歴を棚卸しするときは、次の問いで振り返ると上流に近い経験が見つかりやすくなります。
- 仕様が曖昧で、自分から確認しに行ったことはあるか
- 現場の担当者と直接話したことはあるか
- 要望をそのまま作らず、別の方法を提案したことはあるか
- 作る範囲を削ったり、段階に分けたりしたことはあるか
面談では「どう進めるか」を具体的に話す
上流の案件の面談では、技術スタックより、進め方を聞かれることが多くなります。「参画したら最初に何をしますか」と聞かれたときに、具体的な手順で答えられるよう準備しておきます。
たとえば、次のように答えられると、進め方のイメージが伝わります。
- 最初の1週間で、現行の業務フローを資料と聞き取りから図にし、関係者に確認してもらう
- 図をもとに、時間がかかっている作業やミスが起きている作業を洗い出す
- 課題を原因ごとに整理し、優先順位の案を作って合意をとる
- 合意した範囲で要件をまとめ、見積もりの前提をそろえる
それぞれの工程で使う型を知っていると、答えに説得力が出ます。会議で論点を出し合意をとるための資料づくりはミーティング資料作成、顧客が選べる見積もりの出し方は見積もりのやり方にまとまっています。
参画した直後の動き方
上流の案件に入れたら、最初の数週間の動き方で評価が大きく変わります。
最初にやること
- 関係者の一覧を作る：誰が決める人で、誰が現場の担当者で、誰に確認すればよいかを把握する
- 今ある資料を読み込む：業務マニュアル、帳票、過去の議事録、既存システムの画面を見て、業務フローの仮説を作る
- 定例の形を決める：何を、誰に、どの頻度で報告するかを最初に合意する
避けたいこと
- 聞き取りの前に解決策を話してしまう：「それならこう作れます」と早く言いすぎると、現状の把握が浅いまま話が進む
- 決まっていないことを決まったように扱う：会議で出た意見を、誰が決めたのかを確認せずに要件に入れてしまう
- 報告を成果物の完成まで待つ：準委任では途中経過を共有することが信頼につながる
要件を開発側と現場側の両方に伝わる形でまとめる方法は、現場導入のための要件定義を参照してください。
この記事のまとめ
- 上流の案件に入りにくい主な理由は、上流の実績が経歴書から見えないこと
- 入りやすいのは、小規模開発や生成AIの業務改善など、実装と上流が混ざった案件
- 職務経歴書には、聞き取った相手、見つけた課題、提案した範囲を工程ごとに書く
- 面談では、参画後の進め方を手順で説明できるように準備する
- 参画直後は、関係者の把握、資料の読み込み、定例の形を決めることから始める
FDE Guildのロードマップでは、最後のステップ7「現場に出る」で依頼への応募を扱っています。応募の前に、ステップ1から6のどこに経験が足りないかを確かめておくと、面談でも自分の言葉で進め方を話しやすくなります。