読者です 読者をやめる 読者になる 読者になる

ku-sukeのブログ

Just another hatena blog

エンジニアキャリアのためのアーキテクチャ選定権という報酬

こちらの2記事を読んだのと、社内でエンジニアに一定の時間なにかに打ち込む時間を提供するという案について先週議論したので、常々考えている報酬(あるいは福利厚生)としてのアーキテクチャ選定権というものについて書きます。

 

blog.yuku-t.com

paiza.hatenablog.com

なお、paizaさんのベース記事による「ITエンジニア」は非常にスコープの広いエンジニアを対象としていると思われますが、私が対象にしているのは大手SIerなどではないWebエンジニアです。

学び続けないと死ぬんだけど、学ぶの大変すぎ問題

Webエンジニアは技術のトレンドの移り変わりや進化が早く、また雇用も他職種に比較すると流動的なので、学び続けないとキャリアが頭打ちになりやすいわけですが、年々難しくなっています。

範囲広すぎ!

ほんの10年前は、Webサイトを構築するプログラミング環境といえば、Perl / PHP / JSP / ASP そしてRailsの芽が出始めた頃でした。jQueryもまだ世の中に無く、フロントエンドエンジニアという職種はありませんでした。

ところが、いまエンジニア向け求人サイトをみてみるとこういう状態なわけです。

f:id:ku-suke:20160830225701p:plain

(例:CodeIQ JOBS https://codeiq.jp/jobs/ の検索画面)

言語だけでなく、インフラエンジニアであっても同様です。前佛さんのスライドをいつも引用させていただくのですが、このような状況です。

f:id:ku-suke:20160830230256p:plain

SlideshareRe: ゼロから始める監視設計

「インフラを学びたい」といっても、AWSなのかGCPなのかオンプレなのかで学ぶ内容の優先度が異なりますし、それぞれ奥が深いわけです。

語弊を恐れずカンタンに言うと、300種類くらいの技術要素のどれが流行るか(雇用やキャリアアップに直結するか)わからない中から、自分の限られた時間をどれとどれに投入するべきなのか超悩むのです。

特にフロント界隈は、コレが定番というのがなかなか現れずに地獄と化していますね。

フロントエンドでみた、情報系ブログとはてブの地獄メカニズム - エモくありたい

高度すぎて個人で学べない・コストかかりすぎる

学ぶべき対象が広すぎて悩む問題を乗り越え、これをまじめに取り組もうと進んできた時にぶつかる壁が難易度の高い学習は個人でやりにくいという点です。

本当に必要とされる人材というのは1番目の id:yuku_t 氏のエントリにある通り、「あの人はプロフェッショナルだ」と呼ばれる人だと思うのですが、たとえばWeb言語(golangとか新しいものを想定して)において以下の様な知見は個人の机上の開発では身につきにくいでしょう。

  • 10人以上のエンジニアで作るときに保守性を保つには?
  • サーバを分散した時のベストプラクティスは?
  • いまのX年メンテしたPHPのコードをリプレースするほどの価値がある?

インフラでも同様です。企業レベルのAWS操作スキルを身につけようと各種製品をいじっていたら、あっという間に月額数万円かかってしまう可能性があります。(無料枠も初年度だけだし、毎年新機能出るし)

そこで企業によるスキルアップの支援を求めるようになる

ここまでのおさらい

  • 学んだほうが良さそうな技術要素が世の中にあふれている
  • 全く無駄にならないとはいえ、できるだけ雇用やキャリアに直結するものを選定したほうがコストパフォーマンスが良い。
  • プロフェッショナルと呼ばれるレベルの知見を個人の机上で獲得するのは難易度が高い

そのような状況で、ミドルクラス以上のエンジニアは、自分が伸ばしたい技術要素を採用している企業に転職したりするわけです。

企業サイドとしては、出来るエンジニアに抜けてもらっては困るので、転職しなくてもうちでそのキャリアアップできますよ。という点が補強できればより定着してくれるのではないでしょうか。

(※もちろん、転職時には技術キャリア以外の要素も多分にあると思いますが)

 

そこで、報酬、あるいは福利厚生としてのアーキテクチャ選定権です。一定以上のレベルのエンジニアが「おれはgoが来ると思うからgoで書きたいんだ」「Erlangだ」「React.jsを実戦投入するんだ」という希望を自社のプロダクトで満たしてあげる。それはなにも大きいものでなくても、社内向けツールでもいいわけです。

やりかたは20%ルールみたいなものでも、本当にプロダクトでやってみるのも良いのですが、エンジニアの「時間」と「サーバ代などお小遣いの範囲では厳しいコスト」を会社としてサポートしてあげることは、組織として検討してもよいのではないでしょうか。

 

「検討して」というのは、やはり個の要望の数だけ聞いていると、メンテする人がいない、プロダクトや事業として本来のゴールを満たすスピードや質が低くなる、などのデメリットが出てくるためです。

なので、その技術要素をやりたい人を募る投票制にしたりテーマ制にしたりして、個人のキャリアも伸ばしつつ組織の知見としても活かせる方向の解決が良いと思います。

 

もっと小さな組織の場合は、「この人!」という人を一本釣りするためにチーム側をすべて合わせていくという属人性MAXなハイリスク採用戦略としても使えると思います。