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

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

実録:お母さんが挑んだ、その一年を振り返る。

はじめに

みなさまこんにちは、たかのと申します。 昨年よりお仕事をしており、ちょうど一年前に、入社後2ヶ月の様子を4コマでご紹介しました。

今回は、その一年後。なんとか生き残れている、その様子をお届けします。 相変わらず検索性に若干難点がございますが、そこはご容赦を。

  • はじめに
  • 1. 母、春先の荒波を乗り切る!
  • 2. 「やりたい」と「できる」はちがうんだ。
  • 3. とくいなことはなんだっけ?
  • 4. いろんなデータが取られてる!
  • 5. フロントエンドも楽しく楽しく。
  • 6. この一年をふりかえる。
  • おわりに

続きを読む

クラウドワークスのフロントエンド活動を振り返る 2020

CrowdWorks Front-End 2020 CrowdWorks Engineer Blog 2020 Adevent Calender

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

クラウドワークスでフロントエンドの可能性を模索し続けている @yamanoku です。 アドベントカレンダーを今年もやっていきます。初日の盛り上げ手としてよろしくおねがいします。

フロントエンド活動の振り返りをしてみよう

クラウドワークスでは現在、フロントエンド専属のエンジニアチームというものは存在しません。 その代わりにサーバーサイド(Ruby on Rails)も併せてフロントエンド開発するのが基本体制となっています。

各チームごとでのフロントエンド開発の悩みやノウハウといったものは存在するのですが、それらを全体を通してうまく共有・把握できてないような気がしていました。

そこで今後の開発で各チームの「次」に活かすための参考として、併せて今年はどういったことを行っているのかを外部にも知ってもらうために、この記事では 2020 年のフロントエンド活動を振り返ってみました。

続きを読む

業務系一筋のエンジニアがクラウドワークスに入って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 × 年月」 の組み合わせで、一意制約がかけられています。
続きを読む

© 2016 CrowdWorks, Inc., All rights reserved.