BASE開発チームブログ

Eコマースプラットフォーム「BASE」( https://thebase.in )の開発チームによるブログです。開発メンバー積極募集中! https://www.wantedly.com/companies/base/projects

TerraformでNGTのポータブル環境を作った

はじめまして、BASEでSREに所属している浜谷です。現在は主にAWSを使用したインフラ構築と運用を担当しています。
そこで今回は前回好評だったBASEビール部部長が語ってくれた「Yahoo!の近傍探索ツールNGTを使って類似商品APIをつくる」のインフラ環境の構築についてお話をしようかと思います。

1. 背景

BASEでは機械学習の環境以前に今本番で何が動作しているのか、又その全体を把握するにはAWSのコンソールにログインして調査する方法しかありませんでした。 AWSの運用をしているとよくある事かと思います。
そんな中BASEではシステム全体構成図の見直しやサーバの一覧を自動化したりとインフラの見える化を進めています。
そこで次はインフラの構成管理を行っていこうといった流れがあり、まずはData Strategyチームの環境をTerraformで構成管理しようと相成りました。

2. 機械学習の環境

f:id:jhamatani:20180912101224p:plain

環境をサクッと説明するとS3に画像がアップロードされたら、SNSにイベントを送付します。 SNSからSQSやLambdaに振り分けて情報を蓄積し、蓄積したデータを元にECSのDockerで機械学習した結果をAPIで返すといったインフラ環境となります。 類似商品APIって何と詳細が気になった人はBASEビール部部長の記事を読んでみてください。

3. そもそも構成管理は必要?

運用をしていく為に構成を把握する事は必要不可欠です。 ただ私自身構成管理ツールの必要性をあまり感じていませんでした。

というのはSIerの出身なので設計書、手順書、運用のドキュメントは納品物なので時間を掛けて作るのは当たり前でした。 SIerのエンジニアはoffice製品でのドキュメント作りや成果物の承認に時間を割くことが多く、その上構成管理のツールまで必要なのって感じている人は少なくないと思います。 またドキュメントでの構成管理は構築を始めるまでに時間が掛かるのは当然といった考え方が前提としてあります。

しかし、BASEの行動指針の一つに「MOVE FAST」があります。 このMOVE FASTを実現するためには、時間が掛かるのは当然といった考え方を捨てる必要があります。 そこで構成管理ツールは必要不可欠なのです! 構成管理ツールを使用するとインフラをコードで管理できるので設計から構築までを一気通貫に実現できます。

4. なぜTerraformなの?

現在BASEではAWSをメインに利用しているので、AWS CloudFormationの方が良いかもしれません。
機械学習の環境においてGCPのBigQueryを使用する場面が今後発生してくるかと考えています。
その際にマルチプラットフォームに対応した構成管理ツールを選ぶ必要がありました。

5. コードでのインフラ管理

AWSを管理コンソールで構築しているとGUIベースで確認するか、ドキュメントベースで環境を把握する必要があります。
しかし、Terraform等の構成管理ソフトを使用するとコードベースで管理できます。

VPCをTerraformでコード定義すると以下のようになります。

resource "aws_vpc" "ds-image-processing-vpc" {
  cidr_block = "10.1.0.0/16"

  tags {
    Name = "ds-image-processing-vpc"
  }

  # We explicitly prevent destruction using terraform. Remove this only if you really know what you're doing.
  lifecycle {
    prevent_destroy = true
  }
}

コードで管理することでGitHubを利用した管理が出来ます。
GitHubはアプリエンジニアだと日常的に使用しますが、インフラエンジニアにとっては少し敷居が高く感じます。 私もBASEに入社するまでは殆どGitHubは使用していませんでしたが、今では普通に使用してレビューなどの履歴も残すことが出来てとても便利に感じています。 今まではインフラ構築のレビューをシステム構成図や設計書ベースでのレビューをしていたので、別途レビュー票を起こしたり等の手間が大幅に減りました。

f:id:jhamatani:20180912101551p:plain

またインフラ構成の変更をAWSのコンソールでを漏れなくチェックするのは非常に困難です。
しかし、GitHubを使用することで差分の確認をすることで、何を変更したのかも一目瞭然です。

f:id:jhamatani:20180912101546p:plain

6. 実際にTerraformを使ってみよう!

それではいよいよ実際にTerraformを使用してみましょう。
今回はハンズオンとして、RDSのAuroraとEC2のLinuxインスタンスを実際に作ってみます。

①まずはTerraformを実行出来る環境の準備をします。
 Terraformのダウンロード(URL:https://www.terraform.io/downloads.html
  ※バージョンは適時ダウンロードしたファイルに読み替えてください。
 ダウンロードしたファイルを展開して、環境変数にパスを通す。

$ mv terraform_0.11.4_linux_amd64.zip /usr/local/bin
$ unzip terraform_0.11.4_linux_amd64.zip
$ ls -l terraform 
 ※実行権限があることを確認
$ env | grep PATH 
 ※PATHに/usr/local/binが通っていることを確認
$ mkdir -p <作業ディレクトリ> 
$ cd <作業ディレクトリ> 

②GitHubにサンプルを用意しましたので、ダウンロードします。
 GitHubのリポジトリ:https://github.com/baseinc/Hands-on-Terraform
 Terraformのドキュメント:https://www.terraform.io/docs/providers/aws/

$ git clone git@github.com:baseinc/Hands-on-Terraform.git
$ terraform init
$ vi terraform.tfvars

 必要に応じて以下の内容を書き換えてください。

aws_access_key = "<AWSのアクセスキー>"
aws_secret_key = "<AWSのシークレットキー>"
aws_region = "ap-northeast-1"

main_aurora_root_user = "<auroraへのアクセスユーザ>"
main_aurora_root_password = "<auroraへのアクセスパスワード>"

external_ip = "<EC2にアクセス出来るIP>"
host_ssh_key = "<EC2にアクセスする際のキーペア名>"

③準備ができたので、Terraformを実行するだけです。

  • 実行前の動作確認(DryRun): $ terraform plan
Plan: 20 to add, 0 to change, 0 to destroy.

------------------------------------------------------------------------

Note: You didn't specify an "-out" parameter to save this plan, so Terraform
can't guarantee that exactly these actions will be performed if
"terraform apply" is subsequently run.

 上記の様に「20 to add」と表示されればOKです。
 20個のリソースがコマンド一つで作成されます。

  • 実行:$ terraform apply
Plan: 20 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

 「yes」と回答します。

aws_iam_role.db-main-aurora-monitoring: Creating...

 リソースの作成が開始します。

④リソース作成完了までは少し待ちます。

aws_rds_cluster_instance.db-main-aurora-instance.0: Still creating... (12m50s elapsed)
aws_rds_cluster_instance.db-main-aurora-instance[0]: Creation complete after 12m57s (ID: db-main-aurora-instance-0)

Apply complete! Resources: 20 added, 0 changed, 0 destroyed.

 これでAWS上にAuroraとLinuxのインスタンスが立ち上がりました。  どうですか、サクッと作れてしまいましたね。
 リソースが出来たかどうか、実際にAWSコンソールにログインして確認してみましょう!

f:id:jhamatani:20180912101538p:plain f:id:jhamatani:20180912101543p:plain

6. リソースを作った後は。。。

こんなに簡単に作れてしまうと、次から次へとリソースを作ってしまいますね。
そして放置なんてことになったら、AWSに多大な貢献をしてしまうことになりかねません。
ですので不要になったらきちんとお片付けを実施します。

  • 削除 :$ terraform destroy

コマンドを実行して削除完了と思ったら。。。。

Error: Error running plan: 1 error(s) occurred:

aws_route.db-vpc-route-external: aws_route.db-vpc-route-external: 
the plan would destroy this resource, but it currently has lifecycle.prevent_destroy set to true. 
To avoid this error and continue with the plan, either disable lifecycle.prevent_destroy or adjust the scope of the plan using the -target flag.

あれ?なんでだろう。。。エラーが出てしまいます。
理由は削除保護が有効になっていたからです。 VPCやDB等は間違えて消してしまうと想定外の影響が出てしまう可能性がある為、簡単に消せない様に削除保護prevent_destroy = trueをリソースに定義していました。
ただ、今回は消してしまいたいのでリソース上の定義を全てprevent_destroy = falseに変更して再度実行してみましょう。

Do you really want to destroy all resources?
  Terraform will destroy all your managed infrastructure, as shown above.
  There is no undo. Only 'yes' will be accepted to confirm.

  Enter a value: yes

「全てのリソースを削除しますが、良いですか」と聞かれます。
「yes」と回答します。

…
aws_subnet.db-vpc-subnet-d1: Destroying... (ID: subnet-0bae4cb4032d56f93)
aws_subnet.db-vpc-subnet-a1: Destroying... (ID: subnet-0a9d2118812674f12)
aws_subnet.db-vpc-subnet-c1: Destruction complete after 0s
aws_subnet.db-vpc-subnet-d1: Destruction complete after 1s
aws_subnet.db-vpc-subnet-a1: Destruction complete after 1s
aws_security_group.db-main-aurora-security-group: Destruction complete after 2s
aws_vpc.db-vpc: Destroying... (ID: vpc-0790adf505d9e6ac3)
aws_vpc.db-vpc: Destruction complete after 0s

Destroy complete! Resources: 20 destroyed.

今度は消えましたね。 また必要になったら、$ terraform applyで作り直しましょう。

まとめ

Terraformを使用することで新規作成から削除までコマンドで簡単に出来るようになりました。 今後、既存の本番環境のTerraform化や新規にプロダクトを開発している子会社のBASE BANKもTerraformを利用したりしているので、また機会があれば続きを書ければなぁと思います。

ランサーズ、ReBuild、BASEの3社合同のイベントで、「PHPバージョンアップと決済テストを支えたユニットテスト」について話しました

こんにちは!BASE Product Division サーバーサイドエンジニアの東口(@Khigashiguchi)です。主にEコマースプラットフォーム「BASE」の決済領域の開発や、BASE BANKというBASEの子会社にて金融事業の立ち上げを行っています。

さて、2018/8/7(火)に、ランサーズ、ReBuild、BASEの3社でエンジニア向けの勉強会「レガシーコード改革!UT/CIでWebサービスの技術的負債を解消する取り組み」を開催しました。

www.wantedly.com

そこで「PHPバージョンアップと決済テストを支えたユニットテスト」というタイトルで発表させていただきました。

f:id:khigashigashi:20180816100445j:plain

「レガシーコードを取り扱うためにどのようなユニットテストを書いていったか」について実体験ベースでの取り組みと得られた課題について話しています。 参加者の方からも、「実体験ベースでの知見が参考になった」といったフィードバックもいただけました。

登壇資料

この発表は、PHPカンファレンス関西2018にてLT発表させていただいた、テストを書いたことがないエンジニアがテストを書けるようになるまでやったことの詳細版として、以下のポイントについて言語化させていただきました。

  • テストがないコードに対して、どういう考え方でテストを書いていったか
  • チームとしてどうやってテストを広めようとしたか
  • 結果としてどのような課題があったか

実際にコードレベルでの説明にまで落とし込んでいるので、同じ課題を持つ方にとって一つの有益な知見として参考になれば幸いです。

また、今回はイベントタイトルが「レガシーコード改革!UT/CIでWebサービスの技術的負債を解消する取り組み」というものなので、「レガシーコード」をテーマとした発表になりました。
そのため、「レガシーコード」というテーマで発表するに当たり、主に下記の2点の書籍を改めて読み直して発表のコアとなる部分の言葉をお借りさせていただいています。

www.shoeisha.co.jp www.shoeisha.co.jp

とても参考になるので、今回の資料を入り口にそちらもご参考にしていただければと思います。

まとめ

Yahoo!の近傍探索ツールNGTを使って類似商品APIをつくる

はじめまして、BASEビール部部長の氏原です。BASEのData Strategy Groupで機械学習エンジニアをしています。 今回初登場ということで、暑いときにいいサワーエールのお話でも......といきたいところですが、ここは開発ブログということなので仕方ありません。開発のお話をしましょう。

現在私は商品の画像に基づいて、その商品に似た商品を類似商品として提示するAPIの開発を行なっています。今回はこのAPIをYahoo!さんのNGT(Neighborhood Graph and Tree for Indexing)を使って作成したことについて書いてみようと思います。

f:id:beerbierbear:20180814180938p:plain:w800

背景

BASE株式会社はネットショップ作成サービス「BASE」を運営しています。ここで作成されたショップはそれぞれ別のWEBサイトとして公開されていますが、ショッピングアプリ「BASE」では作成されたショップを横断して商品を検索し購入することができます。しかしショップの数は公称で50万店舗、非常に多くの商品がありますのでユーザーさんが興味を持つであろう商品をいかにして探しやすくするかはサービスにとって喫緊の課題と言えます。その取り組みの一環として、私は商品詳細ページにある関連商品の改善を目的に類似商品APIの作成を行っています。

全体の概観

類似商品APIは以下の3つの構成要素で成り立っています。

  1. 画像の特徴量抽出
    • 新しい商品画像がサービスに登録された際に特徴量を計算して保存する
  2. 特徴量のindexing
    • 関連商品として出す商品の画像を選別して近傍探索用のindexを作成する
  3. API
    • 検索元商品の画像から近傍の画像を探索しその画像に対応する商品を類似商品として返す

ではそれぞれについて解説していきましょう。

画像の特徴量抽出

BASEには毎日結構な量の商品が新しく登録されていきます。既存の商品の画像を差し替えたりすることもあります。それらの新しい画像の特徴量は随時計算しておかないといけません。

特徴量抽出の全体構成

BASEでは商品画像をS3に保存しています。S3ではファイルが登録されると、そのことをイベントとして通知できます。特徴量抽出ではそれを利用して以下のようにシステムを組んでいます。

f:id:beerbierbear:20180814175019p:plain:h300

S3, SNS, SQS

S3で画像が登録されると、そのイベントをまずSNSに投げます。そしてSNSはそのイベントをそのままSQSに投げます。

一旦SNSを通しているのは、画像登録を契機に何かしらの処理を行いたいという要望は今後他にも出てくることを想定しているためです。SNSであればsubscriberを増やせばイベントをbroadcastできます。

こうしてS3に登録された画像はイベントとしてSQSに溜まっていきます。

ECS

SQSに溜まったイベントを取りに行くのがECS配下で稼働しているServiceです。ここではSQSからイベントをpollingして、取得したイベントから画像を取得して一枚づつ特徴量を計算してDBに保存していきます。ECSはAuto Scalingと組み合わせればSQSが溜まってきたときにServiceを増やすのが簡単です。

画像の特徴量

みなさん、画像の特徴量といえば何を思いつきますか?SIFTとかHOGでしょうか。最近ですとDeepLearningでしょうか。今回、画像の特徴量の抽出にはMobileNetを利用しました。

いちからMoblieNetを作るのではなく学習済みモデルをそのまま利用しました。Kerasのやつですね。ホント楽になりましたね。

from keras.applications.mobilenet import MobileNet

model = MobileNet(weights='imagenet',
                  include_top=False,
                  input_shape=(224, 224, 3),
                  pooling="max")

include_topはFalseにしてクラス分類のネットワークは外して特徴量を抽出する部分だけ使います。画像はもう単純に224×224にリサイズして使います。これで224×224のRGB画像からfloat32の1024次元のベクトルが得られます。

from keras.applications.mobilenet import preprocess_input
from keras.preprocessing import image

import boto3
import keras.applications.mobilenet
import numpy as np

import io

# S3から画像を取ってくる
s3 = boto3.resource('s3')
img_object = s3.Object(bucket, object_key)
response = img_object.get()
# 画像を読み込む
img_data = io.BytesIO(response["Body"].read())
img = image.load_img(img_data, target_size=(224, 224))
# numpyのarrayにしてMobileNetの前処理をする
x = image.img_to_array(img)
xs = preprocess_input(np.array([x])
# 特徴量を計算する
vec = model.predict(xs).flatten()

特徴量を保存するDB

上で得られた特徴量はDBに保存しておきます。 今回特徴量を保存するのにはAuroraを利用しました。1024次元のfloat32のベクトルを保存するのに容量あまり気にしないでもいい場所が欲しかったためです。でもRDSとか単にベクトル保存する場所としては機能過多ではあります。必要な機能を考えると単なるKey-Value Storeでいいんですが、ここは今後も要検討です。

特徴量のindexing

画像登録に連動してDBに特徴量を保存できるようになりましたが、サービスで使うにはある画像の特徴量vectorの近傍にあるvectorがどれなのかを知ることができるようにしなくてはいけません。これを実現するために今回はNGTを利用しました。

NGTとは

Yahoo!さんの説明をそのまま引用させていただきます。

NGTは任意の密ベクトルに対して事前に登録した(同次元の)ベクトルから最も距離が近いベクトルの上位数件(k件)を高速に近似k最近傍探索(k-Nearest Neighbor Search)するためのソフトウエアです。 高次元ベクトルデータ検索技術「NGT」の性能と使い方の紹介

超高速に近傍のベクトルを探せるソフトです。本当に超高速です。350万件の1024次元のベクトルを登録してみたところ、メモリを15G程度食いますが近傍1000件取ってくるのに数十msくらいしかかかりません。これならキャッシュを併用すれば十分使えると判断しました。 python wrapperもあるので使うのも簡単です。

index作成の全体構成

ECS Taskを利用したバッチ処理でNGTのindexを作成しています。

f:id:beerbierbear:20180814175146p:plain:h300

ECS

indexの作成は日次バッチで行うのでCloudWatch Eventをdailyで投げるようにして、ECSがそれを受け取ってTaskを実行するようにしました。 TaskはAuroraからindexingする特徴量を取得してNGTに登録します。このとき全部の特徴量を使うのではなく、古い商品は登録しないなどある程度の取捨選択をしています。

NGTはpython wrapperを使ってこんな感じです。(適当に簡略化してます)

from ngt import base as ngt

ngt_index = ngt.Index.create(b"any/where/you/want/to/save/index", 1024)

# 結果は大きいのでサーバーサイドCursorつかう
conn = MySQLdb.connect(..., cursorclass=MySQLdb.cursors.SSCursor)
cursor = conn.cursor()
cursor.execute(......) # 画像の特徴量とかとってくる

# 大きくて全部持ってこれないから一個づつ処理
for row in cursor:
    image_id, vec = row
    oid = ngt_index.insert_object(vec)
    # NGT内でのobject idと画像のIDの紐付けは自分で覚えておく必要あり
    ...

# indexの作成
ngt_index.build_index(num_threads=8)

S3

作成されたNGTのindexはS3に保存しています。indexは毎日作成され、ある程度の期間保存して古いものは捨ててます。

API

NGTのindexが日々作成されるようになりましたので、今度はそれを利用する部分を用意しましょう。

API提供部分の全体構成

f:id:beerbierbear:20180814175216p:plain:h150

構成としてはAPI Gatewayを入り口としたECSの二段構えになっています。 これは類似商品を取得するという機能と類似画像を取得するという機能を分離させておくことで、類似画像APIを利用した他の機能の開発を簡単にするためです。例えば、現在BASEの商品の画像検索APIも開発中ですが、これはこの仕組みにそのまま乗っかっています。

f:id:beerbierbear:20180814175234p:plain:h300

類似商品API

ここは以下のような役割を受け持ちます。

  1. API Gatewayから商品IDを受け取る
  2. 商品IDを対応する画像IDに変換する
  3. 画像IDを類似画像APIに投げ、類似画像のIDを受け取る
  4. 類似画像のIDを対応する商品IDに変換する
  5. 類似商品のIDをAPI Gatewayに返す

やってることはシンプルです。 構成のところには出ていませんが、毎度類似画像APIを呼ばなくてもいいようにElastiCacheを設置して、類似画像APIを呼ぶ前にそっちを確認しています。

類似画像API

ここはNGTの薄いwrapperになってます。やっているのは画像IDや画像の特徴量そのものを受け取り、近傍の画像のIDを返すだけです。 ここはindex作成が終わったときに新しいindexを読むように再起動されます。この再起動はECSの仕組みを使って複数動いているECS Serviceを少しづつ再起動させていくことでサービスとしては無停止で行われるようになっています。

実際にどう変わるか

では、構築したAPIで類似商品がどの程度改善したかみてみましょう。

f:id:beerbierbear:20180814175959j:plain:h600

この洋服の関連商品は以前のロジックだと以下のようになってました。

f:id:beerbierbear:20180814180047j:plain:h600

うん、服ですらないですね。 正直どうしてこれらが関連商品に上がってきたのか謎です。名前だろうか。

で、それが今回のAPIで以下のように改善しました。

f:id:beerbierbear:20180814180241j:plain:h600

おお!服だ! ......まあそれだけで感動できるほど前のが悪すぎたという話もあります。 雰囲気もなんとなく似てますかね。ファッション系は概ね良い感じに類似商品を出せるようになりました。

まとめ

私の所属しているData Strategyチームは最近できたばかりで、まっさらなAWS環境を渡してもらってインフラ含めて一から類似商品APIを構築するというなかなか楽しい経験をさせてもらいました。まだまだ精度を上げたいところではありますが、そこそこ良いものができたのではないかと思っています。 実際関連商品のタップされる率は今までの2倍ほどに伸びており一安心というところです。

今回構築した類似商品APIでは今のところ画像しか見ていません。そのため少々コンテキストから外れたものが出てくることもあります。そこで現在商品のタイトルや説明も考慮するようにAPIをアップデートしようとしているところです。もっと精度を上げて、私がいいビールを探せるように......いえ、ユーザーさんがいい商品をみつけられるようにこれからも頑張ります。

開発した成果は、ショッピングアプリ「BASE」で見ることが出来ます。個別の商品を見るビューをスクロールして「関連する商品」をぜひご覧下さい。

P.S.

長くなるんで省きましたが、実は今回作ったAPIのAWSの構成管理はTerraformで書いて1発で構築できるようにしています。その話はまたの機会にしたいと思います。

PHPカンファレンス関西2018・非公式前夜祭 にシルバースポンサーとして参加 & 2夜連続LTしてきました

こんにちは!BASE Product Division サーバーサイドエンジニアの東口(@Khigashiguchi)です。主にEコマースプラットフォーム「BASE」の決済領域の開発をしています。

さて、この度、BASE株式会社は7月14日(土)に開催された「PHPカンファレンス関西2018」にシルバースポンサーとして協賛いたしました。 私は当日スポンサー担当として参加し、前日に開催された「PHPカンファレンス関西2018非公式前夜祭」と合わせて2夜連続でLT発表してきました。 また、同じくBASE Product Divisionの田中(@tenkoma)も本編の懇親会にてLT発表いたしました。

PHPカンファレンス関西2018

2018.kphpug.jp

PHPカンファレンス関西は、大阪・梅田のグランフロント大阪で開催され、全国のPHPerが集結したイベントになりました。

f:id:khigashigashi:20180724142850j:plain
メイン会場の様子

BASEは、シルバースポンサーとして協賛いたしましたので、オープニングにてBASEを紹介していただきました。

発表内容

本編

本編では、「テストを書いたことがなかったBASE入社前から現在に至るまでテストに対してどういう取り組みを行ってきたか」をぎゅっと5分に詰めて話しました。

f:id:khigashigashi:20180724142907j:plain
LT発表中の様子

内容を詰めたので、ある意味「LTっぽく」スピード・テンポ感重視のプレゼンではありましたが、要点と随所のポイントは無事伝わったようで「一部実践してみよう」という反応をいただけたので良かったです。

懇親会

こちらは、先ほどご紹介した田中(@tenkoma)の発表です。 CakeFest2019というCakePHPにフォーカスしたカンファレンスの候補地に日本が入っており、「みんなで日本開催に投票しよう!」という話をしました。

f:id:khigashigashi:20180724142927j:plain
懇親会LTの様子

7月30日まで投票中なので私もこのブログが書き終わったら投票します!

非公式前夜祭

非公式前夜祭では、PhpSpreadsheetというライブラリを扱う上でトラブルシューティングについて話しました。 

f:id:khigashigashi:20180724142945j:plain
非公式前夜祭での様子

「PHPでExcelを扱ったことがある方」が参加者の方に多かったので、「あるある」という共感をいただきながら、ラフに話させていただきました。

まとめ

PHPカンファレンス関西2018にスポンサーし、せっかくの大阪遠征なので張り切って2夜連続LTにチャレンジしてみましたが、充実感があって楽しかったのです。 ただ、個人的な反省としては両日資料完成が発表直前になるくらい追い込まれたので資料準備はより計画的にしないとです。 もし来年参加される方はチャレンジしてみてはいかがでしょうか。

続きは8/7 (火)の勉強会で

今回、PHPカンファレンス本編で5分に詰め込んだテスト関連の話を15分に伸ばした詳細版を、8月7日(火)に開催するエンジニア向け勉強会にてお話しします。ランサーズさん、ReBuildさんにもお越しいただき、CIや技術的負債を解消する取り組みについてお話ししていただきます。

ご興味のある方はぜひ下記のページよりお申込みください。

base.connpass.com

「お母さんも使える」サービスはどう生まれているのか? BASEのデザイン思想

f:id:lllitchi:20180711134528p:plain

こんにちは、BASEのDesign Groupに所属している北村です。
現在は主にプラットフォームとアプリのデザインを担当しています。

BASEのデザインチームはここ数年で一気に人が増え、社内でも大所帯の部署へと成長しました。今回は、BASEのデザイナーが日々の開発でどんなことを行い、どんなことを考えているのかについてご紹介したいと思います。

1. BASEのデザイナーの役割

プロジェクトの共通認識を作る仕事

BASEでは仕様検討の段階からデザイナーが入り、プロジェクトの担当者と一緒に開発要件を詰めていきます。ときには箇条書きの要件書からワイヤーを起こし、UIをアウトプットしていきます。画面デザインが先にあると、メンバー同士のコミュニケーションがスムーズになり、かつ他部署との認識合わせも円滑になるため、BASEの開発フローでは まずデザインありき という文化が浸透しています。また単純に、先にデザインがあると実際の画面をどう作っていけば良いのかチームの皆で把握しやすい、という利点があります。

プロジェクト内で共通認識となるアウトプットを担うのが、BASEのデザイナーの仕事のひとつです。

BASEにおけるデザイナーの責任

BASEでは基本的に、プロジェクトにアサインされたデザイナー本人がデザインクオリティのチェックを行います。

さらに、担当デザイナーが自分で画面のUIを実装することも多いです。最近はフロントエンドエンジニアも増えたので分業が進んではいますが、例えば細かなインタラクションの実装やUIの改修などはデザイナー自身が積極的に行っています。 画面のUIを設計するだけでなく、最終的なUXの担保まで担うのが、BASEのデザイナーの責任範囲になります。

2. BASEのデザイン思想と、大切にしていること

「お母さんも使える」という共通言語

BASEには社内全体の共通言語として「お母さんも使える」という思想が存在しています。

これは、BASE創業当時から変わらない哲学で、代表取締役CEOである鶴岡の強いポリシーであり、「BASE」の重要なコンセプトです。

というのもこのコンセプトは、「BASE」のサービス立ち上げのストーリーにまつわります。鶴岡の母は、大分の商店街で洋品店を営んでいますが、「ネットで服を売ってみたい」と鶴岡に相談があったので、楽天のような大手のECモールを使ってみるよう勧めましたが、使い方が難しくてできないと母から返ってきます。

その際に鶴岡は、母と同じような悩みを持っている人が世の中にたくさんいるのではないかと感じ、「BASE」の開発を始めた、という背景があります。

お母さんのために、良くも悪くも「機能をつけない」

便利だけれど使い方が難しい機能よりも、いかにクリック数を少なくして、簡単にショップを開設・運営してもらうかが最優先事項になります。

4、5クリックしなければならない機能より、2、3クリックで完了する機能を開発・提供する。たとえば、ユーザが一番使用する管理ページには、あえて機能をつけないなど、設計については、当初から「ユーザの手間を減らすための開発」を意識していました。

現在、BASEチームには13人ほどのエンジニアがいますが、新しい機能ができてもチーム内で「この機能は、お母さんたちには使えないのでは」となったら、たとえ便利そうな機能でもリリースしていません。

出典:お母さん目線で作ってみたら、「BASE」はシンプルなサービスになった

BASEではプロダクトの開発中、あらゆる場面・文脈で「お母さん」という単語が出てきます。「これって複雑すぎてお母さんは使えないよね」や「この説明、お母さんに伝わるのかな?」など、議論の主語となることがとても多いです。

複雑な仕組みだったとしても、お母さんも使えるくらい簡単なサービスとして提供するのが、プロダクトを作るときに最も大切にしている思想です。

誠実さを大切にしている、BASEのデザイン思想

「お母さんも使える」を実現するために、デザイナーで作成したデザイン思想があります。

f:id:lllitchi:20180711121335p:plain

  • 誠実であること
  • あらゆるユーザに寄り添える、柔軟な拡張性
  • 価値を最大化させる新しいショップ体験
  • 「お母さんも使える」親しみやすいサービス
  • 簡単じゃないものを簡単に

BASEのデザイナーはなによりも「誠実」さに重きをおいています。

例えばユーザが何かものを売りたいと思ったときに、今までだとハードルが高くて気軽にできなかったものを、誰でもできるようにするのがインターネットの力で、BASEはそのインターネットのポジティブな力を信じてサービスを作っています。

一方で、インターネットがインフラとして広まっていく上で負の側面もあり、伝え方次第では誤った情報が多くの人に広まってしまったり、誰かを傷つけてしまうことがあったりします。

そういった意味で、デザインの役割は非常に重要です。多くの人に影響を与えるインターネットというインフラ上でサービスをデザインする以上、誠実さを忘れてはいけない、という思想を大切にしています。

3. デザイン思想を実現するワークフロー

では実際に、2 のデザイン思想を実現するために行っているワークフローをご紹介したいと思います。

BASEにおけるデザインのフロー

  1. PMやディレクターから機能要件がくる
  2. 要件・仕様を元にデザイナーがワイヤー、またはプロトタイプを起こす
  3. 起こしたデザインを「UI/UXミーティング」でレビューする
  4. 実装に入る

週2回おこなわれるUI/UXミーティング

BASEでは週に2回、UI/UXミーティングという場が設けられています。 このミーティングでは、各デザイナーそれぞれが担当しているプロジェクトのUIをレビューしてもらいます。

(プロジェクトの粒度によってまちまちですが)鶴岡、PM、ディレクター、プラットフォームデザイナー、アプリデザイナー、フロントエンドエンジニア、CSが一堂に会し、デザイナーの作成したUIを見ながらみんなで議論し合います。

他のデザイナー目線でのUIに対するダメ出しも含め、ビジネス視点からの要望や、実装に対するツッコミ、全体のUXへの指摘など、多角的な意見が入ります。もちろん「そもそもその機能って必要なの?」という意見が出ることも多々あります。そこをまとめて取捨選択するのもデザイナーの役目です。

たとえ途中で仕様が変わろうとも

プロジェクトのメンバーだけでは把握できなかったより大きなユーザ体験が、UI/UXミーティングでの議論で見えてくる部分もあります。先日公開されたエンジニアの日比野柳川 の記事でも書かれていましたが、BASEではプロジェクトを進行してゆくなかで「ちゃぶ台返し」が起こるポイントがしばしば発生します。

デザイン目線でいうと、例えば

  1. 「簡単じゃないものを簡単に」が満たされてない
  2. 「親しみやすさ」が満たされてない
  3. 「価値を最大化させるショップ体験」が満たされていない
  4. 「お母さんも使える」が満たされてない

この部分の踏み込みが甘く、議論が充分でないままプロジェクトが進んでしまった時に、UI/UXミーティングで指摘を受けることも多いです。 これはBASE全体にデザイン思想が浸透しているからこそ起こる議論で、たとえもう一度仕様を練り直すことになったとしても、より良いものを作る努力は惜しまない、納得するまで議論する、というBASEの「SPEAK OPENLY」のあらわれだと思っています。

まとめ

BASEのデザイナーは裁量が多く、担う範囲も広いですが、開発の上位レイヤーから関われる環境というのはやはりやり甲斐があります。
誠実にサービスを作る、というBASEのデザイナーが大切にしている思想に共感してくださった方、一緒サービスを作りましょう!
デザイナーを随時募集しています!

jobs.binc.jp