開発系エンジニアのスキルロードマップ Part 3


(このエントリは Part 2 からの続きです。)

さて、Part 2 のエントリでは、開発系エンジニアの 5 つの分類を示しました。この 5 つのロールに関して、昨今のトレンド及び育成ロードマップがどのようなものであるべきか、自身のスキルを高め、市場価値を高めるためにはどうならなければいけないのかについて考えてみたいと思います。

image

[① 業務 SE (要件定義・業務設計)について]

私がこの IT 業界に飛び込んだ頃は、まだ要件定義や業務設計に関してはあまり情報が整理されていませんでした。しかし、最近は要件定義手法に関する研究が進んできており、書店にも多数の書籍が並ぶようになりました。「要求開発」といった手法や考え方が出てきたり、また特に品質特性(非機能要件)の領域に関する研究の深化などにより、従来に比べてかなり方法論が整ってきた感があります。また、パッケージ製品や SaaS が適用できる領域も増えつつあり、メールなどの IT インフラ領域だけでなく、販売管理や顧客管理などの領域でも、パッケージ製品や SaaS 利用ができるようになってきています。こうした中で、「業務」のことだけを見て、技術のことを知らずに業務設計を行うと、「実現不可能な」システムになってしまったり、「コストがかかりすぎる」システムになってしまう危険性もあります。

こうしたことを踏まえると、業務 SE のスキルロードマップとしては以下のようなものが考えられます。すなわち、まず入社直後は一般的なモデリング技術や業務分析手法を習得して基本的なスキルを身に着け、その後、技術スキルをベースとして、業界・業種知識を伸ばしていきます。最後には、業界・業種に関する深い造詣を元に業務コンサルティング領域へと踏み出していき、業務の To-Be モデルの策定や、実現可能な業務システムの提案・設計ができるようになっていくことが一つのゴールとなってくるでしょう。

image

[② アーキテクト(方式設計)について]

前述したように、アーキテクトはシステムの実現方式やアプリケーションの作り方を決定し、それを開発チームで実践する役割を担っています。このため、アーキテクトロールは開発チームの中で非常に重要な役割を担っていますが、アーキテクトを取り巻く環境は厳しくなる一方です。特に厳しいのは、昨今の開発技術の複雑化です。UI の多様化(Web, RIA, スマクラ, モバイル)、クラウドコンピューティングなど、システムのプラットフォームが一気に複雑化してきており、こうした多種多彩な技術に深い造詣を持つエンジニアの希少性が一段と高くなってきています。このため、どこの会社もアーキテクト不足に悩んでいる、というのが実情でしょう。

また、アーキテクトの重要性が頻繁に語られる割には、「アーキテクチャ」の詳細に関する業界標準がないのも大きな課題です。例えば、何を以て「アーキテクチャ」とするのか? また標準化としては何をすべきか? に関しては、業界内で統一的な見解がなく、例えば SIer 各社がノウハウを持っていたとしても、社外に対して公開されたり share されたりすることがなく、ノウハウを外部から入手することが困難、という難しさもあります。また、方式設計(アーキテクチャ設計)は「机上の空論」ではなく「実践可能」でなければなりませんので、高度なテクニカルスキルも求められます。簡単に言えば、多種多彩な開発技術に対して深い造詣を持つと共に、そこからアーキテクチャに関して自分なりの見解を組み立てるスキルが求められるのが、アーキテクトというロールだと言えます。

ただし、最終的なゴールは前述したように、自分でアーキテクチャを考えるだけではなく、それを流布させ定着させていくことです。ここまで含めて考えると、アーキテクトとして目指すべき最終的なゴールは、教育的視点まで含んだ開発標準化の実践、というところになっていくでしょう。

image

[③ デベロッパー(内部設計・実装)について]

Part 1 にて解説したように、昨今のアプリケーション開発の特徴は、内部設計と実装の距離が大きく縮まっていることです。すなわち、実装の手間が軽減されることで、内部設計がダイレクトに実装に直結するスタイルに近づいてきており、内部設計者がそのまま実装することが可能になってきています。このことは、裏を返せば、内部設計スキルのないエンジニアがツールやフレームワークを誤用すると、品質に大きな難のあるアプリケーションが出来やすいということでもあります。このため、デベロッパーの人たちは、コーディングのスキルだけでなく、内部設計のスキルを高めていくことが非常に重要になっていると言えます。

ところが現場の実情を見ると、特に若手デベロッパーに、基礎スキルの不足の傾向がみられます。これは、ウィザードやツールを多用した開発の練習ばかりしているためで、内部の動きや作業の意味を理解しないまま、技術の勉強を進めているためでしょう。ひどいケースになると、変数定義やインスタンス生成などの基本的な意味がわかっていないことすらありましたが;、こうしたことを避けるためには、単に表面的なツールの使い方やコーディング方法を勉強するのではなく、裏側の動きまで含めた、一歩踏み込んだ学習をしていかなければなりません。そうしたことを怠ると、その場しのぎの作業がどんどん増えていき、最後にはインターネットからコードをコピペしまくる「Copy & Paste」デベロッパーになってしまいます。でも、こうしたデベロッパーは確実に淘汰されます。オフショアなどとの価格競争に巻き込まれないようにするには、デベロッパーとしての生産性や付加価値をどのように守っていくのか、どのようにそれらを向上させていくのかを、真剣に考える必要があります。なぜなら、今でもフレームワークや共通部品群、アプリケーションの中核部分は開発が難しく、スキルの高いデベロッパーにしか作れないからです。基本的には、デベロッパーが自身の市場価値を維持・向上する方法は以下の 2 つのいずれかだと思います。

  • ツールを最大限に生かし、開発生産性を大幅に高めること
  • 他の人には作れないような高度なコードを開発できるようになること

要するに、「早く・安く・上手く作れる」ことが、デベロッパーの目指すゴールとなります。

image

[④ テスター(結合機能テスト・システムテスト)について]

システム開発の世界におけるテスターというのは、以前は肩身の狭い職種だったように思いますが、最近になって、テストはデバッグとは違うということ、すなわちテストとは品質評価であることが、ようやく認知され始めてきました。米国では、ここ 5~10 年ほどで現場での研究ノウハウがようやく結実し始め、書籍などの形で入手しやすくなってきています。実際、マイクロソフトも Visual Studio 2010 でようやく本格的なテストツール Microsoft Test & Lab Manager (略称 MTLM)をリリースし、科学的なアプローチに基づく「品質評価」を実践しやすい環境が、ツール面でも整ってきました。

しかし残念なことに、日本の開発現場の多くは旧態依然としたテストが実践されており、KKD (勘と経験と度胸)でテストが行われてしまっていることが多いと思います。システム開発を生業としている SIer ですら、製造業のような高度な品質管理はほとんど実践されておらず、テストの専門性が認知されていないことすらあるのではないでしょうか? 先進的な企業ではこうした部分にメスが入りつつありますが、米国に比べるとまだまだ遅れは大きい状況ではないかと思います。実際、日本ではテスターの人数や品質評価作業の工数が削られがちで、例えばテスト工数の削減となると、すぐさま「ツールによる自動化」に飛びついて解決を図ろうとする安直な考え方が目立ちます。テスト工数を削減する際には、まず テスト実施計画の最適化やテストケース設計の見直しを行うべきなのですが、このような考え方では、せっかくツールがあってもそれを使いこなしたり生かしたりすることは難しいでしょう。

こうしたことから、今のシステム開発の世界においてテスターの専門家を目指そうとするのは、日本の場合、かなり茨の道になる可能性もあります。しかしその一方で、今後さらに重要性を帯びてくる領域でもあるため、この分野のスキルを伸ばしておくことは非常に重要になってくると思います(実際、この領域に関する問い合わせはここ最近非常に増えてきています)。この分野のスキルを伸ばそうとする場合には、まず正しいテストの考え方を理解すること、そしてテストケース設計やテスト実施に関するノウハウを身に着けていくことが大切です。テストツールを使った自動化などは最後に学ぶべきことで、確たる知識ベースラインに基づいて学習しないと、ツールに振り回されることになるため注意が必要です。最終的には、テスト実施計画、テストケース設計、テスト結果分析を通して、システムの品質を可視化・定量化できるようになることがテスターとしてのゴールです。

image

[⑤ プロジェクトマネージャー(プロジェクトマネジメント)について]

プロジェクトマネジメントを取り巻く環境については、ここ 10 年で大きく変化しました。特に大きいのは、PMBOK のようなプロジェクトマネジメントに対する知識体系の整理や、Team Foundation Server (TFS)に代表されるような、高度なプロジェクト管理システムが安価・容易に入手できるようになったことだと思います。後者は非常に重要で、従来、「プロジェクト管理のため」に行われていた手作業の報告作業や集計作業が、一部とはいえ自動化できるようになったところは非常に大きいと思います。Agile 型(XP, RUP, Scrum など)のような開発プロセスであっても数値ベースでプロジェクトを管理できるようになったのは、こうした開発管理システムがあったからこそ、ではないかと思います。

しかしその一方で、プロジェクト管理においてプロジェクトを数値ベースで管理できるようにすること、すなわちプロジェクトの「見える化」をするためには、それ相応の「仕掛け」が必要になります。つまり、プロジェクトメンバに、「データ収集を意識させない」仕組みを作り、日常作業を普通にこなしているだけでデータが収集されるような仕組みを組み立てておく必要があります。そのために、プロジェクトマネージャは以下のような仕組みを組み立て上げておかなければなりません。

image

プロジェクトマネジメントの世界では、コミュニケーションスキルに代表されるようなスキルが重要視されます。こうした部分のスキルロードマップの考え方については、PMBOK やそれに関連する部分で十分に体系化されていると思いますのでここでは述べませんが、実務レベルで見た場合、上記のような「プロジェクトマネジメントのために必要なプロジェクトの計測手法」を考え出し、「プロジェクト状況の計測システム」を作り込むことも重要です。実際のシステム構築は、アーキテクトやデベロッパーの手を借りながら進めることになりますが、こうした作業が必要であることも、ぜひ意識していただければと思います。

[T 字型スキルの必要性と重要性]

なお、ここまで話を簡単にするために、5 つの開発系エンジニアのスキルを完全に個別にものとして紹介してきましたが、実際にはこの 5 つのスキルエリアは排他なものではなく、どちらかというと、どこかに高い専門性を持ちつつも、他のスキルエリアについてもある程度は広く知っているようにするべきものだと思います(いわゆる「T 字型スキル」と呼ばれるもの)。私自身は、②のアーキテクトとしてのスキルをメインとしながら、③ デベロッパースキルや④ テスタースキルもある程度掛け持ちしている、という感じですが、例えば SIer の人であれば、①④⑤あたりの掛け持ちが必要になってくるのではないかと思います。どんなスキルがどの程度求められるのかは、プロジェクト規模や企業規模などによって随分状況が異なると思いますが、こうした考え方のフレームワークを持っていると、何かと考えやすいのではないかと思います。

[キャリアパスとしての技術系コンサルタント]

さて、ここまで開発系エンジニアのタイプとそれぞれのスキルロードマップについて解説してきましたが、それとは別にひとつ、悩ましい課題について考えておく必要があります。それは、企業の中でのキャリアパスの問題です。

Part 1. のエントリの中でも触れたことですが、日本企業の場合、開発系エンジニアには、ひとつのロードマップ(=ひとつのキャリアパス)しか与えられていないことがしばしばあります。専門職としてのキャリアはある程度のところで頭打ちとなり、それ以上に昇級していきたければ、管理職(マネジメント)になるしかない……といったような企業は、残念ながら日本の場合は少なくないと思います。これに対して外資系の企業、例えばマイクロソフトなどでは、(製品を作る会社だからという理由も大きいのでしょうが)エンジニアとして高いレベルまで昇級していくことが可能になっており、例えば私自身、自分のマネージャよりも自分の方が(年齢も若いのに)職位が高いという逆転現象を起こしたこともありました。要するに、専門職には専門職のキャリアパスが、管理職(ピープルマネージャ)には管理職のキャリアパスが用意されているということであり、管理職の方が専門職よりも必ず偉いという仕組みにはなっていません。無論、そうした上級専門職の人には、給料に見合った高いアウトプットを出すことが求められるので非常に大変ではあるのですが;、少なくとも制度として、専門職の職位に関して上限(キャップ)が低く設定されているようなことはないわけです。日本企業でも、ハイスキルな人材の流出を防ぎ、社内にキープできるようにするよう、専門職でありながら管理職と同等、あるいはそれ以上の職位を設けるといった動きが出てきてはいるものの、こうした動きはまだまだ全体としては少ない状況だと思います。日本だと、現実にはもっと基本的なこととして、年功序列制度が色濃く残っているようなケースの方が多いのではないでしょうか?

年功序列制度や、専門職・管理職の上下関係などについては、当然、良い面・悪い面があり、是非や功罪を一側面的に論じられるものではないのでここでは立ち入りませんが、ある個人として会社を見た場合、人によってはこうした仕組みが足かせのように感じられるケースはあると思います。開発系エンジニアとしてのスキルを思いっきり伸ばしたいとか、あるいはまだまだ専門職で自分の力を伸ばしていきたいとか、そういった人たちにとって、こうした仕組みはもしかしたら邪魔に感じられるかもしれません。このような場合には、状況によっては、社外へ転職する(技術系コンサルタントへの転職)というのも、キャリアパスのひとつの選択肢として考えるべきだと私は思います。社外に出ることによって得られる経験や知見は、それはそれで高い価値があるからです。

その一方で、安易な考え方(例えば今の会社がイヤだとか上司とそりが合わないとか;)で社外への転職を考えることは、あまりお奨めできません。私自身、マイクロソフトのコンサルタントになるにはどうすればいいんですか? といった相談を受けることがあります。これは別にマイクロソフトの技術コンサルタントに限った話ではないのだと思いますが、外資系企業の技術系コンサルタントを目指そうとする場合には、① 技術力がちゃんとあって、② その技術力を現場で駆使して、③ それを他の人に伝えていける、という高いベースラインスキルを持っているだけではなく、さらに厳しい環境に身を置く覚悟が必要とされるからです。後ろ向きな気持ちではなく、前向きな気持ちで「もっと上を目指したい!」と意欲的に考えられるときに、ひとつの候補として挙げられるものではないかと思います。

実は私が所属しているコンサルティングサービス統括本部では、現在、開発系コンサルタントの募集を行っていて、採用枠もあるのですが、こういうものを見ても、なかなか怖くて食指が動かなかったり、あるいは逆に安易な気持ちや後ろ向きな気持ちで応募したりすることが現実的には多いのではないかと思います。しかしどちらのケースも、応募する側・される側両方にとって不幸なことだと思います。いきなり応募!の前に、もうちょっとカジュアルに、自分のキャリアのことを考えたり、仕事の実情を知ることはとても大切なことです。今回、そんな話を人事の担当者と話したら、だったら小さめのカジュアルなセミナーを開いてみては? という話をもらいました。マイクロソフトのコンサルタントという職種に興味はあるんだけど、自分が応募すべきかどうかが分からない、そもそもコンサルタントってどんな仕事をしているんだろう? といった興味を持っている方向けにセミナーを開いてみたいと思いますので、よかったらこちらのページから応募してみてください。(万が一好評だったらリピート開催してみようかと思います。すでにセミナーが終わっていたら、私にメールで個別にコンタクトしてみてください^^。)

# ちなみに同様の話として、女性のエンジニアとしてのキャリアについて悩んでいる方もいるかと思います。
# そういった方には、女性向けのセミナーもあるそうなので、よかったら参加してみてください。何かヒントが得られるかもしれません。

実際に社外に応募する・しないにかかわらず、そうした職種の選択肢の存在を知っておくことも大切ではないかと思います。エンジニアとしてのキャリアに迷われている方や、技術系コンサルタントという職種に興味のある方は、参加してみていただければと思います。

[まとめ]

というわけでいろいろと説明してきましたが、要点をまとめると以下のようになります。

  • 昨今の開発技術の深化により、ブルーカラー的な単純労働は非常に少なくなってきている。
    • スキルの高い人でないと、Visual Studio などの高い開発生産性ツールの良さを十分に引き出すことができない。
    • このため、デベロッパーは自分たちのスキルを維持・向上させることが極めて重要。
  • 直接、内部設計や実装などを行わない SIer においても、やはりテクニカルスキルは重要である。
    • プロジェクト管理やチームリードなどの「単価の高い」業務へのリソース集中は重要だが、やりすぎるとコアコンピテンスを失う。
    • コアコンピテンスを維持するためにも、ベースラインスキルを維持すること(日々の基礎トレ)は欠かしてはならない。
  • スキル強化を考える場合には、座学(トレーニング)と OJT のバランスを意識する。
    • 基礎学力を応用問題(OJT)だけで身に着けるのは効率が悪すぎる。
    • 基礎学力なしで応用問題(OJT)を学ぼうとすると、場当たり的・その場しのぎのパッチ的な解決策に走りやすくなる。
  • 開発系エンジニアのスキルを考える場合には、5 つの専門分野に分けて捉えると分かりやすい。
    • 業務 SE(要件定義や業務設計を担当)
    • アーキテクト(方式設計などの設計・実装標準化を担当)
    • デベロッパー(内部設計や実装を担当)
    • テスター(テストと品質評価を担当)
    • プロジェクトマネージャ(プロジェクト管理を担当)
  • スキルアップを考える場合には、自分がどの専門分野を特に得意とするのか、どこを特に伸ばしたいのかを意識するとよい。

会社にとって、社員の市場価値を守ることは会社の価値を守るために必要ですが、だからといって個々人が自分の市場価値を守ることを会社にまかせっきりにしてはいけない、と私は思います。自分の市場価値を維持し向上していくことは、基本的には自分の責任、ではないでしょうか? この話は正解や結論のない話ではありますが、本エントリが、ご自身のスキルや市場価値、キャリアなどに悩まれている方の、何らかのヒントになることを願っています。

Comments (0)

Skip to main content