開発支援チーム

インフラ/DevOps/SRE

株式会社うるるでは、CGS(Crowd Generated Service)という概念の下、クラウドソーシングで働くワーカーを活用した事業作りと事業運営をしています。
同時に、事業運営することでワーカーに対して仕事を提供していく役割を果たしています。

運営しているサービスは様々、複数存在します。
その中で事業推進チームでは、
複数サービスにおけるインフラ戦略の共通化を図ることでスピーディーなローンチを実現
DevOpsとしての観点によってアプリケーションを担当するエンジニアの生産性を最大化
SREとしての観点によってサービスの安定稼働を実現
といったミッションを持っています。

メンバー

インフラエンジニア
@KsntsTt

インフラエンジニアとして各事業部のインフラ面で支援しております。事業部を跨いで働くチームなので、どのチームよりも多様な技術や言語に触れることができるチームです。また弊社サービスへの支援だけでなく、アカウント管理の自動化による省力化やインフラのコード化による統制対応、全サービスのログ集約・分析基板構築などエンジニアとしてだけでなく、ビジネスマンとしてより経営層に近い立場で自身の技術力を活かせる環境です。まだ規模の小さいチームですが将来的にはもっと大きくしてSREチームとDevOpsチームを確立し、より事業全体へ良い影響力を発揮できるチームへ成長させてくれる方とご一緒できたらと思うと楽しみです。


開発チームからのメッセージ

我々はWebプロダクトを保有し、それを軸にビジネス展開をしている会社なので、事業の成長にコミットし、貢献できるエンジニアと一緒に働きたいと思っています。
貢献の仕方は人それぞれ、得意分野を活かせば良いと考えています。
その中でこの事業推進のチームは、他のエンジニアの仕事のし易さを向上することで組織のアウトプットを高めていくチームだと考えています。
組織の動きを見た上で、より効果的な動き方をできるような設計をするような考え方を持てる方だときっと活躍頂けると考えています。


クラウドワーカーを活用した事業を行う会社(クラウドソーシング、入札情報速報サービスなどを運営)


利用技術・開発環境

AWS
NewRelic
Beanstalk
CloudWatch
CloudFront
Terraform
Datadog
Aurora
ECS-Fargate
GitHub
Jenkins
Docker
CircleCI2.0

その他チャットやタスク管理などのツール

PivotalTracker, Slack

自動化していること

開発環境構築
Lint
テスト
デプロイ

継続的に実践していること

Infrastructure as Code
スクラム
ペアプロをしている
モブプロをしている
事業数値をチーム全体に共有している
毎日チーム全体で状況共有をしている
定期的に振り返りを行っている
評価制度がある

コードレビューについて

設計に踏み込んだコードレビューをしている
可読性を意識したコードレビューをしている
バグが出ないようにコードレビューをしている
優先度が低くあまりできていない
体制、環境上できていない

技術的負債について

技術的負債の返済を重視し、迅速に返済している
定期的に技術的負債の返済をしている
既存実装に手をつけるタイミングで必要に応じて技術的負債の返済をしている
現在は優先度が低いため技術的負債の返済をあまりしていない
技術的負債の返済をする必要がない

テストについて

高いテストカバレッジを目指している
テストコードを当たり前に書いている
サービス運営上またはビジネス上重要な部分についてのみテストを書いている
基本的に手動でテストしている
テストを書く必要がない・または少ないプロダクトだ

チーム全体での開発の進め方

<次に作るものはどうやって決められるか>
各アプリケーション開発チームにおいて、相談があがってきます。
また、Slackのやり取りからアプリケーション開発チームが苦労していることや直面している困難を発見することがあります。
それらの内容を基に、優先順位、技術的な仕様を決定して実装に取り掛かります。

<コードレビュー>
GitHub の Pull Request をベースに、エンジニア同士でレビューを行っています。基本的に1名から OK が出ればマージ可能としていますが、仕様・動作確認や自動テストを通過していないとマージされないように自動化しています。
また実装に悩むところがあれば、ペアプロや対面レビューなども活用しています。

技術面でのアピール・課題・考え方

基本的には「3度同じことを繰り返すのであれば自動化しよう」「楽できることは楽をしよう」「楽をするためにお金を遣う」といったマインドで仕事に取り組みます。
 
例えば、コードレビューで不要な議論がうまれないように、または人が介在する意味のないことに時間を使わずに済むようにするためにCIツールを組み込むといった考え方をしています。
また障害時の調査にsshすることは不毛なので必要なログを引っ張れる仕組みをJenkinsで構築したりもします。
 
こういった考え方に基づいて仕事はしていますが、それでもまだまだ課題はあります。
例えばソフトウェアのにおけるメトリクスを数値化できていないような部分も残ったり、CIのフローに乗せられずに一部手作業が発生もしています。
こういった部分に対して組織を広い目線で見ながら改善に動いていきたいと考えています。


求人一覧

開発支援チーム

インフラ/DevOps/SRE

株式会社うるるでは、CGS(Crowd Generated Service)という概念の下、クラウドソーシングで働くワーカーを活用した事業作りと事業運営をしています。
同時に、事業運営することでワーカーに対して仕事を提供していく役割を果たしています。

運営しているサービスは様々、複数存在します。
その中で事業推進チームでは、
複数サービスにおけるインフラ戦略の共通化を図ることでスピーディーなローンチを実現
DevOpsとしての観点によってアプリケーションを担当するエンジニアの生産性を最大化
SREとしての観点によってサービスの安定稼働を実現
といったミッションを持っています。


クラウドワーカーを活用した事業を行う会社(クラウドソーシング、入札情報速報サービスなどを運営)


利用技術・開発環境

AWS
NewRelic
Beanstalk
CloudWatch
CloudFront
Terraform
Datadog
Aurora
ECS-Fargate
GitHub
Jenkins
Docker
CircleCI2.0

その他チャットやタスク管理などのツール

PivotalTracker, Slack

自動化していること

開発環境構築
Lint
テスト
デプロイ

継続的に実践していること

Infrastructure as Code
スクラム
ペアプロをしている
モブプロをしている
事業数値をチーム全体に共有している
毎日チーム全体で状況共有をしている
定期的に振り返りを行っている
評価制度がある

コードレビューについて

設計に踏み込んだコードレビューをしている
可読性を意識したコードレビューをしている
バグが出ないようにコードレビューをしている
優先度が低くあまりできていない
体制、環境上できていない

技術的負債について

技術的負債の返済を重視し、迅速に返済している
定期的に技術的負債の返済をしている
既存実装に手をつけるタイミングで必要に応じて技術的負債の返済をしている
現在は優先度が低いため技術的負債の返済をあまりしていない
技術的負債の返済をする必要がない

テストについて

高いテストカバレッジを目指している
テストコードを当たり前に書いている
サービス運営上またはビジネス上重要な部分についてのみテストを書いている
基本的に手動でテストしている
テストを書く必要がない・または少ないプロダクトだ

メンバー

インフラエンジニア
@KsntsTt

インフラエンジニアとして各事業部のインフラ面で支援しております。事業部を跨いで働くチームなので、どのチームよりも多様な技術や言語に触れることができるチームです。また弊社サービスへの支援だけでなく、アカウント管理の自動化による省力化やインフラのコード化による統制対応、全サービスのログ集約・分析基板構築などエンジニアとしてだけでなく、ビジネスマンとしてより経営層に近い立場で自身の技術力を活かせる環境です。まだ規模の小さいチームですが将来的にはもっと大きくしてSREチームとDevOpsチームを確立し、より事業全体へ良い影響力を発揮できるチームへ成長させてくれる方とご一緒できたらと思うと楽しみです。

開発チームからのメッセージ

我々はWebプロダクトを保有し、それを軸にビジネス展開をしている会社なので、事業の成長にコミットし、貢献できるエンジニアと一緒に働きたいと思っています。
貢献の仕方は人それぞれ、得意分野を活かせば良いと考えています。
その中でこの事業推進のチームは、他のエンジニアの仕事のし易さを向上することで組織のアウトプットを高めていくチームだと考えています。
組織の動きを見た上で、より効果的な動き方をできるような設計をするような考え方を持てる方だときっと活躍頂けると考えています。


チーム全体での開発の進め方

<次に作るものはどうやって決められるか>
各アプリケーション開発チームにおいて、相談があがってきます。
また、Slackのやり取りからアプリケーション開発チームが苦労していることや直面している困難を発見することがあります。
それらの内容を基に、優先順位、技術的な仕様を決定して実装に取り掛かります。

<コードレビュー>
GitHub の Pull Request をベースに、エンジニア同士でレビューを行っています。基本的に1名から OK が出ればマージ可能としていますが、仕様・動作確認や自動テストを通過していないとマージされないように自動化しています。
また実装に悩むところがあれば、ペアプロや対面レビューなども活用しています。

技術面でのアピール・課題・考え方

基本的には「3度同じことを繰り返すのであれば自動化しよう」「楽できることは楽をしよう」「楽をするためにお金を遣う」といったマインドで仕事に取り組みます。
 
例えば、コードレビューで不要な議論がうまれないように、または人が介在する意味のないことに時間を使わずに済むようにするためにCIツールを組み込むといった考え方をしています。
また障害時の調査にsshすることは不毛なので必要なログを引っ張れる仕組みをJenkinsで構築したりもします。
 
こういった考え方に基づいて仕事はしていますが、それでもまだまだ課題はあります。
例えばソフトウェアのにおけるメトリクスを数値化できていないような部分も残ったり、CIのフローに乗せられずに一部手作業が発生もしています。
こういった部分に対して組織を広い目線で見ながら改善に動いていきたいと考えています。


求人一覧

公開中の求人はありません