読書記録：具体と抽象

ビフォー（本を読む前の自分）

私にはずっと腑に落ちなかったことがあります。
それは、
「なぜコンサルの単価はエンジニアよりも高いのか？」
です。
私がまだ若手社員だった頃、自分の働くSIer企業でITコンサルとシステムエンジニアの両方の部署での仕事を経験しました。
若手なのでまだまだ仕事を一人でこなすには程遠い状態にも関わらず、コンサル部署で私はエンジニア部署の10歳上の先輩よりも高い単価で働いていました。
そして自分も、コンサル部署からエンジニア部署に移動すると単価が自動的に下がりました。

どう考えても仕事での貢献度は私のほうが低いのにも関わらず、先輩よりも高単価になるのか？
部署が変わっただけで自分の能力は変わらないにも関わらず、どうしてこんなに単価に差がつくのか？
パワポ資料しか作らないコンサルよりも、動くものを作ることができるエンジニアの方が価値を生み出しているのではないのか？
そんなモヤモヤに対して納得できる答えを自分の中で持てないまま、「世の中そういうものなのだ」とスルーし続けていましたが、この本を読んでやっと納得できる考え方を見つける事ができました。

具体と抽象

気づき

それは、
抽象度が低い仕事よりも高い仕事の方が、1人で扱うことができる範囲が広くなる
ということです。

例えば同じシステムを対象にした仕事でも、コンサルはシステムの全体構想を、エンジニアは上流工程の計画に沿ってシステム設計・構築を行います。
V字モデルの工程に沿ってシステム化計画からシステム開発に進むに従い、より具体性が増していくと同時に関わる要員の数も増えていきます。
つまり、システムというものをより抽象的に扱っているコンサルの方が、浅く広くではあっても、一人でより広い範囲をカバーしているという状態になります。
単価の違いは、専門性や能力の違いではなく、仕事の重要度でもなく、こんなシンプルな話だったのだと気付かされました。

TODO

とは言え、抽象度の高いテーマを扱うには「抽象化された考え方を別のシステム・分野・業界・世界にも応用すること」が求められるという難しさがあるので、これは日々トレーニングを積んで身につけてる必要があると思いました。
個別に発生する問題に対しどのような根本課題があるのかを考えたり、上手く行ったことはなぜうまく行ったのか？次に活かすには？を明文化したり、そんなことを繰り返しながら、具体⇔抽象トレーニングを積んでいこうと思います。