クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

そういえばRails5へ移行しましたのご報告

Railsをアップグレードするということ

じゅんてつです。 Rails4更新時にはご報告の記事が書かれていたのにも関わらず、Rails5更新は記事を挙げておりませんでした。今更ながら記事をしたためてみました。ひとえに多忙だったり、Rails4更新のように世間的に宣言して更新をしていなかったからかと思います。

f:id:juntetsu-tei:20191213185333p:plain

さて、今年はRails6がリリースされたように大きな動きのあったRails界隈ですがいかがお過ごしでしょうか。

Rails4更新のときのように特に大きな告知はしておりませんが、CrowdWorksでは、Rails4.2からRails5.2へのアップグレードに取り組んでいました。Rails6がでたところ今さら感も漂いつつあるかもしれませんが、CrowdWorksはサービス全体がRails5.2で稼働していますことをここにご報告いたします🎉

根幹となるフレームワークを古いまま使い続けることは、洗練された記法が使えなかったり、高速化最適化が進んだモジュールが使えなかったり、周辺gemの対応についていけずに置いていかれるリスクなどが負債となって積み上がっていきます。また、セキュリティの問題が修正されなくなるリスクもあるため長い目でみてユーザーに不利益になり、生きたサービスを開発し続けるためにはフレームワークのアップグレードが不可欠と感じています。

CrowdWorksがやったこと

稼働中のサービスのRailsをアップグレードするということは、単に bundle update するだけでは終わりません。ましてやCrowdWorksのような30万行を超えるサービスの中心となるフレームワークを更新していくことにはいくつもの課題があります。10万行超のRails4更新時は「車を走らせながらエンジンを取り替えるようなもの」と課題の大きさを比喩していたようですが、今回はさらに規模が大きくなっており「旅客機を飛ばしながらエンジンを空中で取り替える〜」と比喩してもいいのではないかと思います。

稼働したサービスを止めずにRailsのアップグレードをするにあたって、Rails4とRails5が並列に存在できる環境を構築しました。これによってHTTPリクエストを振り分け、カナリアリリースの体裁をとることが可能になり、問題が発生した際は即座にRails4へ切り戻しができたり、ユーザー影響を最小限に留めることができ安全に新しいバージョンへ移行することができるようになりました。安全なリリース方法を模索した結果、カナリアリリースを採用しましたが、もちろんリリースに至るまでに多大なる努力を行っています。自動テストの充実や、手動テストでの網羅的な確認、シナリオテストでのパターン網羅、ミドルウェアやインフラ構成に着眼した個別の確認など、思いつくあらゆる軸で対応を行いました。

このような取り組みのお陰で大きな障害を出すこともなくユーザーへの影響も最小で移行しています。 Rails5更新に関する記事は、メインミッションとしたメンバーが少数という事情や、技術的な話は世の中の多くの会社の方が記事にしていただいてるところもありますので、特筆する内容が思い浮かびましたら記事にしたためたいと思います。

人事の思い出でも語ろうか。

この記事はクラウドワークスアドベントカレンダー13日目の記事です。

はじめまして、木村です。

まずは、自己紹介をしたいと思います。ハワイオワフ島出身、川崎在住。やる気はあるが意識は低い系男子。Over 40。2018年3月からクラウドワークスにてプロダクトGMとかマーケティングGMとかしながら生息しておりますが出自はエンジニアです。もっと言えばゲームプログラマーです。セガサターンN64プレイステーションプレイステーション2でゲーム作ってました。その後は、組み込み系エンジニア、新規事業開発、サービス企画、ゲーム企画、ゲームディレター、プロデューサーやれる物は何でもやった感じです。THE なんでも屋

趣味は、漫画を読む事と各種協会のサイトをみながら、すあま(寿甘、素甘)を食べる事です。すあま(寿甘、素甘)がわからない人は、ググってください。人生の可能性が広がります。あとは、スペインにちょくちょく行って、お酒を飲みながらご飯を食べてます。理由もなく30回以上は行ってるので呪いですね。Hablo espanol un poco.

f:id:ac_kimura:20191205193644j:plain
すあま(not かまぼこ)

嫌いは、おから、トマト、納豆、煮たセロリです。おからは前世で親を殺されたんじゃないくらい嫌いです。トマトは、調味料という認識なのでトマトをそのまま食べることはしませんが、モスバーガーでバーガーに挟まっていたり、出汁につかったり、トマトケチャップ等は好きです。むしろ、Love!

エンジニアっぽい紹介すると得意はC言語perlです。はい、老害感ありますね。でも、Cはシンプルで好きなんです。Love!基本的には型がある言語が好きです。プログラム自体は小学生の頃にBASICを始めてからなので、四半世紀上やってます。むしろ、C言語書き始めてから四半世紀たってます。それは、歳もとるわ。


1話「木村、人事に立つ!!」

そんな、木村が今年の5月末から人事をはじめました。「冷やし中華はじめました」ばりに「人事はじめました」ってな具合です。肩書は人事部長!といっても、人事とはヒューマンサポートとか言うのが嫌でまず最初にやったのは名前を変えることです。其の名も「ヒューマンサクセス部」。人の成功にコミットした組織です。かっこいい。なぜこの経歴で人事を引き受けたかと言う話を少ししたいと思います。社会人22年以上やってる中で、そんなに今までやってきた事とズレはないかなと思ったからです。そもそも、人事は働く人の為に行動するわけで、エンジニアが働きやすい、デザイナーが働きやすい、営業が働きやすい環境を作るには、やっぱり事業を経験していた人がやるべきかなというのが僕の考えです。しかし、人事って始めてみたらサービス開発と同じ楽しみがありますね。いろいろな制限(法律関係)があって、其の中でカスタマー(メンバー)の幸せを最大限叶えるという点においては、完全一致!割と楽しくやっております。さて、うちの人事部(あえてわかり易い表現をします)は、独りよがりにならように2つの工夫をしております。

  • 人事にBoardという組織がある

会社で言えば相談役のような存在です。メンバーは、エンジニア、デザイナー、営業、カスタマーサクセスのスペシャリストです。私の私見による判断には限界があるので、このメンバーに制度であったり、方針だったりを相談してます。こうやって、事業を推進してるメンバーとの差分を減らす様にします。全ての最適解は難しいですが、ある程度の最適解はだせるんじゃないかと仮説をたててます。

  • 人事にフレンズがいる

いくら、Boardがいても人事単体で考えていくのは難しいです。人は万能ではないのです。方向性を誤って頑張ってしまうと、誰も幸せにならい人事制度や仕組みが出来上がってしまいます。ゲーム企画の世界で言えば「俺が作った最強(に面白い)ゲーム」が起き得るわけです。そこで、人事部に協力いただけるメンバーをフレンズと呼ばせていただいて、その方々に「得意な所」で色々アイディアをもらったりしてます。結局、系が閉じた世界で考えると袋小路に入り込んでおかしな事になるのは新規事業だろうが、サービス企画だろうが同じですね。

f:id:ac_kimura:20191211151628p:plain

ちなみに、ヒューマンサクセス部のメンバーは人事一筋って訳ではなく、他のフィールドで活躍していた事がある人で構成されてます。重んじるは多用性。この多用性は本当に面白いので今度時間を取って書きたいと思います。


25話「フルフレフルリモの激戦」

今年は、去年のAdvent calendarで、話題としては上がっていた(*1)フルフレックス・フルリモートが全社で適応となりました。プロダクトを開発する人達だけではなく営業からコーポレート、我々ヒューマンサクセスまでの全社対応となりました。なもんで、今回はそのフレックスフルリモートについてちょっとだけ深堀りしたいと思います。どうでもいいですが、フルフレックス・フルリモートって言いにくいですよね。

「そもそも、フルフレックス・フルリモートとは?」という簡単な所から入ります。

そもそも、フレックスは変形労働時間制の一種であり、「始業及び終業の時刻をそのメンバーの決定に委ねる事」を意味します。一般的な会社では、フレックス制度は以下の2点で構成されているかと思います。

フレキシブルタイムは「労働時間を自分の意志決定によって、決められる時間」を指します。簡単に言えば、「今日は8時に出社するよ」「今日は16時に帰るよ」てな感じです。 コアタイムは「必ず労働しなければならない時間帯」を指します。多くの会社で12〜16時とか、昔のクラウドワークスで言えば10〜16時という部分にあたります。実際、多くの会社で大なり小なりコアタイムがあり、コアタイムを会議の時間なんかに、暗黙の了解として利用してる事が多いのだと思います。このコアタイムが存在するので、コアタイム無しのフレックスをフルフレックス等と呼ぶ事になるわけです。若干、レトロニム感ありますね。

次に、フルリモート。リモートは、昔はテレワーク、在宅勤務等と呼んでいました(今でも政府の資料はテレワークの呼称を使うことが多いです)。簡単に言えば、就業場所の決定をメンバーに委ねる事です。就業場所?と思うかもしれませんが、就業場所って概念は割と重要で、どれくらい重要かと言うと採用するときは労働条件を明示する必要があります(労働基準法第15条第1項、労働基準法施⾏規則第5条)。其の際にも必ず就業場所を記載しないといけないくらい大切な物だったりします。制限のついたリモートが何かは解りませんが、クラウドワークスでは週3回までと言うルールがありました。他で聞いた話だと、「自宅のみ」なんていう制限も聞きます。これを撤廃したものが、フルリモートと呼んでます。

結局、フルフレックスはフレキシブルな時間、フルリモートはフレキシブルな場所を意味することになり、合わせると「フレキシブルな働き方」の提供となります。

さて、フルフレックス・フルリモートは福利厚生ですか?

答えはNoです。クラウドワークスでは、福利厚生とは捉えておらず、メンバーに働く時間・働く場所を委ねる事によって効率的に業務する手段を提供してるだけにすぎません。簡単に言えば、「今日はリモートするよ」「今日は出社するよ」は同じ手段であり同じ基準で選択ができるようになるわけです。じゃぁ、具体的に何が効率的なのかという問いに対しては、ライフステージによって、働き方は大きく変わってきます。たとえば、子育てをしていれば、「子供を保育園につれていく」イベントがあり、状態によっては「保育園が受け入れしてくれない」イベントは日常で割と発生して、多くのパパ・ママは其のたびに家に帰って云々と頭を悩めるわけです。しかし、フレキシブルな働き方を提供すれば、「家で仕事をする」選択が簡単に出来て、余計な思考をしなくてすむわけです。今は子育てを例に上げましたが、介護であっても同様ですし、自分が病気になって働き方に制限が生まれる事だってあるかもしれませんし、そこを柔軟に受け止めることが出来るのがこの制度の良いところです。

では、この制度を運用していく上で大切な事は何でしょうか? それは、他人を思いやる事です。クラウドワークスでは、フルフレックス・フルリモート活用に関してはチームでルールを決めてもらっています。そのルールを、適宜見直してもらってより良い制度の利用をしてもらい、それをフィードバックする事で全社でナレッジがたまり、より良いフルフレックス・フルリモートになると考えております。この活動を続ければ、フルフレックス・フルリモートだけではなく、より良い働きの方の提供ができるのではないかと考えています。

ちなみに、他人を思いやった結果、「今日は、子供の迎えあるけど帰りにくいなぁ」「あの人、子供理由に早く帰ってるとか思われるのやだなぁ」なんて悩みをよその会社ではよく聞きますが、ここがクラウドワークスのいいところ!そんな雰囲気は一切ありません。正直この会社に入って一番驚いた所がそこです。取締役からメンバーに至る前で、家庭の事情で帰る人何か言う人もいないですし、子育てしてるパパ・ママ共に帰ることを気にする人もいません。あまりにも、普通すぎてそれがこの会社のいい所だと思わない人もいるくらいです。

f:id:ac_kimura:20191212100504p:plain
リモートの様子(ヒューマンサクセス部)

今後のライフステージの変化を色々考えてる方はクラウドワークスを訪ねてきてください(笑)

参考に、このフルフレックス・フルリモート導入した結果、ヒューマンサクセス部では優秀な人材が働いていてくれてます。彼女のnoteがあるので読んでみてください。色々参考になるかもしれません。少し前までは、人事でリモート・フレックスとかありえなくない?と思われていた事を普通に出来てしまうのが弊社のすごいところではないでしょうか。

note.com


35話「ロウム攻略戦」

最後に、フルフレックス・フルリモートで苦労した点を少し書きたいと思います。というのも、多くの時間を費やしたのは制度の準備もあるのですが、現行の法律との戦いです。世の中には労働三法などといわれてるように、労働に関わる法律は数多くあります。また、給与計算を含めたペイロールの仕組みもこの法律の上にのかって存在しております。これの何が億劫かと言うとそもそも、性悪説に基づいて作られてる。これは、世の中を見渡せばそうせざるえない状況も見えてきます。が故に、本当はここも自由にしたいんだけど、出来ないという所がまだまだ多くあります。次に、基本的には「会社に出社して、一日決まった時間働く」事を前提に作られてる法律・仕組みが数多くあることです。このあたりは、今後変わっていくかもしれませんが、今はまだまだ未整備な領域だと思っております。そのうち、うちのノウハウを近いうちに公開して、どんな会社でもフレキシブルな働き方・ライフステージの対応ができるようなればいいなと考えております。目指せ、オープンソースならぬ、オープン規定。


43話「脱出」

書きたいことは沢山あるのですが、今後順を追って公開していきたいと思っております。新しく作った制度を自分たちで独り占めすることなく、多く世間に公開することで世の中でいろいろな働き方が許容されて、在野に眠ってる潜在する働き手が有効活用される時がくれば、この世はもっと良くなると考えております。あ、あと人事周りの友達が少ないので、だれか情報交換してもいいよなどという人がいたら、ぜひぜひお声がけください。世界を変えたいけど、まだまだ山は険しいです。

現場のエンジニアがエンジニア採用をマネージャーから引き剥がした話

この記事はCrowdWorks Advent Calendar 2019の6日目の記事です。

SREチームの@sawadashotaです。 今年、2019年1月からSREでの活動をする傍ら、兼任という形でエンジニア採用にも携わっています。

クラウドワークスの中途採用選考フローと各ステップでの担当は大まかにいうとこんな感じになっていました。

  1. カジュアル面談 (マネージャー)
  2. 書類選考 (マネージャー)
  3. 一次面接 (現場のエンジニア)
  4. 最終面接 (役員)
  5. 内定

当然ながら、入り口のほうほど、応募者は多くなり、多くの時間を必要とします。 加えて、当時は20人超のエンジニア組織に対してマネージャー1人だったので、相当ハードだったと想像しています。(現在は30人まで増えました)

そんな状況だったこともあって、当時マネージャーが受け持っていたタスクをバラして、現場に卸していく動きがありました。エンジニア採用はそのうちのひとつでした。

採用活動といえば、多くの面談・面接は定時を過ぎた時間に行われるので、わざわざやるのは損というやったもん負け感がある活動ですが、クラウドワークスではフルフレックス制度があるので、その月で営業日数 * 8時間働けばよく、夜遅くなってしまっても、他の日に帳尻を合わせることができるので手を挙げやすかった、というのがあります。

そんなこんなで、各ステップでの担当は 現場のエンジニア が担当しています。

  1. カジュアル面談 ( 現場のエンジニア )
  2. 書類選考 ( 現場のエンジニア )
  3. 一次面接 (現場のエンジニア)
  4. 最終面接 ( マネージャー ・役員)
  5. 内定

現場のエンジニアがエンジニア採用を回すようになるまで

会社や事業を説明できるようになろう

当たり前じゃん!って言われそうですが、これが意外とできないんです。 身近な人に今自分がやっていることは説明できると思うんですが、会社や事業の今までとこれからを初めて会った人に説明するは思っていた以上に難しいものでした。 自社のIRをよく読んだり、マネージャーと一緒に面談に出る中で言い回しを学んでいきました。

自分のリソース配分を考えよう

クラウドワークスでは、エンジニア採用専任はいません。 人事はいますが、全社を見てますし、採用だけをやっているわけではありません。 故に、今まで選考業務はやってきたものの、エンジニア採用にフォーカスして持続性のある仕組みを作ることには、あまり着手できていませんでした。

かくいう私も本分はSREで、エンジニア採用にかけられるリソースはせいぜい10 ~ 20%(週半日 ~ 1日)と少ないので、仕組み化して持続性のある状態にしていくことを意識しています。 例えば、スカウトを打つにしても、最初は自分で手を動かしますが、最後には必ずスカウトを送る基準や、文章の作り方など、自分以外の人もできる状態にするようにしています。

最新情報を常にPULLし続けよう

マネージャーが採用をやっていたときには問題にならなかった新しい問題が発生します。

採用を取り巻く情報はとても流動的です。 退職者が出たり、予算が変わったり、他の部署で採用が決まるとエンジニアの採用枠が変わることもあります。 採用枠数が縮小すると、「採用基準はクリアしていたけど、この少ない枠は使えない...」 というとても悲しい決断をしないといけなかったり、逆に採用枠が拡大したのを知らずに、採用枠が少ないときの厳しい基準でお見送りにしてしまうことも起こりえます。 エンジニア採用やっているとはいえ一般社員なので、この手のセンシティブな情報は口をあけて待っていても降ってくるものではなく、自分から取りにいかないといけません。

情報統制の観点もあり、難しいところですが、持続的な解決策は今後、模索していきたいです。

仲間を増やそう

この半年で一緒に持続的なしくみを考えてくれる仲間が7人に増えました! ここまで増えると、もうマネージャーに属人化した状態から脱却できたと言えるんじゃないかと思っています。

採用のしくみがまだまだ整っていない中でより良くしていくためには、いろいろな人が必要だと考えています。 想いを持って採用を良くしていこうとしてくれてるエモ人材、組織的な制約と戦ってるくれるソルジャー人材など。 また、この7人の中にはエンジニアだけでなく、人事の方も含まれており、体制が整ってきた感を感じています。

エンジニアとしてエンジニア採用に携わるメリット

個人としてエンジニア採用に携わるメリットも書いていきたいと思います。

自分たちがやっていることの価値を説明できるようになる

面談・面接をやる上で重要なことは、 自分たちがやっていることの価値を伝えること だと思っています。 もっと踏み込んで言うと、表面的なこと(技術スタックや福利厚生、条件等)だけじゃなくて、クラウドワークスの事業やエンジニアがどんな挑戦をしたり、現実と折り合いをつけているのか、できる限り面談・面接でお伝えするよう努めています。

実際、どのくらい伝えられているか... は正直わかりませんが、普段、現場でコードを書いてるだけでは、見ず知らずの人に価値を伝える機会はなかなかないので、採用活動を通して磨いていきたい能力です。

たくさんのキャリアに出会える

多くのエンジニアとお会いする中で、今までどのようなキャリアを歩んできたか、これからどういうキャリアを歩もうとしているのか聞き、自分のキャリアの参考にすることができます。

自分の給与に対する不満がなくなる(かもしれない)

日々、応募者に対して「この希望条件なら、これくらいのレベルを求めたい」と思いながら活動しているわけですが、省みて、そのモノサシを自分に当ててみると、採用活動を始める前、内心、なんなとなく「自分はもっと評価されてもいいかもしれない」と思っていても、実は正当な評価だったということに気づきます。

おわりに

まだまだ採用にまつわる制度やフローが整備されてないところではありますが、普段関わらない部署と連携しながら整えていくのも世界が広がる感じで楽しかったりします。

また、今やっている活動は 「自分たちの仲間は自分たちで探す」 というのは採用のあるべき姿であるとも考えており、時間的な制約と戦いながら、仕組みを作っていきたいと考えています。

実録:お母さんが挑むチーム開発、モブプロの理想と現実の2ヶ月

この記事は クラウドワークスアドベントカレンダー2019 5日目の記事です。

はじめに

みなさまこんにちは、たかのと申します。 この秋よりご縁をいただいて、クラウドワークスでお仕事をしております。

さて、わたしはそれなりの年齢のお母さんエンジニア。 新しい世界に飛び込んで行くことに、今回も例に漏れず非常に不安をいだいておりました。

「まずは生き延びる」

そんなモットーで通い始め、いつの間にか2ヶ月。 日々若い方々のパワーに圧倒されている中で、気がつけば楽しく過ごしている自分がおりました。

今回は、一番自分らしい方法で、この2ヶ月をお伝えしたいと思います。 以下、4コマにてお届けします。 検索性に若干難点がございますが、そこはご容赦を。

  • はじめに
  • 1. 母。生きのこるを目ざす。
  • 2. チームビルディングに感動する
  • 3. いよいよ開発!モブプロを初体験する
  • 4. リリースまでを体験したよ!
  • 5. くやしいのでがんばりたい!
  • 6. まとめ
続きを読む

システムと金の関係を改めて考えてみる

この記事はクラウドワークスアドベントカレンダー1日目の記事です。

クラウドワークスでマネジメントとかプロダクト戦略とか色々やっている@ysk_118です。
11月は実は登壇3連戦で、ちょうど昨日のデブスト2019が最後でした。というわけでちょっとぎりぎりになってしまいましたが、クラウドワークスアドベントカレンダー今年もやっていきます!

なぜこの記事を書こうと思ったか

f:id:yo-iida:20191201224857p:plain

最近は経営の議論なども色々理解が進んできたので金の話も考えるようになってきたのですが、そこで「うわ、私の理解浅すぎ...?」と思ったのが、

このシステムは持続的に金を生み出していけるのだろうか?

ということです。

というのも、先日の通期決算でも出ているようにサービスの売上は成長していっていますが、以前の記事で書いている通りコードの総量や変更量は鈍化傾向にあり、複雑化したシステムの中に見えていない技術的な負債・リスクがどれくらいあるのか?それによってこの先売上の成長が鈍化するリスクがどれくらいあるのかがあまり科学できていない、ということに気づいたためです。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.