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

投稿者「yoshimoto」のアーカイブ

ランサーズ開発合宿2018@熱海 仕事案件のクローラー開発チーム

yoshimoto｜2018年09月06日
イベント／登壇

はじめに

開発部の吉本です。
一泊二日で、ランサーズ開発合宿を熱海で行いました。
クローラー開発チームでは、自社の外部サイトや提携サイトの仕事案件をランサーズの仕事検索に表示するという目的で、クローラーを開発して外部サイトとのデータ連携を行いました。

 

データ連携の全体像

主に以下の2つの処理に分けられます。
  1. 案件をクロールしてCloudSearchに追加するバッチ処理
  2. 案件を表示する仕事検索のview側処理

1. バッチ処理

案件をクロールするバッチ処理では以下を行っています。
  • 案件をクロールして取得する
  • 取得したデータをドキュメントとしてDBに保存
  • ドキュメントをCloudSearchに追加する

外部サイトの案件をクロール

クローラーで自社の外部サイト、提携サイトの案件の取得を行います。
クロール先では、求人情報の構造化データとして、schema.orgのJobPostingを使用しています。
schema.orgとは、正確な情報を検索エンジンなどのクローラーが認識するための、構造化データのマークアップです。統一した規格でデータを用意することで、複数の外部サイトで同じ形式でデータを取得することができます。

 

CloudSearchに追加

取得したJSON-LDをCloudSearchのドキュメント形式に変換して追加します。
ドキュメントをDBに保存しておくことで、変更があった時に差分のみ更新できるようにしています。

 

キャッシュについて

バッチを実行した際に、クロールした案件データを以下でキャッシュして、表示側で読み込む際にはキャッシュを使用しています。
  • JSON-LDをキャッシュ (memcached)

2. 仕事検索のview側処理

CloudSearchから取得したドキュメントをオブジェクトに変換して、viewに渡すことで、ランサーズ仕事検索に自社の案件と同じ形で表示しています。オブジェクトに変換する際にキャッシュを読み込むことで処理を軽くしています。
クロール先を変更することで、同じ仕組みで複数の外部サイトから案件を取得して表示することができます。今回は、以下のサイトの案件を取得して表示しています。

 

おわりに

外部サイトの案件を取得するためのクローラーの開発を行いました。
自社の仕事検索において、DBが見れない提携サイトなどを含めたデータ連携を実現しています。
合宿で良かった点としては、以下が挙げられます。
  • まとまった時間、いつもと違う環境で短期集中できる
  • ペアプロして他の人の開発ノウハウを学べる
  • ハマった時にチームですぐに解決できる

合宿の様子

ランサーズ開発ランチ（Lunchers ＃7） ～Kyash社でのプロダクト開発プロセス～

yoshimoto｜2018年08月21日
イベント／登壇

はじめに

はじめまして、開発部の吉本です。

今回の開発ランチ（Lunchers）では、Kyashでプロダクトオーナー兼プロダクトマネージャーをしている重松さんにゲストに来て頂いて、 Kyash社でのプロダクトの意思決定フローと開発プロセスについて2部構成でお話しして頂きました。

社内のPMから話しを聞いてみたいという要望から実現しました。ありがとうございます。

  • プロダクトの意思決定フロー
  • 直近の開発体制 / プロセス

Kyashについて

まず、ウォレットアプリの「Kyash」についてです。KyashはアプリからVisaカードを即座に発行して、買い物や送金が手軽にできるサービスです。今回の参加者のほとんどの方が、Kyashを知っていました。

Kyashは送金が手軽にでき、39円を投げ銭として送金すると特別なアニメーションがみれるそうです。

 

1部「プロダクトの意思決定フロー」

 一部はプロダクトマネジメントについてのお話しです。

 

Kyashの文化

  • Kyashでは「動いて風を知る」という文化があります。これは、まずやってみる、振り返りとしてKPTする、失敗してもすぐに振り返りTryして改善することを習慣にしていることを表しています。

OKRの導入

  • Q1(1月-3月): OKRをプロジェクトごとに決める。->プロジェクトが多くなり、またそれぞれのOKRと会社全体のOKRとの連動性が見えづらくなる
  • Q2(4月-6月): 開発チームとしてOKR持ち、また内容もシンプルに(〜までに〜の機能をリリース) -> PO1人に意思決定が集中しボトルネックとなる
  • Q3(7月-9月): OKRの立て方はQ2を引継ぎ、意思決定者を分ける。POはフォーカスを決め、howはチームで決める。

Kyash社では、ランサーズでも導入しているOKRで目標の設定を行っていました。
OKR導入にあたり、失敗もあったそうですが、OKRについて四半期ごとに振り返り改善していました。OKR導入でもKyashの文化が表れていると感じました。

弊社でも、はじめOKRの失敗から試行錯誤を繰り返してきていたので、共感できるポイントもとても多くありました。

質問

  • Q. OKRの決め方はどのように行っているか。トップダウンで決めるか、ボトムアップで決めるか。
  • A. 今はトップダウンでやっている。Q1でボトムアップでOKRを決めてやってみた際にズレが生じ、何が重要なのか現場が混乱してしまった。OKRを始めても形骸化してしまうことが多く見られるので、トップダウンで決めた時はきちんと理由を説明する必要がある。

2部「直近の開発プロセス」

2部では直近の開発プロセスについて、以下のようなお話がありました。
  • リーガル、CSと連携するため、チームに一人は含むようにしてスピードをあげる
  • 失敗するととりあえずKPTする
  • KPTのKPTを行う
  • バグ1グランプリの取り組み

 

Kyashでは、デザインや色など使用感も含んで、エンジニアだけでなくチームの皆でバグを発見する、「バグ1グランプリ」を行っており、皆でレビューすることで、リリース後の後戻りが生じにくくなるなど良い取り組みだと感じました。

 

質問

  • Q. なぜ皆でレビューするようになったのか、始めたタイミングは？
  • A. リリース後に問題を発見するという事が何度か発生したため、マーケ、リーガルを含むチーム皆でレビューを行う事で解消につながった。

おわりに

今回、プロダクトの意思決定フローと直近の開発プロセスについてお話しして頂きました。講演の後も、ランサーズの開発体制との違いやOKRについて意見を交換するなど、お互いに学び合う良い機会となりました。