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

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

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

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に通知してみましょう!

続きを読む

リファクタリング専門チームによるお金周りリファクタリング

こんにちは、エンジニアの @MinoDriven です。 今年2019年4月にリファクタリング専門チームを発足しました。 crowdworks.jp の最重要機能であるお金周りの機能に関して、どのような技術アプローチでリファクタしているかを紹介致します。特に、Railsには適用困難と言われているドメイン駆動設計の考え方を取り入れた手法を解説致します。


目次

  • 背景
  • リファクタリング専門チーム発足
  • 技術的負債
  • リファクタリング対象選定
  • どのようにリファクタしたか
    • 手法①:Concern側メソッドのinterface化
    • 手法②:ドメインオブジェクト
    • 手法③:コンテキスト分解
  • 成果
    • 構造before→after
    • 技術的負債が低減した
    • ロジックの見通しが良くなった
    • 仕様が見える化された
  • 苦労してること
    • 影響範囲調査が大変
    • 仕様不明瞭
    • テストが大変
  • その他リファクタリングする上で重要な考え方
    • 理想の設計を追い求めること
    • 既存コードを一切信用しないこと
  • We are Hiring!!

※本記事は下記スライドと関連します。ご参考にどうぞ。

www.slideshare.net

背景

過去記事 にあるように、crowdworks.jpはサービスインから7年経過し、30万行を超えるモノリシックRailsアプリになっています。

f:id:yo-iida:20190611210040p:plain:w600

コード増加量やファイル変更数が低下し、開発生産性が低下傾向にあります。 技術的負債の蓄積により、事業継続性や成長性を考える上での課題となっております。


リファクタリング専門チーム発足

技術的負債に対しては、外から見た挙動を変えずにコードを整理する「リファクタリング」で解決する必要があります。 しかし新機能追加案件に比べると優先度が落ちてしまうなど、力学上どうしても後手後手になりがちです。

そこでプロダクト開発と同じプライオリティでリファクタリングを遂行できるように、2019年4月にリファクタリング専門チーム「バグハンター」を発足しました。 チーム名は、私が制作した、リファクタリング技術によりバグを退治するゲーム「 バグハンター 」に由来しています。

バグハンターは一般的には「セキュリティ脆弱性を発見し賞金を得る専門家」という意味で使われますが、ここでは「バグやバグになりやすい設計を退治する専門家」という意味合いで使っています。 「バグが生まれてからバグ退治するのは退治にあらず。始めからバグが生み出されない、バグを根絶やしにする構造に作り変えるのが真のバグ退治」という想いも込めています。

私を含めチーム人数は2名。 両名ともエレガントなコードや設計が大好きで、なにより私自身は リファクタリング専門要員として採用され 、2019年2月にクラウドワークスにジョインしました。


技術的負債

様々な技術的負債を抱える中、目下最大の課題はFat Modelです。

f:id:DaiyaDriven:20190829174906p:plain:w300

crowdworks.jpではActiveRecordの多くがFat Modelとなっています。 Railsのお作法ではFat Modelがあるべき姿なのかも知れません。しかし実際には巨大化複雑化しすぎていて、下記にあるような技術的負債を抱え、開発生産性に悪影響を及ぼしています。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.