エンジニアの評価は何で測れるか

本日皮膚科の病院に来ております。体が痒くて仕方がないと相談したら、会社徒歩10分のオススメの病院を紹介いただきました。

入ったら受け付けで
「診察券に名前を書いて、該当の棒に刺してください」
→「診察」「お薬」「なんとか（忘れた）」
って案内を受けました。

さすがにIT入れません？作りましょうか？って思いましたけど、これはこれで効率いいんですかね。


さて本題。

エンジニアのスキル評価は何で測れるか

最近よくよく考えることが多いテーマです。立場上というのもありますし、教育上というのもありますし、プロマネとしてのチーム構成上というのもあります。

結論からお伝えしておくと、残念ながら本記事で結論出して完結は點せられておりません。悪しからず。もう1～2回かけていろんな観点の洗い出しをしてみた後、結論もってこうという感じのないようなので、気長にお待ちいただけますと幸いです。

一応補足して言っておくと、後世に残る天才的なアルゴリズムを残せるかどうか、みたいなのではなくて、ビジネス的な要件から高い評価を得るエンジニアのスキルについてです。

どれだけいろんな言語を使えるか

どれだけいろんな言語を使えるか
これはどっちかというと評価される側が気にしがちというかなんというか。
「あれもこれもやっとかんと世の中についてけねぇ」
っていう感じですかね。でも一つの企業やサービスで求められるのは対して多くない上、最近は分業が徐々に進んでいることを考えると

・世の中のニーズに沿って勉強は必要

・ただ、全部自分でできる必要はない

・その上、別にサービス内で使ってない言語のことは知ってても評価には直結しない

てなわけで、別に使える言語の種類を増やすことは、そのまんまの評価につながるわけでもなさそうって印象です。

どれだけはやく作れるか

大事ですよね。早く作っていただけるのは正義。しかし言わずもがな、運用上の課題や考慮事項とか、そこらへん諸々の長期的な考慮事項も含めて『早い』というのがなかなか難しい。むしろロクなことにならないケースのほうが多い。

あとはまあ、その開発にどのくらい時間がかかるかの工数見積の妥当性って、本人にしかわからないところもあるので、やはり速さを追求するのもなんか違うなと言うところです。（極端な話工数見積を長めにとって早めに上げました、なんてこともできなくはない、やらないけど）

ということで早いだけで優れているかどうかはわからないため却下。

どれだけ案件をこなしてきているか

開発は、ある程度の水準まではやればやるほど引き出した増えていくので、目安にはなると思っています。

が、なんだかんだひとところで継続してやっているだけだと類似の技術が増えてきたり、仕事関係者がアップデートされなかったりで成長はやはり鈍化していきますね。

そういう意味では「案件」の粒度にもよりますが、どれだけ「いろんな現場」をこなしてきたか、のほうが正解かな？

どれだけ要件定義をこなしてきたか

これはちょっといい線いってるかなーとは思いました。

当然ですが実装ができなければ要件定義はできませんし、特に非機能要件の予見定義は、数をこなさなければ身につかないところではあります。

ただ惜しいのは、要件定義も機能レベルだとやはり繰り返しやっていくうちに類似のケースが増えて成長スピードが鈍化していくところですね。

どれだけ「実工数に見合った」計画を建てられるか

そんで色々考えたところ、今の所一番しっくり来るのはコレかなーと。

・（技術インプット）商品開発をするにあたって、実装に不明な技術があっては計画を立てることはできない（つまり技術のインプットは必要な前提）

・（スピード）実装にあたってビジネス上必要なスピード感を体現する実装スピードで実現できる

・（課題解決）より長期に渡るプロジェクトの場合、不確実性を考慮したスケジュールを引いておき、課題発生時適切な対処により実装ができる

ビジネス上、やはり当初計画からできるだけズレなくアウトプットを出すことは非常に重要だなあと最近思っていまして、これまでバラバラに考えていた技術インプットやスピード、あとは課題に出くわしたときの解決の引き出しと、その辺諸々をいろいろ考慮して評価する指標っていうのはこのあたりなのかなと思います。

次はどうやって計測するか

そうすると今度はどうやって計測するかのお話になりそうです。ただまあ、普通に考えると予め当初計画を引かせておいて、最終的なプロジェクト完了時にその差分が妥当なものかどうかをFBするという形になるのかと思います。

その内容はまたの機会に。