Windows Serverを中心に、ITプロ向け教育コースを担当

ITエンジニアのキャリアパス

»

 月刊「Windows Server World」の連載コラム「IT嫌いはまだ早い」の編集前原稿です。もし、このコラムを読んで面白いと思ったら、ぜひバックナンバー(2006年12月号)をお求めください。もっと面白いはずです。なお、本文中の情報は原則として連載当時のものですのでご了承ください。

■□■

 IT業界には実にさまざまな職種がある。その中には、IT業界に入って最初に務める職種もあれば、一定のキャリアを積んでから務める職種もある。また、意図的、あるいは偶然に職種転換を行うこともある。

 今月は、ITエンジニアの職種転換、つまりキャリアパスの話である。誌面の都合で今回はプログラマ系の職種に限定するが、他の職種でも成り立つ部分があるはずだ。

●ITエンジニアの職種

 同じITエンジニアであっても、職種によってステータスが違う。高いステータスの職種は、それだけ多くの経験が必要とされているからだ。筆者が日頃から感じている主観的序列は以下のとおりである。

  1. コンサルタント(顧客の潜在的な要求を具体化する人)
  2. アーキテクト(その要求を実現する方法の全体像-アーキテクチャ-を決める人)
  3. システムエンジニア(そのアーキテクチャに従って、具体的な実現方法を決める人)
  4. 上流プログラマ(具体的な実現方法に従って、プログラムの構造を決める人)
  5. 下流プログラマ(プログラムの構造に従って、実際のプログラムを作る人)

 IT系エンジニアとして仕事を始める場合、通常は下流プログラマからスタートする。「下流」といっても「二流」の意味ではない。IT業界ではハードウェアに近い方を「下」、顧客に近い方を「上」と呼ぶ習慣がある。

 下流プログラマは、コンピュータで動かすプログラムを直接作る作業を担当する。与えられた条件で、最高の性能を実現し、読みやすいプログラムを作成することが下流プログラマの仕事である。

 ただし下流プログラマの仕事の中には、本当に単純な作業も含まれる。最初に担当する仕事はそういう作業だ。

 下流プログラマの経験を積んだら、上流プログラマに徐々に移行する。上流プログラマは、与えられた問題解決の手順(アルゴリズム)やデータの表現方法(データ構造)を考える。抽象度の高い仕事なので、プログラムの動作を深く理解していないと務まらない。コーディングを知らない上流プログラマは実現不可能な案を提案しがちだし、アルゴリズムとデータ構造を知らない下流プログラマは保守性の悪いプログラムを作りがちである。レベルの高いエンジニアになるには上流・下流両方のスキルが不可欠である。

 システムエンジニア(SE)は、上流プログラマの仕事の一部も担当するが、主な仕事は顧客にインタビューして、顧客が何をしたいのかを明らかにすることである。そういう意味ではコンサルタントの仕事も含まれる。コンサルタントは、顧客の潜在的な要求を引き出し具体化する人だ。

 最近では、1つのプログラムが巨大化しているし、複数のプログラムを連係して使うことが増えてきた。そのため、プログラムの全体像を、首尾一貫した整合性の取れたものにしておかなければならない。こうした仕事をする人がアーキテクトである。

 アーキテクトの仕事は元々SEや上流プログラマが行っていたが、最近は独立した職種になってきた。一般的にはSEや上流プログラマの次のステップとされている。アーキテクトからコンサルタントに移行する人もいる。

 さて、こうして列挙してみると、ITエンジニアのキャリアパスは、5から1へ向かっていることが分かる。ステータスもそれにつれて高くなる。このように、キャリアパスとステータスが連動しているのは健全な姿である。

 もちろん、プログラムを書くのが好きな人もいるだろう。そういう人は下流プログラマに留まっても構わない。ただ、自分の作ったプログラムが、システム全体でどのように役立っていて、作ったシステムが顧客のビジネスにどのように影響を与えているかを知っておくことは、良質な仕事をする上で不可欠だ。そのためには、SEやアーキテクトとしての仕事を知っておくことは悪くない。

●ITエンジニアのキャリアパス

 実は、多くのエンジニアが悩むのはエンジニアのキャリアパスではなく、マネージャになるかどうかの選択である。多くの人は、SEを務めたあたりで一般管理職にならないかという打診がある。

 ほとんどのエンジニアはここで迷う。マネージャになると、自分の好きな技術から遠ざかってしまうからだ。中には「プレイング・マネージャ」として活躍する人もいるが、それで成果を出せる人は決して多くない。マネージャとしての仕事とエンジニアとしての仕事を両立させるのは非常に困難である。

 一流スポーツ選手が一流監督になるとは限らないように、一流エンジニアが一流マネージャになるとは限らない(*1)。マネージャになっても成功するとは限らないという不安があるので、迷いはますます大きくなる。

 もっと問題なのは、いったんマネージャになったら、エンジニアに戻る方法が事実上ないということだ。多くのIT系企業は、「マネージャとエンジニアは対等であり、職種転換は可能である」と主張する。しかし、実際にはエンジニアからマネージャへの転換は多くないような印象を筆者は受けている。一般には、エンジニアからマネージャへの転換「降格」という印象を持つ人が多いことも原因の1つだろう。

●まずやってみる

 しかし、そうしたリスクがあったとしても、もしマネージャになる機会があれば、受けた方がよいと思う。もしかしたら、自分の隠れた才能を引き出してくれるかもしれないからだ。最悪でもマネージャの仕事が何なのかを知ることができる。これは、今後の職業人生に大きなプラスになる。

 ただし、マネージャとして成功しなかった場合や、マネージャの仕事にどうしても興味を持てなかった場合のリスク対策は必要だろう。まず、成果を出せなかったらエンジニアに戻してもらうように言っておく。もっとも、こうした約束はあまり期待しない方がよい。すぐ反故にされる。

 転職は1つの選択肢だ。何かが嫌で転職することはおすすめしないが、何かしたいことがあって転職するのは悪くない。ただし、転職先の本当の状況は分からないという大きなリスクもある。

 筆者がおすすめする方法は、自分が進みたい方向の業績で、社外で有名になることだ。ただし、社外「だけ」で有名になると、社内での評判を落とし、自分の意見が通らなくなるので注意して欲しい。

 社内に有名人を抱えていると、経営者は、その力をもっと発揮させたいと思うものだ。さらに直接的には、重要な得意先の、なるべく偉い人にお願いするという方法もある。「ところで、XXXさん、最近現場に出てないようだけど何してるの」と聞いてもらう。

 圧力をかけるような言い方だと反感を買うかもしれないが、最悪の場合はそれも選択肢の1つだ。この時、自分の直属上司ではなく、さらに上の職位の人、たとえば事業部長と話をしてもらおう。事業部長は、きっと「XXXって、誰だ」ということになるだろう。調べたら、どうも一流エンジニアだったのに、マネージャになって成果が出ていないらしいということになる。「だったら、いっそエンジニアに戻そう」と話が進む(かもしれない)。これでうまくいかなければ、自分の力量が足りないということだ。別の方法を探して欲しい。

 有名になる方法で、手っ取り早いのはオンラインコミュニティへの参加である。Windows系のエンジニアなら、Microsoft MVPになるというのも効果的だ。最近は人数が増えてきて、MVPの価値も相対的に低下したようなきらいもあるが、それでも効果はある。少なくとも、マイクロソフト社内での知名度向上には貢献する。

 オンラインコミュニティで頭角を現し、MVPに選出されるには、それだけの技術力と自分の技術力をアピールする力が必要なことはいうまでもない。単に「有名になりたい」だけではだめだ。だからこそ効果があるのである。優れたエンジニアは、自分のキャリアパスを自分で選択できる。しかし、そうでなければ選択の余地がないどころか、首を切られる恐れすらある。厳しいようだが頑張って欲しい。

 だれでも持っている人は更に与えられて豊かになるが、持っていない人は持っているものまでも取り上げられる。[マタイによる福音書25章29節(新共同訳)](*2)

 (*1)「優秀なマネージャになったエンジニアはいない」とマイクロソフト社員に言われたので「Bill Gatesがいるじゃないですか」と答えたら「それはどうかなあ」と返された。経営者としては優秀だが、マネージャとしてはそうでもないかもしれない。古川享氏のブログを読んでそう思った。

 (*2)これは、与えられたタラントン(当時のお金の単位、英語ではtalent)を使って儲けた人と、何もしなかった人についてのエピソードである。タラントンは、タレント(才能)の語源となった。

■□■Web版のためのあとがき■□■

 エンジニアのキャリアパスが問題になるのは、上級エンジニアのステータスが低いからではないかと思う。では、エンジニアのステータスを上げるにはどうすればいいだろう。筆者は2つの条件があると考える。第1に「上級エンジニアの給料が上がること」、第2に「上級エンジニアが尊敬の対象になること」である。

 上級プログラマの生産性は、初級プログラマの10倍に至ることも珍しくない。数ある職業で、これほど差の付く分野はそれほど多くない。にもかかわらず、給与はせいぜい2倍だ。おそらく部長の給料よりは安いだろう。これではやる気も出ないし、目指すべきキャリアパスとは言えない。

 給料が安くても、社会的なステータスが高ければ満足できる人もいるだろう。しかし、エンジニアは尊敬の対象となるだろうか。同じ技術系でも、科学系だと大学教授のような名誉職がある。大学教授の給料は決して高くないが社会的ステータスは高い。たまに不祥事を起こす人もいるが、ニュースになるということ自体ステータスの高さの表れだろう。ところが、エンジニアが工学系の大学教授になったという話はそれほど多くない。筆者の知人に限れば数人である。決して少なくはないが、一般的なキャリアパスではない。

 筆者自身、答えは持っていないが、そろそろ引退の時期を模索する年齢が近づいてきた。継続的に考えていきたい。

Comment(1)

コメント

しっぱ

こんにちは。しっぱと申します。

この手のお話って難しいですよね。
SIer時代は上流を目指すってことがキャリアパスでした。
反して、現在のWEB屋では上級エンジニアが評価されます。

あくまで私の状況からの想像ですが、

SIerではプロジェクトを円滑に進め、利益を創出する人に評価をします。

WEB屋では効率的にプログラムを作れる人が評価されます。

といったイメージですね。

私個人の感覚として「上流」「下流」って言葉も良くないですよね。。。。
横山様が解説されている通りハードに対しての言葉なんですが、
どうも「上=上司」的なイメージが着きまといますね。。。。

本来であればそれぞれ1~5の分野において総合的に人を評価してほしいものですが、役職や担当業務によって評価自体ができないことが多いですね。
そこから本来もっと違う現場であれば力を発揮できるだろう人材の流出にもつながります。
今までそういう場面を見てきました。

実際に私の上司で非常に評判が悪い方がいたのですが、あるプロジェクトでその方の直属の部下になったのですが、非常にお客様からの評判も良く、業績もあげられました。

現場に恵まれなかっただけなのかもしれません。

かくいう私はその後、逆に合わない現場に配属され給料をがっつり落とされましたが^^;
配属PJによって評価の仕方が変わってしまうのはしょうがないのでしょうが、横山様のおっしゃられている通り、「有名になる」ことをしっかり押さえる必要があるのかもしれませんね。

ただし、過剰な期待を持って迎えられるリスクはありますが・・・・・

コメントを投稿する