SIer の現場で日常的に使われる「上流工程」「下流工程」という言葉は、もともとウォーターフォール型開発の工程を時系列で切り分ける素朴な呼称として入ってきました。
ところが、この言葉が作業の順序だけでなく、もうひとつの含意を運んでいるのに気づくことがあります。
「私の担当は下流工程です」と自己紹介するときのわずかな遠慮。「上流に行きたい」と語るときの前向きな響き。工程の時系列は本来横並びのはずが、いつの間にか縦の階層として扱われています。
本稿では、この言葉の構造を観察しながら、エンジニアの自己評価がなぜ言葉によって歪んでいくのかを整理してみたいと思います。
1. 「上流」「下流」という言葉が運ぶ、もう一つの含意
この呼称は、工程の時間軸を川の流れに喩えた素朴な比喩のはずでした。
それが日本の SIer 文化の中で価値のヒエラルキーと結び合わさっていった経緯があります。
川上から川下へ水が流れるという物理的なイメージが、以下のような含意と重なって定着してきました。
- 上流 = 構想・判断・抽象。企画、要件定義、アーキテクチャ設計の領域
- 下流 = 実行・手作業・具体。実装、テスト、保守の領域
ここに、多重下請けの構造とキャリアパスの慣習が重なります。
元請け SIer が要件定義を担い、二次請け以下が実装を受ける——この分業モデルが、工程の時間軸と企業間の階層を重ねて、言葉そのものにヒエラルキーのラベルを帯びさせていきました。
誰もが意識しているわけではありません。ただ、言葉の背後に置かれたこのヒエラルキーは、わずかな瞬間に見え隠れします。
2. 実装とテストが担う、設計書の先の価値
「下流工程」という呼称が運ぶヒエラルキーの下では、実装やテストの価値は系統的に低く見積もられがちです。
一方で実際の現場では、設計と実装の質はどちらが欠けても成立しない関係にあります。
- 品質担保: 設計書通りに作ることを土台にしつつ、そこに残る抜け漏れを現場で拾う
- 実行可能性の検証: 紙上で成立していた設計が、現実の制約と噛み合わない箇所を実装段階で見つける
- ユーザー体験の決定: UI の反応、処理速度、エラーメッセージ、ユーザーに触れる部分は実装で仕上がる
アジャイル開発や DevOps の現場では、工程の境界そのものがすでに書き換えられつつあります。設計と実装を短いループで往復し、テストを自動化して常時回し続ける——これは「上流・下流」という縦の構造を、前後の対等なサイクルへ組み替える試みと捉えることもできます。
3. 工程のラベルを外して、自分の仕事を見直す
自身の業務を「◯◯工程」というラベルではなく、どの課題を解き、どんな価値をプロジェクトに残したかで記述し直してみます。
- バグ修正 →「顧客の業務効率の低下を本番リリース前に抑えた」
- パフォーマンスチューニング →「ユーザー離脱の兆候を数日前に抑え込んだ」
- デバッグ →「複雑な状態遷移を紐解き、再発条件を特定した」
どれも時間軸の上では「下流」に分類される作業ですが、生み出した価値の側から見れば、それぞれに固有の専門性があります。
補足として、貢献の可視化も重要です。チームや顧客に対して、自分の判断と結果を定期的に言語化して共有する。報告会でも、ドキュメントでも、デモでも構いません。価値を言語化する習慣そのものが、自分の仕事を自分の言葉で説明できる力になります。
まとめに代えて
「上流」「下流」という言葉は、工程を切り分けるだけでなく、価値のヒエラルキーを暗黙に運んでしまう構造を持っています。この構造が定着した背景には、ウォーターフォール型開発の流儀と、多重下請けのキャリア慣習が重なっていたこともあります。
実装もテストも、設計書をプロダクトに変えていく不可欠な局面であって、そこにある専門性や判断が、価値が低い、ということではありません。
工程という縦の構造ではなく、解いた課題と残した価値という軸で自分の仕事を語り直すことで、自己評価を他人の言葉に預けずに済みます。
