いちエンジニアがファーストビューのデザインを改修した話

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

クラウドテックのエンジニアをしている久村です。 2020年5月からクラウドテックに異動し、開発をメインで担当しています。 この記事では、サービスの顔とも言えるファーストビューを改修した話ができればと思います。

クラウドテックは、ハイクラスなフリーランス IT・WEB エンジニアやデザイナーに特化したマッチングサポートサービスとして 2015年4月から始まったサービスです。

クラウドワークス開発組織と今後の取り組み

この記事はクラウドワークスアドベントカレンダー 18日目の記事です。 はじめまして。クラウドワークスでEMを担当をさせていただいている庄司です。

EMは、Engineering Managerの略で、そのままですがエンジニア組織のマネージャでして、具体的にはチーム単位での組織設計やメンバとの1on1等を通じた課題の抽出/取り組みを行い、組織を運営する役割を担っています。 今回はEMとして過ごしてきた中で、いいなと感じたことや、組織としての取り組みについて簡単にご紹介できればと思っています。

内容については、人によってご意見が色々と当然あるかなと思いますが、あくまでも私自身の今までの経験を元にした解釈ですのでそのあたりはご容赦くださいませ。

すごくざっくりと私の経歴を書かせていただきますと、大学時代、片道3時間の通学時間の読書のなかで認知心理学やアフォーダンス、ユーザビリティ等に影響を受けUI周りに興味を持ち、周りがメーカに就職してゆく中、webの開発会社に約20年前に就職しました。…が結局はそちら方向には向かわず、携帯電話のミドルウェア開発のベンチャーで上場含めての様々な開発経験であったり、上場企業の子会社でのゲームプラットフォームの立ち上げや運用、本社での事業立ち上げ等を経験させて頂きました。というようなバックグラウンドを持っております。

そんな経歴の私が、ご縁あってクラウドワークスにお世話になっている訳ですが、Webの世界にどっぷりではなかったエンジニアの視点としてクラウドワークスの雰囲気をお伝え出来ればと思っています。

開発組織で、良いなと思っていること

「発信」が組織に根付いている

まず、入社直後に驚いたのはドキュメントの量でした。プロダクト組織ほぼ全員がQiita Teamのアカウントを持っており、エンジニアに限らずプロダクトに関わるメンバが積極的に記事を書いています。その投稿内容は、サービスの機能説明・仕様・設計の経緯・障害対応の手順に限らず、サービス・システムの課題提起や、取組みへの提案なども含まれています。 私の見える範囲では記事の数は11,530本、Qiita以前に利用されていたConfluenceも含めるとかなりの量の記事が社内に公開されています。ルール化はされていませんが、投稿を皆さんチェックしていて、役割関係なくリアクションやコメントも積極的にされており、それがコミュニケーションの一部になっているように思います。

クラウドワークスには、クラウドワークスの重視する価値観や行動の基本が書かれた「カルチャーブック」という文章があり、その中の一つの項目に下記があります。 「成果＝結果＋伝達」 成果は結果だけでなく伝えることも大切という内容ですが、こういった考え、文化が定着している結果なのかもしれません。 常に新しい情報が投稿され続けることが当たり前になっていることは、すごいことだと思います。

あと、発信という意味では、アドベントカレンダーも自発的にメンバ内で準備を進めてくださいました。エンジニアに限らずPO、デザイナが協力してカレンダーを作り上げているのは、発信に加えて、クラウドワークスっぽい仲の良さが現れているんじゃないのかなと思います。

サービスの成長モデルを定義し、「森も見ながら木を見る」プロダクトマネジメントへ

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

はじめまして、プロダクト開発部にて、crowdworks.jpのプロダクトマネジメントを担当している西村（通称チャンタマ）です。

突然ですが皆さんのサービスでは、KPIをどのように定めていますか？

一般的には、事業部全体の売上目標から因数分解して、特定の指標（会員登録数・継続率など）をKPIとしておくことが多いかと思います。 crowdworks.jpの開発チームでも、長らくそのようなKPIの立て方をしていました。

しかしながらサービスの特性や組織設計も関係して、様々な弊害が生じるようになりKPIの立て方を見直す必要性を感じるようになりました。

したがって今期からは、サービスの「成長モデル」を定義し、サービスが抱える様々な問題に対してどのように優先度をつけていくか、その開発スタイルも考え直してみました。

今回は成長モデル作成のプロセスと背景をご紹介します。

複数の開発チームを抱えるプロダクトマネージャーの方、サービス全体の開発方針、優先度の意思決定をする立場にある方などに参考にしていただけると嬉しいです。

SREチームに入ってからの2年間にチームでやってきたこと

この記事はクラウドワークス アドベントカレンダー6日目の記事です。 前日の記事は@bugfireのgithub-script は便利でした。GitHub Actionsでのちょっとした作業が捗りますね！

SREチームの@kangaechuです。 気がつくと入社から2年が経ちました。2年前のAdvent Calendarでは ぴよぴよSREという記事を書くくらい何もわかっていませんでしたが、ようやく自分なりに動けるようになってきました。 この記事ではcrowdworks.jpのSREチームで、この2年間でどのようなことをやっていたのかを振り返ります。 SREチームの範囲は幅広く、いろいろなことをやっていました。今回はDocker化とTerraformの2つの取り組みについてご紹介します。

なんで1年じゃなく2年かって？去年はaws-vault についてのあれこれを書いたからだよ。

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

はじめに

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

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

---