表参道フォークウヱル別館（旧）

「えっ、今さら？」とか「今までなかったの？」とか言われそうですが、Forkwell Jobs の求人ページに応援機能がつきました。

内容を簡単に説明しますと、「お、この会社の求人よさそう」と思ったり自分や友達の会社が掲載している求人票に「いいね！」ぽいものをつけて、同時に Facebook や Twitter にシェアできるというものです。ありがちですね。

リリースと同時にあってもよさそうな機能だったんですが、「他社のサービスでもさんざんやってる機能だし、マネしてるみたいでなんかやだ」という声が開発チームであったりなかったりで、今までつけていませんでした。

しかし実際つけてみたら、初日に VOYAGE GROUP の求人掲載開始にかぶったのもあり、PV が急上昇。グラフで見るとまさに「うなぎのぼり」。

ソーシャルの拡散力恐るべし。

まあ変なところに意地を張らずに、他社のサービスでも実績のあるものは検討した上で採り入れてブラッシュアップするべきですよね。まんまパクリはよくないですが。
（※この手の機能に「応援」という名前をつけたのは WishScope が最初だそうです。以前ザワットの原田社長からそう聞いたので、ここで注釈しておきます）

さらに求人検索の結果ですが、従来の「掲載の新しい順」「提示年収上限の高い順」「提示年収下限の高い順」に、今回「応援が多い順」が新しく追加されました。

ちなみにデフォルトの並び順は「応援が多い順」ですが、近日中に「直近2週間の応援が多い順」になる予定です。
これにより、今話題になっている求人が常に上の方に表示されるようになります。

リリースから2ヶ月がたった Forkwell Jobs ですが、おかげさまで当初からコンスタントに応募があり、しかも比較的技術力の高いエンジニアの方々からの応募が多く、順調なスタートを切ることができました。

今回のような機能改善・追加は今後も続けていきますので、「ここはこうなっててほしい」「こんなふうになっていたら便利」みたいな意見があれば、どんどんお寄せください。

お問い合わせフォームが Forkwell Jobs のページフッターにありますので、そちらからご意見・ご感想お待ちしております。

サカタカツミさんの寄稿による、人事側から見たエンジニア採用の問題についての短期連載も今回が最終回。

片や技術をこよなく愛しそれを軽んじるものには容赦なく斧を投げつけるモヒカン族、片やことあるごとに「IT業界はブラック企業の巣窟、SEやPGはIT土方」と唱えてモヒカンを冷めた目で見る厭世的“職業エンジニア”。

非エンジニアのサカタさんには両者の対立は決定的に見えるようで、この間お会いしたときもその話をされていました。解決策を求められて、「お互い価値観が違いすぎるので仲良くするのは難しいと思います」としか答えられなかったのですが、確かに採用現場においては、両者の齟齬が不幸なエンジニアを生む大きな原因になっていそうです。

このブログの今後の記事の方向性はもちろん、Forkwell Jobs ではいかにその問題を解決し、かつエンジニアが採用に関われる仕組みを作るかを考えていかないといけないなと考えさせられました。

エンジニアは他のエンジニアとわかり合えないのか、という話

短期連載の最終回。ということで、今回は『幸せなエンジニアライフを送るエンジニアを増やすためにエンジニアができること』と題して、エンジニアがなにするべきなのか、少し一緒に考えてみたいと思います。

前提として『幸せなエンジニアライフを送るエンジニア』をエンジニア自身が増やしたいのか、という問題があります（それ以前に幸せなエンジニアライフという定義が曖昧なのですが、それは置いておくとして）。非エンジニア領域に生息している筆者からすれば、エンジニア領域に生息している人たちの中に潜む、お互いが相容れない考えを持っている場合、ひどく加虐性が高くなるという性質に、いつも戸惑ってしまいます。

例えば「技術書を自費で買ったら負け」というフレーズをネット上でよく目にします。他の領域のビジネスパーソンが、自分たちの業務範囲の知見を深めるために書籍を求めて勉強するという行為を「負け」と称することや、負けであると判定することは、あまりありません。しかし、エンジニア領域に生息する人の中で「そんなことをしたら負けだ」と攻撃したい人がいるようなのです。

こういう人たちは、別の視点でも攻撃の手を緩めません。典型的なのが「休みの日まで勉強会に参加するなんてバカ」とか「家でコード書くなんてありえない」という罵倒や、「俺は自宅にパソコン持っていない」という自慢（？）もそうかもしれません。考え方が違っていれば、そっとしておけば良いのですが、エンジニアと呼ばれる人たちは、一言いいたい人が少なくないようで、特にネット上ではこういう発言に満ち満ちています。これを見ていると、エンジニアは他のエンジニアのことが嫌いなのでは、と考えてしまうほどです。

エンジニアがブログを書くのは「ナルシスト」だからなのか

エンジニアの中には、技術的なことを学んだあとに、それをまとめたり、勉強会などに参加して気づいたことを書き留めたりするために、ブログを活用している人も少なくないようです。また、日々の雑感などを書き記したり、中には退職しました、転職しましたというキャリアの節目を報告したりするエントリーをアップしている人も意外にいます。が、これも攻撃の対象になるケースを見かけます。ブログで退職報告するヤツのほとんどは「ナルシストでどうしようもない」という記述を多数見かけたときには愕然としました。

先の二回のエントリーで繰り返し書いてきましたが、企業の採用担当者の多くはエンジニアのことについて、ほとんど無知に近い状態です。ですから、人物を正確に判断することがとても難しくなる。技術的なスキルに関しても通常の採用プロセスで判定することが困難ですし、どのくらいの総合的な能力があるのかを判断するには、職務経歴書では役不足なのです。

したがって、勉強に参加したり、技術書を読んで学んだり、自分で業務外にコードを書いたりしたことを、ブログなどで日々まとめておくことは、エンジニアが幸せなエンジニアライフをおくるために、とても重要になってきます。そう、自らがどのような能力やスキルを持つエンジニアであるか、それを相手にわかりやすく伝えるには、エンジニアとしてのライフログが非常に有効な手段になるのです。事実、エンジニア採用が上手くいっている企業の採用担当者やエンジニアは、応募したエンジニアが書くブログに注目しているといいます。

エンジニア同士で罵倒し合う構造が続く以上、ログを作っておくことに躊躇してしまったり、勉強会に参加したり技術書を買い求めたり、趣味と仕事の境界線上でコードを書いたりすることをためらったりする人が、出ないとも限りません。前向きな取り組みがシュリンクしてしまうのは、とてももったいない。

「スキルアップを唱えるエンジニアはウザい」「仕事でコード書いているこちらには、そういう輩は迷惑だ」という声も聞こえてきそうです。が、その罵倒がエンジニアにとって快適に働ける環境をスポイルする可能性もあるのです。

幸せなエンジニアライフを送るエンジニアを増やすために

以前、ゆかさんは『エンジニア求人と掛けて婚活女性のプロフィールと解く、その心は相手の視点に立つことが大事』というエントリーの文末に、こういう文章を書いています。

いや別にどんなエンジニアでもいいのでしたら、わざわざこんなことをする必要はありません。

これは、企業の採用担当者に向けられた台詞ですが、同時に企業で働いているエンジニアに向けられた台詞でもあります。一緒に働くエンジニアが、どんなエンジニアでもいいなら現状のママでいい。ただ、それは嫌だ、もっとこうするべきだと考えがあるならば、積極的に採用プロセスに関与すべきだと。

Forkwell Jobs や、私がプロデュースする CodeIQ は、通常の求人サービスとその仕組みが大きく異なります（詳細が知りたい人は、ぜひリンク先をのぞいてみてください）。だからというのも変ですが、現場のエンジニアが、採用担当者に対して「こういうサービスがあるから使ってみては？」と推薦してくれるケースが結構あります。手前味噌になりますが、これらのサービスは従来型の採用サービスと比較して、エンジニアが関与する量が圧倒的に多いのです。ですから、自社の採用を変えたいと考えるエンジニアの皆さんが期待をして、活用したいと申し出てくれるのでしょう。

幸せなエンジニアライフを送るエンジニアを少しでも増やすためにエンジニアだけができることは、あまりたくさんありません。一つは、前向きなエンジニアが萎縮しない環境を整えること。そう、エンジニア同士が仲良くしてくださいというとてもシンプルな話です。もう一つは、エンジニアがエンジニア採用に積極的に関与してください、というちょっと手間がかかる話。

後者は、一時的に業務量が増えるかもしれませんし、面接官などを依頼された場合、向き不向きも大きいので、自分には手に負えないという可能性もあります。しかし、自分と一緒に働く人たちを、自分たちの手で選ぶということが、実は自分たちの働く環境を改善する、最も有効かつ、近道であることは考えてみれば、直ぐわかることですよね。前向きに働きたい、業務量を軽減したい、エンジニアとして幸せなエンジニアライフを送りたいと考えるなら、自分自身のパートナーは、なるべく自分の手で選ぶ、という状況を作り出さなければならないのです。

「応募資格：ＪＡＶＡ業務経験２年以上」のような求人を出す企業や、「俺たちが世界を変えるんだウェーイ系」の求人広告を作ってしまうような企業をこれ以上増やさないために、もしくは「エンジニアって要は労働集約型のアレでしょう」と、エンジニア自身がいわれないようにするためには、エンジニアの手で、エンジニア採用を変えるよりないのです。

追記

長々と書いてきましたが、このブログに寄稿したあと、私は毎回自分自身のブログでサブノートを書いています。前回のエントリーのあと、こんなサブノートを書きました。この寄稿文に違和感を持つエンジニアは、そういう環境にいるのだから幸せだと。同時に、以下のように記しています。

エンジニア採用をコアにいろいろと論じているが、これはエンジニア採用に留まらない。人材要件定義が曖昧であることはエンジニア採用だけではないのだから。いまはそれほど大きな問題にはなっていないが、いずれなる可能性ははらんでいる。人を雇ってやる（まさにここで指摘されていることは、その典型的な例だろう）というスタンスから、良い人材を招き入れるという姿勢に変える。その動きを戦略的な採用担当者はすでに行いつつある。

エンジニアは、働き方や仕事の進め方などは、時代の最先端を走っているといっても過言ではないでしょう。そしていま、採用の仕方、そして、キャリアの作り方も真っ先に変わろうとしています。そして、それらを担うのは、より幸せな働き方をしたいと強く願う、エンジニア自身に他なりません。Forkwell Jobs や CodeIQ は、そのお手伝いが少しでもできれば、と思っています。

（サカタカツミ - クリエイティブディレクター）

前回に引き続きサカタカツミさんによる寄稿シリーズの第2回目をお送りします。
前回の記事では社内のエンジニアと人事の間の壁について語っていただきましたが、今回はなぜその壁ができてしまうかについて踏み込んだ内容になっています。

サカタさんは CodeIQ のプロデューサーもされていて、日常的にそのクライアントとなるエンジニア採用担当の方々と接する機会があるわけですが、その中で聞く人事のホンネについて赤裸々に語ってくださっています。

正直、聞いててカチンと来ること多々ありです。しかし私の立場としては、単純に反発するのではなく、この溝を生む人事側の意識を受け止めた上で今後の Forkwell Jobs のあり方とか、このブログの記事の書き方とかを考えないとなあ、と思わされる示唆に富んだ記事でした。

エンジニアって要は労働集約型のアレでしょう、という話

『CodeIQ』というサービスをプロデュースしていますので、さまざまな方からエンジニア採用に関して意見を求められたり、実際に相談を持ちかけられたりする機会は少なくありません。そこで、細かい市場データを持ち出してエンジニア採用の現状を説明したり、採用そのものも意外に骨が折れることを話したりしていると「だけどなー」とつぶやきながら、以下のような反応をする採用担当者がいます。

「エンジニアというか、プログラマーって、要は労働集約型のアレですよね。別に何か特殊な能力があるとか、自分でなにか発明できるという仕事じゃないですし、極論すれば『誰でも良い仕事』って感じ。仕様書通りに仕事ができればそれでいいというレベルでしょう、みんな欲しがるのは。それなのに、どうしてエンジニア採用は難しいと特別扱いするのか、よくわからないなぁ」

これを読んで「ふざけるなよ」とか「だったら自分で書けよ」と憤ってしまうエンジニアの皆さんがたくさんいることは容易に想像できます。しかし、前回のエントリーにも書きましたが、そもそもエンジニアの仕事内容を十分に把握していない採用担当者だと、こういう反応をしてしまうケースも珍しくない。

ゆかさんは『俺の求人の応募者がこんなにスキルが低いわけがない』というエントリーでエンジニア採用において企業がやるべきことは『ターゲットとしているエンジニアの目線に立って、彼らが欲している情報を的確に伝えること』と書いていますが、目線に立つ以前に、エンジニアそのものがまるで理解できていないことも、割と多いのです。

エンジニアといっても『千差万別』という当たり前の事実

「エンジニアって要は労働集約型のアレでしょう？」という話が出ると、必ずセットになるのが『エンジニアといっても千差万別』という当たり前の話。採用担当者の心のうちは、こんな風に吐き出されていきます。

「ジーニアスなエンジニアを採用したいというなら、凄く苦労すると思いますよ。そういう人は業界でも少ないでしょうし、そもそも間違いなく転職活動なんてしない。引き抜かれて移籍していくというタイプでしょうし。でも、エンジニアがすべてそうか、といわれれば違うでしょう？」

エンジニア採用をしている企業のほとんどは『フツーのエンジニア』が欲しいだけ。ただ、そのフツーと称されるエンジニアすら転職市場での数が足りていないからエンジニア採用は大変だといわれているだけだ、と断言する『エンジニアのことはあまりよくわからない採用担当者』もいるほどです。

先のエントリーでゆかさんは『プログラミング経験3年以上、Java業務経験2年以上、××の実務経験、○○の運用経験、さらに△△の経験を優遇と応募資格を延々と書き連ねてある』大学の入試要項系の求人を揶揄していますが、このスタイルは他の職種の求人では、ごく一般的なスタイルです。それがダメだといわれても、エンジニアに理解の乏しい採用担当者は、ピンと来ない。

「フツーのエンジニアをフツーに採用しようと考えて、フツーの求人広告を作って出してもダメだといわれても、困ります。何様？という気になりますよ」

そんなことだから採用できないのだが、という台詞を、私はその場で飲み込み我慢しましたが、労働集約型のアレといってしまい、フツーでいいのにと考えてしまう採用担当者がいる限り、人手が足りなくて苦労している現場のエンジニアが浮かばれない日々が続く可能性は、きわめて高いのです。

従業員に求めていることをエンジニアに求めて何が悪い？

さらにエンジニア採用を難しくしている要因に『コードが書けるだけではダメである』という採用担当者や経営陣のポリシーがあります。

私がプロデュースしている『CodeIQ』というサービスでは、事前にコードを書いてもらって、それを企業のエンジニアがチェック、会ってみたいという人とミートアップ（面接ではありません）を設定して、エンジニア同士で話をするというスタイルを採っています。この説明をすると、難色を示す採用担当者は眉をひそめます。

「求められた水準でコードが書ける、ということは重要ですが、もっと大切なことがあります。それはウチの従業員としての資質を備えているかどうか、ということです」

例えばこういうことです。ちゃんとしたコードが書けたとしても、客先で折衝が上手くできないエンジニアはいらない。また、一定の年齢に達したとき、下の人間の面倒をきちんとみて、いわゆるマネージメント能力がなさそうなエンジニアは必要ない。それだったら、コードを書く能力はそれほど高くなくても人間性が優れている（＝意味不明な言葉だとは思いますが、ママ）エンジニアを採りたい。だから、コードで判断する転職サービスは使えないと。

「極論すれば、良いコードを書くプログラマーが必要なら外注すればいい。企業としては、自社の採用基準にそった人間を採るべきで、それはエンジニアでも営業担当者でも、総務人事の人間であっても変わりません」

エンジニアが客先で折衝するケースはあるのですか？　と質問したところ、ないですと答えるので、だったらその資質は必要なのですか？　とさらにぶつけてみたところ「社会人として当然のスキルですよね」と。

生涯『１プログラマー』として働きたいという考えのエンジニアは？　と質問すると「給料があがらないという状況でよければいいですが、そういうのはダメでしょう？　だとしたら、自社の給与テーブルに沿った（エンジニアとしてではなく従業員としての）仕事をしてもらわないとダメです」とにべもない。

さらに、ゆかさんが先のエントリーで触れている『会社の理念と仕事のやりがいを前面に押し出し（中略）リア充感満載の求人』にしても、出稿する立場の人間からすると、価値観が共有できない人とは一緒に働けない、たとえそれがエンジニアであったとしても、ということの裏返しなのです。

応募者のスキル、という言葉ですら企業は勘違いしている

エンジニアとして仕事ができない人は困るけど、さりとてエンジニアの仕事『だけ』ができる人も困るし、全部できる人がいいけどいないから、どれも『そこそこ』のエンジニアが欲しい。けど、そんな人もなかなかいないので、エンジニア採用は難しいと思われている。

エンジニアの人からみれば突っ込みどころが満載でしょう。けれども、残念なお知らせになりますが、これが（すべてとはいいませんが）現状です。書いていて悲しくなるくらいですから、読んでいる皆さんはもっと悲しくなるはず。

エンジニアの皆さんがこの悲しさから逃れる方法は一つしかありません。それは『ピンと来ないアプローチをしてくる企業には近づかない！』これに尽きるでしょう。前回の寄稿の後、私は自分自身のブログのサブノート的なエントリーを書きました。そこから少し抜粋してみましょう。

エンジニア採用に長けている企業は、エンジニア出身の採用担当者がいて、気持ちの斟酌が上手い。もしくは組織を作るときにエンジニアの気持ちを理解できる人がいて、彼らが働きやすいように職場環境やキャリアプランを整えることが多い。

そういう企業が、エンジニアの間で働きやすい会社だと評判を呼んで、結果として、エンジニア採用が上手い企業になる。そのサイクルが回っている企業は人気も高いので、確かに入社するのは難しいかもしれません。けれども、幸せなエンジニアライフを送りたいと考えるエンジニアは、難関をくぐり抜けなければならない。同時に、そういう環境づくりにも積極的に関与しなければ「労働集約型のアレでしょう？」と、言われ続けることにもなるのです。

（サカタカツミ - クリエイティブディレクター）

今回からまた短期連載シリーズをお送り致します。
書き手はいつものおおかゆかではなく、サカタカツミさんによる寄稿。

サカタさんは主にHR（人材採用）業界でフリーのディレクターをされている方。『こんなことは誰でも知っている！ 会社のオキテ』や『就職のオキテ』という著書があり、Business Media 誠で「サカタカツミ『就活・転職のフシギ発見！』」という連載も持たれています。
また最近では、リクルートさんの CodeIQ のプロデュースもされています。

HR業界、特にエンジニア採用では顔の広い方で、業界内にはサカタさんの信奉者までいると聞きます。
これまで当ブログではエンジニアの視点から採用について物申してきたわけですが、サカタさんは人事の視点からこの問題について書いてくださるとのこと。

いつもは「なぜ人事はこうじゃないのか？」「こうしようよ」と言うばかりのこのブログですが、今回はその「なぜ」という部分に答えてくれる記事になっています。
今回を含めて3回のシリーズ連載、お楽しみに。

エンジニア採用は特殊である、という話

エンジニア採用の現場にいると、エンジニア採用は特殊であるという話（愚痴に近いかもしれません）を企業の採用担当者からよく聞かされます。

ただし、それは『エンジニアのことが理解できていない』採用担当者の口からであって、例えば、ウェブサービスを立ち上げたばかりの企業の採用担当者から聞かされることはありません。後者はエンジニア出身、もしくは現役エンジニアであるケースが多く、エンジニアのことをよく理解しているからです。

このブログでゆかさん（普段からこう呼んでいますので、そのまま）は『なぜ「応募資格：ＪＡＶＡ業務経験２年以上」のような求人がエンジニアに見向きもされないのか』という衝撃的なエントリーを書きましたが、そこにある『なぜ』を読んでもなお、問題が理解できない採用担当者は多いのです。

ゆかさんが書いた一連のエントリーは、エンジニア視点からのエンジニア採用における問題点の指摘でした。私は逆の視点、つまり採用担当者が『なぜ』そういう求人を出してしまうのかを、3回程度の連載形式で、この場を借りて少し整理してみたいと思います。

エンジニアが何をしているのか、採用担当者は知らない

まず、前提として、企業の採用担当者の中でエンジニアが関わる業務について精通している人は多くない、ということです。そう、自社のエンジニアがどんな仕事をしているのか、それさえ『あやふやな』理解しかしていない採用担当者がゴロゴロいるのです。もちろん、自社がどんなサービスを提供しているのか、ということは理解しています（たぶん）

Forkwell Jobs に掲載されている企業情報を例にとってみると、『会社はどんな事業を行なっていますか？』という質問には、採用担当者も答えることができます。しかし『現場で使われる技術について教えてください』という質問に対しては、まともな（＝少なくともエンジニアの琴線に触れるような）回答ができるという採用担当者はそれほど多くないのです。

もちろん、営業担当者や総務を募集するとしたなら、エンジニアではない採用担当者たちも、その仕事は容易に想像がつき、少なくとも自分には皆目理解できないということにはなりません。開発言語や環境といった、エンジニア採用で頻出する言葉も、その言葉自体のおおよその意味はわかっています。けれども、その先でなにが行われているのか、つまり『エンジニアがいったい何をしているのか』をほとんど理解していないので、それらの言葉が『採用において何を意味するのか』その重要性が、今ひとつよくわからない。

そんな状態で、エンジニアの琴線に触れるフレーズなど、当然書けるはずもなく、逆に見向きもされそうにない求人広告を出してしまうというわけです。

だからこそ、ゆかさんは先のエントリーで「だからこそ、エンジニアが採用に関与しなければならないのだ」と強く訴えています。私も同感で、プロデュースしている CodeIQ では、積極的にエンジニアの関与を増やす仕組みを作って、新しいカタチの採用プロセスを模索、実績を出してきました。

が、エンジニアが人を採用することに関与するのは容易ではありません。正しく言うと『採用担当者たちが』エンジニアを採用フローに関与させることは簡単ではない、と思い込んでいるのです。

エンジニアと採用担当者たちの壁の正体

Forkwell Jobs や CodeIQ などの求人サービスを、企業にお勧めする場合、その窓口のほとんどは人事セクションになります。彼らに「これからのエンジニア採用は、エンジニア自身が深く関わらないと上手くいきません」と私たちが言ったところで「ウチのエンジニアには、そういうことはできないですよ」とあしらわれることは少なくありません。そういう企業は、同じ社内にもかかわらず、採用担当者とエンジニアの間に、どこか余所余所しい空気が漂っています。普段からあまり接点もなく、それこそコミュニケーションはそれほど多くなさそうです。

実際、エンジニア自身と話をしてみると「そういうことでしたら、いろいろと協力したいです」とか「以前から、そういう採用に興味を持っていました」と向こうから切り出されることもあるのですが、その時、隣に座っている採用担当者たちは一応に『驚き』ます。まさか、自社のエンジニアがそんなことを考えていたなんて、という反応なのでしょう。

そういう反応を目の当たりにして、エンジニアが採用に関与することは大切だと気がついた企業（＝その採用担当者）は、採用フローの中にエンジニアを積極的にかかわらせようと取り組みはじめます。しかし、そこに立ちはだかる大きな壁を超えることはなかなかできないのが現実です。

その壁とは、先ほどから繰り返し書いている採用担当者たちが『エンジニアが何をしているのか、それがわからない』ということ。さらに、コミュニケーションすら満足に取れないので、社内での調整や役割分担も上手くいくはずもなく、結果的に、関わる人がすべて疲れ果ててしまって、採用も上手くいかない、という惨事が待ち受けているのです。

■壁を超える必要はない、と考える企業も意外に多い

エンジニアと採用担当者の間に横たわっている壁は、それほど容易くクリアできそうにありません。双方が（大げさな言い方ですが）歩み寄って、特にエンジニアの皆さんが『自分たちが何を大切にしているのか』そして『日常の業務について』エンジニア領域にいない採用担当者たちに『わかる』ように説明するところから始める必要があるのです。とても面倒な作業ですが。

ゆかさんは先のエントリーで『使えないエンジニアが入社してきて困るのはエンジニア自身』と書いています。日常の業務以外にこれほど骨の折れることをしなければならない理由を、その一点に見いだすことは、大きな価値がある。のですが、それはあくまでエンジニア自身の都合です。エンジニアの仕事とその価値を理解していない採用担当者たちにとっては「どうしてそこまでしなくてはならないのか」という気分になっても不思議ではないと。

実は「応募資格：ＪＡＶＡ業務経験２年以上」と書いてある求人広告がダメな理由はなんだと思う？　と、周囲の採用担当者に聞いてみました。いろいろな反応が返ってきましたが、「なるほど、でもなー」という言葉が続けられることが少なくありませんでした。確かに優秀なエンジニアが欲しいと、口ではいうのです。しかし、そもそも仕事そのものがよくわからないので、何が優秀であるのかも今ひとつ理解できない。結果として『現状が良くないことは認識しているけれども』何をしていいのかもよくわからなくなって、なおかつ『手間暇かけて時間取られるよりも早く人の補充を』という話になってしまう。

ゆかさんが『エンジニア求人と掛けて婚活女性のプロフィールと解く、その心は相手の視点に立つことが大事』というエントリーの文末に、こういう文章を書いています。

いや別にどんなエンジニアでもいいのでしたら、わざわざこんなことをする必要はありません。

確かにその通り。ですが、そもそも『優れたエンジニアと、そうでないエンジニアの区別』がイマイチついていない人たちにとっては、コミュニケーションの上手く取れない社内のエンジニアと口をきいたうえで、彼らの手を煩わせるような調整をすることは、苦痛以外のなにものでもありません。

企業規模が大きくなり、エンジニアが採用から遠ざかってしまった企業であればあるほど、この問題は容易に解決できません。結果として「応募資格：ＪＡＶＡ業務経験２年以上」という求人広告を出しつつ、給料や人材紹介会社への斡旋フィーを高く設定する、つまり自分たちのできる範囲のことで『なんとかしよう』と、採用担当者たちは『つい』考えてしまうのです。

（文責： サカタカツミ - クリエイティブディレクター）

「エンジニア採用の落とし穴」シリーズの第3回目。
今回がシリーズ最終回です。ちゃんとオチがつくといいですね。書きながらドキドキしてます。

さて前回の記事では、エンジニア向け求人で陥りがちなアンチパターンとして「大学の入試要項系」「俺たちが世界を変えるんだウェーイ系」「キミでもなれる！SE系」の3つのタイプを挙げました。

これらに共通するダメな点は、それを読んで応募するかもしれない相手の立場に立った視点がなく、ひとりよがりだったり相手の人格を尊重していなかったりするところ。
たとえば転職はよく恋愛や結婚にたとえられますが、「大学の入試要項系」などはさながら「年収800万円以上、身長175cm以上、首都圏在住転勤なし、親と同居不可、専業主婦希望、etc,etc…」と条件を一方的に並べ立てる婚活女性のようなもの。

さほど相手に困っていない男性がそういう女性にコンタクトを取ろうと思うでしょうか。結果、応募があっても条件だけは何とか満たしつつ後は地雷だらけの人ばかりが来ることになってしまいます。

前回の主張を繰り返し述べますが、大事なのは「ターゲットとしているエンジニアの目線に立って、彼らが欲している情報を的確に伝えること」。

ちなみにここでいうターゲットですが、技術に対して愛情がありそれを何らかの形でアウトプットしている人で、かつそれなりに業務経験があり、受け身でなく課題を自分で見つけて自発的に仕事をするエンジニアとします。
弊社でもそういう人を求めていますし、Forkwell Jobsに求人を掲載していただいているクライアント企業様のお話を聞く限りでも、概ねそういう求人像ですので。

そういったエンジニアが職を見つけようとする際、避けたいと考える仕事とはどんなものでしょうか。
それは、誰の役に立つかわからないような退屈なプロダクトを、好きでもないカビが生えたような技術で、自分のコントロール外の理不尽なマネジメントの元に作らされる仕事。それで給料が安かったら最悪です。

ですから、求人を作る際にはこの逆をやればいいわけです。
ウチはこんな人たちの役に立つ社会的意義のあるプロダクトを、ギーク好みのクールな技術で、現場のエンジニアの裁量が大きいやり方で作ってますよとアピールできれば、第一関門を突破したことになります。

どんなプロダクトを作っているかの説明は、当たり前のようですが非常に重要です。
多くのエンジニアは案外、自分が作っているプロダクトがちゃんと人のために役立っているのか、社会的価値があるのかということを気にしています。

一般に人気のWebサービスをやっている会社にエンジニアの応募が多いのはそれがわかりやすいためで、そこがわかりにくい会社が説明をおろそかにしていては、その段階で切られてしまいます。
大言壮語する必要はありませんが、自分たちのプロダクトに懸けている熱い想いがあるなら、それを書かない手はありません。
そのプロダクト、サービスはどんな人たちをどのように助けるもので、いかに社会的に価値あるものなのかを、詳しく説明しましょう。

そして次に必要なのは、どんな技術を使って作っているかの情報です。
「大学の入試要項系」はその情報をほとんど公開しないまま、エンジニアに求めるスキルだけを書き連ねていましたが、むしろ必要なのはその逆です。

どんな技術を使って開発しているのかを詳細に渡って公開することで、その職場のレベル感が伝わり、応募資格スキルを書くまでもなくちゃんとそれに見合った人の応募が見込めるようになるのです。

ですから、そこはできるだけ詳しく書く必要があります。
使用技術が公開されているものでも言語だけといった求人が多いのですが、アプリケーションフレームワークの選定がいちばん技術センスを問われるところなので、最低でも絶対にアプリケーションフレームワークは公開しましょう。

さらにDBやKVS、各種ライブラリ、テストフレームワーク、バージョン管理ツール、バグトラッキングツール、プロジェクト管理ツールといった情報も、エンジニアがその職場を判断する材料になるので極力書くようにするべきです。

最後のどんなやり方で開発しているのかという情報。これは地味なようですが、実際に働き出すとダイレクトに関わってくるところなので外せません。
どんなチーム編成で、どのようなフローでプロジェクトが進められているのか、それを知ることでエンジニアは地雷の求人を避けることができます。

何も考えていない会社にありがちなのが、知らない内に上から降ってきた仕様に、これまたPM様やディレクター様によって一元的なスケジュールが根拠なく設定され、それに間に合わせるため末端のエンジニアが日々全力で走り続けるという開発スタイルとチーム構造。

4〜5年くらい前までならばそれも許されたのでしょうが、ちゃんとトレンドを追っている今どきのエンジニアからはそういうスタイルは忌み嫌われています。
ここ数年で日本にもアジャイル開発が普及したことで、日々変更される要求に対してタスクを細かく分割してエンジニア自身が見積もりを行い、リリースされる機能や納期も柔軟に変更していくスタイルが、先進的な企業から採用されるようになってきました。

これはプロジェクト管理の民主化とも言うべきムーブメントで、これを一度経験したエンジニアは、それまでの一方的に上から押しつけられる前近代的なやり方ではもう働けなくなってしまいます。

ですので、そういうやり方を採り入れているならば、詳細にそれをアピールすることで、優秀なエンジニアが入ってきてくれやすくなります。
（そうでない場合は…、まず自社の開発を統括している人に『アジャイルサムライ』を渡して読んでもらうことから始めましょう）

以上の3つが揃って初めて、ターゲットとなるエンジニアに検討してもらえる俎上に乗ることができるわけですが、実はこれらをショートカットできる裏技もあります。

できる企業は限られているのですが、ターゲット層が評価していそうなエンジニアが会社に在籍しているのであれば、そのことをアピールするという方法です。
個人的に私が今の会社にジョインしたときもそうだったのですが、エンジニアは自分が信頼しているエンジニアが関わっている会社であれば、深く考えずにすでに地雷はクリアされているものと判断します。

「キミでもなれる！SE系」では親近感を演出するためか、入社2〜3年目の無名の社員をフィーチャーしていましたが、これは人選を誤っています。
エンジニアコミュニティで知名度の高い人をこそアピールするべきなのです。

その効用を理解しているから、SalesforceがRuby作者のまつもとゆきひろ氏を自社のチーフアーキテクトにしたり、DropboxがPython作者のグイド・ヴァンロッサム氏をGoogleから引き抜いたりしているわけです。

以上いかがでしたか？
これまでの反響から「これだけやってようやくスタートライン？ エンジニアって何様なの？」みたいな声が今回も聞こえてきそうです。

いや別にどんなエンジニアでもいいのでしたら、わざわざこんなことをする必要はありません。
自分の仕事をことあるごとに「IT土方」と卑下したり、技術に対して何の愛情もなくて、たとえば業務外でコードを書いたことがなかったり、自腹で技術書を買ったら負けと思っているようなエンジニアでいいのなら、たとえば媒体にたくさんお金を払って「キミでもなれる！SE系」の求人を出せば、応募の数は集まるでしょう。

ただ不況のころからずっとIT業界では、各社求めるスキルを持ったエンジニアが全然足りないと言い続けていて、それがスタートアップブームやらアベノミクスやらでますます獲得合戦になっている現状で、これまでのやり方では必要なエンジニアの確保が難しくなってきています。

あなたの会社のエンジニア求人を見直すきっかけになればと思い、書かせていただきました。
冒頭の話に戻りますが、採用は婚活と同じようなものと考え、自分の条件だけを押しつけるのではなく、相手の視点に立ち相手が知りたがっていそうな情報をできるだけ詳しく伝えることが大事。

自分は地雷じゃないことをさりげなく伝え、自分との結婚生活をイメージするために必要な材料を提供する、そんな求人を作ることができればあなたの会社にふさわしい人材がきっと応募してきてくれるはずです。