Reach One|株式会社ビズリーチ(BizReach)【企業公式ブログ】

株式会社ビズリーチの公式ブログ「Reach One(リーチワン)」です。 Reach Oneでは、ビズリーチのメンバーやプロジェクトの紹介、社内外のイベントレポートなどを通じて、「ビズリーチのイマとこれから」をお伝えします。

REACH ONE

ビズリーチのイマとこれから

最高の仲間と絶景トレッキング!その魅力とは?byトレッキング部

こんにちは。ビズリーチ トレッキング部の小倉です。
2016年10月に、大学時代のフィギュアスケート部の先輩(現トレッキング仲間)の紹介から、ビズリーチに入社しました。
現在はコンサルタントとして、新規のお客様の経営課題を発見・解決し、お客様の成長を最大限に引き出す仕事をしています。

トレッキング部について

トレッキング部は、2017年6月に5人で活動をスタートし、現在の部員数は20名ほどです。
入部に必要なことは「仲間と助け合う心」と「ハプニングを楽しむ心」の2つだけ!
コンサルタント、エンジニア、人事など様々な部署の社員が所属しており、そのほとんどが初チャレンジです。

トレッキングは、非日常的な大冒険を簡単にできるのが魅力だと思います。
「そんな冒険を普段一緒に仕事している仲間と共に共有したい」と思い、創部しました。

直近の活動レポート

そして先日は、部員17名で某TVCMで有名になった「栗沢山」に日帰りトレッキングに行ってきました!

出発は土曜朝2時過ぎ。安全のためには早起きも必要です。
一人、寝坊するというハプニングがございましたが、電話し続けてなんとか全員で出発できました。笑

まずはバス乗り場の仙流荘でパシャリ。
f:id:bizreach:20170727101650p:plain

スタート地点の北沢峠までのバスは、運良く貸切。まるで修学旅行みたいでした。
f:id:bizreach:20170727101944p:plain

そして、いよいよトレッキング開始!!
道中、木の根っこでできた自然の階段や、透き通った川、生き生きとした木々に癒やされます。
普段なかなか一緒に仕事をする機会がないメンバー同士も、登りながら仕事や趣味についてなど、色んな話をするなかでたくさんコミュニケーションをとることができました!
f:id:bizreach:20170727103316p:plain

疲れた人の荷物はみんなで分け合います!こういう時は助け合い!
f:id:bizreach:20170727104100p:plain



そして、無事に全員で栗沢山山頂へ!!
山頂からの景色は絶景です!!! 初トレッキングのメンバーも、これには感動していました!! f:id:bizreach:20170727105131p:plain f:id:bizreach:20170727105511p:plain

山頂でのお昼ごはんも絶品~! f:id:bizreach:20170727105719p:plain

下山後は、綺麗な川で顔を洗い、足を冷やしながらゆっくりしました。 f:id:bizreach:20170727110646p:plain

最後はみんなで温泉へ!
全員、はしゃぎ過ぎて気持ちよく疲れきりました。笑
やっぱり大自然の中でみんな遊ぶって楽しいですね!!

トレッキング部の魅力

トレッキング部は、見たことのない綺麗な景色、澄んだ空気や川、植物、虫を見たり、達成感と共に美味しさが倍増する食事などを通じて、ハプニングあり笑いありの大冒険を「仲間」と簡単にできるのが魅力だと思います。
非日常空間で苦楽や感動を共有するからこそ、普段と違う一面を知れたり、普段関わらない部署の人と一生の思い出ができ親友のようになったりと、深いコミュニケーションができるのだと思います。
そして大自然の前では上下関係もなく、全員フラットに遊べます。
社内ですれ違ったら全力の笑顔で声掛けますよね。笑

ビズリーチには「Work Hard, Play SUPER Hard」というバリューがあります。
仕事も遊びも一切手を抜かず、何事も全力でやりきるのがビズリーチ流。
そんな仲間と、今後も冒険できるのが楽しみです。

ありがとうございました!

f:id:bizreach:20160823213758j:plain

この記事を書いたメンバー

小倉 淳 / Atsushi Ogura


2016年10月にビズリーチに入社し、現在は企業様向けコンサルタント。インパクトの大きな仕事を称える社内表彰式「インパクトアワード」にも選出される。趣味はフィギュアスケートと登山。世界7大陸最高峰の3座を登頂したところで、こっそりビズリーチマンとして7座登頂を目指している。

仕事も子育ても全力で。ワーママが語る「諦めない働き方」

こんにちは!広報の午頭(ごとう)です。
今回は、ビズリーチで活躍するママ社員についてお届けしたいと思います!

実は、ビズリーチの女性従業員比率は、38.2%。(情報通信業界の平均は25.1% ※1
そして、育児休暇からの復帰率は男女ともに100%なんです!(2009年の創業時~2017年7月現在まで)

【株式会社ビズリーチの女性従業員比率、育休復帰率】 f:id:bizreach:20170720104633p:plain

※1 「平成26年経済センサス‐基礎調査結果」(総務省統計局)(http://www.stat.go.jp/data/e-census/2014/pdf/kaku_yoyaku.pdf)(2017年7月24日に利用)

このように女性が多く活躍するビズリーチには、家庭と仕事を両立しながら高い成果をあげているワーママがたくさんいるのですが、今回はそのなかの3人と座談会を開催。
一日のスケジュールから両立のポイントまで、気になるところを聞いてきました!

f:id:bizreach:20170720105119p:plain

廣田 由子 / Yuko Hirota 
大学卒業後、大手医療機器メーカーで研究職や新商品開発のPMに従事。2015年7月にビズリーチ入社。入社後は、即戦力人材と企業をつなぐ転職サイト「ビズリーチ」の法人向けコンサルタントを経て、大手企業専任チームへ異動。現在は、担当する企業様の経営課題を解決すべく、ビズリーチが展開する各プロダクトの他にも、イベントの企画・集客サポートなどを含む幅広いソリューションを提案中。プライベートでは4歳の息子を持つ一児の母。写真左。

林 スンヒョン / Seunghyun Lim
日本の大学を卒業後、ネット広告代理店等を経て、2013年6月にビズリーチへ入社。その後はデザイナーとして、20代のためのレコメンド型転職サイト「careertrek(キャリアトレック)」の立ち上げを担当。2015年5月から約一年半の産休・育休を取得。昨年の9月に復帰し、OB/OGネットワーク「ビズリーチ・キャンパス」のデザイン、2017年5月からは戦略人事クラウドサービス「HRMOS(ハーモス)」のUI/UXデザインを手がける。2歳になった息子の育児に奮闘中。写真中央。

丹野 羽衣子 / Uiko Tanno
大学卒業後、大手人材サービス企業、ITベンチャー等を経て、2014年3月にビズリーチ入社。「ビズリーチ」の法人向けコンサルタントとして首都圏近郊の企業様を担当し、2015年4月から産休・育休を取得。2016年5月に復帰後は、廣田と同じ大手企業専任チームで、企業様の採用支援や、新商品開発プロジェクトなどを担当。4歳の息子、2歳の娘、夫との4人家族。写真右。


自分が働く意味を見いだせる会社なら、頑張れる

——今日はよろしくお願いします!まずは皆さんがどうしてビズリーチに入社したのか、聞かせてもらえますか?

廣田: 私は新卒で大手医療機器メーカーに入社し、研究職や新商品の開発のPMなどを経験させてもらいました。それなりにハードな時期もありましたが、大きなやりがいを感じながら働けていましたね。ただ、産休から明けて復帰したタイミングで、会社が任せてくれた仕事と、自分がやっていきたいと思っていた仕事の方向性にズレを感じるようになって。会社としては、「産休明けで大変だろうから、少し余裕をもってできる業務をやったら?」という配慮をしてくれたと思うんですが、私としては「大好きな会社だからこそ役に立ちたいのに、今の私は会社にとって役に立っているのか?役に立てる日が来るのか?」という違和感を感じたんです。そこで、また大きなやりがいを持って働ける環境を、社内外含めて探していたタイミングで、ビズリーチに出会いました。

——具体的にはどういう軸で探していたんですか?

廣田:前職で様々なタイプの業務にチャレンジさせてもらうなかで、例えば実験していいモノを作る、といったような「対モノ」の仕事よりも、社内外の人に協力を仰ぎながら「どうやって作っていくか」というプロセスの改善をしていくような「対ヒト」の仕事の方が自分には合っているんじゃないかと感じていました。 また、子供が生まれたことで「人」や「キャリア」にすごく興味がわくようになったんです。「世の中で活躍している人って、どういう経験を積んできたんだろう?」ということが気になるようになったりして。そういうところから、それぞれの人が自分らしく輝けるための支援を、自分の仕事を通じてできたら素敵だな、と思うようになっていきました。

——HR領域でサービスを展開する会社は数多くありますが、そのなかでビズリーチに決めた理由は何だったんでしょうか?

廣田:率直に、「インパクトのある事業をやっているな」と思えたのが大きいと思います。あとは、面接で会った人が魅力的で一緒に働きたいと思えたこと、自分自身が貢献できるイメージをしっかり持てたことが決め手になりましたね。 実は選考のなかで、二人目のお子さんを妊娠中だった羽衣子さん(丹野)にも面接してもらったんです。実際に子どもがいながら働いている社員とリアルに話せたことで、働くイメージをより鮮明に持つことができました。

——ありがとうございます。林さんはどうしてビズリーチへ入社したんですか?

:私は前職のネット広告代理店で一緒に働いていた先輩が先にビズリーチに入社していて、誘ってもらったのが最初のきっかけです。ビズリーチは当時から海外にも進出していて、グローバルなサービスに携われたら面白そうだなと思いました。また、外国人の社員も多くいて、そういった環境で働けることも魅力に感じました。

——丹野さんはいかがですか?

丹野:私の場合は、一時期子どもの体調が悪くて、働くことをあきらめていた時期がありました。でも、少しずつ子どもの状態が回復に向かい始めたときに、ビズリーチで働く知り合いにちょうど声をかけてもらったんです。もともとキャリアを積んできた人材の仕事は好きでしたし、子育てと仕事を両立していく必要があるなかで、全く新しい業界に飛び込むより自分に知見がある領域の方が価値提供ができるんじゃないかと思っていました。

ただ、「まるっきり同じことをやり続けるのもつまらないな」と感じていたので、当時から人材の領域にインターネットを持ち込んで新しい価値を生み出していたビズリーチにはとても惹かれました。自分が知見をもっている領域で、強みを生かしながら新しいことを仕掛けていける。そう思うとワクワクしましたし、ビズリーチという会社が目指す世界観や今後の可能性を知るうちに、「この会社なら多少無理をしてでも頑張りたい」と思い、入社を決めました。

——廣田さんと丹野さんはお子さんがいる状態でビズリーチへの入社を決めたかと思いますが、ベンチャーで働くことに不安はなかったですか?

廣田:ビズリーチも当時は今ほど制度も整っていなかったですし、もちろん不安はありましたよ。でも、「子どもを預けてまで働く意味を見いだせるところなら頑張れる」と思っていたので、後からどうにでもなるかなと割と楽観的にとらえていました。親であれば、本来は子どもと一緒にいたいのは当然だと思うんです。それでも仕事をするのであれば、働いている時間を最大限有意義なものにしたい。そう考えると、不安よりも「やるしかない」という気持ちの方が勝りましたね。

大切なのは、信頼関係を丁寧に作っていくこと

——実際に入ってみて、やっぱり大変でしたか?

廣田:ビズリーチに入って、というよりは、産前産後の自分の働き方を根本的に変えることに必死だったと思います。出産前は9~22時まで働いても自由でしたし、前職では「明日から一週間出張いってきます!」ということもよくあったので。以前と同じやり方では全くやっていけないな、と最初は衝撃を受けました。

——そこからどのように乗り越えていったんでしょうか?

廣田:う~ん、“Just Do It!”って感じですかね。笑 とにかくタスクを溜めないようにしたり、効率的なスケジュールの組み方などには以前に比べて断然こだわるようになりました。二人はどうしてます?

丹野:私は必要に応じて、自分の状況をお客様にも開示しています。会社には18時までしかいられないことを伝えた上で、緊急時の対応などについては事前にお客様と相談して決めています。使える時間が増えるわけではないですが、自分の状況をオープンにすることで、精神的にかなり変わると思います。

:私はそれぞれの業務の目的と優先順位を常に明確にすることを意識しています。何のためにこのデザインをするのか、を繰り返し問うことで、仕事の質もスピ―ドも圧倒的に改善したと感じます。また、ビズリーチでは新規事業に携わることが多いので、スピード感を持って形にしていくためにも、分からないことがあればすぐに周りに聞いて助けてもらったり、逆に自分も以前より意識して他メンバーのフォローをしたりしていますね。

廣田社内外を問わず「信頼関係を作ること」がベースになっているかもしれないですね。私も以前と比べて、丁寧なコミュニケーションを心掛けるようになったと思います。

丹野:たしかに。私も「人としてどうなの?」というミスは絶対にしないように気を付けています。笑

ママ社員の存在がチームの生産性をアップさせる

——みなさんが個人で意識していることを聞かせてもらいましたが、やはり一緒に働く仲間の理解や協力も大切かと思います。そのあたりは実際ビズリーチで働いていて、どう感じますか?

:私の部署ではエンジニアやPM(プロダクトマネージャー)でパパの人がとても多いんですよ。今の上司である園田さん(執行役員の園田 剛史)も3人お子さんがいますし。そういうパパ社員たちが「今日は保育園のお迎えだから早く帰ります」ということを普段から発信しているので、自分が特別目立つといった感じはないですね。

廣田:経営陣や部長陣にもパパが多いのは良いよね。うちのチームでも最近、一か月間の育休をとったパパがいますよ。毎週月曜に開催している全社朝会の時間も一年ほど前に変更されて、子どもを保育園に送ってからでも余裕を持って参加できるようになりましたし、会社全体としてもより柔軟に進化しているなと感じます。

丹野:そういう意味では、私たちがもっと社内に発信していくことも大切だよね。私の場合は1on1(1対1のミーティング)などで上司に、「二年後に上の子が小学生になるんですけど、そうすると学童の都合で17時には会社を出ないといけなくなります。今よりさらに時間が減るけど、お客様の社数や裁量は減らしたくないんです。」と話して、そのときまでに何を身に着けておくべきか、ということを相談しています。そういう話を聞いてもらえるのは、すごく心強いですね。

廣田:あ、あとうちのチームではママ社員が何人かいるので、全員でより生産性高く働くために、共通化できる業務を洗い出したり、Tipsを共有する会もやっていたりしますね。デスクトップはこう整理するとすべてのデータに3秒以内にたどりつける、とか。笑

——「ママ社員の発信がきっかけで、チーム全体の生産性がアップする」って、すごく良いサイクルですね!

f:id:bizreach:20170720111301p:plain

一日のスケジュールは?

——想像するだけでみなさん忙しそうですが、実際の一日のスケジュールを教えてもらえますか?

【ママ社員 3人のスケジュール】

f:id:bizreach:20170720134148p:plainf:id:bizreach:20170720134153p:plain

f:id:bizreach:20170720134151p:plain

完璧を求めすぎないこともポイント

——廣田さんはけっこう直帰することが多いんですか?

廣田:はい。移動効率を考えて、意識的に入れるようにしています。

——移動時間ってけっこう大きいですもんね。ちなみに、、毎日洗濯しないとやっぱり回らないんですか?笑

丹野:子どもがいると、本当にあっという間に洗濯物がたまるんですよ!一人暮らしのときと違って衝撃だった!あれは何なんだろう?(笑)

:洗濯つらいですよね。食器洗うのも。(笑)

廣田:でも今は色々便利な製品があるから、テクノロジーを最大限活用していいと思う。私はお互いのスケジュールやタスクを旦那とアプリで共有して、フォローしあってます。

丹野:そうそう、食洗器もいいのあるし、うちなんてルンバの二台目を買おうとしてるよ。(笑)前は自分に高いハードルを設定しすぎて、家事を完璧にできない自分にモヤモヤしていたけど、今は割り切るところは割り切れるようになりました。例えば、私は平日は料理をしないと決めていて、土日に全部作りためてます。ちょっと味は落ちるかもしれないけど、母親が笑顔でいることの方が子どもにとっては大切かなと思って。

——なるほど、完璧を求めすぎないことも両立のポイントかもしれないですね。とはいえ、先ほどのお話を聞いて、みなさん起きてから寝るまでのスケジュールをかなり細かく管理されていて驚いたのですが。

廣田:たしかに、朝起きてから寝るまでの行動は分刻みで暗記してますね。

丹野:うちは決まった時間になると、毎日3回自動で音楽が鳴るようにタイマーを設定してますよ。まず7時40分になったら、となりのトトロの「さんぽ」が流れ出して、みんなが靴を履いて家を出る。帰宅したあと20時45分になると、「マルマルモリモリ!」が流れて、旦那と子ども達がお風呂に入る。それで21時半になると、「きらきら星」が10分くらい流れて、それぞれ寝る前にやり残したことをやる。おもちゃの片付けとか、絵本を読んだりとか。条件反射をうまく使ってます。(笑)

——漫画になりそうな光景ですね!(笑)

丹野:自分が仕切らないと流れていっちゃいますからね。

——家庭でもしっかりリーダーシップを発揮されていることがよく分かりました。(笑)



どちらかを諦める必要はない

——みなさんの今後の目標って、何ですか?

:私は、問題解決能力が高いデザイナーを目指しています。得意な部分を伸ばしながら、提案力や企画力ももっと磨いて、ユーザー様を深く理解したうえでビジネスに貢献できるデザイナーになりたいですね。プライべートでは、子どもと旦那にもっと美味しいご飯を食べさせられるように、料理の上達が目標です!

廣田:大目標としては、若い世代の人たちが早くから社会との接点を持って、たくさんの選択肢を知れる社会を創りたいです。手段としては「ビズリーチ・キャンパス」のようなサービスでも、私個人を経由してでもいいと思っています。なので、直近だと担当させていただいている企業様とその候補者様をつないでいく部分で、もっと大きな価値を提供したいですね。そのために、お客様にもより信頼いただける人になって、より深く入り込んでいきたいです。前職では専門職の世界にいたので、限られた情報にしか触れることができなかったですが、ビズリーチにいると社会で活躍している多様な人を知ることができるので、仕事で学んだことを子ども達にも伝えていきたいですね。

丹野:私は、「解を描ける人」でありたいと思っています。ビズリーチには優れたプロダクトや様々なスキルやバックグラウンドを持った社員がいます。そういった会社の強みを活かして、今まで世の中になかった解決策もデザインでき、お客様に気付きを与えられる人でありたいです。あとは、自分のキャパシティを広げるために、仕事でも家庭でもない「第三の扉」を開きたいと思っています。山に登ったり、釣りをしたり、なんでもいいと思うんですけど、そういう新しいインプットを通じて自分の幅を広げることで、巡り巡って仕事にもつながってくると思うんです。

廣田:私も茶道を復活しようと思ってます!仕事をしていて、子どもがいるからといって、どちらかを選ぶ必要も、何かを捨てる必要もないんだって最近気づきました。

ビズリーチは、頑張る人をどこまでも応援してくれる会社

——最後に、ビズリーチは女性が働く環境として、ずばりどう思いますか?

丹野:個人的には、子供がいる人を雇うのって会社にとってある意味リスクもあると思うんです。子どもが熱を出したら、急に会社を休まないといけないこともありますし。それでも、新商品の開発のような会社にとって重要なミッションだったり、責任の大きな仕事を任せてくれるのは、懐が深いなと思いますね。

廣田:たしかに、「こんなにやりがいのある仕事を任せてもらってるんだから、しっかり応えたい!」という気持ちは強いですね。

:私もこれまで何度も新規事業の立ち上げを担当させてもらっていますが、大きな案件を任せてもらえるのは素直に嬉しいし、会社に感謝しています。

丹野子育てって人生のうちの一瞬の出来事だけど、その後も人生は長く続いていくからね。会社が積極的に新しい制度を考えたりつくったりしれくれるので、そのスタンスがすごく嬉しいですね。

廣田:私は「ビズリーチは、頑張る人をどこまでも応援してくれる会社」だなと感じます。そこで本人が「応援してくれるなら頑張ろう!」と思えるかどうかが大事な気がします。

丹野:そうですね。あとは、このスピード感でたくさん新しい制度ができているのだから、アイデアがある人が積極的に発信して、どんどん新しい仕組みを作っていけばいいと思います。それができる会社だと思うので。

——そうですね。より働きがいがある環境を、これからも社員が主体的につくっていきたいですね!たくさんお話を聞かせていただき、ありがとうございました!



ビズリーチの制度について

ビズリーチには、社員一人一人のキャリアを尊重し、大きなやりがいを持って働くことを応援するための制度があります。
最後に、ママ社員の声をもとに2016年8月に新たに作られた2つの制度について概要をご紹介します。 (その他の制度はこちら

ランウェイ(出産復職支援制度)
出産からのフルタイム正社員復帰をサポートする制度です。
早期復帰特別賞与(出産から復帰までの日数により変動)、幼稚園・保育園・ベビーシッター費用補助(毎月最大3万円)を提供することで、女性社員のスムーズな仕事復帰を支援しています。社内の適用ルールに準じて、お子さんが小学校に入学するまで支給され、社員が十分にパフォーマンス発揮できる環境を提供しています。

マイチョイス(勤務形態選択制度)
ライフステージに合わせて働き方を選べる制度です。
予期せぬ親の介護など、働けなくなるリスクを恐れず、安心して働き続けてほしいという想いから形になりました。勤務日数と勤務時間などの組み合わせから自身の生活にあった働き方を一定期間選択できます。(例:週3日×6時間勤務 など)



今回は、ビズリーチで活躍するママ社員にリアルな本音も含めて話を聞いてみましたが、いかがでしたか?
「働き方」や「家庭と仕事の両立」といったテーマは、採用面接などでも特に女性の方から多くいただくご質問です。Reach Oneでは今後も、上記の制度を実際に利用している社員へのインタビューなども含め、ビズリーチの働き方やカルチャーが伝わるような情報発信をしていきたいと思います。

今回の座談会を通じて、私個人としても将来に向けた学びがたくさんあったと同時に、これからも社員がどんどん発信して、より働きがいのある環境づくりに主体的に関わっていきたいと感じました!
ありがとうございました!

f:id:bizreach:20160823213758j:plain

この記事を書いたメンバー

午頭 優佳 / Yuka Goto


2015年6月に株式会社ビズリーチに入社。「ビズリーチ」の採用法人様向けコンサルタントを経て、2016年8月から広報。現在は、採用広報とリクルートメントマーケティング室(マーケティングの手法で自社の採用活動を最適化するチーム)の立ち上げを担当。

課題解決のための技術選定~4つの事業でフロントエンド開発に新技術を導入した話~

f:id:bizreach:20170719190244j:plain

こんにちは。エンジニア・デザイナーの新卒採用を担当しています、荒井です。
暑い日が続いていますが、皆様いかがお過ごしでしょうか。

先日、ビールが美味しいこの季節にピッタリのイベント「Frontend Beer Bash」がビズリーチのオフィスにて開催されました。
名前の通りフロントエンドの開発に特化したイベントで、「Angular vs React vs Vue.js」がサブテーマとして掲げられており、ビズリーチで実際に開発に携わっているメンバーによるLTやトークセッションが行われました。 www.bizreach.co.jp

ビズリーチでは、プログラミング言語やシステムのアーキテクチャにおいて様々な技術を採用しています。
そのほとんどは事業フェーズや事業の目的に合わせて、現場で開発に携わるメンバーが自ら技術選定を行います。また、お客様やユーザーの皆様に対してより大きな価値を提供できると判断した場合には、新しい技術も積極的に取り入れていきます。

そんなビズリーチの「現場の開発者が大きな裁量を持ってプロダクト開発を進めていくカルチャー」をより多くの方に知っていただきたいと思い、今回は「Frontend Beer Bash」に登壇した4名に、それぞれのプロジェクトにおける技術選定の背景や実際に導入してみて感じたことを聞いてきました。
ここからはビズリーチcareertrekHRMOS、社内向け新規サービスの4つの事例をご紹介します。

1. 即戦力人材と企業をつなぐ転職サイト「ビズリーチ」の場合

f:id:bizreach:20160823213758j:plain

ビズリーチ フロントエンドエンジニア

小枝 優駿 / Masatoshi Koeda


2014年にフロントエンドエンジニアとして入社。幼少よりマークアップに触れ、Qiitaでは一時トップ記事として「HTMLを15年書いてる僕が語ってみる」が掲載され、はてなブックマークの人気エントリにも。前職では大手広告代理店の業務を主とし、数千ページの実装を行ってきた経験を活かしてビズリーチのフロントエンドエンジニアリングを牽引。 趣味はテレビゲーム、スケートボード。

採用した技術と導入のポイント

  • Angularを採用
  • 「安全性」が最重要
  • サーバサイドのAPI化を進めるにあたり、フロントエンドにも新しい技術の導入が必要
  • ヒューマンエラーをなくし、かつ取り扱うデータの整合性を保つ解として、型安全であること
  • TypeScriptを用いて作られたフレームワークとして、Angularを採用
  • 結果として、対応できる案件が過去と比較すると増え、生産性が劇的に向上した

Q.導入の経緯を教えてください

「ビズリーチ」は、株式会社ビズリーチが運営しているプロダクトの中でも一番歴史が長く、システムとして改善が必要な部分も増えてきていました。
今までも課題感こそあったものの、多くのユーザー様に日々ご利用いただいているなかで新しい技術を導入したり、アーキテクチャレベルでシステムを作り変えるという選択になかなか踏み込むことができませんでした。

私は元々スタンバイというサービスの開発に携わっていたのですが、「ビズリーチ」事業に異動になったタイミングで「えだっち(社内で呼ばれているあだ名)が来るなら今までできなかったことをやろう!」と同じチームの仲間が言ってくれたことで、今回のAngular導入プロジェクトが動き出しました。
私自身、長年フロントエンドエンジニアとして数々のサービス開発に携わっており、自分の技術に対してある程度の自信や誇りを持っていました。このように周りから期待をしてもらったことが嬉しかったし、このプロジェクトを通じて今後の開発がスムーズになることで、よりお客様に「本質的な価値」を提供できる時間が増えることに対して、自分自身も大きな期待感を持てました。

このプロジェクトでの技術選定や、その時考えたことなどはデザイナーブログにまとめましたので、詳しくはこちらの記事をご覧ください。 design.bizreach.co.jp

Q. 実際に導入してみてどうですか?

結果としていいことばかりでした。

やはり大きな恩恵を受けたのは、安全な実装ができることです。人的ミスによる手戻りが劇的に減りました。Angularの導入にあたり、「ビズリーチ」の中で使用されているコンポーネントをいくつも作っておいたため、新規画面を作る時間も短くなりました。

また、若いメンバーの育成にも良い影響がありました。フロントエンドの開発者の中にはJavaScriptに慣れていないという人もいますが、勉強会や小さなタスクをこなしていくことを通じて段々とJavaScriptが書けるようになるメンバーもいました。

新しい技術を導入するためには、チームメンバーが学習するための時間がある程度必要でしたが、チームメンバーのモチベーションも高く、積極的に社内での勉強会を開催したことで、スムーズにメンバーの学習と、技術の啓蒙を進めることができました。

2. 戦略人事クラウド「HRMOS(ハーモス)」の場合

f:id:bizreach:20160823213758j:plain

HRMOS フロントエンドエンジニア

浅井 雅彦 / Masahiko Asai


大手のWeb企画・制作企業にて、ナショナルクライアントの大規模なWeb制作を手がける。その後、自社のサービス開発でのやりがいを求め2015年にビズリーチに参画。HRMOS事業部のフロントエンド開発を牽引している。

採用した技術と導入のポイント

  • Angularを採用
  • 元々AngularJS + TypeScriptの構成で稼働しているWebアプリケーションであった
  • 開発チームの人数が増え、今後さらに大規模なアプリケーションになっていくことが明白だった
  • AngularJSが抱えているパフォーマンスの課題が顕在化しつつあった
  • 現状の資産とメンバーが持っているスキルを最大限活用しながら、モダンな環境に移行していきたかった
  • 現在移行を進めている最中。機能単位で徐々に移行していくアプローチを採用

Q. 導入の経緯を教えてください

現在、HRMOSでは主にAngularJS + TypeScriptを用いて開発を行なっています。 機能拡充によりアプリケーションが大きくなっていく中で、昨年9月にAngular 2がリリースされ今後のAngularJSのロードマップが不透明になってきたことと、今年初めにはAngularJSにおけるパフォーマンスの課題が顕在化してきたため、新しいモダンなフレームワークへ移行を検討することになりました。

HRMOS自体まだ発展途上のプロダクトであることから、既存のコードベースで機能改善も行いつつ、新しい環境を構築していけることが導入の条件としてありました。

その中でAngularが第1候補に出てきたのは、現行の環境でもTypeScriptを既に導入していること、個人でAngularを触っていたメンバーが数名おり、触ってみた結果比較的ポジティブな感触であったことが大きかったです。

また、Angularは学習コストが比較的大きいフレームワークですが、その中でもポジティブな感触だったのは、従来のAngularJSとはコードの書き方が変わっているものの、アーキテクチャの考え方が類似している点があったからかもしれません。スムーズに移行できるであろうと判断し、最終的にはAngularを選定しました。

Q. 実際に導入してみてどうですか?

現在はAngular4への移行を進めている最中でまだ移行途中なため、最終的な所感はまだ判断できませんが、AngularJS時代に苦労していた部分が多数解消され、開発しやすくなった点は大きいと感じています。

またAngular CLIというCLIツールの出来が良く、Angularのベストプラクティスに沿って基盤が整備されているところも大きいです。 標準でユニットテストのコードが付いてくるため、現場全体でテストコードをもっと書いていこうという流れができつつあります。

Componentをどの粒度で分けるかは、開発メンバーの中で議論しながら試行錯誤を重ねている段階です。Vue.jsの話の中で日本語ドキュメントの充実具合について言及されている一方、Angularでは日本語のドキュメントが少なくて苦労することもありますが、メンバーが持ち回りでドキュメントを翻訳して、それをベースに勉強会を開催して知見を深めていくなどの工夫を行っています。

3. 20代のためのレコメンド型転職サイト「careertrek(キャリアトレック)」の場合

f:id:bizreach:20160823213758j:plain

careertrek エンジニア

西名 順平 / Junpei Nishina


iOS/Androidアプリ開発、フロントエンド開発、サーバサイド開発の経験を活かし、現在はキャリアトレック開発チームの新規技術導入を主に担当。 最近の興味の対象はドメイン駆動設計とReactNativeで、プロダクションに本格投入する機会を虎視眈々と狙っている。

採用した技術と導入のポイント

  • React/Reduxを採用
  • 事業拡大にあたりモノリシック→マイクロサービスに移行する必要
  • React or Vue.jsという2つの選択肢
  • 将来的にReact Nativeを利用したネイティブアプリ開発の可能性を考慮
  • 機能の見直しも同時に行ったこともあり、レスポンスタイムが大きく向上

Q. 導入の経緯を教えてください

キャリアトレックは2014年にグランドオープンしてから、順調にサービスを拡大してきました。今まではスピード重視で開発してきましたが、さらなる事業拡大に向けてアーキテクチャの見直しが必要なタイミングでした。
具体的にはモノリシックな作りからマイクロサービスにし、サーバサイドとフロントエンドの作業分担を円滑にするためREST APIとSPAというアーキテクチャを採用し、フロントエンドのフレームワークとしてはReact/Reduxを導入しました。

Angularは時期的に変化が激しいタイミングだったので追いかけきれない可能性を感じていました。また、一度Vue.jsでプロトタイプも作りましたが、どのフレームワークを選んでも結局そこそこ学習コストがかかるため、コミュニティの大きさやコンポーネント指向の書きやすさも考慮してReactを採用することにしました。さらに、その中で将来的にReact Nativeを利用したネイティブアプリ開発の可能性も考慮していました。学習コストはある程度かかるものだと考えていました。

Q. 実際に導入してみてどうですか?

今までの技術から新しい技術にジャンプしたこともあり、学習にはそれなりに時間がかかりました。
施策として「モダンjs勉強会」というものをチーム内で開催し、講師は持ち回りで、1年目のメンバーも積極的に協力してくれました。
導入にあたり苦労した点は「Componentって何?」という共通認識をチーム全体で合わせることでした。今回はサービスの中の一機能をリニューアルしたのですが、今後他の機能にも展開していくにあたり「どんな作りが最適なのか」を模索していました。様々な試行錯誤はしたものの、結果として無事Reactの導入に成功し、これからサービスを改善してくための足がかりを築くことができました。

コンポーネント単位で実装/テストが出来るようになったので、作業範囲が明確になり、複数人で同時に開発するときにブランチ同士のコンフリクトも起こりにくくなりました。Reactの導入と直接関係はありませんが、今回のリニューアルプロジェクトによりプログラムの処理を見直したことで、レスポンスタイムを劇的に向上させることができました。新しいことにチャレンジするときには必ず負荷がかかりますが、予期していなかった部分まで改善することができ、手応えを感じています。

4. 社内向け新サービスの場合

f:id:bizreach:20160823213758j:plain

ビズリーチ エンジニア

松岡 幸一郎 / Koichiro Matsuoka


早稲田大学卒業後、日本IBMを経て、2015年に株式会社ビズリーチに入社。 キャリアトレック事業部にて約2年間開発に従事し、現在は社内システムの新規開発プロジェクトにてアーキテクト兼スクラムマスターを担当。基本はサーバーサイドエンジニアだが、Vueを用いたSPAアーキテクチャを構築、開発中。サーバーサイドではドメイン駆動設計を全力推進中。 趣味はサバゲー、カート、ボードゲーム、筋トレ、植物栽培。

採用した技術と導入のポイント

  • Vue.jsを採用
  • 社内向けの新規サービスの開発
  • プロジェクト発足のタイミングではフロントエンドエンジニア不在
  • Angular、React、Vue.jsを使っているプロジェクトにヒアリングを行いVue.jsに決定
  • プロジェクトの目的を元にアーキテクチャとしての最適解を有識者と徹底的に議論
  • 手厚い日本語のサポートでスムーズに開発を進められている

Q. 導入の経緯を教えてください

新規サービスとして社内向けのATS(Applicant Tracking System)を、現在は5人のチームで開発しております。
フロントエンドのフレームワークを決定するにあたり選択肢として上がっていたのはBeer BashのディスカッションのテーマにもなったAngular、React、Vue.jsの3つでした。それぞれのフレームワークに関して社内での開発実績があるメンバーからヒアリングを行い、自分たちが作るサービスに対して最適解を模索していました。新しいサービスなのでスピード感を持って開発したいという思いがあったため、「学習用の日本語ドキュメントが充実している」「仕様がシンプルである」「ルーティングの仕組みやCLIも備わっている」という観点でVue.jsを採用することとなりました。

Q. 実際に導入してみてどうですか?

社内に有識者がいたため、プロジェクト初期はよりよい設計について細かく相談させてもらい、議論しながらチームのノウハウを溜めていきました。しかし、開発が軌道に乗ってきた後でも課題や疑問に思うことが何度も出てきます。Vue.jsには日本人のコミッターが在籍しているため、ドキュメントに加えslack上での公式サポートチャンネルなど、とにかく日本語で素早く情報収集できることがありがたかったです。抱えていた問題が10分で解決するということもありました。

その他の技術としてFlowによる型チェックを導入しています。細かなミスは防げる一方、TypeScriptと比較すると型づけの制約が弱い点があるため不安な面もあるのが今後の課題です。現在も継続的に学習を行っていますが、それぞれのフレームワークに関して有識者が集まっており、情報交換や品質向上のための相談などを気軽にできる環境はとてもありがたいです。

ビズリーチの開発チームが大切にしていること

今回4名の社員へのインタビューを終え、ビズリーチの開発チームが大切にしていることは、大きく3つあると感じました。

1. 課題解決のために、新しい技術も積極的に導入する

開発現場において、新しい技術を導入したりアーキテクチャを刷新することはコストと見られてしまうこともよくありますし、「大きな不具合を引き起こすのではないか」という心配はあります。しかし、私達が運営している数々のサービスは「作って終わり」ではなく、今後もサービスを長く育てていく必要があります。今までのシステムを使い続けることも選択肢の一つではありますが、長期的な目線でサービスの成長を考えた場合に、新しい技術を導入することでお客様への提供価値を最大化できるのであれば、積極的にチャレンジしていくという風土が根付いてます。開発者は新しい技術を使うこと対してはポジティブなケースが多いですが、それがただの自己満足ではなく「〇〇という課題を解決できるから」と、開発者がビジネス的な観点を持つという姿勢も大切だと再認識しました。

2. 技術選定の裁量は、ビジネス視点も兼ね備えた現場のエンジニアが持つ

サービス開発において、そのアーキテクチャが最適かどうかはビジネスの内容やプロダクトの規模感に応じて変わります。技術は分かるけど、ビジネス観点がない開発者ではその最適解を見つけることは非常に難しいはずです。ビズリーチの開発組織では、創業当初からCPOの竹内が「ビジネスも分かるエンジニアになってほしい」という言葉を投げかけてきました。実際エンジニアの仕事を見てみると、機能を実装するためにコードを書くだけではなく、ユーザーの行動分析から事業におけるボトルネックを見つけたり、サービスグロースのための新しい企画のMTGに顔を出したりと、ビジネス的な考え方を求められるシーンが多くあります。それらの業務を通じて「ただ単に言われた機能を開発する」ではなく「事業課題を解決するために開発する」という意識が浸透しています。ビジネス的な観点と技術力の双方があるからこそ、現場のエンジニアに安心して技術選定を任せることができるのだと思います。

3. 社内の技術共有がとても活発

今回のFrontend Beer Bashでも3つのフレームワークが登場しましたが、ビズリーチでは様々な技術を採用しています。現在複数のサービスを運営しているビズリーチとしては、各事業におけるノウハウの蓄積が会社としての大きな財産になります。今回の事例にもありますが、新規事業においてはそれぞれの技術における有識者にヒアリングをした上で最適な技術を選ぶことができます。どれくらいの開発メンバーなのか、ゴールは何なのか、気をつけなければ行けない点はなにか、などの情報を知った上で開発をスタートさせることができれば、大きなつまづきは確実に減らすことができるはずです。また、開発途中に躓くことがあっても、都度相談することで解決までの時間を大きく短縮することができます。

このように、技術共有が活発な文化や、困ったときに相談しやすい雰囲気がビズリーチの各プロダクトの成長を支えてくれているのだと思います。

次のFrontend Beer Bashは秋頃開催予定!

今回の記事ではビズリーチの開発チームがどのように技術選定を行っていくのか、アーキテクチャを考えていくのか、実際の事例を交えてお伝えさせていただきました。ビジネス課題も積極的に踏み込んでく4名の話を聞いて、本当に頼りになる開発チームだと改めて感じました。

さて、vol.1には多くの方にご参加いただいた「Frontend Beer Bash」ですが、次回vol.2の開催を秋頃に予定しております。
詳細が決まり次第情報を公開させていただきますので、楽しみにお待ち下さい!

ビズリーチではフロントエンドエンジニア・デザイナーを募集しています

www.bizreach.co.jp

ビズリーチではエンジニア・デザイナーが勉強会を実施しています

ぜひ一度お気軽にご参加ください! d-cube.connpass.com

f:id:bizreach:20160823213758j:plain

この記事を書いたメンバー

荒井 利晃 / Toshiaki Arai


電気通信大学大学院を卒業後、2014年に新卒1期生としてビズリーチに入社。エンジニアとしてニクリーチの立ち上げや、キャリアトレックの開発リーダーを経て、現在はエンジニア職・クリエイティブ職の新卒採用に従事。学生時代ライターとしての業務経験を持ち、密かにReach Oneの人気ライター枠を狙っている。

世界最大のScalaイベント「Scala Days@CPH」に行ってきた(後編)

f:id:bizreach:20170706143948j:plain

こんにちは。
HRMOS事業部のScalaエンジニア、岩松です。社内ではZ戦士とも呼ばれています。

ただいま5月30日から6月2日にかけて開催された「Scala Days Copenhagen」の参加レポートをお送りしています。今回の記事も前編に引き続き、特に印象に残ったセッションをお伝えしていきます!

前編の記事はこちらreachone.bizreach.co.jp

Class up your config

f:id:bizreach:20170706144205j:plain

Scalaにおける設定ファイルの取り扱いを楽にするライブラリ「case classy」の紹介です。

サービスを開発するにあたってセンシティブな情報をプログラム上で取り扱いたい(コードには直接書きたくない)、実行環境毎にサービスの挙動を変えたいといった事はよくあります。設定ファイルや環境変数、JVM環境のシステムプロパティを用いる事でこれらが実現できますが、設定ファイルに関してScalaでは特にHOCON書式を読み取るTypesafe Configがよく使われています。

このTypesafe Configがどんな使い方をするのか見てみましょう。まず、以下のような設定ファイルを用意します。

foo {
  bar = 1
  baz = "baz"
}

この設定ファイルを読み込むコードが以下のようになります。

val config = ConfigFactory.load()
object FooConfig {
  val bar = config.getInt("foo.bar")
  val baz = config.getString("foo.baz")
}
println(FooConfig.bar)

一見普通のコードに見えますがScalaらしいコードを書きたい場合、いくつか困った事があります。

  • 指定したパラメータがなかった、間違った設定ファイルを当ててしまったときにRuntimeExceptionになってしまう

  • プリミティブ(相当)型だけでなく、任意の型にもマッピングできるようにしたい 

  • 分かりやすいエラーにしたい

  • 関数型らしい実装がしたい

ここで登場するのがcase classyというライブラリです。case classyでは先程のコードを以下のように扱う事ができます。

case class Foo(bar: Int, baz: String)
implicit val decoder = deriveDecoder[Config, Foo]
ConfigDecoder[Foo].atPath("foo").load() match {
  case Right(foo) => println(s"success! => $foo")
  case Left(e) => println(s"error! => $e")
}

これを実行すると…

success! => Foo(1,baz)

というように、Eitherで包んでくれる上、特に設定をしなくてもケースクラスにマッピングしてくれました!もし設定ファイルに不備があったとしても

error! => AtPath(foo,AtPath(bar,Missing))

このようにEitherのLeftかつパラメータ情報を持ったまま扱う事ができるようになりました。項目がない、型が違うといったエラー情報も細かく出してくれるので、だいぶ扱いやすくなっていますね。Typesafe Configを使った場合に比べてかなりScalaらしい書き方ができるようなりました。

Monad transformers down to earth

f:id:bizreach:20170706145228j:plain

現地では「Monad Transformers down to earth」を「モナドトランスフォーマーが地球に落ちる」というちょっと危ない意味で捉えていましたが、後々確認したところ「down to earth」は「しっかりと、ちゃんと」という意味だったため「モナドトランスフォーマーをちゃんと学ぼう」といった意味のタイトルだったことが分かりました。😅

ScalazやCatsを使っていると「OptionT」や「EitherT」といった「~T」という型に出くわす事がよくありますが、これがどういうものなのか分からずに使っている方、もしくは分からないので使わないという方も多いのではと思います。このセッションではなぜモナドトランスフォーマーが必要になるのか丁寧に説明してくれました。

例えばFuture[Option[Int]]といった型の値を変換したい場合mapを使っていくことになりますが、素直に書くと

val future: Future[Option[Int]] = Future.successful(Option(1))
future.map { option =>
  option.map(_ + 1)
}

と2つのmapが必要となってきます。これだけだとあまり気にならないかもしれませんが、以下のようなケースだと冗長ぶりが伝わるかと思います。

val future1: Future[Option[Int]] = Future.successful(Option(1))
val future2: Future[Option[Int]] = Future.successful(Option(2))
val future3: Future[Option[Int]] = Future.successful(Option(3))
// Optionの値を足し合わせたい
future1.flatMap { option1 =>
  future2.flatMap { option2 =>
    future3.map { option3 =>
      option1.flatMap { num1 =>
        option2.flatMap { num2 =>
          option3.map { num3 =>
            num1 + num2 + num3
          }
        }
      }
    }
  }
}
// こういった書き方もできます
for {
  option1 <- future1
  option2 <- future2
  option3 <- future3
} yield for {
  num1 <- option1
  num2 <- option2
  num3 <- option3
} yield num1 + num2 + num3

ネストが深くなってしまいますし、for式に書き直した所で2重の構造になってしまい、見栄えもあまり良くありません。。。しかし、これから紹介するOptionTを使うことで

for {
  num1 <- OptionT(future1)
  num2 <- OptionT(future2)
  num3 <- OptionT(future3)
} yield num1 + num2 + num3

と書けるようになります。だいぶシンプルになりました!
そして、どうやってOptionTが作られているかというところで「Functor」と「Monad」が登場してきます。😨

trait Functor[F[_]] {
  def map[A, B](fa: F[A])(f: A => B): F[B]
}
trait Monad[F[_]] {
  def pure[A](a: A): F[A]
  def map[A, B](fa: F[A])(f: A => B): F[B]
  def flatMap[A, B](fa: F[A])(f: A => F[B]): F[B]
}

なんだが難しそうに感じますが、それぞれのメソッドはシンプルです。例えば、FutureのFunctorを実装するとこうなります。

new Functor[Future] {
  def map[A, B](fa: Future[A])(f: A => B): Future[B] = fa.map(f)
}

Futureのmapを呼び出すだけなので、そんなに難しいことはありませんね!Monadも同じように作る事ができます。

new Monad[Future] {
  def pure[A](a: A): Future[A] = Future.successful(a)
  def map[A, B](fa: Future[A])(f: A => B): Future[B] = fa.map(f)
  def flatMap[A, B](fa: Future[A])(f: A => Future[B]): Future[B] = fa.flatMap(f)
}

これらを使ってOptionTを作るとこのような形になります。

case class OptionT[F[_], A](run: F[Option[A]]) {
 def map[B](f: A => B)(implicit functor: Functor[F]): OptionT[F, B] = {
   OptionT(functor.map(run) { option =>
     option.map(f)
   })
 }
 def flatMap[B](f: A => OptionT[F, B])(implicit monad: Monad[F]): OptionT[F, B] = {
   OptionT(monad.flatMap(run) {
     case Some(a) => f(a).run
     case None => {
       val none: Option[B] = None
       monad.pure(None)
     }
   })
 }
}

型パラメータのFはListやSeq、Optionでも良いのですが、OptionTに渡ってきたFがmapやflatMapを持っているかどうかは分かりません。OptionTとしてmapやflatMapを実行するときにFunctorやMonadを渡す事で、これを経由してFのmapやflatMapを呼び出すことができるようになります。これにより、最初に書いたような簡単なfor式で記述する事ができるようになりました!

サンプルコードはこちら

手前味噌となりますが、なぜ~Tが登場するのか、必要となるのかについては同じような発表をこちらでもやっていました。HRMOSスタンバイといったビズリーチのScalaプロダクトでもEitherTはよく使われていますが、実際に自分で作ってみることでより理解が進んだなと感じています!

Building a Company on Scala

f:id:bizreach:20170706150525j:plain

Tapadという最近3億6000万ドル(約400億円!)で売却された企業では2010年ごろからScalaを採用していました。こちらのセッションはここまでにご紹介したものとは少し毛色が異なり、TapadなぜScalaを採用していたのか、何が良かったのか、何に気をつけるべきかを紹介しています。

途中「“FP”(Functional Programming) Mastery is not Required to Master Scala (Scalaをマスターするために関数型プログラミングをマスターする必要はない)」という言葉がありましたが、これはその通りだなと感じました。Scalaは関数型プログラミングとして使わないといけないかのような風潮がありますが、そうではありません。「〜できる」=「〜しなければいけない」ではありませんし、Better Javaでも十分Scalaの特性を活かせるという事ですね。(前項で散々モナドの話をしましたが…🙄)

また、Scalaを使う際に気を付けたい事としてJVMの資産を使える事を忘れないようにしようという事です。「It’s fun to implement RFCs in Scala, but is it productive?」(ScalaでRFCを実装するのは楽しいけど、それって本当に生産的?)とありますが、いわゆる車輪の再発明をするなということですね。鉄腕エンジニア部という車輪の再発明を積極的に行っていく部活動をしているので耳が痛いです😇 (勉強目的なので、普段の開発ではもちろん車輪の再発明は避けています!)

まとめ

名だたるScalaエンジニア、企業が集まるカンファレンスなだけに内容についていけるか不安な気持ちもありましたが、ちゃんと内容を追っていけば自分たちのプロダクトでも使われている技術の話であったり、同じような課題感の共有があったりと内容の理解には意外と苦労しませんでした。

今回の経験をしっかりとプロダクトにも活かし、よりScalaを活用していきたいと思います!

ありがとうございました!

ビズリーチではScalaエンジニアを募集しています

hrmos.co

f:id:bizreach:20160823213758j:plain

この記事を書いたメンバー

岩松 竜也 / Tatsuya Iwamatsu


2015年新卒入社のScalaエンジニア。戦略人事クラウド「HRMOS(ハーモス)」のサーバーアプリケーション開発を担当。AtomでScalaを書くようになり早1年半、"目"型推論が得意になってきた。

世界最大のScalaイベント「Scala Days@CPH」に行ってきた(前編)

f:id:bizreach:20170704173318p:plain

こんにちは。スタンバイ事業部のScalaエンジニア、田所です。
社内ではエモジニアと呼ばれています。

Scala Daysというイベントをご存知でしょうか?
Scala Daysは世界最大のScalaカンファレンスで、2017年で7回目の開催になります。Scalaの作者や著名なScala製 OSSの開発者、Twitter社を始めとしたScala採用企業のエンジニアなど、大変豪華な面々が登壇します。今年はシカゴとコペンハーゲンの2箇所でそれぞれ開催されました。

Scala Days Chicago

Scala Days Copenhagen

今回は、5月30日から6月2日にかけて開催された「Scala Days Copenhagen」に同期のエンジニアと2人で参加してきたので、特に印象的だったセッションを、前編・後編に分けてお伝えしようと思います。

What’s different in Dotty?

f:id:bizreach:20170704173340p:plain

Scalaの作者であるMartin Odersky教授によるDottyについてのキーノートです。DottyはScalaの次世代コンパイラであるdotc、REPLのdoti、ドキュメントツールであるdotdなどからなるツール群です。

Dottyでの変更

  • Union, intersectionの導入による型システムの健全化&シンプル化

  • Traitパラメータの導入

  • 新しいEnum構文の導入

  • Implicits Conversionのルール厳格化による複雑さの軽減

全体的に、Dottyでは型システムなどから複雑になっているものを取り除き、よりパワフルで親しみやすい言語になるように、といった印象を受けました。

特にシンプルなEnum構文の追加は好意的に受け止められているようでした。

いままでは一般的に下記のようにsealedとcaseを使って代数的データ型としてEnumを表現していたものが、

sealed trait Color
case object Red extends Color
case object Blue extends Color
case object Green extends Color

Dottyでは下記のようにシンプルに表現できるようになります。

enum Color {
  case Red, Blue, Green
}

Scalastic Principle

Scalaのprincipleは「型と関数とオブジェクトの調和」であり、「Implicitsによる簡潔さとパワーとユーザビリティの共存」であるとのことです。それをさらに引き出すため、Dottyでは本質的でない周辺的なものを削ぎ落とし、コアの部分を磨いていくとのことでした。

このような言語作者の思想は言語そのものだけでなくライブラリやツールの方向性にも大きく影響を与えますし、いわゆるハウツー的なセッションでは語られないような内容でしたので、今回直接聞くことができたのは良い経験でした。

Dottyに興味のある方には、JSFiddle的なScalaのお試し環境であるScastieがおすすめです。Dottyの機能一覧などを見ながらぜひお試しください。

またMacの場合、brewからインストールしてすぐREPLを試すことができます。

$ brew install lampepfl/brew/dotty
$ doti

Tools for Verified Scala

f:id:bizreach:20170704173417p:plain

コード解析ツールであるStainlessの紹介です。

Scalaの型システムはバグを防ぐ上で大変強力な機構ですが、それでも不完全なパターンマッチングや、ゼロ除算、範囲外の配列インデックスへのアクセスなど、型では防ぎきれないバグも存在します。

そこでStainlessは"Predicate types that refine the function type"という考え方のもと、処理が満たすべき事前条件/事後条件をコード中に定義してチェックを行うというアプローチをとります。

verifyで事前条件を、ensuringで事後条件を記述すると、「すべての入力」に対してチェックを行い、制約を満たさない場合はその値をレポートしてくれるようです。

例えば平均値を求める処理のコードは下記のようになります。

import stainless.annotation._
import stainless.lang._
object StainlessTest {
  def mean(x: Int, y: Int): Int = {
    require(x <= y && x >= 0 && y >= 0)
    (x + y) / 2
  } ensuring(m => m >= x && m <= y)
}

上記のコードは一見正しく動作するように見えますが、xやyが大きすぎる場合、Intがオーバーフローするためにensuringの制約が破られてしまうと教えてくれます。

セッションではその他にも二分探索木や並列コレクションを構成するデータ型をリファクタする例が挙げられていました。

8 Akka anti-patterns you’d better be aware of

f:id:bizreach:20170704173443p:plain

やってしまいがちなAkkaのアンチパターンの紹介です。Akkaはメッセージ駆動型アプリケーションを構築するためのミドルウェアであり、ビズリーチでも求人検索エンジンのスタンバイや戦略人事クラウドサービスのHRMOSで大々的に利用しています。

バッドパターンとして挙げられていたのは下記でした。

  1. グローバルでmutableな状態を使うこと

  2. 階層のないActor System

  3. 多すぎるActor Systems

  4. 同期的など適切でないロギング

  5. ハードウェアを意識しないこと

  6. ブロッキング

  7. Akka自身でできることの再発明

  8. JavaのSerializationを使うこと

5の「ハードウェアを意識しないこと」では、fork-join executorにてCPUを使い切れない設定などが例に挙げられていました。

ミドルウェアレベルでどのように抽象化がされていようと、その下のレイヤーについてまったく気にしなくて良いというわけではなく、やはりレイヤーをまたいだ学習は必要であるなあと改めて実感させられる大変教育的なセッションでした。

7の「Akka自身でできることの再発明」では、特に再発明されがちなものとしてat-least-once deliveryback-off supervisionmessage prioritizationが挙がっていました。やはりドキュメントをちゃんと読むのは重要ですね。

ScalaQuest: the Scala adventure

f:id:bizreach:20170704173526p:plain

Scala学習ゲームであるScalaQuestのセッションです。

各種コレクションメソッドの問題では、並んだ石をfilterメソッドでフィルタリングしたり、mapで色を塗り替えたりなど、学び方を相当工夫されているようです。

作者である@andanthorさんは高校生の時から教育に携わり、自身もゲームで英語を学んだ経験からこのようなScala学習ゲームを開発するに至ったとのことです。

Scalaはとっつきづらいと言われがちな言語なので、このようにカジュアルに学べるゲームなど学習の選択肢が増えることはとても素晴らしいことだと思います。

ちなみにLightbend社の方にScala初学者向けの教材について尋ねたところ、Scala for Impatientの動画版をオススメしていただきました。言語のエッセンシャルな部分がコンパクトにまとまっているとのことです。

なおビズリーチでもPlay2 + Slick / ScalikeJDBCでのアプリケーション作成を学ぶplay2-hands-onを公開しています。興味があれば是非お試しください。

Event Sourcing and CQRS

f:id:bizreach:20170704173549p:plain

「全ての状態は一連のドメインイベントの結果である」という話から始まり、

アプリケーションモデル/リレーショナルモデル間のインピーダンスミスマッチ解消やスケールアウト、ヒストリーの保存をどのようにESで行うのか、なぜCQRSが必要になるのかを解説するセッションでした。

ES/CQRSとはどんなものなのか?なぜ必要なのか?を丁寧にお話されていたので、事前知識がなくても理解できるセッションだったのではないかと思います。

ビズリーチでは技術イベントの「D3」など、社員が登壇する機会も多いので、プレゼンの仕方なども大変勉強になりました。

d-cube.connpass.com

後編もどうぞお楽しみに!

ビズリーチではScalaエンジニアを募集しています

hrmos.co

f:id:bizreach:20160823213758j:plain

この記事を書いたメンバー

田所 駿佑 / Shunsuke Tadokoro


2015年新卒入社のScalaエンジニア。求人検索エンジン「スタンバイ」のWebクローラー開発を担当。ScalaとClojureとEmacsと絵文字が好き。

Salesforce 会長 兼 CEO マーク・ベニオフ氏に、事業戦略メンバーの取り組みを紹介いただきました!@Salesforce Trailhead Live Tokyo

こんにちは!広報の午頭(ごとう)です。

昨日、Salesforceさん主催の大規模イベントSalesforce Trailhead Live Tokyo 2017が、東京ミッドタウン ホール、ザ・リッツカールトン東京で開催されました。

こちらは、Salesforceさんの顧客、パートナー、社員の皆様が集まり、最新テクノロジー、クラウドサービス、事例を学ぶイベントなのですが、なんとその基調講演で・・・
会長 兼 CEOのマーク・ベニオフ氏が、ビズリーチ事業戦略部 滝田の取り組みについてプレゼンしてくださいました!!

f:id:bizreach:20170705142117j:plain
(プレゼン中の様子)

・エンジニア未経験だった滝田が、Salesforceの無料学習サービスTrailheadを活用して開発にチャレンジし、業務改革をシステムで推進していった過程
・セールスやディレクションという領域から、業務改善をリードしていくポジションへのキャリアチェンジ
という点にフォーカスして、お話しいただきました。

イベントの開催に合わせて、こちらのブログでは滝田のインタビューを掲載いただいています。
ご興味のある方は、ぜひブログで詳細もチェックしてみてください! www.salesforce.com

社員の新しいチャレンジを称賛・応援するビズリーチのカルチャーと、自ら学び続けキャリアを切り拓いていく仲間をこのような形で取り上げていただけて、心から嬉しく思います。
ありがとうございました!

【キャリア採用情報】経営企画・事業企画ポジション

ビズリーチでは現在、経営企画・事業企画ポジションで採用活動を行っています。
経営陣・各事業オーナーとともに、急成長する事業・組織の課題解決に向けて、戦略立案から実行までを担っていただける方を募集します。 hrmos.co

f:id:bizreach:20160823213758j:plain

この記事を書いたメンバー

午頭 優佳 / Yuka Goto


2015年6月に株式会社ビズリーチに入社。「ビズリーチ」の採用法人様向けコンサルタントを経て、2016年8月から広報。現在は、採用広報とリクルートメントマーケティング室(マーケティングの手法で自社の採用活動を最適化するチーム)の立ち上げを担当。

新卒全員が対象の「経営陣メンター制度」とは?ビズリーチが育成にかける想い

こんにちは。人事企画部の清家(せいけ)です。
ビズリーチを日本で一番働きがいのある会社にすべく、仲間とともに日夜奔走しています。

今回私からは、ビズリーチの新卒社員を対象にした「経営陣メンター制度」についてご紹介します。

メンターとの対話で成長を促す

「メンター」は、古代ギリシャの叙事詩『オデュッセイア』に登場する人物・メントールが語源と言われており、「師・助言者」を指します。
ビズリーチにおける「経営陣メンター制度」も、その名のとおり、経営陣が新卒社員の助言者となる制度です。新卒社員が抱えている不安や悩み、ぶつかっている課題に対して、経営陣が一緒に考え、対話を通して気づきを促す。これを定期的に繰り返すことで、新卒社員の成長を支援します。

もちろん現場では、日々直属の上長・先輩がしっかり業務に必要なスキルの指導をしていきます。そのため、「視座を上げる」「課題への見方を変える」など、主にマインドやスタンス面の支援をするのが経営陣メンターの大きな役割となります。

実際にやっていること

それでは制度の具体的な紹介に移りましょう。
まず、採用に関わったメンバーを中心に、「この新卒社員には誰がメンターになるのがふさわしいか」を議論し、経営陣17名から割り当てを決定します。それぞれの性格や志向・強みと弱みを客観的に理解できるのは、新卒社員と入社前から長期に渡って伴走した採用チームだからこそ。それぞれの新卒社員に「今最も必要な要素」を伸ばしてくれるメンターを選出します。

その後は、経営陣が月に1回新卒社員と30分間の1on1(マンツーマンの面談)を行っていきます。
そこで話す内容はすべて新卒社員に決定権があります。
普段の業務で困っていることを相談するもよし、自分の夢をどう実現したいかをアピールするもよし。
新卒社員の成長のための場として活用してもらえれば、テーマはなんでも構いません。

f:id:bizreach:20170627195941p:plain
1on1の様子

新卒社員の声

実際にどう感じているのか、新卒社員に聞いてみると、こんな声が上がってきました。

メンターとの最初の1on1では、あまり話したことがなかったこともあり、「優等生」な対応をしていました(笑)。でも、私が業務で悩みを抱えていたとき、表情や様子からそれを察して話しかけてくれたことがあり、それ以降は「この人には全て見透かされているな」と感じて正直な気持ちを話しています。直属の上長とも週次で1on1をしてもらっていますが、そこでは主に目の前の業務に関することを話しています。経営陣とは、自己投資の方法や基礎スキルの底上げなどをテーマにして、自分の目的に応じて使い分けるようにしています!(2017年度新卒入社・女性)

最初に経営陣メンター制度について聞いたときは、「経営陣の方から月に一度、キャリアの棚卸しをして頂ける貴重な機会」だと思い、純粋に嬉しかったですね。メンターとは、自分のキャリア観や、人生においてどういったことを大事にしたいか、ということまで率直に話しています。自分より圧倒的に経験が豊富で視座の高い経営陣と話すことで、自分の状況を客観的に振り返る機会にもなっています。(2017年度新卒入社・男性)

また、僭越ながら私もこの制度でメンターを担当させていただいていますが、新卒社員からたくさんのことを学ばせていただいています。将来のビズリーチを担う人財がどういった想いで何を考えながら働いているのか?彼らの熱い熱量を肌身で感じることも経営に還元するにあたり重要なことと考えています。

育成の本気度は、トップの姿勢で示す

事業の成長にともない社員数が急速に増えるなかでも、「社員を全力で育てる」というビズリーチの想いに変わりはありません。

また、ビズリーチは新卒入社から3年間を「社会人としての土台づくりにあたる最も大事な時期」と考えています。特にその間は、経営陣を始め、上長や人事が一丸となり、“本気”で育成にコミットします。

毎年入社する新卒社員に、社長の南が約束することは「成長できる機会と環境を提供する」こと。それをどう活用するかはそれぞれの新卒社員にかかっていますが、会社として機会と環境の提供を惜しんではいけない。そうした共通の意識を経営陣全員が持っているからこそ、全力で新卒社員と向き合うことができるのだと思います。

これからもビズリーチの全てのメンバーに成長を実感してもらえる会社にするため、経営陣が先頭に立ち育成に本気で向き合い続けたいと思います。

f:id:bizreach:20160823213758j:plain

この記事を書いたメンバー

清家 良太/ Ryota Seike


兵庫県神戸市出身。人事企画部の部長として、日々「STRONG HR」を体現すべく奔走中。趣味は登山とテニスとフィギュアスケート。土鍋で炊いた白米が大好きなので、糖質制限はしない主義。