├── README.md └── teams ├── dfplusio.md ├── ecbooster.md └── omni-hub.md /README.md: -------------------------------------------------------------------------------- 1 | ## チーム紹介 2 | 3 | * [dfplus.io](teams/dfplusio.md) 4 | * [EC Booster](teams/ecbooster.md) 5 | * [Omni Hub](teams/omni-hub.md) 6 | 7 | ## Feedforce Engineer's Principles 8 | 9 | ### :triangular_flag_on_post: Stay Humble; 常に謙虚であるべし 10 | 11 | チームメンバーと自分は異なった立場や文脈、背景を持っているうえ、自分と向いている方向が同じとは限らないが、顧客への価値を最大化するという目標は共有している。相手の立場と理解を尊重して慎重に行動する一方、自分へのフィードバックには常に客観的であるようつとめよう。 12 | 13 | ### :triangular_flag_on_post: Be Positive & Proactive; 常に肯定的・主体的であるべし 14 | 15 | 受け身であること、否定的に捉えることは誰でもできる。チームのパフォーマンス、そして顧客への価値を最大化するため、次に何をできるか、よりよくするためにさらに何ができるかを常に考え、自ら行動しよう。 16 | 17 | ### :triangular_flag_on_post: Be Prepared; 常に来たるべき機会に備えるべし 18 | 19 | 自らを生かす機会はいつ来るか分からない。何を求められているかを把握した上で来るべき機会に備えて能力を高め、爪を研いでおこう。機会は爪を研いでいる者にのみ訪れる。 20 | 21 | ### :triangular_flag_on_post: Share All; 己の知見、試行、失敗、遍く共有すべし 22 | 23 | 己の学んだ知見の価値を決めるのは己ではなく、その知見に接する者全てである。共有する前に己でその価値を過小評価せず、何を学んだか、何をどのようにやってみたか、どう失敗したか、遍く、そして根気よく共有し続けよう。 24 | 25 | ### :triangular_flag_on_post: Just Do It; 全力でやりきるべし 26 | 27 | たとえ高邁な理想を持っていたとしても、実現できなければ砂上の楼閣に過ぎない。やりきるために全力を尽くそう。 28 | -------------------------------------------------------------------------------- /teams/dfplusio.md: -------------------------------------------------------------------------------- 1 | ## 基本情報 2 | 3 | https://dfplus.io 4 | 5 | ## プロダクト 6 | 7 | ### プロダクトの説明 8 | 9 | dfplus.io は、マーケター向けのデータフィード管理ツール（SaaS）です。 10 | 11 | Googleショッピング広告、Criteo、Facebookダイナミック広告など、近年ますます重要度が高まっている「商品データフィードを利用する各種広告」を効率的に管理する機能や、施策成果を高めるための最適化機能を直感的なUIで提供しており、多くの広告代理店様、事業会社様から支持されています。 12 | 13 | 主な機能として、 14 | 15 | * 顧客が保有する商品データ（オンラインストアの商品、求人票データ、不動産物件データなど）の取込 16 | * 柔軟で強力なデータ変換ルール 17 | * 設定内容をわかりやすく確認できる広告クリエイティブプレビュー 18 | * 複数サイト、複数データフィードの統合管理機能 19 | * 広告媒体仕様に合わせてデータフィードの値を補正する自動最適化機能（[参考記事](https://dfplus.io/news/update-auto-optimization-20181227)） 20 | * 作成されたデータフィードの仕様適合度を評価するスコアリング機能（[参考記事](https://dfplus.io/news/new-feature-datafeed-score)） 21 | * 広告タイトルの自動改善機能（[参考記事](https://dfplus.io/news/new-feature-auto-improvement-for-google-shopping-20190828)） 22 | 23 | 24 | 25 | を備えており、これらを用いてEC、人材、不動産、旅行などの業界でデータフィード広告に関わるマーケターのお仕事をサポートします。 26 | 27 | [開発体制](https://media.feedforce.jp/n/n2e855d168e62)の記事をnoteで公開中です。 28 | 29 | 30 | ## 利用技術・開発環境 31 | 32 | ### 自動化していること 33 | 34 | - 開発環境構築 35 | - Lint 36 | - テスト 37 | - デプロイ 38 | 39 | ### 継続的に実践していること 40 | 41 | - ChatOps 42 | - Infrastructure as Code 43 | - スクラム 44 | - ペアプロ/モブプロ 45 | - 事業数値をチーム全体に共有 46 | - 毎日チーム全体で状況共有 47 | - 定期的に振り返り 48 | - キャリアアップの評価制度 49 | 50 | ### 利用している主要技術（本番環境で利用しているもの） 51 | 52 | `AWS`, `EC2`, `EKS`, `Lambda`, `Aurora`, `DynamoDB`, `Terraform`, `Kubernetes`, `Rails`, `TypeScript`, `React`, `redux`, `Heroku`, `Pusher` 53 | 54 | ### それ以外の開発環境や管理画面等で利用しているもの 55 | 56 | `CirceCI`, `Docker`, `Datadog`, `Mackerel`, `Bugsnag`, `Redash`, `Amazon Athena` 57 | 58 | ### タスク管理・チャットツール等 59 | 60 | `GitHub`, `GitHub Project`, `Slack`, `Zoom`, `esa`, `Figma`, `Trello`, `Google Spreadsheet`, `Miro` 61 | 62 | ## チーム全体での開発の進め方 63 | 64 | ### 開発・計画のサイクル 65 | 66 | 詳しくはこちらも一緒に御覧ください。 67 | [エンジニア採用を強化しているので優秀なマネージャーと開発体制をアピールするよ｜フィードフォースのnote](https://media.feedforce.jp/n/n2e855d168e62) 68 | 69 | スクラムをベースにした開発を行っています。UX/UI の設計と開発を同一イテレーション内で行っていないのが特徴的で、UX/UI を先のイテレーション内でプランニングし、開発が後のイテレーションで実装しています。これによって、開発が長くなったとしてもバックログアイテムのストックを増やすことができたり、 UX/UI についての議論を深くするための時間を増やしています。 70 | 71 | 1 スプリントは 1 週間です。初日に、今スプリントで実施するタスクを宣言することで達成したいゴールを明確にします。そして、毎日朝会(デイリースクラム)を行い、ゴールが達成できそうか共有することで問題の早期発見ができるよう心がけています。 72 | 最終日にレトロスペクティブ (KPT) を実施して、 1 スプリント通しての学びやカイゼン点を次回のスプリントに活かせるようにしています。 73 | 74 | どのような機能をどのようなUX/UIで提供するかを議論する「プランニング」には、すべてのエンジニアとUXデザイナー、およびプロダクトマネージャーが参加しています。情報の非対称性をなくし、開発スピードを上げることを意識しつつ、必ずドキュメントに残すようにしています。参加できなかったメンバーや後から見返す際に齟齬がないようにしています。 75 | 76 | タスクの管理には Google Spreadsheet, Trello, GitHub Issue/PR と GitHub Project を利用しています。 77 | 78 | ### 開発とリリース 79 | 80 | 開発フローは GitHub Flow を基本としていますが、リリース(デプロイ)は計画に従って任意のタイミングで実施しています。 81 | 82 | 1. Pull Request ベースでの開発(単独、ペア、モブ) 83 | 1. CI (Lint、単体テスト、結合テスト、E2E テスト、ビジュアルテスト) 84 | 1. 開発者レビュー(ペア、モブの場合は省略もあり) 85 | 1. レビュー環境作成(Heroku Review App / Render Pull Request Previews) 86 | 1. プロダクトオーナーレビュー 87 | 1. リリース(ChatOps) 88 | 89 | 機能開発と並行してユーザーガイドやプレスリリース、ユーザーアナウンスなども準備が進められており、それらと協調するために任意のタイミングでリリースできる方式を採用しています。 90 | 91 | ## 技術面でのアピール・課題・考え方 92 | 93 | ### 全体 94 | 95 | - バックエンド、フロントエンド、インフラ、デザイナーとそれぞれの分野に特化したメンバーが揃っています 96 | - フルリモートによる開発を行っており、ミーティングには Zoom を利用しています 97 | - どの職能でもなるべく 2 人以上で相互にレビューおよびモブレビューしながら開発しています 98 | - イテレーションごとにエンジニア同士で深い開発共有を行っています 99 | - 強制ではありませんが、ペアプロ・モブプロによる開発を推奨しています 100 | - レビューや CI、技術的負債返済の文化がしっかりあります 101 | - 属人化しないよう気をつけつつ、得意なことは各自でどんどんリードしてもらう雰囲気です 102 | - 監視・通知は Slack に集約しています 103 | - 週一でそれぞれの職能別のミーティングを行い情報共有や次週以降のタスク決めを行ってます 104 | 105 | ### バックエンド 106 | 107 | - 主に 3 人で開発しています 108 | - デプロイやオペレーション作業などの ChatOps にも積極的に取り組んでいます 109 | - Docker を利用した開発環境で開発しています 110 | - 主な技術スタックは [Ruby](https://www.ruby-lang.org/en/), [Ruby on Rails](https://rubyonrails.org/), [PostgreSQL](https://www.postgresql.org/), [Docker](https://www.docker.com/) です 111 | 112 | ### フロントエンド 113 | 114 | - 主に 2 人で開発しています 115 | - 日々の開発はペア/モブプロが中心です 116 | - 単体テスト、E2E テスト、ビジュアル回帰テスト、型チェック、Lint、Bundle Analyzer を導入しており、安心して Pull Request をマージできる CI 構築に努めています 117 | - 主な技術スタックは [TypeScript](https://www.typescriptlang.org/), [React](https://reactjs.org/), [Redux](https://redux.js.org/) です 118 | 119 | ### インフラ 120 | 121 | - 専任は 1 人ですがバックエンドチームもインフラに理解があるため積極的に相談や協力しています 122 | - より安定的なサービス稼働を目指し、インフラ構成の見直しや運用コストの削減、属人性の排除を重視しています 123 | - 現在は EKS/Kubernetes を利用したサーバ環境のコンテナ化を進めています 124 | - 主な技術スタックは [Kubernetes](https://github.com/kubernetes/kubernetes), [AWS](https://aws.amazon.com/), [Terraform](https://www.terraform.io/), [Chef](https://www.chef.io/), [Datadog](https://www.datadoghq.com/) です 125 | 126 | ### デザイナー 127 | 128 | - 今は 1 人のデザイナーがアサインされています 129 | - ステークホルダーの課題や解決策を素早く視覚化してチームに共有し、議論を進める「旗振り役」的な動き方が多いです 130 | - 実際の開発に関してはたまにコーディングに参加したり実装レビューをしています 131 | - 主な使用ツールは [Figma](https://www.figma.com/), [Sketch](https://www.sketch.com/), [Miro](http://miro.com/), [GitHub](https://github.com/), [Slack](http://slack.com/)です 132 | 133 | ### 課題 134 | 135 | - 大量のバッチ処理を高速・安定・安価に実行できる基盤の実現 136 | - メンテナンスなどに伴うサービス停止時間を極小化したシステムの実現 137 | - 統計・機械学習的なアプローチでの「使いやすさ」「成果」向上 138 | 139 | ## 開発チームからのメッセージ 140 | 141 | - メンバーの UX の理解度が高く、常にユーザーストーリーを意識して開発に取り組んでいます 142 | - 職域またいで興味を持って意見出しができ、落とし所を探れるメンバーが揃っているチームです 143 | - 課題や問題をチームのこととして捉えてチームでどう解決するのかを考えられるチームです 144 | - 風通しの良いフラットで働きやすいチームです 145 | - 不安に思ったことをすぐに共有できる場が用意されています 146 | - 真面目な話をする時と、雑談をする時の切り替えがしっかりしています 147 | -------------------------------------------------------------------------------- /teams/ecbooster.md: -------------------------------------------------------------------------------- 1 | ## プロダクトについて 2 | 3 | ### サービスサイト 4 | 5 | https://ecbooster.jp/ 6 | 7 | ### プロダクトの説明 8 | 9 | 中小のEC事業者をターゲットにした、ECの集客業務を自動化するサービスです。 10 | 現在は、「Google 無料リスティング」「Google ショッピング広告」への掲載・運用を自動化しており、EC事業者様が手がけるこだわりの商品を、Google検索におけるECの一等地へ簡単に掲載できます。 11 | 12 | ◆ EC Boosterがめざすもの 13 | EC の集客で欠かせない手段として、Google の検索結果や各種 SNS への商品掲載が挙げられますが、これらの掲載には配信媒体にあわせた商品データの整備や登録など専門的な知識が必要です。 14 | そのような広告出稿・運用における複雑なワークフローを自動化し、EC事業者が「よりよい商品・店づくりに専念できる」ことをめざしています。 15 | 16 | ◆技術面の特徴 17 | バックエンド領域の主な特徴として、集客に関する複雑なフローを自動化するためのジョブを開発/運用しています。また、モダンフロントエンドを通じた各種レポート、改善アドバイス機能などを提供しており、自動処理とインタラクティブなUIの両輪で最適なUXを提供しています。 18 | 19 | ## 利用技術・開発環境 20 | 21 | ### 利用している主要技術（本番環境で利用しているもの） 22 | 23 | `Ruby`, `Rails`, `TypeScript`, `React`, `Redux`, `GraphQL`, `Apollo`, `Heroku`, `GCP`, `Firebase`, `Cloud Functions`, `Firestore`, `BigQuery`, `AWS`, `Terraform`, `Pusher` 24 | 25 | ### それ以外の開発環境や管理画面等で利用しているもの 26 | 27 | `CircleCI`, `Docker`, `New Relic`, `Librato`, `Bugsnag`, `Redash`, `Amazon Athena` 28 | 29 | ### タスク管理・チャットツール等 30 | 31 | `GitHub`, `GitHub Projects`, `Slack`, `Zoom`, `esa`, `Figma`, `Trello`, `Google Spreadsheet`, `Miro` 32 | 33 | ## 開発の進め方について 34 | 35 | ### 現在の開発体制 36 | 37 | - エンジニア３名 38 | - デザイナー１名 39 | - プロダクトオーナー１名 40 | 41 | ### 開発・計画のサイクル 42 | 43 | EC Booster ではスクラムをベースに、モブプログラミングを取り入れたチーム開発をしています。 44 | 45 | ![開発スプリント回し方](https://user-images.githubusercontent.com/12433221/114650303-fcbfb780-9d1c-11eb-9720-eadb3fb83c75.png) 46 | 47 | 詳しい開発の進め方やモブプロの様子は、以下の記事をご覧ください！ 48 | 49 | - [EC Booster 開発スプリント回し方](https://docs.google.com/presentation/d/e/2PACX-1vTQY639rUAwDDtLfj_c9WbU1E0IlDSFzAbrP-XFCmbg8V_sNKPX_pCvKpiy50CQpS02nXvZnQHBb6JT/pub?start=false&loop=false&delayms=3000) 50 | - [半年モブプロしたらチームが大きく成長した話](https://developer.feedforce.jp/entry/2020/12/11/172338) 51 | 52 | タスク管理には GitHub Projects、Google Spreadsheet 、Miro などを利用しています。 53 | 54 | 55 | ### 自動化していること 56 | 57 | - 開発環境構築 58 | - テスト 59 | - Lint 60 | - デプロイ 61 | 62 | ### 継続的に実践していること 63 | 64 | - [スクラム開発](https://docs.google.com/presentation/d/e/2PACX-1vTQY639rUAwDDtLfj_c9WbU1E0IlDSFzAbrP-XFCmbg8V_sNKPX_pCvKpiy50CQpS02nXvZnQHBb6JT/pub?start=false&loop=false&delayms=3000&slide=id.gcefcb55f74_0_16) 65 | - モブプロ/ペアプロ 66 | - DevOps 67 | 68 | ### 開発とリリース 69 | 70 | 開発フローは GitHub Flow を基本としています。feature のリリース（デプロイ）など、計画に従って任意のタイミングでリリースする場合もあります。 71 | 72 | 1. Pull Request ベースでの開発（単独、ペア、モブ） 73 | 1. CI (Lint、単体テスト、結合テスト、E2E テスト、ビジュアルテスト) 74 | 1. レビュー環境作成（Heroku Review App） 75 | 1. 開発者レビュー、動作確認（ペア、モブの場合は省略もあり） 76 | 1. プロダクトオーナーレビュー、動作確認 77 | 1. master ブランチにマージ、リリース 78 | 79 | 機能開発と並行してユーザーガイドやプレスリリース、ユーザーアナウンスなども準備が進められており、それらと協調するために任意のタイミングでリリースできる方式を採用しています。 80 | 81 | ## 開発チームの特徴・課題 82 | 83 | ### 特徴 84 | 85 | - バックエンド、フロントエンド、デザイナーとそれぞれの分野に得意領域を持つメンバーが協力しながら開発しています 86 | - 得意領域はありつつ、それぞれの垣根を超えてお互いに教え合いながら開発をしています 87 | - 全員フルリモートによる開発を行っており、ミーティングやモブプロには Zoom を利用しています 88 | - ペアプロ・モブプロによる開発を中心に行っています 89 | - なるべく 2 人以上で相互にレビュー、またはモブレビューしながら開発しています 90 | - 設計の見直しやライブラリアップデートなどの、技術的負債を返済するタスクがスプリントバックログに組み込まれるようになっています 91 | - 属人化しないよう気をつけながら、得意なことは各自でどんどんリードしてもらう雰囲気です 92 | - モブプロや振り返りで突発的に深い技術的な話が繰り広げられることがあり、テックトークを楽しみながら開発をしています 93 | 94 | ### 課題 95 | 96 | ユーザー数の増加やサービスの成長に伴って、バックエンドの運用/改善の重要性が高くなってきているのですが、現在リソースが足りず後回しにせざるを得ない状況です。EC Boosterはバックエンドで複雑な処理を自動化しているため、バックエンドの運用/改善がサービスの価値に直結します。 97 | サービスの更なる価値向上のため、サービスの基盤を整えながらも機能開発をリードしてくれるバックエンドエンジニアを募集しています。 98 | 99 | ## 開発チームからのメッセージ 100 | 101 | EC Booster は toB のプロダクトでありつつ、全国の様々なECを運営されている方々に向けてサービスを提供しています。なので、toC のような距離感でユーザーさんと関わることができ、チームがまだ小さいこともあって臨場感を持ちながら開発をすることができます！ 102 | 103 | また、メンバーそれぞれが幅広い技術をキャッチアップしつつ、プロダクトで使う技術はきちんと全員に共有する環境のため、技術的にも楽しみながら成長できるチームです。良いプロダクトを良い技術で作って行きたい方、ぜひ一緒に働きましょう！！！ 104 | -------------------------------------------------------------------------------- /teams/omni-hub.md: -------------------------------------------------------------------------------- 1 | ## 基本情報 2 | 3 | https://omni-hub.jp/ 4 | 5 | ## プロダクト 6 | 7 | ### プロダクトの説明 8 | 9 | Omni Hubは2021年4月にリリースされた、ECサイトと実店舗の会員を統合するBtoBtoCのID連携サービスです。 10 | Shopifyと実店舗のPOSサービスの顧客情報を連携し、カスタマーに一貫したブランド体験を提供出来るようにします。 11 | 12 | 主な機能として、 13 | 14 | * 店舗で提示出来る会員バーコード 15 | * ECサイトと実店舗の売上情報の共通化 16 | * オンライン・オフライン共通のポイントプログラム 17 | * 他社アプリと連携した、オンライン・オフライン共通のポイントプログラム 18 | * 店舗発行のレシートを使ったポイント後付 19 | * Apple/Googleウォレットを使った会員証 20 | * 実店舗の在庫をECサイトで表示 21 | * 実店舗への訪問をチェックインイベントとして特典付与 22 | 23 | を提供しています。 24 | 25 | 従来これらの施策は、大手POSベンダーとの密な協業を含むブランドごとの個別開発が必要であり、大きなコストの掛かるものでした。 26 | そういった既存の顧客体験を低廉にカバーしつつ、消費体験をブランドが再デザインできるような機能の提供を目指しています。 27 | 28 | ## 利用技術・開発環境 29 | 30 | ### 自動化していること 31 | 32 | - 開発環境構築 33 | - 運用環境構築 34 | - 静的検査 35 | - テスト 36 | - デプロイメント 37 | 38 | ### 継続的に実践していること 39 | 40 | - スクラム 41 | - Blue/Green Deployment 42 | - Architecture Decision Recordの作成/周知 43 | - 機能仕様書の作成/更新 44 | - アプリケーション基盤のコード管理 45 | - 障害レポートの作成/追跡 46 | - 事業の数値進捗をチーム全員で共有/追跡 47 | - 透明性のある意思決定プロセス 48 | 49 | ### 利用している主要技術（本番環境で利用しているもの） 50 | 51 | `AWS`, `EC2`, `ECS`, `SQS`, `Aurora`, `Elastic Beanstalk`, `Terraform`, `Rust`, `Actix Web`, `Diesel`, `TypeScript`, `React`, `Polaris` 52 | 53 | ### それ以外の開発環境や管理画面等で利用しているもの 54 | 55 | `GitHub Actions`, `Docker`, `Sentry`, `Redash` 56 | 57 | ### タスク管理・チャットツール等 58 | 59 | `GitHub`, `Slack`, `Zoom`, `esa`, `Figma`, `Google Spreadsheet` 60 | 61 | ## チーム全体での開発の進め方 62 | 63 | 開発者3名、ビジネス3名、マーケティング1名のチームで、スクラムで進めています。 64 | 65 | 1イテレーション = 2週間を基準に、 66 | 67 | 1. そのイテレーションで取り組むタスクを全員で詳細化/分解していく `スプリントプランニング` 68 | 1. 次のイテレーションで取り組むタスクや顧客商談/開発の過程で新しく生まれたアイデアを優先度付け/詳細化する `バックログリファインメント` 69 | 1. そのイテレーションの成果をチームで共有する `スプリントレビュー` 70 | 1. そのイテレーションの取り組みを振り返る `スプリントレトロスペクティブ` 71 | 72 | 4つのイベントに全員で取り組んでいます。 73 | 74 | ## 技術面でのアピール・課題・考え方 75 | 76 | ### 全体 77 | 78 | - ドメイン駆動開発をベースにコードを組織化しています 79 | - 各自の得意領域を中心にしつつ、フロントエンド・バックエンド・インフラなどに担当領域を分けず、サービスそのものに対してコミットメントするように心がけています 80 | - 1つのレポジトリでフロントエンド・バックエンド・インフラのコードを全て管理しています 81 | - 自動CI/CDが実施されています 82 | - リファクタリング/コードベース改善の文化がしっかりあります 83 | - フルリモートで開発を行っています 84 | - 監視・通知は Slack に集約しています 85 | - バックエンドはRust/Actix Webで書かれています 86 | - フロントエンドはTypeScript/React/Preactで書かれています 87 | - インフラはTerraformで書かれています 88 | 89 | ### 課題 90 | 91 | - 企業顧客、生活者が望む機能を素早く提供していくために、人員が足りない 92 | 93 | ## 開発チームからのメッセージ 94 | 95 | 実店舗は、単なる販売の場だけでなく顧客に対するメディアとして再定義されつつあります。 96 | そのような中での、新しい小売体験・購買体験を提供するサービス作りが刺激的です。 97 | 98 | ぜひ力を貸して下さい！ 99 | --------------------------------------------------------------------------------