エンジニアの技術力をどう測定するか？

(2019年11月当時の記事です)

初めまして、株式会社プラハ代表取締役兼エンジニアの松原（dowanna）です。

今日は全てのIT企業が悩む「エンジニアの技術力とは何か」「技術力をどう測定するか」に関して自論をまとめてみます。

なぜ技術力を定義する必要があるか

社内のエンジニアの技術力をあげたい！と考えた時、まず技術力を測定可能な定義に落とし込まないと始まらない。近づいていることを判断できない目標は目標ではない。

技術力とは、価値を生み出すスピード

僕個人の考えを最初に伝えると、技術力とは価値を生み出すスピードだ。何かが出来る/出来ないとか、知識の有無とか、そういう物は関係ない。スピードだけを見ている。

同じ人間である以上、誰かに出来ることは（大半は）基本的に誰にでも出来る。例えば僕は家の作り方を知らないけど、今から仕事を全部放棄して調べ始めれば、5年くらいで作れるだろう。でも建築技術の高い職人なら、今から半年で同じものを作れるかもしれない。

家という価値を生み出すのにかかる「半年」と「5年」の時間差が、技術力の差だ。似たように、同じWEBサービスを作るのに30日かかるエンジニアと1日で終わるエンジニアが居たら、後者の方が技術力が30倍高いと定義する。

現在価値と将来価値

でも価値を測る時、現在価値だけで計算してはいけない。将来価値も加味する必要がある。

開発者の書いたコードは本番公開した瞬間に価値を生むのではなく、本番公開してから価値を生み始める。将来も価値を提供し続けられなければ、開発者のコードに意味はない。

WEBサービスは本番稼働中も継続的に開発することが大半だから、改修に時間がかかるようなコードを書くことは将来価値を損ねる事になる。

図にするとこんな感じで、

現在価値 x 将来価値＝エンジニアが生み出した価値（青い面積）

という具合に考えている。

1日でサービスを開発したエンジニアが、仮に一行もテストをかかず、共通化もせず、設計もデタラメで、その後の改修に著しく手間のかかるコードを書いたとする。そのエンジニアが生み出した価値はこうなる。

赤エンジニアが作ったWEBサービスは今日この瞬間、仕様を満たして動いている。だから現在価値は高い。でも継続的な開発には耐えない作りで、少し改修すればバグを生み、膨大なテスト工数を要する負債だらけのシステムだとしたら、将来価値は著しく低い。

一方、30日かけたエンジニアはテストもちゃんと書き、CI/CD環境も構築し、設計にも時間をかけて、インフラもコードで管理してる。とすれば、こんな図形になるかもしれない。

用意に保守・開発できるモノを開発した青いエンジニアは、現在価値に加えて、高い将来価値も生み出している。青いエンジニアの方が優秀そうに見える。

しかし、話はここで終わらない。それぞれの価値を費やした時間で割ってみよう。

結局青のエンジニアは30日もかけたから、1時間あたりに生み出す価値を計算すると赤と大した差がない。むしろ1時間あたりに生み出す価値の合計は赤を下回るかもしれない。

時間をかければ誰だって将来価値の高いコードは書ける。それを早く書けなければ意味がない。

これがエンジニアの技術力の要旨だと思う。

・現在価値 x 将来価値＝価値
・価値 / 時間^2 ＝技術力

現在価値は生むが将来価値はそこまで生まない赤エンジニアは、実務経験が乏しい若手エンジニア。

将来価値は生んでいるが時間をかけすぎる青エンジニアは、技術中心に考えすぎて自身の成果に無頓着な職人気質エンジニアと見立てていいかもしれない。

いずれのエンジニアも技術力は低いと僕は思う。

僕が一緒に働いていて「技術力が高いな」と思うのは、1日で青エンジニアの成果を出す人だ。将来も見据えながら普通のエンジニア以上のスピードで開発できる人こそ「技術力が高い」と感じる。

短期評価の落とし穴
一般的な企業は半年に一回程度で目標を定めて、その達成度合いで給料を決める。こうした企業で評価されるのは赤エンジニアだ。爆速で開発して、その場で成果が出れば賞賛される。ひどいコードの尻を拭うのは他人だ。その頃には赤エンジニアは出世して現場に居ない。

多くの企業は短期評価を繰り返すから負債だらけのシステムが出来上がる。気づいた頃には負債が大きすぎて返済できず、簡単な開発に何ヶ月もかけるようになる。モタモタしているうちにスタートアップが玉砕覚悟で似たサービスを高速開発・低価格で攻めて市場を奪う。こういう構図を何度も見た。

青エンジニアが評価される企業は、エンジニアリングに対する理解が深いと思う。余程のバランス感覚がなければ出来ない。「Aさんが10日かけた仕事をBさんは1日で終わらせました」と報告されたら、誰だってBを評価したくなる。そこをグッと我慢して中身を確認する手間を割き、理解出来るマネジメント層は稀有だ。

青エンジニアのスピードをジャッジ出来る人は更に珍しい。技術的難易度の高い作業を実施しているエンジニアが、速いのか遅いのか。それは同じ難易度の技術的課題を解決した人にしか判断できないからだ。

エンジニアはビジネスを理解するべきか
取捨選択すればいいと思う。「僕はフロント一本で食うのでインフラはやりません」と宣言するエンジニアと同じだ。全てを自分で出来る必要はない。

でもビジネス側の心理を理解すれば「おそらくこんな仕様変更があるはずだから、この辺りは汎用性を高く設計しておこう」と予見しておける。こうした予見は自分の身を守る。

「仕様変更が多すぎて辛いです」とぼやく人をたまに見たけれど、申し訳ないけど、そういった方はビジネス観点が無いことが多い。

「この人すごいな」と思うエンジニアは「自分はフロントエンジニアです」とか言いながら、大体サーバもインフラも問題なく書ける。ビジネスに関しても同じだと思う。普通のビジネスマンと同程度の知識と勘所を持っていればいい。

ただ一つ言えるのは、技術力を「価値（役に立つもの）を生むスピード」と定義する場合、役に立たないものを作ることは技術力を損ねる事になる。この定義に沿うのであればビジネスを理解する必要性は高い。

例えば緑色の線が、自分が作っているプロダクトの価値を表すとする。

僕の大前提として、開発者が生み出す価値がプロダクトそのものの価値を上回ることはない。

１＋１を計算して描画するWEBサービスをいかにマイクロサービス化しようとSSRしようと、そのプロダクトの価値が低ければ、どれだけ技術の粋を集めようと生み出す価値は低い。

だから結果的にこうなる

価値のない物を作っても意味はない。価値が０なら、先述の公式を当てはめると技術力も０だ。分子が０なら何で割っても０だ。（厳密には０で割れば無限だけど）

もちろん、この説は少し乱暴だと自覚している。１＋１サービスを作る過程で得られた知見は、いつか価値の高いサービスを作るときに役立つかもしれない。

でも「いつか」が来る保証はない。不確定の未来である以上、現在の価値に換算する時には割引率を考慮するべきだ。今100の価値を生んでいるエンジニアと、いつか100の価値を生むかもしれないエンジニアの価値は、同じではない。（割引率の考え方はこの辺りが参考になりそう）

実装力はあるのに、たまたま運悪く価値のないサービスを作らされたエンジニアも居るだろう。でも本来自分が生み出せる最大の価値を生み出していないのだから、技術力を発揮できていない状況には違いない。

だから僕は自社の社員には、自分が作るモノの価値を常に考えてほしいと思っている。価値を生み出せる商品を作らなければ、僕らの書くコードにも、デザイナーが描く作品にも価値は生まれない。心血を注ぐ対象を見極めることが、自分の技術力を最大限に証明し、最大限の報酬を勝ち取る近道になると思う。

自分さえ技術的に上達すれば何を作ろうと構わない。それはそれで一つの生き方だけど、技術の根本を見落としている気がする。

技術は人を幸せにしたり、生活を豊かにするためにある。人を幸せにも豊かにもしない技術に何の価値があるだろう。時間は有限なのだから、価値があるモノを作り、それを楽しむ人生を過ごして欲しいと思う。だから僕らは社内スローガンとして「誰かのために考えて、誰かのために作る」を設定している。誰を幸せにするのか考えずにモノを作るようになったら、それは技術ではなく遊びになってしまう。

もちろん遊びから始まったモノがいつか技術に昇華する例は多い。でもそれはやはり不確定な未来だから割引率を考えるべきだ。「目先の開発ばかりお金が集まって研究に予算が回らない。うちの組織は将来のことを考えていない」とぼやく研究者がたまに居るが、遠い将来の価値が低いのは割引率の概念を当てはめれば自明だ。

リファクタリングもこれに似ている。リファクタリングしても現在価値は変わらない。得られるのは将来価値だ。だからその価値を現在価値に置き直す時に割り引かれる。よほどメリットのあるリファクタリングでなければ、今すぐ価値を生む実装とは釣り合わない。

技術力をどう測定するか
現在価値は比較的容易い。issueにestimateをつけて消化数を累積したり、余裕があれば開発による売上連動を算出してもいい。

ただ売上のような複合的な指標を使うと、売上が伸びた時に雨後の筍のように「俺のおかげ俺のおかげ！！！」「いや俺！」「いや俺だ！」みたいな人が大量に現れて、アピールが上手い人が評価される会社になるので注意した方がいい。

将来価値の測定は凄く難しい。僕らも全く回答が見つかっていない。優れた実装によって将来浮く時間を予測しようにも、「雑な実装で開発していたら、本来はどれだけ時間がかかっていたか」が予測できない以上、コストカットでは測れない。

ここは定性評価を積み重ねて擬似的な定量評価にするしかないのかなと思う。エンジニア同士で高頻度に「この実装ヤベェ、イケてる。将来価値ぱねぇ」と思った瞬間を計測して、その集計を評価に使う。定性評価も、積み重ねれば十分な定量評価になる。

共通するのは、いずれの価値も非エンジニアには評価しづらいこと。非エンジニアが直接エンジニアを評価するのではなく、エンジニア同士の評価を正確に集計する仕組み作りに腐心したほうが良いと思う。そうしないとアピールが上手い人、現在価値しか生み出さない人が評価されてしまう。

たまには真面目なことも書いてみました。明日からはちゃんとギックリ腰の話とか茶番劇に戻ります！