エンジニア業の傍ら採用の担当もさせていただいています。
主に同じエンジニアの方の派遣採用をしていますが、
中途採用の方や、その他の職種の方についても私が見ることがあります。
送られてくる経歴書は、どれも自分が一昔に書いていたような書式ですが、
見れば見るほど勿体無いなあと感じています。
正直な話、今まで上手な経歴書を書いている人に会ったことがありません。
上手な経歴書を書くだけで印象違ってくるのになあ、
と思ったのがこの記事を書いたきっかけです。
恐らく端折って書いている人は、
『採用担当はそんなに読まない』と思っているのかもしれませんが、
それは大きな間違いです。
少なくとも僕は、端から端まで2回は読みます。
2回読むのは送られてくる経歴書の書き方が下手すぎるために、
良い部分を探すのに苦労するからです。
なぜしっかり読むのかというと、採用担当のミッションとは、
応募者をふるいにかけるだけが目的でなく、
優秀な人材を絶対に逃さないようにする職務があるからです。
絶対にというのがポイントで、自分がいい加減に採用をやっていたがために、
ライバル企業に優秀な人材が流れて行ってしまえば、
最悪自分が採用担当から外される可能性があります。
将来性に投資するという意味合いの強い新卒採用と大きく異なるのがこの点です。
また、下手な経歴書のデメリットで言えば、
具体的に何が出来るのか分からないために、
本人の自己評価する報酬額と、
雇う側が評価する報酬額にギャップが生まれる事です。
下手な経歴書の人ほど、『ん？なんか希望額が高いな』と感じますが、
恐らく本人からすれば妥当な金額なのだと思います。
問題は、その妥当性が採用する側に伝わっていないことなのです。
上手な経歴書には3つのポイントがあります。
僕自身の経験はIT業界にしかありませんので、
IT業界、特にエンジニア限定と言うことでお願いします。
1.直近の経歴順に書かれている
もうこれは最低限のレベルです。
新卒で担当した案件で重要な作業をしてる筈が無いので、
一番上に書く必要なんてまったくありません。
履歴書ではないので、時系列順に書くルールなんて無いのです。
直近から始まり、キャリアスタートで終わるように書きましょう。
2.経歴紹介に具体性がある
『保険のシステムを作っていました』
というような、一言コメントが多すぎます。
概要レベルの話では、決して習得したスキルは想像できません。
もっと具体性のある書き方をしましょう。
作っていたシステムの業務内容を書く必要はありません。
・どんな処理を実装したのか
・どういった技術を使って問題解決したのか
・チーム内でどんな役割を担っていたのか（※）
この3つに要点を絞ってもらうのが良いです。
（※）ただし、SEでした、リーダーでしたというのは抽象的すぎます。
例えば、
『品質管理を任されており、
テストケースの評価やリポジトリの管理をやっていました』
というような文章だとわかりやすいです。
3.仕事への姿勢を記載する
僕自身、フリーランスで業務委託のエンジニアをやっていたため、
経歴書はしょっちゅう書いていたのですが、
自己PRは必ず書いていました。
そして採用担当をやらせて頂き、色々な方の経歴書を見ると、
そもそも自己PRを書く人が全くいない事に驚きました。
これは完全に自分の将来性を捨ててるとしか言えません。
必ず自己PRは書きましょう。
現実問題、人柄や持っているビジョンはスキル並に重視されています。
いわゆるコミュニケーション力が高くなくても僕はいいと思います。
ただし、仕事へのひたむきさと、
向上心があるかないかを重要視しています。
以下のような内容があると参考に出来ます。
・どういったモチベーションでスキルアップをしているか
・仕事の時間以外、IT関係でどう時間を使っているか
（アプリをたくさんいじる、オープンソースに貢献している...etc）
・自分が得意としている言語、開発分野
・こんなシステムをやりたい、こんな担当をしてみたい
以上の3つの他に、経歴が長い方は希望する会社の業務にあわせて、
見て欲しい経歴だけをピックアップした別紙を用意し、
そっちを先に見てもらうと良いと思います。
また、扱った事のあるオープンソースや、ツールや製品など、
一覧にして別紙にしてもらうのも良いです。
個人的に作ったプログラムや、
貢献したオープンソースプロジェクトがあれば、
採用にとってとても大きな強みになります。
必ず紹介するようにしましょう。
中途採用希望の方は、上記ポイントは必ず守ってもらいたいです。
下手な経歴書は、将来性を捨てることになるからです。
人気希望は毎週数百近い経歴書が送られてきますが、
面接に辿りつけるのはほんの僅かです。5％切ってます。
良い経歴書を書けば人気企業に就職できる可能性が生まれます。
業務委託や派遣の方は、キャリアアップだけでなく、
報酬に直結する部分ですので、同じく遵守していただきたいですが、
所属会社やエージェントの書式に則っている場合もあるかと思います。
そういった場合は、会社に経緯を説明して
書式を変えてもらった方がよいと思います。
自分自身のためだけでなく、関係するみんなにメリットが生まれるので、
変えるよう提案するだけの価値はあると思います。
社内でスマホブラウザ向けの
フロントエンドフレームワークを作ることにしました。
フレームワークというと大仰ですが、
実はこの約半年、僕がTMNに加わって以来、
既に1例開発事例があります。
軽量でシンプルな、最低限のフレームワーク機能を持たせ、
実装作業にテンプレートワークを持ち込むことを設計思想とした、
現実的な分、自由が大好きなエンジニア諸兄のウケは悪そうなフレームワークです。
主目的としては、GAE/JのRESTサーバサイド構築のために作っています。
『想定される用途を極端に絞ったフレームワーク』です。
こういった設計思想であるならば、
フレームワーク自体の開発コストは減少する、ということもさることながら、
単純に『フレームワーク開発プロジェクトが成功しやすいパターン』
なんだなと言うことを実感しました。
身の丈にあった小さいフレームワークを自前で開発することは、
生産性を高めることは勿論、アウトプット品質の向上と均質化が図れ、
生産物の障害発生リスクを大幅に低減出来ます。
設計のポイントとしては、
1.俯瞰して使いそうな機能をピックアップする。
2.過去のフレームワークの成功事例を参考に、機能の詳細設計をする。
3.1～2をベースにアーキテクチャを決める。ただし、時間をかける。
この3点だけを意識しています。
逆に言えば開発に入ってから見つかる再利用性の高い個別機能なんかは、
モノによってはフレームワーク側に移植していたりしています。
足りない機能も見つかり次第追加するというスタンスです。
こういった柔軟なフレームワークの運用は、
誰かが作ったフレームワークをフォークしたとしてもなかなか難しいです。
また、社内で作ったとしても、全機能フル盛りなフレームワークは、
時代に合わなくなった際や、新プロジェクトの型にハマらない場合、
思い切って捨てるという選択がし辛いという問題点もあります。
僕達が取っている開発手法は、手直しすることも、捨てることもしやすく、
開発ペースの早いIT業界の中の成長産業の更に最先端にいる会社にとって、
とてもよい選択肢だと思っています。
フロントエンドフレームワークを作ることにしました。
フレームワークというと大仰ですが、
実はこの約半年、僕がTMNに加わって以来、
既に1例開発事例があります。
軽量でシンプルな、最低限のフレームワーク機能を持たせ、
実装作業にテンプレートワークを持ち込むことを設計思想とした、
現実的な分、自由が大好きなエンジニア諸兄のウケは悪そうなフレームワークです。
主目的としては、GAE/JのRESTサーバサイド構築のために作っています。
『想定される用途を極端に絞ったフレームワーク』です。
こういった設計思想であるならば、
フレームワーク自体の開発コストは減少する、ということもさることながら、
単純に『フレームワーク開発プロジェクトが成功しやすいパターン』
なんだなと言うことを実感しました。
身の丈にあった小さいフレームワークを自前で開発することは、
生産性を高めることは勿論、アウトプット品質の向上と均質化が図れ、
生産物の障害発生リスクを大幅に低減出来ます。
設計のポイントとしては、
1.俯瞰して使いそうな機能をピックアップする。
2.過去のフレームワークの成功事例を参考に、機能の詳細設計をする。
3.1～2をベースにアーキテクチャを決める。ただし、時間をかける。
この3点だけを意識しています。
逆に言えば開発に入ってから見つかる再利用性の高い個別機能なんかは、
モノによってはフレームワーク側に移植していたりしています。
足りない機能も見つかり次第追加するというスタンスです。
こういった柔軟なフレームワークの運用は、
誰かが作ったフレームワークをフォークしたとしてもなかなか難しいです。
また、社内で作ったとしても、全機能フル盛りなフレームワークは、
時代に合わなくなった際や、新プロジェクトの型にハマらない場合、
思い切って捨てるという選択がし辛いという問題点もあります。
僕達が取っている開発手法は、手直しすることも、捨てることもしやすく、
開発ペースの早いIT業界の中の成長産業の更に最先端にいる会社にとって、
とてもよい選択肢だと思っています。
12月21日にKindle Fireが6.2.1にアップデート。強制アップデートでroot穴を塞いでくれた上に、
/system/xbin/suなどを勝手に削除するという
神アップデートをやってくれたAmazonさん。
ひと通りいじった後だったので別にroot無くてもいいかな～とか思っていたら、
よく見るとフォントが中華フォントに逆戻り…。
中華フォントだけは嫌だったので、
時間を作って再度root取得に挑みました。
結果5分もかからず再取得できたので、とりあえずは安心。
以下root化手順。
※adbで接続出来ている事が前提。
※基本的にコチラを参考にした。
1.FireでBurritoRoot: Kindle Fire EditionをDL&Install
2.起動→Agree→You Rock→Root
3.USBでPCに接続
4.adb kill-server
5.adb root ※adbでのrootが有効か確認
6.superuserをPCに落とす+解凍
7.adb remout
8.adb push ~/Downloads/superuser/su /system/xbin/su
9.adb shell chown 0.0 /system/xbin/su
10.adb shell chmod 06775 /system/xbin/su
11.adb install ~/Downloads/superuser/com.noshufou.android.su-1.apk
12.adb reboot
13.完了+再起動後端末側でrootがとれているか確認
たった数日でrootを取れるようツールを作ってくれた先人にマジ感謝。
フォント入れ替え等の儀式を済ませ、ようやく元のFireさんに。
ただ、もうFireに飽きてきたから、
そろそろROM入れ替えて遊ぼうかなあ。
強制アップデートの心配も無くなるしね。
社内のプロデューサーに向けた、
仕事の進め方や仕事内容、職種定義といった内容の、
『プロデューサーの定義』という本が配布されました。
僕も頂戴し数度通読したのですが、
非常に得るものが多く感銘を受ける一方、
エンジニアならどうすべきかということを考えさせられました。
考えた中で、自分が大事にしているなあ、いつも、
というポイントを4点にまとめてみました。
何か感じてもらえれば幸いです。
何よりも重要な事です。
好奇心が無いのに尊敬されているエンジニアは存在しません。
エンジニアの能力開発において、すべての動機は好奇心であり、
好奇心の無いエンジニアはダメなエンジニアと同義です。
2.可能性
人がかけるコードは自分にも出来る。それ以上のが書ける。
人ができるチューニングは自分にも出来る。それ以上出来る。
よきエンジニアの探究心と
スキルアップへの欲求は無限大であるべきです。
自分には出来ないと思った時点で、
よきエンジニアとは呼べなくなります。
3.立ち止まらない
ここは少し大事なので長く書きます。
評価されるエンジニアは手を止めません。
手を止めないエンジニアは、視点が違うからです。
それは、製品やサービスの品質に責任を持てているか、
という視点に立てているかということです。
よく自分の手持ちのタスクを消化しきったため、
手を止めて暇を弄び始めるエンジニアがいますが、
チーム全体、ひいてはサービス全体で見たタスク、
改善点というのは終わりがありません。
バグ修正や高速化のためのチューニングや、
コードの整理、ドキュメント作成、
ただ使い込むというのも重要な作業のうちです。
エンジニアのタスクが終わるのは、
サービスがクローズしたその瞬間だけです。
サービスを作っているエンジニアにとっての
責任を持つという言葉は、
この視点に立てるかどうかという事に尽きると思います。
4,いいものを素直に良いと言う
自分の直感やスタイルに固執する人がいます。
その直感は本当に正しいですか？
そのスタイルは時代遅れじゃありませんか？
新しく提案されたものには客観的な視点を持ち、
素直に良いといい、次の瞬間から自分のモノにする、
世渡り上手な姿よきエンジニアには必要です。
これが出来ない人が多いように感じます。
自分自身、注意するようにしています。
エンジニアという職に就いているのであれば、
その中でもよきエンジニアを目指しましょう。