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

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

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

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

じゃーーーーん🎉

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

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

そして今回の目玉👀💡
VueFesJapanのロゴをお借りして私がデザインして作った
「VueFesJapan x CrowdWorks ロゴコラボ 2USBポートACアダプタ」限定200個となります！
まだまだ現役な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) に移行しました。

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マネジメントコンソールの上部に表示されている🔔のアイコンですね。

AWS Personal Health Dashboard

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

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には適用困難と言われているドメイン駆動設計の考え方を取り入れた手法を解説致します。

---

目次

---

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

クラウドワークス プロダクトの持続的開発のためのリファクタリング実践アプローチ from MinoDriven

www.slideshare.net

背景

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

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

---

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

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

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

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

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

---

技術的負債

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

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

認定スクラムマスターになりました！

お久しぶりです。気づけば入社してから1年以上の時が経ちました。
プロダクトDiv. カスタマーサクセス でエンジニアをしております @lemtosh469 です。

2019年3月、認定スクラムマスターの資格を取得しました！

認定スクラムマスターを取得してから少し期間が空いてしまいましたが、 改めて記事としてまとめることで、 クラウドワークスにおけるスクラムマスターの活動の様子が少しでも社外に伝われば幸いです。

クラウドワークスでは、アジャイルにプロダクト開発を行っており、 主にスクラムのフレームワークを採用しています。 （スクラムとXPのハイブリット*1が多い印象です。）

これまでもスクラムを採用したアジャイル開発自体は活発でしたが、スクラムの手法に責任を持つ役割（ロール）のスクラムマスターの認知はそれほど高くはありませんでした。 しかし、ここ最近急速に スクラムマスター や スクラムマスターに興味を持つ人 の数が増えつつあります。

今回は、

• 認定スクラムマスター研修のこと
• スクラムマスターになって行ったこと

をまとめて記事にできればと思います。

目次

認定スクラムマスター研修のこと

認定スクラムマスターとは

認定スクラムマスター(CSM: Certified ScrumMaster)とは、 ScrumAllianceの提供する2日間の研修講座を受講してWebテストに合格すると取得できる資格です。

www.scrumalliance.org

スクラムマスターは、主に下記のような役割が定義されています。

スクラムマスターがやること

• ROIを最適化する文化と環境を維持する
• スプリント計画を運営する
• スプリントレビューミーティングを招集する
  • スクラムチーム以外のひとがやってくる（チーム外の人など）
• 外部からの撹乱からチームを守る盾となる
  • （スプリント期間中に）プロダクトバックログアイテム以外の作業をさせない
• 進捗に対する障害を取り除く
• チームに指示しない、チームが何をすべきか言わない、という場合もある
• 振り返りを促進すべき

また、スクラムガイドと呼ばれるルール集などを規範としてスクラムチームを支援します。

https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

認定スクラムマスター研修とは

研修は、2日間に渡って行われます。 座学とワークショップを繰り返しながらスクラム開発について身体で学んでいきます。

www.jp.agilergo.com

僕の参加した回では、 ジェームス・コプリエン氏と川口恭伸（@kawaguti）さんを講師として、 スクラム開発を実践していくための基本的な知識の理解や心構えを体得していきました。

ちなみに、ジェームス・コプリエン氏は『組織パターン』の著者です。

組織パターン (Object Oriented SELECTION)

基礎から学べるとはいえ、ソフトウェア開発の用語や考え方、 実際に現場でスクラム開発を実践されている方が多く参加されているので、 事前知識や具体的なスクラムの実戦経験があるとより実りのある研修になるのではないかと思います。 （質問の時間もありますので、日々の実践で湧いてくる疑問も講師に聞いてみることができます。）

ランチタイムや自由時間は、基本的にフリーに過ごすことができますが、積極的に他の人に話かけるほうがよいです。 社外のスクラム実践者／経験者、アジャイルコミュニティの有識者と知見の交換や考えを知ることができる貴重な時間でもあります。

僕はおしゃべりが得意な方ではないので「意外と弁当お美味いっすね！」くらいを入り口にして、席の近い人とお話をさせていただきました。

余談ではありますが、アジャイル系のコミュニティのイベントは、 基本的にOST形式*2が取られていることが多く、ディスカッションを通じてアジャイルやスクラムの理解を深めていきますので、積極的に話すことに慣れていくほうが圧倒的に得られるモノが多いです。

*1:スクラムのフレームワークにXPのプラクティスを組み合わせてアジャイル開発をしている

*2:OST（Open Space Technology）は、参加者が議論したい課題を自ら提案し、自主的に話し合いを行う手法です。