見出し画像

おやつスタートアップのフロントエンジニアって何してるの?

こんにちは、スナックミーCTOの三好です。
今回はスナックミーのフロントエンドについて少しお話させてください。フロントについて何かを書くのは初めてだが、スナックミーのフロントエンドはおやつ体験を提供するのにとても大事なこと。そのため、フロントエンドエンジニアの方はぜひこのnoteを読んでいただきたい。

マイページ

画像1

フロントエンドの開発は主にマイページの機能開発がメインになります。例えば上記画像のページ(コンテンツ)が存在します。

限定商品: 通常のBOX以外の商品を購入することが可能。例えば、アイス、コーヒー、ホットケーキミックスなど通常のBOXで表現できないおやつを提供。
リクエスト: 食べてみたいおやつがある場合、リクエストすることで次回以降のBOXに入る可能性があります。また、苦手な場合は入れないで欲しいというNG登録が可能。
myおやつ: 発送日ごとに届いた自分だけのおやつ一覧。評価やおやつのお届け回数がわかり、味覚や食感などの詳細評価なども可能。

のような追加・改修開発をすることとなり、その他にも、原材料などの好き嫌い登録や、友達紹介、SNSシェアなどがあります。

フロントの技術スタック

画像2

主にフロントエンドはReactで実装され、コンポーネントの管理をStorybookやstyled-componentsを用いています。テストはjest、エラー検知などのログ管理はsentryを用いて、異常値があった場合に対応できる仕組みも整えています。
エンジニアチームの共有認識として常に新しい技術・ツールに対してアンテナを張り、取り入れていくスタンスを創業当初から意識しています。フロントの技術スピード(JS)は速い印象ですが、その分パフォーマンス向上や実現可能範囲も広がっていると感じています。数ヶ月前まで実現し辛い部分が容易なることが多々ある。フロントエンド特にJavascriptは計り知れない可能性を感じています。

開発フロー

フロント開発のやりがいの一つ、それはEnd User(今回はあえてユーザーさん、お客様などのことを構成図などの表記と一致させるためにEnd Userと記載します。)との距離が近いということ。また、問い合わせなどのやりとりはメールよりLINEが多く、Twitter、InstagramなどのSNS投稿からEnd Userとの声を感じやすい。さらに、スナックミーのSlackにはVoice of Customerというサービスおやつに対しての声を全社員に共有するチャンネルがあり、より一層身近に感じれる仕組みを取り入れています。
様々な声からマイページの機能へ落とし込むために下図のような開発サイクルになっています。

画像3

スナックミーの開発スタイルは一言でいうと「全員で作る」そのようなイメージと思ってもらえれば良いと思います。バイヤー、パティシエ、コーポレートなど様々なポジションが存在し、それぞれが束になりsnaq.me が作られます。そのため、エンジニアは要件だけ共有されて開発するというより、ご自身の意見(アイディア)から実装に落とし込むことが可能です。
【開発する上での面白さ】
同じコンテンツでもWeb上での見せ方一つで印象が変わってきます。動的なものだったり、色、ピクセル単位での配置などに気を配っていったり、そう言ったプロセスに面白みを感じますし、良いコンテンツができたとしても、ページのスピードが遅かったりすると大変勿体ないので、パフォーマンスも重要だったり、フロントとしての役割はただ見える部分だけではないところも面白い。

Amazon Web Services (AWS)なども挑戦できる

フロントエンジニアと言ってもフロント以外も関わりたい場合はいろんなチャレンジが可能です。2つほど例を出します。

・Lambda @Edge
・CI/CD

Lambda @Edge

比較的Lambda@EdgeはAWSの中では馴染みやすい内容だと思います。なぜなら
- オリジンへのリクエストをリダイレクト
 (国に固有の URLへのリダイレクト )
- レスポンスヘッダーのオーバーライド (SPA)
- A/Bテスト (異なるバージョンのイメージテストなど)
など様々なことができます。
スナックミー ではTwitterシェア時にOGP画像生成などでEdgeを用いています。

画像4

Lambda@Edge 関数では次の4つのCloudFrontのイベントをトリガーに設定できます。
[ビューワー]
Request: 全てのリクエストに対してCloudFrontのキャッシュを確認する前
Response: オリジンかキャッシュからレスポンスが応答された後
[オリジン]
Request: キャッシュミスの時にオリジンへリクエストを送る前
Response: キャッシュミスの時にオリジンからレスポンスが応答された後
詳しいことは[Lambda@Edge デザインベストプラクティス]を参考にしてください。 Lambda@Edgeだけでもフロントの表現幅は確実に広がります。

・CI/CD

もう一つがCodePipelineを用いたCI/CDです。

画像5

上記のようにスナックミー ではS3-CloudFrontでフロントを表現しています。 そのS3のバケットへファイルをアップロードするまでをCodePipelineで実行しています。
フロントの方がCI/CDの構築と聞くとAPI開発よりも畑が違うと感じる方が多いかもしれない。しかし、開発環境、テスト方法やビルドなどは開発しているフロントが一番理解しています。そのため、CI/CDも比較的根本を理解していると実現可能です。

アップロードまでのフローは、Githubのgit pushがトリガーとなりCodePipelineが実行され、CodeBuildでテストが走り、成功するとS3へファイルをアップロードする流れになっています。Pipelineの成功失敗はAWS Chatbot を利用してSlackで受け取るようにしています。AWS Chatbotは現在ベータ版(2020.04.21現在)であり、メッセージ内容のカスタムはできませんが、成功・失敗通知するのみではあればLambdaなど使わなくても容易に設定可能です。

まとめ

以上がフロントエンドがスナックミー との関わってきたことを紹介させていただきました。
- Userと近い距離で開発
- 新しい技術へのチャレンジ
- チームでサービスのリファイン
など
これが全てではないので、より詳しいことやここに書いてないことなど興味がある方はぜひ一度お話をしませんか?一緒に新しいおやつ体験創りをテクノロジーで実現しましょう。DMでも以下からでもお待ちしています。

Twitter↓↓



この記事が気に入ったら、サポートをしてみませんか?
気軽にクリエイターの支援と、記事のオススメができます!
読んでいただきありがとうございます!
6
@snaqme CTO co-founder / おやつ( snack-time ) / おやつ x IT / ベンチャー / エンジニア / 楽しく生きていく / トライアスロン・マラソン経験