連載「エンジニアを導く、新しい学びのロードマップ」
2021年、IoTやAIの活用普及、そしてコロナ禍を経験し、新しい時代がやってきます。ITの開発現場は、曖昧な要望を具体化し、プログラミングして動かすことは変わっていません。しかし、Stay Homeだけでなく、コンピュータ性能の低コスト化とサービス化、そしてネットワークも含めた劇的な進化は止まりません。開発スタイルもこの進化に追従する為に、協調した作業を支援する方法論やツールが現場で実践されています。
この連載では、エンジニアの学び支援する方々（企業の教育部門や高等教育機関）へ向けて、未来をつくるエンジニアの学びについて情報を提供します。テクノロジーを使いこなせる人材を育成するために必要なモノ・コトは何かを考え、新しい潮流を踏まえて整理を試みます。
＊連載「エンジニアを導く、新しい学びのロードマップ」の過去記事はこちら
１．【新連載】学びにおける知識と行動の分離評価による教育効果の最大化
２．【連載】教育担当者が意識すべき、人材育成と企業収益の関係性とは
３．【連載】氷山モデルでみる、人材育成に欠かせないスキルの見える化
４．【連載】ITエンジニアのOJTで身につけたいスキルと指導方法とは
５．【連載】教育カリキュラム開発のセオリー「ID」を知り、活用する
６．【連載】教育担当者と現場管理者が鍵、 収益と企業価値の向上をもたらす人材育成とは
７．【連載】SECIモデルで考える、組織競争力を高める人材育成施策
８．【連載】エンジニア「スキルレベル」の考え方と高め方
前回はエンジニアのスキルレベルについて、レベル感の考え方や、レベルの向上方法について紹介しました。技能として個人が身体的（エンジニアの場合、頭がメイン）に身につける能力や、基礎的なスキルから高度なスキルへの向上方法などでした。今回はエンジニアの出来ることを一言で表現する呼称であるキャリアについて、レベル感の考え方と、キャリアレベルの向上方法についてです。
一般的に広く使われる「キャリアアップ」という言葉は、収入や組織での立場を高くすることを意味しています。課長、部長という組織での役職の観点や、その職種としてのレベルを上げる観点、また中小企業から大企業への転職という観点もあり、対外的な見え方や収入アップ、自己実現や働き方の選択など、キャリアアップという言葉には色々な要素が含まれています。
ITシステム開発の場合はどうでしょうか？「プログラマーからマネージャになる」「普通のプログラマーからスーパープログラマーになる」これらは私がこの業界に入った当時から変わらぬ代表的なキャリアアップのイメージです。
今回はこのITシステム開発におけるキャリアアップについて考えるために、キャリアの定義、キャリアレベルの定義、キャリアレベルの高め方について紹介します。
キャリアの定義
ITシステム開発におけるキャリアは、プログラマーやプロジェクトマネージャが代表的です。現在は人材育成や人材活用のために、より具体的に細分化されていますし、求人情報や案件情報では、アプリケーションエンジニア、アーキテクト、ITスペシャリスト、コンサルタント、テストエンジニア、データアナリストなど、数多くの職種が使われています。
そんな中、iCD（ iコンピテンシディクショナリ※1）では、キャリアという表現でなく、ITSS、UISS、ETSSなど毎に職種で定義されています。
・ITSS
ITシステム開発を担うITベンダやソフト開発のIT人材を対象にしたスキル標準
・UISS
ITシステムを利用する企業でのIT人材を対象にしたスキル標準
・ETSS
製品に組み込まれるソフトウェアを開発する企業でのIT人材を対象にしたスキル標準
また、iCDではこれらのスキル標準以外にも、情報セキュリティやクラウド、IoTに関する職種も定義されています。職種とは、その人の仕事における特徴や役割を表すラベルみたいなものです。関係者が、そのラベル名を聞くことで、その人の特徴や出来ることをイメージするために使われると言って良いと思います。
しかし、スキル標準に関する仕事をしていると「私の職種は○○○と言われますが、違和感があるのですよね」という話をよく聞きます。例えば、プログラマーと呼ばれるけど、プログラミング以外に仕様定義から設計、テストさらにはチームの進捗管理までやっている場合があります。この場合、プログラマーでなく、プログラミングもタスクや役割に入っているソフトウェアエンジニアの方が適切になります。
この職種名は、スポーツにおけるポジションで考えるとわかりやすいです。（図１参照）
（図１）
野球におけるピッチャー・キャッチャー・外野手、サッカーではフォワード・ディフェンス・キーパーなど、どんなスキルを持ちどんな役割を果たすのか、ポジション名で大体理解し共有できます。ラグビーとサッカーではポジション名が同じですが、役割が違ったりしますので、ある意味、ここでのスポーツはITシステム開発におけるドメインと考えてもいいかもしれません。競技名が「金融システム開発」や「車載組込みソフトウェア開発」と考えてみてください。それぞれにしか存在しない役割やポジション名もありますが、同じポジション名で異なる役割がある場合もあります。
なお、iCDやスキル標準で定義される職種が全てではありません。システム開発対象のドメインや所属する組織によって、仕事のやり方が異なり、職種の呼称も変わってきます。「自分の特徴や役割と違うからその呼称を使わない」でなく、もっとも近いものを選び利用することをおすすめします。海外を探して、自分の仕事をもっとも的確に表している呼称を使うこともいいでしょう。
自分のドメインや組織で定義されている職種名に近いものを選択し、自分がその定義と異なることを明示することが重要です。そうすることで、他者が自分の特徴や役割を理解し易くなります。
職種というラベルを利用することは、自分だけでなく他者とのイメージ共有をも助けます。このイメージ共有によって、人材育成や人材活用が推進できます。人材育成でいえば、現在地から目的地までの共有、現在所有しているリソースの共有などができるようになります。
例えば、プログラマーからソフトウェアエンジニアになるには、設計やテストに関するスキルが必要だと共有できます。人材活用では、プログラマーが何人いて、ソフトウェアエンジニアが何人いるが何人不足しているといった定量化ができ、齟齬の発生を減らすことができるのです。
キャリアレベルの考え方
iCDには職種のレベル感に関する定義はありません。しかし、キャリアパスを考えた場合、レベル感があった方が、より「エンジニアの出来ること」のイメージが明確になります。
ソフトウェアエンジニアからアーキテクトになる場合、一足飛びではキャリアアップできません。ソフトウェアエンジニアと言っても、モジュールの一部分だけ実装できるだけのエントリーレベルから、システム全体を俯瞰し最適化が図れるハイレベルな人材までピンからキリまで存在するからです。例えば、ソフトウェアエンジニアのハイレベル人材であれば、アーキテクトのミドルレベル人材へのキャリアチェンジの可能性が高くなります。
- ITSSの場合
職種のレベル（７段階）毎に達成度指標を明示しています。それぞれのレベルで価値を創出するための必要なスキルの度合いであり、キャリアパスを明確にするためにも、レベルがあると理解を助けます。レベル１、２はエントリーレベルで助けが必要なレベル。レベル３、４はミドルレベルで、自立した存在として業務が遂行できるレベル。レベル５から７はハイレベルで、組織や業界を引っ張るようなレベルです。これらは、業務の貢献範囲、プロとしての貢献度・認知度、要求作業の達成度、知識の活用という観点で整理されているので、これを参考にするとレベル感が共有できると思います。（図2参照）
（図2：引用「ITスキル標準V3 2011 1部概要編 」）
ETSSでもキャリアレベルが存在し、キャリアフレームワークとして定義されています。また、UISSも同じくキャリアフレームワークの定義があります。
ITSS/UISS/ETSSの３つに共通するものは、このキャリアフレームワークです。求められるスキルや、タスクについては、それぞれのドメインで求められる要素は大きく変わります。
しかし、キャリアという職種を定義し、求められる責任を明示し、それぞれの達成度を共有することは、ドメインに関係なく、ITシステム開発もしくはそれ以外の一般的な仕事においても共通的な考えが適用できます。その人の職業的な独自性と、そのレベル感を共有することは更なる人材育成と人材活用を効率化します。
また、一人の人材が複数のキャリアを兼ねることも考えられます。例えば、ソフトウェアエンジニアのハイレベルな人材が、プロジェクトマネージャやアーキテクトというキャリアではエントリーやミドルレベルであるようなイメージです。その場合、自分の軸足をどのキャリアに置くのかを、周囲と共有する必要はあります。これからはアーキテクトとして活動していくのであれば、自分のラベルとしてはアーキテクトの見習いとして業務や学習に務めることが必要になります。
残念ながら、エンジニアがスキル標準を毛嫌いすることがよく見受けられます。レベルの判断基準が現場と乖離しているように感じていることが原因と思われます。私も人事考課でこのキャリアレベルを使うことは望ましくないと考えています。なぜなら人事考課は、その人の保有するスキルや責任だけでなく、与えられた業務に対する達成状況や、その業務の業績など各種パラメータがあります。人事考課はエンジニアとしての振る舞いだけでなく、組織における社員として求められる振る舞いも評価対象になります。キャリアレベルの状況を参考することはあっても、それだけを人事考課に使うことは相応しくないと考えます。
キャリアレベルの高め方
各スキル標準では、研修ロードマップを用意して、未経験者からエントリーやミドルレベルに高める方法を例示しています。研修として用意されていないスキルも多くあることはご理解いただき、有効活用にして欲しいと考えます。大手企業も含め完璧な研修ロードマップやそれぞれの研修を用意することは非常に難しいことです。リファレンスとして参照して、自組織での研修設計や個人の学習プランに役立ててください。
キャリアレベルを高めることは、求められるスキルや責任と現状のギャップを埋めることです。キャリアレベルを一つ上げるには、数年を要する覚悟が必要になります。キャリアレベルは、業務や要求の達成が前提であり、ミッションをクリアしながら成長していくことになります。さらにハイレベルになると、自組織での育成ができなくなることがあり、業界やドメインのプロフェッショナルコミュニティでの活動を通じ、相互作用による学習や成長が必要になります。
また、資格試験に取り組みキャリアレベルを上げる方法があります。資格試験でキャリアレベルが上がらないだろうとか、資格試験に合格しても実務ができないなどネガティブな意見も多いのは事実です。しかし、資格試験は「言葉を知っている」「理解している」「計算ができる」など、知識の第３者評価と考えることが出来ます。資格試験に合格していれば、共通言語や共通認識を共有できる可能性を高めます。対象技術について、最低限知っていると判断できるのです。
実務は知識だけではできませんが、知識があることは実務において有効に作用します。キャリアレベルと資格試験との関係性は、組織によって考え方が大きく違うので、組織のポリシーを踏まえ考えていただきたいです。
まとめ
ITベンダ、ユーザ企業との分け方は時代遅れかもしれません。ITの主戦場は、自社にてITを最大限活用し価値を高めている企業になっており、ビジネスのスピードが求められるこの時代、フルスタックエンジニアというクラウド側のサービス、端末側のアプリケーション、エッジの組込みシステムまで。さらにはアーキテクチャ、性能・品質・コスト、デザイン、CI含む開発環境構築など、プロセスにも精通したワイルドカードのような職種も求められています。サービスをなるべく早く実現し、早いフィードバックループを回すために全てに精通することが求められるのです。
フルスタックエンジニアとの職種名称を使ったとき、広範囲にIT開発ができる人材であることは共通認識できます。しかし、レベルとしてどれくらいなのか、出来る要素技術は何なのか、プロセスとしてどこからどこまで出来るのかは、個別に確認する必要があります。今後、○○系フルスタックエンジニアとか、フルスタックエンジニア（〇〇系）といった表現が利用されることが増えるかもしれません。
ITシステム開発は利用される技術が次々生まれてきます。ソフトウェア開発の量を減らしプログラマーでない人材がITシステムを実現するためのノーコード開発や、クラウドやPC/スマホのプラットフォームの高度化によるアプリケーション開発の効率化、アプリケーションエンジニアの場合にも、ネイティブアプリなのか、WEBアプリなのかなど多様な得意領域が存在します。
モバイルアプリと呼ぶなど、キャリア名や職種名だけでは、送り手側と受け手側で齟齬が発生してしまう可能性がありますが、新しいキャリア名や職種名を増やすことに躊躇せず、具体的に定義をしつつ、社内外でも共有できるようにすることが今後も必要です。
サッカーでは、フォワード、ハーフ、ディフェンス、キーパーだった時代から、現在ではトップ下、ボランチなど新しいポジションが増えています。求められる人材に対して、キャリア名や職種名というラベル付をし、求められるスキルや責任をレベルとして明示し、広く共有してください。そうそれば、人材育成や活用において、エンジニアも組織もハッピーな環境ができると思います。
参考
※１：iコンピテンシディクショナリ【申込受付中】AIやデータ分析の基礎について学びたい方必見
