ランサーズ（Lancers）エンジニアブログ > ohira.koki の記事

投稿者「ohira.koki」のアーカイブ

上期の振り返りとOKR 「いま4月に戻ったら？」

ohira.koki｜2023年09月29日
PM

ランサーズのエンジニアの大平です 🙋‍♂️

この上期にプロジェクトのオーナーとして行動した振り返りを書きます
書いてみると、OKRを用いたプロジェクトマネジメントの振り返り、になりました

月並みな意見ではありますが、どなたかの参考にはなればです

振り返り

上期の振り返りを一言で表すと

リリースはもっと早くできた
もっと早くできれば、その時間でより重要な課題と向き合えた

です

以下に、そう感じた理由と、今後のTryを書いてみます

1. OKRは定めた方がいい、Oはあるべき状態

  • Oはあるべき「状態」を定める、定性的なもの、pj初期では考えすぎない、少し願いを込める
  • KRはそれを実現するための要素、定量的に、MECEに、達成基準について共通認識が作れるようにする
  • KRの下には、その達成に向けたマイルストーン・課題がいくつかぶら下がってる

というのがOKRというフレームワークだと感じました (模範解答)

Objectiveは組織・プロダクトのあるべきと同じ方向を向き、その上でpjが達成したいあるべき状態を示す、が大事だと思います

2. KR・マイルストーンはチューニングする。課題の大きさ・重要度は変化する

  • pjを進めると課題やゴールの解像度が上がる
    初期は大きな課題と考えていたことも、解像度が上がると実はそうでもなくて、それより重要な課題が分かったりする
  • その状態で今1度優先度を検討する、過大にも過小にも見積もらない
  • その比較を通して、今1番重要なことに時間が使う、Objectiveを達成するために

当たり前のことを書きましたが、振り返るとこれが1番できておらず、そしてこれが1番大事だと思いました
かつこれができていれば、もっと早くリリースできて、もっと重要な課題に向き合えてたかもしれない、と感じてます

メンターの聡さんには「常に現在地を確認する」って表現で教わっていましたが、本当にその通りでした、難しい。

3 – 1. マイルストーンは具体的なアウトプットにする

  • マイルストーンをアウトプットにする = ゴールを明確に定義する
  • ゴールを明確に定義すると、スコープを決められる
  • ゴールを明確に定義すると、何故か見えてない課題やMoreな部分が見えてくる

3 – 2. アウトプットは必要なもののみにする

  • アウトプットはMVPに留める、本当にMinimumか？本当に価値はあるか？は問う
  • 作っても使われない、は社内外であり得る (社内ドキュメントとか)
  • 「ここにも影響がある・課題がある」と理解できていれば、あとは優先度の問題、段階的に改善すれば良い

3 – 3. マイルストーンは他者と共通認識をつくる

  • pjの現状を1番理解しているのは自分、その上で他者とやることの共通認識を作る・提案する
  • 共通認識があると、FBを得やすい
  • 共通認識があると、その差分から協力を得やすい

3の部分はOKRのフレームワークで言うとマイルストーンの部分で、やって良かったことと気づいたことです

3の行動をもっと早くできていたら、気づきを早く得られて、2を上手くできるようになってたかもしれないと感じてます

まとめ

全体のまとめとしては

1の内容は、やって良かったことで、あまり難しくない、というか正解がないようなことだと思っていて、
2の内容は、振り返るとできてなかったことで、かつ1番大事だと思うことです
3の内容は、やって気づいたこと・良かったことで、ここは具体的に改善できる粒度なので、今後に活かしていきたいです

多分3ができれば、2のKRのチューニング・現在地の確認はもっと上手くできるようになると思ってます

他にも課題は残る状態ではあるけれど、KR・マイルストーンのいくつかは解消でき、Objectiveに近づけられたのはGoodだと思うので、今後も頑張っていきたいと思います

最後までお読みいただきありがとうございました 👏

[Lancers × coconala] Tech meetup Vol.1を開催しました ! @AWS Startup Loft

ohira.koki｜2023年03月14日
イベント／登壇

こんにちは、プロダクト開発部の大平 (@kokitecture)です
最近はちょっただけElasticsearchに変更を加えられるようになってきました (ちょっとだけ)

この記事では1/26 (木)に行った、ココナラさんとのLT・交流会「Tech meetup Vol.1」の様子をご紹介したいと思います！

記事内にLTのスライドを展開していますので、気になるものに是非目を通してみてください

イベント概要

テーマ

今回のイベントは以下のようなテーマで行いました

  • 自由なテーマで交流するフリーなLT大会
  • 発表時間は質疑含めて8分
  • 登壇者は計10名 (ココナラさん4名 + ランサーズ6名)

また今回のイベントはオフラインで開催し、会場はAWSさんオフィスにて開催させて頂きました

新卒の自分は初めてのオフラインイベントでしたが、皆さんの表情が分かる分会話も弾み、とてもワイワイした雰囲気で楽しかったです！
AWSの皆様には会場のご用意から、当日のイベント進行までして頂きました、ありがとうございました

https://aws-startup-lofts.com/apj/loft/tokyo

coconala とは

ココナラさんは 一人ひとりが「自分のストーリー」を生きていく世の中をつくる というビジョンに向け「知識・スキル・経験」を売り買いできるスキルマーケット、coconalaを提供されています

ココナラさんとランサーズは共に「個をエンパワーメントする」というミッションを掲げており、その実現に向けて共に業界を盛り上げていきたいと思っています

そんな共通点もあり、プロダクトや開発組織に関する共通項は多く、今回のイベントは発表も雑談もとても盛り上がりました

トップページ

LT 発表内容 スライド

本イベントの発表内容は以下のようになっています
ランサーズメンバーのスライドに関しては、以降に添付されてますので、気になるものは是非読んでみてください

新生インフラ・SREチームの取り組み ココナラ 吉川さん
カレンダー機能をどう作ったか ココナラ 光吉さん
アプリのE2Eテストの取り組みの話 ココナラ 勘舎さん
WebのE2Eテスト自動化〜ツール選定編〜 ココナラ 鈴木さん
ランサーズ紹介、利用アーキテクチャ、組織・フリーランス連携紹介 ランサーズ 倉林
ランサーズSRE – 1年間の取り組みとこれから ランサーズ 日吉
IDEをどこまで使いこなすべきか（哲学） ランサーズ 五十嵐
言語モデルの変遷と応用事例など ランサーズ 友利
仕事連動型・教育サービス始めました。 ランサーズ 磯野
プロダクトオーナーとして経験した2つの失敗と学び ランサーズ 大平

ココナラさんは、大きく、SREチーム取り組み / 新機能について / E2Eテストについて、4名の方が発表されていました！

SREチームに関する発表ではインフラに関する現状や課題感など、弊社メンバーも特に共感できる点が多かった印象です。(笑)

新機能のカレンダー機能については、coconalaに必要な要件とそれに最適なデータ構成はどれか、といった発表をされてました。改めてカレンダー機能は要件が複雑でしたが、作るのは楽しそうだな、と思いました！

E2Eテストに関しては、テストが導入されたことで、リリース前や早期タイミングでバグを検知できており改めてE2Eテストの重要性を感じました！
WebのE2Eテスト導入に関しては、様々なテストツールを比較された内容とその結果について発表されており、ツール選定に関してとても勉強になりました！

ランサーズ紹介、利用アーキテクチャ、組織・フリーランス連携紹介

こちらはVPoE 兼 プロダクト開発部/BPR推進部 部長 の倉林さん (@terukura)の発表です

トップバッターとして弊社のサービス紹介とランサーさんと連携した組織体制について発表されていました。プロダクト開発部もランサーさんに協力して頂いて開発を進めていますが、その独自性についてはココナラさんも驚いてました。

ランサーズSRE – 1年間の取り組みとこれから

こちらはプロダクト開発部 アーキテクトチーム MGR の日吉さんの発表です

SREチームによるサーバーのコンテナ化から、現在の課題や取り組みについて発表されていました。いつもお世話になってます、本当にありがとうございます (笑)
最近はインフラに関するドキュメントも徐々に蓄積され、知識の属人化がなくなってきています、目指せ逆Embedded SRE！

IDEをどこまで使いこなすべきか（哲学）

こちらはプロダクト開発部 プロダクト開発部 アーキテクトチーム フロントエンド テックリードの翔さん (@syo_igarashi)の発表です

EclipseからAndroid Studio, Xcode, VSCodeとIDEの変遷と、IDEの環境構築とどこまでやるかについて発表されてました
また翔さんが開発されたstylelintやESLint、textlintについても紹介されており、もうIDEなしでは開発できないな、って思いました (笑)

言語モデルの変遷と応用事例など

こちらはプロダクト開発部 アーキテクトチーム AI/データ テックリード 友利さんの発表です

言語モデルの概要からその仕組み、最近話題のChatGPTについて発表されています
機械学習への理解が浅い自分でも分かりやすく、将来予想なども言及されており、とても面白かったです！

仕事連動型・教育サービス始めました。

こちらはプロダクト開発部 新規事業開発チーム 磯野さん (@wadakatu)の発表です

弊社の新規事業である、Lancers Degital Academy について紹介されています
「学び直し」が注目される現代において、実務で活かせる技術を学べる教育サービスを提供しています、気になる方は是非！

https://lancers.academy/

プロダクトオーナーとして経験した2つの失敗と学び

こちらはプロダクト開発部 プラットフォーム開発2 大平 (@kokitecture)の発表です

内容としてはここ約3ヶ月でPdMに近い役回りをして得た失敗と学びについてです
今思えば当たり前のことばかりですが、この数ヶ月の経験に発表しました。個人的には考えてることをちゃんとスライドで表現することにも力を注いでみました！

当日の様子

さいごに

 

今回のイベントは、両社事業内容や組織としての課題など共通項が多く、またAWSさんのご協力でオフラインでできたこともあり、とても盛り上がったイベントになりました！

また弊社は現在ミッションやビジョンに共感頂けるメンバーを募集しております！ 一緒に働きたい・話を聞いてみたいという方は、是非カジュアルにお声がけ下さい！

採用サイト：https://www.lancers.co.jp/careers/

最後までお読みいただき、ありがとうございました！

課題分析からリリース、結果分析までサイクルを回して学んだ3つのこと

ohira.koki｜2022年12月14日
アドベントカレンダー

プロダクト開発部のエンジニアの大平 (@kokitecture)です。

最近は散歩する時に、わざとゆっくり歩くのにハマってます、なんとなく気持ちが落ち着きます。

この記事は Lancers Advent Calendar の14日目の記事です。

昨日は友利さんの「トピックモデルでランサーズのデータを文書分類をしてみる」でした。機械学習に疎い自分としては、流石友利さんって感じでした。

はじめに

自分は下期から、施策の課題策定からリリース、結果分析までの一通りの作業を担当させて頂いています。

この記事ではその中で学んだ3つのことを共有したいと思います。今思えば当たり前のことが多いですが、反省も含めてどなたかの参考になれば幸いです。

1. 大通りから攻める、がそこは本当に大通りか？

ここでの内容は、課題策定や施策考案する上での行動原理のような話です。

課題分析や施策考案する上で、重視すべき指標の1つとして「そこが大通りかどうか」は認識すべきだと考えています。

ここで言う「大通り」とは、サービスにおける重要な機能や画面のことを指しています。
そこに力を加える方が効率的だと考えているので、この指標を意識しながら分析や設計などを行なっていました。

参考
・#13 神は順序に宿る
・グロースの逆説 : メルカリで分析とサービスグロースをやる前に知りたかったこと

ですが、、

それらを認識しつつも、自分は「大通り」を勘違いしていました。なのでそれに関して反省も含めた学びをここに共有します。

① 「入り口」が1番の大通りとは限らない

自分が企画考案し始めた時、まず提案したのがパッケージトップページのUI改善でした。理由はトップページであり、ユーザーはそこを起点に流入していると考えていたからです。

しかし、実際のPVを確認してみると、トップページはパッケージ関連のページの中でもPVは多いほうではあるが、それよりもPVの多いページはいくつかありました。

「入り口」が1番の大通りと言うわけではなく、その先にユーザーの関心が高いページがあったのです。

大通りかどうかは、ユーザーの行動・事実ベースで判断すべき、だと言うことを学びました。

② 「全体の」大通りかどうか

次に、上記の学びを踏まえてパッケージ関連のページでPVの多い (大通りの)画面の課題解決を考え始めました。

しかし、いくつかの分析とチームと会話する上であることに気づきました。

自分が提案したページは、パッケージ関連においてはPVが多い方でしたが、プラットフォーム全体を見渡すと同程度のPVのページはいくつかありました。

「大通り」と言っても、基準をどこに置くかで判断が変わるということです。時には全体を俯瞰して比較することも大事そうです。

まとめ

ここでの話をまとめると以下について学びました。

  • 大通りは事実ベースで確認すること
  • 大通りを何を基準とするかで判断が変わること

今後も施策を検討する上ではこの学びを活かしつつ、そこが大通りかどうか判断していこうと思います。

2. その判断は正確か、数字の構成と奥行き

ここでの内容は主に数字の正確性についてです。

企画考案・設計をする際に、クエリを書いた分析をよく行います。日々クエリを書いている中で、少し数字の見方を知ったので、ここではその学びについて振り返ります。

ただ書いていて説明が難しかったので、ここでは「ECサイトにおける検索」という具体例を使って説明しようと思います。

① 数字の構成について

例えば、「検索したユーザーが商品を閲覧する割合」を明らかにしたいとします。その時に「検索結果一覧」→「商品」への遷移率が50%だったとします。

高い数字ではないので、この数字から「検索結果に課題がある」と判断できるでしょうか？

個人的にはこの数字だけを見て判断するのは賢明ではないと考えていて、その数字が何で構成されているのか、もう一歩先を明らかにしてから判断すべき、だと今は考えています。

この場合だと「検索したユーザー」の構成をもう少し詳細にできそうです。

これを見ると「検索結果に課題がある」と言うよりは、「画面Aからのユーザーには需要が低い」といった判断ができそうです。

こういった形で、データの構成を明確にすることで判断が変わる、と言ったことを学びました。

② 数字の奥行きについて

続いて、先ほど「画面Aからの検索ユーザー」の閲覧率の改善に取り組むとした時、次はどんな数字を明らかにすべきでしょうか。

いくつか候補はあると思いますが、その1つとして「検索回数」があると考えています。

上記の場合、画面Aのユーザーに対して「需要が低い」という判断から
「需要は高いが、どんな文言で検索すれば分かっていなそう」などの仮説が挙げられそうです。

このように「xxの数字が低い」と言った場合でも、その行動の回数や頻度といった数字の奥行きまで考慮すると、解像度や判断基準が変わってくる、ということを学びました。

まとめ

ここでの話をまとめると以下について学びました。

  • 数字は、その構成まで明らかにすることで判断が変わる
  • 数字は、その奥行きまで考慮することで判断が変わる

恐らくもっと見るべきステータスや構造などは色々あると思います。これからも色々と手を動かして気づきや学びを得て行きたいと考えています。

3. やっぱり最高か最速か

ここで書く内容は半ば感想のような話です。

アジャイル開発 / MVP / やっていき、と何かと物事を実行する妥当性とその「速さ」について語られることが多い気がします。

Lancersの行動指針、LWayの1つにも「アクション・アジャイル」というものが含まれています。(少し前は「最高か最速か」というものがありました)

始めは「速さ」の重要性について理解できていませんでしたが、今期から色々担当するに当たり「なぜ重要か」が少し理解できたので共有します。

① 土台がないことには会話が生まれない

自分が企画考案し始めた時、正直はじめの方は (今でも?)色々と解像度が低く、的が外れていたものも多かったと思います。

それに対してはチームからFBを頂き、その会話を通して、新しい見方なども教えて頂きました。その結果解像度が上がり、いくらか的を射たものにできたかな、と感じています。

この「手順」に速さの重要性があると思っています。

人間の性質として、何か成果物があると、それにFBやレビューをしたくなるものだと思います。

ただし、そのためには会話の発端となる、何かしらの成果物が必要です。しかもそこで重要になるのは、恐らく「質」ではなく「速さ」です。

といったように、施策の質や解像度を効率的に上げるために「速さ」は重要な指標だと感じました。

② やってみないことには気づきを得れない

自分が企画考案する際、いくらか仮説とKPIを持って話を進めています (意識はしてます)。ここを改善すると、恐らくこの数字が伸びるだろう、と言った風に。

ただ実際に一通り経験してみると、そこまで予想通りに数字は動いてくれません。

ではそれが失敗だったのかと言うと、そうではなくて、分析をすると意外な数字が変化していることに気づくことがあります。

この「気づき」に速さの重要性があると思っています。

仮説や予想を掲げても、良くも悪くも予想外の変化は発生すると思います。 ただそこから気づきを得られば解像度が上がります。しかしその気付きは、一旦リリースしてみることでしか得られません。(「不確実性」と言うやつでしょうか)

「気づき」を効率的に得るために「速さ」は重要な指標だと感じました。

上記のような経験を通して、どの段階においても「速さ」は重要な指標なのだということを学びました。(質も重要だと理解した上で)

さいごに

今期からは色々と幅広く経験させて頂いていますが、やっぱり「知る・分かる・やる」は違うな、と感じてます。

今後もぐるぐる動き回って、色々学んでいければと思ってます。

明日のアドベントカレンダーは新卒同期の高橋くんです。社内でクワッスに似てると言われている高橋くんです。

最後まで読んでいただきありがとうざいました。

ランサーズ開発合宿2022 ① Amazon Comprehendを用いたSlackチャンネルの感情分析アプリ

ohira.koki｜2022年11月02日
イベント／登壇

1. はじめに

プロダクト開発部の大平 (@kokitecture)です！

この記事では、10月に開催しましたランサーズ開発合宿2022のレポートを書こうと思います！

今回の開発合宿では、いくつかのチームに分かれてアウトプットを行いました。なので今後それぞれのチームレポートを公開していく予定です。

今回はその第1弾となります！

2. ランサーズ開発合宿2022 概要

まずはランサーズ開発合宿2022の概要を紹介します

ランサーズの開発合宿は、3年ぶりで、今回が6回目となります！コロナも少しずつ収まってきて、久しぶりのオフラインでの集合になりました！

以下が概要です。

テーマ 未来へのアウトプット
スケジュール 1泊2日。チェックアウト前の1時間で発表を行いました。
参加人数 22人 (エンジニア/デザイナー/PdM/etc..)
場所 熱海。とても風情のある旅館でリフレッシュに最適でした ○
アウトプットについて 2~4人のチームに分かれ、それぞれ自由にアウトプットを行いました。成果物・発表の形式も各チームにお任せです！

普段は違う場所・違うチームで働くメンバーとも顔を合わせ、会話も弾み、楽しさ満点の時間でした。中には初顔合わせの方もいたりして、やっぱオフラインも大事だな〜。

3. チーム成果: Slackチャンネルの感情分析アプリ

発表スライド: 長峰謙さんによるToday’s Report

では、ここからは自分達のチームのアウトプットを共有します。

自分達のチームは、Slackチャンネルの感情分析アプリを作成しました！

チームメンバーは以下の3人で、それぞれの得意領域を活かそうと考えた結果それになりました。(下画像の手前3人)

仕様説明

ランサーズでは分報チャンネル、timesと言う、その日やることや気づいたことなど、自由に呟くチャンネルを1人ひとつ持っています。

今回作ったアプリでは、この分報チャンネルから、そのチャンネルのオーナーがその日に呟いたコメントを抽出し、その日1日の感情分析を行うものを作りました。
以下が実際の動作です。分析結果に対して、Botが気の効いたコメントを返してくれます。

注: 動作確認のためにわざとネガティブなコメントをしています (笑)

レスポンスがランダムなので、毎日違う返答が帰ってきます

構成紹介

アプリの構成は以下のようになっています。メインの処理はGASで書き、感情分析の部分はAmazon Comprehendを利用しています。

Amazon Comprehendの詳しい仕様はこちらをご確認下さい！https://aws.amazon.com/jp/comprehend/

以下が実際にAmazon Comprehendにリクエストを投げている部分になります。
引数textListにその日の投稿を与えており、レスポンスにはPositive, Negative, Neutrul, Mixedの4項目の数値がそれぞれ返ってきます。それらの数値を計算し、その感情に合わせたコメントを返すようにしました。

function predictSentiment(textList){
  AWS.init("XXXXX", "XXXXXX");

  const req = {
    service: "comprehend",
    region: "ap-northeast-1",
    action: "Comprehend_20171127.DetectSentiment",
    method: "POST",
    params: {},
    headers: { "Content-Type": "application/x-amz-json-1.1" },
    payload: { LanguageCode: "ja", Text: textList.join(" ") },
  }
  
  const res = AWS.request(
    req.service,
    req.region,
    req.action,
    req.params,
    req.method,
    req.payload,
    req.headers
  );

  if(res.getResponseCode() < 200 || res.getResponseCode() >= 300){
    throw new Error("Amazon Comprehend DetectSentiment API の呼び出しでエラーがでました。" + JSON.stringify(res));
  }

  return {
    code: res.getResponseCode(),
    headers: res.getHeaders(),
    payload: JSON.parse(res.getContentText()),
  };
}

参考: https://akkinoc.dev/posts/2022/05/18/google-sheets-with-amazon-comprehend/

発表の様子

4. さいごに

いつもとは違う場所で、まとまった作業時間を確保でき、チームビルディングも含め開発合宿はとても濃い時間を過ごせました！

これから順次開発合宿レポートが展開されていく予定です。それぞれのチームのアウトプットは結構質が高かったので、是非そちらもお読み頂ければと思います！

最後までお読みいただきありがとうございました！

[Lancers x dip]第1回 Engineer Meetup を開催しました！

ohira.koki｜2022年07月01日
イベント／登壇

プロダクト開発部所属の22卒エンジニアの大平 紘基(@kokitecture)です。今年はじめに開発言語を Rails から CakePHPに変更して最近やっと慣れてきました。

この記事では、6/29 (水)に行ったdipさんとのコラボイベントの様子をご紹介したいと思います！

dipさんとランサーズは両社とも「仕事」を一つの軸に、長年ご利用いただいているプロダクトを運用している企業です。今回のイベントでは、そんな開発組織の生産性やコードの品質管理など、プロダクト開発の土台に関するテーマが発表の中心になっています。

それではよろしくお願いします！

タイムスケジュール

今回のイベントは、以下のようなタイムスケジュールで実施しました。

企業紹介（10分）

  • dip について
  • ランサーズ について

勉強会（15分 × 6）

開発組織の生産性を可視化する。State of DevOpsとFour Keysとは ランサーズ / 三宅 勇魚
CakePHPの内部実装から理解するPSR-7 ランサーズ / 久保 路
Lancersをコンテナへ本番移行する取り組み ランサーズ / 安達 涼
大規模プロダクトにLinterを導入し運用している話 dip / 大塚 裕紀
バイトルPROソフトウェアアーキテクチャ再設計の取り組み dip / 米田 宏
適正企業を見つける思考術 dip / 戸村 裕樹

クロージング（10分）

以下でそれぞれの詳細を紹介していこうと思います！

企業紹介

はじめにdipさんとランサーズ、両社の会社説明をしていただきました。

dipとは

まずはdipさんの システム開発2部の部長 山本 直希さんから、サービスと会社の概要を説明して頂きました。

ビジョンに関しましては以下のように掲げており、労働力における課題解決に強く情熱を持ったメンバーが在籍しているそうです。

サービスに関しましては、労働力のマッチングサービスに加え、労働環境の改善に向けAIやRPAサービスも提供されています。

ランサーズとは

次にランサーズのプロダクト開発部 部長/VPoE の倉林さん (@terukura) から、サービスと会社の概要を説明して頂きました。

ビジョンに関しましては以下のように掲げており、「個のエンパワーメント」というMissionに向け、企業様と個人に向けてそれぞれ定義しています。

サービスに関しましては、「働く」という営みを切り口に、プラットフォームやエージェント業に加え、最近では学び・教育という観点からLancers Digital AcademyやMENTAも提供しています。

勉強会

いよいよメインである、それぞれの発表のスタートです！

  • 開発組織の生産性を可視化する。State of DevOpsとFour Keysとは

1人目は、Lancersのプロダクト開発部 Q/Aチームから、三宅 勇魚さん(@isanasan_)に登壇頂きました。

登壇内容としましては、毎年世界中から組織のパフォーマンスデータを収集・分析したレポートである State of DevOps を参考に、開発組織の生産性のモニタリングする方法についてお話されていました。

Four Keys とは上記スライドにある4項目であり、これらは組織のパフォーマンスと相関関係があることが証明され、組織の生産性を可視化におけるデファクトスタンダードとなりつつあるそうです。

発表後半では「Four Keysを利用した生産性改善をどうやって運用に乗せるか」について、「信頼貯金」と話されているのが印象的でした。現在社内では指標が可視化され始めており、これらの改善について自分も少しずつ意識していこうと思いました。

組織の生産性において大事なのは、どれだけ開発フローがスムーズに流れているのかということ、デリバリと組織のパフォーマンスには因果関係にあるということ。この発表を聞いて、これまで部会などで話されている生産性改善の試みに関して、改めて背景や目的について知ることができ、とても腹落ちしました！

  • CakePHPの内部実装から理解するPSR-7

2人目は、Lancersのプロダクト開発部 Q/Aチームから、久保 路さん (@amamanamam)に登壇頂きました。

登壇内容としましては、CakePHPにおける$this->request への疑問をきっかけとして、フレームワークにおけるHTTPメッセージの仕組み理解と、その過程における内部実装の深掘る面白さについて話されていました。

今回のスライドの中心になっているPSRは、フレームワークの相互運用性を高める為に定義された規約であり、中でもPSR-7はHTTPメッセージのインターフェースについて定められているそうです。

PSR-7についての詳細はスライドに記載されてありますが、スーパーグローバル変数の変更危険性やオブジェクトを利用するメリットなどについて説明されており、オブジェクト思考への理解が深めまるような内容でした！

いつもなんとなく使っている変数やメソッドに関して、その内部実装の理解を進めるのは、アプリレイヤーより上位の理解に繋がり面白いなと感じました。また久保さんが今回のテーマ選定理由に関して「知的好奇心から」と説明されているのが素敵だなと思いました！ (次はPSR-15だそうです！)

  • Lancersをコンテナへ本番移行する取り組み

3人目は、Lancersのプロダクト開発部 SREチームから、安達 涼さん (@adachin0817)に登壇頂きました。

登壇内容としましては、Lancers本番環境のコンテナ移行までの経緯とそのノウハウについてです。コンテナ移行は1年かけての大プロジェクトであり、MENTAやLancers Agencyなどのグループのプロダクトにて試行錯誤の結果、集大成のプロジェクトでもあります。

Terraformによる本番環境のIaC化 → インフラをCIrcleCIでCI/CD → EC2をAmazon Linux2化 → ログサーバーのKinesis化 = 単一障害点の撲滅 → 開発環境の修正 → フロントエンドのビルド方法最適化 → ☆ 本番環境のコンテナ化 ☆ (改めて見るとすごい工数ですね、、)

ここでは詳細について説明できていないですが、他にもBatchサーバーのECS Scheduled Task化や独自デプロイシステム deploy-sanの廃止など、実際に日々開発しているエンジニアとしては、本当に快適な開発環境へ進化しており、日々恩恵を受けています。

それぞれの工程に関してはスライド内に安達さんが執筆したブログやスライドのリンクが記載されていますので、気になる方は是非チェックしてみてください。以下に今回のコンテナ化に関するエンジニアブログの記事を貼っておきます。

> Lancers本番環境のコンテナ化が完了しました

  • 大規模プロダクトにLinterを導入し運用している話

4人目は、dipさんのシステム開発1部 から大塚 裕紀さんに登壇頂きました。

登壇内容としましては、10年近く運用されている「はたらこねっと」の大規模システムリプレイスに合わせて、PHPのLinterである「PHP Insights」を導入したコードの品質担保についてお話しされていました。

PHP Insightsは設定を柔軟に変更することができ、導入コストも高くないそうです。運用に関しては、Githubへのpushをフックとして、AWS CodeBuildを用いてテストとLinterを実行されているそうです。(実行結果画面がめっちゃ見やすい！)

PHP Insights導入後は、レビュアーの負担も減り、開発体験が向上されているそうです。今後の方向性として、Linterのルールの厳密化と自動修正を掲げられていました。

勇魚さんのメタ的な生産性改善も、Linterを用いたデティールのコード管理、どちらも開発の品質担保には重要ですよね。ちなみに今回のリプレイスに合わせて開発言語をJavaからLaravelに移行されたようで、言語のリプレスってできるんだ、と衝撃を受けました。

  • バイトルPROソフトウェアアーキテクチャ再設計の取り組み

5人目は、dipさんのシステム開発1部 から米田 宏さんに登壇頂きました。

登壇内容としましては、Laravel6で構成されている「バイトルPRO」のアーキテクチャの課題に対して、「オニオンアーキテクチャ」と「戦略的DDD」をによるアーキテクチャの再設計により、それぞれの役割と責務を明確化したお話しされていました。

バイトルPROのアーキテクチャ課題は、ディレクトリやコンポーネントの責務が曖昧であり、新規参画者のオンボーディングに時間を要する点にあったそうです。その解決策として広く知られた構成を採用することで、責務を明確化し、共通の語彙の導入によりコミュニケーションコストも軽減できたそうです。

オニオンアーキテクチャに加え、戦術的DDDのコンポーネントを各ディレクトリに対応させることで、ディレクトリの責務と格納されるコンポーネントの責務を一致させる構成にしたそうです。それにより各コンポーネントの責務や実装指針も明確に定義できたそうです。

こちらのテーマもだいぶ濃密で、大規模なプロジェクトであったことが容易に予想できます。実際に課題に対してアーキテクチャで解決するといった実例を聞けたのは貴重な体験で、アーキテクチャや設計に関する興味が加速しました！

  • 適正企業を見つける思考術

6人目は、dipさんのシステム開発1部 から戸村 裕樹さんに登壇頂きました。

登壇内容としましては、「自分に合った会社が見つからない」と感じがちなエンジニアの課題に対して、仕事・キャリアチェンジへの捉え方や考え方、そのきっかけについて、一般とは少し違った視点でお話しされていました。

キャリアチェンジする際の企業の見極め方について、「営業とエンジニア比率」「主要取引先」「損益計算書 (P/L)」を確認すると説明されており、その理由や意図を聞いていくと、なるほど…と納得させられました。

「企業から選ばれるようなスキルセットの準備」「年収を棚卸し・逆算して方向性を定める」といった話をされており、相手の視点から考える・結果から逆算する、といったことは何においても大切なのだな、と改めて感じました。

こちらの発表は他とは少し毛色の違うテーマでしたが、仕事を軸に扱うdipさんならではの角度の意見で、内容にとても説得力がありました。エンジニアとして、社会人として常に付き添う課題であり、当日のコメント欄でも視聴者の方にとても刺さってました (笑)。

おわりに

今回のイベントでは、両開発組織の生産性やコードの品質管理といった観点について、直近の学びについて共有できた良いイベントでした！

またdipさんとランサーズ、両社ともにミッションやサービスに共感頂けるメンバーを募集しております！一緒に働きたい、話を聞いてみたいという方は、是非カジュアルにお声がけ下さい！

dipさんの採用サイト：https://www.dip-net.co.jp/recruit/top/

ランサーズの採用サイト：https://www.lancers.co.jp/careers/

最後までお読みいただき、ありがとうございました！

今回イベント: https://lancersrecruit.connpass.com/event/248522/

KPTの振り返りと継続的Try

ohira.koki｜2021年12月11日
インターンシップ

この記事はランサーズの AdventClender2021 の11日目の記事です。

現在ランサーズに内定者インターンとして、Lancers Creative 開発にジョインしている 大平紘基 (@kokitecture) です。

この記事では、初めて実務開発に参加した約4ヶ月間を、週1で行ってきたKPTを見返す事で、自分の考える業務改善・継続点を共有したいと思います。

まず簡単な自己紹介

自分は建築学部出身で、卒業後からプログラミングを開始しました。
学部時代にインターンなどを行っていなかったことから、ランサーズでの経験が自分の初の社会人の体験でしたので、初めは結構緊張していました。

インターンとして業務の初感は以下の記事で書かせていただいております。
また入社前の準備・心構えに関しても書いていますので、良かったら見てみてください。

振り返りのフレームワークKPT

今年を振り返るにあたり、まず自分のチームで毎週金曜日に実施している、KPTを見返しました。

KPTとは、「振り返り」によって、業務やプロジェクトの改善を加速するフレームワークのひとつです。KPTのそれぞれの頭文字である、
Keep ≒ 良かったこと  /  Problem ≒ 良くなかったこと  /  Try ≒ Keepの継続案やProblemの改善案
の3要素に分けて、共有・議論します。

自分のチームでは、それぞれの要素において具体性を重視して行っています。
このルールの下行うことでで、1人ひとりのProblemがより言語化され、Tryが行動に結びつきやすくなっている、と感じています。

前段が長くなりましたが、以下に今年を振り返り、来年も継続させたいTry要素をまとめていきます。

来年も継続的なTry

密なコミュニケーション

Tryの中で最も多かったのは、メンバーとの連携についてでした。 エンジニアは、ユーザーの要望やデザイナーの考えを最終的にカタチにする責務があると考えています。
そのためのチーム間コミュニケーションは重要であり、それらを円滑に行うべく、作業の確認と共有はとても大切だと感じました。

  • まずは作業の方向性が正しいことの確認から
  • 議事録のメモは共有する
  • 確認 → 再確認の流れ

技術的な振り返り

実務開発に取り掛かり4ヶ月ですが、その間に感じた技術的な改善・継続案です。
新機能の追加や既存コードの修正など、どの場面においてもまずはコードを書いてみる、手を動かしログを見る、そこから理解を進めることが最速だと思いました。

  • まずは手を動かす
  • まずはエラーかどうかの確認、エラーの場合は原因を特定するところから、ログを見る
  • ペアプロする際は、作業の目的を明確にする

業務の進め方について

これは自分の考える、業務効率を上げるTry要素です。
睡眠時間はやはり大切だと感じています。 また朝一のタスクに関しては、業務開始から最速で対応すべく、前日のうちにTodoを細かく分けるようにしました。これは来年も続けていこうと思います。

  • タスクを細かく分類する
  • 早寝早起きを意識する

プロジェクトの進め方に関して

この項目はこれまでとは少し主旨が異なりますが、素人目線ながらプロジェクトを進める上で大切だと感じたことをKPTで共有させて頂きました。
中でも「早い段階で共通認識を持つこと」は、手戻りを少なく抑え、最速で実装を進めることができると思っています。
段々とプロジェクト毎といった、中規模的な目線も身につけていきたいと思います。

  • 長期・中期・短期、もう少し細かく目的を分類する、プロジェクトの優先順位
  • 早い段階で共通認識を持つこと
  • 担当外の機能のPRレビューも、自分毎として取り組む

さいごに

今年は自分の中で大きく環境が変化した年なので、このような振り返りを発信できることはとてもいい機会だと感じました。

来年からは、技術的なアウトプットにも積極的に挑戦していきたいと思います。
また現在は目の前のタスクをこなす事で精一杯ですが、今後はより中長期的目線を持って、業務に取り組んでいきたいと思います。

最後までお読み頂きありがとうございました！
明日の AdventClender2021 は、新卒の橋口さんです！是非お読みください！

[Lancers x SUPER STUDIO]第1回 Engineer Meetup を開催しました！

ohira.koki｜2021年09月10日
イベント／登壇

開発部でインターンをしています、大平 紘基  (@kokitecture) です。

SUPER STUDIOさんとLancersのコラボイベントを、9月8日に開催しました！参加者はなんと67人！！多くの方々に参加頂きました、その内容を紹介させて頂きます。

Lancersはスキルシェア、 SUPER STUDIOはD2Cとそれぞれプラットフォームを提供しています。今回は各社の技術的取り組みや現場で働いているエンジニアの雰囲気について、若い世代のエンジニアからベテランエンジニアの方々に登壇して頂きました。

それでは、よろしくお願いします！

タイムスケジュール

https://lancersrecruit.connpass.com/event/221994/

今回のイベントは、以下のようなタイムスケジュールで実施しました。

企業紹介（15分）

  • 株式会社SUPER STUDIO
  • ランサーズ株式会社

勉強会（60分）

  • 「リーダーを降りてヒラになった話」　SUPERSTUDIO社 宮下さん
  • 「インターンから入社してRailsのメール送信をSengGridに移行してみて」　ランサーズ社 平野さん
  • 「開発チームにスクラムを導入した話」SUPERSTUDIO社 　齋藤さん
  • 「新卒がMENTAの企画立案から実装までを一人で行ってみて」　ランサーズ社 池田さん
  • 「アルゴリズムに苦手意識がある私がアルゴリズムを勉強してみた」　SUPERSTUDIO社 下村さん
  • 「Terraform v0.12.29 → v1.0.5にバージョンアップする上で気をつけること」　ランサーズ社 安達さん

Q&A, 雑談（15分）

今回のイベントは、主に新卒エンジニアや駆け出しエンジニアの、キャリアのヒントになるような登壇内容が中心となっています。

それではそれぞれについて、以下で紹介させて頂きます！

企業紹介

はじめにSUPER STUDIOさんとランサーズ、両社の会社説明をしていただきました。

SUPER STUDIOとは？

まずはSUPER STUDIOさんのエンジニアリングマネージャー 河端 良介さんから、サービスと会社の概要を説明して頂きました。

SUPER STUDIOさんはD2C支援専門企業として、SaaS事業、D2Cコンサルティング事業を行っています。

SaaS事業では現在、ECプラットフォーム［ecforce］を運営されています。D2Cコンサルティング部隊から必要な機能に関するフィードバックを受け、それを国内外の3拠点にて迅速に改善されているそうです。SUPER STUDIOさんのより詳しいの情報はこちら！

ランサーズとは？

次にランサーズの開発部 部長/VPoE 倉林 昭和 (@terukura)さんから、サービスと会社の概要を説明して頂きました。

ランサーズは個人の生活・働き方、あり方の変革を目指し、新しい働き方を提供するサービスを運営しています。

企業とフリーランスのオンラインマッチングサービスである Lancers を中心に、定額で業務をサポートする Lancers Assistant など、「働く」というキーワードを軸に様々なサービスを展開しております。

勉強会

それではメインテーマである、6人の登壇内容を紹介していきます！

リーダーを降りてヒラになった話

1人目は、SUPER STUDIOさんのソフトウェア開発ユニット/改善チームから、宮下 裕志さんに登壇頂きました。

登壇内容としましては、自身の経歴を参考に、運用/改善チームのリーダーというポジションから、技術力でチームをリードする、スペシャリストというポジションを選択した、といったキャリアプランのお話をされていました。

現状のリーダーという働き方と、入社当時の「自身の技術力をつけたい」という思いの、2つ考えを検討し、今回の決断に至ったそうです。

登壇最後には、エンジニアのキャリアプランに対する考えを述べらており、現在エンジニアとしてインターンをする自分に、今後とても参考になる内容でした。

インターンから入社してRailsのメール送信をSengGridに移行してみて

2人目は、ランサーズの開発部から、平野 達也 (@n44511336tatuya)さんに登壇頂きました。

登壇内容としましては、前半はご自身の経験をもとにインターンからランサーズに入社する経緯を、後半は直近の業務内容であるメールサーバーをSengGridに移行されたお話をされていました。

前半部分では、フランス料理人というプログラミング未経験の立場から、エンジニアを目指すまでの経緯や、実際に開発現場に参加して感じたことを述べられておりました。ちなみに平野さんがインターンの際の経験をまとめた記事もございますので、よかったらそちらもご覧ください。

元料理人が入社してからの1ヶ月を振り返る

 

後半部分では、メールサーバーのSengGridへの移行の際の、課題やその解決方法について説明されていました。その具体的な方法を記した記事もございますので、そちらもご覧ください。

Railsのメール送信をSendGridに移行しました

 

インターンから現在の業務内容までを聞くことができ、同じく未経験からエンジニアを目指している自分には、とても学びの多い内容でした。また現在自分は平野さんに業務をフォローして頂いているということもあり、平野さんの背景を聞くことができて興味深かったです！

開発チームにスクラムを導入した話

3人目は、SUPER STUDIOさんのソフトウェア開発ユニット/開発チームから、齋藤 一輝さんに登壇頂きました。

登壇内容としましては、現状の開発体制の課題について見直し、その解決策として、開発サイクルにスクラム開発を導入された際の、目的やその方法について話されていました。

スクラム開発とは、ラグビーの「スクラム」が語源であり、チームのコミュニケーションを重視した開発手法のフレームワークです。

最後には、今回のスクラム開発の導入を1つの例に、チーム全体に影響のある課題に取り組む際には、迅速に対応することや周りを巻き込む事の大切さを説明されており、課題に向き合う姿勢についてとても勉強になりました！

新卒がMENTAの企画立案から実装までを一人で行ってみて

4人目は、ランサーズの開発部/MENTA事業部から、池田 直人 (@naoching7010)さんに登壇頂きました。

登壇内容としましては、前半に新卒時代の経験やチーム2人の状態からメンバーが20人に増えた際に心掛けたことを、後半にMENTAの新機能立案から実装までを1人で行ってみた際の学び、について話されていました。

前半部分ではまず、はじめて実務でLaravelの開発に携わった際に、自由なフレームワークだからこそアーキテクチャ設計の重要性を実感したお話をされていました。またチームメンバーが大幅に増加した際の、タスク管理やチームビルディングの方法について説明されていました。

 

後半部分では、実際にMENTAに導入されているチップ機能について、企画立案から実装まで手掛けた際の、「『早く作ること=偉い』と勘違いする」や「『誰のため、なんのため』の機能か忘れる」といった、実体験から得た学びを紹介されていました。

チーム開発の際の注意点や、新機能をリリースするまでの実態など、多くの学びを得ることができました。また実際に自分がMENTAを利用していた際にリリースされた「チップ機能」が、新卒の池田さんによって企画立案から実装までされていことを知り、その行動力と積極性に驚き、感服しました。

アルゴリズムに苦手意識がある私がアルゴリズムを勉強してみた

5人目は、SUPER STUDIOさんのソフトウェア開発ユニット/運用チームから、下村 由紀さんに登壇頂きました。

登壇内容としましては、もともと苦手意識のあったアルゴリズムについて勉強した際の感想と、そこから得た学びについてお話されていました。

下村さんは、アルゴリズムの勉強を始める前に、今回のイベントの参加を決められたそうです。そしてイベントに向け、苦手意識のあったアルゴリズムの勉強に取り掛かる、といった挑戦的なアプローチをされており、感動致しました…！

そしてその結果、アルゴリズムの知識に加え、勉強することの楽しさを知ることができたそうです。また現在もアルゴ式というサイトで、アルゴリズムの勉強を続けているそうで、新しいことへの挑戦や学ぶ事への姿勢など、とても参考になりました！

Terraform v0.12.29 → v1.0.5にバージョンアップする上で気をつけること

最後は、ランサーズの開発部/技術基盤 SREチームから、安達 涼 (@adachin0817)さんに登壇頂きました。

登壇内容としましては、ランサーズで利用しているTerraformのバージョンを、v0.12.29からメジャーアップデートされた安定板v1.0.5へ、4つのプロジェクトをアップデートされた際の方法やその苦労話をされていました。

まず前提としてランサーズでは、各サービスの本番環境とステージング環境でAWSのアカウントを分割した構成になっています。その構成において、Deployサーバーを用いてterraform applyを実行することで、変更をそれぞれの環境へ反映させる流れになっています。

今回のバージョンアップでは、AWSの管理をより安定させる為に、下記の4つのサービスにおいてバージョンアップを行ったそうです。しかし実はTerraformのバージョンアップでは、0.12から0.15に一気にアップデートをすることができず、0.12→0.13..と徐々にローリングアップデートすることしかできないそうで、一つひとつ実行されたそうです、、

今回のお話を聞いて、既存ツールのバージョンアップする事の難しさを感じた同時に、やはり影響力の大きいインフラ領域の知識の大切さを再度実感致しました！

Terraformバージョンアップに関しては、より詳細な内容を別途記事にまとめておりますので、よろしければそちらもご覧ください。

Terraform v0.12.29 → v0.15.0にバージョンアップしました

また自分はインターンとして、安達さんには日頃からフォローアップして頂いておりますが、安達さん自身も新たな技術的挑戦を続けられており、その学び続けられる姿勢に脱帽致しました。

Q&A, 雑談

最後はそれぞれの登壇内容を踏まえて、各社のエンジニアの開発環境などについて、雑談を交えてそれぞれ質問を行っていました。

また参加者の方から頂いた「新卒エンジニアなど実務経験の浅いメンバーの受け入れに関して、どういった体制を取っていますか」という質問がありました。それに対してSREチームの安達さんが、心理的安全性を高めるためにペアプロや雑談など、頻繁にコミュニケーションをよく取るよう心掛けている、とお答えされていました。

その他に各社のエンジニアの育成環境や、駆け出しエンジニアに何が必要とされているか、など貴重なお話を聞く事ができました！

さいごに

今回のイベントでは、各社の若い世代のエンジニアを中心に、その開発環境や現場で得た学びに関して共有する事ができました。

またSUPER STUDIOさんとランサーズ、両社ともにサービスやミッションに共感できるメンバーを募集しております！一緒に働いてみたい、話を聞いてみたいという方は、是非お声がけ下さい！

SUPER STUDIOさんの採用サイト：https://careers.super-studio.jp/dept

ランサーズの採用サイト：https://engineer.blog.lancers.jp/engineer-recruit/

最後までお読みいただき、ありがとうございました！

インターン1ヶ月目で感じたこと

ohira.koki｜2021年09月07日
インターンシップ

はじめまして！今年の7月26日からインターンをしております、大平紘基( @kokitecture )と申します！

ランサーズに入社するまでは、大学で建築学について学んでおりました！今回は入社に至る経緯と実務未経験で現場に参加して感じたことに関して記述させて頂きます！

よろしくお願いします！

バックグラウンド

私は2020年に、東京の建築学部を卒業しました。

モノづくりが好きだったこともあり、学部時代には建物の設計を中心に取り組んでいました。

卒業後は、大学院入試の勉強に努め、建築とエンジニアリングを専門とする研究室を目指しました。その過程で、成果物を提供することで、分野を問わず人々に貢献できる、エンジニアの魅力を知りました。

そして独学とプログラミングスクールにて、RubyとRailsの学習を始め、サービスを作ることに面白さを見出し、エンジニアを目指すことを決意しました。

入社の経緯

プログラミング学習 → 就職活動

2021年の5月にはポートフォリオも作成し、就職活動を始めましたが、現在は未経験エンジニアが多くいることもあり、順調に面接などに進むことができませんでした。

そこでポートフォリオの改善点や就職におけるの自身の問題点を探求すべく、弊社サービスである MENTA を利用しようと考えました。

MENTA → ランサーズへ

MENTAにて「メンターを募集」を行うと、10人以上のエンジニアの方々にメンタリングを提案して頂き (@adachin0817) にメンターをお願いすることにしました。

安達さんには、ポートフォリオのインフラ面の技術不足を指摘して頂き、slackでのやり取りを中心に、インフラ面の強化を行いました。その結果、Herokuにデプロイしていたポートフォリオを、開発環境をDocker、本番環境をEC2でそれぞれ構築し、TerraformやCircleCIを用いてそれらをコードで管理する構成にできました。ちなみにその時のポートフォリオはこちらです。

また学習と同時に、社会人経験のない自分に、エンジニアとしての心構えや現場での振る舞いなどを教えて頂き、感謝でしかありません。そしてメンタリング最後にはランサーズを紹介してくださり、インターンに至ります。現在は同じMENTA経由でランサーズに入社された、平野さん (@44511336tatuya) に色々と教わりながら、Lancers Creativeを中心に開発に携わっています！

開発現場で感じたこと

ここでは実務未経験の自分が、実際に開発を経験して感じたこと、を書きたいと思います。

1.   エンジニアはチームで働くということ

これまで個人で開発を進めてきた自分に取っては大きな変化であり、とても大切だと実感したことの一つです。チームで開発を進める事から、疑問点はすぐに質問できますし、間違っている点は指摘して頂いています。ただその分、質問や報告の仕方など、コミュニケーション能力はとても大切だな、と実感しています。

またランサーズは基本フルリモートで開発をしていますが、slackを有効活用し、ストレスなくコミュニケーションを取る事ができます。最近ではハドルという機能を用いて、通話と画面共有でペアプロを行う機会も多く、会話をしながら疑問点を解消して頂き、とても勉強になっています！

2.   チャレンジできる環境があるということ

入社1ヶ月目ではありますが、本当に色々なことに挑戦させて頂きました。サービスの機能改善などだけでなく、Rails開発環境構築の自動化や本番DBのマスキングSQLの作成、WordPressによるサブディレクトリの修正、Rails社内ツールの改修など、幅広いタスクに着手し、多くの学びを得ることができました。

現在は託される事で業務に取り掛かる事が多いですが、今後は自ら手を挙げてタスクに挑戦できるようになる事が、目標のひとつです！

3.    独学での学習経験は現場に活用できる

初めての開発現場では、見たことのないコードやファイルの多さに圧倒されました。現在もその点はあまり変わりませんが、時にポートフォリオで扱った知識が活用できる場面もあり、基礎学習の大切さを痛感します。

ポートフォリオは就職活動のツールの一つではありますが、いい勉強素材の一つになり得ると感じました。またその点は現在の自分にも通じ、着実に新しい知識を積み重ね、今後に繋げていこうと思っています！

まとめ

入社して1ヶ月が経ちましたが、本当に様々なタスクに挑戦させて頂き、あっという間に感じます。ただ知識不足なことから、理解が追いついていない点もまだまだ多く、力不足を実感しています。今の目標としては、目の前にあるタスクを着実にこなしながら、サービスの理解を深め、徐々に改善点などを提案できるようになりたいと考えています。

また現在は主にRailsの開発に携わらせて頂いていますが、フロントエンドやバックエンドなどにも挑戦し、徐々に貢献できる幅を増やしていきたいです！！

最後までお読み頂きありがとうございました！！

[スペースマーケット×ランサーズ][SRE]第2回目のコラボイベント開催しました！

ohira.koki｜2021年08月27日
SRE

開発チームでインターンをしています、大平 紘基  (@kokitecture) です。

8月25日に2回目となる、スペースマーケットさんとランサーズのコラボイベントを開催しましたので、今回その内容を紹介させて頂きます。ちなみに第1回目はこちら！

今回のテーマは「シェアリングエコノミーを支えるインフラ/SRE」です！

両社ともにシェアリングエコノミーのプラットフォームを提供していますが、それらを支えるインフラ/サーバーは大きく異なっています。 それぞれどのような課題と向き合い、取り組みを進めているのかをご紹介する内容になっています。

それでは、よろしくお願いします！

タイムスケジュール

https://lancersrecruit.connpass.com/event/219434/

今回のイベントは、以下のようなタイムスケジュールで実施しました。

企業紹介（15分）

  • 株式会社スペースマーケット
  • ランサーズ株式会社

勉強会（60分）

  • メインAPIのRailsバージョンを4.2から6.0に上げた話 / スペースマーケット社 鈴木さん
  • Go + SQS + Fargateで速度、品質、低コストを実現する / スペースマーケット社 土屋さん
  • MENTAをAWSに移行して振り返る(ECS/Fargate + Laravel編) / ランサーズ社 安達さん
  • SendGrid用のメールモックコンテナを作った話 / ランサーズ社 金澤さん

Q&A, 雑談（15分）

今回は第2回ということで、SREや技術基盤の内容が中心となっており、最後の雑談の部分でも技術的な話題について盛り上がりました。

それではそれぞれについて、以下で紹介させて頂きます！

企業紹介

はじめにスペースマーケットさんとランサーズの両社の会社説明をしていただきました。

スペースマーケットとは？

まずはスペースマーケットさんはCTOの斉藤さん (@araki3106) より、サービスと会社の概要を説明して頂きました。

スペースマーケットさんは、スペースを貸したい方と借りたい方を結びつける、プラットフォームを運営されています。

スペースマーケットさんの技術スタックは以下の通りです。サービス品質と開発効率の最大化を目指し、事業の成長に合わせて、アーキテクチャをどんどん作り変えていく文化について紹介されていました！スペースマーケットさんのより詳しい情報はこちら！

ランサーズとは？

次にランサーズはVPoEの倉林さん (@terukura) より、サービスと会社の概要を説明して頂きました。

ランサーズは、仕事をお願いしたい企業さんとフリーランスの方々をマッチングする、安心して取引して頂く為の機能群を提供するプラットフォームを中心に運営しています！

ランサーズの技術スタックは以下の通りです。ランサーズは、” 個のエンパワーメント ” をミッションとしており、現在は「働く」というキーワードを軸にしていますが、ミッションの実現の為にはどんどんビジョンもアップデートしていく想定です！

勉強会

いよいよメインテーマである、それぞれの発表のスタートです

メインAPIのRailsのバージョンを4.2 → 6.0に上げた話

まずはスペースマーケットさんの技術部 SREチームから、鈴木 景介さんに登壇して頂きました。

登壇内容としましては、スペースマーケットさんのMain APIのRailsのバージョンを、4.2から6.0に一気にバージョンアップした際のお話をして頂きました。

 

他社の実績があることや効率的なバージョンアップを目指し、メジャーバージョンを2つ一気に挙げられたそうです。

バージョンアップに伴い500件以上のRSpecを改善したお話や、リリースの際にAWSのALBを用いたBlue/Greenデプロイを行ったというお話がとても勉強になりました。

SendGrid用の メールモックコンテナを作った話

次にランサーズのSREチームから、金澤さん (@yakitori009) に登壇して頂きました。

登壇内容としましては、ランサーズのメールサーバーのSendGridへの移行に伴い、検証環境で用いるメールモックコンテナ用のOSSを自作した際のお話です。

メールモックとは、ダミーのメール送信サーバーで、実際に送信はせず表示だけ行うコンテナであり、開発環境からお客様にメールを送信するなどの、メールの誤送信問題を解決する目的で利用します。しかし、現在提供されているメールモックコンテナの多くは、SMTP通信に対応しているが、SendGridに対応しているものは少ない状況でした。またこれまで利用していたSendGrid用のメールモックコンテナに関しても、利用を進める上で追加の要望が増えてきたことから、金澤さんが自前でSendGrid対応メールモックコンテナを作ることにしました。（すごい…!

SendGrid用のMailモックコンテナを作りました

メールモックにはコンテナの軽量化を目的に、MailDevを採用しています。SendGridのAPI部分はGolang × echoで自作しています。

 

既存のメールモックコンテナに課題を感じ、マルチアーキテクチャへ対応したOSSを自作したという、とてもチャレンジングな取り組みに感銘を受けました。

Go + SQS + Fargateで速度、品質、低コストを実現する

3人目は、スペースマーケットさんの 技術部 BEチームから、土屋 陽介さんに登壇して頂きました。

登壇内容としましては、Go + SQS + Fargateのシステム構成に移行することで、サービスの新たな予約機能への対応と運用コストを最適化した、というお話をして頂きました。

サービスへの新たな予約導線の追加に伴い、サーバーへ既存の数十倍のリクエストが生じてしまい、それに伴うUXへの影響の解消の為に、アーキテクチャの変更に至ったそうです。

 

GoやSQS、Fargateは上記の課題解消に向け、適材適所の対応する為に技術選定されていました。

MENTAをAWSに移行して振り返る(ECS/Fargate + Laravel編)

https://speakerdeck.com/rvirus0817/mentawoawsniyi-xing-sitezhen-rifan-ru-laravelbian

最後にランサーズのSREチームから、あだちんさん(@adachin0817) に登壇して頂きました。

登壇内容としましては、さくらのクラウドで運用していたMENTAのサーバーの苦労話や、全てAWSに移行してECS/Fargateでのコンテナ運用に変わり、今回初となるコンテナでのオートスケールなどにもチャレンジしたについてお話頂きました。ちなみに自分はMENTAを利用して、あだちんさんにインフラ/サーバー周りをフォローしてもらいましたが、MENTAのバックグラウンドも知ることができたので感慨深いです！

 

個人的には、ECS Scheduled Tasksの毎分バッチで、NAT Gatewayの通信費が肥大化していた苦労話が印象的でした。その時の改善としては、ECRのpullをNat Gateway経由ではなく、VPCエンドポイント経由に変更することで、大幅なコストダウンを実現できたそうです。

[AWS][Fargate]ECS Scheduled TasksによるNAT Gatewayの通信費肥大化について

登壇最後には、弊社の社内ツールや会計システムのインフラはECS/Fargateに移行済みなので、今後はランサーズ本家のコンテナ移行にチャレンジしたい、と仰っていました。（頑張ってください！

Q&A, 雑談

最後はそれぞれの登壇内容を踏まえて、各社の開発環境やインフラに対して、それぞれ質問を行っていました。

ここでは視聴者の方から頂いた具体的な技術的質問への回答や、両社の技術スタックに関してカジュアルに雑談をされていました。

各サービスを支えるインフラやその選定に至った背景など、各社の実例を交えた貴重なお話を聞くことができました！

さいごに

今回のイベントでは、各社のインフラに対する課題やその解決から得た学びの共有ができました。

スペースマーケットさんとランサーズ、両社それぞれの技術事業やその解決など、日々新しいチャレンジを積極的に行っています。

両社ともに、一緒にそれらを解決してくれるエンジニアを募集しておりますので、興味がある方は、是非お声がけください！！

また9月8日(水)には、SUPER STUDIOさんとのエンジニアコラボ企画としまして、各社の技術的取り組みについてご紹介するイベントもございます。 新卒エンジニアや未経験エンジニアの方にも参考になる内容となりますので、こちらも是非ご参加ください！

https://lancersrecruit.connpass.com/event/221994/

最後まで読んでいただき、ありがとうございました！