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

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

CloudWatch Logsの料金が高い原因はコレだった。CloudTrailとの微妙な関係

こんにちは。crowdworks.jp SREチームの田中(kangaechu)です。先日RubyKaigi2023に参加するため、松本に行きました。街を歩いていると目線の先に山が見えたり、温泉が近くにあったりなど松本の自然が近くにある感じがとてもよかったです。ちょっと住みたくなって不動産屋さんで家賃を眺めたりしておりました。

今回は小ネタとして、AWSのCloudWatchの料金が高くなったことで見つけたCloudTrailの設定についてです。

続きを読む

RubyKaigiのスポンサーをする理由

記事タイトル「RubyKaigiのスポンサーをする理由」サムネイル 過ごしやすい季節になり外出が増えましたプロダクト開発部部長兼VPoEの@hihatsです。私は入社してまだ2年弱ですが、クラウドワークスでは2018年以降、継続的にRubyKaigiのスポンサーをしています。RubyKaigi2023のために松本にきている真っ最中の今、我々がRubyKaigiというプログラミング言語の技術カンファレンスにスポンサーする理由を明確に発信したほうがよいなと思いたちブログ記事にすることにしました。

1. RubyでのOSS活動への貢献

これが最も大きい理由です。弊社の基幹事業とも言えるマッチングプラットフォームの クラウドワークス、エージェント型マッチングの クラウドテックビズアシRubyを採用しており、我々の事業および利益はRubyというプログラミング言語が無ければ成り立っていないと言えます。Rubyが無かったらプロダクトの立ち上げができなかったのかと言われると、他のプログラミング言語で開発することは可能ではあったろうと思いますが、現在のように多くのユーザーに使われるためのプロダクト改善開発ができただろうかという点で、当時は最善に近い選択ではなかったのではないかというのが個人的な見解です。

Rubyを採用していていいことばかりではないのも正直というかむしろ当然ありますが、今後も我々の事業とはそう簡単に切り離せるものではなく、Rubyの発展が私たちのソフトウェア開発に大きく影響していくのは自明であり、結果的にそれがプロダクトのユーザーへの価値提供に繋がるため、なんらかの形でRubyに貢献したいです。

2. Ruby企業コミュニティとのネットワークづくり

同じプログラミング言語を使い(主に)Web開発をしている組織の人たちが一同に介するわけで、自社がどういったことをやっているか知ってもらいたいし、もっと他社のことも知りたいと思っています。RubyKaigiに参加するだけでもそれらは可能ではありますが、会社としてやるべきことを個人に負わせることは健全ではないし、スポンサーになることでよりやりやすくなると考え積極発信する場を設けています。

3. Rubyエンジニアとの接点を増やす

日々採用媒体などを活用して積極的に採用活動をしており、ここ1年でも順調に仲間が増えています。とはいえ、Rubyという言語のコアに興味をもっているエンジニア1,000人以上と直接的に接して覚えてもらうのにこれ以上の場はないです。なんなら採用予算のすべてここに突っ込んでもいいんではないか?くらいの過激派な思考の持ち主であることは社内秘の話です。とにかくもっと仲間が欲しい。

以上の3点がRubyKaigiにスポンサーをする理由です。

まとめ

技術知識を得ることなどは一般参加者として参加するだけでも可能なので、スポンサードでないとできないことに絞って列挙しました。一方でスポンサーとして企業の名前を広告してもらうだけでもまた一定の効果はあると思います。それに留まらず、実際に言語の進化をこの目で見ることができるのもRubyKaigiの良さで、わずかながらでもそれに貢献できていると実感することができます。セットでなおオトク。残り1日ですが、現地のみなさん引き続きよろしくお願いします。

(いつも忘れる)追記、We are hiring!

エンジニアを募集しておりますので、少しでも気になる方はこちらDMでも気軽にご連絡ください。RubyKaigi2023参加者ですって書いてもらえれば私とカジュアルに話す場セットさせてもらいます!

ブースに足を運んでいただいた皆さんありがとうございました。最終日の緊急企画に当選したみなさんおめでとうございます!

なお私の推薦書はこちらでした!作戦お見事

RubyKaigi2023にてスポンサーとして協賛・ブース出展・ノベルティ配布します

こんにちは。みーたです。

株式会社クラウドワークスは2023年5月11日から13日までの3日間で開催される、プログラミング言語 Ruby に関する世界最大級の国際カンファレンス「RubyKaigi 2023」のプラチナスポンサーとして協賛・ブース出展します。

また、まつもと市民芸術館(およびオンライン)にて開催されるため、クラウドワークスのエンジニアメンバーも私を含む11名で現地参加いたします。

会場ではこの後紹介するノベルティTシャツを着ながら飴を配っておりますので、サービス開発やエンジニアリング組織のことなどお気軽に話しかけてもらえたら嬉しいです🫶

Rubyクラウドワークス

創業事業である crowdworks.jp では開発の基盤として Ruby on Rails を使用しており、一昨年サービスリリース10周年を迎えました。 クラウドテック、新規事業のPARKなど複数のプロダクトでRubyを使用しております。 Rubyコミュニティのさらなる活性化に寄与するとともに、これからのRubyの発展に一層貢献してまいります。改めまして、よろしくお願いいたします。

RubyKaigi 2023 概要

主催:Team RubyKaigi 2023 ・ 一般社団法人日本Rubyの会 開催期間:2023年5月11日(木)、5月12日(金)、5月13日(土) 場所:まつもと市民芸術館 および オンライン

基調講演:まつもと ゆきひろ氏 ほか

公式サイトURL:https://rubykaigi.org/2023/

今年もかわいいノベルティ作りました

RubyKaigiのロゴをあしらったTシャツとレザースタイルマルチケース、クラウドワークスのロゴ組飴

今回は、RubyKaigi 2023のロゴをあしらったTシャツと、クラウドワークスのロゴが入ったレザースタイルマルチケースを用意しました! 2022年3月に新しくなったクラウドワークスのコーポレートロゴを使った組飴も持っていきます。

RubyKaigiの会場である松本のイラストが大きく配置されたTシャツの拡大画像 Tシャツは4.4オンスのドライ素材を使用しており、とても軽く風通しが良いものになっています。 RubyKaigiの会場である松本のイラストが大きく配置されいます。 (ロゴ提供:Team RubyKaigi 2023)

数に限りがあるため、ブースにてアンケートにお答えいただいた方の先着でお渡ししたいと思っております。

マルチケースを閉じた状態マルチケースを開いた状態・内に仕切りがある

レザースタイルマルチケースは大きく開いて使いやすい手のひらサイズの合皮素材マルチケースです。目薬やリップなどの薬・化粧品や、イヤホンやケーブル類のモバイルグッズなど細々としたものを持ち運ぶのにピッタリ。ゴムバンドとメッシュポケットが付いているので、開いたときに中身が落ちてしまうのを防げます。カバンの中で迷子になりがちなものをまとめて入れておけるので便利です🙆‍♀

こちらも数に限りがありますのでご了承ください。

あめを配り切る迄帰れないのでもらってってくださいと書かれたプレートと飴が入ったカゴ そして去年たくさんの人に手にとっていただき大好評だったCrowdWorksロゴ飴も持っていきます。

塩サイダー味で、材料に塩が入っているので熱中症対策にも役立ちます💪

ブースに来てお話出来たら嬉しいです

CrowdWorksとしても久々のブース出展で、私にとっては初めてなので至らないところもあるかもしれませんが、当日はたくさんのRubyistさんたちとお会いできることを心より楽しみにしています。

受付から見て一番奥のCookpadさんのお隣におります。

あと、みーたはこんな感じのタグを引っ掛けてうろうろしていると思うので仲良くしてください🙇‍

また、現地にまで来ちゃうRuby愛が収まらないRubyistさんたち💖とお仕事も一緒にしていきたいので、もし転職で「RubyRuby on Rails)を使っている企業探したいな...」と思っていらっしゃいましたら、弊社にも興味を持っていただけたら嬉しいです🙌

www.green-japan.com

RundeckをFargate化してデプロイを自動化しました

RundeckをFargate化してデプロイを自動化しました

久方ぶりです。crowdworks.jpのSREチームに所属しています @ciloholic です。

この記事では、半年ほど行なっていた「RundeckのECS on Fargate化」の取り組みを紹介していきます。

まず、Rundeckとは

PagerDuty社が提供するOSSのジョブ管理ソフトウェアです。OSS版の「Rundeck Community」とEnterprise版の「PagerDuty Process Automation」が存在し、ジョブのスケジュール実行や処理失敗時の自動リトライ、処理の開始/終了/成功/失敗に対して通知フックが設定できます。SSH経由でもコマンドが実行できるため、複数サーバに渡ってジョブ実行が可能です。

続きを読む

「輪読会ってどうやるの?」が「やってみてよかった」に変わった!"レビューを考える輪読会"のご紹介

こんにちは。クラウドテックの開発チームでエンジニアをしている@tama555です。今回は社内で開催した「レビューを考える輪読会」についてご紹介します。はじめての輪読会で手探りでしたが、毎回ディスカッションが盛り上がって「やってよかった!」と胸を張って言える楽しい会になりました。この記事では「輪読会やってみたいけど、どう始めたらいいのか分からない」という方向けに、具体的な手順やポイントについて書いていきます。

一般的な輪読会とは

人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。

引用元: 「輪読会(りんどくかい)」の意味や使い方 わかりやすく解説 Weblio辞書

輪読会に参加することで、参加者で共通の知識や考え方を身につけることができ、お互いの専門分野や知見を交換できます。また、定期的に輪読会行うことで、参加者同士のつながりを深め、コミュニティの形成にもつながります。

今回の輪読会を始めたきっかけ

去年の夏ごろ、個人的にコードレビューについて悩むことが増えていました。例えば「レビューでどこまで細かくみたらいいか分からない」とか「パッと見良さそうに見えるけど、LGTM出す自信がない」とか、です。これをチームメンバーに相談したところ、あるひとりの方がGoogleが公開している「コードレビューの基準」というドキュメントを紹介してくれました。レビューする側もされる側も何か基準があればやりやすいだろうと考えて「まずは一緒に読みましょう!」とチームに声をかけて始まりました。(輪読会や勉強会など開催する人の背中を押してくれる、いい会社です。)

「レビューを考える輪読会」概要

題材

Googleが公開している「コードレビューの仕方」の日本語翻訳版

目的

  • 題材をきっかけにレビューについて考えて意見交換する
  • どんなレビューが「良い」とされるか、メンバー間で会話して目線を合わせる
  • (できれば)クラウドテック開発チームのレビュー標準化を目指す

参加者

開催頻度

  • 毎週30分
  • 全15回で読了

その他

  • 事前準備は不要 → 題材が一部を切り出して読んでも理解できる内容なので予習復習は不要でした
  • オンライン開催 → 普段から業務で使っているGatherというバーチャルオフィスで開催しました
  • 毎回議事録を残す → ドキュメントのテンプレートを作って毎回記録を残しました

輪読会の進め方

事前にアジェンダの型を作って参加者に共有することで、やることが明確化してスムーズになりました。1回30分の配分も大まかに決めて、会話する時間を多く取るように工夫しました。

パソコン画面のスクリーンショットです。 画面の右半分はブラウザが開かれていて輪読する題材のページが表示されています。タイトルは「コードレビューのスピード なぜコードレビューは素早く行うべきか?」です。ひとりの人が読む範囲が選択されています。 その左には別のブラウザウィンドウが開いていて、輪読会の議事録が表示されています。 タイトルは「レビューを考える#7」で「今日の読む範囲」の項目に「コードレビューのスピード」とハイパーリンクがあり、その下にリストで、コードレビューはどれほど急ぐべきか?/スピード vs 割り込み/素早い応答/タイムゾーンをまたがるレビュー と記載があります。 その下の項目は「アジェンダ」です。 リンクの共有(2分)資料/議事録 議事録の書記を決定(3分) チャンネル #product-dev-service-babubabu/ランダム @cwbit shuffle (伏せられている)/先頭の人が書記をお願いします Googleの「コードレビューの仕方」を読んでみよう(10分) 1人1分くらいで読み終わる分量ずつ/席順に時計回り/わからなかった用語はその場で調べる/どこまで読んだか分かるように議事録に記録する 読んで思ったことを発表しよう(1人1分) (時間が余ったら)チームに活かせそうな具体的なトピックがないか考えてみよう(10分) 一番左端には別の細長いウィンドウがあり、Gatherのコメント欄が表示されています。題材のリンクと議事録のリンクが投稿されており、最新のコメントは「CL=change list でしたよね?」とあります。
オンラインで実施した輪読会の画面共有イメージ(当時のスクショがなかったので疑似再現です)

以下、アジェンダについて順番に紹介します。

リンクの共有(2分)

  • 参加者にその日に読むページと議事録ページのリンクを共有します

議事録の書記を決定(3分)

  • 後からいつでも見返せる場所に議事録を残します
  • 参加者の中から毎回ひとり書記をしてもらうので、負担が偏らないように気を配りました
    • 名前をシャッフルしてくれるツールを使ってランダムで決めます
    • 参加者の方の中から積極的に挙手してくださることもありました

Googleの「コードレビューの仕方」を読んでみよう(10分)

  • 1人2分程度で読み終わる分量を4〜5人で順番に回して読みます
  • 資料を開いて画面共有すると今読んでいる範囲が分かりやすかったです
  • 分からなかった用語はその場で調べて議事録にも記録しました

読んで思ったことをコメントしよう(1人1〜2分くらい)

  • その回で読んだ範囲で、気になったこと、思ったことなどを順番に全員がコメントします
    • 例: "レビューは「素早い応答」が大事という記述がありましたが、業務ではなかなかできていないので反省しました。簡単なコメントだけでもこまめに返答するように心がけたいです。"
  • コメントを議事録にメモすることで、後からどんな話になったか見返すことができます
  • コメントに対して他の参加者が自由に発言してOK。賛同の感想や深掘りする質問など、毎回話が盛り上がりました

参加者の会話を促すポイント

コメントのパートで参加者同士のディスカッションが活発になるかどうかは、ファシリテーションが鍵になります。参加者の会話を促すポイントを自分なりにまとめてみました。

  • まずはじっくり話を聞く
  • 全部聞いた後に、聞き返して深掘りする
  • 自分の意見を簡単に言ってから、他の人はどう思うか指名して聞く
    • ただ漠然と「どうですか?」は答えにくい
  • 具体的な事例を聞いてみると、話が発展することが多い
    • 例: "コーディングの最中にレビューを割り込みしてしまうと作業効率が下がるという話がありましたが、実際の業務ではどのようにレビューする時間を確保していますか?"
    • 例: "レビューのスピードを上げたいけれど経験が少なく時間がかかってしまいます。レビューのコツを掴むにはどうしたらいいと思いますか?"

参加者のフィードバックアンケート結果

輪読会の最終回の後で、参加者のみなさんにフィードバックアンケートを回答してもらいました。結果は概ね好評価で、やはりディスカッションが有益だったという意見が多かったです。

輪読会について何かコメントやご意見があれば、お聞かせください。

・輪読会を通じてレビューの目線が揃った状態で運営できているので新しく入ってきた方にどうやって落とし込むかを考えていきたいですね

・開催いただきありがとうございました。RVのベストプラクティスってちゃんと読んだことなかったので、学びが多く、すごくいい機会になりました!

・話が逸れていったときのほうがなんとなく興味深い話になっていった気がしています!

・また別の輪読会があったら参加したいと思いました

・参加者の皆様も積極的にコメントしてくださって盛り上がったので大感謝です

(回答一部抜粋)

 ▼その他のフィードバックアンケート結果(クリックで展開)

Q1. 今回の輪読会の内容は、あなたにとって興味深かったですか?(5段階)
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 1人(14.3%)
5: 6人(85.7%)

Q2.輪読会の進行や時間配分について、適切でしたか?(5段階)
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 2人(28.6%)
5: 5人(71.4%)

Q3. 輪読会のディスカッションは、有益だと感じましたか?
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 2人(28.6%)
5: 5人(71.4%)

Q4. 輪読会に参加することで、新しい知識やアイデアを得ることができましたか?
1: 0人(0%)
2: 0人(0%)
3: 0人(0%)
4: 1人(14.3%)
5: 6人(85.7%)

よかったこと

  • 時間配分について
    • ディスカッションの時間をしっかり確保できたので良かった
    • 30分は集中が途切れないちょうどいい時間だった
  • 参加へのハードルについて
    • 事前の準備が不要なので気軽に参加できた
    • 前の回を聞いてなくても参加できるゆるさが良かった
  • ディスカッションパートについて
    • 参加者の積極的なコメントによって、毎回盛り上がりのある輪読会になった
    • まずは話を聞く、頭ごなしに否定しないことで、自由に話せる空気づくりができていた
    • チャットツールを使った文字でのコメントから話が広がることもあった
  • 得た知識やアイディアの活用について
    • 題材が「レビュー」で毎日の業務と関連が高かったので、学んだことをすぐに実践できた
    • 2チーム合同で実施したので他チームの文化を知れた。良い取り組みを真似することができた

改善できそうなこと

  • 予定の30分をオーバーする日もあった
    • その日に集まった人数から「今日は時間オーバーになるかも」など最初に予想して、後ろの時間に予定がある人から順番に喋ってもらってもよかったかも
    • 話が盛り上がりすぎてオーバーになることもあったので、それはそれで良いことだったかもしれない

筆者の個人的な感想

  • 業務が忙しい期間はお休みをしましたが、無事に最終回までやり切れて達成感!
  • 参加できる日は毎回ファシリテーションをやるようにして経験を積ませてもらったので、ファシリ力が上がったかも
  • それより何より、毎回ディスカッションが楽しかったのが大収穫でした(つまらないことは続かない……)

具体的なアクションにつながった事例

私たちクラウドテックの開発チームでは、輪読会で得た知見からレビューの標準化を進めるべく、ドキュメントにチーム独自の「コードレビューの仕方」をまとめました。

例えば、レビューコメントに内容に応じたラベルをつけることを、チームの合意をとって明文化しました。ラベルは[MUST] [IMO] [NITS] [ASK] [GOOD]があり、チームメンバー間でコメントの粒度を揃えることができ、実装者に修正の必要度を伝え、レビュアーと実装者の心理的負担を軽減するのに役立っています。

レビュー標準化の細かい紹介はいつの日かまた記事にまとめたいですね。

ドキュメントページのスクリーンショットです。左上に「コードレビューの仕方 - クラウドテック(2022/09/29)」とタイトルの記載があります。以下本文です。GOOD良い実装につけるコメントです。レビューは間違い探しになりがちなので、良いところを積極的に賞賛しましょう。実装者のモチベーションアップにつながりますし、レビュワーとしても良いコードを意識することで自分の実装に還元することができます。1つのPRに対して1つ以上GOODコメントをつけるように意識しましょう。「ご対応ありがとうございます」だけでもOKです。観点例: うまくメソッドを使ってスマートに書けている/例外処理が適切に実装されている/面倒な実装を丁寧にやってくれた コメント例: GOOD この書き方、スマートでいいなと思いました!
チーム独自の「コードレビューの仕方」をまとめたドキュメントの一部

今後の展望

今回、良い輪読会体験ができたので、違う題材を使ってまたやりたい欲があります。次回はもっと技術的な内容に特化した題材でも良いかもしれません。例えばクリーンアーキテクチャドメイン駆動設計(DDD)関連の書籍は、今回より分量も多いし難易度も高そうです。でもその分、より多くの知識をチームで共有できるのでチャレンジのしがいがありそうですね。

現在は別の勉強会のシリーズが始まっており輪読会については何も決まっていませんが、また何か実践した時にはブログにまとめたいと思います。

まとめ

今回「レビューを考える輪読会」を通してコードレビューへの理解が深まり、チーム内での目線合わせができました。また、参加者同士が意見交換をし、相互理解を深めることができました。普段一緒に働くチームや、違うチームとの合同開催など、コミュニケーションを深めたいメンバーで輪読会をやることをおすすめします。

もし、これを読んでいるあなたが輪読会をやろうかどうか迷っているのであれば、まずは思いきって第一回を始めてみましょう。やってみて改善点が見えてきたらブラッシュアップしてより良い輪読会にしていきましょう。

ここまで読んでいただいてありがとうございました!

We're hiring!

最後に、クラウドテックでは事業と開発をリードしていただける仲間を募集しています!ご興味のある方は以下のリンクからご応募ください!

herp.careers

© 2016 CrowdWorks, Inc., All rights reserved.