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

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

業務系一筋のエンジニアがクラウドワークスに入って1ヶ月たった感想。

f:id:tk584:20201111152059p:plain

はじめに

はじめまして。クラウドワークスに今年10月に入社しました小橋と申します。

この記事では、私がクラウドワークスに入って1ヶ月たった感想について書いていきます。

今までの経歴と入社した経緯

まず本題に入る前に、今までの経歴とクラウドワークスに入った経緯について簡単に触れます。

新卒で大企業向け業務パッケージソフトメーカーのエンジニアとして入社し、給与・会計分野の社内向けWebアプリケーションの開発を行ってきました。

上記12年程在籍したあと、クラウドワークス子会社のgravieeに入り、2年ほど社内業務システム開発(契約・請求管理)+ひとり情シスみたいなことをやっていました。

今年の8月くらいからクラウドワークス-graviee間の連携を今まで以上に強化するという流れになり、その一環でシステム周りも徐々に統合するため、graviee内で自分の仕事がなくなってしまいました。

これを機に転職なども考えたのですが、会社とも相談したところクラウドワークスのエンジニアとして受け入れていただけるということで、頑張ってみることにしました。

このような経緯なので、クラウドワークスという会社についても、「クラウドワークス」のサービスを運営している会社だというくらいの認識で入社に至りました。

ずっと業務系&Javaをやってきたので、Webサービス運営会社&Railsでの開発業務も初めてです。

予備知識もなくキャリアも異なる状態で入社した自分がクラウドワークスについて書くことで、クラウドワークスに興味を持っている方や、業務系エンジニアからWebサービス運営会社へキャリアチェンジを検討している方などの参考になれば良いと思っています。

目次

  • はじめに
    • 今までの経歴と入社した経緯
  • 目次
  • クラウドワークスに入っての感想
    • 文化について
    • チームやスクラム開発について
    • プロダクトや技術について
  • 大変だったこと
    • 質問をするコストが高い
    • MTGが多い
    • 情報に飲まれやすい
  • やっていきたいこと
  • We're hiring!
続きを読む

業務効率化には強化された Slack のワークフローがオススメ

はじめに

こんにちは。家にいる時間が長くなってからジャンキーなベジタリアン料理が趣味になっている大浦です。(おからこんにゃくのカルビ丼おいしいですよ!) ここ最近 Slack のワークフローのステップにアプリが追加されたことにより非常に便利になったので、そのひとつの例を書いていきたいと思います。ワークフローについては去年末に「Slack ワークフローをさわってみた」という記事を投稿してますので参考にしてみてください。

本記事で扱うアプリのステップ

Google Sheets for Workflow Builder https://slack.com/app-pages/google-sheets

Google スプレッドシートの行の追加に Slack が使えるようになって業務効率化が捗ります。🎉

Add information from Slack… https://slack.com/apps/A01AWGA48G6-google-sheets-for-workflow-builder

何に使える?

下記のような 頻度は低いがそれでも一定発生する業務 に向いているでしょう。

  • 相談窓口
  • 稼働報告/管理
  • 従業員の体調報告/管理
  • 定期的なミーティングやイベントのフィードバックの収集

逆に、頻度が極端に低くかったり高かったりする業務だと、Slacck ワークフローは使わず、直接スプレッドシートに書き込んだり、専用のUIを設けたりしたほうがよいと考えます。当人のコンテキストスイッチの負荷が目安というところで、なかなか塩梅が難しいところですね。

続きを読む

クラウドテックのテーブル構造を改善していった話

はじめに

クラウドワークスの運営する クラウドテック というサービスで開発に携わっている @hamajyotan といいます。ここでは、最近クラウドテックのデータベース構造の課題を解消した話をします。

クラウドテックは、ハイクラスなフリーランス IT・WEB エンジニアやデザイナーに特化したマッチングサポートサービスとして 2015年4月から始まったサービスです。サイト自体は Rails 4.0 あたりからスタートし、現在 Rails 6.0.3.3 で動いています。

データはアプリケーションより長寿なので改善を要する

一般に、データ(ベース) の寿命はアプリケーションの寿命より長いと言われています。例えばシステムの統合、あるいはシステムのフルスクラッチなどがあったとしてもそれとは別観点でデータベースはそのまま残すか否かは検討の余地があり、そしてそのまま既存のデータを引き続き扱うことも多いです。

そして、データに長く付き合うためにはプログラムと同様、頻度の差はあれど定期的なリファクタリングはあるべきでしょう。 プログラムと違い、 Security Fix や Rails バージョンアップの変更に追従するなどの動機はあまりありませんが、少し前にバズっていた技術的負債の解消などはデータベース構造のリファクタリングの動機となりえます。

改修前のざっくりとした構造

今回の話題の登場人物を示しています。

f:id:murasahi:20200929170713p:plain

※ ここでの名前は、ある程度抽象したものに置き換えており実際の名前とは異なります。

  • 「ユーザ (User)」はクラウドテックに登録くださっているユーザそのものを表します。
  • 「クライアント (Client)」はクラウドテックに案件を提供くださっている企業を表します。
  • 「案件 (Project)」は、特定のクライアントの案件を特定のユーザが実施する業務を示し、通常 3ヶ月前後の期間で実施されます。
  • 「月間作業報告 (MonthlyReport)」は、ユーザが案件の業務を実施する際の作業報告書のイメージです。
    • 月ごとに分かれており、例えば 1月から3月までの3ヶ月間の案件であれば、1レコードの案件から 3レコードの月間作業報告が発生することになります。
    • 「案件ID × 年月」 の組み合わせで、一意制約がかけられています。
  • 「クライアント請求 (Bill)」および「ユーザ支払 (Payment)」は、月ごとの稼働の検収を経て、クライアント/ユーザそれぞれに対する請求/支払を意味するデータです。
    • 「月間作業報告」と同様に月ごとに分かれており、例えば3ヶ月間の案件に対しそれぞれ 3レコード発生することになります。
    • 「案件ID × 年月」 の組み合わせで、一意制約がかけられています。
続きを読む

クラウドワークスのWebアクセシビリティチェックを始めてみた

こんにちは。フロントエンドエンジニアの yamanoku と申します。

最近久々に出社しましたが、どうやら半年以上も出社していなかったことに驚愕しました。自分自身が違和感なくリモート作業やれているのかもなぁという気づきにもなりました。

前回の記事では東京都 新型コロナウイルス対策サイトの Web アクセシビリティチェックをしたという話をしました。

engineer.crowdworks.jp

今回の記事では、チーム内でクラウドワークスの Web アクセシビリティチェックを実施してみた話をします。

続きを読む

【Vue.js】負債を返却しながら機能追加しなければならない状況で実践したフロントエンドのコンポーネント設計

はじめに

こんにちは! 社会人2年目を頑張っております、エンジニアの@b0ntenmaruです。

今年2月までリファクタリング専門チームにてcrowdworks.jpの技術的負債を返却するために奮闘しておりましたが、そこから現在まではユーザーの皆様に安心安全なサービスを提供するためにクラウドワークス 安心安全宣言のための施策を行っています。

リファクタリング専門チームについては以下をご覧ください。

engineer.crowdworks.jp

qiita.com

施策による機能開発を行う際に直面した課題

施策では主にフロントエンドの機能追加をすることになったのですが、技術的負債によりスピードを維持しながら開発を続けることは困難な状態でした。 crowdworks.jpを取り巻くフロントエンドの技術スタックはざっくり書くと下記3つに分類できます。それぞれで発生している問題を簡潔にまとめます。

ERB

  • html.erbファイルにif分岐や業務ロジックが直接記述されており、かつ同様の記述が複数ファイルに散らばっている

※ ERBはcrowdworks.jpで採用されているRuby on Railsのテンプレートエンジン

CSS

  • 秩序なく数年上書きされ続けたCSSが無数に存在していて、意図したように実装できなかったり意図しないページのデザインが破綻してしまうことが頻繁にある
  • 変更による影響範囲の特定が困難、かつできたとしても調査に時間がかかる
  • CSSの中には!importantで上書きされ続けたCSSも多数存在しており、新規のデザインを適用される場合やむをえず!importantを上書きするしかない場合がある

jQuery

  • 古の時代に書かれたjQueryイベントハンドラが大量に張り巡らされており、変更を加えると意図しないページで破綻していることがある
  • そもそも読むのに膨大なエネルギーを消費する
  • 変更による影響範囲の特定が困難、かつできたとしても調査に時間がかかる

このような課題があり、スピードを維持して開発が続けられるよう機能追加だけでなく負債の返却作業をする必要もありました そこで、関心事を集約して複雑なUIを確実かつ堅牢に組み上げる手段であるコンポーネントベースの思想を取り入れ、かつ今後の負債化を防ぎ、持続的に開発していくためのコンポーネント設計を考えました

※ crowdworks.jpではVue.jsを採用

この記事ではhtml.erbからVue.js置き換えなど負債を返却しながら機能追加していく時に実践したフロントエンドのコンポーネント設計について書いていこうと思います。

続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.