エンジニアは転職回数が多い職種ですが、そもそもフリーランスでやっていける職種でもあるので、特定の会社に留まらずに短期スパンで開発を数多く行う開発サイクルを回して、自分のスキルアップをモチベーションアップを行なっている人が多いからではないでしょうか？
ただし、エンジニアはビジネスを生み出すスキルが欠けている人が多く、マネタイズを生み出す開発を依頼されてそれを遂行する為、常に依頼主に対して自己アピールをしなければいけません。
転職をするエンジニアも、職務経歴書や履歴書は設けているが、自分のスキルを明確に表す資料を提出してくるエンジニアはほぼいないのが現状です。
（最近では、WEB学習などのプログラム勉強サイトなどを行うと、言語スキルレベルの成績表などが出るらしいですが・・・）
企業側にしても、エンジニアを管理しなければいけない人はエンジニア経験のない人が多く、エンジニアの持ってくる資料は、学歴、職歴だけで判断しなければいけない為、非常に困っているというお話を聞きました。
そんな時に役に立ちそうなエンジニアのスキルを比較できる指標のベースを考えてみたので、参考になるかたはお役立てください。
エンジニアのスキルを定量評価するポイント
営業部門の人は、売り上げ成績の向上が「大人コミュニケーション」や「業務遂行能力」などが向上している証しとして指標になりますが、エンジニアを評価するポイントは、履歴書と職務経歴書だけでは、全くもって測りきれません。
エンジニア部門のマネジメントを行なっている人や、人事部門の人は常に頭を悩ませている事と思います。
エンジニアを評価する大きなくくりとしては以下の3点で行いましょう。
1. 対人スキル
2. 技術スキル
3. ビジネススキル
「対人スキル」は、組織全体の人に対して同じルールで評価し、比較するのがいいと思います。
エンジニアは対人コミュニケーションが弱いということがまかり通っている組織は、どうしてもエンジニア部門が浮いた存在になってしまいます。
きちんと人に対してプレゼンテーションができて、説明する内容がわかりやすく、気持ちよくコミュニケーションがとれるエンジニアの方が優れていると判断する方が自然だと思います。
ちなみに、エンジニア部門を切り分けるタイプの会社が言いがちなセリフが
「うちの会社のエンジニアは技術は優れているんだけど・・・」
このセリフを聞くだけで、その組織のエンジニアの立ち位置が明確に分かります。
「技術スキル」に関しては、今回のモノサシの内容になるので以下に記します。
「ビジネススキル」は、エンジニアには関係ないと思われがちな営業スキルであったり、会社の財務事情が理解できる経理スキルや、大きな意味での経営スキルです。
これらの技術とは関係ないスキルが必要な要因としては、組織に属する時に、単一の作業だけしていればいいという従業員はあまり望まれません。
嫌がってもきちんとこうした事をスキルとして伸ばしてもらうことが、エンジニア本人の為にもなる事です。
技術のモノサシ
・プログラミングレベル（アルゴリズム）
・ネットワークレベル（通信技術）
・HWレベル（機械の仕組み）
・設計レベル（経験、効率化）
・コミュニケーションレベル（職場人間関係）
・遂行レベル（業務遂行、完了技術）
・品質レベル（テスト、検証）
・知識レベル（セキュリティ、効率化）
・会社経営の知識（社会人能力）
基本的には、上記のような「スキルレベル」とそれに対する「経験回数」を指標にするのが良いでしょう。
その詳細に関しては、組織毎に違う内容になるので、色々な項目を洗い出してみる事をお勧めします。
プログラミングレベル
組織で現在使っているプログラミング言語は、熟知度と経験則を10段階評価するだけでいいでしょう。
ここには細目を用意してアルゴリズムから、色々なジャンル分けしたできることチェックリストなどがあると、より組織の内容に沿った評価ができるはずです。
多くの会社がこの部分はやっていると思いますが、それでもうまく評価できないのは、この点だけで終わっているからでしょう。
ネットワークレベル
通信技術は、WEBを中心とするIT業界にはなくてはならない技術です。
できればサーバーも含めたそれぞれのプロトコルや、IPなどに関する深い知識を知る事で、より仕事の幅が広がるという視点でネットワーク系が苦手なエンジニアもモチベーションを高く持てる組織の仕組みが必要です。
HWレベル
クラウドサーバーが主流になってきた昨今では、AWSは操作できるが、オンプレサーバーは全く操作できないというインフラエンジニアが増えてきているようです。
メモリや配線の物理管理や、サーバーがヒートアップするようなトラブルを経験したことが無い人たちにとって、クラウドネットワーク以外は未知の領域なのですが、基本知識としては、非常に重要な要素を担っています。
英語の文法を知らないけど、会話だけはできるというような状態なので、きちんと文法を理解してもらうように推奨した方が、トラブル対応などの際の心強いメンバーになってくれます。
システム設計のスキルと経験
「設計はSEの仕事」と考えている人はとんでもない勘違いをしています。
プログラミングをする人は、設計ができないと良質なプログラミングなどできるはずがありません。
行数の少ないプログラムでも、人によって様々な記述がされます。
その中には良し悪しもあれば、奇抜だけどとてもアイデアが含まれているモノもありますが、そうしたこと全てが「設計」という作業がちゃんとできているかどうかで判断できます。
「行き当たりばったり」でプログラムするタイプと「考慮、整理された思考」でプログラミングするタイプでは、設計思想が大きく違う評価になると思います。
大きなサービス全体構成設計などは、この思考が大きくなっただけと考えるのがいいでしょう。
設計思考は、論理思考と置き換えて考えても良いので、その組織にあった設計思想を書き出してみましょう。
検証テストのスキルと経験
プログラミングをして、本番にデプロイする前に「不具合が発生しないかどうか」、「別の機能に影響は無いか」などの心配をしながらアップデートを行うくらいなら、きちんと検証しましょうと言いたいのですが、
ここでも行き当たりばったりのエンジニアと、理論的にテストを行うエンジニアかで評価は明確に分かれると思います。
不具合がでないシステムを作れるというスキルは経験から成り立つものが多いのですが、そもそも自らキチンと思考をしない限り良質な検証理論を持つことはできないので、その点が評価対象になると思います。
検証・テストを別の人に任せているエンジニアよりは、自らの構築物に責任を持てているかどうかも、この指標で明確になるはずです。
定量作業の速度
この項目は、その組織の通常作業に対して「できる・できない」判定だけでもいいし、「できるレベル」「スピード」を段階評価してもいいでしょう。
組織における貢献度という内容に直結するはずですし、エンジニアも納得感のある評価になるはずです。
とある会社の評価リスト
上記概念に基づき、エンジニア評価リストのサンプルを載せておきます。
プログラミングのスキルと経験
1. □ PHP （経験年数 / 年）
- 操作できるフレームワーク [ ]
2. □ Javascript （経験年数 / 年）
- 操作できるフレームワーク [ ]
3. □ Shell （経験年数 / 年）
4. □ Awk （経験年数 / 年）
5. □ C言語 （経験年数 / 年）
6. □ Python （経験年数 / 年）
7. □ Ruby （経験年数 / 年）
8. □ Java （経験年数 / 年）
9. □ Objective-C / Swift （経験年数 / 年）
10. その他 [ ]
ネットワーク
1. □ サービス提供環境の構築ができる
2. □ ドメイン、DNSの各種設定が行える
3. □ メールサーバーの構築ができる
4. □ SSH通信、認証鍵などのセットアップが行える
5. □ セキュリティ対応ができる
6. □ アクセス過多のサービスでバランシング技術構築が行える
7. □ バックアップアルゴリズムを理解している
8. その他 [ ]
HW
1. □ サーバー構築が行える
2. □ 電源の電力計算が行える
3. □ 適正なメモリ、ストレージ、などの計算ができる
4. □ 負荷テストを実施できる
5. その他 [ ]
システム設計のスキルと経験
1. □ 非技術者から要件を聞いて、技術設計が行える
2. □ 提案資料作成が行える
3. □ 他社サービスなどとの比較検討が行える
4. □ 世の中の技術に対しての情報収拾ネットワークを持っている
5. その他 [ ]
検証テストのスキルと経験
1. □ テスト設計書が書ける
2. □ テストコードが書ける
3. □ ユースケース、ホワイトボックステスト、ブラックボックステスト、シナリオテストなどを理解している
4. その他 [ ]
定量作業の速度
1. □ 定期のルーティーン作業をスケジューリングできている
2. □ それぞれの作業の時間の平均値を把握している
3. □ 作業効率化のアイデアを模索している（実施したことがある）
4. その他 [ ]
最後に
ここで重要なのは、これは組織毎に全く違うリストになるという点を考えると、きちんとリストを作り込めるかどうかが評価をする組織のポイントになるという点をしっかり理解して、組織評価の為のリストを作成してみてください。
上記のような自己評価シートにおいて重要なのは、「やればできる」という予測ではなく、「やったことがある」という経験則にしていくことで、机上の空論感を排除することが大事です。
そして一度こうした評価リストを作って、その時点で完成ではなく、事業の変化や、人による評価ポイントの変動などに対応するために、都度評価シートを書き直す運用が必要になります。
慣れてくると、その組織で評価シートをどういう風に変えていくのがいいかという事が見えてきます。
なんにせよ、適正に評価して、評価する側、評価される側のどちらも納得感が生まれ、HAPPYになることが重要ですね。
0 件のコメント:
コメントを投稿