BASE開発チームブログ

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

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

PHPカンファレンス福岡 非公式前夜祭リジェクトコンでPHPアプリのテストスイートのカスタマイズについて発表してきました & カンファレンスレポート

f:id:tenkoma:20180615194143j:plain

こんにちは、Back-end Engineer の田中 @tenkoma です。ショッピングアプリ 「BASE」向けAPIの開発を担当しています。

去る6月16日に福岡で開催された「PHPカンファレンス福岡2018」に参加してきました。当日は一般参加でしたが、前日に開催された非公式前夜祭 リジェクトコンで発表してきたのでブログでもご紹介します。

BASEのPHPアプリケーションは2018年5月にようやくPHP7化が完了しました。 アップデートプロジェクトの中でユニットテストしやすくするためにテストスイートをカスタマイズしたので、発表で3つほどをTipsとして紹介しました。

紹介した3つのTipsについてこの記事でも説明します。

Tips 1. assertSame() で配列のdiffを出力できるようにする

PHPUnit 7 で assertSame()配列のdiff を出力できるようになりました。CakePHP2アプリ(データ形式として配列を多用する)で使えるとありがたいのですが PHPUnit 7 の利用は難しそうです。そこで、配列のdiffを出力できるように移植してみました。以下のように出力されます。

SampleTest.php

<?php
App::uses('ExtendTestCase', 'ExtendTestSuite.TestSuite');
class SampleTest extends ExtendTestCase
{
    public function testAssertArray()
    {
        $actual = ['User' => ['id' => 1, 'name' => 'Taro']];
        $expected = ['User' => ['id' => '1', 'name' => 'Taro']];
        $this->assertSame($expected, $actual);
    }
}

出力

There was 1 failure:

1) SampleTest::testAssertArray
Failed asserting that Array &0 (
    'User' => Array &1 (
        'id' => 1
        'name' => 'Taro'
    )
) is identical to Array &0 (
    'User' => Array &1 (
        'id' => '1'
        'name' => 'Taro'
    )
).
--- Expected
+++ Actual
@@ @@
 Array &0 (
     'User' => Array &1 (
-        'id' => '1'
+        'id' => 1
         'name' => 'Taro'
     )
 )

テストが失敗したときかなり原因がわかりやすくなるので、すぐにPHPUnit 7にアップグレードできない場合は以下のコードを実装すると便利です。

Tips 2. テストスイート向けにユニットテストを書く

setUp(), tearDown() などに記述したコードをどうテストするか、という話で test for test cycle(setUp/tearDown) #1 のようなテストコードを書きました。 スライドの最後で、CIで複数のPHPバージョンでテストした話をしましたが、そのためのCircleCIの設定は.circleci/config.ymlのようになっています。

Tips 3. runkit, php-timecopのコードをIDEで補完するためのスタブ

PhpStorm組み込みのスタブファイルに無いrunkit, php-timecopのようなPHP拡張のコードを補完できるようにするものです。以下のリポジトリをgit clone してIDEの include_path に追加してお使いください。

カンファレンスレポート

以下はカンファレンス当日・非公式前夜祭後夜祭のレポートです。来年も開催されるらしいので、参加したい方の参考になれば幸いです。

前日に福岡入り (6月15日・金)

PHPカンファレンス福岡を楽しむには前日入りが必須。13:30頃に福岡空港に到着しました。

このときまだリジェクトコンの資料が仕上がっていなかったので博多駅近くにとったホテルで資料の手直しをしました。

リジェクトコンの会場であるLINE Fukuoka株式会社と同じビルの1Fで知り合いの方と一緒に食事を取り、19:00 に会場到着しました。 以下、発表前の現場の様子です。

f:id:tenkoma:20180628111750j:plain

発表順は1番目。印象に残るようGitHub Username Shirtを着て発表しました。

カンファレンス本編より多い同時3セッション。だれも聞きに来なかったらどうしようと思いましたが、多くの人に聞いていただけたようです。

PHPカンファレンス福岡2018 当日 (6月16日・土)

f:id:tenkoma:20180616101153j:plain f:id:tenkoma:20180616101639j:plainf:id:tenkoma:20180616101627j:plain

PHPカンファレンス福岡は去年初参加でした。そのときは前日午前2:00くらいまで懇親会に参加した結果当日1時間以上遅刻してしまいましたが、今年は午前10時に間に合いました。

「PHPカンファレンス福岡2018」は同時2セッションです。2つの会場は両方とも席に余裕がある感じで出入りがしやすかったです。

参加したセッションについて紹介します。

MySQLで画像 を扱うメリット・デメリットと障害・解決事例

以前実装してみたことがあり、メリット・デメリットについて実感したので、さらに学ぼうとおもい参加。 発想としては思いつきがちですが、適用するメリットの大きいケースは限られそうですね。

ログの設計してますか?PSR3とログ設計の話

何をログに残せば良いかで迷うことが未だにあり、周辺知識を強化したくて参加。ログのリスクの部分を一番集中して聞いてました。

Event Sourcing,CQRS For PHP Application

複雑化するサービスのための設計パターン、アプリケーションとミドルウェアの組み合わせ例紹介。扱うデータやトランザクションが増えたり、集計分析などのシステムがあると必要とされそうに思いました。

Testing Live!!!

実際のWebサービスに対して探索的にテストを行い、問題を探すデモでした。5分という短い時間でアプリケーションに潜む不整合が見つかり、会場がすごく盛り上がってました。

PHP 5.3 + CakePHP1.3 バージョンアップ報告

去年、同じくPHPカンファレンス福岡で発表された計画の現状報告。BASE もCakePHPを利用しているので、気になりました。

物理層のこと、時々でいいから、思い出してください。

システムの物理層というより物理インフラ構築運用について面白おかしく紹介。失敗談が聞いていて面白すぎました。

その他

スポンサーブースも参加者に足を運んでもらえるようAsk The Speakerコーナー(セッション後に発表者に直接質問できる場所)とコーヒーが用意されており、いつ行っても賑わっていました。

翌日 (6月17日・日)

去年同様、株式会社Fusicのセミナールームで開催されたので参加しました。参加者各自で自由に作業しながら、発表したい人が自由に発表するようなゆるやかな集まりでした。

僕は前夜祭で発表した内容のコード tenkoma/extend-cakephp2-testsuite-example の準備をしていたのですが、飛行機の都合で2時間ほどしか参加できませんでした。

来年もし開催されるなら、絶対フルで参加できるように調整します!

まとめ

  • 非公式前夜祭 リジェクトコンで発表しました
  • PHPカンファレンス福岡、フルで楽しむなら前後のイベントもチェックしてみるのがオススメです。

スタートアップでもSIerの経験はバッチリ役に立つ~ショップコインをリリースしました~

f:id:gimutokenri:20180619154450p:plain こんにちは、BASEのPayment Engineer Groupに所属している柳川です。

先日BASEではショップコインという新機能をリリースしました。ショップコインの説明を簡単にすると、BASEをご利用いただく各ショップさんが、独自にショップで使えるコインを発行することで、ショップさん独自の経済圏を作れる機能です。詳しい説明はこちらをご覧いただけると幸いです。 私はこの機能の開発でサーバーサイドエンジニアとして設計、開発、リリースを行いました。

今回は開発者ブログの記事ということで、開発していて気がついたことをまとめてみたいと思います。

事前情報

プロジェクトの特徴

  • 修正範囲がでかい

    • 新規コード+既存の決済コードに手を入れる
    • 端的にいうと新しく決済方式を作るということ
  • 開発量に対して実装者が少ない

    • サーバーサイドエンジニア:1人
    • デザイナー:2人

私の特徴

大規模開発をしていたSIer出身。

プロジェクトの情報と私の特徴から、SIer時代の開発経験をうまく活かせば、上手にプロジェクトを回せるのではとうっすら考えながら開発に挑むのでした。

やったこと

UMLを書いた

開発が始まる前に、自分の中で以下のことを確認したいと考えUMLを書きました。

  • ヒト
  • モノ
  • コト
  • カネ

このあたりのことを詰めると、実装の漏れが防げると考えてのことでした。

SIerからスタートアップに転職してからは、関係者の人数が少ないことや、スピードが求められることからこの工程を省くことも多かったのですが、今回はそうも言ってはいられない物量であると考えてSIer時代の知識を引っ張り出してきました。このとき書いたUMLが、人に設計を共有する上でも役に立ちました。少人数で開発していると、開発中の内容がブラックボックスと化してしまうきらいがありますが、その点を少なからず軽減できたのではないかと思います。

また図に起こすことで、エンジニア以外も直感的に機能の把握が行えたようです。弊社がドキュメント管理ツールとして使用しているDocBaseにてPlantUMLの記法が使用できるため、そちらを使用してUMLを記述しました。文章でダイアグラムの作成ができるので、通常のドローイングツールに比べ、あとからの変更が非常に容易でした。おすすめです。

設計書を書いて設計書のレビューをした

転職後はあまり行ってこなかった、設計書自体のレビューをしました。

小さな機能開発であれば
頭の中や手元のメモで設計→実装→コードレビュー→リリース
この流れで、進めて大きな問題はないように思います。

しかし今回は開発量の多さが懸念されたため、SIer時代を思い返して、設計書をある程度書いて、なおかつ設計書のレビューもしようと考えました。致命的な指摘等炙り出せたので、本当にやってよかったと思いました。

ちゃぶ台返しポイントを積極的に作った

SIer時代の経験を思い出して辛いのが大幅な手戻り、いわゆるちゃぶ台返しというやつです。

残念ながら自社プロダクトの開発でもちゃぶ台返しは起こります。大切なのはいかにちゃぶ台返しのインパクトを少なくして、プロダクトのクオリティの向上に活かすか。ちゃぶ台返しは敵ではなく、味方なのです。今回はちゃぶ台返しへの対抗手段として、いろいろなところで細かくちゃぶ台返しを起こさせるという作戦を取りました。

  • 設計書のレビュー
  • 複数回のコードレビュー
  • 出来ている場所までをデプロイして操作してもらいながらのレビュー

上記のように開発期間中に数々のレビューをはさみました。

ちゃぶ台返しの回数こそ多くなったような気はしますが、結果的に工数が収まった上でクオリティを上げられたのではないかと思います。ポイントとしてはSlackでレビューを依頼をするだけではなかなか見てもらえないので、必要と思うタイミングで必要な人には明確に時間を取ってもらいレビューを行うことです。他力本願は駄目!

リリース前にQAプロセスを入れられたこと

今回少人数での開発、かつ開発量が多かったこともあり、明示的にQA期間を設け、リリース前の検証を行いました。機能の開発に関わっていないメンバーの新鮮な目で、QAをおこなってもらうのは、実際にバグが潰せるのはもちろん、精神的にも大きな助けとなりました。

うまくやれなかったこと

リリースの単位がでかくなってしまった

この発表資料を読みながら反省したのですが、リリースの単位がでかくなってしまったのは反省点かなと思います。後で確認する範囲がでかくなるだけなので、できるだけ細かく早く出すべきだったと思います。ただすぐには本番稼働しないコードを本番に組み込むのも影響確認とロールバックという点でどうだろう、というのはあるので難しいところかなとも思います。

リリース前の忙しい時期がうまく回らなかった

開発自体は、少ない人数でも段取りをしながら進めることが出来たのですが、リリース直前に立て込んでくると、開発作業とそれ以外作業の帽子をかぶり直すことが出来ませんでした。特にリリース前のQA作業を行うことと、バグを修正することを同時に行うのが厳しかったです。リリース直前に忙しくなることがわかっているなら、極力帽子をかぶり直すことなく進められるように、人をアサインしてもらうなどで準備するべきでした。

開発範囲が少ない場合は、できるだけ一人でやったほうがスピーディーに進められますが、ある程度開発範囲が大きくなると、各人が各ロールに分かれた体制を作ることに強みが出てくるのだろうなと思いました。このあたりは今後の課題かなと思います。

また、自分が今何に集中すべきかを客観的に考えるのが大切だと感じました。テンパらない。

まとめ

大きめの機能開発を、主導する立場として担当させていただき、非常に勉強になりました。まるごと任せていただけたからこその気付きが多かったように思います。特に設計書を作る、開発プロセスを明確化する等のSIerで培った技術が役に立ったのはいい経験でした。

SIer時代は、最初から決まりとしてあった開発の手順に窮屈感を感じることもありましたが、実際になんのために行うのかということを考えて、開発中の課題と照らし合わせていくと、力となる部分は無数にあるなと感じました。

当たり前ですがSIerでもスタートアップでもアプリケーションを作るという上では同じです。アプリケーション開発の道具として使えるソフトウェアの開発手法を、積極的に取り入れていくべきだと感じました。すべての開発工程が最初に描いたとおりに進んだわけではありませんでしたが、それも含めいい経験でした。忙しく開発作業を終えたあとは、知識の吸収が早い気がするので、振り返られなかった分をしっかり振り返って、学ぶべきものを見定め学んで、次に活かしたいです。日々勉強。

最後に

BASEでは、様々な経験を活かしながら一緒に未来を作っていく仲間を募集しています。前向きかつ自由にやっていけるのは間違いない環境です。 ご興味を持たれた方は以下の採用情報から!

jobs.binc.jp