ジンジニアニッキ!

人事→Opsな人のニッキ。真面目なことも、そうじゃないこともごっちゃで書いてます。

採用とエンジニアリングと私

はじめに

この日記はモバイルファクトリーアドベントカレンダー23日目の日記です。
昨日は@yashims85さんのReactiveExtensionsでstreamを分割するというお話でした。
当初は@kfly8さんが書く予定だったのですが、雑談の最中に「それ、面白いから記事書いてよ」という話になり、参加することになりました。
今日は、採用担当としていろいろ担当している時に利用している思考フレームワークについてのお話です。

採用においてやっていること

採用活動においては、どのような手法で人を集めてくるのかということをまずは検討します。
その手法について、一般的なサービスの説明は以前に社内LT用にスライドをつくりましたので、そちらをご覧ください。

www.slideshare.net


また、その過程で考えているフレームワークとしては、とても素朴なPDCAです。
そちらも、以前の勉強会で発表したことがありますので、ご覧ください。

www.slideshare.net

かけるべきコストとアウトプット

自分自身が普段の業務において行っていることとしては、上記の通り非常に素朴なことです。
最近はダイレクトリクルーティングやらリファラル採用やら、採用関係のバズワード的なものがいろいろあってサービスもいろいろ出ていますが、本質的には新しいことは全くないですし、既存サービスが名称と見せ方を変えただけというものも少なくありません。

エンジニアリングと同様、銀の弾丸はありませんので、地道なことをひたすらやり続けるしか採用に至る道はないと思っています。
また、銀の弾丸はなくても札束の塊でぶん殴るということはできますが、コストに見合うだけのアウトプットが得られるかどうかは見極める必要があります。
これもまた、エンジニアリングと同じですね。

採用活動については、採用という行為そのものが会社としての利益を生み出している訳ではありませんので、そこに予算やコストをかけるべきなのかどうかは慎重に考える必要があります。
これは、採用に限らず管理部門といわれる業務一般的に同じことです。

細かくPDCAを回すことによって、採用にかけるコストは抑えることができます。
実際、モバイルファクトリーの場合は、採用担当は自分ひとり*1ですし、1人あたりの採用にかけている成果報酬や媒体費用*2も一般的な相場の3-5分の1程度です。
これは、お金をかけるべきポイントの見極めを細かくやっていることと、社員からの紹介や勉強会経由で会社のことを知ってくださった方からの応募から採用に至っていることが大きく寄与しています。

細かいPDCAを回すこと

f:id:mameco0417:20151223172112p:plain
実際に行っている思考フレームワークとしては素朴なものですが、これらを細かいサイクルで回していくということが非常に大事だと思っています。
これは、エンジニアリングでいうとことの「ちゃんとテスト書け」と似たようなことではないかと思います。


例えばですが、面接官として面接に入っている時には、相手の反応に合わせて聞き方は話し方を変えます。
自分が発した質問に対しての反応が自分の想定したようなものでなかった場合、特に自分の意図したことがうまく伝わっていなかった場合に、どうすれば相手が受け取りやすい言葉になるのかをその場でPDCAを回して振り返っています。

また、前回うまくいった採用手法が同じようなケースでうまくいかなかった場合、どうしてなのかを採用活動を行っている過程で考えます。
採用市場は日本経済や競合他社の動向に大きく左右されるので、その場その場での細かい振り返りが大事です。
特に、「P =企画すること、意図すること」を言語化できるレベルで考えておかないと、その方法がうまくいかなくなった場合のリカバリーがききません。

採用がうまくいったケースでも、その要因分析をきちんと言語化できるレベルで振り返っておくことも大切です。
前述の通り、採用市場は水ものなので、もしかすると単純に運が良かっただけなのかもしれないからです。



まとめ

  • 素朴なPDCAを回しましょう
  • 細かいサイクルで回しましょう


明日は@karupaneruraさんです。

*1:様々な人の協力あってこそなので、厳密にいうとひとり「だけ」ではないですが

*2:人件費やその他採用ブランディングのコストは含まない

YAPC::Asia Tokyo2015に参加してきました 

最後のYAPCに参加してきました。

登壇したこと

「若手エンジニア達の生存戦略」ということで座談会のファシリテーターをしました。
まとめはこちら。
(なぜか、本編と関係ない写真がOGPに使われてる…w)togetter.com

生存戦略ありません」みたいな結論の話に持って行ったけど、それぞれがいろんな形で模索していることが見れたのは良かったかなと思う。
(というのが精一杯のポジティブな感想…)

率直なところでいうと、面白い人たちのラインナップだったと思ったんだけど、うまいこと調理しきれてなくて申し訳なかったなと…。
もっと面白いし、もっと凄い人たちを集めたのに、引き出しきれなかった感じはある。
ファシリテーションスキルを上げたい。

アルコール入ったほうが面白い話がいっぱいでたから、裏座談会やりたい。
とりあえず、反省会はやりたい。


その場の雰囲気とか

カンファレンス運営(PyCon)に関わってもうすぐ3年で、YAPC参加も3回目。
やっぱりコミュニティっていいなぁって思いました。

YAPCに関しては「同窓会」みたいな雰囲気もありつつ、新しい人もいっぱい参加していて、コミュニティ自体が大きくなっている感じがした。
これを書いている今も、弊社がある五反田方面では三次会が開催されているらしく…。いい雰囲気だなと思う。

YAPCという形では(今の所)いったん終わりだけど、また別の形でそういう場があればいいなと思う。

そのほか諸々

今年のYAPCにはスタッフじゃないのにいろいろ関わらせていただいて、特に何もしてないのにオイシイところだけ持って行っていて、いろいろ申し訳ないと思いつつ、図々しくその立ち位置を甘受させていただきました。
本当にありがとうございました。

Perl業界に対してなのかエンジニアカンファレンスという広い括りに対してなのかとかはまだ何も考えてないのですが、別の形で恩返しできればと思っています。

よし、次はPyConだ!!

社内勉強会で発表したというお話

弊社の管理系部署(人事、総務、経理等のいわゆるバックオフィス系職種の部署)では月1のタイミングで各自の目標進捗を共有したり、持ち回りでノウハウ等を発表するMTGがあります。


発表する内容については他の人からリクエストを受け付けてそれに応えるのもよし、それ以外のことを発表してもよし。
時間は質疑応答合わせて10-15分程度の簡単なもの。
「資料を作るのは業務内で1時間以内程度」という、ざっくりとした縛りもある。(そこまで頑張りすぎるなよ、という意味合いです。)



今月は自分の番だったので、リクエストにお応えして「情報収集のやり方」を発表してみた。

www.slideshare.net



カンファレンススタッフやってたりするのもあって、「どうやって勉強しているの?」とか「どうやって知ったの?」とか聞かれることもままあるのですが、たいしたことはしてません。
もし、参考になることがあれば。


ところで、他の人事の人ってどうやって情報収集してるんだろうか。
「どうやって」も気になるけど、「どういう情報を」もチョット気になる。

非エンジニアだけどYAPCのトークに応募してみたというお話

内容はそのままです。

応募してみたこと

「ウチの人事がイケてない」と嘆くエンジニアのための「採用」入門講座 という名前で応募してみました。
本職は人事だし、「非エンジニアがプログラミングしてみた」系のは過去にも発表があったので、応募するなら自分の土俵で!と思って人事の話にしてみました。
自分自身は人事としてたいした経験も実績もあるわけではないのですが、タイトル大事!なので強気に出てみた!!*1

応募するのにあまり躊躇しなくなったこと

今回トークに応募してみたのにはいろいろ意図があって、社内からの応募を募りたい(自分が応募していれば「なんでまだ応募してないの?」と積極的に応募するための声かけしやすい)とか、採用系の話って実はエンジニアも関心があるんじゃないかとか、カンファレンスのスタッフしてる人事ってレアなのでいいんじゃないかとかいろいろありますが、「ま、応募しても採用されるかわかんないし、採用されなくても死なないし、応募してみればいいんじゃないか」というカジュアルな動機が一番大きいです。*2

去年までの自分だったら絶対にありえないことで、トークをするということや応募するということ、ひいては人前で自分の仕事内容や気づきを発表することに対しての閾値がここ1年でかなり下がったのだと思います。*3

人間が苦手なのとPyCon JP 2014でLTしたこと

人事という仕事をしてはいますが、私自身は元々人間対応が苦手で、猫とかPCとかと会話している方が自分にとって快適な環境だったりします*4
ひょんなことから人事になり、仕事上どうしても人とコミュニケーションをとることが不可欠なので、テクニックとかでコミュニケーションとってることがよくあるくらい。
人前で話すなんてもってのほかで、学生の前で会社説明(5分くらいとか)するときは緊張して声が震えます。

では何でここまで閾値下がったのかというと、去年のPyCon 2014でLTしたという経験が大きいです。

去年PyConでLTに応募したのは、YAPCのLTを聞いている時に「なんか、LTって良いなぁ」と思い、その時たまたまPyConがLTを募集していたので話せそうなネタで応募したら採用されてしまったという、その場の空気にキレイに流された感じでした。
数百人の前で話すのなんて初めてだし、参加者はエンジニアばっかりだし、当日発表するはずだった座長のたかのりさんがたまたま風邪引いてLTの日が入れ替わりになったせいで発表の当日に運営の合間でスライド作るし…みたいな感じだったし、緊張して足も声も震えて、このまま意識失うんじゃないかっていうくらい頭の中が真っ白だったけど、死ななかった。

まあ、LTに失敗したくらいで死なないことくらい分かってるんですけど、これまで発表したことない身からするとそのくらいハードルが高かったわけです。

発表後にTwitterみたら意外と良い反応が呟かれてて、パーティではいろんな人に声かけてもらえて、翌日のジョブフェア*5にはたくさんの方が来てくれて、良いことしかなかった。
「エンジニアはなぜ勉強会を開催して知見をシェアするのか」といった話の中でよく「発表すると良いことある(雑)」っていうのがあるけれども、自分が発表するまでは「エンジニアってすごいなぁ」っていう風にしか思ってなかった。
まさか自分があの記事と同じようなことを体験するとは!という感じ。

相変わらず、学生向けの会社説明はあんな大人数の場所よりも人が少ないのに声震えるけど。

PyCon JP 2015でもトーク募集してるよ!!!

ということで、カンファレンスとか勉強会とかいろんな場がありますが、こういう場で発表するとなんだか良いことがあるので、とりあえず応募してみれば良いんじゃないかと思います。*6

応募しても採用されなくても死なないし、採用されたなら聞いてくださる人に「よかった」と思ってもらえるように準備するしかないかな、と。
仮に自分のトークがクソだったとしても、マサカリは飛んでくると思うけど刃はついてないから死なない。(たぶん)

YAPCの宣伝みたいになっちゃいましたが、PyCon JP 2015もトーク募集しています。

ドーン!!!pycon.jp

今年はいわゆるカンファレンスのトークだけじゃなく、カンファレンスの前日に開催されるチュートリアル*7のセッションも募集されています。

締め切りは7/15(水)までということなので、ぜひ、応募してくださいー!!!

*1:けど、実はびびってる。

*2:とはいえ、実はびびってる。

*3:それでも、実はびびってる。

*4:人間は苦手ですが、嫌いではないです。

*5:PyCon 2014で開催したリクルーティング要素をいれたコンテンツ

*6:どんな良いことがあるかは@songmuさんが素敵な記事を書いていらっしゃるのでこちらを読まれるのが良いです。 www.songmu.jp

*7:講義形式で行われる有料のセッション

「採用は誰でもできることなのか」というゆるふわなお話

Blog始めようとして開設したものの、まったくアウトプットができてない私です。
久々に更新。


先日ちょっと飲んでた時に「あなたの仕事は『誰でもできること』を複数人分やってるように見える」って言われて、後からちょっとボディーブロー的な感じだったことがあり。
※注:別にdisられたわけじゃないです。


で、ふとtwitterで呟いたらなんか意外と反応があったので、ちょっとBlogにでも書いてみようかな、とかとか。




前提
  • 「自分の仕事が大変だ」とかガチで言うことほどうざいことはないと思ってるので、「採用って大変でね」とか語る気も、そういう気もないです。(「大変じゃない仕事ってあるんだろうか」という文脈において)
  • 自分が特にできるとかは思ってないですが、上記言われた時も「へぇぇー、じゃあ、やってみなー、絶対できないから。ケケケ」って思えるくらいには自分の仕事に誇りは持ってます。
じゃあ、なんなのかという話

たぶん、「採用担当になる」っていう参入障壁が低いんだろうなーっていうのが感じてたことです。


たとえば、ITエンジニアになろうとすると、プログラミングを勉強しないといけない。PCや黒い画面が怖かったりすると難しい。
たとえば、大工さんになろうとすると、いろいろ技術を学ばなければならない。体も強くないといけないし、いろいろ難しい。
たとえば、歌手になろうとすると、歌が上手じゃないといけない。歌で食べていこうとすると才能や運が必要なので難しい。


採用担当者は、(会社のなかで抜擢されるかどうかは別として)一般的なビジネススキルがあれば、おそらく誰でもできます。
たぶんね。(雑w)


「できる」と「成果を出せる」とかのゴニョゴニョとか

きっと誰でもできるであろう採用ですが、誰でも成果が出せるかというと、きっと違います。
成果を出すためにはきっといろんなスキルがあるんだと思うんですが、私はうまいこと言語化できてないですが、Linkedinが出していた資料がいい感じだったので、気になる人は見てみるといいと思います。
資料を手にいれるには登録が必要ですが、まとめてあったBlogがあったので、こういうのみてもらえると。www.social-recruiting.jp


ただ、採用(やバックオフィスの仕事)をやってて感じるのは、「できることが当たり前」なんだなーって思います。

  • 優秀な人が望むタイミングで入社すること
  • 毎年優秀な新入社員が入社すること
  • 採用した人が入社後のミスマッチなく活躍すること

全てができてようやく「当たり前」なんだと思います。
つまり、「ただできる」じゃだめで「成果を出す」ところまでできてようやく「できた」になる。*1

だから、採用がうまくいっている会社の担当者以外の側からすると「普通にやれば人が入ってくる」って感じるし、担当者がうまいことやってることに気づかなかったりする。*2
採用がうまくいっていない会社の人からすると「うちの人事はいけてない」になっちゃうし、担当者からすると「マーケットのことをわかってない」とかそんな感じになっちゃうんだろうなーって思う。*3

あああ、超絶めんどくさくなってきたぜ...ふう...w


とはいえ採用楽しいよっていう話で綺麗にまとめてみる

まあなんか、それっぽくゴチャゴチャめんどくさい感じに書いてみましたが、自分自身は採用の仕事は楽しいものだと思ってます。
人間が苦手で、どちらか言うと「猫やPCと会話しながら日本酒飲んでたい」みたいな私ですが、社内外問わず「現場の人」と話しているのはとても楽しいです。


「大変だ」「難しい」「現場はわかってくれない」
みたいなのが採用人事界隈の飲み会でよく聞く*4話ですが、弊社の人たちは基本的に採用に協力的だし、ちゃんと話すと分かってくれるし、困ることはあまりないです。


飲み会に参加していても、今やってるプロジェクトの話とか、チームでの仕事のこととか聞いてると楽しいです。
現場で起こっている問題の幾つかは、採用や人事でなんとか解決できそうなこともあったりするので「自分もちゃんと仕事しないとダメだなぁ」って思ったり思わなかったりします。


ところで

エンジニアクラスタの人とばかり飲みに行っている私ですが、たまーーーーーに人事の集まりに行ったりします。
そして、毎回、話すことなくて、隅っこでしょんぼりしてます。
隅っこで飲みながら話を聞いていると、「現場の人とうまく話せない」っていうのが人事の人の大きな悩みの一つみたいですね、はい。


そういう人は、コミュニティなりカンファレンスの運営スタッフになって、エンジニアといっぱい話す機会を作っちゃえばいいと思います。



ところで、私がスタッフをしているPyCon JP2015では運営スタッフを募集しているみたいです。
エンジニアと話ができるようになりたい人事の人は参加するといいですヨ。

ボランティアスタッフ募集について - PyCon JP 2015



運営スタッフなんかやってる時間なんてないよ!っていうそこのアナタ!
PyCon JP2015では、スポンサーの募集をしてるんですよ、これが。
エンジニアの人と話すチャーーーーンス!!!
スポンサーシップのご案内 - PyCon JP 2015

*1:このへんの話は、別に採用にかぎらず、いろんな職種でそうなんだろうとは思う

*2:メール対応とかそういうのやってる仕事だと思われて誰でもできそうとか思われがちだったりするし、そういう話は聞いた事がある。特に、「経営陣にそう思われてて困る」みたいなことはよく聞く話。

*3:こっちのケースの方が多いのかも。エンジニア「うちの人事はわかってない」人事「現場はわかってないし協力してくれない」的な。

*4:あまり人事の人と飲まないし、人事の人と何話していいかわからないからちょっと不明だけど、噂でよく聞く

「ちゃんとブランチを切って作業しようね」というお話。

前回のエントリーから日が経ってしまい、心折れそうになりつつも些細なネタを。

人事として身につけたスキル…のひとつ。
それは、
gitの使い方!
です!

以前はひとり(と、社内のたくさんの人の協力)で会社サイト運用を担当していたのですが、先月からようやくデザイナーの人が入社してくれました!

そこで起きたのが、作業の管理方法とかコンフリクトとかのこと。

デザイナーさんは時短&週3日勤務で来てもらっていること、担当プロジェクトが基本的に会社サイトだけということもあって、開発環境は私のものを使って、私になりすまし(?)て作業をしてもらってます。

で、最初の頃、何も考えずに作業してもらってたら
  • 私の作業とデザイナーさんの作業とがコンフリクト(´・_・`)
  • masterが大混雑してしまい、本番環境に反映する時にad漏れして404アラート(´・_・`)(´・_・`)
などやったりとか。

すごく当たり前のことですが、
  • masterは常にキレイにしておく
  • 作業に応じてブランチを分ける
  • 作業が終わったらこまめにcommitする
  • masterをデプロイ後はブランチにmergeして、最新の状態にしておく
というのを気をつけて作業するとコンフリクトが起きることもなくなり、
「こんふりくと???えらー???あばばばば˚̑̑̑̑̑༾(-᷄◞८̻◟-᷅)༿˚̑̑̑̑̑」
となることもなくなりました。

使い方が分かってくると、gitって便利ですなー。

もうちょっといろいろコマンド覚えてスラスラと作業できるようになろう。


「ジンジニアとは、人事としてもエンジニアとしても中途半端な立ち位置のことである」というお話。

とあるベンチャーで人事(採用)と会社サイト運用業務とか、いろいろやってます。


会社サイト運用業務ですが、

  • 採用サイトのコンテンツライティング(社員インタビューとか、3000-4000字くらいのもの)
  • ニュースリリースページの作成(最近、デザイナーさんが入社してくださったので、簡単な調整くらい)
  • サイト制作のディレクション(主に、デザイナーさんへの指示出しとか、工数の管理とか)
  • その他、こまごました修正とか(従業員数とか、誤植とかそういうもの)
  • 本番環境への反映作業(つまり、デプロイ)

とかをやってます。

本職は人事です。
だけど、ちょっと技術っぽい業務もやってます。
だから、「ジンジニア(人事+エンジニア)」。

管理系の職種(人事)と技術系の職務(会社サイトの運用)を兼務している訳なのですが、両方をうまいことやるのが難しいです。

黒い画面にごにょごにょしていると、突発的に人事業務の対応があって、とりあえずコミットしておいたら人事の仕事しているうちに忘れちゃって、追加で別のコミットしてデプロイするの忘れてた、とか。
(←これ、まさに本日あったことw)

コンフリクトがうまく解消できなかったりとか、初めて対応することとか、大きなトラブルとまではいかないけどうまくできなくて、どうしようかと思うけど同じ部署に技術のことを聞ける人がいないし、google先生に聞いても分からんし、とりあえず誰に聞けばいいんだろう、とか。

要は、技術的なスキルがない上に採用業務とかその他の業務も兼任しているわけだから、うまいことできてないんですよね。

ということで、いろいろ日常であることとか、うまくできたこと、うまくできなかったことをblogにしてみることにしました。

徒然に書いてみようかな、と。

さて、投稿がどこまで続くか…。
とりあえず、頑張って続けてみようと思いまふヾ(o´∀`o)ノ