職務経歴書に真っ先に「PHP」や「Ruby」と書くエンジニアがいるが、いまどき「プログラミング言語」ごときに高いお金を出す企業はない。「Ruby on Rails」と書いておけばいいやと思っているエンジニアも正直危ない。
[adinserter block="1"]
Java や Ruby、Python などの人気言語を扱えると声高に叫び、職務経歴に「10年のキャリアがある」と書くエンジニア達。だが、フリーランスエンジニアの価格は7,8割、お仕事をする「前」に決まる。彼らの職務経歴を見ただけで、「地雷だから回避しよう」という力が働き、年俸500万そこそこが提示され、結果彼らは負ける。
そのレベルで燻っているエンジニアは、持っているスキルが弱い。ではどうすれば魅力的なスキルが手に入るのか。それが今回の趣旨だ。
目次
あなたの肩書き、メインスキルはなんですか？
「○○株式会社 プロジェクトマネージャー」や「フリーランスエンジニア」は肩書きです。肩書きだけで業務委託が決まったり、あるいは転職先が見つかれば万々歳ですが、そのようなケースはほとんどなく、エンジニアはすべからく今まで培ってきたスキルを職務経歴という形で記載し、顧客はそれをジャッジします。
そんな中、職務経歴書に真っ先に「Java」や「Ruby」と言語書くエンジニアがいますが、それでは評価は高まりません。そればかりか、「Perl」や「PHP」と書くだけでかえって評価が低くなる…なんてことも…！
言語や環境「だけ」書いてあるのは低評価
例えば、あるプロジェクトで使ったスキルをこんな風に書いている人、いますよね？
利用した技術
- Java
- MySQL
- HTML/CSS環境
環境
- Linux
- nginx
- Tomcat
もしも企業側の人事が非テクニカル職の人だけで構成されるような場合は厳しいジャッジを免れることができるかもしれませんが、フリーランスエンジニアに仕事を振ろうという会社は間違いなくテクニカル職の方が選考に関わっています。彼らからすると、上記のような内容の職務経歴は、どれだけ経験年数が長くとも「地雷」と見なされます。なぜでしょうか。
それは、エンジニアであればフレームワークの利用経験、できれば「フルスタックフレームワーク」の利用経験があることが、期待外れのエンジニアを回避する方法であると、「できるエンジニア」は知っているからです。翻って、言語や成果物の動作環境だけしか書いていないエンジニア、いわゆる「Javaプログラマ」や「Rubyプログラマ」は期待外れだと言うことがわかっているのです。
「Javaプログラマ」や「Rubyプログラマ」が期待外れなのは、職務経歴に言語しか書くものがないから。とはいえ、プログラミングは言語を使って行うものです。言語以外で、現場が重宝するスキルとはなんでしょうか。
上っ面だけのスキルではなく、現場で通用するスキルを持っているよ！とアピールすることが重要です。
[adinserter block="1"]
魔法の篩(ふるい)、フルスタックフレームワーク
フルスタックフレームワークの代表格は、Java であれば Spring、Ruby であれば Ruby on Rails です。フロントエンドの世界では Angular が有名でしょうか。言語の学習だけでなく、フレームワークの利用経験、可能であれば実務経験を持つエンジニアを現場では欲します。
逆に、フルスタックフレームワークの利用経験がなければ、「使えないエンジニア」と見なして良いという"ふるい"を、テクニカル職の採用担当は持っているのです。
フルスタックが望ましいと書いたのは、守備範囲が限定的なフレームワーク(例えば View のみを司る React)に対し、フルスタックフレームワークでは MVC パターンをはじめ、O/R Mapper やロガーの仕組みなど、様々な機構を備えているが故に、「フルスタックフレームワークの利用経験がある人は経験豊富である可能性が高い」と見なされるからです。また、様々なフレームワークが共通で持っている概念、例えば Dependency Injection や「設定より規約」を知っていることは、他のフレームワークの理解の助けにもなります。
ここで、先ほどのスキルをもう少しかみ砕いてみましょう。このようになるはずです。
利用した技術
- 言語/フレームワーク
- Java/Spring Boot
- DB
- Hibernate/MySQL
- プレゼンテーション層
- Thymeleaf, HTML
- CSS/SCSS
言語と一緒にフレームワークを書くこと、DB と一緒に O/R Mapper を書くこと、CSS ではなくスーパーセットの SCSS を書くことで、スキルの羅列だけでもぐっと「現場が欲しがる人材」に近づきました。加えて、第一レベルで抽象、第二レベルで具象(実装)を書くことで、概念も理解しているプレイヤーだとアピールできます。
本稿で扱う範囲外ですが、せっかくなので環境に関しても細かく書いてみましょう。
環境
- OS
- Ubuntu Xenial
- リバースプロキシ
- nginx
- アプリケーションサーバー
- Tomcat (Spring Boot による起動)
こちらも抽象・具象を分け、ディストリビューションへの理解があること、nginx の役割がわかっていること、アプリケーションサーバーの動作の仕組みがわかっていることをアピールしています。
残念すぎる「自社フレームワーク」
ただし、経験したことがあるものが自社フレームワークのみの場合は注意が必要です。
その昔量産された Zend Framework の亜種等であればまだいい方ですが、大手 SIer 内部ではまるっきりスクラッチされたフレームワークのみ利用する部署もあったようです。OSS 全盛のこの時代、プロプライエタリかつクローズドなものしか経験が無いなどという事実はいかにエンジニア売り手市場と言えど究極の「地雷」です。絶対に職務経歴に書くべきではありません。
[adinserter block="1"]
「Perl」「PHP」が地雷の理由
冒頭で
「Perl」や「PHP」と書くだけでかえって評価が低くなる
とまで書きましたが(Perl, PHPが好きな人、ごめんなさい)、これには理由・共通点があります。どちらの言語も Web 上の CGI として地位を確立し、そのためにオブジェクト指向型言語というよりは手続き型言語として重宝された期間が長く、かつ Ruby on Rails のような圧倒的な浸透力を持つフルスタックフレームワークが長らく登場しなかったことです。それに伴い、パッケージ管理機構や周辺のエコシステム、ユーザーコミュニティの発達も遅れた言語達です。
今でこそ Compose や Laravel が有名かつ有用になってきていますが、言語だけ書いても「Ruby やってるなら Rails もやってるよね？」とはならないのが、Perl/PHP プログラマのつらみでしょう。
安心するのはまだ早い、「Rails エンジニア」が地雷になる日
Ruby は Ruby on Rails と共に日本国内での人気は凄まじく、2018年現在、JavaScript や Python 関連の求人需要にやや押されてきた感はあるものの、依然としてその地位は揺るぎないものがあります。
そんな中で増えてゆく、痩せても枯れても Rails オンリーというエンジニア達。なんで毎回 Rails なの？と聞くと、「一番早く作れるじゃん？」「いやだって全部これで足りるし」といった声が聞こえてきそうです。
MVC 系フレームワークだけやっていればよかった今までの時代はそれでよかったのかもしれませんが、Rails だけでは様々なアーキテクチャを把握するのに必要な概念が足りません。
- コンパイル/トランスパイルの概念がわからない
- サービス層がなぜ有用なのかわからない
- MVP, MVVM がなぜ発明されたのかがわからない
- Dependency Injection がわからない
このようなエンジニア達は応用が利きませんし、新進気鋭のエンジニア達の教育係を任せることもできません。
また、バックエンドから離れることになりますが、例えば Single Page Application を作ったり、あるいはバックエンドを実装しないアーキテクチャ、マイクロサービスを組み合わせたシステムを設計・開発するような場面では、より広い知見が必要になります。
一つのフレームワークを極めただけで生涯安泰と言える程、Web の世界の流れは穏やかではないので、やはり最低でも複数言語、複数フレームワーク、それも静的型付けのあるなしや、ライトウェイト言語に分類されるかどうかなどの性質が違うものをいくつか実務利用し、その違いを説明できるようになって初めて「できるエンジニア」からの地雷扱いを回避できるでしょう。
[adinserter block="1"]
まとめ
今回は「プログラミング」の分野でテクニカル職の人事から見た場合の「地雷」評価がいかなるものか、そのような評価を回避するスキルの書き方についてお話ししてきました。たかがスキル羅列、されどスキル羅列。最低限の情報でも、ちょっとしたテクニックでご自身の経験を効果的に相手に伝えることができます。是非、スキルシートや職務経歴書を見直してみてください。
次回は「インフラ」分野でテクニカル職の人事から見た場合の「地雷」評価について考察します。
ハリー
Profile：エンジニア歴15年。現在もバリバリのエンジニアとして一線で活動中。