時代に先駆け、EV（電気自動車）コンセント設置カテゴリを追加したお話

EV（電気自動車）コンセント設置イメージ

こんにちは。 みんなのマーケットでカテゴリーマネージャーをしている工藤です。

当社が運営しているサービス「くらしのマーケット」では、常に人に必要とされているサービスの模索、展開を行っています。
今や生活には欠かせない「自動車」関連のカテゴリを昨年リリースし、ユーザーの皆様の役に立つサービスの展開を続けています。

僕自身、週末は子供と一緒にアクティブに行動するタイプで、自家用車（愛車のVOXY）で高速道路もよく利用します。
もちろん、ソーシャルディスタンスを保ちながら！

高速道路のサービスエリアや道の駅などで、ここ数年やたら目にするようになったEV（電気自動車）の充電器。

何か聞いたことはあるけど、実際の市場ってどうなんだろう？
何か困ってる人のために展開すべきサービスってあるのかな？

っていう好奇心から、調査を行うことにしました。

現状の電気自動車の普及率がどのくらいなのか調べる

2020年の電気自動車普及率	約17.3％
電気自動車の登録数	約940万台
普通自動車の登録数	約4,500万台

引用
一般財団法人　自動車検査登録情報協会　わが国に自動車保有傾向

まだまだ普通自動車の方が主力ですね。
しかし、小池東京都知事が2030年脱ガソリン車100％する方針を打ち出していることはニュースで知っていました。
（後に菅総理も2035年に新車全て電動車の実現を目指すと発表）

そこで年間の自動車登録台数と、過去の自動車登録数を元に2035年の電気自動車普及割合を算出したところ、普通自動車よりも電気自動車の方が多くなる結果になりました。

電気自動車の充電スポット数を調べる

2020年の電気自動車充電スポット割合 ※	約37.5%
電気自動車充電スポット数	約18,000箇所
ガソリンスタンド数	約30,000箇所

引用
電気自動車充電スポット数：ゼンリン社調べ
ガソリンスタンド数：経済産業省　資源エネルギー庁　資源・燃料部石油流通課　揮発油販売業者数及び給油所数の推移（登録ベース）

※：燃料補給（ガソリンスタンド＋電気自動車充電スポット）に対する、電気自動車充電スポット数の割合

ちなみに、ガソリンスタンド数のピークは平成6年で60,000箇所あったそうです。
わずか30年弱で半分に減っちゃったんですね。

このままの推移をたどると、電気自動車の数同様、2035年にはガソリンスタンドの数 ＜ 電気自動車充電スポット数　になると容易に想像できます。

余談ですが、普通自動車の数5,900万台の燃料補給を、たった30,000箇所のガソリンスタンドでまかなえてるのって、単純に驚きでした

電気自動車が主流になると、わざわざ充電スポットにいかずとも、自宅で夜寝てる間に充電したい。
などのニーズが出てくるのは容易に想像できます。
仮に、スマホの充電が10分でできる！っていう充電器が自宅から100m以内のコンビニにあっても、もわざわざコンビニで充電しないですよね。
これと同じ感覚の未来が、近い将来やってくると思いました。

また、現状だと電気自動車コンセントの取り付けをどこに頼めばいいのか分からない。っていうユーザーの方も多いと思います。
（主に電気自動車購入時に、メーカーから紹介された工事業者で取り付けてる方が多いそうです。）

今すぐに、万人に必要とされるサービスではないと思いますが、近い将来きっと自宅に電気自動車コンセントは標準装備になると考え、カテゴリの新設に至りました。

新設したカテゴリはこちら → EV（電気自動車）コンセントの設置

つい先日リリースしたカテゴリですが、早くも作業予約が入っており、やはり困っているユーザーがいたんだな。と思うと同時に、困っているユーザーの助けになれたな。と思えました。（この業務をやってて嬉しい瞬間です！）

このように、弊社では個人の思いつきや、自分が必要（ってことは、他にも必要としている人がいるはず！）って思うサービスからも、 自社サービスの展開へ繋げることも可能です。

パッと思いついたアイディアを上長に話して、馬鹿にされるなんてこともありません。
いい意味で、思ったことを何でも言え、自分の考えを強くもって仕事をすすめることも可能です。（もちろんメンバーや上長と相談しながら）

与えられた業務に追われ、興味がある分野の業務を行う機会がない方。
常に新しい何かを考えているけど、アウトプットを出す機会がない方。

是非一緒に、世の中のくらしに便利なサービスを展開していきましょう。

Stripe Connect Expressの利用事例を発表しました

こんにちは。みんなのマーケットでCTOをしている戸澤です。

くらしのマーケットでは2020年8月に初の決済機能である、オンラインカード決済機能をリリースしています。 オンラインカード決済機能の実装では決済代行としてStripe社のConnectを使用しています。 Connectはくらしのマーケットのような、売り手、買い手、プラットフォーマーの3者がいるマーケットプレイス向けのプロダクトです。

今回、Stripeのユーザーコミュニティである、JP_Stripesさんよりお誘いいただき、 くらしのマーケットでのConnectの選定の背景、リリースの運用面についてお話させていだきました。

発表資料

関連記事

オンラインカード決済の開発に関する過去記事もありますので、ぜひご覧ください。

tech.curama.jp

tech.curama.jp

ヤッホー！シワちゃんだよーん

こんにちは、バックエンドエンジニアのキダです。 先日くらしのマーケットでSign In With Apple（SIWA）対応のリリースをしました！ SIWA対応でハマった点などを紹介いたしますので、興味がある方は参考にしてください。

背景

AppleのポリシーによりApple IDでログインできるソーシャルログイン機能のSign In With Apple（SIWA）は2020年7月より対応必須となりました。 ※ 元々は2020年4月からとなっていましたが、コロナウィルスの影響もあり延期されていました

対応必須の詳細は以下になります。

• ソーシャルログイン機能持つアプリはSIWAの対応が必要
• 対応してない場合、Appleのアプリの審査が通らない（新しいバージョンのアプリをリリースできない）

くらしのマーケットは店舗向けアプリと、ユーザー向けアプリが存在します。 ユーザー向けアプリは『Yahooログイン』『LINEログイン』を対応しているので、SIWAの対応が必須になっていました。 ユーザー向けアプリはAndroid、iOS共にWebViewで作成されていて、アプリネイティブの機能以外は全てWeb側で実装されています。その為それほど優先度は上がっていなかったのですが、iOSユーザー向けアプリにマージ済みでリリースできていない機能が溜まってきた為、2021年1月より対応を進めていました。

SIWAの特殊なところ

さて、そろそろ本題に入ります。 SIWAが他のソーシャルログイン機能と比較して異なる点を箇条書きにしてみます。

1. iOS端末（mac, iPhone）のSafariでは独自のサインインUIが利用可能で端末にログイン済みのApple IDで簡単にSIWAでの認証が可能（touch ID, face ID利用可）
2. メールアドレス、ユーザー名を連携するためにはコールバックエンドポイントをPOSTで実装する必要がある
3. 利用者はメールアドレスの匿名化オプションと、転送停止設定が可能

1.はとても便利な機能なのですが、2,3は開発する際に考慮する必要があり、主にこの点でハマったので詳細を説明します。 この点はdev.toの記事がとても参考になったので、合わせて確認いただけるとよいと思います。

なおAppleのデータ、デザインに関するガイドラインは以下になるので、こちらもご一読する事をお勧めします。

https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/data-management/

https://developer.apple.com/design/human-interface-guidelines/sign-in-with-apple/overview/buttons/

メールアドレス、ユーザー名を連携するためにはコールバックエンドポイントをPOSTで実装する必要がある

例えばYahooやLINEログインは以下のようなフローで Authorization CodeのOAtuh2認証がされています。

1. ログインボタンをログインや会員登録やアカウント連携ページに配置（/login, /regist, /connect のようなURL）
2. ボタンを押すと、それぞれのソーシャルアカウントでの認証処理を実行
3. 認証完了後に、元のページに code, state のパラメータをクエリストリングに付与してリダイレクト
4. 元ページではcodeの内容を検証して、問題なければ認証完了として、ログインや会員登録が完了

ここの3でのリダイレクト処理はGETでリクエストされます。

さて、SIWAではどうなっているでしょうか。 まずSIWAでの1のボタンに設定するURLは以下のように設定可能です。

https://appleid.apple.com/auth/authorize?response_type=code&scope=email&response_mode=form_post&client_id={{ clientId }}&redirect_uri={{ redirectUrl }}&state={{ state }}&nonce={{ csrfToken }}

それぞれパラメータは以下のようになります。

パラメータ	用途	設定例
response_type	Authorizationフロー	code（id_tokenも可）
scope	連携するユーザー情報	emailとname
response_mode	リダイレクト方法	form_post, query, fragment
client_id	Appleで登録する識別子
redirect_uri	リダイレクトURL	https://example.com/login
state	リダイレクト先で検証可能なcsrfTokenなど	自由に設定可能
nonce	リダイレクト先で検証可能なcsrfTokenなど	自由に設定可能

ユーザー情報を連携するためにはresponse_modeをform_postに指定する必要があり、GETで戻す前提の作りになっていたため、リダイレクト先でPOSTを受け取れるように修正する必要がありました。 くらしのマーケットでは先の/login, /regist, /connectのようなページは元々GET,POST存在していましたが、既存の仕組みではcsrfTokenのチェックでリダイレクト時にエラーが出てしまいました。

■ 対応策

こちらの問題の対応として、Appleからリダイレクトする専用のエンドポイントを作って対応しました。

以下のようなredirect_uriを設定して、動作します。

https://example.com/redirect/?/login

1. ログインボタンをログインや会員登録やアカウント連携ページに配置（/login, /regist, /connect のようなURL）
2. ボタンを押すと、それぞれのソーシャルアカウントでの認証処理を実行
3. 認証完了後に、/redirectページに code, stateのパラメータをクエリストリングに付与してリダイレクト
4. /redirectページで、stateの値を用いてセッションに保持したcsrfTokenチェックをして、問題無ければ元ページにGETでリダイレクト
5. 元ページではcodeの内容を検証して、問題なければ認証完了として、ログインや会員登録が完了

/redirectを挟む事で元のエンドポイントでの修正を抑えて実装することが可能でした。 これにて一件落着に見えたのですが、もう一つPOSTに起因する問題がありました。

samesite cookieの対応

Google Chromeではこの認証フロー中にapple側の認証前（1.の状態）、apple認証後（4.の状態）でセッションが変わってしまう問題が出る事に気付きました。 具体的にどういうことかというと、セッション情報はcookieに保持していて、長期間同一のセッションとして管理されています。 Google Chromeでは2020年ごろからデフォルトのcookieプロパティがLaxになっており、今回POSTでリダイレクトする際にこのセッション情報を管理するcookieが失われてしまうといった問題が出ました。

こちらの問題は前段で上げたdev.toの記事に紹介されている、リダイレクト先のscopeで有効なsamesite="none"のcookieを短時間で設定する方法で回避ができました。

ちなみにユーザー情報を連携しない場合はGETでリダイレクトすることが可能な為、上記のような対応で懸念点がある場合にはGETで実装することも可能です。他のサイトも参考に見てみましたが、GETで実装されているサイトが多い印象です。

利用者はメールアドレスの匿名化オプションと、転送停止設定が可能

もう一つ特徴的な機能がメールアドレスの匿名化になります。 エンドユーザーとしては、メールアドレスの流出を防いだり、メールマガジンなどの配信停止を利用するサイトにアクセスする必要無く対応できる点で、とても良い機能に見えました。

以下のような画面で非公開設定が可能で、匿名化されたメールアドレスは以下のような形式になります。

<ランダムな文字列>@privaterelay.appleid.com

運用する側では以下のような対応をする必要があります。

1. Appleサイトにて送信元メールアドレスとドメインを登録
2. 配信停止から配信再開になった場合を考慮して定期的なbounceリストの削除

2.について少し説明します。 くらしのマーケットではメール送信にSendGridを利用しているのですが、以下の操作をした後にメールを送信し配信に失敗した場合bounceリストに入ってしまいます。

• AppleIDのサイトからメールの転送を無効化
• AppleIDのサイトからアカウント連携を削除

まだ本番ではbounceは発生していないですが、QAテスト時には同じAppleアカウントの連携を削除して、くらしのマーケットのアカウントを削除して、また新しくアカウントを作成してテストなどをしていたので、メールが届かないなどの問題がありました。 こちらはbounceリストから該当のメールアドレスを削除することで対応が可能でした。

最後に

色々とハマりどころがあったのですが、なんとか対応できました。 iOSユーザーにとってはとても良い機能だと思いますので、是非使ってくださいね！

くらしのマーケット開発職向けの会社紹介資料を公開します！

こんにちは。みんなのマーケットでCTOをしている戸澤です。

みんなのマーケットでは採用を強化しており、 2020年11月から2021年2月の4ヶ月間で、開発メンバーだけでも18名が入社しています。

カジュアル面談や面接をしてきた中で、「当社が何を考えていて」、「今どんな状態で」、「これから何をするのか」が候補者に知られていないことに気が付きました。

そこでカジュアル面談や面接の中でお話している内容に加え、技術やプロダクト、働き方などの5つの項目をスライドにまとめて、公開します！

主な内容

• くらしのマーケット について
• 開発体制と技術スタック
• プロダクトでこれから目指すもの
• フルリモートワークでの働き方
• 評価制度と報酬

内容はくらしのマーケットの開発職であるエンジニア、プロダクトマネージャー(PM)、UI/UXデザイナー、QAに特化しています。

このスライドは今後も定期的に加筆、更新していく予定です。

会社紹介資料

全職種で積極採用中！

ご興味のある方は以下リンクより応募ください。カジュアル面談も歓迎です。 https://www.minma.jp/recruit

全員で会議できる時間をいもす法で探そう

こんにちは。SRE / バックエンドエンジニアのマノメです。

前回の記事 を読んで、以前私が思いつきで作った、「全員で会議できる時間はいつか？」を調べるコードを書いたことを思い出しました。
どういうものかというと、チームメンバーの数日間の出勤記録をもとに全員が揃っている時間を割り出す、という至ってシンプルなものです。

弊社では現在、コアタイムなしのフレックスタイム制で、多くのメンバーがフルリモート出勤です。
会議をしたい！となったらもちろん、開始時間を決めてその時間に出勤するようにするべきなのですが、とはいえ生活時間を急に変えるというのは朝が弱い私のような人間にとってはなかなか大変です。
なので、チームメンバーが全員揃う時間帯を割り出して会議を設置すれば、そういった杞憂をせず済むと考えたわけです。
特にチームの再編を行った際は、このデータが参考になるのではないでしょうか。
そういった私の思いつきでコードを書いたものの、そのときにはすでにチームができて数ヶ月経って会議時間も決まっていたため、誰にも披露することなくお蔵入りになりました。

今回は、このとき作ったコードを元に、累積和のアルゴリズムのことをちょっとだけ話そうと思います。

作ったもの

Go で書いています。
余談ですが、くらしのマーケットでは一部で Go が使われている箇所があります。

用意したデータ

A 〜 D の 4 人の出勤記録をテキストに書き起こします。
※記事のために適当な値を作っています

# A
08:54-17:24
09:42-17:37
09:39-18:24
10:46-19:33
# B
10:23-20:32
10:16-18:28
10:28-19:42
10:45-19:36
# C
10:08-18:32
10:07-19:48
10:00-19:49
10:11-19:27
# D
11:14-21:00
11:02-20:47
11:47-21:19
10:59-21:04

書いたコード

func main() {
    // データを読み込んでいい感じにする
    // [[As_start_time, As_end_time], [Bs_start_time, Bs_end_time], ...]
    input := read()

    data := make([]int, 60*24)
    for _, i := range input {
        // i[0] が 出勤時間, i[1] が 退勤時間
        data[i[0]] += 1
        data[i[1]] -= 1
    }

    // 必ず全員いる時間 = データの数
    max := len(input)

    // 全員いる時間を探す
    cur := 0
    isMax := false
    start, end := 0, 0
    for index, d := range data {
        cur += d
        // 全員が揃った時間の記録
        if !isMax && cur == max {
            start = index
            isMax = true
        }
        // 全員が揃っていた最後の時間の記録
        if isMax && cur == max-1 {
            end = index - 1
            isMax = false
        }
    }

    fmt.Printf("%d:%d - %d:%d\n", start/60, start%60, end/60, end%60)
}

結果

与えられたデータより、11:47 - 17:23 が適切な会議の設定時間となります。

解説

さて、アルゴリズムについての話ですが、今回使ったのは いもす法 という素晴らしいアルゴリズムです。
これは、累積和を用いて複数の要素の重なりや深さなどを計算するものです。

例えば以下のような出勤表があるとします。

出勤時間のグラフ

これをもとに、愚直に累積和のデータを作るならこうなるでしょう。

	08:00	09:00	10:00	11:00	~	17:00	18:00	19:00
A	0	0	1	1		1	1	1
B	0	1	1	1		1	0	0
C	0	0	0	1		1	1	0
合計	0	1	2	3		3	2	1

この「合計」の配列を用意して計算することになります。
ただ、プロットするのに以下のような処理が必要です。

input := read()
data := make([]int, 60*24)

// データのプロット
for _, i := range input {
    // i[0] が 出勤時間, i[1] が 退勤時間
    // 1 つのデータに対して、該当範囲を"塗りつぶす"イメージ
    for k := i[0]; k < i[1]; k++ {
        data[k]++
    }
}

max := len(input)

// シミュレート
start, end := 0, 0
isMax := false
for index, d := range data {
    // 全員が揃った時間の記録
    if !isMax && d == max {
        start = index
        isMax = true
    }
    // 全員が揃っていた最後の時間の記録
    if isMax && d == max-1 {
        end = index - 1
        isMax = false
    }
}

これは、人数(N) と 時間範囲(T) に対して、データのプロットに必要な計算量は O(N*T) 、シミュレートに必要な計算量は O(T) となり、合計で O(N*T + T) となります。

さて、いもす法を用いると、かなりシンプルに、計算量も抑えられます。
データの作り方が肝で、「出勤したら+1、退勤したら-1 する」という方法を取ります。

	08:00	09:00	10:00	11:00	~	18:00	19:00	20:00
A	0	0	+1	0		0	0	-1
B	0	+1	0	0		0	-1	0
C	0	0	0	+1		0	-1	0

よって、データのプロットは最初に書いたコードの通り、

for _, i := range input {
    // i[0] が 出勤時間, i[1] が 退勤時間
    data[i[0]] += 1
    data[i[1]] -= 1
}

となります。
この場合、データのプロットに必要な計算量は O(N) 、シミュレートに必要な計算量は O(T) となり、合計で O(N+T) となります。
処理がシンプルになり、計算量もかなり減ります。

これなら、人数が大幅に増えても計算量が大きくなりすぎないですね。

さいごに

結局、いもす法を使って作った「全員で会議できる時間を探す」というコード自体は、実用性があるのかないのかよくわからない結果になりましたが、いもす法は実際のデータ分析においてとても役に立つと思います。
例えばこのご時世ですから、部屋の中に一定以上の人数がいる時間帯を調べて換気の強さを調整するというのができそうですね。
くらしのマーケットでいうなら、登録している出店者のサービス提供が最も盛んな時間帯を調べたい、といった場面で役に立つかもしれません。

こういったアルゴリズムは知っているとひょんなことで役に立つかもしれないので、そういった知識を深める場として競技プログラミングはいい機会だと思います。
競技に参加しなくても、エクササイズとして過去問に取り組むだけで勉強になると思います。
ぜひ、挑戦してみてください！