上流工程の案件に入るために必要な経験｜要件定義・基本設計への広げ方

上流工程の案件に入るために求められるのは、要件定義や基本設計を、発注側の担当者と話し合いながら合意し、文書にまとめた経験です。技術の知識に加えて、業務を理解する力、利害の違う人の意見をまとめる力、決まったことを誰が読んでも分かる形に残す力が見られます。

いきなり上流工程だけの案件に入るのは難しいことが多く、詳細設計や開発を担いながら、設計のレビューや顧客との打ち合わせに少しずつ関わる範囲を広げていくのが現実的な道です。この記事では、必要な経験、広げ方、スキルシートでの示し方を整理します。

上流工程で担う仕事

システム開発の工程は、プロジェクトによって呼び方が違いますが、一般的には次のように分けられます。

フリーランスの案件で「上流工程」と言うときは、多くの場合、要件定義と基本設計、あるいはその手前の企画・構想を指します。下流（詳細設計や開発）との違いは、決めるべきことがまだ決まっておらず、決めること自体が仕事になる点です。

上流工程の案件で見られる経験

上流工程の案件では、スキルシートと面談で、次のような経験があるかを確かめられることが多い傾向があります。

1. 発注側の担当者と直接やりとりした経験

要件定義では、業務部門や情報システム部門の担当者から話を聞き、要望を整理します。打ち合わせの進行、議事録の作成、宿題の管理など、相手の会社の人と直接やりとりして物事を進めた経験が評価されます。

2. 決まっていないことを決めた経験

要望には、互いにぶつかるものや、予算・期間に収まらないものが含まれます。優先順位を整理し、選択肢と影響を示して、相手に判断してもらう。この「決めるための材料をつくる」経験が、上流工程の中心です。

3. 文書にまとめた経験

要件定義書、基本設計書、業務フロー、画面の遷移図など、決まったことを文書に残した経験です。誰が読んでも同じ理解になるように書けるか、変更があったときに経緯を追えるように管理できるかが見られます。

4. 業務の知識

会計、販売、生産、人事など、対象の業務の知識があると、要望の背景を理解しやすくなります。特定の業界や業務に詳しいことが、技術の幅以上に評価される案件もあります。

5. 下流工程の理解

設計が実装やテストでどう使われるかを知っていると、実現できない要件や、あとで手戻りになる設計を避けやすくなります。開発の経験は、上流工程でも強みになります。

下流工程から役割を広げる道

上流工程の経験がまだ少ない場合、次のような順で関わる範囲を広げていく道があります。

ステップ1：詳細設計とレビューを担う

開発の案件の中で、詳細設計を任される、他の人の設計をレビューする、といった役割を引き受けます。基本設計書を読み込み、不明点を質問として整理する作業は、上流工程の考え方を身につける近道です。

ステップ2：打ち合わせに同席し、記録を担う

設計の打ち合わせや、発注側との定例会に同席し、議事録や課題の一覧を担当します。決まったこと・決まっていないこと・誰がいつまでに何をするかを整理する経験は、そのまま要件定義の仕事に生きます。

ステップ3：一部の機能の基本設計を任される

小さな機能や改修の範囲で、画面やデータの設計を任されると、基本設計の実績になります。規模が小さくても、自分が設計を決め、相手と合意した経験として示せます。

ステップ4：要件定義のメンバーとして入る

要件定義のチームに、メンバーとして加わる案件を探します。最初は特定の業務領域の整理や、資料の作成を担い、徐々に打ち合わせの進行を任されるようになると、上流工程の経験として説明できる幅が広がります。

PMOや業務コンサルの経験から入る道

プロジェクトの進捗管理や課題管理を担うPMO、業務の整理を担う業務コンサルの経験から、要件定義の案件に入る人もいます。会議の運営や関係者の調整の経験が、上流工程で生きるためです。それぞれの進み方はPMOがフリーランスになる方法やITコンサルタントがフリーランスになる方法で整理しています。

上流工程の案件を選ぶときに確かめること

上流工程の案件は、案件情報の書き方が抽象的になりやすく、参画してから「思っていた役割と違う」と感じることがあります。応募や面談の前に、次の点を確かめておくと安心です。

契約の形の違いは準委任契約と請負契約の違いの記事で整理しています。

スキルシートと面談での示し方

スキルシートに書くこと

上流工程の経験は、工程の名前を並べるだけでは伝わりません。プロジェクトごとに、次の点を書きます。

1. 担当した工程：要件定義のどの部分か、基本設計のどの範囲か
2. 相手：どの部門の、どの立場の人とやりとりしたか
3. 自分が決めたこと・まとめたこと：論点の整理、選択肢の提示、文書の作成
4. つくった文書：要件定義書、業務フロー、画面設計書など
5. 結果：合意できた範囲、手戻りの減少、スケジュールへの影響など

工程の欄に「要件定義」と書くだけでなく、「業務部門の担当者◯名と週1回の打ち合わせを進行し、帳票の要件を整理した」のように、場面が浮かぶ書き方をすると、読み手が任せられる範囲を判断しやすくなります。書き方の型はスキルシートの書き方の記事で紹介しています。

面談で話すこと

面談では、うまくいった話だけでなく、意見が分かれたときにどう整理したか、要件が変わったときにどう対応したかを聞かれることがあります。次の流れで話すと伝わりやすくなります。

• どんな状況で、何が決まっていなかったか
• 自分はどんな材料を用意し、誰に何を判断してもらったか
• 結果どうなり、次に何を変えたか

よく聞かれる質問は面談でよく聞かれる質問の記事、経歴の話し方は自己紹介の記事にまとめています。

よくある質問

上流工程の案件は、未経験でも入れますか？

上流工程だけの案件に、関連する経験がない状態で入るのは難しいことが多いです。開発の案件の中で設計やレビュー、打ち合わせへの同席を担い、少しずつ経験を積む方が現実的です。経験の一部があれば、その範囲を正確に示して応募できる案件もあります。

上流工程の案件は、単価が上がりますか？

担う責任の範囲が広がるため、条件が上がりやすい傾向はありますが、案件によって大きく変わります。単価は役割のほか、需要や稼働日数、商流でも決まります。考え方は単価の仕組みの記事と単価を上げるための考え方で整理しています。

年齢が上がってから上流工程に移ることはできますか？

年齢よりも、どんな経験を積んできたかが見られることが多い傾向があります。長く開発を担ってきた人が、業務の知識や設計の経験を生かして上流工程に関わる例もあります。年代ごとの案件の傾向は40代のフリーランスの記事などで整理しています。