(3)上流指向は正しいのか？
キャリアパスの一つの方向性として上流指向があるわけだが、果たしてこれが正しいのかを考えてみたい。それには、なぜ多くのITエンジニアが上流指向になるのかを考える必要がある。
①上流指向は日本的雇用環境が形成したのだろうか？
多くのITエンジニアが上流指向になる背景には、日本的雇用環境が影響している可能性がある。
良く言われるように、日本の雇用形態は、終身雇用を前提とした年功序列がまだ多く残っている。成果主義や能力主義などの欧米流の雇用形態がもてはやされ、幾つかの企業で導入された時期があったが、結果的に個人主義を助長するなどの弊害が出て、日本では主流にならなかった。能力主義や成果主義を導入した企業も、年功序列との折衷型に舵をきったように見える。最近の傾向を見ても、日本の就業希望者の多くは、安定した雇用環境と協調性を望んでいる。
年功序列型の企業の場合、経験を積んで管理職、上級管理職に、さらに一部の人は役員へと昇るのが一般的なキャリアパスである。ソフトハウスの場合であれば、初級レベルのプログラマーから始まり、経験を積んで上級プログラマーになり、やがてはチームリーダーや部門の管理職になる。
SI企業の技術職の場合は、初級レベルのSE（ITSSの用語を当てはめるならば、アプリケーションスペシャリストやITスペシャリストなど）から始まり、経験を積んでレベルを上げていき、プロジェクトマネージャーや部門の管理職になる、というのが一般的なキャリアパスであろう。
ここで賃金を考慮にいれると、経験年数と収入が比例する年功序列型の企業では、プログラマーよりもSEの方が、SEよりもプロジェクトマネージャーや管理職の方が、収入は高くなる。
日本の雇用形態のもとでは、プログラマー、SE、プロジェクトマネージャーの順に収入が高くなるという順序付けが定着してしまった。そしてこの収入の順序付けが職種の順序付けにもなったと考えられる。
正確に言うならば、この順序付けを形成したもう一つの要因は、元請企業と下請企業の多層の階層構造である。元請企業は管理的な業務、下請企業は作業的要素が大きい業務、という具合に職種の順序付けが形成された。
さて、この順序付けは本当に正しいのだろうか？
プログラマーやSE、プロジェクトマネージャーというのは役割の違いであって、そこに収入や職種の優劣があるのは、少々おかしな気もする。
これはITSSの職種でも同じことである。職種の違いは役割の違いであって、そこに職種の優劣や順序付けは本来ない。本来ないはずであり、ITSSの説明をよく読むとそのことが強調されているのだが、現実には優劣は存在している。
優劣や順序付けはないと説明しているITSSであるが、そのマトリックスをよく見ると、実は上流指向であり、優劣を付けている節がある。
②実はITSSも上流指向で、職種に優劣の順序付けをしているのだろうか？
ITSSのマトリックス（ITスキル標準のフレームワーク）を良く見ると、職種や専門分野によって、レベル7やレベル6が歯抜けのように無いところがある。正確には、レベル3やレベル4の部分でも歯抜けがあるのだが、ここでは上位のレベルに着目する。
具体例を挙げると、ITスペシャリストやアプリケーションスペシャリストにはレベル7は存在しない。従って、これらの職種でレベル6の人が、さらにその先のキャリアパスを探すならば、ITアーキテクトかプロジェクトマネジメント、あるいはコンサルタントを指向することになる。
これは、暗黙のうちに職種に優劣や順序付けが行われているということではないのだろうか？
本当にアプリケーションスペシャリストやITスペシャリストにはレベル7はあり得ないのだろうか？
③プロジェクト組織の構造から考察すると
上流指向について、プロジェクトの組織構造、要員構成から考えてみる。
ここでは一例として、スクラッチ開発の上流工程（要求分析、要件定義）からカットオーバーまでのシステム構築プロジェクトを考える。要員構成は、上流工程では、プロジェクトマネージャーと、業務分析やデータ分析などの上流工程を担当できるSE少人数で構成される。プロジェクトが次の工程へと進むと、システムアーキテクチャ部分を担当するSEや、さらにネットワークやインフラを担当するSE、データベース設計を担当するSEなどが参画してくる。さらに下流工程に進むと、業務プログラムを開発しテストする、プログラマーやテスターなどが参加し、プロジェクト組織の要員数はピークに達する。
その後は内部結合テストを終えるあたりから、要員は漸次減少していく、というのが一般的な組織構造の遷移である。
プロジェクトの組織構造、要員構成から考えると、上流を担当するSEは、相対的に少ない人数である。特にプロジェクトマネージャーや、それをサポートするマネジメント要員（PMOなど）は、コストの面からも少人数にしたい部分であろう。これは企業の組織構造がピラミッド構造になっているのと似ている。上級のマネジメント層は少人数であり、中間のマネジメント層もできるだけ少人数の方が望ましい。マネジメント層が多すぎると管理コストが嵩んで生産性が低下するため、組織のスリム化やリストラが必要になる。
プロジェクトの組織構造もこれと同じで、上流工程で必要になる要員数はそれほど大人数ではない。むしろ、下流工程を担当する要員の方が大人数である。そして、下流工程を担当する要員のスキルが直接、生産性に影響する。
このようにプロジェクトの組織構造から考えると、上流を担当する要員の必要人数は、相対的に少人数である。それにもかかわらず、上流を担当できるSEが不足している、という類の話は良く耳にする。
何故か？ その原因として大きく２つ考えられる。
１つは、専門家と言いつつ、求められるスキルに到達している人が実際には少ないということが想定される。技術の進歩が速い業界であるから、最新の技術を習得しながら専門性のレベルを維持、向上していくことはなかなか大変なことである。
今１つは、専門領域が細分化されたこととあいまって、プロジェクトで必要な専門領域を担当できる要員が、直にアサインできない、ということが想定される。専門領域を担当するSEというのは、プロジェクトのある限られた期間だけ必要になる。そして必要人数も少人数である。つまり、日本の雇用環境と人材調達市場では、そんなに都合良く人がアサインできるほどの流動性がない（=上流工程に関わる人材調達市場の流動性が低い）と考えられる。
一方、下流工程の人材調達は、下請企業やオフショア開発の発達により流動性が高くなったと考えられる。
(4)スキルレベルと価格と需要と供給と
人材を調達する際の価格は、一般に、スキルレベルが高いほど、上流工程になるほど高価格になると考えられる。但し、これはあくまで、「一般には」である。
価格は（多くの場合）需要量と供給量で決まるから、例えば、上流工程を担当できるSEの人数が需要を上回ると価格は低下するはずである。これに類する顕著な例が、弁護士や会計士の世界である。
高度の知識と専門性が要求される弁護士であっても、人材の供給が需要を上回れば（つまり、沢山の人が法曹界を目指せば）、価格が低下するか、あるいは、職に就ける人を限定したり、選別することで価格を維持しようという動きが出てくる。
先に記したように、上流工程で必要とされる人数は相対的に少人数であるから、ある特定の専門領域を目指す人が増えて、需要を上回ると、価格が低下するか、職に就けない人が出てくるはずである。
従って、キャリアパスを考えるときは、今後どのような専門領域が必要とされるのかを考えるとともに、その需要量と供給量も予測する必要がある。
(5)キャリアパスの制約条件と多能工化
あるプログラマーが、上流工程、たとえば金融業務のアプリケーションスペシャリスト（業務分析と業務要件定義が出来て、アプリケーションの構造設計やデータベースの概念設計などが出来るエンジニア）を目指したとしよう。
このプログラマーが所属している企業がソフトウェア・ハウスで、下流工程を中心にビジネス展開している場合、彼がキャリアパスを実現するのは簡単ではないはずである。従って、自らのキャリアパスを強く意識しているエンジニアは、制約条件を考慮してキャリアパスを設計するか、転職するなどの手段を使って制約条件を回避すると考えられる。
今一つキャリアパスを設計する際に考慮すべきことの一つは、多能工化である。
専門領域が細分化され、それぞれの領域の技術が高度になってきた昨今では、一人のエンジニアが複数の領域をカバーすることは難しくなってきたのかもしれない。しかしながら、プロジェクトを管理する側からみると、一人のエンジニアが複数の専門領域をカバーしてくれた方がありがたい。
例えば、あるエンジニアがアプリケーションスペシャリストとソフトウェアデベロップメント（プログラマー）の二つの領域を担当できるとした場合、それぞれを別のエンジニアが担当する場合よりも、上流から下流への情報の引き継ぎがスムーズになるはずであり、引継ぎに関わるコストも低減できるはずである。
このように、エンジニアが自らのキャリアパスを設計する際には、
- 所属する企業や組織の制約条件
- 将来の技術動向と、労働市場における需要・供給の予測
- 専門性のレベルと多能工化の度合い
を意識する必要があるだろう。 |
ITSSのマトリックス（ITスキル標準のフレームワーク）