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

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

新規プロダクト開発におけるPhaseごとの技術選定あれこれ

f:id:APPLE4869:20191225135543p:plain

はじめに

このブログはクラウドワークスのアドベントカレンダーの最終日の記事です。(今年もクリスマスイブをアドベントカレンダーで使ってしまった・・・。)

クラウドワークスの副社長をやってます @shuzonariata です。

現在自分はエンジニアリングDivの管掌役員やその他事業管掌もしているのですが、新規事業の開発の責任者も行っています。新規事業では、クラウドワーカーの新しいマッチング体験を実現するプラットフォームサービスを作っています。

そこで今回のアドベントカレンダーでは、そんな新規プロダクト作りの裏側で、どんな技術選定をしてきたか、なぜその考えに至ったか、どんな結果になったか、そんな経緯をまとめてみることにしました。(ちなみに新規サービスは2020年の年始には公に発表できると思います。乞うご期待)

※なおこのブログは新規事業のチームメンバーで、プロダクトマネージャーでありUXデザイナーの@takuto0516との共著です。

続きを読む

チームにプロダクトオーナーが加わり変化したこと

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

フロントエンドグループ・トリュフチームの @eighty8 です。

私たちのチームでは、crowdworks.jp におけるデザインガイドラインの作成と、UIコンポーネントカタログの実装をメインで行なっており、既存のUIを大きく崩さずレガシーなデザインやHTML構造を刷新していくことを目指しています!(いずれはデザインシステムに発展させていきたい!

チーム発足から一年弱が経過しましたが、このたび待望だったプロダクトオーナー(以降PO)も加わり、プロジェクトを推し進める上で大きな原動力となっています!

クラウドワークスにおけるPOの役割

【POのミッション】

・プロダクトや担当機能のROI最大化
・ミッション遂行に向けたチーム管理
・施策の優先順位の決定/意思決定

【業務内容】

・開発テーマ設定/KPI設定
・開発のプロセスに責任を持ち、機能企画からリリース・運用を推進
・実行/実装にむけた工数およびスケジュール管理
・KPIモニタリング、データ分析
・ユーザーインタビュー等による定性調査/分析
・スクラムチームの運営/改善

この記事では、PO不在のチーム発足当初からPOが加わるまでの間にあった問題と、加わった後でどのようにチームが変化したかを書いていきたいと思います。

続きを読む

とあるチームのチームビルディング話

この記事はクラウドワークス Advent Calendar 2019 の 17 日目の記事です。 昨日はアクセシビリティ向上隊長 みーたさんによる「なんとなくで書かないで!HTML5 を書く時に気にしてみたいタグごとのお約束」でした。自分は懺悔室送りとなりましたが、皆様いかがでしたでしょうか。

続きを読む

そういえば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話「脱出」

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

© 2016 CrowdWorks, Inc., All rights reserved.