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

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

ゴールが見えなくなったプロジェクトに立ち向うときに必要なたった1つのこと

f:id:k-waragai:20191112163201p:plain

目次

  • 目次
  • はじめに
  • なぜ本人確認を自動化することになったのか
  • 施策が始まって中盤までのお話
  • そしてゴールの見えないタスク消化の連続
  • イチから...いいえゼロから Re:Start !!
  • ついに本人確認を人力から自動化へ
  • 気づきや学び
  • 最後に

はじめに

今更ながら食べるラー油にハマりだした、きびだんご*1チームの @k-waragai です。

チャーハンに混ぜて食べるのが一番ハマっています(美味しいのでやってみてね)

今回は人力で行ってきた本人確認を自動化するまでの軌跡と、そこでの気づきや学びを振り返りながらまとめていこうと思います。

*1:きびだんごの由来は、名前ガチャで決まりました。

続きを読む

リモート主体のチームで成果以上にコミュニケーションを重視したら生産性が向上した話

f:id:pontatanpo:20191030114518p:plain

みなさん、こんにちは。エンジニアリングdivのしもはたです。 最近、機動戦士ガンダムを一話から見始めました。戦場で戦って成長していくアムロの姿を見ると自分もうかうかしてられないなと思いますね。早くニュータイプ系エンジニアになれるように日々成長ですね。

さて、話は変わりますが入社時から関わっていたチームから別のチームに異動することになりました。移動前のチームでは、自分以外のメンバーがフレックス・リモートの制度をフルに活用し、私が出社してもチームメンバーが職場にいない状況は珍しくありませんでした。 今回はリモートワーク初心者の私がリモートワーク中心の開発チームで直面した問題と解決策をお伝えしようと思います。リモートワークを取り入れてみたがうまく運用が回らないよ、とお困りの方の参考になれば幸いです。

【目次】

  • チームの体制とフルリモートの実態
  • リモートワークのメリット
  • 発生した問題と解決策
    • 問題①:メンバーが何やってんのかよく分からない問題
    • 解決策①:タスクを一箇所に管理して見える化の促進
    • 問題②:心が疎遠になっていく問題
    • 解決策②:朝会に雑談の時間を設定
    • 問題③:相談しづらい問題
    • 解決策③:通話用にチャットアプリの導入
  • まとめ
続きを読む

VueFes2019にリフレッシュメントスポンサーとして参加します!

こんにちは。フロントエンドチームのUXエンジニア みーた です。

新作ノベルティ作りました

この度クラウドワークスは、10月12日(土)に開催される VueFes2019 にリフレッシュメントスポンサーとして協賛させていただきます!!
初のVueFesへの協賛で個人的にわくわくしすぎちゃって、調子に乗って新作のノベルティを3つも企画・作成しちゃいました!

じゃーーーーん🎉 VueFesで配布する2USBポートACアダプタとBeAgileコースター、Vue.jsコードステッカーの三点の写真

いやーーー自画自賛してしまうほどかわいい。

ステッカーとコースターのデザインは弊社のデザイナー YUCCA さんにお願いしました♡
イラストがめちゃよき...!! かわいい。(何度でも言う)
BeAgileコースターに関しては今後のイベントでも配布予定です。
Vue.jsコードステッカーもシンプルながらオシャレですごく気に入ってます。

そして今回の目玉👀💡
VueFesJapanのロゴをお借りして私がデザインして作った
「VueFesJapan x CrowdWorks ロゴコラボ 2USBポートACアダプタ」限定200個となります!
まだまだ現役なUSB充電が出来るタイプです。

2USBポートACアダプタを横から見てUSB差込口が見える写真
フリスクくらいのサイズ感です

ちょっとフロントエンドの話

ところで「え?クラウドワークスってVue.js使ってたの?」と感じている方も多いかと思いますが、8月に新機能としてリリースされた「検索条件保存」など一部の開発で導入され始めました。

blog.crowdworks.jp

crowdworks.jpの大部分がCoffeeScriptで古き良きjQueryを使っているのですが、正直いろいろプラグインを使ってたりするのですぐにはやめられない状態です。
ただ、そんな中でも今後もサービス開発をやっていくにあたってモダンな開発環境の構築をしていきたいという気持ちで新しいフレームワークを導入していってます。

クラウドワークスのフロントエンド事情はこちらから御覧ください。 engineer.crowdworks.jp

Vue.jsを起用した背景としては

  • DOMの変更等をフレームワークに任せることができる。
  • 自分でhide()してshow()してということをしなくてよくなる。
  • Objectの値を変えるだけで見せたり消したりできる。(observerパターン)
  • 書き方に統一性が出るのでメンテナンスしやすくなる
  • 既存のjQueryと共存できるか

などが挙げられていたそうです。(私の入社前&考えてた人が退社したため残っていたログから推測)

React.jsも候補に入ってたのですが弊社はバックエンドの人でもフロント実装するので扱いやすいVue.jsがしっくり来たのかなーと解釈してます。

それでも扱えるとはいえやっぱり「ベストプラクティスなアーキテクチャを考えるのは難しい!」と弊社内で毎週木曜に開催されている【フロントエンドを考える会】にて嘆きの言葉をいただき、フロントエンドチーム内でもモヤったりしている現状です。

サクッと軽く作る分には素晴らしく万能なVue.jsですが大規模な構造になるとなかなか難しい...
でもこれって私達だけじゃなくてサービス開発でVue.js使ってる人たちみんな悩んでるんじゃない?と思い

10月30日(水)19:30~ クラウドワークスにて
BASE株式会社 松原 さん、株式会社スタディスト 笹木 信吾 さん、CBcloud株式会社 entaku さんをお招きし Vue.jsアーキテクチャリング勉強会を開催します! (唐突な宣伝)

cw-engineers.connpass.com

同じ悩みを持ってて困ってるぞーな人や、俺こうやってるぜと答えを持ってる人、みんなで考えていけたらなと思います。
是非ご参加くださいー!

最後に一言... まじで台風消滅してくれ...!! VueFes絶対に出たいんじゃ!! 今回VueFesの運営の方々が神対応すぎてハゲそうになってる。本当にありがとうございます。当日楽しみにしております。

クラウドワークスではフロントエンド(じゃなくても)エンジニアを募集しています:)

www.wantedly.com

コンテナフレンドリーではなかったRailsアプリケーションをDocker(ECS)に移行するまでの戦い

はじめに

SREチームの @minamijoyo です。 先日 CrowdWorks (crowdworks.jp) の本番環境のRailsアプリケーションを Docker (AWS ECS: Elastic Container Service) に移行しました。

f:id:minamijoyo:20190930160711p:plain

CrowdWorksは2012年にサービスを開始し、2019年10月現在、ユーザ数は300万人、月間で数億円規模のお仕事がやりとりされる、国内最大級のクラウドソーシングプラットフォームにまで成長しました。 サービスの規模拡大に合わせて、ソースコードも数十万行規模に成長し、 決して小さくはない規模のRailsアプリケーションに成長しました。

CrowdWorksの開発環境にDockerが導入されたのはもうかれこれ3年半前の2016年の4月頃、2017年1月頃にはCrowdWorks本体から切り出された一部の機能で本番環境に投入され、 その後新規に追加される周辺サービスや新規事業などでは最初からDockerが利用されるようになりました。 しかしながらCrowdWorksのコア部分であるモノリシックなRailsアプリケーション(通称CrowdWorks本体)は、いわゆる普通のEC2サーバで長らく運用されていました。

開発環境や新規の本番環境にDockerを導入するのはそれほど難しくはありません。 しかし既存の本番環境をDockerに移行するには、現行のシステムの仕様や制約事項など考慮すべきポイントが多く困難が伴います。 それが会社の主力事業であるそれなりに規模と歴史あるWebアプリケーションなら尚更です。 変更に伴うリスクが大きいのはもちろんですし、そもそも歴史あるWebアプリケーションはコンテナフレンドリーではないことが多く、 Dockerに移行するためには単にDockerfileを書けばよいという単純な話ではありません。 アプリケーションのアーキテクチャレベルでの変更が必要です。

これを技術的負債と言ってしまうのは簡単ですが、そもそもDockerの初期リリースは2013年で、イミュータブルなインフラが提唱されるようになってきたのもここ数年の出来事です。 それより以前からあるアプリケーションにコンテナフレンドリーを求めるのはちょっと厳しいかなと思います。

CrowdWorksではこれまでも、本番環境でDockerを利用していましたが、小規模な周辺のサービスで利用してもその恩恵は限定的でした。 というのも、多くの機能は依然としてCrowdWorks本体に実装されており、維持管理上の多くの問題も必然的にCrowdWorks本体に関連するからです。 とはいえDockerに移行するために解決すべき課題は多く、組織的な優先度の高い案件が次から次に降ってきたり、なかなか難しい時代が続きました。

しかし、Dockerというソフトウェアが生き残るかはさておき、 Webアプリケーションをコンテナ化していく時代の流れは巻き戻ることはなさそうですし、 コンテナフレンドリーではないCrowdWorks本体を、歯を食いしばって少しずつコンテナフレンドリーにしていかない限り、我々に幸せが訪れないことは明らかでした。

この記事では、コンテナフレンドリーではなかったCrowdWorks本体のRailsアプリケーションをDocker(ECS)に移行するためにやったことを紹介します。 網羅的なタスクの一覧を挙げるとちょっと書ききれないので、コンテナフレンドリーではない依存からどうやって脱却したのかを中心に、ハマりポイントで学んだ知見を共有します。

続きを読む

AWS Chatbot を使って AWS Personal Health Dashboardの通知をいい感じにSlackに通知する

みなさんこんにちは。SREチームの @kangaechu です。

8月23日に発生したAWSの障害は大丈夫でしたでしょうか?弊社のサービス crowdworks.jp は障害が発生したAZを使用していたものの、幸いにもサービス停止などの大きな被害を受けることなく乗り切ることができました。でも心臓にはよくないですね。

そんな障害時にも活躍するのがPersonal Health Dashboardです。 Personal Health Dashboardは自分のAWSアカウント上のリソースに影響する障害や、ハードウェアメンテナンスなどの対応が必要なイベントをお知らせしてくれる機能です。 AWSマネジメントコンソールの上部に表示されている🔔のアイコンですね。

f:id:kangaechu:20190906091220p:plain:w200
AWS Personal Health Dashboard

Personal Health Dashboardは便利なのですが、AWSマネジメントコンソールにログインしないと見ることができません。メールでの通知はあるのですが、Slackのインテグレーション経由で見ると長々と文面が表示され、要点が掴みづらいという問題があります。また、SNS経由でメール通知も試してみましたがJSONが潰れて表示され、可読性がよくありませんでした。

f:id:kangaechu:20190909155038p:plain:w400
SNS経由でのメール通知で SlackにPostしたもの。みづらい⤵️
2019年7月にAWS Chatbot のパブリックベータ版がリリースされました。

aws.amazon.com

AWS ChatbotはSlackへの通知をサポートしています。またAWSの他サービスからの通知の受信をサポートしています。現時点では以下のサービスが対応しています。

  • AWS Billing and Cost Management (for AWS Budget Alerts)
  • AWS CloudFormation
  • Amazon CloudWatch
  • AWS Config
  • Amazon GuardDuty
  • AWS Health
  • AWS Security Hub
  • AWS Systems Manager

今回はAWS Personal Health Dashboardの通知をSlackに通知してみましょう!

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.