「上流」と「下流」は、地続きに見える
先日、エンジニアと話していると、上流と下流をひとつながりの道のように捉えている人がいて違和感を覚えました。
「AIの進化によって、これからは要件や設計などの上流が大事になる」と話すと、「では自分も上流をやってみます」と返ってくる。本人にやる気があるのは良いことです。ただ、その言葉の奥には「下流の延長をまっすぐ進めば、いずれ上流に着く」という感覚が透けて見えることがあります。手前の工程で経験を積めば、自然と奥の工程に手が届く。そういうイメージです。
30年近くSIの現場を見てきて私が感じているのは、この感覚が実態とずれている、ということです。上流と下流は、同じ一本道の手前と奥ではありません。求められる頭の使い方がほとんど反対を向いた、別系統のスキルです。地続きに見えて、実は別の山なのです。
この記事では、その違いがどこから生まれるのか、上流へ進むとは本当はどういうことなのかを、できるだけ具体的に分解してみます。
なぜ「地続き」だと感じてしまうのか
そもそも、なぜ多くの人が上流と下流をひとつながりだと感じるのか。ここを先に解いておきたいと思います。
ひとつは、工程図の見え方です。要件定義、設計、製造、テスト。プロジェクトの工程はいつも左から右へ一直線に並んで描かれます。同じ矢印の上に乗っているのだから、左を究めれば右にも進める。図がそう錯覚させます。
もうひとつは、キャリアの序列です。一般に上流ほど報酬も役割の重さも上がっていく傾向があるため、「上流＝昇進した先にある場所」という印象が強くなる。経験年数を重ねれば自動的に到達するステージのように見えてしまうのです。
けれど、工程が隣り合っていることと、必要なスキルが連続していることは別の話です。隣の山が近くに見えても、登る技術はまったく違う。まずはこの二つを切り離すところから始めたいと思います。
下流は「モノを正しく作る」思考
では、それぞれが何を問う仕事なのか。下流から見ていきます。
下流、つまり設計が固まった後の実装やテストの工程で問われるのは、決まっていることを正確に形にする力です。仕様という「正解」があり、それをいかに漏れなく、堅牢に、保守しやすくコードへ落とすか。論理の一貫性、エッジケースへの目配り、性能やセキュリティへの配慮。ここで磨かれるのは、曖昧さを許さず正しさを積み上げていく思考です。
優れたプログラマーほど、この「正しさへの執念」を強く持っています。決められた仕様の中で、いかに崩れない構造を作るか。そこに職人的な誇りがある仕事です。
上流は「情報を扱う」思考
一方、要件定義や方針設計といった上流で問われるのは、性質の異なる力です。
そこには「正解」がありません。顧客の言葉は曖昧で、関係者ごとに望むものは食い違い、そもそも何を作るべきかが決まっていない。その状態から、ばらばらの情報を抽象化して構造を見抜き、利害の異なる人たちを合意へ導き、決まっていないことを決めていく。扱っているのはコードではなく、人と業務と情報です。
下流が曖昧さを排除する仕事だとすれば、上流は曖昧さの中に居続ける仕事です。向いている方向が、ちょうど逆を向いている。だから「実装が得意だから上流もすぐできる」とはなりません。実装力は素晴らしい武器ですが、それが上流の適性を保証するわけではないのです。
違いは、3つの軸で見えてくる
両者の違いを、もう少し輪郭のはっきりした形で並べてみます。私が現場で説明するときは、いつも次の3つの軸で話します。
まず、扱う対象が違います。下流が向き合うのはコードとロジック、つまり機械に対して正しさを保証する仕事です。上流が向き合うのは人と業務と情報、つまり立場の異なる人間の間で納得を作る仕事です。
次に、正解の有無が違います。下流には仕様という正解があり、それにどれだけ忠実かつ堅牢に近づけるかが勝負になります。上流には正解がなく、何を正解とするか自体を自分たちで定義するところから始まります。
そして、評価のされ方が違います。下流の良し悪しは、動くか、速いか、壊れにくいか、といった検証可能な基準で測れます。上流の良し悪しは、その判断が後々どんな結果を生んだか、関係者がどれだけ納得して進めたか、という時間をおいてしか見えない基準で測られます。
この3つを並べると、両者が「同じスキルの初級と上級」ではないことがはっきりします。問われている能力の種類そのものが違うのです。
だから「学び直し」が必要になる
上流が実装の延長線上にないとすれば、上流へ進むことは、新しい科目を一から学び直すことに近くなります。具体的に、何を学び直す必要があるのか。
まず、抽象化の力です。「この画面にボタンを足したい」という要望の奥にある、業務上の本当の目的までさかのぼる。個別の要求を構造として捉え直す。実装ではむしろ抽象を具体へ降ろしていくので、ここは思考の向きが逆になります。
次に、合意形成の力です。技術的に正しい答えを出すことと、関係者全員が「それでいこう」と腹落ちすることは、まったく別の作業です。誰が何を心配しているのかを読み、落としどころを設計する。コードは論理で動きますが、人は感情と立場で動きます。
そしてもうひとつ、曖昧さに耐える力です。下流で優秀だった人ほど、ここで苦しむのを何度も見てきました。「要件が固まっていないと気持ち悪い」という感覚は、実装者として正しく育ってきた証でもあります。けれど上流では、決まっていない状態を自分の手で決めていくのが仕事です。不確実さを敵ではなく前提として受け入れられるか。これは性格に近い、根の深い切り替えなのです。
要件定義というスキルそのものの中身については、「要件定義できます」の落とし穴でさらに具体的に掘り下げています。あわせて読むと、上流の輪郭がはっきりすると思います。
向き不向きという、避けて通れない話
ここで、正直な話をしておきます。上流には、向き不向きがあります。
誰もが努力すれば等しく上流のプロになれる、とは私は思っていません。情報を抽象化し、曖昧さの中で人をまとめていく思考は、すんなり馴染む人もいれば、何年やっても手応えをつかみにくい人もいる。これは現場で実際に起きていることです。
ただ、これを「頭の良し悪し」の話に還元するのは違うと考えています。問われているのはIQのような単一のものさしではなく、思考の型がその仕事に合っているかです。下流の「正しさを詰める思考」が抜群に強い人が、上流の「曖昧さを泳ぐ思考」では伸び悩む。そういうことは普通に起こります。逆に、実装は人並みでも人と情報の整理になると急に輝く人もいる。優劣ではなく、向いている方角が違うのです。
だから、上流に挑んで「どうにも肌に合わない」と感じたとして、それはあなたの能力が低いということにはなりません。あなたの思考の型が、下流でこそ最大化されるというだけのことかもしれない。そう捉え直せるほうが、よほど健全だと感じます。
どちらが上、という話ではない
世の中の論調が「これからは上流」「上流へ行かないと生き残れない」に傾くほど、私はひとこと添えたくなります。優れた下流エンジニア、深い実装力を持つ人は、AIが普及したこれからも確実に必要とされ続けます。
AIが書いたコードを正しく評価し、危うい設計の予兆を嗅ぎ取り、本当に堅牢なものへ仕上げる。その役割はむしろ価値を増していくはずです。上流へ進むことだけが「正解のキャリア」ではありません。下流を究めるという道も、同じだけ確かな選択です。
大事なのは、上流と下流が別系統だと理解したうえで、自分の思考の型がどちらで生きるかを見極めること。「なんとなく上流のほうが上だから」という理由で、向いていない方角へ無理に舵を切る必要はないのです。
自分の向きを知る、いくつかの手がかり
向き不向きを完璧に事前診断する方法はありません。それでも、自分の傾向を探るヒントはいくつかあります。
たとえば、仕様が曖昧なまま渡されたとき、あなたはストレスを感じるでしょうか、それともむしろ面白いと感じるでしょうか。前者なら下流に、後者なら上流に、思考の型が傾いている可能性があります。あるいは、技術的に難しい問題を一人で解ききった瞬間に喜びを感じるのか、立場の違う人たちが「それでいこう」とまとまった瞬間に喜びを感じるのか。どちらに心が動くかも、ひとつの目安です。
そして何より確かなのは、実際に少しだけ上流の領域に足を踏み入れてみることです。変更仕様の整理から始め、その奥にある業務の意図を考える癖をつける。この入り口の歩き方は、SESエンジニアが上流工程に進むためのロードマップや、SEからPLへキャリアアップするために必要なスキルで具体的に整理しています。やってみて初めて、自分の型が見えてきます。
下流技術者にとっての、最初の上流は「基本設計」
別系統だと言われると、上流は遠い世界のように聞こえるかもしれません。けれど、下流の知見をそのまま足場にして上流の思考を試せる、ちょうどよい入り口があります。基本設計です。
私は、基本設計を単なる仕様書だとは考えていません。あれは、関係者の合意形成の結果をまとめた資料です。何を作るのか、どこまでをこの開発で実現するのかを顧客やチームと擦り合わせ、合意の上で文書に落とす。決まっていないことを決め、人の納得を作るという上流の本質が、基本設計には詰まっています。
同時に、基本設計は下流の知見なしには書けません。この設計で本当に実装が回るのか、性能やデータ構造に無理はないか、既存システムにどう波及するか。作る側の土地勘があるからこそ、地に足のついた設計ができます。業務分析だけのコンサルタントには出せない、実装を知る人間ならではの強みがここで効く。言いかえれば、基本設計とは下流の知見をもって行う上流なのです。
だからこそ、基本設計は下流技術者が目指すべき「最初の上流」になります。実装力という武器を手放さないまま、抽象化し、合意を作り、決まっていないことを決めるという上流の筋肉を、限られた範囲で鍛えられる。要件定義という本丸にいきなり挑むより、はるかに現実的な一歩です。
ひとつだけ注意があります。同じ基本設計でも、すでに決まった要件を仕様書の体裁に書き写すだけの作業だと捉えてしまうと、この入り口は上流への入り口にはなりません。決まったことをなぞるのではなく、何を決めるべきかを自分から問い、関係者の納得を取りにいく。同じ工程を担っていても、その姿勢の差こそが、やがて上流へ進める人とそうでない人を分けていくのだと感じています。
まとめ
上流と下流の違いを、最後に整理しておきます。
両者は一本道の手前と奥ではなく、扱う対象も、正解の有無も、評価のされ方も異なる別系統のスキルです。だからこそ、上流へ進むことは昇進というより学び直しに近く、抽象化・合意形成・曖昧さへの耐性という新しい力を一から養う必要があります。そして残念ながら、そこには向き不向きが存在します。
けれど、その違いを正しく認識できれば、回り道は大きく減ります。自分が上流の思考に向いているなら、覚悟を持って学び直せばいい。その最初の一歩は、下流の知見をそのまま活かせる基本設計にあります。下流の思考でこそ輝くなら、そこを究める道に胸を張ればいい。どちらも、長く現場に必要とされ続ける確かなキャリアです。
「上流をやってみます」と口にする前に、それが別の山を登り直すことだと知っておく。その認識こそが、遠回りに見えて一番の近道になると、私は考えています。
スーパーソフトウエアが考える「任される」の意味
スーパーソフトウエアでは、全員に上流を目指すことを求めてはいません。上流で力を発揮する人もいれば、下流を深く究めて現場を支える人もいる。どちらも、現場から継続して役割を預けられる「任されるエンジニア」です。
大切にしているのは、自分の思考の型を理解し、その強みが最大化される場所で着実に信頼を積み重ねていくこと。上流にも下流にも本物の現場があるからこそ、無理に型を曲げず、自分に合った方角で長く頼られていける。そんな会社でありたいと考えています。
この記事のテーマについて、もっと話を聞いてみたい方へ：
- カジュアル面談を申し込む — 30〜45分のオンライン面談
- 募集職種を見る — 上流SE・PL候補から下流のスペシャリストまでの求人一覧
- 「要件定義できます」の落とし穴 — 上流スキルの中身を具体的に掘り下げた記事
- SESエンジニアが上流工程に進むためのロードマップ — 上流へ足を踏み入れる5ステップ
- SEからPLへキャリアアップするために必要なスキル — SE→PLで問われる力の整理
- 他のキャリア記事を読む — PL／上流工程／キャリアに関する他の記事
