伝わる、つながる、いい仕事。

お店のやること・VMD・情報連携がサクサク進む
「ふせん」でつながる本部・店舗間、店舗内のコミュニケーションサービス

StoreFINDは、店舗が主役となりお店で働く人がより活躍できるよう支援するサービスです。
店舗の役割・人にとって最適な指示・連絡の仕組みを実現する「ふせん」機能。企業の規模や業態に合わせて柔軟に活用でき、店舗のコミュニケーションロスを低減、指示の実行率が向上します。

StoreFINDは従前のP2NetEXの経験を踏まえ、AWS上でゼロから開発を行いました。
その時点の社内エンジニアにはAWSの経験がありませんでしたので、マネージャー、リーダーがAWSの勉強をするとともに、AWSに熟練したアーキテクトを探しました。 運良くお付き合いのあるパートナーさんから非常に優秀なアーキテクトを紹介していただき、IaC（Infrastructure as Code）やCI/CDも含め、トータルなアーキテクチャを作ることができ、大きなトラブルなどなく進めることができました。
基本的な機能の初ローンチまではプロジェクトがスタートしてから、10ヶ月ほどでローンチすることができました。

チーム体制はPM、アーキテクト、フロントエンジニア、バックエンドエンジニア、テスター、デザイナー、スマホアプリエンジニアがいます。半分が社員エンジニアで、残り半分が外部のパートナーエンジニアですが、別け隔てなくチームの一員として働いてもらっています。
社員のほとんど、外部パートナーさんは100%リモートでの開発です。
コミュニケーションのために週に一度、10分程度のZoomミーティングをしています。
基本的にはFigma、GitHub、GitHub Issue、Slack、で事足りますので、Zoomミーティングに関しても顔合わせ程度の感覚で、トピックがない週に関してはそれもスキップします。エンジニアは無駄な打合せを嫌いますので。
オンラインでのコミュニケーションが割とうまくいっているのではないかと思います。

StoreFINDに求められる要求というのは前のサービスのP2NetEXを10年以上やってきたことから、重要なポイントについては把握していました。同時多くのお店（1000店舗以上）で使われることから特定時間帯の急激なアクセスの集中（スパイクアクセス）と、従業員のマスターデータが頻繁に入れ替えが発生することによる、DBでのjoin、排他制御をどのように捌いていくか、というテーマがありました。これらをアーキテクトとともに雛形などを作り、アーキテクチャを確定していきました。

使っている技術は、フロントエンドは、Vue.js、バックエンドはAmplify、GraphQL、DynamoDB、OpenSearch、Step Functions、Aurora、Fargate、PostgreSQLなどを使用し、KVSとRDBのハイブリッドDBを構成することにより、スパイクアクセスとマスターデータの入替の負荷に対応しています。

GitHub Issueを使って、スクラム開発をしてしています。
ブランチ戦略をある程度決め、GitHub Flowを少し簡略化したモデルで回しています。
コードレビューもしっかり行っており、コード品質は気をつけています、スプリントサイクルは最初のローンチから３年間ほど2週間のサイクルで行っていましたが、StoreFINDというサービスがBtoBで、利用するユーザーが企業ユーザーであり、機能が増えてきたことにより２週間サイクルでのバージョンアップではユーザーへの周知が難しくなってきたことがあり、ユーザーの希望で１ヶ月サイクルへ変更しました。
１スプリントが少し長いですが、やってみると大きな問題がないことから、今は１ヶ月サイクルでスプリントを回しています。