リモート主体のチームで成果以上にコミュニケーションを重視したら生産性が向上した話 - クラウドワークス エンジニアブログ
みなさん、こんにちは。エンジニアリングdivのしもはたです。 最近、機動戦士ガンダムを一話から見始めました。戦場で戦って成長していくアムロの姿を見ると自分もうかうかしてられないなと思いますね。早くニュータイプ系エンジニアになれるように日々成長ですね。 さて、話は変わりますが入社時から関わっていたチームから別のチームに異動することになりました。移動前のチームでは、自分以外のメンバーがフレックス・リモートの制度をフルに活用し、私が出社してもチームメンバーが職場にいない状況は珍しくありませんでした。 今回はリモートワーク初心者の私がリモートワーク中心の開発チームで直面した問題と解決策をお伝えしようと思います。リモートワークを取り入れてみたがうまく運用が回らないよ、とお困りの方の参考になれば幸いです。 【目次】 チームの体制とフルリモートの実態 リモートワークのメリット 発生した問題と解決策 問題
リファクタリング専門チームによるお金周りリファクタリング - クラウドワークス エンジニアブログ
こんにちは、エンジニアの @MinoDriven です。 今年2019年4月にリファクタリング専門チームを発足しました。 crowdworks.jp の最重要機能であるお金周りの機能に関して、どのような技術アプローチでリファクタしているかを紹介致します。特に、Railsには適用困難と言われているドメイン駆動設計の考え方を取り入れた手法を解説致します。 目次 背景 リファクタリング専門チーム発足 技術的負債 リファクタリング対象選定 方針①：パレートの法則（80:20の法則） 方針②：リファクタリング選定基準3軸 「仕事周り」か「お金周り」か お金周りモデルのリファクタリングを妨げるConcern 課題①：ActiveRecord側の構造に依存したコード 課題②：型や構造のチェック(リスコフの置換原則違反) 課題③：重要業務概念の埋没 どのようにリファクタしたか 手法①：Concern側メソ
crowdworks.jpのエンジニアリング戦略(2019年6月現在) - クラウドワークス エンジニアブログ
最近は人事のほうにも片足突っ込んでおりエキサイティングな日々を送っております飯田です。 今回は現在のcrowdworks.jpのエンジニアリング戦略についてお伝えできればと思います。 状況の整理 これまでの中長期戦略の反省 中長期の技術的投資のための専任チームの発足 フロントエンドチーム(チーム名: トリュフ) リファクタリングチーム(チーム名: バグハンター) 継続的バーションアップの浸透 今後の組織戦略 エンジニアの役割定義 今期エンジニアリング部の目標 個人的なこと We Are Hiring 状況の整理 crowdworks.jpはサービスインから7年が経過し、モノリシックなRailsアプリケーションのコードは30万行を超える規模感に成長しています。 一方で、コード行数の増加量はここ最近の傾向としては鈍化しており、ファイル変更数の推移も低下の傾向となっています。以前から巨大なクラス
スクラムチーム内で1on1を実施した話 - クラウドワークス エンジニアブログ
はじめに こんにちは、玉露チームの @t0yohei です。 CrowdWorksに入社して5ヶ月と日は浅いですが、5万行に及ぶJavaScriptの大改修や仕事検索の表示順位改善をなどを行っています。 上記の大改修についてまとめられている記事がありますので、よろしければ合わせてお読みください。 混沌を極める jQuery のコードをいかにして Vue.js に頼らずに整理したか CrowdWorksでは、毎年12月にアドベントカレンダーを作成しています。アドベントカレンダー明けの一発目の記事ということで、ネタがねーよ頑張って書いていきたいと思います。 自分が現在所属する玉露チームは、クラウドワーカーの、お仕事とのマッチング体験を良くすることがミッションのチームで、エンジニア3人・プロダクトオーナー1人・デザイナー1人で開発を行なっています。この玉露チームではチームビルディングの一環として
2018年マネジメント振り返り - クラウドワークス エンジニアブログ
この記事は、クラウドワークス Advent Calendar 2018の10日目です。 こんにちは、プロダクトDiv. エンジニアリング部 部長の飯田です。 エンジニア組織のマネジメントは4月からやらせていただいているのですが、この記事ではこのマネジメント観点から激動の2018年を振り返ってみたいと思います。 私自身のマネジメント歴としては、4月当初は2チームのマネージャーとして始まり、その2ヶ月後にはエンジニア全体をみることになり現在に至ります。 4月から10月までの半年は、プロダクト全体の施策の攻めと守りのバランスの葛藤や、現場と経営陣の価値観の差異をどうやって埋めるのかということについて頭を悩ませてきた半年でした。 思うに、組織全体で長きにわたり分析・解決が難しかった課題としては「組織の意思決定プロセス」があげられると思っております。 現在所属しているプロダクトDivではスクラムでプ
OSS開発に参加してみたい人の背中を押して回る - クラウドワークス エンジニアブログ
はじめに SREチームの @minamijoyo です。 今回は最近社内でやってる、OSS開発に参加してみたい人の背中を押して回る草の根的な活動について書いてみようと思います。 クラウドワークス は Linux / Ruby / Rails など、たくさんのOSS (Open Source Software) のエコシステムの上に成り立っています。 むしろ現在のWebサービス開発はOSSなしに開発するほうが難しいでしょう。 つまりWebサービスを開発してご飯が食べられるのも、OSSのおかげと言っても過言ではありません。かくいう私は普段業務で Terraform をいじってることが多いので、たとえば Terraform の細かいバグを直してみたり、サードパーティのツールを作ってOSSとして公開してみたりして遊んでおります。 そんなOSS活動について、周りを見渡したところ、「やってみたいけど、
WebエンジニアのチームがReactNativeでアプリをリリースした話 - クラウドワークス エンジニアブログ
@kinakobo です。 先日フィークルという新規サービスのiOS, AndroidアプリをReactNativeで開発し、リリースしました。 アプリ: iOS | Android feecle.works すでに国内でもいくつか採用事例があるReactNativeですが、まだまだ事例が少ないと感じます。 今回自分たちもReactNativeを採用したので、まずはその検討段階から紹介したいと思います。 また、開発チームはWebエンジニアのみで構成されていたため、特にWebエンジニアの方向けの内容になります。参考までに、開発チームの人数は4人でAPI側も同じメンバーが担当していました。 はじめに、ネイティブアプリを何で作るか検討した際に出た選択肢は以下の3つでした。 iOSとAndroidそれぞれネイティブのコードで書く ReactNativeを使用する Flutterを使用する 1は全く
ペアプログラミング + メンタースイッチを組み合わせてやってみた！ - クラウドワークス エンジニアブログ
テーマ：ペアプロ こんにちは、今年4月に入社した新人プログラマの@flatbaです。クラウドワークスでは、開発手法にペアプログラミング（ペアプロ）を取り入れています。 今回、既存メンバーが新人（僕）を新たにチームに受け入れるにあたって、 既存チームへ新メンバーのスムーズな受け入れ 新メンバーと既存メンバーとの早期の相互理解 スキルアップ を目的としてチーム内で ペアプログラミング + メンタースイッチ を導入して実感したメリット、実践するなかで出てきた課題とその解決の様子、 を今回のブログのテーマにします。 目次 目次 ペアプロとは ペアプログラミング + メンタースイッチ 導入してみて良かった点 ペアプログラミングによって得られた効果 メンタースイッチによって得られた効果 ペアプログラミング+メンタースイッチによって得られた効果 課題と解決の様子 あえてペアプログラミングと称する理由 ま
CircleCI 2.0に移行して新機能を活用したらCIの実行時間が半分になった話 - クラウドワークス エンジニアブログ
⠀人 / ⁰⊖⁰ \ オカメインコエンジニアの五十嵐(@ganta0087)です。 CrowdWorksでは、サービスのCI環境としてCirlceCIを利用しています。 今回、CircleCI 1.0から2.0に移行すると同時に、新機能のキャッシュをフル活用したことで、コストを増加させることなくCI実行時間を半分にすることができました。 今回の記事では、CirlceCI 2.0のメリットや、どのようなチューニングを行ったのかをご紹介します。 CircleCI 2.0について CircleCI 2.0は現在ベータ版となっており、「CircleCI 2.0: Beta Access - CircleCI」から申し込むことができます。(試してみたところ個人のリポジトリではすぐに利用できるようです。) 申請したOrganizationのすべてのプロジェクトで突然バージョンが切り替わるわけではなく、
Lambda + CloudWatch Events + KMS で AWS コンソールへの不正アクセスを秒速で検知して「平穏な生活」を手に入れる - クラウドワークス エンジニアブログ
ペルソナ5にドハマリし、先日100時間以上かけてクリアした @tmknom です。 主人公の名前は吉良吉影。怪盗団の名前はキラークイーンです。ちなみに二周目に突入しました。 さて、みなさんもご存知の通り、 AWS ユーザは常にある不安を抱いています。 AWS アカウントを乗っ取られたらどうしよう。バイツァ・ダストよろしく、すべてを吹っ飛ばされたらどうしよう。という不安です。 しかし、我々は AWS を使わずにはいられないという『サガ』を背負ってはいますが『幸福に生きてみせるぞ！』という強い意思を持たねばならないのです。 そんなわけで、意思を現実のものへと体現すべく AWS コンソールへ、いつ誰がサインインしたのかSlackに通知して、 不正アクセスを簡単に検知できる仕組みを構築してみましょう。 はじめに 事前準備 バージニア北部へリージョンを切り替え Lambda の初期セットアップ Cl
Herokuで本番サービスを運用する際にやっておきたいこと & 構成の事例 - クラウドワークス エンジニアブログ
こんにちは、最近アルコールが入っていたらなんでもいいと思うようになってきた @yo-iida です。🍻 今回はみんな大好きHerokuのお話です。 サービス立ち上げ期に大活躍するHerokuですが、CrowdWorks内でもいくつかのプロダクトで本番までHerokuで運用しているサービスがあります。 今回は私が携わっている社内プロダクトでのtipsを紹介します。 やっておきたいこと Heroku PipelineとReview appを使いこなす 本番とデータ同期できるpreview環境を追加する Heroku上のアプリケーションはすべてRAILS_ENV=productionで動かす DBのバックアップ設定をしておく Production Checkを行う アプリケーションのビルドの仕組みを知っておく 構成の事例 Standard以上のdynoを使用する ミドルウェアはHeroku公式
ソースコードの減らし方 - 基本的な考え方と10個の方法 - クラウドワークス エンジニアブログ
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
