iOSエンジニアが選ぶ、GCPをローカル開発環境で動作させるのにとても便利なツールたち

自己紹介

このブログを見ていただきありがとうございます。
Androidも少しかじりつつ、iOSエンジニアをここ数年やっておりましたハラです。

iOSエンジニアを始めてから某大手企業のアプリ等にも携わらせていただき
更にご縁もあり、ここ2年ぐらいクラウドワークスのiOSアプリ担当をしておりました。

... (過去形)

古株なエンジニアが改めてUXの回復に取り組んでいる話

まえおき

みなさんこんにちは、エンジニアの@YusukeIwaki です。2015年の春に入社してもうすぐ４年、気づけば周りのメンバーは半分くらい変わっていて、古株扱いされる身となってきました（苦笑）

半年くらい前までずっとアプリチームでAndroidアプリつくったりスマホアプリ向けのAPIを作ったりしていましたが、2018年11月ごろに、なんかの話の流れで「クラウドワーカーを探す」機能（以下、ワーカー検索）の改善をやることになり、今に至ります。

今回は、直近３ヶ月間くらいのワーカー検索の改善の中で強く意識しているUX改善に対する思いを改めて共有してみようと思います。

※ エンジニアブログにもかかわらず技術的要素は少ないかもしれませんが、あらかじめご了承ください

なぜUX改善なのか

きっかけは読書でした。

これを読み始めて、「あ、自分は "やりかた" とか "機能" にこだわりすぎているのかもしれない」と改めて思い直しました。

機能で数字は上がらない。熱心に使う人がいるから数字が上がる。

スクラムチーム内で1on1を実施した話

はじめに

こんにちは、玉露チームの @t0yohei です。 CrowdWorksに入社して5ヶ月と日は浅いですが、5万行に及ぶJavaScriptの大改修や仕事検索の表示順位改善をなどを行っています。

上記の大改修についてまとめられている記事がありますので、よろしければ合わせてお読みください。 混沌を極める jQuery のコードをいかにして Vue.js に頼らずに整理したか

CrowdWorksでは、毎年12月にアドベントカレンダーを作成しています。アドベントカレンダー明けの一発目の記事ということで、ネタがねーよ頑張って書いていきたいと思います。

自分が現在所属する玉露チームは、クラウドワーカーの、お仕事とのマッチング体験を良くすることがミッションのチームで、エンジニア3人・プロダクトオーナー1人・デザイナー1人で開発を行なっています。この玉露チームではチームビルディングの一環として2018年の11月(ブログ作成時の2ヶ月前)から、1週間に2ペアのペースで1on1を実施しています。

ちなみにチーム名の由来は、マッチングチームをもじった「まっちゃ」チームというものが過去に存在し、抹茶よりカフェイン量の多いチームということで「玉露」チームになったらしいです。(なるほどわからん)

この玉露チームで、上司と部下ではなくチームのメンバー同士で1on1を実施することになった経緯とその成果について書いていきたいと思います。 スクラムで自己組織化しているチームにおけるチームビルディングについて、何らかの知見になればと思います。

なぜ1on1実施することになったのか

実は、玉露チームは自分が入社した当時からすでにいいチームでした。そのおかげで自分が入社2, 3ヶ月でスムーズにチームに合流できたり、全社キックオフでチームMVPを取ったりしていました。

【2018年版】クラウドワークスで起きた変化とその感想まとめ8つ

この記事は、クラウドワークス Advent Calendar 2018の24日目です。

メリークリスマス！

クラウドワークスの副社長をやってる成田です。

今年もアドベントカレンダーの季節がやってきました。毎年最後の方で、クリスマスとかぶりますw

この1年も、色々やらせてもらってめちゃくちゃ楽しかった！というのが雑な感想なんですが、振り返りとしてマネジメントサイドで、これはやってみて色々あった、と思うことをキリ悪く8個(！)、まとめてみました。

この1年で起きた変化とその感想8つ

1. 役員やマネージャーでエンジニアリングマネジメントやデザイン思考の読書会が始まった

2018年マネジメント振り返り

この記事は、クラウドワークス Advent Calendar 2018の10日目です。

こんにちは、プロダクトDiv. エンジニアリング部 部長の飯田です。
エンジニア組織のマネジメントは4月からやらせていただいているのですが、この記事ではこのマネジメント観点から激動の2018年を振り返ってみたいと思います。

---

私自身のマネジメント歴としては、4月当初は2チームのマネージャーとして始まり、その2ヶ月後にはエンジニア全体をみることになり現在に至ります。

4月から10月までの半年は、プロダクト全体の施策の攻めと守りのバランスの葛藤や、現場と経営陣の価値観の差異をどうやって埋めるのかということについて頭を悩ませてきた半年でした。

思うに、組織全体で長きにわたり分析・解決が難しかった課題としては「組織の意思決定プロセス」があげられると思っております。
現在所属しているプロダクトDivではスクラムでプロダクト開発を行なっています。チームはプロダクトオーナーを中心に意思決定を行い、自己組織化した状態で開発を進めます。

しかし、ときにプロダクトDivの外で決定した方針が入ってくるケースがあります。たとえば経営陣で進めるM&Aや事業提携、ジョイントベンチャーによる新規事業などです。
こういった急な方針転換は現場にハレーションを起こすことがほとんどです。チームで最優先だと考えていたバックログがなかったことになってしまうためです。
しかしながら、経営としても資金調達力や時価総額といった観点を元に打ちだしている施策であり会社・事業を伸ばしていくために考えた上での意思決定です。
さて、このような異なる視点で意思決定されたものをどのように開発していくべきでしょうか。