上流工程

上流工程は「何をつくるか」「なぜつくるか」を決める区間です。ウォーターフォール型の開発を想定すると、おおむね次の工程が含まれます。

• システム化企画
  投資の目的や解決したい業務課題を整理し、システム化の方向性と大枠の範囲を決める段階です。経営や業務部門の意思を確認します。
• 要求定義・要件定義
  利用者や発注側が実現したいこと（要求）を集め、システムが満たすべき条件（要件）へ落とし込みます。機能要件と非機能要件の双方を扱います。
• 基本設計
  要件を満たすための画面・帳票・データ・外部連携などの全体構造を決めます。詳細設計より前の、方式レベルの決定が中心です。

対して、詳細設計から先の実装・結合テスト・システムテストなどは下流工程と呼ばれます。上流と下流の線引きは現場や契約の形態によって揺れるため、プロジェクトごとに「どこまでを上流とみなすか」を関係者で合わせておくと認識のずれが減ります。

上流工程では、PMは手を動かす主役というより、意思決定を前に進める調整役になります。進め方は大きく次の流れをたどります。

• 関係者と目的をそろえる
  発注側の担当者、業務部門、利用者、開発側のアーキテクトやSEが集まり、何のためのプロジェクトかをキックオフで共有します。ここでステークホルダーの顔ぶれと決裁の経路を押さえます。
• 要求を引き出して要件へ変換する
  業務部門への聞き取りや現行業務の確認を通じて要求を集め、SEや業務分析の担当が要件定義書へ整理します。PMは論点の抜けや要求同士の矛盾を見つけ、判断が必要な点を担当者に戻します。
• 全体像を設計へ落とす
  要件が固まったら、基本設計で画面構成やデータの流れを決めます。成果物はシステム化企画書、要求定義書、要件定義書、基本設計書といった形で残ります。

この区間でPMが管理するのは、スケジュールだけでなく「決めるべきことが決まっているか」です。合意が取れていない論点を抱えたまま次工程へ進めると、後で手戻りが生じやすくなります。

上流工程は成果物が文書中心で進捗が見えにくく、いくつかの典型的なつまずき方があります。あらかじめ形を知っておくと対処しやすくなります。

• 要求の固まり切らないまま先へ進む
  業務部門の意向が定まらない、決裁者が会議に出てこないといった状況で、曖昧な要件のまま設計へ移ってしまう形です。後工程での変更管理の負荷が増えます。
• 要求と要件の取り違え
  「こうしたい」という要望をそのまま機能として書き起こし、本当に解くべき課題を飛ばしてしまうことがあります。課題設定の段階で一度立ち止まる余地を残しておくとよいでしょう。
• 非機能要件の後回し
  性能、可用性、セキュリティ、運用のしやすさといった条件は目に見えにくく、議論が機能面に偏りがちです。基本設計以降で制約として効いてくるため、上流のうちに言葉にしておきたい部分です。

いずれも「決めきれないこと」を放置した結果として表れます。決められない論点は、誰がいつ判断するかまで含めて明示しておくと、宙に浮きにくくなります。

上流と下流は、担う問いの種類で区別すると整理しやすくなります。軸を「扱う問い」「主な成果物」「変更のしやすさ」に置いて比べます。

• 扱う問いの違い
  上流は「何を・なぜつくるか」を扱い、下流は「どうつくるか」を扱います。詳細設計から先は、上流で決めた方針を具体的なコードやテストへ落とす区間です。
• 成果物の違い
  上流は企画書・要求定義書・要件定義書・基本設計書といった文書が中心です。下流はソースコードやテスト結果など、動く・検証できる成果物の比重が高まります。
• 変更のしやすさの違い
  上流での方針変更は文書の修正で済む場合が多い一方、下流に進んでからの要件変更は、設計・実装・テストへ波及し、やり直しの範囲が広がりやすくなります。

なお「上流工程」と「上流コンサル」は語感が似ていますが同じではありません。前者は開発の工程区分、後者は構想や課題設定により踏み込む役割の呼び方で、文脈によって指すものが異なります。

上流工程の経験は、PMとしての市場価値を考えるうえで一つの分かれ目になりやすい領域です。進捗管理や課題管理といった工程運営の力に加えて、要求を要件へ翻訳し、立場の異なる関係者の合意をまとめる力が求められるためです。この合意形成と課題設定の経験は、下流中心の役割からは積み上げにくく、担当できる範囲が広がるほど評価の裏づけになりやすいと考えられます。キャリアを次に進めたいPMは、自分がどの工程までを主導してきたかを棚卸しし、要件定義や基本設計でどんな判断を担ったかを言葉にしておくとよいでしょう。上流に軸足を移す道筋としては、要件定義への関与を増やす、課題設定の段階から関わる、といった進め方が現実的な一歩になります。

上流工程にはどこまでの工程が含まれますか。

一般にはシステム化企画、要求定義、要件定義、基本設計あたりまでを指すことが多いです。ただし線引きは現場や契約形態で揺れます。詳細設計以降を下流とみなす場合もあれば、基本設計を下流に寄せる場合もあるため、プロジェクトごとに関係者で範囲を確認しておくと安全です。

上流工程でPMが最も意識すべきことは何ですか。

決めるべきことが期限内に決まっているか、という点です。上流は文書中心で進捗が見えにくく、合意されていない論点を抱えたまま次工程へ進むと手戻りが生じやすくなります。判断が必要な事項を洗い出し、誰がいつ決めるかまで明示しておくことが、後工程の負荷を抑える助けになります。

上流工程の経験はキャリアにどう効きますか。

要件を固め関係者の合意をつくる力は、下流の工程管理だけでは身につきにくく、評価されやすい領域とされています。課題設定や要件定義に踏み込んだ経験があると、より広い裁量を持つ役割や上流寄りのポジションを検討する際の裏づけになりやすいでしょう。