今回はソフトウェアエンジニア界隈でよく話題に上がる、上流／下流工程とお給料の話についてです。
給料についてよく話題になるのが「大手SIerで上流工程だけやっていてプログラムも書けないエンジニアが高給取りで、下流工程を担当しているバリバリにコーディングできるエンジニアが薄給なのはよくない」というような話です。
過去の自分を振り返ると、私自身やはり上に書いたように「なぜコードすら書けないエンジニアが高給をもらっているのか」というところに疑問を覚えていたこともあったように思います。
ただ、ここ3年程で色々な立場を経験して徐々にこの考え方も変わってきたので、今回はなぜこのようなことが起きてしまうのかということを書いていきたいと思います。
なお例のごとく、ここに書く内容はあくまでも1人の経験に基づく100%主観的な考えですので、IT業界全体に当てはまる話ではないかもしれませんので、その辺はバイアスを除いて扱って頂くようにお願いします。
上流／下流の定義
ここではまず前提として、何を持って上流／下流とするかを決めておきたいと思います。
考え方自体は会社によっても人によってもレベル感や粒度が異なるかと思いますが、今回はざっくりと以下のように定義したいと思います。
- 上流：主に仕様を決めることが仕事のエンジニア
- 下流：主に仕様にもとづいて実装することが仕事のエンジニア
仕様といっても、要求仕様レベルの比較的抽象度の高いものから、外部設計に相当するような抽象度が低めのものまでありますが「ある工程よりも上流は高給、ある工程よりも下流は薄給」という風に、一連のソフトウェア開発の流れを完全に二分して考えるような話ではないです。
むしろ任意の2つの役割を考えたときに「相対的にどちらが上流／下流に位置するか」という程度に考えて頂いて大丈夫かと思います。
立場が変わって見えてきたこと
まず「立場が変わった」について触れておきます。
私は今のベンチャー企業に入って、ざっくりこんな感じで役割が変わってきました。
- 1年目：機械学習エンジニア（途中から非公式なリーダー）
- 2年目：エンジニアリングマネージャー (EM)
- 3年目：VP of Engineering (VPoE)
具体的な業務も役割の変更や会社の状況の移り変わりとともに、様々な店においてある程度変わっていったのですが、今回の記事の内容に関しては「仕事を依頼される側から、依頼する側に変わっていった」という点を認識しておいて頂ければ大丈夫です。
さらに少し言うなら、依頼する仕事の粒度も徐々に粗くなっていった（＝抽象度が高い状態で依頼することが多くなっていった）と言うイメージです。
例えば、リーダーの頃は、
「このプロジェクトのこの部分をお願いします。他の部分は私がやるので」
だったのが、EMやVPoEになると
「このプロジェクトをお願いします」
という感じになっていきました。
さて、ここまで書けば大体見当はつくかと思いますが、このEMやVPoEになってからの仕事の依頼の仕方が、今回の記事で言うところの「抽象度が高い」と呼んでいるもので、逆にリーダーの頃の依頼の仕方が「抽象度の低い」ものになります。
ここで会社の立場から見たときにどっちの仕事の依頼の仕方が楽かというと、当然「抽象度が高い」依頼方法の方が圧倒的に楽です。
まぁこんなざっくりした依頼方法がそもそも良しとされるのかはまた別の話にはなりますが、そこは会社によっても全然異なってくるものなので細かくは考えないこととします。
つまり、言葉の表現として多少不適切な部分もあるかもしれませんが「仕事を楽に依頼できる社員」＝「会社にとって便利な社員」ということになる訳です。
これは具体的に考えてみれば分かるかと思いますが、仕様を全部決めてあげて、担当する部分も細かく割り振ってあげて、逐一レビューしないといけない社員よりも、プロジェクト全体を任せられる社員の方が、会社側がプロジェクトの遂行に要する時間が圧倒的に少なくなりますよね。
そのため「この人にプロジェクトを任せておけば、会社は経営等の本来やるべきことに集中できる」状態を作り出すことができるので、会社にとって非常に希少価値の高い社員になる訳です。
なぜ上流＝抽象度が高い？
では「なぜ上流工程を担当するエンジニア」に抽象度が高い仕事を依頼できるかというところです。
上流工程を担当する人は、それよりも下流にある工程を担当する人と比べると、相対的に視野が広い状態になることが多いです。
例えば、要求仕様を取りまとめて基本設計まで落とし込む人と、それ以降を担当する人とでは、顧客の具体的な要望の温度感や仕様／設計をまとめる上でドキュメントには記載されないちょっとしたニュアンスや情報などの有無が異なるため、やはりどうしても上流側を担当している人の方がプロジェクト全体を俯瞰的に見ることが可能になりやすいです。
そうなると、より広い視野を持てているために、他のエンジニアに対して「指示を出しやすい」立場になることができるようになり、一方で下流工程を担当する人は「指示を受けないといけない」立場になりやすい状態になることが多いです。
そうなると組織構成を見た時にはやはり、上流工程を担当する人は多くのエンジニアを統括しやすい立場になるため、会社から見たときには「この人にプロジェクトを任せて、下流工程を担当するエンジニアを必要人数分だけアサインしておけば問題ないな」となって、会社からそのプロジェクトは一旦手が離れた状態にできる訳です。
まとめ
ここまでの話をまとめると、
- 上流工程を担当するエンジニアは広い視野を持つことが相対的に容易になる
- 視野が広い方が人に「指示を出す」立場になりやすく、逆に視野が狭くなってしまう人は「指示を受ける」側になる
- そのため上流工程を担当するエンジニアの方が、会社から見たときの手離れの良さを考えると、より抽象度の高い状態で仕事を依頼しやすくなる
- その結果、上流工程をやれるエンジニアの方が価値が高くなりやすい
となります。
一方で、本当に優秀な（主に下流を担当する）エンジニアがいるのも事実です。しかし、そのようなエンジニアというのは大体が「作業上はコードを書いているだけかもしれないけど、実態としては上流工程もしっかり考慮している」ということが多いかと思います。
そういう意味では、世間の言説を真に受けて「下流工程だけやるスペシャリスト」という姿を目指していると、貰える給料やエンジニアとしての価値という観点では遅かれ早かれどこかで頭打ちになってしまうんだろうなと思います。
おすすめ記事
こちらにおすすめ記事をまとめているので、もしよかったらこちらもご覧ください。